Re: Linux and GPLv2

[Måns Rullgård <mru@inprovide.com>]

Henning Makholm <henning@makholm.net> writes:

> Scripsit Humberto Massa <humberto.massa@almg.gov.br>
>> Matthew Palmer wrote:
>
>>> > Basically, ".h" bits are *not* copyrightable.
>
>>>  Under what theory do you come to that conclusion?  Note that a .h
>>>  file can contain more than function prototypes, and function
>>>  prototypes don't have to be in a .h file.
>
>> Whoa, slow down, cowboy! Re-read what I have written up there: <<".h"
>> _bits_ are not copyrightable>>. Now take a deep breath.
>
> Deep breath taken. I still want to know why you think bits are treated
> differently by copyright just because they happen to be in a file
> whose name ends in .h.

Obviously, the precise name of the file is irrelevant.  What counts is
that the file forms the definition of an interface.

>> The thing is: it is considered by USofA and other countries case law
>> that the bits that are at compile/link time from a .h file (as you
>> mentioned down here, as macros and inline functions) are not really
>> being "included" in the work, but are in reality being "referenced"
>> on it.
>
> Inline functions are certainly being included in the machine code that
> comes out of the compiler, at least if they are called by the rest of
> the compilation unit.

Irrelevant.  If someone chooses to implement a particular interface
using an inline function, that should not impact the derivedness of
code using the interface.

>>   extern char **__err_msgs;
>>   #define perror(s) (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno]))
>
>> Is "myfile.c" a derivative work on "errno.h"? The answer is NO.
>
> Of course. But myfile.o might have been if perror() were complex
> enough to leave any room for expressive choice.

Again, irrelevant.  If your implementation puts things in macros,
that's your problem.

>> In the Abstraction, Filtration, Comparison process, bits that come
>> from a ".h" by way of its interface (as opposed to "by way of its
>> implementation") are filtered OUT in the filtration phase.
>
> The compiler does not even know which bits in it input come from .h
> file and which come from a .c file. It has no means of filtering on
> them specifically. (Well, excluding #line markers, but they should
> *not* influence the machine code being generated).

Are you even trying to be serious?

-- 
Måns Rullgård
mru@inprovide.com