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>

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)