Re: Bacula and OpenSSL (original) (raw)

On Wed, Jul 25, 2007 at 03:12:33PM +1000, Anthony Towns wrote:

In particular, going by the GPLv3: ] The "System Libraries" of an executable work [...]

So I've done the "here's what the license says, let's parse it to see if we can extract any meaning" thing, but I haven't done it the other way -- "here's what's intended, let's see if that fits the case we're considering, and if that helps understand the wording".

(Well, to be fair, I haven't seen a very clear statement of what the FSF intends by the clause -- beyond "minimal changes to the GPLv2 to make OpenSolaris okay" anyway)

I figure the exception is to allow people to write GPL programs on non-GPL operating systems and use the standard OS features and compilers/interpretors without having to worry. But that exception needs to be limited, so that when you add features to a GPLed program that would otherwise have to be freed, you can't avoid freeing them by carefully packaging and making use of some loophole in the exception.

Some characteristics of legitimate uses of that exception seem to me to be:

(1) they're readily available features that come standard with the
"system" (whether that be operating system, windowing system,
programming language, etc)

(2) they're not designed specifically for the program being used

(3) they're independent of the program being used

(4) they're used by standard components of the system, other than
your program

(5) they're used by other programs than the ones included with
    the system and that are unrelated to your program

(6) they implement standard interfaces, with altnerate implementations
    that you could rebuild your program against without much bother

(7) they implement standard interfaces, with source or docs available,
so you could create your own implementation and build your
program against that

(8) the implementation is widely available and is easily and
    practicably obtained by anyone, either commercially or freely

So writing GPLed apps that use Solaris features like dtrace or similar seem reasonable, in that dtrace hits (1)-(5), and (7) and (8); and GPLed programs that use the Windows API hit (1)-(5) and (8), though probably not (6) or (7), and programs that use non-free .NET or Java APIs probably hit (1)-(8).

Having the test be something like:

(1) and (2) and (3) and
( (4) or (5) ) and
( (6) or (7) or (8) )

seems to allow the things we want, and restrict the things we don't -- eg, trying to implement an add-on to GCC or emacs would fail (2) and (3), even if specially packaged so they met (1), (4), (5) and (8), eg.

The above could be applied to writing GPLed software that used libraries with special proprietary packages like Mathematica or similar too; YMMV.

To be a bit more concrete; say you have some GPLv3 code -- an implementation of an interesting peer-to-peer IM protocol, say. Then:

- if you're running Vista or OS X, you can integrate it into the
  environment, add a native GUI and add new features that will
  be a pain to port back to a free OS because they use libraries
  that haven't been reimplemented elsewhere yet; then send it
  to Apple or Microsoft and have it be included as a standard
  part of the OS.

- if you're running Debian, you have openssl as a standard
  component, but you can't add openssl support to your p2p IM
  app without making use of the system library exception and
  can't distribute it in Debian. So if Debian wants to have
  the same features as the new versions of Vista or OS X do,
  we can't just use our existing libraries and the GPL app as
  Microsoft and Apple did, we either have to reimplement the
  app with an OpenSSL friendly license, or reimplement OpenSSL.

  That is: it's easier for non-free OSes to incorporate GPLed
  code than for free OSes.

Maybe that is the result of the way the GPLv3's been drafted, and maybe it actually has to be that way for some reason -- but is there really any question that the above's a bad outcome?

If we can agree it is a bad outcome, it seems worth exploring other interpretations of the new System Library exception to see if we can avoid them.

Cheers, aj

Attachment:signature.asc
Description: Digital signature

Reply to: