Verwaltung einer Lizenz mit Maven-Plug-ins

Softwaregestütztes Open-Source-Lizenzmanagement

Markward Schubert, Dr. Lutz Keppeler

© Shutterstock/v.schlichting

Das Thema Lizenzmanagement erfährt in den letzten Jahren aus verschiedenen Perspektiven verstärkt Aufmerksamkeit, sowohl in proprietären, als auch in Open-Source-Softwareprojekten. So ist zu beobachten, dass die Verwendung von Open-Source-Lizenzen bei der Auseinandersetzung mit Vertragspartnern in der Softwareindustrie eine zunehmende Rolle spielt. Der Beitrag erläutert vor dem Hintergrund der juristischen Risiken und Implikationen von Open-Source-Lizenzen die wichtigsten Dos und Don’ts bei der Implementierung eigener Projekte. Dabei stellen wir das License-Maven-Plug-in vor und erläutern, wie es unterstützen kann und wo seine Grenzen liegen.

Die rechtlichen Implikationen von Open Source werden immer genauer analysiert. Gleichzeitig stellt die Open-Source-Community fest, dass es offenbar unter jungen Entwicklern eine bemerkenswerte Nachlässigkeit bei der Lizenzierung der eigenen Open-Source-Software gibt. In Zeiten von GitHub ist ein Projekt schnell mit der Welt geteilt, die Folgen, die sich aus dem Verzicht einer expliziten Lizenzierung ergeben, werden zulasten von ungewollten Konsequenzen aber vernachlässigt. Bereits im Jahr 2013 startete GitHub die Website choosealicense.com. Unter der Überschrift „Choosing an OSS license doesn’t need to be scary“ bieten die Betreiber hier Hilfestellungen bei der Wahl der passenden Open-Source-Lizenz an.

Zumindest bei komplexeren Entwicklungen sollte schon allein aus juristischer Perspektive ein License-Management-System etabliert werden, um stets einen Überblick über die Vielzahl der unterschiedlichen Open-Source-Lizenzen zu erhalten, die ansonsten unentdeckt in einem Projekt schlummern und so zu einem Risiko werden können.

Im Fall von Maven-basierten Java-Projekten kann das License-Maven-Plug-in dem Entwickler bereits viel Arbeit beim Lizenzmanagement abnehmen, wenn es richtig verwendet wird. Das Plug-in, welches in erster Linie dafür vorgesehen ist, bei der Pflege der Lizenz des eigenen Projekts zu unterstützen, kann auch einen nützlichen Beitrag zur Erfüllung von Third-Party Licenses Compliance leisten.

Anwendung des License-Maven-Plug-ins bei der Pflege der eigenen Lizenz

Wir gehen von der Grundfunktion des License-Plug-ins aus: Die Verwaltung der eigenen Lizenz. So kann das Plug-in vor allem bei der korrekten und stringenten Distribution der entsprechenden Lizenzvereinbarung, zusammen mit den zu verteilenden Softwareartefakten helfen. Das können einerseits Dateien mit dem Lizenztext in einem JAR- oder WAR-Archiv sein, die Veröffentlichung auf einer Projektwebsite, oder ein entsprechender Header in den Quelldateien des Projekts. An einem Beispielprojekt sollen zunächst folgende Arbeitsschritte demonstriert werden:

  1. Konfiguration einer Lizenz für das eigene Projekt und Verwendung durch das License-Plug-in
  2. Erstellung von Lizenz-Headern mit der eigenen Lizenz in den Quelldateien des Projekts

Das Beispielprojekt

Unseren Beispielen liegt ein kleines Testprojekt zugrunde, welches auf GitHub verfügbar ist. Es handelt sich um ein Maven-Projekt mit einem übergeordneten Projekt license-plugin-demo und zwei Kindprojekten library und webapplication. Die library beinhaltet Klassen, die im WAR-Projekt webapplication verwendet werden. Das Projekt webapplication erzeugt hierbei eine WAR-Datei, die an Kunden ausgeliefert werden soll. Um die beschriebenen Arbeitsschritte einfach nachzuvollziehen, empfehlen wir, das Demoprojekt von GitHub zu klonen. Die beschriebenen Goals sind dort bereits konfiguriert und müssen nur einkommentiert werden.

