lkml.org 
[lkml]   [2000]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
On 4 Sep 2000, Henning P. Schmiedehausen wrote:

>>> >I am sorry to here of this, but I know what you mean about microsoft.
>>> >My and co-worker's code for doing full taskfile access under linux was
>>> >rejected here but is being used in MicroSoft Whistler 2001. They are
>>> >quick to grab the very best of Linux and adopt it for their own.
>>>
>>> If you can prove this, then you could talk to FSF about M$ GPL
>>> violations.
>
>>You can not go after people for patches.
>
>Hi,
>
>>there is no GPL issue. Upon Microsoft's adpotion of the model they will
>
>of course you can. Just don't release a patch but grab the driver
>you're patching against (which is GPL), add your modifications and
>release your driver with full task file access as a complete package
>(including the full .c and .h files) under GPL which is compilant with
>the available license. I think you can even do this with a patch. But
>then again it is your call to add or name a license.

I was under the understanding a "patch" to something GPL, means
the "patch" is also GPL. If the patch was not GPL, and it
patches GPL code, then it itself is in violation of the GPL. The
fact that the patch is a "derivative work" of the original GPL
code, means it is GPL wether stated or not.

Someone removing a portion, and using it, must make their work
GPL as well.


>It is your code. You can put it under every license you want. You can
>even put it under the "no white male over 28 years and left handed is
>allowed to use this code unless he types it into the keyboard with
>only his left hand and the right hand tied behind his back"
>license. If is, after all, _YOUR WORK_ and you can choose to license
>it in every way that you want.

But if the code is a modification to a GPL work, then it must be
GPL only. In other words, a patch to the kernel which modifies
existing kernel files, MUST be GPL or else it is useless. You
can call it "My private license" if you like, but that prevents
it from being used in the kernel because "My private license" is
not GPL compatible. The key word is "derivative work" here. If
your patch or other program is a derivative work of something
else GPL, you can NOT license it how you see fit. If your code
contains code from other GPL sources as a whole, then you require
permission from those sources to relicense the code under a
different license.

If you didn't, one could make a kernel patch that modifies
existing kernel GPL code, say it is licenced as public domain,
and then allow Microsoft to use the patch which now contains
linux kernel GPL code as if it were not GPL'd. That is not the
way it works at all.


>There are even countries (like Germany) where you CAN'T give up your
>copyright and put things into public domain. There is no such thing as
>public domain here. You _always_ keep a certain copyright until
>someone else assumes responsibility. It is for sueing people over
>here. :-)

Cool. ;o)

>new variables if you want to stabilize things. The existing IDE driver
>works fine for normal operations so it was kept. I would bet much that
>your IDE driver will be one of the first things included once 2.5 is
>opened up.

I duly hope it is!

>Until then, nothing stops you from releasing patches against official
>2.2 and 2.4 releases. I'm sure that many people will use it and SuSE
>will put it into its kernel (they put everything they can find on the
>net into their kernel :-) ). I will use it as I really enjoy the new
>features for IDE under 2.2. But not on my business-critical machines
>but on my Workstation and my machine at home.

As will I when 2.4 final is released...

>"FreeBSD will laugh at us" to look onto the installed server and user
>base and then to realize that BSD was years before Linux and failed
>where Linux succeeded. And Linux did not succeed because it was aimed
>"at the server market" or "at the end user" but because there is a
>bunch of people _that_ _do_ _not_ _care_ _at_ _all_ about the
>"marketability" of a feature but for the correct solution. As long as
>decisions in the kernel are made because of good and bad taste, I'm
>not at all afraid for Linux.

Good point.. That is one of the things I like most about Linux.

>"They" came to Linux. Not vice versa. And "they" did not come just
>because Linux is good. But because the alternatives are worse. And are
>not improving. Just ask yourself why there was no such rave about the
>release of the 4.4BSD code, the first FreeBSD and the first OpenBSD
>release. It is not because their code is bad. But they have no cute
>mascot as Tux and no all-famous benevolent dictator from Finland. :-)

Right, and "Linux" is a word you can pronounce easily, and it
sounds cool. Linus himself I believe when asked "why would one
use Linux over FreeBSD aside from the cool name" responded
something like "No that is the main reason - because Linux has a
cool name."

I about fell off my seat laughing when I read that one... I think
it is in the fortune database... A good one-liner. ;o)

--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate

"Facts do not cease to exist because they are ignored."
- Aldous Huxley

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.164 / U:0.796 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site