Re: Linux and GPLv2
Henning Makholm <email@example.com> writes:
> Scripsit Humberto Massa <firstname.lastname@example.org>
>> 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?