Eine Lizenz für das Projekt

Zu Beginn unseres Szenarios haben wir die Projektstruktur vorliegen und bereits eine Servlet-Klasse und eine Hilfsklasse implementiert. Das Projekt steht noch am Anfang, und es wurde bereits in dieser frühen Phase darüber nachgedacht, unter welcher Lizenz das Projekt veröffentlicht werden soll.

Damit das License-Maven-Plug-in mit Lizenzen arbeiten kann, müssen diese dem Plug-in bekannt sein. Von Haus aus kennt das Plug-in bereits eine Anzahl offener Lizenzen, die mit dem Goal license:license-list aufgelistet werden können (Kasten: „Vom Plug-in unterstützte Open- Source-Lizenzen, gruppiert nach Copyleft-Effekt“).

Vom Plug-in unterstützte Open-Source-Lizenzen, gruppiert nach Copyleft-Effekt
Copyleft-Lizenzen:
* agpl_v3 : GNU Affero General Public License (AGPL) Version 3.0
* cddl_v1 : COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0
* epl_only_v1 : Eclipse Public License – v 1.0
* eupl_v1_1 : European Union Public License v1.1
* gpl_v1 : GNU General Public License (GPL) Version 1.0
* gpl_v2 : GNU General Public License (GPL) Version 2.0
* gpl_v3 : GNU General Public License (GPL) Version 3.0
* lgpl_v2_1 : GNU General Lesser Public License (LGPL) Version 2.1
* lgpl_v3 : GNU General Lesser Public License (LGPL) Version 3.0
Lizenzen ohne Copyleft:
* apache_v2 : Apache License Version 2.0
* bsd_2 : BSD 2-Clause License
* bsd_3 : BSD 3-Clause License
* mit : MIT-License

Vorbereitungen, die gewählte Lizenz konfigurieren

Da wir in diesem Beispiel eine der bekannten Open-Source-Lizenzen verwenden wollen, brauchen wir keine Texte für eine eigene Lizenz zur Verfügung zu stellen. Wir wählen für unser Projekt die Apache-Lizenz in der Version 2.0. Um die im Folgenden beschriebenen Goals ausführen zu können, müssen wir dem Plug-in mitteilen, welche Lizenz den Operationen zugrunde liegen soll. Dies geschieht über das Konfigurationselement licenseName, wie in Listing 1 gezeigt.

Hinzufügen des Lizenzheaders zu den Quelldateien des Projekts

Es ist üblich, die eigenen Quelldateien mit einem Lizenzheader zu versehen. In der frühen Phase unseres Demoprojekts wäre dies noch eine überschaubare, manuelle Aufgabe. Möchte man jedoch einer bestehenden Codebasis einen Lizenzheader hinzufügen oder einen bestehenden Header ändern, gelangt man schnell an den Punkt, an dem diese Arbeit manuell unzumutbar wäre. Mithilfe des Goals license:update-file-header kann dieser Header in allen Quelldateien in einer einfachen Batch-Operation gesetzt werden. Das Goal ist für die Ausführung während einer passenden Lifecycle-Phase konzipiert und kann durch zahlreiche Konfigurationsmöglichkeiten angepasst werden.

Wir wollen die Klassen unserer Projekte mit dem Lizenzheader unserer Lizenz versehen. Hierfür ergänzen wir die Konfiguration wie in Listing 1.

<plugins>
  <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>license-maven-plugin</artifactId>
    <version>1.8</version>
    <configuration>
      <licenseName>apache_v2</licenseName>
    </configuration>
    <executions>
      <execution>
        <id>first</id>
        <goals>
          <goal>update-file-header</goal>
        </goals>
        <phase>process-sources</phase>
      </execution>
    </executions>
  </plugin>
