Re: GPL-licensed packages with depend-chain to OpenSSL

[Glenn Maynard <glenn@zewt.org>]

On Fri, Sep 10, 2004 at 09:08:47AM -0400, Raul Miller wrote:
> > >  One piece of the resulting binary--OpenSSL--is not.
> > > This seems to clearly violate the spirit of the GPL.
> >
> > It might, but the GPL does have the normal components of an OS 
> > exception, for example. And only GPL (3), not (1) or (2) mentions all 
> > components of the resulting binary.
> 
> This is valid for the case where we're not shipping that derived work
> with the GPL'd parts of the program.  So, for an extreme example, users
> writing shell scripts that include curl+ssl and some gnu utils don't
> have any such issue to worry about (well, unless they're distributing
> that script and running a debian mirror, or some such).

I don't quite understand your example--I'm not sure if you're talking
about the with-the-OS exception, "only (3) talks about binaries", or
both.  Also, shell scripts make for murky examples, since there's an
entire separate argument about whether you're linking binaries by using
a shell script and a pipe ...

I think it's reasonable to consider OpenSSL part of the Debian OS (and
presumably others; I assume most distributions are shipping it these
days, but I wouldn't know).

So, you don't need an extreme example.  It's perfectly valid for one to
take Emacs, link it against OpenSSL, and distribute binaries, as long as
OpenSSL doesn't accompany it.

This only becomes a problem when Debian, or some other OS distributor,
wants to distribute those binaries.

I'm not sure if the running-a-mirror case is a problem or not; the GPL
doesn't define "accompanies".  A similar case would be distributing the
binaries on SourceForge: even if you don't include OpenSSL binaries, it's
probable that some other project on SF is, which means that there are
OpenSSL binaries in some other place on the same mirror.  Do they
accompany one another?  (No, I don't think they do according to what
I believe is the intent of the exception; but as for the letter of the
license, I don't know.)

> Of course, another issue is: does anyone really care about this kind
> of thing?
> 
> If people do, perhaps the right place to start would be to create a
> dummy package which conflicts with all packages which provide software
> only available under a gpl-compatible license.

Do you mean GPL-incompatible?

-- 
Glenn Maynard