lkml.org 
[lkml]   [2007]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: GPL vs non-GPL device drivers
Date
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/

\
 
 \ /
  Last update: 2007-02-22 05:21    [W:0.272 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site