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.

17 of 127 comments (clear)

  1. Superior Power Management... by $$$$$exyGal · · Score: 3, Insightful
    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

    --
    Very popular slashdot journal for adul
    1. Re:Superior Power Management... by 6 · · Score: 3, Insightful

      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.


  2. Sensible for Intel by Fluffy+the+Cat · · Score: 4, Insightful
    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.

  3. Indeed by kfg · · Score: 2, Insightful

    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

  4. How does redhat even have the authority to do this by mark-t · · Score: 2, Insightful
    Subject line says it all.

    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.

  5. Re:How does redhat even have the authority to do t by Anonymous Coward · · Score: 4, Insightful

    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.

  6. Why dual license? by shepd · · Score: 3, Insightful

    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
    1. Re:Why dual license? by HiThere · · Score: 4, Insightful

      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.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    2. Re:Why dual license? by shepd · · Score: 2, Insightful

      Okay, allow me to be more detailed:

      ANY BSD source that touches my system is automatically GPLd, 'cause that what I like (Go ahead and call me a zealot if you like, it doesn't change that fact :-). Sorry, I didn't think of binaries. I guess I just never touch stuff like that unless I have to, and when I have to, it's because it's usually proprietary, and in that case I'm spending my time looking for alternatives.

      There. That should clear it up. Sorry, I guess I just didn't think about binaries (GNU tunnel vision! :-)

      --
      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
    3. Re:Why dual license? by bovinewasteproduct · · Score: 4, Insightful

      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

    4. Re:Why dual license? by SN74S181 · · Score: 2, Insightful

      Just like BSD model itself, even the licensing is a fractured mess.

      Wow.

      What a statement. Well, if you think the BSD model is a fractured mess, you'd better stay away from the big swamp of incompatible versions, non-standard /etc structures, and in general the totally fractured mess that is Linux.

      Hell, any kludge that two kids throw together can be considered a 'Linux distro.'

  7. Re:Why not to use LGPL? by swmccracken · · Score: 2, Insightful

    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.

  8. Re:How does redhat even have the authority to do t by Anonymous Coward · · Score: 1, Insightful

    ...and lastly it does so without input or consent of the larger host.

    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.

  9. Re:Quite a lot of fuss; not too important... by Anonymous Coward · · Score: 2, Insightful

    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.

  10. Re:I went right to the source: microsoft.com by mark-t · · Score: 2, Insightful
    By the same reasoning that a person should not expect to have the right to freely copy copyrighted works for which he has received no authorization to do so, a person should likewise not expect to be able to restrict the copyright that an original author has placed on material, as in the case of the GPL. An author of GPL material chooses to do so, and chooses to keep his (copyrighted) material free for duration of the copyright. He has as much right to demand this as a book author has to expect to be paid for his published works.

    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.

  11. Not exactly... by inode_buddha · · Score: 4, Insightful

    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
  12. ACPI driver license by stock · · Score: 2, Insightful
    So Intel and RedHat (well lets call it here the Linux kernel community) agreed to have the ACPI driver source inside the linux kernel tree to have 2 licenses. the GPL and the BSD. Because its GPL we as Linux people are happy. And because its also BSD licensed, Intel is also happy, because parts of its open-source project can be extracted as BSD licensed code. That code can then be implemented inside binary only commercial software concerning ACPI. How briljant. It sure is a way commercial OS vendors really can benefit from that open-source project.

    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.