The saga of the GCC runtime library has been
a couple of times
in the past. The library's license is a legal hack which tries to accomplish a set
of seemingly conflicting goals. The GCC runtime library (needed by almost
all GCC-compiled programs) is licensed under GPLv3; that notwithstanding,
the Free Software Foundation wants this library to be usable by proprietary
programs - but only if no proprietary GCC plugins have been used in the
compilation process. The runtime library
published by the FSF appears to have accomplished those
objectives. But now it seems that, perhaps, the GCC runtime licensing has
put distributors into a difficult position.
The problem has to do with programs which are licensed exclusively under
version 2 of the GPL. Examples of such programs include git and udev,
but there are quite a few more. The GPLv3 licensing of the GCC runtime
library (as of version 4.4) would normally make that library impossible to
distribute in combination with a GPLv2-licensed program, since the two
licenses are incompatible. The runtime library exception is intended to
make that problem go away; the relevant text is:
You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if
such propagation would otherwise violate the terms of GPLv3,
provided that all Target Code was generated by Eligible Compilation
Processes. You may then convey such a combination under terms of
your choice, consistent with the licensing of the Independent
So, as long as the licensing of the "Independent Modules" (the
GPLv2-licensed code, in this case) allows it, the GCC runtime library can
be distributed in binary form with code under a GPLv3-incompatible
license. So there should not be a problem here.
But what if the licensing of the "Independent Modules" does not allow this
to happen? That is the question which
Florian Weimer raised on the GCC mailing list. The GCC runtime library
exception allows that code to be combined with programs incompatible with
its license. But, if the program in question is covered by GPLv2, the
problem has not been entirely resolved: GPLv2 still does not allow the
distribution of a derived work containing code with a GPLv2-incompatible license. The
GPLv3 licensing of the runtime library is, indeed, incompatible with GPLv2,
so combining the two and distributing the result would appear to be a
violation of the program's license.
The authors of version 2 of the GPL actually anticipated this problem; for that reason,
that license, too, contains an exception:
However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either source
or binary form) with the major components (compiler, kernel, and so
on) of the operating system on which the executable runs, unless
that component itself accompanies the executable.
This is the "system library" exception; without it, distributing binary
copies of GPLv2-licensed programs for proprietary platforms would not be
allowed. Even distributing a Linux binary would risk putting the
people distributing the program in a position where they would have to be
prepared to provide (under a GPLv2-compatible license)
the sources for all of the libraries used by the binary. This exception is
important; without it, distributing GPLv2-licensed programs in binary form
would be painful (at best) or simply impossible.
But note that the exception itself contains an exception: "unless
that component itself accompanies the executable." This says that,
if somebody distributes GCC together with a GPLv2-licensed program, the
system library exception does not apply to the code which comes from GCC.
And that includes the GCC runtime library. One might think that tossing a
copy of the compiler into the distribution of a binary program would be a
strange course of action, but that is
exactly what distributors do. So,
on the face of it, distributors like Debian (which, naturally, turned up
this problem) cannot package GPLv2-licensed code with the GCC 4.4 runtime
library without violating the terms of GPLv2.
This is a perverse result that, probably, was not envisioned or desired by
the FSF when it wrote these licenses. But Florian reports that attempts to get clarification
from the FSF have gone unanswered since last April. He adds:
If the FSF keeps refusing to enter any discussion on this matter
(I'm not even talking about agreeing on a solution yet!), our
options for dealing with the GCC 4.4 relicensing fallout at Debian
are pretty limited. It's also likely that any unilateral action
will undermine the effect of some of the FSF's licensing policies.
One could argue that the real problem is with the GPLv2 system library
exception-exception. That (legal) code was written in a world where there
were no free operating systems or distributors thereof, and where nobody
was really thinking that there could be conflicting versions of the GPL.
Fixing GPLv2 is not really an option, though; this particular problem will
have to be resolved elsewhere. But it's not entirely clear where that
resolution could be.
A statement from the FSF that, in its view, distributing GPLv2-licensed
binaries with the GPLv3-licensed GCC runtime library is consistent with the
requirements of both licenses might be enough. But such a statement would
not be binding on any other copyright holders - and it is probable that the
bulk of the code which is not making the move to GPLv3 is not owned by the
FSF. A loosening of the licensing on the GCC runtime library could help,
but this is a problem which could return, zombie-like, every time a body of
library code moves to GPLv3. It's a consequence of the fundamental
incompatibility between versions 2 and 3 of the license.
This has the look of the sort of problem that might ordinarily be
studiously ignored into oblivion. If one avoids the cynical view that the
FSF desires this incompatibility as a way of pushing code toward GPLv3,
it's hard to see a situation where a copyright holder would actually
challenge a distributor for shipping this particular combination. But the
Debian Project is not known for ignoring this kind of issue. So we may
well be hearing more about this conflict in the coming months.
(Thanks to Brad Hards for the heads-up on this issue).
to post comments)