Dual-Licensing am GFZ - ein Fallbeispiel¶

Als einen spezifischen Anwendungsfall für das Transfermodell Dual Licensing wird an dieser Stelle ein Fall beschrieben, bei dem Software im Bereich der Fernerkundung entwickelt wurde und von einem kleinen (<5 Personen) Entwicklerteam verwertet werden sollte. Alle Entwickler:innen sind beim GFZ angestellt, das Intellectual Property liegt also direkt bei der Forschungseinrichtung. Es gab keine Contributions von Externen.

Die Python-Software wurde von Anfang an mit dem Ziel entwickelt, diese zu verwerten. Auch wenn die Idee zur Software initial durch einen internen Bedarf entstand, war schnell klar, dass ebenfalls ein Interesse für außerwissenschaftliche Zielgruppen (NGOs, Behörden, ggf. sogar die Industrie) vorhanden sein könnte, was durch eine erste Marktrecherche bestätigt wurde. Die Entwicklung der Software dauerte mehrere Wochen über ca. ein Jahr gestreckt, aktueller Entwicklungsstand ist durch TRL 7 zu charakterisieren. Die Software wurde über den Softwaremeldeprozess der Einrichtung gemeldet, um Lizenzabhängigkeiten zu überprüfen und die Beratung des Technologietransfers in Anspruch zu nehmen bezüglich der weiteren Schritte für eine erfolgreiche Verwertung.

Potenzialanalyse¶

Entsprechend der Bewertungskategorien, die im Rahmen des SoftWert-Projekts entstanden sind, lässt sich der hier beschriebene Anwendungsfall als Superstar kategorisieren. Dabei konnten alle Fragen beantwortet werden. Es wurde kein kritischer Bereich identifiziert. Die Bewertung wurde gemeinsam vom Entwicklerteam und dem Technologietransfer durchgeführt. Einzige Herausforderung bei der Bewertung war, dass nicht alle Fragen für die Einschätzung und den spezifischen Kontext zur Software relevant waren, dass lässt sich jedoch bei Benutzung des Tools einstellen.

Entscheidungshilfe Softwarelizenzierung¶

Im nächsten Schritt wurde mit Hilfe der im Projekt entstandenen Entscheidungshilfe ein Transferweg priorisiert. Dual-Licensing bietet sich als Transferweg für den hier beschriebenen Fall an, da sowohl Bedarfe für die wissenschaftliche Community als auch für wirtschaftliche Stakeholder identifiziert wurden, man aber der Wissenschaft eine kostenlose Nutzung ermöglichen will im Sinne des Open Science Gedankens. Entscheidend für die Verwertung ist bei diesem Projekt auch die hohe Motivation des Entwicklerteams, da professionelle Softwareentwicklung auch zusätzliche Aufwände bedeuten, wie z.B. eine gute Dokumentation der Software, ein strukturiertes Packaging der Software inklusiver Testautomatisierungen und einen hohen Grad an Nutzerfreundlichkeit. Die größte Herausforderung wird es zukünftig sein, das Marktpotenzial noch genauer abzuschätzen. Die Software wird vor der dualen Lizenzierung zunächst einmal komplett frei für einen bestimmten Testzeitraum zur Verfügung gestellt (wenn sich Kunden melden, werden individuelle Vereinbarungen zur Nutzung im Testzeitraum getroffen) und evaluiert, ob die Software eine Nachfrage bedienen kann.

Für den hier beschriebenen Anwendungsfall war die Entscheidungshilfe nicht unbedingt notwendig, da dem Entwicklerteam alle Rahmenbedingungen von Anfang an bekannt waren und mit dem Ziel einer Verwertung entwickelt wurde, insbesondere durch die enge Zusammenarbeit mit dem Technologietransfer von Beginn an. Die Beantwortung der Fragen der Entscheidungshilfe wäre aber wie folgt verlaufen:

