Geimpft, statt viral und infiziert (Was: Impfen statt Re: Suche Zusammenfassung: Warum sollte ich meine Software frei stellen?)

[Volker Grabsch]

Matthias Kirschner <mk at fsfe.org> schrieb:
> * Bernhard Reiter <reiter at 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

-- 
Volker Grabsch
---<<(())>>---