http://www.pro-linux.de/news/2009/14027.html

Florian Weimer fw at deneb.enyo.de
Sa Apr 4 15:14:48 UTC 2009


* Arnulf Pelzer:

> mit der Bitte um aufklärung.

Aufklärung bezüglich was?

GCC soll offener gestaltet werden. Bisherige Versuche (GCCXML,
llvm-gcc, das C-Backend von Sun), GCC-Technologie außerhalb des
GCC-Projektes zu nutzen, wurden von der FSF mit Argwohn betrachtet,
weil sie es grundsätzlich ermöglichen, GCC-Funktionen von
Nicht-GPL-Programmen aus zu nutzen. Eine Plugin-Schnittstelle (wozu
auch stabile Serialisierungsformate für interne
Compiler-Datenstrukturen gehören), die in der offiziellen GCC-Version
enthalten ist, hätte diesen Ansätzen, die GPL zu umgehen, indirekt
ihren Segen erteilt.

Beim Kompilieren und Linken vieler Programme werden Teile von GCC
(nämlich libgcc) in das Resultat kopiert, meist sogar ohne dynamisches
Linken. Die FSF versucht daher, die negativen Auswirkungen von Plugins
dadurch zu verhindern, daß libgcc nicht für Kompilate genutzt werden
kann, bei denen GCC mit proprietären Plugins zum Einsatz kam.

Die erste Version der Ausnahme übersah, daß der Java-Compiler in GCC
seit einiger Zeit vom Java-Bytecode aus Maschinencode erzeugt.
Java-Quellcode wird zunächst vom Eclipse-Java-Compiler kompiliert, der
der EPL unterliegt, die nicht GPL-kompatibel ist. Damit wäre die
libgcc-Ausnahme für kompilierte Java-Quellen nie nutztbar gewesen. Man
hätte z.B. mit GCC keine Java-Quellen unter der Eclipse-Lizenz
kompilieren und das Kompilat weiterverteilen können (also insbesondere
einen kompletten, GCC-basierten Java-Compiler). Das war nicht
beabsichtigt.

Ob das in der Praxis funktioniert, ist unklar. libgcc ist nicht
sonderlich groß und kann ggf. reimplementiert werden.

Die neue libgcc-Lizenz hat zudem Nebenwirkungen auf andere Compiler
(auch wenn diese direkt auf Quellcode arbeiten). So ist nicht klar, ob
der Objective-Caml-Compiler, der selbst der QPL unterliegt (und
typischerweise mit sich selbst und GCC kompiliert wird), als Kompilat
weiterverbreitet werden darf, weil die QPL nicht kompatibel mit der
GPL ist und die libgcc-Ausnahme somit möglicherweise nicht nutzbar
ist. (Der Grund für diesen Efekt ist, daß libgcc Teil von GCC ist und
die Katze sich lizenztechnisch in den Schwanz beißt, sobald ein
Compiler in sich selbst geschrieben ist.)

Ich sehe das ganze ziemlich skeptisch. Ich hoffe, die FSF wird sich in
der einen oder anderen Form klarstellend zur verbleibenden
Compiler-Problematik äußern. Letztlich treffen diese Spielchen nicht
diejenigen, die GCC in proprietäre Technologie einbetten wollen (was
eigentlich jeder Hersteller von proprietären Allzweck-Betriebssystemen
tut), sondern diejenigen, die explizit freie Betriebssysteme bauen und
nun vor der Frage stehen, ob alle unsere Nicht-GCC-Compiler plötzlich
nur noch Programme erzeugen, die unter der GPL lizensiert werden
müssen. Ich hätte kaum Probleme damit, wenn wir wenigstens (wie die
ganzen proprietären Hersteller!) gegen Systembibliotheken wie OpenSSL
linken könnten, die nicht der GPL unterliegen, aber selbst das dürfen
wir nicht. Die alte "mere aggregation"-Klausel (die auch in der
Version 3 weiterlebt) greift für freie Betriebssysteme nicht, weil wir
alles integriert ausliefern. Die proprietären Hersteller machen das
zwar heutzutage auch, aber hören diesbezüglich vermutlich auf ihren
Rechtsbeistand, während wir versuchen, die Wünsche der FSF zu
respektieren.



Mehr Informationen über die Mailingliste FSFE-de