How To Break The GPL

[Mark Wells]

On Sat, 4 Mar 2000, David Johnson wrote:

> We definitely need to define the term "derive", both in the copyright sense,
> and as it applies to code. My Dodge automobile works with my Bridgestone tires,
> but it is hardly derivitive of the tires :-)
> 
> A sometimes useful tool of logic is to take something to it's absurd extreme.
> If everything that *works* with some piece of code is derived from that code,
> then everything in my current OS distribution is ultimately derived from
> Linux and Glibc!

And Linux and glibc are derived from the Intel (or whatever) architecture.  
The problem is that they're also derived from the Alpha architecture, the
Sparc architecture, and the PowerPC architecture.  And since GCC runs on
Linux, it's derived from Linux, which is very interesting when we consider
that GCC is used to _compile_ Linux.

Therefore, by _reductio ad absurdum_, we've shown that linking to a
library is not derivation.  Wasn't that simple?

Unfortunately, while taking a principle to extremes is useful in logic,
it's somewhat less effective in law.  The courts frequently overrule logic
in favor of what seems right to them.

> > If a body of software has it's 
> > direct funcionality added to, modified or changed, then the resulting outcome 
> > should become part of the body of software in terms of copyright and licensing. 
> 
> I would agree with everything expect for the "added to" part. In code terms, it
> may very well be derivitive, but it hardly demands an identical copyright or
> license. As an example, neither the GTK nor the Qt libraries require that
> additional widgets be handed over to GNU or TrollTech, or even use their
> licenses.  It is only in the area of GPL libraries that there exists a problem.

It's easy to distinguish between 'libraries' and 'applications' on
technical grounds when we're talking about code written in C and compiled
into machine code.  It becomes substantially more difficult when we extend
it to other languages.

I'm not just talking about the run-time vs. compile-time linking question
that's important for Java and Perl.  What about a shell script?  You might
call 'grep' an application, but if I use it to perform some task in a
shell script it's acting more like a library.  (And my shell script itself
might be a library from the perspective of other applications that pipe
data through it.)

Let's go back to Alice, Bob, and Trent for a moment.  Alice writes a
proprietary application that uses a shell script for something (such as an
installation utility), and the shell script uses the 'grep' library
somewhere.  She sells a license for this application to Bob.  When he
installs it, the shell script calls 'grep' on his machine.  He has a GPL
version of 'grep', and here's this EEEEEVIL proprietary shell script
linking to it!  Shame on you, Alice!  You're trying to make an end-run
around the GPL, aren't you?

Isn't this completely within Alice's rights?  Do we really need to split
hairs about whether Alice's own machine has the GNU version of 'grep' or
some other version?  If Trent sues Alice for linking to his GPL'd library
in violation of the license, would the judge be able to stop laughing long
enough to announce the summary dismissal?