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.
Intel wanted to have the code under a "looser" license so that they could accept patches back for use in non-GPL projects.
People often say that companies want to use the BSD license, because they want to be able to take and not give back. This is true in many cases, no doubt. In this case, Intel is also contributing back.
Could this not have been resolved with a dual GPL/Intel license, rather than with a BSD license, much like the Trolltech dual licensing scheme?
</peanutgallery>
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
More like...
[one Intel engineer to another] "don't worry about our hardware bugs, the software departement will find a workaround".
To be completely honest, linus will probably not care. Despite the common opinion around here, linus did not chose the GPL as a religious decission. If yo uremember correctly, at first, linux was distributed with a very restrictive license that prohibited comercial use.
I'm glad they came up with an acceptable agreement. The end result is that more people will have superior power management abilities... and those people probably won't care how they got them. Still though, they wouldn't have the ability so quickly and as well if Intel and Redhat didn't come together.
--sex
Very popular slashdot journal for adul
The problem is that Linus isn't a GPL zealot, so I'm not sure that he'll say anything at all. Why should he?
Linus's kernel is licensed under the GPL, but Linus, and Linux, do not "stand" for it.
I think you've been taking RMS's insistence that it be called GNU/Linux way too much to heart.
RMS and GNU *do* stand for the GPL, and as RMS himself will be delighted to explain to you, at extreme length, Linux is not GNU.
KFG
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.
There are situations where a BSD-style license is preferable to the GPL. This is one of them.
But the licenses are specifically written for that other 1% for whom the differences are critical, so your observation rather loses its point.
Developers "use" software too.
KFG
Linux is GPL, any changes made to Linux *become* GPL. Period.
Some call this the "viral" aspect of the GPL, but I daresay that those are the people who are only interested in taking from the community without giving something in return.
I could easily rant for half an hour on the subject, but the question I posed in the subject line remains.
File under 'M' for 'Manic ranting'
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.
I could easily rant for half an hour on the subject, but the question I posed in the subject line remains.
Tell you what. A better use of that half hour would be spent reading the article.
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
Thanks Linus. I don't think that I have any inherent moral right to dual-license reiserfs, but it sure is pragmatic to do so, and the courtesy of permitting me to do so is gratefully accepted from our contributors.
A bit more than half of our income comes from the dual licensing, and we'd not have survived to this date fiscally without it. If anyone on the reiserfs team ever owns a Boxster;-) at sometime in the future, it will be from dual-licensing to Apple, a storage appliance vendor, or the like.
(from Hans Reiser)
Mielipiteet omiani - Opinions personal, facts suspect.
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
-
All BSD code is also GPL code (or any other license, by definition). Simply insta-fork it every time it comes out. Problem solved. Everyone wins, especially the GPL guys if they make improvements, since they can't be back-ported to the BSD version.
I see this is a great way to ensure BSD people win, proprietary vendors win, and GPL people win.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
I suppose this deal is important but there is sooo much license, DRM, patent, intellectual property, etc stuff on Slashdot it should really be called Legal issues for nerds
Then don't contribute to the ACPI code, write your own version that's GPL only or whatever.
Remember that Intel wrote this code, they can do what they damn well want with it.
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.)
I agree. I don't understand why the GPLers are up in arms over this, except that it shows a deliberate GPL restriction (which has it's place and uses in a _community_ license such as the GPL) in plain site.
I'm a BSDer. I think they chose the correct license. And, more importantly, as you pointed out, it's Intel's code to give. Just as when someone contributes to a GPL code base, it's their code to give and decide what license to choose. Intel has that right also and what they did does not restrict GPL code bases.
For those of you who don't like this, your argument is not a license issue. It's about open hardware design, not source.
It is also worthwhile to note that the person who holds the copyright on a GPL software package is fully free to create derived works under non-GPL licenses, since he created the original work in the first place. If the GPL were truly "viral", this would not be possible. The GPL, by its very virtue of being a copyright, *cannot* limit the rights of the copyright holder or those who are explicitly authorized by him.
Besides, if you really, really want to create a non-GPL version of GPL software, there is a fairly simple, albeit tedious, way to accomplish this. Analyze the GPL software to the point that it is understood as fully as if you had written it yourself. Write the software in a high level language, such as structured english, which describes *WHAT* the program does at each step, but not specifically say *HOW* it is done (for example, if some kernel code uses a sorted array to hold the set of process control blocks and uses a binary search method to locate entries, rather than describing the binary search algorithm in detail, simply say something like "the PCB list is held in memory as a contiguous block, and search times for random entries cannot exceed O(log(n)) where n is the number of entries currently in the list" when describing the variable, and when you want to find some particular entry, you simply say "look up label XYZ in the PCB list"). The pseudocode can then be passed off to another competent person to implement. Huzzah, you have a derived work, but no GPL. The GPL, as a type of copyright, cannot have any government over the ideas expressed within a work, only over the work itself.
This has gotten massively offtopic, and I kind of expect to be moderated as such, but that's about all I intend to say about this.
File under 'M' for 'Manic ranting'
Linux is GPL, any changes made to Linux *become* GPL. Period
Not exactly. Linux as a whole must remain GPL'd. However, individual components may be licensed under other terms, as long as the whole remains GPL'd. This means that the licenses for the components must be compatible with the GPL, and must allow sublicensing. BSD (except the old, 4 clause BSD), MIT/X, and LGPL are all examples of licenses that meet these criteria.
This is done all the time -- most of the networking code in Linux is, AFAIK, still under BSD license. Yes, that means that someone could, in theory, extract the BSD-licensed code from the Linux kernel and use it in their proprietary system, but so what? They could just as easily have gotten it directly from one of the BSD projects in the first place.
More than a few people here might be surprised to know that there was a *huge* flame-war on the linux kernel mail-list a few weeks ago which dragged on for days, regarding the use of nVidia's closed-source drivers in the kernel, regardless of however open or closed the hooks into their drivers may be. (W/R/T hardware GL rendering) Evidently, it's ok with Linus, and it *is* his project after all, so I can't really complain. Especially not since I use nVidia cards.
Conclusion: It's possible. Nothing new to see here, let's move along...
C|N>K
Dual/triple/whatever licensing doesn't give Intel any new rights. The GPL doesn't put any restrictions on use of the code by its licensor. That's why it's possible to dual-license code in the first place.
All that's happened is that Intel has successfully established a practice for Linux kernel code that the license granted by the author is the license of the component. Linus Torvalds has stated that he won't accept license-narrowing patches into his source tree, and that's as close to Official Policy as you'll ever get. Intel has always been free to do what they like with the code, and to make whatever requirements they like of those who send them patches. Requirements like allowing dual licensing, or even assignment of rights (a good thing if a complex piece of GPLed code ever has to face a copyright-defense lawsuit).
This is a good thing. Everyone who believes in the GPL should support the right of an author to set the terms of use for his or her code. That should include patches - they're modifications of his or her code: in GPL terms, they create a derivative work.
It makes no sense that a patch should not be available to the original author of the code being altered.
Now the only question remains : Who pays the Linux kernel programmers doing ACPI? and if they are not payed , do they feel ripped off when contributing to ACPI functionality inside the Linux kernel ?
Robert
detante : 007 : "if i won't get it , neither will you". and the painting is destroyed.
reverse detante : "if you will get it, then i want it too!". and the source code is copied.