Slashdot Mirror
Intel, Red Hat Agree To BSD License For Intel Patches
stock points to this story on CNET, excerpting "Red Hat and Intel have settled a licensing hiccup that threatened to prevent the Linux company from contributing to Intel's open-source project--a reminder of the frictions that can arise between the commercial tech world and the open-source community." By adding a BSD-variant license to certain kernel contributions from Intel, the two companies have bridged an impasse between the GPL and Intel's "component architecture" license.
Wrong. Linus is fine with it. Andy Grove announced on the kernel mailing list that this would be happening back in November, and Linus was fine with it then. The article mentions this too, maybe you'd like to read it next time? :3
Remember, Linus is the pragmatist of the community, the one that doesn't believe in software to further some philosophy.
If you read the link to the kernel mailing list in that article, you will see that Linus' belief is quite the opposite. He believes that it is the right of the original developer of the code (ie Intel) to set the terms of the license be it dual license or not. Thus he will not accept patches to the code which are not released the both licenses of a dual license.
Linux is GPL, any changes made to Linux *become* GPL. Period.
Changes, sure. Completely new contributions, however, can both become GPL'd and remain under some other license. Just because code touches something under the GPL doesn't mean it automatically becomes "contaminated" permanently.
[...] but I daresay that those are the people who are only interested in taking from the community without giving something in return.
You can daresay all you want, but looks like me the concern is more about getting a standard adopted and usable everywhere.
From: Linus Torvalds (torvalds@transmeta.com)
Date: Sat Dec 07 2002 - 15:07:38 EST
>You can't forbid people to send GPL-only patches, so if a person doesn't
>want his patch under your looser license you can't enforce that he also
>releases it under your looser license.
That's true, but on the other hand we've had these dual-license things
before (PCMCIA has been mentioned, but we've had reiserfs and a number
of drivers like aic7xxx too), and I don't think I've _ever_ gotten a
patch submission that disallowed the dual license.
In fact, I don't think I'd even merge a patch where the submitter tried
to limit dual-license code to a simgle license (it might happen with
some non-maintained stuff where the original source of the dual license
is gone, but if somebody tried to send me an ACPI patch that said "this
is GPL only", then I just wouldn't take it).
I suspect the same "refuse to accept license limiting patches" would be
true of most kernel maintainers. At least to me a choice of license by
the _original_ author is a hell of a lot more important than the
technical legality of then limiting it to just one license.
So yes, dual-license code can become GPL-only, but not in _my_ tree.
Somebody else can go off and make their own GPL-only additions, and
quite frankly I would find it so morally offensive to ignore the intent
of the original author that I wouldn't take the code even if it was an
improvement (and I've found that people who are narrow-minded about
licenses are narrow-minded about other things too, so I doubt it _would_
be an improvement).
Linus
-
In december 2002 Linus said,
"At least to me a choice of license by the _original_ author is a hell of a lot more important than the technical legality of then limiting it to just one license."
May I recommend reading the always excellent Kernel Traffic? This particular issue was first delt with here, so it's not news to anyone that reads Kernel Traffic.
Remember that this code was written and maintained by Intel anyway; in fact, any patches done to the code from outside Intel were redone internally by Intel so they could reuse the code for other uses. ("We have to determine the problem the patch fixes and then do the fix ourselves." - from the Kernel Traffic writeup.)