Re: Linux and GPLv2
Scripsit Humberto Massa <humberto.massa@almg.gov.br>
> Henning Makholm wrote:
>> 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.
> Well, this is kind of easy to explain.
Snip "explanation" that does not do anything the idea that bits are
treated differently by copyright just becuase they are in a file
called .h.
> >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.
> They are not being included by the author, in a creative --
> intelectually-novel -- process; they are being included by the
> compiler/linker in an automated/automatable process.
So what? They are being reproduced, and the mechanicalness of the
reproduction does not prevent copyright from applying to the result.
> Nothing that comes out of an automated process is *per-se*
> copyrightable.
Do you still think this applies if the automated process is an offset
press?
> Obviously, something that comes out of an automated
> process and is equivalent (repeatable result of processing of) a
> copyrightable work is, to the eyes of the law, the unprocessed work
> itself
No, it's a processed work. Which is still coverved by the copyright of
the original work.
> >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).
> Looking from a legal standpoint, the compiler and linker are tools
> like the binding machine in a book factory: they just transform and
> stitch together things (imagine the manufacturing of an anthology
> book) but they realize no transformation on the work itself. They do
> not affect copyrights.
Exactly. The copyright of the original function definition is *not*
affected by its having been placed in a .h file somewhen in the process.
> Concluding: when you write a ".c" file, it is or not a derivative work
> on another original work independently of what the compiler and linker
> will do in the future.
I repeat: No, but the resulting .o file may be derived from another
work that the compiler also read while producing it.
> The output of a compiler/linker is related to the source code as the
> ready-to-be-sold-in-the-bookstore book is related to the original,
> typewritten, version of one of the novelettes inside the book.
Yes. And if I want to reprint the entire book it may well be that I
need the permission not only of the author byt also of the guy who
wrote the preface.
> Trying to explain more: my "myfile.c" is not a derivative work
> on "errno.h",
No, but myfile.o may be. (I feel like I'm repeating myself here).
> Now, just to make my self more clear, when you do a derivative work,
> then you are transforming something -- akin to Peter Jackson
> transforming the works of Tolkien. You had something -- a series of
> books -- and you got other thing in the other extremity -- a series of
> screenplays, plus casting instructions, storyboards, etc. The second
> series of stuff (derivative) came out of the spirit of Peter Jackson,
> but resulted of transformation (novel, intellectual) of the works of
> Tolkien.
I do not see how that has anything to do with the supposed magical
copyright-evading capabilities of filenames that end in .h.
--
Henning Makholm "No one seems to know what
distinguishes a bell from a whistle."
Reply to: