lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2b55d220702211805h6df0b342o7676e37c7aa43bdd@mail.gmail.com>
Date:	Wed, 21 Feb 2007 18:05:55 -0800
From:	"Michael K. Edwards" <medwards.linux@...il.com>
To:	"D. Hazelton" <dhazelton@...er.net>
Cc:	"David Lang" <david.lang@...italinsight.com>, davids@...master.com,
	"v j" <vj.linux@...il.com>, trent.waddington@...il.com,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	"Neil Brown" <neilb@...e.de>
Subject: Re: GPL vs non-GPL device drivers

On 2/21/07, D. Hazelton <dhazelton@...er.net> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