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

Re: Bacula and OpenSSL

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

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.


Attachment: signature.asc
Description: Digital signature

Reply to: