Q to the candidates: GPLv2 system library exception
The GPLv2 contains a system library exception. This enables
proprietary operating systems (such as Solaris or Windows) to
distribute GNU software linked against proprietary libraries
(including the system libc and other compiler support libraries),
something the GPLv2 would not otherwise allow because full machine
readable source code for the executable cannot be provided.
Historically, Debian has assumed that unlike proprietary operating
systems, it cannot use the system library exception in the GPLv2 to
permit linking against libraries part of Debian which are licensed in
a way that is not compatible with the GPLv2. This position is
somewhat unique among free software distributions, and is not fully
enforced within Debian, either. We currently distribute GPLv2
software in such away that we apparently invoke the system library
exception to avoid a GPL violation.
In the past, the most prominent example was OpenSSL. (The OpenSSL
relicensing in progress will not substantially alter this situation
because the new license is still incompatible with the GPLv2.) Today,
the more pressing example is libgcc (the compiler support library part
of GCC), which was upgraded to the GPLv3 some time ago. libgcc is
mandatory on some architectures, but the GPLv3 is incompatible with
the GPLv2 (under which important software such as Git and OpenJDK are
released). It is unclear whether the GCC run-time library exception
restores GPLv2 compatibility.
For OpenSSL, we obtained permission to link against OpenSSL from many
upstream projects. But for libgcc, that seems rather excessive.
Do you think this situation needs addressing? What do you propose do
about it? Do you think the way the ZFS situation was resolved could
be an example?
(Question as suggested by Moritz Mühlenhoff in
<slrnodiv30.67j.jmm@inutil.org> on debian-devel.)
Reply to: