Softwarelizenzen bei der Pluginentwicklung. Eine kleine Recherche.

Ich bin ja schon länger mit verschiedenen Programmierprojekten betraut. zum Beispiel mein Thekendienst-Plugin für WordPress oder das Einwohnermelderegister-Verortungs-Plugin für QGIS, dass ich im Rahmen meines letzten Studienprojektes geschrieben habe.

Da nun ansteht das ein bisschen auszubauen, muss ich mich mal ein bisschen mit Softwarelizenzen auseinandersetzen. Bisher habe ich einfach alles was ich so produziert habe unter der Lizenz der “Muttersoftware” veröffentlicht. Da konnte ich nichts falsch machen. Nun bin ich aber einigen sehr speziellen Anwendungen dran, die für mich evtl. aus berufliche Zukunft taugen würden. Obgleich ich ein großer Freund von Freier Software bin möchte ich mir zumindest die Option eröffnen, das ein oder andere zu vermarkten.

Eine codetechnische Anpassung einer Software die unter einer entsprechenden freien Lizenz steht, muss ich bei Veröffentlichung eben auch unter dieser Lizenz weiterveröffentlichen. Soweit habe ich also mit meinen bisherigen Projekten alles richtig gemacht. Was mir aber auch eingeräumt wird, was ich so bewusst noch nicht wusste, dass ich das umgehen kann, indem ich einfach nicht veröffentliche, sondern meine Anpassungen am Programmcode ausschließlich in-house und durch mich benutze.

Ich schreibe gerade (oder genauer: plane zu schreiben) an einer GIS-Software für ein Demographiemonitoring für den ländlichen Raum mit planerischen Zielstellungen. Das ist etwas, was zur Zeit noch von einigen wenigen Büros und Institutionen gemacht wird, vorwiegend als Dienstleistung, aber höchstens mit kommerziellen Softwareprodukten für INGRADA oder ArcGIS.

Eine Software für freie GIS-Programme (die auch Lizenzabgabenfrei sind und folglich flächendeckend erschwinglich sind) gibt es – soweit ich den Überblick habe – noch nicht. Nun stellt sich die Frage, inwiefern man Erweiterungen für diese Programme kommerziell vermarkten kann. Rein rechtlich. Technisch ist das alles sehr machbar, weil die Software meiner Wahl, Quantum GIS, sehr modular aufgebaut ist, es also eine Schnittstelle für Plugins gibt.

Wie oben geschrieben: Ich darf durchaus mit einer eigenen Software-Anpassung kommerziell tätig sein, allerdings lediglich als Dienstleister. Ich darf also meine Softwareerweiterung nicht als Closed-Source Software (mit Lizenzgebühren) vermarkten. Nun stellt sich die Frage, ob Plugins, die ja mit dem eigentlichen Programmcode des Programms nichts zu tun haben, sondern lediglich deren Programmfunktionen nutzen, als Softwareanpassung gelten, oder aber als eigenständiges Produkt.

Bisher habe ich noch keinerlei Erweiterungen für das Programm gefunden, die man käuflich erwerben könnte, die also als eigenständiges (im juristischen Sinne) Softwareprodukt vermarktet werden. Das legt die Vermutung nahe, dass das nicht möglich ist. Aber bevor ich das als Wahrheit postuliere, muss ich das nochmal genauer prüfen.

Ein paar Quellen nutze ich.

Und eigentlich braucht es nur diese Quellen, damit hier jeder Leser den Überblick bekommen kann. Wichtigste Zitate wie ich meine (von gnu.org):

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

Und ganz konkret (von gis.stackexchange):

You cannot :

  • use a proprietary (or non-gpl compliant) python module in your plugin importing a qgis module
  • link (as in compilation link) your plugin (c++ or python) with any proprietary or non-gpl compliant library.

You can :

  • Execute an external application, whatever its licence, from your plugin, exchanging data through files for example
  • Call a webservice or a socket-based service to a proprietary server application

So ganz klar ist das aber immer noch nicht. Zum Beispiel schreibt meine erste Quelle da oben, mit Verweis auf die EU-Richtlinie 91/250/EWG, dass das Nutzen von “Schnittstellen” (auch “api” genannt) durchaus eine normale Funktion eines Programms sein kann und folglich den Sachverhalt “Armeslänge” erfüllt wäre. Die Frage ist, was ist API und was ist Bibliothek. Bei Plugins, die im Sinne nachfolgenden Zitats als Komponentenschnittstelle gelten, ist das nicht so wirklich deutlich:

