Linus was always bitchy... [LWN.net]

Linus was always bitchy...

Posted Sep 27, 2006 21:06 UTC (Wed) by ibukanov (subscriber, #3942)
In reply to: Linus was always bitchy... by alexbk
Parent article: Why Torvalds is sitting out the GPLv3 process (Linux.com)

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.

to post comments

Linus was always bitchy...

Posted Sep 27, 2006 21:18 UTC (Wed) by alexbk (subscriber, #37839) [Link] (6 responses)

Not necessarily: the phone and the box have to know which server to query for updates. Make that
configurable (a software problem!) and provide server-side tools (also a software problem!).

A real example: latest Nokia phones allow users to update their firmware themselves. You can either
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.

Linus was always bitchy...

Posted Sep 27, 2006 21:40 UTC (Wed) by ibukanov (subscriber, #3942) [Link] (5 responses)

> Make that configurable (a software problem!)

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?

Linus was always bitchy...

Posted Sep 27, 2006 21:50 UTC (Wed) by alexbk (subscriber, #37839) [Link] (4 responses)

Can you give an example of hardware that has no input channels for end-user configuration at all?
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.

Linus was always bitchy...

Posted Sep 27, 2006 22:07 UTC (Wed) by ibukanov (subscriber, #3942) [Link] (3 responses)

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.

Would you like for GPLv3 to prevent such device from existence?

Linus was always bitchy...

Posted Sep 27, 2006 22:10 UTC (Wed) by ibukanov (subscriber, #3942) [Link] (1 responses)

> Would you like for GPLv3 to prevent such device from existence?

Correction, I wanted to say:

Would you like for GPLv3 to prevent such device from running GPLv3 code?

Yes.

Posted Sep 27, 2006 23:40 UTC (Wed) by hummassa (guest, #307) [Link]

Unless your server could be blessed with the same ssl certificate so you
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.

Because if we don't, everyone will begin to make DRMd hardware and
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".

Linus was always bitchy...

Posted Sep 27, 2006 22:51 UTC (Wed) by alexbk (subscriber, #37839) [Link]

Uh, which kind of radio, exactly? I can't think of any kind where your example wouldn't fall apart.

I don't think you're right...

Posted Sep 27, 2006 23:35 UTC (Wed) by hummassa (guest, #307) [Link] (2 responses)

Here is the "offending" GPLv3 paragraphs:

[QUOTE]
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]

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...

Posted Sep 28, 2006 2:32 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (1 responses)

> 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..."

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.

I don't think you're right...

Posted Sep 28, 2006 15:01 UTC (Thu) by sepreece (guest, #19270) [Link]

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.

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.