Re: Linux and GPLv2
Henning Makholm wrote:
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.
Repeating: bits that are in files called .h are not copied in your work,
so your work is not a derivative work of the .h by way of copying it.
The compiled executable may or may not be an anthology work containing
the contents of the .h. It's not the magical fact that the file is
ending in .h (or .inc). It's the fact that you do not transform it, so
you do not create a derivative work.
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.
But the relationship of the result WRT the individual copyrights is
different than many people (including who wrote the damned "do not link"
paragraph in the GPL) expect.
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?
Yes. The copyright does not apply to the printed book /per-se/... it's
applied to the intellectual content (the original creation of spirit).
Imagine I make a program that prints random words. The result is not
copyrightable, even if it makes any sense at all.
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.
What you are calling a processed work is just another "face" of the same
work; as a matter of fact, my copy of linux/errno.h and your copy of
linux/errno.h are THE SAME WORK (not considered two different copies,
unless you want to talk about the cost of copying... which is another
subject altogether)
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.
We seem to agree on this, but...
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.
Not derived. Never. To derive you need inteligence (in Brazilian
letter-of-law, "spirit"). A compiler does not have it. Neither does a
linker. Only a person does.
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.
Yes. These are the rules for anthology works.
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).
An anthology work, maybe, a derivative work, never. That's the part you
seem not to be understanding. The rules for anthology works and
derivative works are different. The "division" or "difusing" is
different in each case:
Anthology work: the act of choosing/selecting/ordering 2+ different
works *is* the intellectual act
A = B + C + W
where B and C are original works and W is the work of thinking, hmmm, an
anthology having B and C in this order would be cool.
license of A = independent;
activities (copy, derivation) on A are only restricted by licenses of B
and C to the extent that you are doing (copy, derivation) on B and C.
For instance, to make another anthology with B, C and E, you only have
to abide to the license of A (IRT the anthology as a whole -- you will
have to abide to the license of B, C, and E IRT the copy of each that
you will put in the anthology)
Classical example: NDIS driver using the GPLd adapters to the Linux
kernel. If you distribute a kernel with the NDIS driver on it, you are
making an anthology work. Neither the NDIS driver is a derivative on the
kernel, nor the other way around.
Derivative work: the act of transforming one work in another.
D = O + O.patch
the real work is summarized in O.patch (as defined by kernel hackers).
O.patch is, also, a derivative work on O. The copyright and the license
of O.patch *and* D are limited by the license you have to make
derivative works on O.
Classical examples: sucessive versions of the same program.
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.
This is an artifact of your imagination... I said only that, in general,
the *usual* .h does not contain copyrightable bits. And I suspect you
know I meant this, but you are trolling, because you ignored the
/per-se/ when I tried to explain myself. You can write poetry in .h
files, and said poetry will remain copyrightable. What I said is, IOW:
ABIs and APIs do not, as a general rule, contaminate the copyright of
their users.
If you are not trolling, I apologize, as I apologize for my crappy
English. But understand, the GPL has far less power over anthology works
that contain a GPLd work than it has over derivative works.
Maybe I helped now?
Massa
Reply to: