From: "D. Hazelton" <dhazelton@enter.net>
To: "Michael K. Edwards" <medwards.linux@gmail.com>
Subject: Re: GPL vs non-GPL device drivers
Date: Wed, 21 Feb 2007 23:17:16 -0500
User-Agent: KMail/1.9.5
Cc: "David Lang" <david.lang@digitalinsight.com>, davids@webmaster.com,
       "v j" <vj.linux@gmail.com>, trent.waddington@gmail.com,
       "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
       "Neil Brown" <neilb@suse.de>
References: <3d57814d0702191458l1021caeyaefd7775398c5f2a@mail.gmail.com> <200702212030.58317.dhazelton@enter.net> <f2b55d220702211805h6df0b342o7676e37c7aa43bdd@mail.gmail.com>
In-Reply-To: <f2b55d220702211805h6df0b342o7676e37c7aa43bdd@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200702212317.16262.dhazelton@enter.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 6616
Lines: 114

On Wednesday 21 February 2007 21:05, Michael K. Edwards wrote:
> On 2/21/07, D. Hazelton <dhazelton@enter.net> wrote:
<snip>
> > 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.

Actually, on re-reading the GPL, I see exactly why they made that pair of 
exceptions. Where it's quite evident that a small to mid scale parsers that 
could have been written *without* the use of Bison is clearly a 
non-derivative work - Bison was not required, but was used as a mean of 
expediency. When you reach a large scale parser, such as one that meets all 
requirements to act as the parser for an ANSI C99 compiler, Bison stops being 
expedient - it'd likely take just as much time to hand craft the parser as it 
would to debug the Bison input. However, it makes maintaining the parser 
easier.

But the fact is that it's the small to medium scale parsers that have a lower 
ratio of original to GPL'd code that are at risk of being declared derivative 
works. All of this because the GPL contains the following text in section 0:
"The act of running the Program is not restricted, and the output from the 
Program is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does."

That clause, to me, seems specifically tailored to cover programs such as 
Bison and Flex. (and is the reason that I try to use Byacc and when I need 
to, write tokenizers by hand) This frankly stinks of attempts to cover all 
possible code. (I actually started studying Copyright law in my free time 
because I was wondering how legal the GPL was and was also puzzled by some 
major online entities actually complaining about it)

> 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.

Since I tailor the license I apply to code I produce to meet the needs of the 
person or entity I am writing it for, I've never run into this. In truth, the 
LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under 
the GPL you no longer have a legal right to it. Note the following text that 
appears in the GPL:

"  We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software."
--IE: Once you release the code under the GPL, it becomes the *copyrighted* 
*property* of the FSF and you are just another person that the GPL is applied 
to. This means that if you later change your mind and decide to revoke the 
GPL on your code and replace it with say, the Larry Wall's "Artistic License" 
you are breaking the terms of the GPL and therefore lose all rights to modify 
and distribute your code.

A similar clause appears in the LGPL:
"We protect your rights with a two-step method: (1) we copyright the library, 
and (2) we offer you this license, which gives you legal permission to copy, 
distribute and/or modify the library."
-- In this case I think the first item is bogus - the "library" is generally 
considered to be the compiled version of the source. Since it is the product 
of a machine translation it *cannot* be copyrighted. What it actually means 
is they copyright the "human readable machine source code" of the library - 
at which point the bad things I've pointed out about the standard GPL become 
true.

> > 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.

Will do. Now I think I'll get back to work on a private project that I've got 
in front of me. (When I release it the code will not be under *any* of the 
various GNU/FSF licenses - I'll probably wind up crafting one specifically 
for the project)

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