Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel, Red Hat Agree To BSD License For Intel Patches

Posted by timothy on from the bsd-is-like-a-convertable-suv dept.

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.

7 of 127 comments (clear)

  1. Released not just BSD, also GPL by 1010011010 · · Score: 4, Interesting

    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>
    --
    Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
  2. Re:What will Linus say? by Anonymous Coward · · Score: 3, Interesting

    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.

  3. Re:What will Linus say? by kfg · · Score: 3, Interesting

    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

  4. Two of the messages from the thread by Vlad_the_Inhaler · · Score: 4, Interesting
    (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)

    --
    Mielipiteet omiani - Opinions personal, facts suspect.
  5. Re:How does redhat even have the authority to do t by Xtifr · · Score: 2, Interesting

    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.

  6. GPL only and GPL/someother dont mix by peope · · Score: 1, Interesting

    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.

  7. Intel could have done that before by JohnQPublic · · Score: 2, Interesting

    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.