Torvalds Explains Dislike For GPLv3 552
Joe Barr writes "Linus Torvalds explains in three recent posts why he doesn't care for the DRM restrictions in GPLv3, and he has never been one to hold back. From his commentary: 'I _literally_ feel that we do not - as software developers - have the moral right to enforce our rules on hardware manufacturers. We are not crusaders, trying to force people to bow to our superior God. We are trying to show others that co-operation and openness works better.' NewsForge has the complete text of all three posts available." We discussed his initial reaction to GPL3 at the end of last month. NewsForge is a sister site to Slashdot.
Both moral and legal rights (Score:1, Informative)
Re:Translation (Score:5, Informative)
Don't put words in his mouth. Linus has never been the crusader that RMS is, and as he says in the article, doesn't want to be either. He claims that he doesn't feel like using software licensing and copyright as a weapon to fight political battles. I don't blame him, either. He seems to have meant precisely what he said. Since Linus isn't much prone to doublespeak or pulling punches, I'm tempted to believe him.
GPL3 is a tipping point for the FSF. If they go that route, they will lose all corporate support, which they think they don't need but in fact very much do. GPL3 goes way too far. So if they want to marginalize themselves...go right ahead.
Re:DRM is the antithesis of openness (Score:2, Informative)
I'm sorry, but in order for the market to work, and chairs to move into the digital age, there has to be chairs rights management so nobody can copy a chair at home.
Oh, wait, that's not 'the market'. What you actually must have meant was 'for monopolists to allow humanity to move forward and reap the benefits from the digital age, they must retain the ability to enforce artificial scarcity in the interest of keeping revenues up in a situation where the laws of supply and demand would otherwise eradicate their ability to profit at their current levels of inefficiency'.
That's pretty much the opposite of 'the market'.
Oh my fsckin' $DEITY ... (Score:3, Informative)
DRM does not work. Ask PSP hackers (*)
Alice is the content creator.
Bob is the content consumer.
Eve is the eavesdropper.
Alice sends the encrypted content to Bob.
Bob has the key to decrypt the content, so he can see the plaintext.
Eve cannot see the plaintext -- but wait, Eve is just another split personality of Bob. So, yes, Eve has the key and can see the plaintext.
(*) Not crackers -- PSP hackers want to install software they themselves developed onto hardware they bought with their own money: if people will take advantage of their hacks to play copied games, it's a collateral. I, myself, want to make linux work on my playstation portable -- that I purchased with MY money. I didn't sign any contracts or NDAs with Sony. I just went to the store and I have the right to install whatever software I want in the fscking thing. If -- and only if -- I install "irregular" software/contents in MY hardware is the concern of the mentioned software/contents creator.
Alan's Comments (Score:5, Informative)
You are wrong and out of context. (Score:4, Informative)
Nothing to do with anything being done now, since RedHat does not currently run on any such locked hardware afaik.
Re:Is it just me (Score:3, Informative)
"If you want to use this software, no problem - you're free to do so. If you want to distribute this software, you must make the source code available to those who you distribute it to, at no cost over the cost of distribution."
Just to clear that up.
Re:Why would they have to give away their keys? (Score:2, Informative)
I read Linus's statement as a what-if, not a this-is. It would be possible for Red Hat to add a private kernel patch that does 'driver signing' like Windows does to protect users from loading 'untested' drivers on their system. Red Hat would have to provide the source code to the system under the current GPLv2; they would have to distribute the public key used for signature verification but would be allowed to keep their private key. This would allow others in the community to create their own 'driver signing' system, with their own key pair, or to modify the existing Red Hat code to defang it or allow loading unsigned modules while marking the kernel as tainted (as loading a proprietary-licensed kernel module currently does).
Under GPLv3's DRM provisions, though, it appears that Red Hat would also have to distribute their private key as well. (GPL v3 Draft, Section 1: "Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you") Distributing the signing key would completely eliminate the effectiveness of their 'driver signing' program, since any J. Random Hacker could sign their just-compiled kernel module and sign it, even if it's horribly broken and will crash systems on load. This removes Red Hat's ability to do a value-add for people who want to contract with them (which is separate from their right to use the software), while it doesn't harm others in the community (we can still recompile the kernel without the 'driver signing' and distribute it). This is limiting the ability of developers to innovate, simply because it does certain things that approximate what a DRM system does. As Linus said, baby and the bathwater...
There will be systems where a GPLv3 license may be quite useful; for instance, I would love to see programs and projects that provide audio and video encoding functions (such as Ogg) adapt GPLv3, so that their code cannot be taken and used as the base of a DRM-restricted media format. (GPL v3 Draft, Section 3: "No covered work constitutes part of an effective technological protection measure", would explicity allow circumvention of any added DRM, since the DMCA only covers "effective technological protection measures.") Those programs are much closer to the 'content creator' class that Linus described in his posts, and I hope those developers will feel it is moral for them to prevent their code from being used in a DRM-restricted system.
Re:The real question (Score:3, Informative)
Good point, but I suppose that the difference would be that you *can* change the code and execute it -- albeit with difficulty (say, by changing the chip) -- and you are not legally restricted, which is the problem with DRM: its not that it is hard or difficult or virtually impossible to run modified code, is that if you circumvent the DRM they'll throw the DMCA book on you.
-dZ.