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.
Sounded the same in both posts to me.
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
I wonder, what will happen to the kernel source then? Surely this means that some part of the kernel is available as source while some other part isn't. If some distribution flatly refuse to incorporate Intel's patches to stay open source, then isn't it will inevitably split the kernel in two? One with BSD license and one with GPL?
Wonder what RMS will shout about this.
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.
Not quite. Linus is ok with it, that should be the zealot seal of approval.
ACPI is becoming far more important these days and this is more about standards not taking something AWAY from linux.
Please read the store first, and please understand the issues before posting. Linus's stance is actually very openminded
still reading?
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.
Touche
File under 'M' for 'Manic ranting'
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'd dare say that those who call it viral are simply calling a spade a spade.
One might agree with the viral provision, as it seems unfair for somebody to profit from what is free code, still it does not change the fact that the GPL is viral.
p.s. About the question in your subject line RTFA.
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
So, Intel is giving a little, RedHat is giving a little, and some parts of RedHat's distro may not be opensource at some point in the future.
Now, this is all fine and dandy. The fact remains, though, that all Intel is doing is keeping their bought-and-paid-for code private. All RedHat is doing is bundling some private code with some opensource code. Now, I haven't memorized the GPL, but restricting this kind of thing sounds pretty draconic.
-Amalcon
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
Perhaps this hinges on the precise definition used for the term "viral"?
Whenever I have encountered the term, it has always been defined thusly (approx.):
"You know, like a virus. You know what I mean."
Now it doesn't use either DNA or RNA, so some other analogy is indicated, but what? Nobody seems to define this clearly, so it's not surprising if different people come to slightly different conclusions. With resulting disagreements when the term is used.
"calling a spade a spade"? No, not so. You are extracting an analogy from an image that can present itself in several different ways. There is no straightforward mapping.
I think we've pushed this "anyone can grow up to be president" thing too far.
If I'm remembering his past quotes correctly, this won't cause RMS any problems either. He's quite dogmatic about his principles, but this doesn't violate any of them, as I understand them (and as I understand it).
I think we've pushed this "anyone can grow up to be president" thing too far.
If you don't like the BSD license, then don't use it as the other poster mentioned. No one is forcing you to use a license that you don't want to use. It all depends on which license is the best option for the situation. Kind of like how you could use a screwdriver to drive in a nail, but wouldn't a hammer or a mallet work better?
Perhaps this hinges on the precise definition used for the term "viral"?
Viral in that it's self-replicating, it spreads to any code it gets in contact with, even a minute amount of code is enough to infect a large system, and lastly it does so without input or consent of the larger host.
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.)
Is that supposed to make sense? How exactly does a piece of code give "input" or "consent" to anything?
Or did you mean the creator of the larger host? In which case, you're completely wrong. A piece of GPL'ed code cannot insert itself into another program. It is up to the author as to whether he chooses to use it or not. If he uses it, he may only do so under the terms of the license.
I think that "viral" is a somewhat meaningful term in the context of this article -- i.e. in comparison to other free software licenses, like BSD.
The problem is that people like Steve Ballmer are using it as a scare word. And in doing it, they're obscuring the important truth that any free software license makes a piece of software far more useful to the user than any proprietary license.
GPL: you may freely use and re-distribute this software; you may build on this software too, but you must license the result under the GPL.
Proprietary Licenses: if you pay us, you may use this software on one PC; you may not use it in any other way, re-distribute it, or build on it.
Frankly, I think your statement is fear mongering, and it's just giving ammunition to the bad guys. Unless, of course, you are the bad guys yourself...then just FOAD.
What was the last contribution you made to this nebulous "community"? Or are you only interested in "taking from the community" (running the software for free) without giving something in return? Pot, kettle, black, eh?
(and if in my ultimate wisdom I've chosen to pick on one of the few active open source developers also on Slashdot, my apologies -- however, the majority of people never have and never will contribute anything to "the community", myself included.)
I don't quite see why a CA/GPL licence wouldn't work, unlike the CA/GPL/BSD triple licence that it appears to be now... Maybe it's because Intel would like to be able to use that code under some (unspecified) other licence than CA, now they can take the BSD code and put it under any licence they want.
The only potentially bad thing is that now anyone can take the BSD code and extend & embrace from the latest version, but I don't think that's any problem here...
Kjella
Live today, because you never know what tomorrow brings
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'
1. Read the GPL (all of it, not just the self-aggrandizing preamble)
2. Read the BSD license
3. Read the article
4. Answer your own question
0 1 - just my two bits
But, if you had such a worldview, then how are you different than Microsoft....
Haven't been here long, then, have you?
This is like a Wobblie rally. We are supposed to be One Big Union under GPL, all for one, one for all.
Don't be un-mutual (reference to 'The Prisoner'). Haven't you heard the Free Software Song?
"You'll be free, hackers, you'll be free."
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.
So do you suppose this will put a stop to Microsoft's "GPL is viral" FUD and encourage other hardware vendors to work to support more OSes?
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
AFAIK GPL prevents code in the same "product" to be anything else than GPL:ed.
Even if you have a license on one part of the kernel that is dual-licensed, you still have to obay to the terms of all other contributors. Who probably have not agreed on you making derived works that are not GPL:ed.
GPL states that if you cannot guarantee that the code can be used with the same rights as you have, you cannot distribute it at all.
Scenario:
1. You submit a patch to intel which you dual-license.
2. This is a derived work of many contributions in the kernel.
3. Intel redistributes you patches with their code under limited license.
4. The users recieving that code cannot get the sources for your derived work on GPL:ed software.
5. You have broken your license with numerous contributors.
Bottom line:
All code in the product needs to be dual-licensed not just a part of it.
Btw.. I dont like this. But nobody said I had to agree with it. Take it or leave it, Stallman says.
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.
And they can't see your code under *GPL? You're delusional. You wouldn't know if they took 200 lines and slapped it into some product. If you think this doesn't happen just cuz its under your blind GPL you're a fool.
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.
it's self-replicating, it spreads to any code it gets in contact with[...]
Hogwash! First of all, simple aggregation is clearly excluded. Second of all, it's not different from any other piece of copyrighted code in that respect. If I post a useful subroutine on my web page, and I don't include any license, and that code mysteriously "spreads" to your application, then you've been "infected" with copyright violation, and I've got a solid basis for a lawsuit.
it does so without input or consent of the larger host.
Uh-huh, just like my copyrighted, license-free code. Which just somehow "insinuated" itself into your app without your knowledge or consent. What a crock. The only thing the GPL does is provide you with an optional automatic defense against charges of copyright violation. You can at your choice release the derivative work under the same terms (GPL). But that's a choice -- your code does not automatically become GPL'd just because you included GPL'd bits.
That's it, the only difference between unlicensed code and GPL'd code is that the GPL'd code allows you an optional out from accusations of copyright violation. No matter how unpalatable you may find that option, GPL'd code is no more (or less) viral than unlicensed code.
Now, if you want to argue that unlicensed code is also viral, then I'd at least give you points for consistency. But in that case, it's not the GPL that makes the code viral, it's simply that the GPL fails to "de-viralize" the code. Thus, rather than being a virus itself, the GPL is simply a "non-de-viralizing" license, unlike, say, the BSDL which we can now classify as a "de-viralizing" license. That, at least, would be an interesting argument, unlike the troll you posted.
Oh, and BTW, when you said, "even a minute amount of code is enough to infect," that's also BS. Since it's copyright law that makes the code "contagious," any defense against copyright violation (such as fair use) will work as a defense against accusations of GPL-violation, since it's actually copyright law, not the GPL, that's being violated in such cases.