</plugins>

Das Goal update-file-header wird nun in der Phase process-sources ausgeführt und wird den Header in allen relevanten Dateien hinzufügen bzw. aktualisieren. Hierbei ist zu beachten, dass das Plug-in von Hause aus verschiedene Dateiformate kennt und über die Möglichkeit verfügt, entsprechende Kommentare einzufügen. Neben Java-Quellcode, XML, JSP, SQL und JavaScript werden noch zahlreiche weitere Formate unterstützt. Das bedeutet, dass prinzipiell alle diese Dateitypen mit dem Lizenzheader ausgestattet werden können, wobei das für den Dateityp passende Kommentarschema verwendet wird.

Nach einem Aufruf von package auf dem Projekt sollte in allen relevanten Dateien, sowohl den Java-Dateien, als auch der Datei /src/main/resources/configuration.xml im Projekt library, der Header hinzugefügt worden sein.

Die Lizenzdatei dem Projekt hinzufügen

Das Goal license:update-project-license ist dafür zuständig, die vollständige Lizenzdatei dem fertigen Artefakt hinzuzufügen. Aktiviert man die Ausführung des Goals in der Konfiguration des Projekts, packt Maven die für die Lizenz hinterlegte Datei mit dem vollständigen Lizenztext in das resultierende Artefakt. Standardmäßig landet so die Datei License.txt im Ausgabeverzeichnis. Optional kann auch durch das Setzen des Attributs generateBundle dafür gesorgt werden, dass die Lizenz unter META-INF/${project.artifactId}-LICENSE.txt. abgelegt wird.

Fügen wir das Goal update-project-license der Konfiguration in Listing 1 hinzu, wird beim nächsten Paketieren des Projekts die Lizenzdatei im Target-Verzeichnis unter generated-sources/license abgelegt.

Hinzufügen einer eigenen Lizenz

Soll das Projekt unter eine Lizenz gestellt werden, die nicht in der obigen Liste enthalten ist, muss diese dem Plug-in bekannt gemacht werden, bevor sie wie beschrieben verwendet werden kann. Hierfür werden zwei Dateien benötigt. Eine Datei mit dem Lizenzheader, der in die Quelldateien eingefügt werden soll und eine Datei mit dem vollständigen Lizenztext. Werden keine anderen Einstellungen vorgenommen, werden die Dateien mit den Namen header.txt und license.txt im Verzeichnis /src/license/<LIZENZNAME>/ erwartet. Eine weitere Datei meldet die neue Lizenz beim Plug-in an. Der erwartete Name lautet licenses.plugin. In dieser Property-Datei wird der logische Name der Lizenz als Schlüssel hinterlegt. Der Wert entspricht dem vollständigen Namen der Lizenz, wie er im Lizenztext erscheinen soll. Im Projekt library haben wir eine inaktive Konfiguration vorbereitet, mit der das Vorgehen ausprobiert werden kann.

Eine Vielzahl von Lizenzen mit einer Vielzahl von Verpflichtungen

Die Anzahl der verschiedenen Open-Source-Lizenzen ist gewaltig. Das Institut für Rechtsfragen der Open-Source-Software listet auf seiner Webseite 230 Lizenzen auf, wobei hier bereits die verschiedenen Versionen der Lizenz berücksichtigt wurden. GPL ist nämlich nicht immer gleich GPL. Auch wenn die verschiedenen Versionen der populären GNU General Public License (GPL) zueinander sehr ähnlich sind, bestehen doch erhebliche Unterschiede zwischen der GPLv1.0, GPLv2.0 und der GPLv3.0. Die meisten populären Lizenzen gibt es in mehreren Versionen und unterschiedlichen Varianten. So ist etwa bei der Berkeley Software Distribution License zwischen der älteren 4-Clause-BSD, der jüngeren 3-Clause-BSD und der seltener verwendeten 2-Clause-BSD zu unterscheiden.

Die Vielgestaltigkeit der Lizenzen erhöht sich zudem dadurch, dass bekannte Lizenztexte für bestimmte Projekte angepasst werden. So steht das OpenJDK etwa unter der GPLv2 mit der so genannten „Classpath Exception“, die den so genannten „Copyleft-Effekt“ betrifft. Die Folge des Copyleft-Effekts kann darin bestehen, dass alle Teile der Software, die als Bearbeitung (engl. „Derivative Work“) in Bezug auf die jeweilige Open-Source-Komponente gelten, ebenfalls unter die Lizenz mit dem Copyleft-Effekt gestellt werden müssten. In dem ergänzten OpenJDK-Lizenztext wird betont, dass sowohl das statische als auch das dynamische Linken von OpenJDK den Copyleft-Effekt auslöst, es sei denn, die proprietäre Software, welche eine OpenJDK-Bibliothek aufruft, wird in einem unabhängigen Modul betrieben. Bekannt ist etwa auch eine Ausnahmeklausel der GPLv2-Version, die auf den Linux-Kernel angewendet wird, nach der Anwendungsprogramme, die normale Systemaufrufe durchführen, nicht als „Derivative Work“ gelten. Neben dieser sehr bekannten Modifikation gibt es eine Vielzahl an Projekten, für die eine Reihe von kleineren Veränderungen an den jeweiligen Lizenzen vorgenommen wurden.

Auszug aus dem Text der „Classpath Exception“ (Modifikation der GPLv2 für OpenJDK)
“Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library.”

Nahezu alle Lizenzen verlangen etwa im Rahmen der Distribution die Mitlieferung des jeweiligen Lizenztexts. Zudem wird es häufig verboten, Urheberrechtshinweise zu entfernen, bzw. es werden bestimmte Urheberrechtsnennungen verlangt. Die meisten Lizenzen enthalten auch einen Haftungsausschluss und den Hinweis darauf, dass auf diesen bei der Weitergabe deutlich hinzuweisen ist. Häufig dürfen die Open-Source-Komponenten auch jeweils nur unter ihrer eigenen Lizenz weitergegeben werden. Darauf muss etwa im Rahmen der Einräumung von Nutzungsrechten in Lizenzverträgen geachtet werden. Darüber hinaus bestehen viele unterschiedliche und teilweise sehr spezielle Verpflichtungen.

Die Vielgestaltigkeit der Lizenzen und ihrer Verpflichtungen machen deutlich: Ein Überblick über die verwendeten Drittanbieterkomponenten ist ein erster Schritt im Rahmen eines Open-Source-Lizenzmanagements.

Mögliche Rechtsfolgen bei Verstoß gegen Open-Source-Lizenzpflichten

Ein solcher Überblick ist wichtig, da die Rechteinhaber an den der Open-Source-Komponenten verschiedene Ansprüche gegen den Verletzer einer Open-Source-Lizenzpflicht geltend machen können. In Betracht kommt zunächst ein Anspruch auf Unterlassung der weiteren Lizenzverletzung. Dies bedeutet zumeist auch einen Stopp der weiteren Distribution der jeweiligen Software. Flankierend zum Unterlassungsanspruch steht den Urhebern zumeist auch ein Anspruch auf Beseitigung bestehender Open-Source-Lizenzverletzungen zu. Diese müssen demnach nicht nur Open in der Zukunft unterbleiben, es müssen auch die derzeit bestehenden Open-Source-Verletzungen entfernt werden. Hierzu gehört auch die Löschung bzw. Vernichtung sämtlicher widerrechtlicher Kopien, die sich noch im Verfügungsbereich des Verletzers befinden. Doch damit nicht genug: Es sind zudem Schadensersatzansprüche denkbar. Deutsche Gerichte haben bereits wiederholt bestätigt, dass Urhebern gegen Verletzern von Open-Source- Lizenzen ein Schadensersatzanspruch zusteht.

Überblick über Open-Source-Lizenzen wichtig im Geschäftsverkehr

