[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Combining proprietary code and GPL for in-house use



On Wed, Jun 27, 2001 at 10:55:58PM -0400, Raul Miller wrote:
> On Thu, Jun 28, 2001 at 12:40:45PM +1000, Anthony Towns wrote:
> > What if Debian, White Knight of Free Software, distributes A (a GPLed
> > library) and obeys the GPL completely, and doesn't distribute anything
> > non-GPLed which links to it at all; but FooCorp, Evil Geniuses that they
> > are, makes an apt source and distributes B .debs which can happily link
> > to A as distributed by Debian [0].
> linking creates a derivative work.
> creation of a derivative work is regulated by copyright.

FooCorp doesn't do any linking with GPLed code in these
scenarios. Further, the linking is only done on the users machine, in
a manner explicitly allowed by the copyright holders of both pieces
of code (the GPL allows you to do pretty much whatever if you don't
distribute; and we can presume FooCorp doesn't mind you linking with A
in the hypothetical).

> in this case, you're describing the creation of a derivative work which
> violates the license on the original work.

No, I'm describing the creation of a derivative work in a manner that
violates the spirit of the license on the original work, but appears
not to violate the letter.

> > In particular, you'll note that in this scenario FooCorp doesn't
> > distribute *any* GPL'ed code themselves, and in the alternate
> > scenarios they don't even need to have the GPL'ed code on their
> > systems at all.
> They're distributing a work derived from GPL'd code.  [They're supposedly
> granting users the right to use such a work.]

I'm curious how you create a derivative of something you've never seen
nor used.

For concreteness, let's assume that "A" is an SSL/TLS library, and "B" is
some random SSL using thing, maybe a non-free application for accessing
your bank account. We can use gnutls for the GPL implementation of A, and
OpenSSL for the non-GPL implementation of A.

For the sake of argument, further assume that gnutls and openssl are
binary-compatible (ie, both provide libssl.so.0), and conflict. [0]

FooCorp happens to be a BSD shop, and uses OpenSSL for their development.
They also happen to be generally nice guys, and so also build .debs
for their product. It's non-free only because the bank they built the
program for is scared of making the source publically available.

Assume the package relationships look like:

	B Build-Depends: openssl-dev
	B Build-Conflicts: gnutls

	B Depends: libssl0.9.6 | gnutls0.9.6

	gnutls Conflicts: libssl0.9.6

FooCorp builds the package. They end up with a program that works
without having touched any GPLed software. They make it publically
available. People download it, and rather than installing OpenSSL,
they use it with gnutls.

Who are you claiming has violated the GPL? FooCorp, who've done their
development with LGPLed and BSDed libraries and had the gall to run
sed over their Depends: line? The user, who does no distribution at
all? The developers of gnutls for writing a GPLed program that dares be
binary compatible with something not GPLed? The developers of OpenSSL?

Or take the following sequence of events:

	* Two packages, libA and B, both non-free. Distributed separately
	  by FooCorp as .debs. License is "Do what you want with it, just
	  don't give copies to anyone else."

	* Independently, someone thinks libA is cool, and does an clean room
	  implementation that's compatible at both binary and source levels,
	  creating libA-gpl. It's uploaded to Debian. It Conflicts: with
	  libA.

	* As time passes, libA-gpl gets hacked on by a whole bunch
	  of people and improves dramatically, but remains ABI compatible
	  with the original libA, because the author and maintainer
	  likes it that way. Eventually, some important and interesting
	  GPLed program uses libA-gpl, and everyone using Debian installs
	  it.

	* Debian users who want B from FooCorp use apt-get and start running
	  B linked with libA-gpl.

	* FooCorp gets informed of this, and says they don't give a damn.

Who, exactly, has done anything illegal here, or in contravention of
the GPL? What clauses should FooCorp put in their licensing to prevent
them being sued by GPL bigots in this case?

How is this any different to:

	* Someone develops libA, thinks it's cool, puts it under the GPL.

	* FooCorp thinks libA is cool too, but doesn't want to GPL their
	  product (B), so makes a binary compatible version, libA-nonfree
	  and builds their program against it. They package it, make
	  it available as debs, and say "We don't care if you use libA
	  with our program, but if you don't want/have it, you're quite
	  welcome to use libA-nonfree. Both are supported by us."

	* Whole bunches of people download B and use it with libA and are
	  happy.

Who's done something illegal here, and what precisely was it? Is
developing non-free clones of GPLed software illegal? If so, some
non-free companies might be interested in exactly how you've managed to
make it illegal, so they can do away with annoying things like Samba. Or
is it illegal for users to do some things with GPLed software even in
the privacy of their own homes?

Cheers,
aj

[0] I realise this is extremely unlikely to actually happen with these
    particular packages. Imagine that the development had happened the
    other way around, like the libeditline and libreadline stuff, and
    that OpenSSL had been specifically designed to be binary compatible
    with gnutls.

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
                      -- John S. Novak, III (The Humblest Man on the Net)

Attachment: pgpF3W4426Oas.pgp
Description: PGP signature


Reply to: