Moin, mit der Bitte um aufklärung. Gruß Arnulf
* 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.
Am Samstag, 4. April 2009 17:14:48 schrieb Florian Weimer:
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.
Ja, das wäre wirklich nett. Florian, danke für die Erklärungen (die ich auch nochmals gründlich lesen muss.)
Wichtig ist mir noch der Hinweise: Die FSFE ist eine gleichberechtigte Schwesterorganisation und _nicht_ die FSF. Sprich, manchmal wissen wir auch nicht mehr als die Ankündigung. Das liegt auch daran, das FSF und FSFE relativ viel auf vielen Gebieten machen.
Gruß, Bernhard