Bei der Frage, ob Komponentenschnittstellen eigenständige Werke trennen, zeigt sich, dass das vorherrschende Programmverständnis aus der Zeit der Computerprogramm-Richtlinie in Auflösung begriffen ist. Während Programmier- und Kommunikationsschnittstellen im Regelfall eigenständige Programme bzw. Betriebssystem und Anwendungsprogramme trennen, lässt sich dies von Komponentenschnittstellen nicht in dieser Allgemeinheit sagen. Ein Programm kann aus mehreren Komponenten bestehen, die zudem in unterschiedlich starkem Umfang voneinander abhängig sind. Dies kann im Extremfall dazu führen, dass eine Komponente in unveränderter Form für eine Vielzahl von Programmen verwendbar ist oder eben so eng mit einem einzigen Programm verwoben ist, dass sie mehr oder weniger in diesem Programm aufgeht.

Ob das Quantum-GIS-API mir so autarke Möglichkeiten einräumt, autark vom eigentlichem QGIS zu arbeiten wage ich – jetzt mal rein intuitiv – zu bezweifeln.

Wer das genauer wissen möchte sollte das PDF von Till Jaeger/ifross lesen. Da ist die notwendige juristische Differenzierung noch genauer aufgezeigt.

Bisher verwende ich Python zur Entwicklung und importiere einfach fleißig externe GPL-Bibliotheken, so dass diese mir meine Funktionen zur Verfügung stellen. Würde ich das sein lassen, sondern ausschließlich und direkt auf die die api-Funktionen von QGIS zurückgreife, wäre eine kommerzielle Vermarktung vermutlich denkbar. Allerdings auch furchtbar aufwändig. Ich nutze so viele externe Funktionen, dass ohne diese eigentlich nichts an eigener Software über bleibt. In dem Jaeger-Text wird das übrigens als intensive Werkverbindung (als juristischer Fachbegriff) benannt, denke ich.

Effektiv kann ich also meine Plugins nicht kommerziell vermarkten, sondern lediglich in-house verwenden.

Denkbar ist für mich also meine Software in zwei Teile zu teilen. Eine Quelloffene die ich beim Klienten ausführen lasse (zum Beispiel zwecks Datenexport) und eine die nicht veröffentlicht wird und die ich als Dienstleister nutze.

Ich habe die Theorie, dass das mit ein Grund ist, warum viele Firmen in der Branche komplett geschluckt werden, statt nur eine Software zu kaufen. Wenn eine In-House-Software irgendwann mal auf einem quelloffenen System basierte und deren Bestandteile noch nutzt, kann man die eigene Softwareerweiterung zwar benutzen, aber eben nicht verkaufen. Und weiter nutzen, wenn man plötzlich zu einer anderen Firma gehört. So ist zumindest mein naives Verständnis der Thematik.

Ich kann mir vorstellen, dass (auch) aus diesem Grund Linux immer noch ein Nischendasein führt. Da dieses Betriebssystem und seine Subdienste freie Software sind, kann Software die diese Funktionen in engem Maße nutzt (enger als Armeslänge) nicht kommerziell vermarktet werden. Unternehmen die mit Software Geld verdienen, haben also keinerlei Interesse sich allzu eng an dieses Betriebssystem zu binden. Wenn ich recht informiert bin, sind viele der Funktionen von Mac OS X und Windows mit entsprechenden Lizenzen ausgestattete, dass eine kommerzielle Nutzung möglich ist. Die damit verbundene Möglichkeit mit Software Geld zu verdienen spornt in einem kapitalistischen System natürlich mehr an, dort Energie und Geld in die Entwicklung zu stecken.

Ich hätte nicht gedacht, dass offene Systeme mal verhindern, dass Innovation stattfindet. Die Restriktivität (unter Einräumung gewisser Rechte) kommerzieller Betriebssysteme hilft offensichtlich auch das eigene Produkt (und das dadurch generierte Einkommen) zu sichern. Auch ein wichtiger Aspekt, denke ich.

In freier Software steckt viel Ideologie. Jetzt muss man nur Fragen ob diese Ideologie durch vorgenannten Sachverhalt sich nicht selbst in den Rücken fällt. Denn es schafft durch die Verpflichtung zur Quelloffenen Veröffentlichung eine Grenze, die durchaus auch durchlässiger gestaltet werden könnte.

Jetzt verstehe ich auch so langsam, warum Qt4 in einer GPL- und einer kommerziellen Version vorliegt: Das Programmbibliotheken die engst mit der eigenen Software verschlungen werden: Armeslänge ist da nicht. Und bei Qt4 ist das auch nur möglich, weil ein Unternehmen da hinter steht, was einen Großteil, wenn nicht allen Programmcode zu Qt4 schreibt. Wie das intern läuft Programmcode, der von dritten für die GPL-Version geliefert wurde, auch in die kommerzielle Version zu bekommen lässt mich mich noch am Kopf kratzen. Vielleicht wird tatsächlich in jedem Einzelfall um Erlaubnis beim Autor gefragt oder ggf. die Arbeit vergütet? Wer weiß? 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *