Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Humberto Massa <[EMAIL PROTECTED]> >> 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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
