Linus was always bitchy...
Linus was always bitchy...
Posted Sep 27, 2006 20:49 UTC (Wed) by ibukanov (subscriber, #3942)In reply to: Linus was always bitchy... by hummassa
Parent article: Why Torvalds is sitting out the GPLv3 process (Linux.com)
> _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.
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.
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...