Ein solider Überblick über die Open-Source-Lizenzen des eigenen Projekts ist außerdem wichtig, weil ein potenzieller Vertragspartner hiernach fragen könnte. Immer häufiger kommt es vor, dass sich Lizenznehmer einer Software in Vertragsverhandlungen dafür interessieren, in welchem Umfang die zu erwerbende Software Open-Source-Komponenten enthält, und was dies für den Lizenznehmer bedeutet. Schlecht ist, wenn erst anlässlich einer solchen Frage eine erste Liste über Open-Source-Komponenten ermittelt werden muss. Gleiches gilt im Übrigen für die Suche von Investoren für Start-ups. Ein Investor wird heute vor einer Beteiligung an einem Geschäftsmodell, dessen hauptsächlicher Wertgegenstand eine Software ist, den Gründern die Gretchen-Frage stellen: Wie hältst du’s mit Open-Source-Bibliotheken?

Hilfe von Maven bei der Erstellung eines Überblicks

Wenden wir uns nun der Aufgabe zu, einen Überblick über die Lizenzen der verwendeten Bibliotheken zu gewinnen. Wie eingangs erwähnt, kann das License Maven Plug-in auch hier unterstützen. Folgende Aufgaben sollen gelöst werden:

  1. Erstellung einer Auflistung der verwendeten Drittanbieterlizenzen
  2. Konsolidierung der Liste der Drittanbieterlizenzen

Mithilfe des Goals license:add-third-party kann eine Liste der verwendeten Drittanbieterlizenzen eines Projekts erzeugt und dem Artefakt hinzugefügt werden. Um die Konfiguration nicht unnötig zu wiederholen, konfigurieren wir add-third-party in unserem Multimodulprojekt license-plugin-demo. Ein erneuter Aufruf von package auf dem Multimodulprojekt führt dazu, dass sowohl für library, als auch webapplication die Drittanbieterlizenzen ermittelt und der Liste hinzugefügt werden.

Die Liste wird im jeweiligen Projekt unter target/generates-sources/license/THIRD-PARTY.txt abgelegt. Wie der Ordner vermuten lässt, findet sich die Datei ebenfalls im fertigen Artefakt wieder. Schauen wir uns die generierte Datei THIRD-PARTY.txt im Projekt library an, wie in Listing 2 dargestellt. Drei Dinge fallen dabei ins Auge:

  • Die Dependency Commons CLI wird unter der Lizenz Unknown license
  • Die Bibliotheken aus dem Apache-Commons-Projekt referenzieren die Apache License in der Version 2.0 unter einem leicht anderen Namen als die Projekte aus dem Apache-HttpComponents-Projekt. Ein kurzer Vergleich der auf den Projektwebseiten angegebenen Lizenzen zeigt jedoch, dass es sich um ein und dieselbe Lizenz handelt.
  • Die Lizenzen von Projekten, die nicht zum ausgelieferten Artefakt gehören, wie beispielsweise JUnit oder die Hamcrest-Bibliothek, sind ebenfalls aufgelistet.
