BT Home Hub: Continued violation

[Arnoud Engelfriet]

Alexandre Oliva wrote:
> On Apr 10, 2008, Arnoud Engelfriet <arnoud at engelfriet.net> wrote:
>> I don't see any statement in the definition that unambiguously covers
>> signature keys.
> 
> Do you see anything that covers say third-party header files installed
> in /usr/include?

If you #include a header file, then the header file is part of the source code. 
I need that header file if I want to recompile the source code to produce that 
same binary. Therefore you have to include a copy of every header file you 
#include.

Fortunately the contents of /usr/include is covered by the "anything that is 
normally distributed ... with the major components ... of the operating system 
on which the executable runs". Therefore you do not have to include a copy of 
the header files from /usr/include.

>>>> The codes are not source code
> 
>>> Why not?
> 
>> Because they are 160 bits of random data that no programmer needs to modify.
> 
> How is this derived from the definition of source code in the license?

"The source code for a work means the preferred form of the work for
making modifications to it." No programmer needs, let alone prefers, 160 bits of 
random data in a separate file in order to make modifications to .c files. The 
160 bits are in fact utterly irrelevant to the .c files.

>> I can generate a functional binary just fine without that secret
>> key. I just can't *install* that binary.
> 
> How is that functional, then?

The binary is fully functional. The environment isn't. But that's not the 
problem of whoever created the binary. I can't install your Linux executable on 
my OS/2 system (yes, I have one). Surely having an OS/2 system is my problem, 
not yours.

> At first, you talked about a distributed executable that included a
> signature.

As I wrote in my previous message, that's not what I wanted to say and I 
apologize if I gave that impression anyway.

> Now, you seem to be talking about some different authorization that is
> part of the installation process only, that doesn't involve a
> signature that is part of the distributed executable.

That is the only case I am interested in. So let us focus on this case.

>> 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.
> 
> It is not.
> 
> But it is part of the CCSC of the combination ls and ls.authcode.
> ls.authcode is the result of combining ls and secring.gpg.

It's the result of combining the MD5 of ls with secring.gpg. I very much doubht 
that the MD5 of a file qualifies as a derivative work of that file. To be a 
derivative, you have to find traces of the work in the 'derivative'.

I also have big problems with this argument for other reasons. The logical 
conclusion is that if anyone produces a digital signature for any GPL binary, 
they have to publish the secret signature key. That would make it quite 
impossible to do any kind of origin authentication of GPL source code.

> I still haven't been able to get any e-mail into the archives.  I
> guess people in the list are only seeing your replies :-(

Well, I just manually change narashima back into 'lists' and it seems to work.

Arnoud

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