Why Torvalds is sitting out the GPLv3 process (Linux.com)
Why Torvalds is sitting out the GPLv3 process (Linux.com)
Posted Sep 26, 2006 18:37 UTC (Tue) by alexbk (subscriber, #37839)In reply to: Why Torvalds is sitting out the GPLv3 process (Linux.com) by robilad
Parent article: Why Torvalds is sitting out the GPLv3 process (Linux.com)
:) Thanks for giving me a smile. Even if the new, bitchy Linus is quite a disappointment.
Posted Sep 26, 2006 19:11 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (36 responses)
He alwasy was "kill-bill-beatrixy bitchy". His skills, both tech and management, are undeniable; but, in his words: "I'm a bastard" (which is a line of Bill in Kill Bill vol 2 also). I think it's fortunate that he is somewhat changing his mind with the "it doesn't kill babies" line.
But, if you are reading, Linus:
GPLv3 = GPLv2 + explicit patent license (*) + clarified language (**) + no-tivoization-clause (***) + permission of some variations (****)
(*) as opposed to the implicit patent license that you have from GPLv2
IMHO, the GPLv3, as of the second draft, is already better than the GPLv2. Some debugging and I think it will be _really_ better than the GPLv2. And look, I was anti-GPLv3 at first.
Posted Sep 26, 2006 22:12 UTC (Tue)
by mingo (guest, #31122)
[Link] (22 responses)
you might also be upset if it's used in weapons, or if it's used on porn sites, or if it's used by an islamic organization. There are many reasons people might be upset about, and we should simply not use the license to "retaliate". We dont want to get into the business of judging people's use. The GPLv2 didnt do that, and the GPLv3 shouldnt do it either. If you dont want a Tivo because it has a too restrictive form factor, RAM size, software selection or modifiability, dont buy it.
To not (ab-)use licensing power to retaliate against choices made by third parties is one of the differences between Linus and RMS.
Anyway, a fair number of kernel contributors have spoken out on the DRM subject, and their arguments were not addressed in any substantial way. So we'll have to wait and see.
Posted Sep 26, 2006 23:01 UTC (Tue)
by arcticwolf (guest, #8341)
[Link] (1 responses)
You may not care that your code is used on TiVo-like devices where you can't substitute your own, modified version and run that instead, but if others do, what's wrong with that? Code I write is *my* code, and I can put it under any license I want to, so you shouldn't tell me I cannot use a license to "retaliate". I'd already be giving TiVo something they'd not have otherwise - they right to use my code, if they meet certain requirements -, so they'd not be a position to complain.
What's more, I think that for those who're not really interested in the technical details of licenses and who just want the "tit for tat" that Linus mentioned, the fact that it's perfectly legal for TiVo to use their code and, at the same time, prevent them from modifying the resulting work may be an unpleasant surprise.
For me, the restrictions the GPLv3 introduces in that regard are no more unacceptable than the GPLv2's requirements that source code be shipped in the "preferred form for modification" - you could also argue that that's unfair to those who'd rather send you the source on microfiche than as a tarball, but nobody in their right mind would do that.
Why is the whole DRM thing different? It all boils down to my actually being able to *use* the source code I received; if I cannot use it, the whole "tit for tat" collapses like a house of cards.
So if Linus is really interested in "tit for tat" and fairness, then I'm not sure why he's opposed to this.
Posted Sep 26, 2006 23:17 UTC (Tue)
by mingo (guest, #31122)
[Link]
Thank you Guest for the polite injection into this discussion ;-)
You may not care that your code is used on TiVo-like devices where you can't substitute your own, modified version and run that instead, but if others do, what's wrong with that?
There's nothing wrong with that, i'm just trying to point out the implicit dangers of such licensing approaches to the free software community.
Or by your argument there's nothing wrong with people wanting to sell their monopolized, closed-source software for $75 apiece either, just because it's their code, right?
Posted Sep 27, 2006 0:52 UTC (Wed)
by RMetz (guest, #27939)
[Link] (2 responses)
you might also be upset if it's used in weapons, or if it's used on porn sites, or if it's used by an islamic organization.
I, respectfully, don't think that's an apt metaphor. The objection to weapons use, in the context of Tivo's usage, would be more along the lines of "I object to Tivo using my code because TV leads to people reading fewer books."
I think objecting to someone selling you a device running code you wrote and not letting you modify it in a useful manner is very different from objecting to someone using your code for a purpose you don't like. The first case is about not having significant access to your code; in the second case you have meaningful access but have a problem with their usage of your code. As you've explained, the GPL doesn't let you choose what people can do with your code, but it _does_ ensure that you'll have meaningful access to the code if they sell/distribute it back to you. Seems to me that this new clause proctects this right in the case of a Tivo-like device and it's an important right to protect.
As for the weapons, I suppose they could always tape CDs with the sourcecode on them to their warheads in order comply. ;)
Posted Sep 28, 2006 2:37 UTC (Thu)
by AJWM (guest, #15888)
[Link] (1 responses)
If you don't like the format they're selling it in, don't buy it. And in the TiVo case, you can do whatever the heck you like with the code, except to run it on hardware that won't support it -- which, in that case, includes the TiVo.
It's the hardware that's broken, not the software.
Personally I avoid broken hardware, and encourage my friends to.
Posted Sep 28, 2006 3:48 UTC (Thu)
by RMetz (guest, #27939)
[Link]
I think this violates the spirit of the GPL. But the GPLv2's language on this matter leaves the loophole open. The clause under discussion closes this loophole.
I'm actually still unsure about the GPLv3, but PJ over at Groklaw has done a lot to bring me over to its side. I'd suggest everyone go read what she has to say for an opinion based in an understanding of the law and legalese.
Posted Sep 27, 2006 5:56 UTC (Wed)
by russell (guest, #10458)
[Link] (3 responses)
The GPL says I can fix bugs and security holes, I can customise it to my needs, I can support it after the company has gone under. So giving the source with no way to use it IS circumventing the intent of the GPL. I see GPLv3 as a more explicit statement of the goals of the GPL.
If the kernel developers didn't agree with the goals of the GPL, why did they choose it? Did they understand the intent/goals of the GPL to be something different?
Posted Sep 27, 2006 8:09 UTC (Wed)
by fooker (guest, #14834)
[Link] (2 responses)
Looks to me that the retaliation is not against what the
code is used for. It is against circumventing the freedoms the GPL is
suppose to guarrantee. The GPL says I can fix bugs and security holes, I can customise it to
my needs, I can support it after the company has gone under. So giving
the source with no way to use it IS circumventing the intent of the GPL.
I see GPLv3 as a more explicit statement of the goals of the
GPL. I don't quite understand this whole TiVo-issue. As far as I understand
the spirit of the GPL is to guarantee free use of program code, nothing
else; not free use of the resulting binaries. You can have all the GPL'd
code used in a TiVo box and use it in any way you like, as per the
license. You just can't run your modified programs in the box. That's not
against the GPL. Against your personal values maybe, but that's a
different issue. Then just don't buy a TiVo. For many devices it is actually good thing that you can't use custom
software in them. I for one don't want to see the day when people start
using hacked firmware on their cell phones, for example.
Posted Sep 27, 2006 10:59 UTC (Wed)
by khim (subscriber, #9252)
[Link]
s far as I understand the spirit of the GPL is to guarantee free use of program code, nothing else Wrong. Very wrong. The goal from the start was to make it possible that the "user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him. Users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes". That was the goal from the start. You can have all the GPL'd code used in a TiVo box and use it in any way you like, as per the license. You just can't run your modified programs in the box. If you can not run modified code then the whole house of cards just become useless. This means GPL failed to achieve the thing it was supposed to do. This is why the GPLv3 is needed in first place - GPLv2 is not enough in today's world to guarantee it!
Posted Sep 27, 2006 11:09 UTC (Wed)
by anandsr21 (guest, #28562)
[Link]
Posted Sep 27, 2006 9:04 UTC (Wed)
by hummassa (subscriber, #307)
[Link] (12 responses)
Posted Sep 27, 2006 10:49 UTC (Wed)
by sepreece (guest, #19270)
[Link] (11 responses)
Posted Sep 27, 2006 10:52 UTC (Wed)
by alexbk (subscriber, #37839)
[Link] (10 responses)
Posted Sep 27, 2006 18:09 UTC (Wed)
by sepreece (guest, #19270)
[Link] (9 responses)
Posted Sep 27, 2006 18:21 UTC (Wed)
by hummassa (subscriber, #307)
[Link] (4 responses)
Posted Sep 27, 2006 19:49 UTC (Wed)
by sepreece (guest, #19270)
[Link] (3 responses)
I abhor the DMCA, but I don't think it's relevant to this discussion. The added restrictions in GPLv3 will do nothing whatever to fight the spread of DRM. The most they can hope for is to make some authors feel better at the expense of making some other authors feel worse.
Posted Sep 27, 2006 23:16 UTC (Wed)
by hummassa (subscriber, #307)
[Link] (2 responses)
Preliminarly: freedom 1 does not "give you the right". You wrote some
In the merit, the text of freedom 1 as in
:: " The freedom to study how the program works, and adapt it to your
It's explicit that access to source code is a precondition to this, but
Posted Sep 28, 2006 14:55 UTC (Thu)
by sepreece (guest, #19270)
[Link] (1 responses)
To me [YMMV], there's a lot of satisfaction in knowing my code is in a particular device, even if I can't change it. That satisfaction is, for me, part of the trade for my effort in creating the code.
Sure, I would prefer a modifiable device, but if that's not an option, I'd rather have a non-modifiable device with my code in it than a non-modifiable device with somebody else's. For some kinds of devices, modifiable is simply not an option.
Posted Sep 28, 2006 15:21 UTC (Thu)
by alexbk (subscriber, #37839)
[Link]
Posted Sep 27, 2006 18:26 UTC (Wed)
by alexbk (subscriber, #37839)
[Link] (3 responses)
Posted Sep 27, 2006 19:34 UTC (Wed)
by sepreece (guest, #19270)
[Link] (2 responses)
If you care about modifiable devices, buy modifiable devices.
To my mind, they have complied with the essential fairness requirement by providing their code.
Posted Sep 27, 2006 19:43 UTC (Wed)
by sepreece (guest, #19270)
[Link]
Posted Sep 27, 2006 20:46 UTC (Wed)
by alexbk (subscriber, #37839)
[Link]
Posted Sep 27, 2006 20:49 UTC (Wed)
by ibukanov (subscriber, #3942)
[Link] (12 responses)
GPLv3 in its current draft does not help you then.
A trivial example: a mobile phone with GPLv3 software implementing draconian DRM where the firmwire can only be changed through GSM net. Theoretically you get the corresponding equipment, but that is very expensive and AFAIK not legal in many countries unless you can get GSM license.
Less trivial example: a box that would accept firmwire updates only from a particular server with a particular SSL sertificate. Since GPLv3 in the current form does not require that you can get access to that server, you would not be able to change the firmwire.
So the "protection" offered by GPLv3 drafts is effectively non-existent that I wonder why it is there at all.
Posted Sep 27, 2006 20:58 UTC (Wed)
by alexbk (subscriber, #37839)
[Link] (11 responses)
Posted Sep 27, 2006 21:06 UTC (Wed)
by ibukanov (subscriber, #3942)
[Link] (10 responses)
Posted Sep 27, 2006 21:18 UTC (Wed)
by alexbk (subscriber, #37839)
[Link] (6 responses)
A real example: latest Nokia phones allow users to update their firmware themselves. You can either
Posted Sep 27, 2006 21:40 UTC (Wed)
by ibukanov (subscriber, #3942)
[Link] (5 responses)
This is not a software problem as you require that the device must accept your input, so the device must have a hardware to do so. And even if the the device already has a keyboard, a license that forces the manufacturer to provided that option would no longer free IMO.
> A real example: latest Nokia phones allow users to update their firmware themselves.
Yes, but what if the manufacturer opted to save the cost and not implemented that, then what? Should GPLv3 prevent that?
Posted Sep 27, 2006 21:50 UTC (Wed)
by alexbk (subscriber, #37839)
[Link] (4 responses)
Posted Sep 27, 2006 22:07 UTC (Wed)
by ibukanov (subscriber, #3942)
[Link] (3 responses)
Would you like for GPLv3 to prevent such device from existence?
Posted Sep 27, 2006 22:10 UTC (Wed)
by ibukanov (subscriber, #3942)
[Link] (1 responses)
Correction, I wanted to say:
Would you like for GPLv3 to prevent such device from running GPLv3 code?
Posted Sep 27, 2006 23:40 UTC (Wed)
by hummassa (subscriber, #307)
[Link]
Because if we don't, everyone will begin to make DRMd hardware and
Posted Sep 27, 2006 22:51 UTC (Wed)
by alexbk (subscriber, #37839)
[Link]
Posted Sep 27, 2006 23:35 UTC (Wed)
by hummassa (subscriber, #307)
[Link] (2 responses)
[QUOTE]
IMHO, "any encryption or authorization keys necessary to install and/or
Posted Sep 28, 2006 2:32 UTC (Thu)
by ibukanov (subscriber, #3942)
[Link] (1 responses)
In the case of the box that accepts firmwire only from a server with particular SSL sertificate there is no "encryption or authorization keys necessary to install". You just need to upload the files on the server. And that particular server happens to require that to upload files you need to come to a server room and put some physical media into the server.
The same story with GSM. There could be no keys, just physical barriers that prevents you entering a control room where you can put CD and start uploading the software to each and every phone of this model.
Posted Sep 28, 2006 15:01 UTC (Thu)
by sepreece (guest, #19270)
[Link]
That's a low-priority item for me, because I feel the license shouldn't have even the current restrictions, but I would think it would be for the FSF and those who believe TiVoization of their code is a problem.
... and I say that in the most respectful possible way ...Linus was always bitchy...
No, really.
(**) come on, no "that is to say..."
(***) _I_, for one, think that if some hardware maker (TiVo) wants to sell me a hardware product in which _MY_ code is used in such a manner that _I_ can't hack it, it would piss me off. YMMV.
(****) there is no intelligent reason why libcrypt, libssh, libssl, or whatever can't be mixed together unless one goes the Gentoo way and makes the end user compile and link all the pieces.
(***) _I_, for one, think that if some hardware maker (TiVo) wants to sell me a hardware product in which _MY_ code is used in such a manner that _I_ can't hack it, it would piss me off. YMMV.
Linus was always bitchy...
That's a pretty silly comment really.Linus was always bitchy...
That's a pretty silly comment really.
DRM again
"(***) _I_, for one, think that if some hardware maker (TiVo) wants to sell me a hardware product in which _MY_ code is used in such a manner that _I_ can't hack it, it would piss me off. YMMV."
Linus was always bitchy...
> objecting to someone selling you a device running code you wrote and not letting you modify it in a useful manner Linus was always bitchy...
But I'm allowed to buy it, and if I do the GPL is supposed to ensure that I have meaningful access to the code. AFAIK, you can only run TiVo's code on a TiVo, and if I can't run modified code on any device, AT ALL, then on a functional level I wouldn't say I've been allowed to modify it. At least, not in any sense that matters.Linus was always bitchy...
Looks to me that the retaliation is not against what the code is used for. It is against circumventing the freedoms the GPL is suppose to guarrantee.Linus was always bitchy...
Linus was always bitchy...
Linus was always bitchy...
You don't really know GPL or FSF or RMS. Suffice it to say that at first there was the printer and now there is the Tivo.Linus was always bitchy...
they are redistributing (or, in v3-speak, "conveying") the code. And in a TiVo is not "using" the code, ....
non-free manner (taking away the freedom to modify it and run the modified
version) and this is exactly what GPLv2 tries to avoid... but fails
because there is a loophole. Closing that loophole is what the
un-tivoization clause tries to do.
Some of us simply don't agree with this definition of "non-free". We believe that the freedom is in the access to and right to use/modify the source code. The source code is the value in the trade. The device is peripheral. [Yes, I do know about the printer RMS was mad at.]TiVo is not "using" the code, ....
I don't get it. How do you excercise the freedom to use/modify the code if the device doesn't allow you to?TiVo is not "using" the code, ....
You run it on some other device. It's the CODE that's free, not the device.TiVo is not "using" the code, ....
TiVo's version of linux only runs on TiVo.There is no other device...
Everything good that TiVo's version of linux has it has only because it's
made to run on TiVo hardware. And you cannot hack and modify it, because
it WON'T RUN. It's useless once hacked or modified. On purpose.
So they took away any liberty from the original coders to hack and modify
it... with a simple technical measure (DRM) and a simple legislative
measure (DMCA).
And that is the point of this whole article: that GPLv2 was made to
protect freedoms # 0..3 and that GPLv2+DRM+DMCA nullify effectively
freedom #1 and that GPLv3 closes the legal loophole, without EVER being
contrary to anything represented by GPLv2.
Again, to me it's about the code, not the device. Freedom 1 only gives you the right to run the code if you have a suitable device. If you have bought a non-reflashable device, then you don't have a suitable device.There is no other device...
> Again, to me it's about the code, not the device. Freedom 1 only gives Respectfully, your answer makes no sense.
> you the right to run the code if you have a suitable device.
code, you have the right to run it wherever you want. You licensed your
code under the GPL (that was made the way it is in order to preserve in
YOUR code [and derivatives] the freedoms 0 .. 3), so the other guy (like
TiVo) only has the right to modify it (eg adapting it to their hardware)
and redistribute it (in their HD or flash) if they follow the rules and
further protect the freedoms 0 .. 3. Now, not even Linus disagrees that
protecting those freedoms is the reason why he GPLd Linux (albeit he can
word it more pragmatically as in "not allowing proprietary vendors to run
with his product"... which is ironically what he's doing when he allows
TiVo to run with linux)
http://www.fsf.org/licensing/essays/free-sw.html
needs (freedom 1). Access to the source code is a precondition for this. "
access to the (one and only) machine where the (object) code will run is
also a (implicit) precondition to "study how the program works, and adapt
it to your needs." Yes, when someone GPLv2 a program, he is trying to make
sure that any derivative works can be freely studied [BOLD] AND ADAPTED TO
ITS NEEDS [/BOLD]. Unless that someone GPLs said program without knowing
exactly what one's doing, which is a possibility -- but no excuse.
I respectfully disagree. To me, freedom 1 is about the program, not about any particular device. I take it on its face: the freedom to run the program, for any purpose. It does not say "the freedom to run the program as part of a particular device."Respectfully, your answer makes no sense.
So you'd be satisfied even if your own code would be used to lessen the freedom of coding that you enjoy? I can't agree with that. If you have and use a freedom, you should also protect it.Respectfully, your answer makes no sense.
You're willing to give a hardware manufacturer the right to use, modify and distribute your code on their hardware. But you're ok if they don't give you the same right. Why do you think that is fair?TiVo is not "using" the code, ....
Why wouldn't I? If I cared about modifying the device, I'd buy a device I could modify. Again, to me, it's about the code, not about the device. The fact that they use my code in a device that I can't modify is no more insulting than that they use it in other devices that I simply have no interest in owning.TiVo is not "using" the code, ....
I should add that I was speaking rhetorically. I do not have any code in Linux. I do not believe my opinion would change if I did.TiVo is not "using" the code, ....
If I care about modifiable devices, I don't allow my code to be used in locked-down ones, aiding TiVo is not "using" the code, ....
their spread in the market. If they become dominant, freedom of code will have no meaning any
longer. Explain why we shouldn't worry about this scenario or why requiring the keys will not help
prevent it. Or at least why well-being of those who don't care is more important than that of those
who do.
> _I_, for one, think that if some hardware maker (TiVo) wants to sell me a hardware product in which _MY_ code is used in such a manner that _I_ can't hack it, it would piss me off. YMMV.Linus was always bitchy...
These are both technicalities that can be fixed with the right language. I'm not sure if the current Linus was always bitchy...
draft really allows them, but I am sure that if you submit these scenarios to http://gplv3.fsf.org
comment system, the FSF will take them seriously. Have you?
Yes, I submitted them. But I doubt that you can fix the issues unless you restrict the design of hardware. Plus a license that restrict the design of the hardware is anything but free. Linus was always bitchy...
Not necessarily: the phone and the box have to know which server to query for updates. Make that Linus was always bitchy...
configurable (a software problem!) and provide server-side tools (also a software problem!).
do it over GPRS data service in GSM networks (in which case the server ip address needs to be
configured on the phone) or via a USB cable with a special windows software tool. Phone's hardware
isn't affected at all.
> Make that configurable (a software problem!)Linus was always bitchy...
Can you give an example of hardware that has no input channels for end-user configuration at all? Linus was always bitchy...
Even gadgets whose function is to only really emit data to the user, like GPS receivers or
temperature sensors, can and do take user input over the same channel, bluetooth or something
similar.
I agree that the vast majority of the hardware has an input channels, but as a hypothetical case consider a radio-synchronized digital clock (not alarm clock!) which has no buttons. In addition the device take periodic firmwire updates through the radio from a server with particular SSL sertificate to take into account changes in day-light saving schedule. Linus was always bitchy...
> Would you like for GPLv3 to prevent such device from existence? Linus was always bitchy...
Unless your server could be blessed with the same ssl certificate so you Yes.
could put YOUR code in YOUR clock. That is the thing: If it's MY code,
and I buy MY hardware with MY code on it, I (and others) better have
freedom 1 ("freedom to study the code and adapt it to my needs")
protected all the way down the line.
literally run with all GPLd code. Because -- as every hardware will be
locked -- no one will ever have the freedom to "adapt it to its needs".
Uh, which kind of radio, exactly? I can't think of any kind where your example wouldn't fall apart.Linus was always bitchy...
Here is the "offending" GPLv3 paragraphs:I don't think you're right...
The "Corresponding Source" for a work in object code form means all the
source code needed to generate, install, and (for an executable work) run
the object code and to modify the work, except its System Libraries, and
except general-purpose tools or generally available free programs which
are used unmodified in performing those activities but which are not part
of the work. For example, Corresponding Source includes scripts used to
control those activities, interface definition files associated with the
program source files, and the source code for shared libraries and
dynamically linked subprograms that the work is specifically designed to
require, such as by complex data communication or control flow between
those subprograms and other parts of the work.
The Corresponding Source also includes any encryption or authorization
keys necessary to install and/or execute modified versions from source
code in the recommended or principal context of use, such that they can
implement all the same functionality in the same range of circumstances.
(For instance, if the work is a DVD player and can play certain DVDs, it
must be possible for modified versions to play those DVDs. If the work
communicates with an online service, it must be possible for modified
versions to communicate with the same online service in the same way such
that the service cannot distinguish.) A key need not be included in cases
where use of the work normally implies the user already has the key and
can read and copy it, as in privacy applications where users generate
their own keys. However, the fact that a key is generated based on the
object code of the work or is present in hardware that limits its use
does not alter the requirement to include it in the Corresponding Source.
[/QUOTE]
execute modified versions from source code in the recommended or
principal context of use" includes access keys that would allow you to
access your phone thru your GSM operator in the scenario you described
because those are "necessary to install and/or execute..."
> IMHO, "any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use" includes access keys that would allow you to access your phone thru your GSM operator in the scenario you described because those are "necessary to install and/or execute..."I don't think you're right...
I do think that this is a real problem. THe current language ONLY affects cases where the installation of updated code is restricted by encryption. There are many other hardware or software ways to make it impossible, and the current language would not block any of them.I don't think you're right...