Lists of 9 third-party dependencies des Projekts "library"
     (Unknown license) CLI (commons-cli:commons-cli:1.0 - no url defined)
     (The Apache Software License, Version 2.0) Commons Codec ([..])
     (The Apache Software License, Version 2.0) Commons Lang ([..])
     (The Apache Software License, Version 2.0) Commons Logging ([..])
     (Eclipse Public License 1.0) JUnit (junit:junit:4.12 - http://junit.org)
     (Apache License, Version 2.0) Apache HttpClient ([..])
     (Apache License, Version 2.0) Apache HttpCore ([..])
     (New BSD License) Hamcrest Core ([..])
     (MIT License) SLF4J API Module (org.slf4j:slf4j-api:1.7.10 - http://www.slf4j.org)

Die veraltete Version 1.0 der Bibliothek Apache Commons CLI wurde im Beispielprojekt eingebunden, um zu demonstrieren, wie fehlende Lizenzinformationen im License-Plug-in ergänzt werden können. Die drei beobachteten Probleme lassen sich durch eine entsprechende Konfiguration des License-Plug-ins beheben.

Konsolidierung der Drittanbieterlizenzen

Um mit dem oben beschriebenen Problem umzugehen, führt das License-Maven-Plug-in das Konzept des missingFile ein. Hierbei handelt es sich um eine Datei im Java-Properties-Format, mit deren Hilfe man die fehlenden Informationen ergänzen kann. Die Verwendung von missingFile muss erst in der Konfiguration aktiviert werden, wie in Listing 3 dargestellt. Auch hier bietet sich das Multimodulprojekt an, damit die Konfiguration sich auf beide Module auswirkt.

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>license-maven-plugin</artifactId>
  <version>1.8</version>
  <configuration>
    <useMissingFile>true</useMissingFile>
  </configuration>
  [..]
</plugin>

Führen wir erneut package auf dem Projekt aus, wird im Projekt library die Datei /src/license/THIRD-PARTY.properties angelegt. Ist die Datei am erwarteten Ort nicht vorhanden, erstellt das Plug-in eine leere Vorlage mit den Dependencies, für die keine Lizenzinformationen verfügbar sind. Öffnen wir die Datei, sehen wir, dass Apache Commons CLI bereits als Schlüssel eingetragen wurde. In einem realen Szenario würden wir nun recherchieren, unter welcher Lizenz die betreffende Bibliothek veröffentlicht wird. Bei dieser Recherche sollte äußerst sorgfältig vorgegangen werden, da für einige Open-Source-Projekte bei Wikipedia und anderen Informationsseiten nicht immer die zutreffenden Lizenzen genannt werden. In diesem Fall stellen wir schnell auf der Projektwebsite fest, dass es sich hier um die Apache-Lizenz in der Version 2.0 handelt. Als Wert wird nun in den THIRD-PARTY.properties der vollständige Name der Lizenz angegeben, wie er später in der Lizenzliste erscheinen soll. Wir kopieren einfach die Lizenzbezeichnung eines passenden Eintrags aus der generierten THIRD-PARTY.txt und rufen erneut package auf. Eine erneute Prüfung ergibt: Die CLI-Bibliothek wird nun in der resultierenden Datei mit der richtigen Lizenz angezeigt. Die Datei THIRD-PARTY.properties wurde zwar neu generiert, aber unsere Lizenzinformation wurde dabei nicht überschrieben.

Mithilfe von includeArtifacts und excludeArtifacts können bestimmte Dependencies von der Lizenzauflistung ausgenommen werden. Für unseren Anwendungsfall bietet sich jedoch an, excludeScopes zu verwenden, um alle Dependencies im Test-Scope auszuschließen. Auch die Möglichkeit, gleiche Lizenzen, die unter unterschiedlichen Namen in der Liste auftauchen, auf einen einheitlichen Namen zu bringen, ist interessant. Hierfür ist das Konfigurationselement licenseMerges zuständig. Jede Zeile innerhalb des Elements repräsentiert eine Anweisung zur Zusammenführung von Lizenzen, wobei der erste Eintrag angibt, welche Benennung beibehalten werden soll. Die Alias einer Zeile werden mit dem Zeichen „|“ separiert. Wir fügen der Konfiguration in der POM des Elternprojekts den Eintrag hinzu, wie in Listing 4 zu sehen ist.

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>license-maven-plugin</artifactId>
  <version>1.8</version>
  <configuration>
    <licenseMerges>
      <licenseMerge>
      Apache License, Version 2.0|The Apache Software License, Version 2.0
      </licenseMerge>
    </licenseMerges>
  </configuration>
  [..]
</plugin>

Risikominimierung durch Policies

Je mehr Entwickler an einem Projekt beteiligt sind, umso mehr lohnt es sich, zu Beginn der Entwicklung klare Prozesse über die Implementierung von Open Source Policies zu definieren und den Entwicklern die rechtlichen Implikationen bewusst zu machen. Die entsprechenden Regeln sollten unbedingt auch in Verträgen mit Freelancern oder im Rahmen der Verlagerung von Teilen der Entwicklung an externe Firmen in den entsprechenden Entwicklungsverträgen klar definiert werden.

Die einfachste Regel könnte in einem Verzicht auf sämtliche Open-Source-Komponenten bestehen. Das ist zwar rechtlich sicher, bedeutet aber zugleich auch den Verzicht auf eine Vielzahl attraktiver Ressourcen. Eine abgemilderte Form dieser drastischen Variante könnte in dem Verzicht auf Bibliotheken bestehen, die unter einer Open-Source-Lizenz mit Copyfelt-Effekt stehen.

Für die Überwachung solcher Policies können die Konfigurationselemente excludedLicenses und failIfWarning des Goals license:add-thirdparty eingesetzt werden. Ersteres erlaubt eine Liste von Lizenzen zu konfigurieren, bei deren Verwendung eine Warnung erzeugt werden soll. Aktiviert man zusätzlich noch die Einstellung failIfWarning, schlägt der Build fehl, sobald eine Bibliothek mit einer solchen, verbotenen Lizenz eingebunden wird.

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>license-maven-plugin</artifactId>
  <version>1.8</version>
  <configuration>
    <excludedLicenses>
      <excludedLicense>GNU General Public License (GPL) 1.0</excludedLicense>
      <excludedLicense>GNU General Public License (GPL) 2.0</excludedLicense>
      <excludedLicense>GNU General Public License (GPL) 3.0</excludedLicense>
    </excludedLicenses>
  [..]
</plugin>

Wer verständlicherweise nicht auf Copyleft-Komponenten verzichten will, muss allerdings sicherstellen, dass durch die konkrete Art der Implementierung kein „Derivative Work“ entsteht bzw. der proprietäre Teil der Software nicht mit dem Copyleft-Effekt „infiziert“ wird. Für einfach gelagerte Fälle kann die Policy hierbei grundsätzliche Vorgaben für die Entwickler enthalten. So könnte etwa definiert werden, dass die dynamische Verlinkung einer Bibliothek, die unter der LGPLv2 steht, ohne weitere Prüfungen in der Regel möglich ist, wenngleich die aus C/C++ stammende Einteilung des dynamisch/statischen Verlinkens nicht ohne Weiteres auf Java übertragen werden kann. Generell ist empfehlenswert, dass über die Verwendung einer Copyleft-Komponente ein Projektverantwortlicher entscheidet, der über die notwendigen Kenntnisse verfügt, um das Auslösen des Copyleft-Effekts auszuschließen. Soweit vorhanden, sollte auch die Rechtsabteilung in diesen Prozess eingebunden werden.

Weitere nützliche Maven-Plug-ins

In diesem Beitrag haben wir erläutert, wie man mithilfe des License-Maven-Plug-ins die Einbindung der Lizenz in das eigene Projekt verwalten kann. Ebenfalls haben wir gezeigt, wie das Plug-in bei der Implementierung eines Lizenzmanagements helfen kann.

Bei der Recherche zu diesem Beitrag sind wir auf weitere interessante Maven-Plug-ins gestoßen, die wir hier nicht unerwähnt lassen wollen. Ein alternatives Plug-in zur Pflege der eigenen Lizenz vom Leader der Java User Group Montreal, Mathieu Carbou, steht unter der <groupId>com.mycila zur Verfügung und zielt hauptsächlich darauf ab, einen Lizenzheader in die eigenen Quelldateien zu integrieren. Von der JASIG Group stehen das maven-jasig-legal-plugin und das maven-notice-plugin zur Verfügung, die darauf gerichtet sind, die in der Apache Foundation üblichen NOTICE.txt– und LEGAL.txt-Dateien zu erzeugen und dem Projekt hinzuzufügen.

Kommerzielle Lösungen

Die beschriebenen Möglichkeiten, das eigene Lizenzmanagement mit den genannten Maven-Plug-ins zu unterstützen, reichen manchmal nicht aus, um in einer großen Organisation an umfangreichen Softwareprojekten arbeiten zu können und gleichzeitig auch strenge Open Source Policies zu implementieren. Auch kann es sein, dass das Management detaillierte Monitoringinstrumente einfordert, die über eine automatisch aktualisierte Liste von Dependencies und ihren Lizenzen hinausgeht.

Für diesen Fall bieten eine Reihe von Softwareanbietern Produkte an, um ein Lizenzmanagement zu implementieren. Als Beispiel ohne Anspruch auf Vollständigkeit seien hier Sonatype Nexus mit CLM, Black Duck Protex oder WhiteSource genannt. In diesen Systemen können Policies definiert und gepflegt werden. Ihre Einhaltung wird an neuralgischen Punkten im Produktlebenszyklus überwacht, um möglichst früh auf eventuelle Risiken hinweisen zu können. Auf die eine oder andere Weise stellen die Produkte Lösungen für bekannte Entwicklungswerkzeuge wie Plug-ins für Entwicklungsumgebungen, Build-Werkzeuge und CI-Server zur Verfügung. Ob sich die Investition in ein solches System lohnt, muss sicherlich von Unternehmen zu Unternehmen entschieden werden, da je nach Zielgruppe, Größe und Markt die Frage nach Open-Source-Risiken anders zu bewerten sein ist.

Aufmacherbild: open Source von Shutterstock / Urheberrecht: v.schlichting 

Geschrieben von
Markward Schubert
Markward Schubert
Markward Schubert arbeitet seit über zehn Jahren als Softwareentwickler und hat umfangreiche Erfahrungen in verschiedenen Java-Projekten gesammelt. Neben der Entwicklung gilt sein Interesse Themen rund um DevOps, Build-Management und Continuous Delivery.
Dr. Lutz Keppeler
Dr. Lutz Keppeler
Dr. Lutz M. Keppeler beschäftigt sich als Rechtsanwalt mit IT- und datenschutzrechtlichen Themen. Neben der Beratung von Mandanten aus diesem Bereich hält er auch Fachvorträge zu aktuellen Themen aus diesen Gebieten. Ein besonderer Schwerpunkt seiner Tätigkeit liegt in dem Bereich des Open-Source-Lizenzrechts.
Kommentare
  1. Robert Reiz2016-07-23 12:48:09

    Guter Artikel. Bietet einen guten Einstieg in die Lizenz Thematik. Bei den kommerziellen Lösungen wurde hier auf Sonatype und BlackDuck verwiesen. Ich würde auch gerne auf VersionEye hinweisen. Im Gegensatz zu BlackDuck und Sonatype CLM ist VersionEye open source und die Firma dahinter sitzt in Mannheim / Deutschland.

    VersionEye löst auch einige Probleme die in dem Artikel hier angesprochen wurden. Z.B. hat VersionEye bereits eine sehr gute Implementierung für Lizenznormalisierung. Unterschiedlich geschrieben Varianten von Apache-2.0 z.B. werden immer als Apache-2.0 Erkannt und in der UI wird immer der SPDX-Identifier angezeigt.

    Ein anderes cooles Features ist die Lizenz Whitelist. Das VersionEye Maven Plugin kann bei jedem Build auf dem CI server die tatsächlich verwendeten Lizenzen gegen eine Lizenz Whitelist auf dem Server abgleichen und bei einer Verletzung der Whitelist wird der Build gebrochen und die Entwickler kriegen sofort Feedback. Im Gegensatz zu BlackDuck sind die VersionEye scans und checks sehr schnell und vor allem transparent (open source).

    Das ganze funktioniert nicht nur für Maven sonder auch für 11 andere Packet Manager wie z.B. NPM, PiP, Bundler, Bower und viele mehr.

    Das hier gezeigte Maven Plugin hat allerdings ein paar coole Feature die VersionEye noch nicht hat. Wie z.B. das automatische erzeugen der class Header. Ich fände es gut wenn beide open source Projekte zusammen arbeiten würden :)

    * Disclaimer - Ich bin der Gründer von VersionEye.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.