Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Intel Software Businesses Red Hat Software Linux

Intel, Red Hat Agree To BSD License For Intel Patches 127

Posted by timothy 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.
This discussion has been archived. No new comments can be posted.

Intel, Red Hat Agree To BSD License For Intel Patches More

Intel, Red Hat Agree To BSD License For Intel Patches

Comments Filter:

  • Released not just BSD, also GPL (Score:5, Interesting)

    by 1010011010 ( 53039 ) on Sunday February 16, 2003 @01:28PM (#5314692) Homepage

    From the Mailing list archives [iu.edu]
    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>

    • Why dual license? (Score:3, Insightful)

      by shepd ( 155729 )
      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? (Score:5, Insightful)

        by HiThere ( 15173 ) <charleshixsn.earthlink@net> on Sunday February 16, 2003 @02:54PM (#5315090)
        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? (Score:2, Insightful)

          by shepd ( 155729 )
          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! :-)

          • The BSD license isn't the same as public-domain. The only person who can change the license is the copyright holder. Sure, you can GPL your own changes to the BSD-licensed code, and distribute those changes as such. And you don't have to resistribute the original, since it wasn't GPL'd. But you can't redistribute the whole thing as GPL, because you don't have the copyright to the original.

            This is probably the second of the most common misconception concerning of the BSD license. The most common misunderstanding is the idea that the BSD license allows people to "steal" the code and make it proprietary. That's false -- they are in the same position that you are. They can only make proprietary their changes and additions to the code. The original is as freely available as it ever was, as are all changes released under the original license. There is no added impetus to fork the BSD-licensed (and thus publically available) version.

            I don't see much use in arguing over whether the GPL or the BSDL is more "free" -- such discussions tend to turn on semantic hair-splitting or contrived examples and probably have more to do with the personal inclinations of the people arguing than anything else. My own feeling is that both licenses have their place and there relative "freeness" depends upon the situation.

            -Ed
            • But you can't redistribute the whole thing as GPL, because you don't have the copyright to the original.

              Oh yes you can - and in fact the GPL requires you to do so if you link in someone else's GPLed code.

              Legally speaking, you have compilation copyright, so you can set the license for the whole compilation.

              • You're engaging in the same fallacy as the original poster. You cannot change the license of the original work. It's as simple as that. No amount of handwaving will change this simple fact.

                However, you can GPL your patch file, and thus prevent your changes from being incorporated back into the original and distributed under the original license. And you can claim compilation copyright on the distribution of the original plus your patch file. But you cannot claim copyright on the entire result of applying that patch file and so discard the claim of the original copyright holder. It may seem like a fine distinction given that the end result is the same, but it is the form of the distribution that is significant, not the form of what eventually gets compiled.

                -Ed
            • You can relicense BSD work. That's what the license says. The only restriction is that the new license must retain the original copyright.
            • >The most common misunderstanding is the idea that the BSD license allows people to "steal" the code and make it proprietary. That's false -- they are in the same position that you are. They can only make proprietary their changes and additions to the code. The original is as freely available as it ever was, as are all changes released under the original license.

              Clearly, one cannot retroactively change the license. Again, I'll clarify my meaning:

              If I am creating a proprietary, closed source, operating system, and I'm too lazy to write my own IP stack and IP utilities, is it legal for my to lift, verbatim, the code for that from another project, assuming that code is licensed under the standard BSD license, and integrate a significant amount of it into my product? If so, am I allowed to sell that product, including that code? And, again, if so, do I, in any obvious to a normal user way, have to state that the product contains any non-proprietary code or any code not specifically created by myself?

              If so, doesn't that strongly smack of authorized plagarism? A lot of people (including myself) do consider plagarism (of all forms) stealing.

              That's the way I feel about it. With the BSD license, I'm free to take anything I like, make minor (or no) improvements, and release said software as my own. Perhaps people using the BSD license have no problems with this, I don't know. I know it would make me feel uncomfortable, at best.

              Considering the fact that even direct forks with just a name change are very successful (vis. a vis. NeoAudio) it seems to me the original authors could easily languish in obscurity while someone who is simply better at marketing enjoys all the glory.

      • Re:Why dual license? (Score:5, Insightful)

        by bovinewasteproduct ( 514128 ) <gclarkii.gmail@com> on Sunday February 16, 2003 @04:43PM (#5315550) Homepage
        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
        • >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....

          Yup. And its just an example of what's wrong with the original, normal, BSD license. Not one of it's hacked up variants.

          Of course, unlike the commercial people, I'm nice and wouldn't sell my newly GPLed BSD-based software. But I don't have to be that nice -- I could be like MS and rip off the hard efforts of the BSD team!

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

          And if people are stupid enough to not to protect themselves against commercial entities taking their code with recompense then they deserve what they get. As a businessman, I don't feel bad at all for someone who forces their own raw deal on themselves.

          Kudos to you for using a different than standard BSD license. Just like BSD model itself, even the licensing is a fractured mess.

          • Re:Why dual license? (Score:2, Insightful)

            by SN74S181 ( 581549 )
            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.'
            • Hell, any kludge that two kids throw together can be considered a 'Linux distro.'

              Of course. Since Linux is only a kernel it doesn't take much. Creating a usable system is a whole different matter. Then again that depends on what you want to use the system for, you can create systems specialized for any purpose.
            • What fractured mess is linux? I only see one official tree avilable at ftp.kernel.org. Am I missing something? Is there another official Linux available that I can choose? Is there another GPL license, apart from the GPL and LGPL that I can choose from?
              If so, I'm clearly misinformed about linux. Sorry.
              • What fractured mess is linux? I only see one official tree avilable at ftp.kernel.org. Am I missing something?

                Normally (unless they are following the FSF standard of GNU/Linux, in which case Linux means just the kernel) when someone mentions Linux they are talking about the Operating System, not just the kernel. If this is NOT the case, then you need to try and convince the media of this. And yes, there is way more distributions (ie operating systems) of Linux (the OS) than there is of BSD.

                Plus, on any of the BSDs systems (even old ones like SunOS < 5.0), I can expect certain utilities to be located in a certain place. The hier.7 the man page has been around for a LONG TIME.

                Is there another GPL license, apart from the GPL and LGPL that I can choose from?

                Nope, not unless you count the knockoffs. Which you seem to do...

                BWP
                • >Normally (unless they are following the FSF standard of GNU/Linux, in which case Linux means just the kernel) when someone mentions Linux they are talking about the Operating System, not just the kernel. If this is NOT the case, then you need to try and convince the media of this. And yes, there is way more distributions (ie operating systems) of Linux (the OS) than there is of BSD.

                  I have no problem with there being lots of distributions of Linux, but they all use the same underlying kernel. Any modifications done to the underlying kernel have been (by virtual requirement of any public GPL project) submitted back to the community and, therefore, any linux distribution can run any linux software, and will run it identically to any other linux distribution, assuming one has added any necessary patches (very few of which exist, except to maintain proprietary software).

                  I understand that with BSD ports, any BSD software should run on any BSD system, however, with the fractured state of the basic BSD kernel (multiple different competing kernels) there is no guarantee that this software will run identically on every BSD system, or that it will necessarialy be available for any BSD system.

                  >Plus, on any of the BSDs systems (even old ones like SunOS Nope, not unless you count the knockoffs. Which you seem to do...

                  There's GPL knockoffs? I've seen different licenses with totally different lineages that happen to be similar to the GPL, but I always thought the GPL protected itself against willy-nilly modification.
                  6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

                  Of course, if your software is completely written from scratch, yes, you could modify the GPL to suit your tastes. However, you wouldn't be able to include any GPL software, and that would make it very difficult to develop it to interoperate with a GPL environment without adding more freedoms (ie: Freedom to change the license, such as the BSD license) than the GPL already provides, or black-boxing an entire rewrite of the GPL-affected code.

                  This ensures that the licensing of programs is relatively similar in the GPL world, but AFAIK, there's no such impetus in the BSD world, apart from being neighbourly. :-)
          • Yup. And its just an example of what's wrong with the original, normal, BSD license. Not one of it's hacked up variants.

            What is wrong with what? The fact that the original 4 clause license won't let you take my code and GPL it?

            There are only two BSDL (UCB defines the BSD license). The original 4 clause license (includes advertising notice) and the more recent 3 clause license that deletes the advertising notice requirement.

            Of course, unlike the commercial people, I'm nice and wouldn't sell my newly GPLed BSD-based software.

            I don't care if you sell my code or not. And BTW, I can take your GPL'ed code and sell it just fine as long as I include the source to any binaries... I can charge $1,000 for GCC if I want.

            But I don't have to be that nice -- I could be like MS and rip off the hard efforts of the BSD team!

            Unless someone is stupid, it's not the hard to just rip off ANY code that has source available and just file off the serial numbers (ie change function names, rewrite comments, etc, etc,). The bulk of the code is the same, just the identifing marks have been removed. Unless your code is VERY hard to come by, you'll never know it.

            And if people are stupid enough to not to protect themselves against commercial entities taking their code with recompense then they deserve what they get. As a businessman, I don't feel bad at all for someone who forces their own raw deal on themselves.

            Huh??? I'm not worried about commericial entities taking my code (if I was I would not be using the BSDL). What I don't like is some jerk forking my code just to put it under the GPL instead of contribing back to the original project. If your not willing to use the original license then don't use my code... simple.

            Kudos to you for using a different than standard BSD license. Just like BSD model itself, even the licensing is a fractured mess

            Different than standard? I just happen to use the original 4 clause instead of the 3 clause BSDL. They are both standard. And again, fractured? There are only two of them...

            BWP
            • >What is wrong with what? The fact that the original 4 clause license won't let you take my code and GPL it?

              Nothing wrong with it. I'm just having difficulty wrapping my mind around the idea that a developer would have no problems with a commercial entity copying your code verbatim and selling it as their own (code used by Microsoft was covered by the extra clause, however they still say it is theirs, they simply make sure that embedded deep withing the executable there is a cryptic copyright message that doesn't even include the term "BSD") but would not want another group to use the software for free, distribute it for free, and make sure all patches are free (and available to the developer), and keep the developer's name on it anyways. But that might just be GPL tunnel-vision again. If you'd care to explain to me what I'm missing, I'd be happy to hear it! :-)

              >I don't care if you sell my code or not. And BTW, I can take your GPL'ed code and sell it just fine as long as I include the source to any binaries... I can charge $1,000 for GCC if I want.

              Yep. But only once (Assuming it's the first copy of something. Otherwise I'd say not at all, in general. That is, unless it's DRM protected, which is a problem RMS missed when writing the GPL the first time). Anybody buying a GPL program twice either hasn't read their license (ie: Is stupid) or is buying whatever comes with it instead (like a TiVo, for example).

              Whereas, with the BSD license, I can sell the software to someone for $1,000 as much as they'll keep buying it, since I can add clauses that prevent them from making copies of the software. That is, unless there's something I've been missing in the BSD license all this time...

              >Unless someone is stupid, it's not the hard to just rip off ANY code that has source available and just file off the serial numbers (ie change function names, rewrite comments, etc, etc,). The bulk of the code is the same, just the identifing marks have been removed. Unless your code is VERY hard to come by, you'll never know it.

              I don't think provenance of code isn't as difficult to spot as you'd suggest, but since I'm not a hardcore coder, I have no hard proof. But there's been more than enough examples of stolen GPL code posted to slashdot to convince me that it can't be all that difficult. The "look and feel" of a program is a dead giveaway to be suspicious of it to start with (that's how I found out about the BSD code in MS Windows to start with -- the look and feel of ftp was just not very "Microsoft", so I did some research).

              >Huh??? I'm not worried about commericial entities taking my code (if I was I would not be using the BSDL). What I don't like is some jerk forking my code just to put it under the GPL instead of contribing back to the original project. If your not willing to use the original license then don't use my code... simple.

              Doesn't that last sentence preclude commercial entities from using your code -- that is, assuming the commercial entities decide to use your code in a proprietary fashion? Would they not be using a different license?

              If you'd just explain why you have a problem with your software being relicensed as GPL, but no problem with it being relicensed under, for example, the Microsoft Windows license, I'd understand more. As it stands right now, I'm not seeing the distinction.

              >Different than standard? I just happen to use the original 4 clause instead of the 3 clause BSDL. They are both standard. And again, fractured? There are only two of them...

              I'm referring to the fact that BSD programs have been relicensed under so many different terms, that while they are still BSD programs, the licensing model itself condones a fractured set of licensing terms. ie: An infinite set.

              If that's not a problem for the developer, well, then that that's A-OK, I guess. I just don't understand why. Sorry.
    • 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
      • 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.

  • Intel patches? (Score:5, Funny)

    by Anonymous Coward on Sunday February 16, 2003 @01:28PM (#5314696)
    More like...

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

  • Superior Power Management... (Score:3, Insightful)

    by $$$$$exyGal ( 638164 ) on Sunday February 16, 2003 @01:33PM (#5314723) Homepage Journal
    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 [slashdot.org]

    • Re:Superior Power Management... (Score:4, Insightful)

      by 6 ( 22657 ) on Sunday February 16, 2003 @04:10PM (#5315432)

      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.


      • The entire point of the GPL was that it does matter how a goal was achieved.

        So far, I'm with you.

        This is just one more step down the path of reducing Linux to just another corporate OS.

        No, you lose me here.

        GPL is a great license and I'm glad the Linux kernel is under it. But it is not the only acceptable license in the world. Even RMS agrees that there are times when it is okay to license things under another license. This is one of those times.

        It is impossible to take GPL code and just suddenly say "I'm putting this under a new license now." Thus it is impossible to take the GPL out of Linux. Your statement that Linux will be reduced to "just another corporate OS" is only flamebait.

        steveha
      • This is just one more step down the path of reducing Linux to just another corporate OS.

        I'm getting sick of hearing this. Look, the BSDs have been using the BSD license for YEARS now. Despite rms' fear-mongering and fud, no-one can come and take away the software you've released.

        Telling someone "this is what you will do with this software" is a sure way to get them to not use your software at all. Just look at all the standard formats used on the internet... Every single one had a non-restrictive license. Meanwhile all the GPL programmers are spitting in the wind by using the GPL, and wondering why their programs aren't taking over the world.

  • Sensible for Intel (Score:5, Insightful)

    by Fluffy the Cat ( 29157 ) on Sunday February 16, 2003 @01:39PM (#5314745) Homepage
    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.

    • Intel want ACPI to be adopted by as many OSes as possible, and they want it to work.

      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?

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

      Surely this is a situation where LGPL is the most appropriate. By using the BSD license, Intel is saying that it's OK for vendors to fork their own versions of the ACPI code, and not contribute the changes back to the rest of the world. That road can only lead to incompatiblity between ACPI implementations. IMHO, it's a poor decision...

  • 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.
    • Umnh...
      The patch is available under the GPL. This means that the source is available under the GPL. If this source is included in the kernel, then the whole thing is still under GPL, and is still available as source under the GPL. You can also get various pieces of it under other licenses from various people who have contributed them. In fact, if you were willing to pay enough to enough people (probably impossible*, but if), then you could license the entire kernel under a proprietary license of your own design. And this wouldn't keep the same kernel from remaining under the GPL.

      * Some of the authors of the code have probably died, so you would need to agree with their heirs also.
  • 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.

    • Re:How does redhat even have the authority to do t (Score:5, Informative)

      by mattdm ( 1931 ) on Sunday February 16, 2003 @02:03PM (#5314851) Homepage
      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 (Score:4, Insightful)

      by Anonymous Coward on Sunday February 16, 2003 @02:09PM (#5314878)
      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.
    • 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.
      • 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.
        • 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.

          • Re:How does redhat even have the authority to do t (Score:1, Insightful)

            by Anonymous Coward

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

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

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

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

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

  • Two of the messages from the thread (Score:5, Interesting)

    by Vlad_the_Inhaler ( 32958 ) on Sunday February 16, 2003 @02:28PM (#5314954)
    (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: (Score:5, Informative)

    by Anonymous Coward on Sunday February 16, 2003 @02:34PM (#5314977)
    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
    -

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

    • Re:Quite a lot of fuss; not too important... (Score:2, Insightful)

      by Anonymous Coward
      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.

  • Legal issues for nerds (Score:5, Funny)

    by hey ( 83763 ) on Sunday February 16, 2003 @02:54PM (#5315094) Journal
    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

  • Not exactly... (Score:5, Insightful)

    by inode_buddha ( 576844 ) on Sunday February 16, 2003 @09:03PM (#5316526) Journal
    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...
  • 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.

  • ACPI driver license (Score:2, Insightful)

    by stock ( 129999 )
    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.

Slashdot Top Deals

Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

Close