Slashdot Mirror
Could Linux Still Go GPL3?
turnitover writes "Even though Linus has said 'The Linux kernel has always been under the GPL v2. Nothing else has ever been valid,' LinuxWatch is reporting that Richard Stallman has said it's ultimately up to the developers. And those on the LKML (Linux Kernel Mailing List) are going back and forth about whether to move to GPL3. The sticking point, not surprisingly, is the issue of DRM." In response to the DRM issue Linus wrote: "I personally think that the anti-DRM clause is much more sensible in the context of the Creative Commons licenses, than in software licenses. If you create valuable and useful content that other people want to be able to use (catchy tunes, funny animation, good icons), I would suggest you protect that _content_ by saying that it cannot be used in any content-protection schemes."
It's what every software project does when there's fundamental differences of opinion on which direction to go. If Linus and the other Linux software devs don't like GPL3, just fork the thing and take out the parts you don't like and use that license. After all, the text of the GPL 3 license should be able to be modified just like source code, right? You wouldn't be able to call it GPL 3, as it's just confusing. But GPL 2.99 might work nicely as a name.
AccountKiller
Well, I guess they could GPL3 all the portions of the kernel that aren't derivative works of Linus' parts. Which would be what, exactly? The build scripts?
You can't just take code already under GPL2 and move it to GPL3 without the authors' permissions. That's CHANGING THE LICENSE, and that's exactly what Linus is getting so fired up about. Everyone that contributed something under GPL2 would have to be contacted and would have to give consent to have their code moved over to GPL3. You can't just make a broad sweeping change to the license. If you could, then you could easily fork and close-source your branch. If that were the case, we'd have IBM, Novell, Sun, and RedHat proprietary Linux. It would also be a management NIGHTMARE to have pieces of code under each license.
The main issue isn't DRM or not-DRM, it's YOU CAN'T CHANGE THE LICENSE!
There is a good article on LWN.net, but it's subscriber-only until Feb 9th: http://lwn.net/Articles/169797/
Here's an excerpt:
==BEGIN EXCERPT===
Another thing to keep in mind is that Linus can change his mind, even after seemingly painting himself into a corner with an absolute statement. One of your editor's favorite Linus pronouncements was issued almost exactly seven years ago. In response to a query on how to set up an i386 box with 4GB of memory, Linus stated:
Oh, the answer is very simple: it's not going to happen.
EVER.
You need more that 32 bits of address space to handle that kind of memory. This is not something I'm going to discuss further... This is not negotiable.
Less than one year later, Ingo Molnar's high memory patch was merged for 2.3.23.
===END EXCERPT---
There are a few things to keep in mind about DRM that have not been explained in a lot of the articles.
This was debated on ILUG yesterday. Here's the mail that started it: http://www.linux.ie/lists/pipermail/ilug/2006-Febr uary/086087.html
So it's worth keeping in mind that what Linus calls the GPLv3 is actually only the first discussion draft - but also, due to point #2 above, while changes may be made, I'd be pretty sure there will be DRM-combatting provisions in GPLv3.
Please help publicise swpat.org - the software patents wiki
I am sure that Linux will be switched over to GPLv3 less then 6 months after GPLv3 is actually released in its final form. The issues that Linux and some others are bringing up are mostly their misunderstanding of what is acually said in GPLv3 and how it corelates with the DMCA and case law of USA and with laws in other countries.
NOTHING in GPLv3 disallows implementing DRM with GPLv3 code. However there are some extra provisions that insure that if such implementations are made, the right to change that code (which is one of the most protected rights in the context of the GPL) can not be taken away from the users by a means of a DMCA-based lawsuits.
Oh, and if you make hardware and sell it to the users, please do not restrict what code users can use on that hardware, or if you do, please do it without using our (GPLv3'd) code. That is the TiVo scenario - the TiVo has sold a person a computer, but it uses a technical provision to deny thoses people an ability to execude their programms on the hardware. They might not be able to give us some services if our software does not work like theirs does or they would surely not support software problems in our software, but it is not right to use our code and then lock it from us in a box that we paid for.
I think that once the GPLv3 is polished a bit more and once someone explains all the provision of the GPLv3 and corresponding laws to the LKML people in ways that they will understand, the move to GPLv3 will be unobstructed (maybe except for by a few people who wish they would be writing code for BSD anyway).
At that point opening a Linux 3.0 branch with GPLv3 clean code only would be most reasonable thing to do.
Yes, this distinction is important. The way the GPL 3 is worded, from what I can tell, it's trying to say: "you can't design GPL-ed software to run on a device that will not accept modified versions of the software. If you design such a device/software combo, you must release the keys so that anyone can run modified code on your device. On the other hand, if the modified software can run properly on the usual device without those private keys, then you don't have to release the keys."
... after all, he doesn't even know what the (final) GPL 3 will be like!
It's this last sentenct of my paraphrase (in bold) that is not adequately clear in the current version of the GPL 3. What I wrote above in quotes is what the GPL 3 is trying to say in legalese (I think), but the way it is currently worded, Linus is worried that it will mean that signed (trusted) binaries will not be allowed.
Of course, what everyone seems to be forgetting is that we are reading a DRAFT of the GPL 3. So if there's something that isn't quite right, now is the time to fix it! Get involved in the discussion and tell those who are working on the GPL 3 that the wording needs fixing to make sure that it acts as intended. Linus is saying publicly that he doesn't like the way it is currently worded... but I wish he would emphasize "I think it should be reworded before the final release of GPL 3" rather than saying "I won't use GPL 3"
To summarize: the GPL 3 is currently a draft only. Let's get it fixed to avoid any problems in the future. I agree with RMS that it should not be possible to create a device/software combo based on GPL-code where no one is able to modify the code (and the code only makes sense in the context of the device it was made for). On the other hand I agree with Linus that we should not have a GPL that forbids signed/trusted binaries. It is possible to write a license that clearly differentiates these two cases... so let's do it!
Linus said
"Notice how the current GPLv3 draft pretty clearly says that Red Hat would have to distribute their private keys so that anybody sign their own versions of the modules they recompile,"
when the (draft of the) GPLv3 says
"3. Digital Restrictions Management. [...] no permission is given [...] for modes of distribution that deny users that run covered works the full exercise of the legal rights granted by this License."
As far as I understand, what the GPLv3 says is that as long as RedHat gives you a way to recompile the OS with your own signing keys (or without authentication at all) then they are allowed to distribute GPL software with whatever signature they want.
Where did I miss something ?
--Go Debian!
What you say is true. However Linus has ideals too. In TFA he says "the point of the GPL is not the 'convert the infidels' logic, but something totally different: 'quid pro quo.' "
The GPL 3 is anti-DRM in a big way, and Linus doesn't agree with that, fair enough. However another aspect of it is to prevent someone from taking GPL code, and designing a hardware/software combo that will only run using unmodified versions of the code. In such an instance, they use GPL code, but their modifications are useless to the rest of the world because we can't modify their version and run it on the device. Basically they break Linus' "quid pro quo" rule. Thus part of what GPL 3 is trying to do is exactly what Linus says he believes in.
I personally think the GPL 3, as it stands, needs some revisions before being finalized. Linus is a smart man and has pointed out one of the very real problems with the current draft. But to suggest that Linus is just an engineer, with no ideological concerns whatsoever is not quite right. He's not the zealot that RMS is, but he still has (legitimate) moral concerns (otherwise he wouldn't care what license gets used). As should we all, frankly.
So GPLV3 effectively prevents digital signatures from being used to determine if a binary may be from a source the user trusts!
No it doesn't. You can provide a digital signature that verifies that binary is from 'Bluehat' without the signature being required to run the binary.
The key difference here is that the former informs the user who is then free to make a decision about whether they want to trust a non-'Bluehat' binary, and the latter tells the consumeruser he isn't allowed to run a binary that's not from 'Bluehat'.
1. it is my technical (as a paralegal) opinion that, if Linus don't change his mind, the kernel can NEVER be relicensed GPLv3. This is because I consider that the GPL restricts the distributions of derivative works under the terms of the GPL (as per section 0) or under more liberal terms (as per section 6) and the GPLv3, at least as currently drafted, is more restrictive than the GPLv2.
2. as a corollary -- and another justification -- to (1) above, it is my technical opinion that most (at least 80%, but probably more than 90%) of the "official Linus Penguin-pee blessed" kernel source lines are, as a matter of fact, a derivative work on the continuous works of Linus Torvalds, since 1991.
3. just as RMS, I think proprietary software is bad. I think proprietary software is bad because proprietary software -- especially the kind you normally buy in a box -- is basically a scam. What is the scam? When you buy some medicine, you are paying for (P) the cost of production [normally the dominant cost factor, but at least au pair with the other cfs] + (R) the cost of research + (F) the amortization of some future research + ($) some profit to pay for the invested money. In the case of proprietary software, we have P ~~ 0. MS invested ten million dollars on MSWord (insert some version number here) and was rewarded a billion dollars by it in less than (number less than ten) years because they use their "bait and switch" tactics, their "first use for free" tactics, their "hook the kids" tactics, and their "leverage any semi-monopoly we have" tactics. Tell me, what other business uses those exact four tactics? (just like some illicit business, their profit margin is incredible)
4. in this respect, I think Free Software (and copyleft licenses) is not only more fair, but more "right", too. When you have an itch, you pay a programmer to scratch it. No strings attached other than "others must play fair too". People that PRODUCE software continue being paid to produce software, ie, to churn out LOCs. But people that just exploit the general public by sitting on a product (yeah, a nice one by a number of accounts, and this "nice" I'm saying even applies -- or applied some day -- to Windows 95) that they have done once. Imagine a perfect world, where instead of lining up MS's stockholder pockets, all the profits of MS had being used to hire more programmers!! And send them to churn out more -- and better -- code!! Get it?
5. yes, I love numbered lists.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
You've got it wrong. Bluehat can still provide signed binaries and not provide the signing key for those binaries. However the hardware must allow the user to run unsigned binaries. That way you get the best of both worlds: you can use Bluehat's signed binaries if you so choose, or you can opt-out and run unsigned binaries, or Bluehat can provide the signing key and you can sign your own binaries. Everybody gets what they want (except maybe Bluehat).
All the GPL3 is trying to stop is the case where Bluehat produces hardware that only runs Bluehat binaries.