Vollständige Verwertungsrechte sind vorhanden
Lizenzen sind alle kompatibel
Kein Copyleft Code enthalten
Kann zu lizenzierfähigem Produkt weiterentwickelt werden
Primäres Ziel: Einnahmen generieren
Mit Ausgestaltung fortfahren (=Output)

Geschäftsmodell¶

Zur Wahl des passenden Geschäftsmodells wurde der Entscheidungsbaum für die Wahl des Geschäftsmodells wie folgt durchlaufen:

Weg durch den Entscheidungsbaum

Ergebnis: Duale Lizenzierung

Eine Duale Lizenzierung erfordert ein strenges Copyleft, damit Weiterentwicklungen durch Dritte wieder zurück an die Einrichtung kommen. Deshalb wurde sich für die für EUPL v1.2 (Anwendung europäisches Recht plus Abdeckung SaaS Fall) für die Community-Version und die Erstellung einer proprietären EULA für die kommerzielle Version (Genehmigung zur Einsicht, Nutzung, Modifikation erlaubt, aber keine Code Weitergabe an Dritte durch Lizenznehmer). Dieser Enduser-Vertrag gilt standardmäßig für alle Interessenten (keine Individuallösungen) und über eine Laufzeit von einem Jahr, automatische Verlängerung wenn nicht innerhalb der Kündigungsfrist gekündigt, automatische Verlängerung umfasst auch alle Updates/Weiterentwicklungen, wenn Vertrag ausgelaufen ist, darf Software nicht weiter unter EULA Bedingungen genutzt werden (Rückfall auf strenge Copyleft Regeln). Es wurde eine bestimmten, einheitliche Jahresgebühr festgesetzt. Zusätzlich wurde für mögliche Weiterentwicklungen durch Dritte ein CLA (Contributor License Agreement) erstellt. Alle potenziellen, externen Contributoren verpflichten sich der Einrichtung alle Verwertungsrechte einzuräumen (auch kommerziell), im Umkehrschluss verpflichtet sich GFZ diese Beiträge immer Open Source (unter EULA v1.2) für alle zur Verfügung zu stellen. Die Ausarbeitung des Vertrags und des CLA wurde in Kooperation mit Rechtsabteilung durchgeführt, für die Preisfindung wurde die Transfer- und Finanzabteilung eingebunden. Sobald alle Genehmigung erteilt sind und alle notwendigen Dokumente vorhanden sind, wird die Software Open Source gestellt und beworben (z. B. Helmholtz Research Directory, Zenodo, PyPi, Teamwebsite, LinkedIn).

Fazit¶

Die Entwicklungszeit wurde zielstrebig mit dem Ziel der Verwertung verfolgt. Die Software ist ein kleines Tool, „from scratch“, aber mit klaren Vorstellungen. Es bietet auch Wissenschaftler:innen einen signifikanten Mehrwehrt und ersetzt ein älteres, auslaufendes Tool, von dem Akteure vom Mark bereits schon kostenfrei profitieren konnten. Insgesamt war der Entwicklungs- und Verwertungsprozess sehr stringent, da alle an einem Strang gezogen haben. Der Erfolg des Transfermodells muss noch bewertet werden (Projekt aktuell noch in der Schlussphase), hier ergibt sich ein möglicher Fallstrick, dass nicht absehbar ist, wie viele Kunden das Produkt am Ende tatsächlich so lizenzieren werden (Erfolg schwer abschätzbar). Der Prozess hat insgesamt ein Jahr in Anspruch genommen, aber die Nettozeit für die reine Software-Entwicklung war deutlich geringer (ca. 1/2 Jahr). Der Evaluationsprozess ist noch nicht abgeschlossen, was man zum jetzigen Zeitpunkt schon sagen kann, ist dass es einige potenzielle Kunde gibt und vor allem durch das Angebot eines Testzeitraums und flankierende Services wie User-Workshop Interesse geweckt wurde.