BT Home Hub: Continued violation

[Arnoud Engelfriet]

Alexandre Oliva wrote:
> On Apr 13, 2008, Arnoud Engelfriet <arnoud at engelfriet.net> wrote:
>> How so? The signature is not #include'd in the source. The header file
>> is. That makes the difference.
> 
> I think you meant key, not signature.  The signature is object code,
> not source code.

No, I meant signature. The signature is not part of the source code, nor is it 
part of the compiled and linked executable. I guess you could compare it to the 
configuration file or maybe the README. It's coming along with the program but 
it just sits there when the program executes. The program does not read or touch 
the signature file.

> ACK on the difference.  I guess you could put the key as part of the
> build machinery, like a configuration file that configures one of the
> build tools.  Like a Makefile, that configures make and various other
> programs through command-line options present in it, or a linker
> script, that configures the linker to combine object files into an
> executable in a certain way, the key file configures the signature
> generator to process object code in a certain way so as to produce the
> signature.

Ehm, what I would do would be to simply take the final executable and generate a 
signature from that. I don't think I would do that from the build script.

> For the sake of the argument, consider that the signature is part of
> the executable it applies to.  (If it is separated just to escape the
> conditions of the GPL, then the argument that this is just an excuse
> to escape from the license applies)

But it is not! It's a separate file. At best it is distributed in the same 
tarball. Are README and COPYING part of the executable in a binary tarball?

How about the scenario where I create signatures for other people's binaries?

> Now, what is the most convenient form to modify the signed executable?

The GPLv2 only requires me to publish what is necessary to modify the 
executable. It says nothing about authorization codes associated with the 
executable.

Suppose I want to modify the version of Linux that Linus Torvalds has signed. 
Can I ask him his signature key?

> Surely you need the source code for the unsigned binary as well as the
> key that generated the signature, otherwise you may succeed in
> modifying the unsigned binary, but not the signed binary, and
> specifically not in adjusting the signature in it such that it is
> verifiable.

That is in itself correct, but you're reasoning backwards: you want to create a 
new signed binary, therefore the signature key must be part of the source. But I 
take the position that you must look at the definition of source code and see 
from that whether the signature key can be considered a part of it.

I can't find any language in GPLv2 that I can interpret to cover someone's 
signature key with which to create authorization signatures.

>> If nothing from the .h file ends up in the executable,
> 
> That's quite a bold assumption you made.  :-)

I'm old-fashioned. Code does not belong in header files. But yes, macros, 
structs and lots of inline code may exist in header files.

> I meant the executable carried stuff from both, but certainly not in
> source code form, i.e., not literaly, but rather in a significantly
> transformed way, even if the transformation was completely mechanical.

Absolutely.

> For sure you won't find the comments.  Even if they're most of the .c
> or .h files, the compiler will discard them.  Does this mean the
> comments are not source code?  Or that you can strip the comments from
> the source code before redistributing the corresponding source code of
> an executable you've received with complete corresponding source code?
> I don't think so.

You are correct, because source code with stripped comments is not the preferred 
form for modifying that source code.

On the other hand, if there is a .c file that isn't compiled/linked into the 
executable, then that .c file is not part of the source for that executable.

> I'm presenting progressively relaxed notions of traces from the
> original that AFAIK are all derived works, the last of which being a
> digital signature.

Right. But the digital signature has no recognizable trace of the original in it 
anymore. It's a lossy transformation.

>> Linus Torvalds publishes a digital signature for Linux kernels he
>> approves of. I build a computer with a BIOS that verifies digital
>> signatures for Linux kernels, and only boots the kernel if the
>> signature is valid and from Linus. Does Linus now have to give
>> everyone his secret signature key?
> 
> IMHO, no, unless he's colluding with you, or he starts adding those
> signatures with the purpose of enabling the kernels to work on your
> device.

I am having great difficulties with the argument that it matters *who*
creates the signature. If a signature is part of the CCSC, then surely it
doesn't matter who wrote it?

In any case, it seems we're not getting any closer with our respective arguments.

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/