Weekly Edition
Return to the Front page
| |||||||||||||
Much ado over licenses
Selling a new license to the kernel developers was always going to be an
uphill battle. They are a large and strong-minded crowd, occasionally
suspicious of the Free Software Foundation and its attitude toward Linux,
and happy with the licensing that they have now. Given the immense
practical difficulties involved in changing licenses, there would have to
be a strong incentive to get the developers to even try.
The odds of a license change fell even further earlier this year, when Linus Torvalds made his opposition to the anti-DRM provisions of the GPLv3 draft known. For some time, it appeared that Linus was alone in that position, however; few other developers had made public statements on the license. Even Linus wondered about it:
The reason the poll and the whitepaper got started was that I've
obviously not been all that happy with the GPLv3, and while I was
pretty sure I was not alone in that opinion, I also realize that
_everybody_ thinks that they are right, and that they are supported
by all other right-thinking people. That's just how people work. We
all think we're better than average.
So while I personally thought it was pretty clear that the GPLv2 was the better license for the kernel, I didn't want to just depend on my own personal opinion, but I wanted to feel that I had actually made my best to ask people. So he put together a quick discussion list involving the top 30 or so kernel developers (see the message quoted above for the the exact selection criteria) and held an informal poll. The results were as clear as it gets: none of the developers polled was positive about the license, and most were strongly negative. Among this crowd of most active kernel developers, nobody is prepared to say that moving to GPLv3 would be a good thing for the kernel project to do. A subset of these developers put their names onto a separate position statement. Some of the positions taken in that statement are quite strong (see Rusty Russell's take), to the point that not all were willing to support it. It also appears that, while the anti-DRM provisions are almost unanimously opposed, a number of developers are sympathetic to the patent-related terms in GPLv3. The anti-DRM clauses are, indeed, at the heart of the problem. The GPLv3 draft requires that, if somebody ships you a device which runs GPLv3-licensed code, they must also provide you with everything required to rebuild and reinstall that code - including encryption keys if the hardware requires them. Those who support this language see it as a fundamental guarantee of the freedom that comes with free software - the freedom to replace that software if need be. In particular, these people want to be able to replace software which implements unpleasant DRM schemes or other user-hostile behavior. In the discussions that have followed, it is hard to find kernel developers who support locking up content and abridging fair-use rights with DRM schemes - though some do see situations where locking down a system's software makes sense. But they see the language in the GPLv3 draft as restricting the possible uses of their software, and they don't like it. The cure seems worse than the disease. The core question behind this whole debate, perhaps, is this: what, exactly, do we want to accomplish with our licenses? Just as there is disagreement over what kinds of problems can be solved by passing laws, there is no consensus on which problems can be addressed with license terms. One can argue that oppressive DRM is a societal or legal problem, and that it should be addressed at those levels through a reaffirmation of what fair-use rights should really be rather than by adopting a license which tries to keep specific software from being used to implement DRM. A license can be a hefty hammer, but not every problem is a nail. Regardless of the reasoning, the fact is that the GPLv3 draft is currently in a difficult spot. There appears to be no way it will be adopted for the kernel in its current form; there has also been quite a bit of speculation that a number of other important projects will either resist the new license or, possibly, fork into GPLv2 and GPLv3 versions. GPL-licensed libraries are of particular concern. The prospect of having to carry around two versions of the C library - one for each version of the GPL - is not particularly appealing. This is the scenario that some of the kernel developers warn about in their position statement; anybody who dismisses it should have a good reason for believing that it will not come about. There are a lot of good things in the GPLv3 draft. The updating of the language for worldwide applicability is something we will almost certainly want, sooner or later. The software patent provisions have the potential to deter patent attacks against free software users - an important protection in the absence of a real fix for the patent problem. The "this code is not a technical protection measure" clause may offer similar protection from some attacks based on DMCA-like laws. All of this, and more, is worth having - but only if the new license can find acceptance from those who have so wholeheartedly adopted GPLv2. The Free Software Foundation is going to have to make a difficult decision over the next few months: it can keep the controversial terms and risk the consequences, or increase the chances of a successful GPLv3 by dropping terms that, in its opinion, are of fundamental importance. [Other things to see: the FSF's response to the position statement and Linus Torvalds's Ode to GPLv2. There is also the announcement of the first discussion draft of the GNU Free Documentation License, version 2, which almost appears to have gotten lost in the noise.] (Log in to post comments)
Open Souce != Free software Posted Sep 28, 2006 2:36 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] let alone GPLv2 programmers and the FSF.
here's a post I recently ran across from 2001 that talks about this exact difference (and predicting firestorms like we are having now)
two versions of the C library?? Posted Sep 28, 2006 2:55 UTC (Thu) by stevenj (guest, #421) [Link] The prospect of having to carry around two versions of the C library - one for each version of the GPL - is not particularly appealing. Considering that the GNU C library is LGPLed, and does not restrict the licenses of code linked to it, and never has, it is hard to see where you are coming from here. It would be easier to take the kernel developers' criticisms seriously if they weren't so reliant on misunderstandings and distortions, such as:
As for the DRM clause, the FSF and other authors who choose to use GPL v3 simply don't want to subsidize DRM'ed software foisted on users. Yes, some DRM will happen anyway, but why should I subsidize it with my code? If the kernel developers want to subsidize DRM development with their code, it's their choice; no one is holding a gun to their head to use v3.
two versions of the C library?? Posted Sep 28, 2006 3:22 UTC (Thu) by atai (subscriber, #10977) [Link] There may be something else going on here; lwn.net's report may not be based on pure air.
Something political going on; the whole issue may not really be the merits of GPL v3 but something else.
It would be great if lwn.net can provide more information regarding the C library.
two versions of the C library?? Posted Sep 28, 2006 5:55 UTC (Thu) by AJWM (guest, #15888) [Link] >It would be easier to take the kernel developers' criticis[ers] seriously if they weren't so reliant on misunderstandings and distortions,
For example, accusing them of claiming that:
> # The patent clauses will force companies to give up their "entire patent portfolios" (rather than merely making explicit what was implicit in v2).
They made no such assertion. The assertion was that _contributing companies' lawyers_ might interpret that explicit language in that way. (Or, more likely, that the lawyers of some company in a patent dispute with a contributing company might argue it that way .. think SCO as an example here.)
And the following is taken in a very mean-spirited interpretation:
> # The FSF will "force" people to switch to v3. (Unless by "force" you mean provide code under v3 that people want to use. Quid pro quo, baby.)
How long after v3 is settled will FSF make software available under v2? Yes, the code they used to make available may still be around somewhere, but harder to find (see below). That's exactly what they mean by "force".
RTF Position Statement; libc is mentioned exactly once, in Section 4, in a short list of examples of projects controlled by FSF. The section as a whole is simply acknowledging the pivotal role of FSF. You are paraphrasing badly to the point of mischaracterization.
Of course it is inevitable that some projects will choose to remain v2 (linux being a prime example) while others (in particular those controlled by FSF) go v3. If there is a large community of users of a project that goes v3 who would rather it remain v2, they _will_ fork it. Forks routinely happen over licensing issues (eg XFree86).
The kernel developers recognize that this weakens the community as a whole, and is something to be avoided. They are _warning_, not threatening, that there may be a sufficient community of developers that dislike v3 (as currently drafted) that this is a real danger. The inevitable result is that one fork or another will wither away, with much waste of time and energy in duplicate development in the meantime.
Since v3 is perceived as a less-free (at least by developers -- who are the ones contributing the code) license than v2, that is the one more likely to fade. The proponents of v3 need to change that perception -- and not by argument, but by changing the wording of the license, either to clarify it if the perception of restrictions is wrong, or to change the meaning if that perception is correct.
two versions of the C library?? Posted Sep 28, 2006 9:37 UTC (Thu) by khim (subscriber, #9252) [Link] How long after v3 is settled will FSF make software available under v2? For many-many years. GPLv1 licensed gcc 1.42 is still downloadable from FSF's site. More then 10 years after switch to GPLv2. Yes, the code they used to make available may still be around somewhere, but harder to find (see below). Have you checked facts before starting the discussion ? FSF is distributing GPLv1 licensed code today. Why do you think they'll remove GPLv2 licensed code after GPLv3 licensed version will become available ? It'll be pointless anyway: copies of said code are on millions of computers worldwide! The best backup policy you can ever imagine... Since v3 is perceived as a less-free (at least by developers -- who are the ones contributing the code) license than v2, that is the one more likely to fade. BSD license was percieved and still is percieved as "more free" license then GPL- most developers agree on that. Yet formelly thriving community of *BSD is in very bad shape now while GPL-licensed Linux is big today. What will happen in DRM-infested future ? Who knows. But I'm pretty sure switch will be step-by-step: as more and more people will be bitten by DRM more and more developers will switch to GPLv3... Of course if most players in IT industry will stop playing DRM games (hard to imagine really) then GPLv2 "wins" - and it, too, will be good result... In short: we need GPLv3 licensed system as safety net if nothing else. And if this GPLv3 licensed system will not include Linux kernel - well, it's Ok. If DRM proliferation will not happen - we'll use Linux, if it will happen - we'll use HURD (if DRM will bite people hard enough then number of HURD developers (GPLv3 licensed HURD!) will increase 10 times or more and usefull release will be achieved in short order). I honestly don't see why people can not just agree to disagree. GPLv2 license is 100% sure short-term gain, but it can be disaster in the long run. GPLv3 license is sure long-term win, but can hamper thing in short term (and can even kill smaller projects!). Both statements are obviously true. Kernel developers value short-term gain higher then long term win - it's their right and I can see why they chose this approach. FSF value long-term gain much higher - and it's easy to see why. Why do we need to fight ? Time will tell. We already had such choice 10 years back - between BSD and GPLv2 license. GPLv2 license "won". Will it happen this time ? Who knows... But to claim that GPLv3 does not have a chance in hell... it's just ridiculous...
two versions of the C library?? Posted Sep 28, 2006 17:30 UTC (Thu) by smoogen (subscriber, #97) [Link] I think the term of distribution is overloaded. There is allowing for something to be downloaded which says that GPLv1 code is still downloadable.
Then there is the term of distribution that gets used about a product where people assume it is still supported. This is the part that most people are wondering about. When GPLv3 comes out, when will bugfixes in (GPLv2 and up) code stop and only be applied to (GPLv3 and up).
Anti-DRM provisions as safety net? Posted Sep 28, 2006 17:38 UTC (Thu) by vonbrand (subscriber, #4458) [Link] In short: we need GPLv3 licensed system as safety net if nothing else. And if this GPLv3 licensed system will not include Linux kernel - well, it's Ok. If DRM proliferation will not happen - we'll use Linux, if it will happen - we'll use HURD (if DRM will bite people hard enough then number of HURD developers (GPLv3 licensed HURD!) will increase 10 times or more and usefull release will be achieved in short order). I honestly don't see why people can not just agree to disagree. I just don't see how "anti-DRM provisions" in the license can provide a safety net against DRM. DRM proponents will just use something else, there are plenty of alternatives, and if push comes to shove they certainly can build their own closed stuff. If they do, and your future PC isn't able to run anything but DRMed Windows, GPLv3 HURD (or Linux for that matter) will be irrelevant anyway. In practical terms, keeping Linux (and open source in general) alive and well is much more important: It will make people who might be tempted to DRM out of pesky competition think twice before loosing this valuable asset. Not as code base, mind you, as a thriving development ecosystem. And that means keeping the people footing the bill (yes, those big, bad corporations that mostly do closed source) reasonably happy too. Not enough people remember the pre-Linux aera: Sure, open source stuff was around, but nobody used it (sure, at the University is was cool to run tcsh and emacs and gcc, and have BSD instead of AT&T Unix, and futz around with code from comp.sources.*, but the "real world" just didn't notice). Changing the GPL to whatever other license wouldn't have made any difference. The whole GNU stuff was completely irrelevant, it became a force to be reconed with because Linux (the kernel) took off the way it did.
Anti-DRM provisions as safety net? Posted Sep 29, 2006 6:58 UTC (Fri) by khim (subscriber, #9252) [Link] Manufacturers are not stupid and today it's easy to create the hardware which can run BOTH Treacherous computing software and non-DRM-encumbered software. Take a look on Playstation 2 or Cell. If there will be demand - there will be offer. GPLv3 will create such demand. Will it be enough ? Time will tell. But without GPLv3 software there soon will be no support for unsigned binaries and kernels everywhere. And that will be the end of story.
two versions of the C library?? Posted Sep 28, 2006 14:55 UTC (Thu) by stevenj (guest, #421) [Link] They made no such assertion [that companies would have to give up their entire patent portfolios]. The assertion was that _contributing companies' lawyers_ might interpret that explicit language in that way. The kernel developers wrote: As drafted, this currently looks like it would potentially jeopardise the entire patent portfolio of a company simply by the act of placing a GPLv3 licensed programme on their website. This statement does not merely say that other lawyers might spread such FUD, it actually agrees with it. libc is mentioned exactly once, in Section 4, in a short list of examples of projects controlled by FSF. The section as a whole is simply acknowledging the pivotal role of FSF. The mistaken idea that changing libc or not changing Linux to v3 will force everyone to fork has come up numerous times in the discussion surrounding the position paper, including in the LWN article. Mea culpa for grouping it with the distortions in the kernel position paper itself, though.
two versions of the C library?? Posted Sep 28, 2006 17:23 UTC (Thu) by JoeF (subscriber, #4486) [Link] I don't see how you can come from this currently looks like it would potentially to it actually agrees with it.It seems to me that you are the one who is spreading FUD here, in particular since you are omitting the next sentence in the kernel developers' statement: Since the Linux software ecosystem relies on these type of contributions from companies who have lawyers who will take the broadest possible interpretation when assessing liability, we find this clause unacceptable because of the chilling effect it will have on the necessary corporate input to our innovation stream.
two versions of the C library?? Posted Sep 28, 2006 19:24 UTC (Thu) by stevenj (guest, #421) [Link] If I state publicly that "it currently looks like you are a murderer," unless I immediately follow it with "but in reality, I don't believe you are", then I am participating in the accusation.It does not help matters if I follow that statement with "And many prosecutors, who take the broadest possible interpretation of the law in assessing guilt, will find you to be unacceptable as a free man."
two versions of the C library?? Posted Sep 28, 2006 20:05 UTC (Thu) by JoeF (subscriber, #4486) [Link] May I suggest you come up with a better analogy? Comparing license issues, which would be a civil matter, with criminal acts is just plain silly and invalidates your whole point.
two versions of the C library?? Posted Sep 28, 2006 20:11 UTC (Thu) by stevenj (guest, #421) [Link] We're not talking about law, we're talking about language. Besides, see below.
two versions of the C library?? Posted Sep 28, 2006 20:58 UTC (Thu) by JoeF (subscriber, #4486) [Link] Even just considering language, you analogy is wrong, and quite frankly, insulting. You are comparing disagreement over a license with murderers. That's less than civil.
two versions of the C library?? Posted Sep 28, 2006 19:38 UTC (Thu) by alexbk (subscriber, #37839) [Link] These lawyers are in committee B and to my knowledge they are working hard to produce the best patent section in the license. Why are the kernel developers trying to do someone else's job?
two versions of the C library?? Posted Sep 28, 2006 19:40 UTC (Thu) by alexbk (subscriber, #37839) [Link] The second link should've beenhttp://gplv3.fsf.org/search?SearchableText=committee+b+pa...
two versions of the C library?? Posted Sep 28, 2006 19:39 UTC (Thu) by stevenj (guest, #421) [Link] Besides how can you argue with a straight face that the kernel developers disagree with concerns that the patent clause is overbroad? If they agree that companies' fears about this clause are based on a misunderstanding of the GPLv3 and have no legal validity, then the correct course of action is to simply educate the companies. (In exactly the same way that companies needed to be educated that using or contributing to the Linux kernel does not force them to open-source up their entire software portfolio.)Face it, the position paper in a plain reading spreads the idea (FUD) that there are valid legal concerns that GPLv3 will force companies to give up their "entire patent portfolio". You have to twist their words to conclude otherwise.
two versions of the C library?? Posted Sep 28, 2006 21:16 UTC (Thu) by JoeF (subscriber, #4486) [Link] Face it, the position paper in a plain reading spreads the idea (FUD) that there are valid legal concerns that GPLv3 will force companies to give up their "entire patent portfolio".And why would that be FUD? Are you in a position, i.e., are you a lawyer, to determine that these concerns are not valid? If not, it is you who is spreading the FUD. If yes, please post (a) your credentials, and (b) your legal opinion.
two versions of the C library?? Posted Sep 28, 2006 22:50 UTC (Thu) by alexbk (subscriber, #37839) [Link] That would be FUD because the kernel developers have no qualification in law and, by their ownadmission, have not contacted a single lawyer prior to writing the claim and because they don't even try to justify it in any rational, factual way at all. There's no need to be a lawyer to see that.
two versions of the C library?? Posted Sep 28, 2006 23:09 UTC (Thu) by JoeF (subscriber, #4486) [Link] That would be FUD because the kernel developers have no qualification in law and, by their own admission, have not contacted a single lawyer prior to writing the claim and because they don't even try to justify it in any rational, factual way at all.I would suggest separating facts from your opinion. The kernel developers may not have contacted a lawyer, but that of course doesn't mean that another non-lawyer can claim that their position is not valid. That's just some random opinion, which is a dime a dozen. And as far as your opinion about the kernel developers justifying things is concerned, you have your opinion, I have mine, which happens to differ from yours. Neither one matters much.
two versions of the C library?? Posted Sep 28, 2006 23:51 UTC (Thu) by alexbk (subscriber, #37839) [Link] What a twisted argument.
Anyway, their position cannot be shown to be either valid or invalid. Ergo, it's FUD by definition :)
two versions of the C library?? Posted Sep 29, 2006 0:32 UTC (Fri) by JoeF (subscriber, #4486) [Link] What a twisted argument.Care to explain what is "twisted"?
Anyway, their position cannot be shown to be either valid or invalid. Ergo, it's FUD by definition :)
two versions of the C library?? Posted Sep 29, 2006 9:11 UTC (Fri) by alexbk (subscriber, #37839) [Link] Note that I didn't state what my position regarding patent provisions is, I just pointed out why Ithink the kernel developers statement lacks merit. If you disagree, say *why*.
DRM turns GPLv2 into the patched BSD license Posted Sep 28, 2006 3:32 UTC (Thu) by jmorris42 (subscriber, #2203) [Link] For all practical intents and purposes, once DRM hardware enters the marketplace in force, GPLv2 will be indistinguisable from the BSD license. This is something the kernel developers need to understand and deal with. And if they really don't care what use people make of their code, if they really don't care if people ship locked hardware where the end user can't do anything to replace the 'GPL' code embedded within, then perhaps they should think about moving to the BSD license and have done with it.
DRM turns GPLv2 into the patched BSD license Posted Sep 28, 2006 4:46 UTC (Thu) by shemminger (subscriber, #5739) [Link] Wrong there is a big difference. Nobody in the BSD world has to ever give back anything. If I make a product with BSD, you don't have to see my changes and you can't build a competing product with those changes.
With GPLv2, I may be able to build something you can't modify. But you can ask for my code and build your own from scratch without the code signing, if you have the resources.
DRM turns GPLv2 into the patched BSD license Posted Sep 28, 2006 9:46 UTC (Thu) by khim (subscriber, #9252) [Link] ...and since only big corporations "have the resources" GPLv2 is undistingushable from BSD cone. Sure - you can take the code and even play in very limited "sandbox" but that code will be unable to ever touch the real world data (which will be 100% controlled by DRM-infested hardware). What good code does if you have no hardware to use it for ? This is exactly difference between long-term approach and short-term approach. Linux kernel guys say: "it's no big deal since today you can easily buy non-DRM'ed hardware to run our code". FSF says: "if we will not fight the DRM today then tomorrow we will have no hardware to run our stuff with". I've seen no answer for this except "this future can never happen" - without explaining why it will never happen if noone will fight to stop it.
DRM turns GPLv2 into the patched BSD license Posted Sep 28, 2006 15:30 UTC (Thu) by sepreece (subscriber, #19270) [Link] The problem with this argument is that the restriction in GPLv3 is NOT "fighting DRM". The most it can do is keep developers from feeling unhappy that their code is used in locked-down systems. It does nothing to prevent or slow the spread of DRM of content or locking down of trusted code.
Those are not technical issues or software licensing issues. If it makes you feel better to say "Well, you can't use my code that way", that's fine, but don't kid yourself that it's a blow for freedom.
As long as content owners insist on DRM and consumers insist on getting the content, there will be DRMed systems. As long as service providers insist on trusted clients and users insist on getting the services, there will be locked-down systems. You can't fight this in a software license.
However, trying to fight it in the license MAY fragment the community and recuce the impact of free software overall.
DRM turns GPLv2 into the patched BSD license Posted Sep 28, 2006 15:38 UTC (Thu) by alexbk (subscriber, #37839) [Link] The exclusion of GPL code from DRM/trusted systems increases the development costs, since you'd have to write your own code or pay someone to do that instead of just using the GPLd code pool for free. Is that nothing?
DRM turns GPLv2 into the patched BSD license Posted Sep 29, 2006 0:58 UTC (Fri) by sepreece (subscriber, #19270) [Link] It's basically nothing. The cost factor is actually less important, to manufacturers, than the access to Linux-based technologies and developers. Yes, they get rid of the per-unit royalty for some proprietary RTOS, but in return they pick up higher support costs for doing things that the RTOS vendor would have taken care of. It's still a loss, but a slight one. Remember, most of the manufacturers were using something else before, anyway.
However, that's really not the point. You're beating on the wrong horse. The manufacturers don't do DRM or locked-down software because they want to, they do it because it's a requirement for the particular market. No DRM, no content. No trusted software, no access to the network. You can, perhaps, make it slightly more expensive to build devices for the market, but if the market is there, they'll do what they need to do.
DRM turns GPLv2 into the patched BSD license Posted Sep 29, 2006 6:51 UTC (Fri) by khim (subscriber, #9252) [Link] You can, perhaps, make it slightly more expensive to build devices for the market, but if the market is there, they'll do what they need to do. Yup. And if there are no demant there will be no offer. You are talking like DRM-locked hardware and DRM-free hardware are the only only possibilities. It's not. Take a look on the PlayStation 2. Take a look on Cell. Today it's not so hard for the manufacturer to make a device where you can run both DRMed content and non DRMed content securely at the same time. If there will be usefull GPLv3 software in the wild - it'll be the norm. If there will be no pressure to support un-DRM-encumbered software at all - there will be no such thing. As easy as that. I do not believe GPLv3 is enough to stop DRM. I do believe GPLv3 is enough to force manufacturers to stop using it everywhere.
DRM turns GPLv2 into the patched BSD license Posted Oct 3, 2006 5:22 UTC (Tue) by svkelley (guest, #37299) [Link] You are still going to kill commercial embedded linux development with v3. Companies are not going roll over and offer up unsigned loaders to their devices. Liability alone would be reason enough. All this means is that GPLv3 creates a future where devices don't run Linux. Instead they run WinCE, Qnx, etc.
Sean
Much ado over licenses Posted Sep 28, 2006 4:32 UTC (Thu) by uwaucs (guest, #6160) [Link] See also Luis Villa's articles What the kernel guys are and arent (and really should be) saying about GPL v3, What the kernel guys got wrong and What the FSF got wrong.
Much ado over licenses Posted Sep 29, 2006 8:49 UTC (Fri) by tajyrink (subscriber, #2750) [Link] These should be mandatory reading for everyone participating in the discussion, including Linus and Richard.
Kernel Developers' Manifesto was Political Posted Sep 28, 2006 4:57 UTC (Thu) by Felix.Braun (subscriber, #3032) [Link] Among this crowd of most active kernel developers, nobody is prepared to say that moving to GPLv3 would be a good thing for the kernel project to do. Given the fact that there are so many contributors to the Linux kernel, changing the license for the kernel really never was a feasable option anyway. Linux would remain GPLv2 even if Linus was a rabid fan of the GPLv3 eager to switch over, simply because it is impossible to trace down every contributor and make him consent to a license change. Therefore the kernel developers' Manifesto wasn't them deliberating what license to chose for their project, but a contribution to a political debate in the Free Software / Open Source community. Telling other people what effect it would have (in the kernel developpers' opinion) if they chose to publish a big body of code under the proposed GPLv3 license. Of course, as contributors to an important open source project of great symbolic value, their opinions should not be undervalued. If one thing their opposition to the current draft shows that in it's current form the GPLv3 might not be adopted as widely as its predecessor.
Is migration feasable? Posted Sep 28, 2006 18:29 UTC (Thu) by coriordan (guest, #7544) [Link] Relicensing the current kernel release would probably be impossible, but migrating to a new licence for some future version is possible. Linux has a high rate of code turnover, and most developers are contactable. If the Linux hackers converted the code they can convert, and put in place a policy which applies to future contributions, they would find themselves in a position to relicense the whole kernel after a few years (a few years of just waiting, not a few years of work).
So it is possible. Should it be done? Yes - even if they don't like GPLv3.
What would they do if a court (in whatever country) tomorrow ruled that the GPLv2 was invalid or that it could be interpretted in farcical ways? What if that ruling was repeated in multiple countries?
Licence maintenance is something that free software projects have to think about.
Much ado over licenses Posted Sep 28, 2006 5:47 UTC (Thu) by drag (subscriber, #31333) [Link] Hrm.
I think it may be prudent for the FSF now to drop the DRM mandate or make it optional.
Optional maybe something like the 'v2 or later' clause. Something were the actual code has to remain replacable on DRM'd machine, but it doesn't extend to other code linking to it. Sort of like the Lesser GPL, but just with the DRM clause.
Maybe that will make it much less obnoxious. But if that won't work out then just get rid of it alltogether.
I think it's much much more important to increase compatability with other licenses and especially take on the patent issue. It's likely that getting rid of the DRM portion will make the patent language easier to sell, especially when people get convinced that this same exact logic is already implied in the GPLv2 under U.S. law (I beleive).
Much ado over licenses Posted Sep 28, 2006 7:16 UTC (Thu) by khim (subscriber, #9252) [Link] I do not think you understand. DRM clause is not up to negotiations. Wording of it - sure. But the thing itself ? It's biggest fix introduced in GPLv3! The problem: when Linus (and others) say GPLv2 is great because it's based on "tit fo tat" principle they are wrong. Very wrong. GPL was never about "tit for tat". Google, HP, IBM and other companies are using tons of stuff in their kernel - and they only give these changes back when it's convinient for them. How is this "tit for tat" ? It's not. GPL is all about the freedom of the end user. It's designed to make it possible to hack on the stuff you own. If you have binaries - you must have corresponding source to be able to play with binaries! Nothing more, nothing less. Google can play with GPLed code freely as long as it's not distributing it. But if I sell you the binary - I must give you means to change this binary (that's why it includes "scripts used to control compilation and installation of the executable" - see cdrecord vs cdrkit fiasco). This was the goal from the start - please read the GPLv2 and Manifest before you'll start thinking differently. Today patents and DRM make this promise hollow - and DRM more then patents right now (see TiVo). How can you salvage it without including any DRM clause ? Remember: "tit for tat" is secondary (GPLv2 does not enforce it at all and neither will GPLv3). Ability to change binary you own is paramount... That's fundamental disagreement between linux kernel guys and FSF - and looks like they have no common ground there at all...
Much ado over licenses Posted Sep 28, 2006 8:19 UTC (Thu) by NAR (subscriber, #1313) [Link] That's fundamental disagreement between linux kernel guys and FSF - and looks like they have no common ground there at all...Yes, I wanted to make a similar comment. I guess the kernel developers' position is that "use the code and if you improve it, give the improvements back to us". This is a developer's view, not a user's view, and it has nothing to do with the user's rights - which is perfectly reasonable for a non-politican developer. It doesn't really matter how the code is used (in a nuclear bomb, in a DRM'd device, by a pedofile searching for kids, by a terrorist organising attacks, etc.) as long as the improvements get back to the code base.
Much ado over licenses Posted Sep 28, 2006 9:02 UTC (Thu) by khim (subscriber, #9252) [Link] But GPL never had such provision! As long as your "nuclear bomb" is not distributed changes can be kept private and when it's distributed recepient will be unable to use any freedom at all!
Much ado over licenses Posted Sep 28, 2006 10:13 UTC (Thu) by NAR (subscriber, #1313) [Link] You're right, but I guess most modified GPLv2 software gets distributed, so the majority of the improvements eventually get back to the author. If a software is used only in-house, the improvements are most likely to be not useful out of that in-house environment, so it's not a loss to the original authors. So even though GPLv2 is theoretically not a 'tit-for-tat' licence, practically it is. And I think this is what the kernel developers care about.
Much ado over licenses Posted Sep 28, 2006 14:08 UTC (Thu) by khim (subscriber, #9252) [Link] Yup. But since this "tit for tat" was not by design it's kind of hard to argue (like linux kernel developers are doing) that it's "violation of trust", "not in spirit to the present version" and such. GPL was always about the ability of tweak the software freely, not about the "tit for tat". If you don't believe me - read the license (v2, of course) again. Slowly.
Much ado over licenses Posted Sep 28, 2006 16:43 UTC (Thu) by NAR (subscriber, #1313) [Link] Yes, the license is about the freedom of the user - however, I guess that the relative success of Linux compared to the e.g. *BSDs is caused by the "tit for tat" side effect, not by the freedom of the users. After all, the *BSDs give even more freedom, the freedom of not contributing back.
Much ado over licenses Posted Sep 29, 2006 7:01 UTC (Fri) by khim (subscriber, #9252) [Link] May be. But that's no reason to claim that FSF "abused trust" and created GPLv3 which is not "similar in spirit to GPLv2"...
GPL and Nuclear Bombs Posted Sep 28, 2006 20:04 UTC (Thu) by GreyWizard (guest, #1026) [Link] Keeping nuclear bombs private and not distributing them seems like good policy in general. ;-)
Much ado over licenses Posted Sep 28, 2006 8:42 UTC (Thu) by gravious (subscriber, #7662) [Link] I, the sole or collective author/owner, of a chunk of code get to decide how it can be used by licensing it. Linus - though he may feel the GPLv2 focuses on tit-for-tat, it sure doesn't except for proximately as we would say with our philosopher's hat on. We get tit-for-tat because we force a distributor of a binary version of our code to yield up the source. If they were distributing it in source form already then we've already achieved our goal. If you can't or don't give me the source then you can't distribute binaries.
So
S -> B -> S
okay
But, under GPLv2, we have
S -> B+DRM+DCMA+PATENT -> S?
With GPLv3 we will have
S -> ALPHBET-SOUP -> S
Remember, a compiler is just a bunch of stuff that happens to code. It just happensss to be technical stuff. RMS wants to have access to the code if he has access to it in any shape or form. Of course now that the FSF does more than just produce compilers. The GPLv3 is more political because the barriers for source retrieval have moved from the purely technical world of assemblers and compilers to the legal world. I personally believe DRM to be ethically neutral (like money - a lot of people believe money to either intrinsically evil in itself or the 'root of all evil' - money is no more evil than a hammer, they both can be used by humans (that is, moral actors) for good or evil, they are both artifacts.) Software isn't run in a vacuum. If I buy a piece of hardware it really annoys me if parts of it are locked off to me. It is very unfortunate that the kernel developers are taking such a strident attitude on this subject. It seems to me though that the FSF should take an incremental approach to GPLv3. First internationalise it - hell, if they don't somebody will. I really am divided on this. RMS has always been political and he lives these issues. The kernel hackers have got to be respected as uber-hackers but they are not ethicists the way the FSF is. When I am feeling more combatative I think, "yes! let's bring the battle to those evil corpos". Really - the FSF are not forcing anyone to _do_ anything. You write the code - you decide. We still have GPLv2. It seems obvious that an internationalised GPLv2.1 would be universally welcomed. How about a simultaneous GPLv2.1 and GPLv3 release? Let the battle lines be drawn. Sometimes we do have to force people to behave :)
Er, anyway my point is - I agree with khim - GPLv2 is not simply about tit-for-tat or source-for-source it is also(mainly?) about source(+mods)-to-binary-to-source(+mods) or tit-for-tot-for-tat...
We live in teresting times. At the very least GPLv3 will force us all to think about DRM and patents and stuff, which can only be a good thing.
Thank you RMS for your strength of character and cool licences and thank you Linus for your strength of character and cool code. We, as a community, are richer because of you both. I would hate to go toe to toe with either of you!
regards, Anto
(this comment is licensed under GPLv3 and may only be compiled by human brains)
OT Posted Sep 28, 2006 15:18 UTC (Thu) by tjc (subscriber, #137) [Link] I personally believe DRM to be ethically neutral (like money - a lot of people believe money to either intrinsically evil in itself or the 'root of all evil' - money is no more evil than a hammer, they both can be used by humans (that is, moral actors) for good or evil, they are both artifacts.)"Money is the root of all evil" is a common misquote of I Timothy 6:10, which actually says that the love of money is the root of all evil. So your personal belief that money is ethically neutral is in fact compatible with the Bible (which says nothing about DRM, BTW).
OT Posted Sep 28, 2006 16:57 UTC (Thu) by mrfredsmoothie (guest, #3100) [Link] Actually, it says "love of money is a root of all kinds of evil."
OT Posted Sep 28, 2006 21:19 UTC (Thu) by tjc (subscriber, #137) [Link] Actually, it says "love of money is a root of all kinds of evil."ASV says "a root", but KJV, Webster, Darby and Young all say "the root." Apparently there is some room for interpretation in mapping this word from Greek to English.
OT Posted Sep 29, 2006 17:05 UTC (Fri) by mrfredsmoothie (guest, #3100) [Link] Apparently there is some room for interpretation in mapping this word from Greek to English.All translation is interpretation, but the Greek text has no definite article to go with "rhiza" (root) and most modern translations translate it "a root" accordingly.
OT Posted Sep 28, 2006 18:41 UTC (Thu) by gravious (subscriber, #7662) [Link] tjc,
Thank you very much. You have reconfirmed my belief that any syntactical unit greater than one word is either an accidental misquote or a deliberate perversion of the original intention of the author. Having said that 'our' use of the one word hacking is at variance with common usage. Let me thus amend. You have reconfirmed my belief that any syntactical unit greater than one word or any one word greater than 6 letters is either an accidental misquote or a deliberate perversion of the original intention of the author. I challenge anybody to show me a word of 6 letters or less that means something radically different in common usage than it's dictionary or jargon definition.
later, Anto
OT Posted Sep 28, 2006 21:21 UTC (Thu) by tjc (subscriber, #137) [Link] Sorry, I have no idea what you're on about. :-)
OT Posted Oct 3, 2006 1:02 UTC (Tue) by xoddam (subscriber, #2322) [Link] > I challenge anybody to show me a word of 6 letters or> less that means something radically different in common > usage than it's dictionary or jargon definition
Why not just recycle the example above: "root"?
If that's not "radical" I don't know what is ;-)
Much ado over licenses Posted Sep 28, 2006 18:40 UTC (Thu) by vonbrand (subscriber, #4458) [Link] The problem: when Linus (and others) say GPLv2 is great because it's based on "tit fo tat" principle they are wrong. Very wrong. GPL was never about "tit for tat". Linus adopting GPLv2 for the kernel was never because "what the GPL is about", it was about what it says. GPL(v2) is a great legal hack, using coyright laws to make code sharing back mandatory. Many people (I dare say most) publish their code under GPL because of this, and because it is wise not to create a license quagmire; and certainly not because of the FSF's crusade. Just look back a dozen years, the whole GNU project was just a curiosity and a plaything for university students with too much free time. And it is nothing more today, the central GNU pieces (GCC, emacs, glibc) have either moved away from the FSF (GCC and glibc, remember the row around egcs?) or plain forked (xemacs vs emacs). The central missing piece of the fabled GNU project (a kernel) is still not usable, some 20 years later.
Much ado over licenses Posted Sep 29, 2006 7:10 UTC (Fri) by khim (subscriber, #9252) [Link] Linus adopting GPLv2 for the kernel was never because "what the GPL is about", it was about what it says. Yup. And I can easily understand where Linus comes from and why he adopted "v2 only" policy. No problem with that: obviously he expected something like that - thus he invented such policy in first place! What I can not understand if where linux developers who scream "abuse of trust", "not similar in spirit" and so on come from.
Much ado over licenses Posted Sep 28, 2006 12:01 UTC (Thu) by louie (subscriber, #3285) [Link] I think it may be prudent for the FSF now to drop the DRM mandate or make it optional. It is optional. See section 7a of the second draft. Striking how many people discussing this have clearly not read the license.
Much ado over licenses Posted Sep 28, 2006 15:39 UTC (Thu) by sepreece (subscriber, #19270) [Link] We've read the license. Since it allows downstream redistributors to drop added permissions, you can't really fix the issue with an optional permission.
Note that you COULD fix the DRM issue by taking it out of the core and allowing it as an added restriciton in section 7, because restrictions are not removable. However, that also causes incompatibility similar to GPLv2 vs GPLv3, so I'm not sure it gains anything.
Much ado over licenses Posted Sep 28, 2006 18:35 UTC (Thu) by pimlott (guest, #1535) [Link] Since it allows downstream redistributors to drop added permissions, you can't really fix the issue with an optional permission.Can you clarify why this is an issue? Would you really expect anyone to fork your code just to add the DRM restriction?
Much ado over licenses Posted Sep 28, 2006 18:10 UTC (Thu) by brouhaha (subscriber, #1698) [Link] It is optional!If you don't want the anti-DRM provisions, use GPLv2. If you do want them, use GPLv3. It's at the discretion of the copyright owner, just as it should be.
The share-alike clauses do not restrict use Posted Sep 28, 2006 7:41 UTC (Thu) by bignose (subscriber, #40) [Link] > [the signatory Linux developers] see the language in the GPLv3 draft as> restricting the possible uses of their software, and they don't like it.
That does seem to be a major complaint. It's incorrect, though.
The license terms unconditionally grant the freedom to use the covered work. There are no restrictions on how someone can use the work.
The license terms also grant freedom to modify and redistribute the work, but with the important condition that the redistribution must allow the recipient the same freedoms to modify, redistribute and use the work.
No user of the covered work is restricted by these terms. Rather, any act of redistribution must preserve the freedoms in the license.
The only acts "restricted" by that condition on redistribution are those which would attempt to restrict the rights of others -- which has always been forbidden under the GPL. Even the much-lauded GPL version 2 states this goal explicitly:
"... if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have."
To twist one's opinion, such that clauses attempting to enforce this are "restricting the possible uses" of the covered work, is rather disingenuous.
The share-alike clauses do not restrict use Posted Sep 28, 2006 15:43 UTC (Thu) by sepreece (subscriber, #19270) [Link] Obviously, the authors were using "use" in its conventional English sense and not in the restricted sense that the license and copyright law use it. If you ask some "What software are you going to use in building your next product?" it's completely natural to say "I'm going to use Linux", even though that particular "use" actually involves conveying copies.
I'm sure the authors understand the distinction you make in your comment.
The share-alike clauses do not restrict use Posted Oct 17, 2006 4:31 UTC (Tue) by bignose (subscriber, #40) [Link] > Obviously, the authors were using "use" in its conventional English sense
It seems to me that the "conventional English sense" -- that is, the sense understood by most speakers of English, and not just programmers -- of the term "to use software" would be to *run* that software, not distribute it.
> and not in the restricted sense that the license and copyright law use it.
Since the entire discussion is about copyright law and the particular license, I disagree that it makes any sense to use an interpretation ignoring those areas.
Much ado over licenses Posted Sep 28, 2006 12:17 UTC (Thu) by ibukanov (subscriber, #3942) [Link] > Just as there is disagreement over what kinds of problems can be solved by passing laws, there is no consensus on which problems can be addressed with license terms.
Very good point. Digital signatures are just one way to lock the code. Using ROM chips is another well-known technical measure. Both are denying the freedom to run modified code. In fact there are more ways to block a user from doing that, like denying access to a compiler for custom-designed chips, requiring extra hardware to upload the code, restricting number of times the firmwire can be changed to just very few etc.
IMO GPLv3 by focusing on one particular issue missed a bigger picture while adding rather controversal legal text.
Much ado over licenses Posted Sep 28, 2006 18:01 UTC (Thu) by smoogen (subscriber, #97) [Link] So basically we are going to see GPLv3.1,2,3,4,5 etc each time someone comes up with a new way that isnt covered under the said license to restrict someone from doing something. Humans are very smart creatures, they have been figuring out how to do things like this for 10,000 years and only gotten better at it as time goes by.
Maybe they should have a GNU Free Hardware License? Hardware in many ways is different in how things "work" on it as Documentation is different from Software.
Much ado over licenses Posted Sep 28, 2006 18:26 UTC (Thu) by ibukanov (subscriber, #3942) [Link] > Maybe they should have a GNU Free Hardware License?
Insted IMO a license that tries to protect the freedom to run modified code can require that for a reasonable fee one can get a box with the modified software on it.
For example, if a company distributes boxes with ROM, then a user should be able to get a ROM chip with his modifications that he can put into the box for the price of the chip plus services.
If the company uses a custom compiler for the code, then again for a reasonable fee the user should be able to get his code compiled.
If the company requires that the firmwire can only be uploaded using custom hardware, then they should provide on reasonable terms an access to that hardware.
And if the box is nuclear reactor, then a reasonable fee would mean to get approval from all the necessary government agencies for the modified code.
Of cause, it may be very well impossible to write such license in precise legal terms, but then it would just mean that the goal of "the freedom to run modified code" is incompatible with the current laws.
Much ado over NOTHING Posted Sep 28, 2006 18:20 UTC (Thu) by brouhaha (subscriber, #1698) [Link] All this discussion over GPLv3 and Linux is a complete red herring. It doesn't make ANY difference whether Torvalds likes the GPLv3 or despises it. The reality is that the Linux kernel is licensed under GPLv2, and that's virtually impossible to change. The FSF can put any random restrictions they want into GPLv3, even that you can't copy the software on Tuesdays, and the effect that it would have on Linux is exactly... NONE WHATSOEVER.Similarly, claims that have been bandied about that the GPLv3 is doomed because Linux isn't going to use it are HOGWASH. The Linux kernel is only one out of a zillion software packages that use the GPL. The Linux kernel not using GPLv3 has no direct effect on whether the copyright holders of any of those other packages might decide to release future versions under the GPLv3. And there's nothing that will prevent people from running GPLv3 user-space applications on a GPLv2 Linux kernel. The fearmongering about having to fork glibc is absurd as well. glibc is covered by the LGPL. There is no reason that you couldn't dynamically link GPLv3 code to a GPLv2 glibc, or vice versa. The only place where this could become an issue is with static linking, which is relatively uncommon in typical Linux applications. (It could be an issue for embedded systems that are statically linked.) This whole issue is being blown up way out of proportion.
Much ado over NOTHING Posted Sep 29, 2006 3:48 UTC (Fri) by JoeF (subscriber, #4486) [Link] You are both right and wrong.It is indeed pretty much impossible to change the Linux kernel license to anything else than GPLv2. All kernel contributors, i.e., holders of kernel copyrights, would have to agree, and that's pretty much out of the question. The Linux kernel is indeed just one of many many projects using the GPL, but it is highly visible, arguably the most visible GPLed project, and while it doesn't have a direct influence on other projects, I think it has a huge indirect influence. The distros are much more affected, since they are the ones who would have to make sure that the applications they put in the distros can actually be distributed together. Small distros are likely to suffer, since they may not be able to afford a lawyer to sort these things out. So this may benefit the Redhats and Novells of the world (I run Slackware...) My hope is that despite all the heated rhetoric, there is going to be a compromise, since the FSF can be pragmatic if they choose so. The egcs episode showed that quite nicely.
Much ado over NOTHING Posted Sep 29, 2006 5:36 UTC (Fri) by brouhaha (subscriber, #1698) [Link] I'm afraid I don't understand your point about distributions. There is no issue with a Linux distribution containing a GPLv2 kernel together with some GPLv2 applications, some GPLv3 applications, some BSD applications, etc.Both the GPLv2 and GPLv3 do not consider running an application on an operating system in the normal way to extend the application license terms to the kernel or vice versa. Similarly, "mere aggregation" of GPLv2 or GPLv3 applications into a distribution doesn't require that other applications in the distribution share that license.
Much ado over NOTHING Posted Sep 29, 2006 6:34 UTC (Fri) by JoeF (subscriber, #4486) [Link] There may be an issue regarding libraries, for example. The "2 copies of libc" type of things (the libc stuff mentioned in the article probably isn't much of a problem because of libc being under LGPL, but with other libraries, who knows...)Distros are more than just a collection of applications. While I may be able to run a GPLv3 application with libraries licensed under GPLv2 or other licenses, it may not be possible to distribute such a combination. Recent articles here and elsewhere have pointed out that some distros are running afoul of license agreements already. My comment was actually inspired by the recent issues regarding Debian and Firefox. Depending on how the actual final language of the GPLv3 is going to look, there may or may not be issues. Then there is the issue about additional restrictions that the current GPLv3 draft would allow. How that works out, how compatible between GPLv2 and v3 these things are going to be remains to be seen. And determining this will probably require IP lawyers, which probably only the big distros can afford.
Much ado over NOTHING Posted Sep 29, 2006 17:17 UTC (Fri) by brouhaha (subscriber, #1698) [Link] I still disagree about their being problems with a combination of GPLv2 and GPLv3 in userspace. If you're not doing DRM, dynamic linking a GPLv3 application to a GPLv2 library or vice versa should be fine, because they are not distributed as a combined derived work. They're merely aggregated onto the same physical medium.Debian v. Firefox is an entirely unrelated issue. That's a trademark problem.
Much ado over NOTHING Posted Sep 29, 2006 20:54 UTC (Fri) by JoeF (subscriber, #4486) [Link] If you're not doing DRM, dynamic linking a GPLv3 application to a GPLv2 library or vice versa should be fine, because they are not distributed as a combined derived work. They're merely aggregated onto the same physical medium.Well, what if an application licensed under GPLv2 uses a library that's under GPLv3, for example? A distribution has a bunch of these things, which could be considered derived works. Distributions are more than just aggregations.
Debian v. Firefox is an entirely unrelated issue. That's a trademark problem.
IMHO: Difference between Stallman and Torvalds Posted Sep 29, 2006 14:22 UTC (Fri) by faramir (subscriber, #2327) [Link] Torvalds wants to see changes to GPL'ed software.
Stallman wants to be able to make changes to GPL'ed software running on
The specific language of GPLv3 isn't the problem. The problem is that
Much ado over licenses Posted Sep 29, 2006 16:09 UTC (Fri) by kleptog (subscriber, #1183) [Link] The GPLv3 draft requires that, if somebody ships you a device which runs GPLv3-licensed code, they must also provide you with everything required to rebuild and reinstall that code - including encryption keys if the hardware requires them.It says that, but it seems to me that hardware developers have a way around that. They could provide instructions on how to change the key in the hardware, so you could compile your own kernel and have the system load it. Ofcourse, now all the non-GPLv3 code sees that the keys have changed and stop working. But they've stuck to the letter of the licence, and RMS still gets to play with the hardware.
Much ado over licenses Posted Oct 7, 2006 10:43 UTC (Sat) by anton (guest, #25547) [Link] IIRC some years ago the kernel developers were not that happy with theGPLv2, either, and have stated a exceptions, e.g., to support proprietary modules. In the meantime, they have changed their attitude, making it harder and harder for proprietary modules.
So maybe we will also see the attitude of the kernel developers
BTW, what about the other components that are typically used in embedded
Much ado over licenses Posted Oct 7, 2006 12:57 UTC (Sat) by stock (guest, #5849) [Link] I fear that the FSF is now behaving like RedHat and Fedora have beendoing over things like the NTFS filesystem driver ntfs.ko and the abandoning support of popular mainstream audio/video formats like mp3. Inside the USA this may seem necessary but overseas like in France, Mandriva has never excluded these. So the GPLv3 might seem a glove match on American soil, where things like the DRM legislation will be enforced, in other countries DRM issues will just be textbook legislative examples only. So my suggestion for Torvalds is to aim, point and identify which parts of the Linux kernel can remain under GPLv2, and make a separate additional part, like if you have linux-2.6.18.tar.bz2, you will now have linux-2.6.18-std.tar.bz2 + linux-2.6.18-gplv3.tar.bz2, where the latter is an extra tarball to be extracted over linux-2.6.18-std. Robert
|
|||||||||||||