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.

Comments

Released not just BSD, also GPL

[1010011010]

From the Mailing list archives
The ACPI AML interpreter (i.e. code in directories under drivers/acpi, but
not source in drivers/acpi directly) has been released by us (Intel) under
the GPL. It has also been released separately under a looser license, so
that other OS vendors may make use of it.

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>

Intel patches?

[Anonymous Coward]

More like...

[one Intel engineer to another] "don't worry about our hardware bugs, the software departement will find a workaround".

Re:What will Linus say?

[Anonymous Coward]

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.

Superior Power Management...

[$$$$$exyGal]

It involved one component of power management software used in Linux and several other operating systems.

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

Re:Superior Power Management...

[6]

The end result is that more people will have superior power management abilities... and those people probably won't care how they got them.

But isn't that the point? If all that was important was having the niftiest and greatest thing why not just use windows?

The entire point of the GPL was that it does matter how a goal was achieved. This is just one more step down the path of reducing Linux to just another corporate OS.

Re:What will Linus say?

[kfg]

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

Re:What will Linus say?

[Kourino]

I know Linux will definitely be opposed to such an action by Red Hat.

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.

Re:What will Linus say?

[baywulf]

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.

Sensible for Intel

[Fluffy the Cat]

Intel want ACPI to be adopted by as many OSes as possible, and they want it to work. Releasing their code under a license that allows OS vendors to simply integrate it into their own OS increases compatibility (the Windows ACPI interpreter has a somewhat different interpretation of the standards to the Intel one) and is plainly in their own business interests.

There are situations where a BSD-style license is preferable to the GPL. This is one of them.

Re:How does redhat even have the authority to do t

[mattdm]

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.

Re:How does redhat even have the authority to do t

[Anonymous Coward]

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.

Two of the messages from the thread

[Vlad_the_Inhaler]

(snip) 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

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)

Linus says:

[Anonymous Coward]

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
-

Why dual license?

[shepd]

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.

Re:Why dual license?

[HiThere]

No. All BSD code can be GPLd. This isn't automatic. If you get your hands on a BSD binary, the restrictions of the GPL that allow you to get the source cannot be invoked. So neither is included in the other.

If you can choose, as a user you would generally prefer to have got the code under a GPL license, and as a distributor you would perfer to have gotten it under a BSD license. (If you care about the difference, of course.)

The GPL license was developed to benefit the developers of the code, but the mechanism for doing so involved giving extra rights to the users of the code (i.e., the legitimate recipients) at the cost of the distributors.

Re:Why dual license?

[bovinewasteproduct]

All BSD code is also GPL code (or any other license, by definition).

Not if they use the 4 clause BSDL.

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.

So, you just want the ability to take the code and not give back to the project? Sounds just like the compliants the GPL guys use aginst the commericial people... hummmm....

And people wonder why I use the 4 clause BSDL...

BWP

Legal issues for nerds

[hey]

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

In december 2002, he said

[swmccracken]

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.)

Not exactly...

[inode_buddha]

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...