Re: GPL vs non-GPL device drivers

[D. Hazelton]

On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote:
> I think you just misread.  I said that the Evil Linker has cheerfully
> shipped the source code of the modified POP server.  He may not have
> given you the compiler he compiled it with, wihout which the source
> code is a nice piece of literature but of no engineering utility; but
> that's the situation the GPL is DESIGNED TO PRODUCE.

Actually, if memory serves, when you license a work under the GPL, part of the 
terms is that you have to provide the source and any scripts needed to 
produce a functioning executable.

*checks a local copy of GPLv2 for the exact wording*

Third clause of the license:
"For an executable work, complete source code means all the source code for 
all modules it contains, plus any associated interface definition files, plus 
the scripts used to control compilation and installation of the executable."

So yes, someone could produce a work that compiles on a specific compiler, but 
there is then nothing stopping someone from fixing the problems that cause it 
to not compile using another compiler and releasing that source code - 
distributing it as a patch, AFAICT, falls outside coverage by the GPLv2. The 
build tool-chain, libraries and other works that are not a direct part of the 
program produced by compilation of the source code. (the wording of the GPL 
is: "However, as a special exception, the source code distributed need not 
include anything that is normally distributed (in either source or binary 
form) with the major components (compiler, kernel, and so on) of the 
operating system on which the executable runs, unless that component itself 
accompanies the executable.")

As a side note: The distinct wording of the GPL actually *invalidates* the 
GNU/FSF claim that dynamically linking a work with, say, the readline 
library,  means the work is a derivative of said library. The GPL states (in 
clause 0) that the license only covers copying, modification and 
distribution. Unless they are confusing "Linking" with "copying" or "creating 
a derivative work" the claim is invalid - because, as it has been shown, a 
mechanical process such as compilation or linking *cannot* create a 
derivative work.

Related to that... Though a parser generated by Bison and a tokenizer 
generated by Flex both contain large chunks of GPL'd code, their inclusion in 
the source file that is to be compiled is mechanical - the true unique work 
is in writing the file that is processed by the tool to produce the output. 
Since the aggregation of the GPL'd code into the output source is done 
mechanically - via mechanical translation (which is what compilation is as 
well) - the result is *not* and under US copyright law *cannot* be a 
derivative work. What this means is that the GNU/FSF "special" terms applied 
to parsers generated by Bison and tokenizers generated by Flex is 
unnecessary - they are granting you a right you already have.

Anyway, it's been fun watching this thread. If I've made a mistake somewhere 
in there, let me know - IANAL and I am just starting to really get into the 
meat of Copyright and related laws in independant study.

DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/