Re: Linux and GPLv2
Henning Makholm wrote:
>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.
>
>Well, of course bits in general are not copyrightable. The digits 0
and 1 are everybody's property. A particular sequence of bits can,
however, form a copy of a copyrightable work.
Well, this is kind of easy to explain. Imagine that copyright is a right
(a reserved, time-limited [?] monopoly) on something *your* spirit
created. Ok? The law -- letter of law and case law -- restricts the
rights in some cases. /In/ /casu/, there are two pertinent limitations:
one, you cannot own the copyright to an API; two, any person can use
your work in their work to make citations (also, but not pertinent to
the case, parody, commentary, etc -- "fair use". So, your spirit can
create stuff and put it on writing, but you do not own -- or better yet,
you are not entitled to exert your monopoly in some conditions -- IRT
that creation.
Well, my point is: in the software development process -- and more
specifically in the C software dev process -- the author of a program
".c" that "#include"s a ".h" file is not copying the ".h" bits, but
making references to them. More below...
>>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.
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. Nothing that comes
out of an automated process is *per-se* copyrightable. 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 (or better yet, just a
copy... imagine I get page 11 of a book and Xerox it, magnifying it by
200%; it's not identical to the original, but it's still a copy).
>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.
If the author of one of the novelettes in an anthology did not gave to
the publishing house permission to publish it, it does not make any
difference if they used the hardcover or paperback, if they put it first
or last in the book, nor if they interspaced each line of the novelette
with one line of another work. The "binding machine" does not affect
this. The work is the original, handwritten/typewritten work that came
out of the author's mind.
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. That's why "abstraction, filtration, comparison"
are operations to be done on SOURCE CODE. 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. Trying to
explain more: my "myfile.c" is not a derivative work on "errno.h",
independently of the definition of perror() being a macro, an inline
function, or just a function prototype to be fulfilled at link-time (or
even possibly at run-time, in case of dyn linking). OTOH, my "myerrno.h"
is a derivative work anyway... it's an improvement and so a
transformation of the original "errno.h".
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.
When you make references to an ABI/API, you are using the limitations of
copyright to the original author, and "#include <stdio.h>" does not make
a copy, but references to what usually is an ABI/API.
Can a person put all of its program in a ".h" file and so, make any
program "#include"ing it a derivative work? Yes, but if said program
does not transform the original work but only make references to it,
then what you have is the limitations on copyright.
HTH,
Massa
Reply to: