Matthias Kirschner mk@fsfe.org schrieb:
- Bernhard Reiter reiter@fsfeurope.org [2010-10-26 09:37:39 +0200]:
Am Montag, 25. Oktober 2010 17:30:23 schrieb Volker Grabsch:
Das gilt erstmal nur für Copyleft-Lizenzen, also "virale" Lizenzen.
"Viral" ist wirklich ein unpassendes Wort dafür, denn die Lizenz "infiziert" keine anderen Werke. Es geht nur um abgeleitete Werke. Und hier sind die proprietären Lizenzen auch gern mal problematisch, am Ende muss ich hier auch die Lizenz genau prüfen. Da ist mir doch eine der gut verstandenen Standardlizenzen der Freien Software, viel lieber.
Eigentlich ist eine Freie Software Lizenz oft eine Impfung gegen unfreie Tendenzen, also eine Lizenz mit starkem oder schwachem Schutz der Freiheit.
Freie-Software-Befürworter sollten möglichst von impfen, statt von viral oder infiziert sprechen. Hab das gerade in meinem Eintrag "Dradio Wissen: Freie-Software-Lizenzen" in meinem Blog http://blogs.fsfe.org/mk/?p=679 und auf Netzpolitik http://www.netzpolitik.org/2010/dradio-wissen-freie-software-lizenzen/ auch wieder so verwendet.
Wobei man "impfen" auch im weiteren Sinne sehen kann.
Zunächst natürlich durch Wahl einer strengen Lizenz wie GPL oder AGPL. Aber darüberhinaus auch durch entsprechende Verteilung / Verschiebung der Urheberschaft. Dadurch schützt man sich und das Projekt davor, erpressbar zu werden. Große Teile (A)GPL basieren auf der Idee "lieber tot als unfrei", sodass unangenehme Zeitgenossen erst gar nicht auf dumme Ideen kommen. Diese Strategie kann man weiter ausbauen.
Mir sind folgende Methoden für eine solche "erweiterte Impfung" eingefallen:
1) Abhängigkeit von einer GPL-Library
Man könnte das Projekt von vornherein auf eine GPL-lizensierte Library aufbauen, die später nicht ohne großen Aufwand ausgetauscht werden kann. So kann man immer sagen: "Also, _ich_ würde das ja gern anders lizensieren, aber dann müssten wir diese schicke Komponente ersetzen - ist das wirklich den Aufwand wert?"
2) Möglichst viele Urheber
Man könnte jedem Patch - auch kleine, triviale Patches - zum Anlass nehmen, die Autorenliste zu vergrößern. Eine große Autorenliste macht ohnehin mehr Eindruck. ;-) Und man kann dann immer sagen: "Also, _ich_ würde das ja gern anders lizensieren, aber da müssten alle anderen zustimmen. Oder wir müssten nachträglich allen Code entfernen, den bestimmte Personen beigesteuert haben. Ist das wirklich den Aufwand wert?"
3) Gemeinnützige Organisation als Urheber
Diese Form der Impfung ist vorallem durch das GNU-Projekt bekannt geworden, da dort jeder Kontributor seine Rechte an die FSF abgibt. Der Vorteil ist, dass sich unangenehme Zeitgenossen statt mit einem Individuum nun mit einer auf Freie Software spezialisierten Organisation anlegen müssten. Der Nachteil ist jedoch, dass dies allein nicht davor schützt, dass andere (z.B. Arbeitgeber) einen Anspruch auf die Verwertungsrechte erheben, wodurch die Übertragung an die FSF nichtig wird. Daher nenne ich diese Methode zuletzt.
Darüber hinaus gibt es auch eine Anti-Methode:
A1) Hauptentwickler als alleinige(r) Urheber
In einigen Projekten besteht der Hauptentwickler bzw. das Kernteam darauf, dass alle Kontributoren die Rechte an Ihren Zuarbeiten abgeben an den/die Hauptentwickler. Das sieht man vorallem bei Projekten, die von der kritikwürdigen Dual-Licensing-Strategie gebrauch machen. Diese Methode sieht zunächst so ähnlich aus wie das, was das GNU-Projekt auch macht (siehe Methode 3)). Allerdings wird in diesem Fall das genaue Gegenteil erreicht, denn es ist eine Negation der Methode 2). Was für Gefahren das im Ernstfall mit sich bringen kann, sieht man sehr deutlich bei der Übernahme von Sun durch Oracle.
Gruß Volker