BT Home Hub: Continued violation
Arnoud Engelfriet
arnoud at engelfriet.net
Sun Apr 13 19:18:55 CEST 2008
Alexandre Oliva wrote:
> On Apr 12, 2008, Arnoud Engelfriet <arnoud at engelfriet.net> wrote:
>> 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"
>
> Not if it's third-party, as above.
I'm not sure what "third-party" means here. I certainly didn't write
/usr/include/stdio.h, but I can add an #include for it in your GPLv2 program.
Still, I don't have to give my downstream recipients my /usr/include/stdio.h
since it's covered by the exception.
>>>>>> 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.
>
> This is at odds with your statement about included header files
> above.
How so? The signature is not #include'd in the source. The header file is. That
makes the difference.
> Whether someone would want to modify it is irrelevant. It is source
> code because it is needed by the builder.
No, it is source code if it is covered by the definition of source code.
>> 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'.
>
> As in, when you compile a .c file that includes a .h file from a
> separate library, do you still find traces of both in the derivative
> executable?
If nothing from the .h file ends up in the executable, then no the executable is
not a derivative of the .h file.
> When you convert an image, or an audio or video stream, using
> resizing, resampling, compression and encryption, and put it together
> with other such creative works, do you still find traces of both in the
> derivative work?
I'm not sure where you are getting at with these examples. The rule of copyright
law is that something is a derivative if copyrighted parts of an old work end up
in the new work. It doesn't have to be literally identical, e.g. a German
translation of an English poem is also a derivative work of the poem. But if you
can find no trace of the English poem in the German poem, it's not derivative.
>> The logical conclusion is that if anyone produces a digital
>> signature for any GPL binary, they have to publish the secret
>> signature key.
>
> Not quite. It depends on whether the signature is software. It
> depends on context. On meaning and purpose.
>
> If it's interpreted by the computer so as to guide its decision on
> whether or not to permit the execution of a program, then it is
> software.
I publish a digital signature for Linux kernels I approve 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 me. Do I now have to give everyone
my secret signature key?
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?
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/
More information about the legal
mailing list