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