BT Home Hub: Continued violation

[Arnoud Engelfriet]

Alexandre Oliva wrote:
> On Apr  9, 2008, Arnoud Engelfriet <arnoud at engelfriet.net> wrote:
>> Nothing in GPLv2 requires me to enable others to "produce a binary
>> that is accepted by the device" on which my original binary
>> resides. I'm required to give out source code and scripts used to
>> control compilation and installation.
>  
> It requires you to provide *complete* corresponding source code.

So? A key used to generate a signature on an executable is not part of the 
source code

>   The source code for a work means the preferred form of the work for
>   making modifications to it.  

What programmer prefers access to ~/.gpg/secring.gpg to modify the source code 
of a program? He may prefer to have access to that key in order to install the 
compiled binary, but that's not what the definition above is talking about.

> I don't see any exclusion whatsoever for keys used in the process of
> creating the distributed executable.  On what grounds should it not be
> regarded as source code, and if so, what else could be excluded under
> this excuse to omit essential portions of the source code?

I don't see any statement in the definition that unambiguously covers signature 
keys.

>> The codes are not source code
> 
> Why not?

Because they are 160 bits of random data that no programmer needs to modify.

> If you wanted to modify the executable work that happens to be on the
> machine in which you received it, would it not be preferrable to have
> the keys, so as to be able to generate a functional executable?

I can generate a functional binary just fine without that secret key. I just 
can't *install* that binary. Nothing in the GPLv2 definition of CCSC refers to 
keys necessary for installation.

> I'm not sure either, but IIUC first you were talking about keys needed
> to produce a binary that is accepted by the device, then you changed
> it to produce a binary.

I never intended to refer to keys necessary to produce a binary. I'm not even 
sure how that would work. But to clarify: I'm talking about keys that generate 
digital signatures for files, which signatures are verified by some external 
module when you try to execute that file.

A simple example would be a file /bin/ls.authcode that contains the 
authorization code of /bin/ls. Generating this authcode file requires an MD5 of 
/bin/ls as well as ~/.gpg/secring.gpg. Please explain how ~/.gpg/secring.gpg is 
part of the CCSC for /bin/ls. As far as I can tell all the source is in 
/usr/src/coreutils/ls

>> Do you think Tivo could legally use signed GPLv3 kernels if they
>> offered a sandbox (virtual machine) in the device where you could
>> install and run modified versions of that kernel, but without actual
>> access to the hardware? That's a pretty neat workaround.
> 
> I don't think so, and this is the bit that's supposed to prevent this:
> 
>   The information must suffice to ensure that the continued
>   functioning of the modified object code is in no case prevented or
>   interfered with solely because modification has been made.

I was triggered by that word "continued". That suggests to me I should be able 
to *replace* the original object code with the modified object code.

Arnoud
PS: by the way, who or what is changing the lists.gpl-violations.org domain to 
narasimha.gpl-violations.org ? I'm not sure what's going on but I keep getting 
bounces when trying to mail to narasimha.
-- 
Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
               Arnoud blogt nu ook: http://blog.iusmentis.com/