Re: GPL vs non-GPL device drivers

From: Michael K. Edwards
Date: Wed Feb 21 2007 - 21:06:18 EST


On 2/21/07, D. Hazelton <dhazelton@xxxxxxxxx> wrote:
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.

Absolutely. But not the toolchain, just the "scripts". This is part
historical, since after all GNU got started when Sun started to
monetize its toolchain independently of its O/S, RMS got annoyed
enough to kick off another cloning project, and more competent
compiler people caught on to the economic opportunity. Ever pay $5K
for a CD full of GNU binaries for a commercial UNIX? I did, after
deciding that getting all their shit to compile was more Morlock-work
than I was up to. So like I say, it's part historical -- RMS didn't
want to owe me a copy of Sun's toolchain along with that CD -- but
it's no accident that it's still in there, because THAT'S HOW CYGNUS
MADE MEGABUCKS.

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.

Of course. The FSF smokescreen around "derivative work" exists not
only to frighten potential commercial users of GPL libraries but to
squelch people like Eric A. Young (principal OpenSSL author) who have
the presumption to retain their own copyrights. Eric has a quite
solid case (IMHO, IANAL) against the FSF and Eben Moglen personally
under at least three different U. S. antitrust and racketeering laws,
and it would be really entertaining to watch him take it up.

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.

Half true. It's not a derivative work exactly, but it could
conceivably be held to infringe against the copyright in Flex/Bison,
if you could prove that the amount of _creative_expression_ copied
into the output exceeds a "de minimis" standard and doesn't constitute
a "fair use". Those nifty photomosaics would probably infringe
against the photographers' copyright in the photos they're made up of,
if they weren't licensed through the graphic industry's "stock photo
archive" mechanism. You could probably defend on "fair use" with
respect to Flex/Bison and the vanilla GPL, since the fact that I can
get some random program with a parser in it from you without needing
my own copy of bison doesn't cost the FSF anything. But it's a
gamble, especially if that random program competes with something the
FSF makes $$$ off of; and I'd want that extra bit of estoppel in my
back pocket.

The LGPL is a very different story. It's not just GPL with extra
estoppel, it's a booby trap. It goes a lot farther to put over its
own perverse definition of "derivative work", and it tries to compel
you to provide all the "data and utility programs needed for
reproducing the executable from it". I don't use the LGPL for my own
work, I wouldn't touch it with a ten-foot pole if it didn't have the
"GPL upgrade" clause in it, and I advise my employers and consulting
clients to go through the "GPL (v2 only!) upgrade" rigmarole with
respect to anything they so much as recompile. They don't all take
that advice, but that's not my problem.

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.

Ditto. If you see a mistake in something I write, please please
pretty please point it out, in public -- I am not a lawyer, absolutely
everything I say could be wrong, and I don't really want these
messages lying around without the context of every rebuttal anyone in
the audience can think of.

Cheers,
- Michael
-
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/