Implementierung von Lizenzmodellen in .NET, Teil 1

Know-how  –  0 Kommentare

Jeder, der Software entwickeln möchte, muss sich mit den Themen Lizenzen und Lizenzmodelle auseinandersetzen. Je nach Anwendungsgebiet der eigenen Software kommt auch noch das Thema Lizenzrecht mit hinzu.

Ganz gleich, ob es sich bei dem eigenen Stück Software um ein Open-Source-Projekt oder um etwas Kommerzielles handelt, früher oder später tauchen Fragen zur Lizenzierung auf. Zudem hat sich in den vergangen Jahrzehnten die Welt der Lizenzen stetig weiterentwickelt. Klobige Disketten oder andere Datenträger mit Lizenzinformationen sind gar nicht mehr oder, im Falle von Dongles, nur noch in bestimmten Szenarien anzutreffen. Grund genug, einen Blick auf Lizenzen, Lizenzmodelle und den aktuellen Entwicklungsstand ihrer Implementierung in .NET zu werfen.

Zunächst ist zu klären, was überhaupt eine Lizenz ist. Ganz allgemein bedeutet das lateinische Wort Licentia Freiheit oder Erlaubnis. Es gibt unterschiedliche Begriffe, die mit dem Wort Lizenz assoziiert werden. Der Duden listet unter anderem neu, begehrt, gültig, teuer und staatlich auf.

Zum einen ist eine Lizenz daher, abgeleitet aus der obigen Definition, eine Erlaubnis. In der Regel eine erteilte Erlaubnis, da eine bestimmte Freiheit besteht, etwas zu tun, was ohne Lizenz nicht erlaubt wäre. Beispielsweise die bekannte "Lizenz zum Töten" vom ebenso berühmten wie fiktiven Geheimagenten James Bond.

Zum anderen ist eine Lizenz aber auch ein Dokument. Es enthält Informationen zur erteilten Erlaubnis, etwa was sie enthält und was eben nicht erlaubt ist. Üblich sind alle Arten von Dokumenten, wie Dateien, gedruckte Dokumente, Scheckkarten oder Ähnliches. Die Lizenz zum Fahren eines Fahrzeuges, zum Beispiel der Klasse B für PKWs, bezieht sich eben nicht nur auf die Erlaubnis. Das Dokument, in dem Fall der Führerschein, ist ebenso wichtig, da es als einziges Auskunft über die Erlaubnis geben kann. Eine Lizenz hat demnach materielle und immaterielle Ausprägungen, die eng miteinander verzahnt sind. Sie werden gern als organisatorische und technische Sicht beschrieben.

Recht und Lizenzen

Natürlich gibt es bei Lizenzen eine rechtliche Seite. Von ihr aus betrachtet, sind Softwarelizenzen nichts anderes als Verträge, für die der Grundsatz der Vertragsfreiheit gilt. Das bedeutet, dass sich der Lizenzgeber und der Lizenznehmer über den Umfang der Lizenzvereinbarung und der damit übertragenen Rechte beliebig einigen dürfen.

Software-Lizenzen sind da noch mal ein Thema für sich, denn bei Standardsoftware gilt häufig das Friss-oder-stirb-Prinzip. Wer Millionen Exemplare seiner Standardsoftware verkauft, hat gar nicht die Kapazität, um mit jedem einzelnen Endverbraucher die Nutzungsrechte im Einzelnen zu verhandeln. Wie der Anwender dabei den Inhalt des Lizenzvertrags zu Gesicht bekommt, spielt keine Rolle. Wichtig ist nur, dass der Vertrag vor Vertragsabschluss vereinbart wurde. Und genau das ist in den meisten Situationen gar nicht der Fall, beispielsweise weil die Software, die einen Lizenzvertrag im Installationsprogramm anzeigt, zu diesem Zeitpunkt schon lange käuflich erworben wurde.

Bei Software-Lizenzen kommt des Weiteren hinzu, dass es viele unterschiedliche Arten gibt. Abbildung 1 fasst einige bekannte Kategorien von Lizenzierungsmodellen zusammen, sowohl für freie als auch für kommerzielle Software. Ursprünglich stammt diese visuelle Zusammenfassung von Chao-Kuei (siehe GNU Projekt, "Kategorien freier und unfreier Software") und wurde seitdem häufig angepasst. Jede der Lizenzkategorien aus Abbildung 1 hat andere Anforderungen an die Lizenzierung und das dahinterliegende Lizenzmodell. Dieser Artikel konzentriert sich im Folgenden auf den rot markierten Bereich, da in der Regel nur in ihm softwaregestützte Lizenzmodelle notwendig sind.

Übersicht bekannter Lizenzierungsmodelle (Abb. 1)

Anwendertypen, Angemessenheit

Sind Lizenzen notwendig?

Die Frage, ob Lizenzen nötig sind, taucht gleichzeitig mit den Überlegungen zu Lizenzen und Lizenzmodellen auf. Abbildung 1 hat schon einen kurzen Einblick dazu gegeben. In der Regel sind für die nicht rot markierten Kategorien zwar Lizenzen erforderlich, es reicht aber aus, sie der Software beizulegen. Andere technische Maßnahmen oder Einschränkungen, beispielsweise um sicherzustellen, dass tatsächlich eine gültige Lizenz vorhanden ist, sind nicht erforderlich.

Im kommerziellen Bereich sieht das beileibe ganz anders aus. Hier lautet das Motto schlicht: Geld verdienen. Viele Geschäftsmodelle basieren ausschließlich oder zu einem großen Teil darauf, Lizenzen für eine Software zu verkaufen. Zum einen, um direkt Umsatz zu generieren, zum anderen um Dienstleistungen für die Software zu verkaufen. Wie gut derartige Businessmodelle in Zukunft noch funktionieren werden, muss sich zeigen. Produkte zu verkaufen, die ohne viel Aufwand kopierbar sind, fällt allerdings recht schwer. Viele Hersteller haben die Erfahrung schon machen müssen.

Im Jahr 2011 brachte die Software Alliance eine weltweite Studie heraus, in der sie globale Zahlen zur Softwarepiraterie veröffentliche. Ihr zufolge liegt der weltweite Anteil der Benutzer, die Raubkopien verwenden, bei 42 Prozent. Vier von zehn Anwendern nutzen demnach illegale Kopien von Softwareanwendungen. Für Westeuropa liegt der Anteil der Studie noch bei 32 Prozent. Für Zentral- und Osteuropa werden gar 62 Prozent angegeben. Erschreckende Zahlen, die zeigen, wie weitverbreitet der Einsatz von nicht oder nur unzureichend lizenzierten Softwareprodukten ist.

Allerdings beschreibt das nur den technischen Hintergrund von Lizenzen. Wie erwähnt, gibt es darüber hinaus eine organisatorische Sichtweise. Dazu gehört auch die Berücksichtigung unterschiedlicher Anwendertypen, die mit der zu lizenzierenden Software in Kontakt kommen. Damit ist gemeint, wie die (potenziellen) Anwender zu kommerzieller Software beziehungsweise zu bestimmten Lizenzmodellen stehen. Oft ist auch die Einstellung zu Lizenzen und Software an sich entscheidend. Es gibt auf der einen Seite das Extrem der immer braven Anwender, die nicht einmal illegal kopieren, wenn es einfach ist. Und es gibt das andere Extrem von Anwendern, die kein Problem damit haben, einen größeren Aufwand zu betreiben, um eine Software kostenfrei nutzen zu können.

App-Stores zeigen eine große Bandbreite von Anwendertypen. Viele sind beispielsweise nicht dazu bereit, selbst einen kleinen Betrag für eine App auszugeben, wenn es eine Light-Version gibt. Selbst dann nicht, wenn die volle Version der Anwendung nützliche Features mitbringt oder die in der Light-Version enthaltende Werbung störend ist. Das Unterscheiden zwischen digitalen und realen Gütern ist bei vielen Menschen noch immer sehr stark.

Anwendertypen

Abbildung 2 zeigt ein Diagramm mit verschiedenen Anwenderkategorien. Die prozentuale Verteilung ist in dem Fall nicht relevant, da nur die Kategorien visualisiert werden sollen. Ganz davon abgesehen, dass eine Verallgemeinerung der Verteilung schwierig ist, da sie natürlich auch von der Anwendung und der Zielgruppe abhängt. Alle Anwender haben eine andere Intention, wenn es darum geht, eine Anwendung zu kaufen. Geld verdient wird mit der in grün dargestellten Gruppe "Software ist ihr Geld wert" und mit der orangen "Zahle aus Angst". Im ersteren Fall ist das sicherlich positiv, im letzten vielleicht nicht ganz so erfreulich. Die anderen drei Gruppen sind nicht bereit, Geld auf den Tisch zu legen. Und in der Regel wird das die größere Gruppe potenzieller Anwender und Anwenderinnen sein.

Unterschiedliche Anwendertypen und deren Einstellung zu kommerzieller Software (Abb. 2)


Mögliche Käufer und Käuferinnen der gelben (Software ist zu teuer) und der blauen (Software hat keinen Nutzen) Kategorie lassen sich durch ein Lizenzmodell schwer zu einem Kauf verleiten. Personen aus der blauen Kategorie können vielleicht noch über neue Features, Fehlerbehebungen oder sonstige Anpassungen der Software zu einem Kauf bewogen werden. Empfinden sie die Software allerdings als zu teuer, muss sich das Kosten-Nutzen-Verhältnis schon sehr stark ändern, um die Meinung noch zu ändern. Meistens gelingt das nur über viele Versionen hinweg und nicht von heute auf morgen.

Die graue Kategorie "Raubkopie ist einfach zu bekommen" ist allerdings genau die Zielgruppe für Softwarelizenzen. Denn hier lässt sich durch ein gutes Lizenzmodell viel herausholen. Zumindest wenn die Anwender Potenzial in der Software erkennen und die Software nicht nur nutzen, weil sie kostenfrei zur Verfügung steht und die eigentlich in Anwenderaugen bessere Software nicht oder nicht so leicht zu kopieren ist.

Angemessenheit und Sicherheit

Das Thema Angemessenheit ist dabei in allen Überlegungen zum Thema Lizenzmodelle und Lizenzierung immens wichtig. Sicherheit lässt sich in der Regel nur auf Kosten des Komforts erreichen. So auch beim Thema Lizenzierung. Ein ausgeklügeltes, mehrfach abgesichertes Lizenzkonzept verlangt dem Anwender nicht selten ein paar Einschränkungen oder Klimmzüge ab. Ständiges Aktivieren, die Eingabe von ellenlangen Schlüsseln oder das Hantieren mit verschiedenen Lizenzdateien sind hier nur einige bekannte Bespiele. Doch auch das kann Anwender vergraulen.

Oft wird das Thema Sicherheit aber auch unverhältnismäßig behandelt. In dem Fall investieren Entwickler viel Geld, Zeit und Mühen, um eine Software bestmöglich abzusichern, nur um dann recht schnell festzustellen, dass der betreffende Schutz doch deutlich schneller geknackt werden konnte als gedacht. Besonders die Spielebranche ist immer wieder mit einer derartigen Situation konfrontiert. Gerade wenn Lizenzierungen auf externe Daten angewiesen sind, ein Datum etwa, geht es vergleichsweise schnell, bis jemand versucht, einen Umweg zu gehen. Auch Sprachen, die eine Zwischensprache erzeugen, sind prädestiniert dafür, dass ab einem gewissen Bekanntheitsgrad der Software jemand nachschaut, ob im Code nicht etwas Interessantes verborgen ist.

Daher gilt auch beim Thema Lizenzen: Sicherheit ist eine Illusion und das Versprechen 100-prozentiger Sicherheit eine Lüge. Die Angemessenheit beim Einsatz von Sicherungsmaßen darf daher niemals aus den Augen gelassen werden. Oder um noch einmal auf die Spielebranche zurückzukommen: Auch die dauerhafte Verbindung zum Server ist mittlerweile ein nicht mehr allzu großes Hindernis, vergrault aber zusehends die ehrliche Käuferschaft und geht regelmäßig nach Hinten los.

Vorüberlegungen

Ein Lizenzmodell für eine Software zu etablieren ist in der Regel kein leichtes Unterfangen. Es gibt einige Punkte zu beachten, die nicht nur das Lizenzmodell an sich beeinflussen, sondern auch die Anwendung, die entsprechend auszustatten ist. Zu beachten ist dabei, dass nicht jedes Modell für jede Anwendung passt – sowohl aus organisatorischer als auch aus technischer Sicht. Folgende Eckpunkte gilt es bei einer Lizenzierung zu berücksichtigen:

  1. Art des Lizenzmodells
  2. Verfügbare Lizenzierungsattribute
  3. Lizenzmanagement
  4. Lizenzierungsprozedur
  5. Lizenz-Deployment

Im Grunde beeinflussen alle Punkte das Lizenzmodell sowohl aus technischer als auch aus organisatorischer Sicht. Die ersten beiden wirken sich allerdings etwas stärker auf die technische aus, die verbleibenden drei auf die organisatorische. Unter der Art des Lizenzmodells wird die grobe Ausrichtung verstanden. Soll es beispielsweise die Zeit oder Feature zur Grundlage nehmen, lassen sich einzelne Komponenten lizenzieren oder basiert das Lizenzmodell auf dem Verbrauch von Ressourcen.

Anhand derartiger Überlegungen lassen sich verfügbare und für das Modell nutzbare Lizenzierungsattribute auswählen. Mit ihnen sind alle Daten und Eigenschaften gemeint, die sich innerhalb einer Lizenz nutzen lassen. Ein Lizenzmodell, das auf einzelne Features beziehungsweise Komponenten einer Anwendung zugeschnitten ist, muss auch Informationen über die Features und Komponenten besitzen. Ähnlich ist es bei Modellen, die eine Identität oder die Zeit zugrunde legen. Die besagten Daten müssen allerdings nicht nur bei der Lizenzerstellung bereit stehen, sondern auch in der Anwendung, um die Gültigkeit zu prüfen.

Je komplexer das Lizenzmodell, desto komplexer sind häufig die nötigen Daten. Ein Lizenzmodell auf Identitätsbasis kann auch bedeuten, dass einzelne Arbeitsplätze zu lizenzieren sind oder die Anzahl eingeloggter Benutzer zu überwachen ist.

Auch die Anwendung beziehungsweise das angepeilte Einsatzszenario kann die Lizenzierungsattribute vorgeben. Muss eine Anwendung zwingend in einem Offline-Szenario, also tatsächlich ohne Netzwerk oder gar Internet auskommen, sind an Zeitstempel gebundene Verfahren schwer bis gar nicht sicher zu realisieren. Denn woher soll man in ihnen eine zuverlässige Zeitangabe nehmen?

Daher sind die Art des Lizenzmodells und die verfügbaren Lizenzierungsattribute eng miteinander gekoppelt. Bevor also zu einem Lizenzierungsmodell oder einer technischen Realisierung gegriffen wird, ist gut zu überlegen, welche Szenarien abzudecken sind. Soweit technisch möglich, sollte die zugekaufte oder selbst implementierte Lösung auch den Wechsel zwischen Lizenzierungsmodellen erlauben.

Lizenz-Patterns

Software Licensing Patterns

In vielen Bereichen der Informatik haben sich Muster etabliert, die häufig aufkommende Design-Entscheidungen vereinfachen sollen. Nicht nur für die Implementierung, sondern auch für die Kommunikation über ein bestimmtes Design. Am besten bekannt sind sicherlich die Design Patterns der sogenannten Gang of Four, die mittels Unified Modelling Language (UML) beschrieben werden.

Aber auch für die Lizenzierung von Software beziehungsweise konkret für die Lizenzmodelle haben sich Muster etabliert. Allerdings sind die sogenannten Policy Patterns weit weniger bekannt. Ihr Name ist nicht ganz unproblematisch, da es auch das Policy-basierte Design gibt, was an ein Idiom der Programmiersprache C++ angelehnt ist und allgemein häufig Policy Pattern genannt wird.

Die hier gemeinten Muster haben damit aber wenig gemein und lassen sich gut mit dem Begriff Software Licensing Patterns beschreiben, da das dem Einsatzgebiet deutlich besser entspricht. Abbildung 3 fasst die bekannten Muster zusammen und ordnet sie zudem in eine hierarchische Beziehung ein.

Zusammenfassung bekannter Software Licensing Patterns (Abb. 3)


Das Software License Module ist der Wurzelknoten dieses Baums. Konkret betrachtet handelt es sich dabei um ein abstraktes Muster (Abb. 4), da es nur das allgemeine Vorgehen eines Lizenzierungssystems beschreibt. Wichtig ist es hauptsächlich für die Beziehungen im Baum, da sonst ein Wurzelknoten fehlen würde.

Das Software License Module als allgemeines Muster dargestellt (Abb. 4).


Alle anderen Policy Patterns sind direkt oder indirekt von diesem Muster abgeleitet. Viele sind sehr gut bekannt, da sie in vielen Anwendungen zum Einsatz kommen. Auch wenn bei der Implementierung vielleicht gar nicht klar war, dass sich dazu ein Muster herausgebildet hat.

Abbildung 5 zeigt den schematischen Aufbau des Time-based Pattern. Dabei handelt es sich um ein häufig eingesetztes Muster, um Anwendungen mit einem Verfallsdatum auszustatten.

Struktur des Time-based Pattern (Abb. 5)


Die klassische Shareware gehört zu den wohl bekanntesten Anwendungsfällen, obwohl diese Form der Lizenzierung durch Cloud-Anwendungen oder allgemeiner über das Web bereitgestellte Angebote zunehmend an Bedeutung verliert. Der Aufbau der Abbildung 5 sieht deutlich komplexer aus, als das in Wahrheit bei einer Implementierung der Fall ist. Neben dem Lizenzmanager sind noch Komponenten notwendig, die Zeitangaben konvertieren, zurückliefern und verarbeiten können. In dem Fall übernehmen der Time Unit Counter und der Time Checker diese Aufgaben. Eine zentrale Rolle übernimmt der Zeitgeber, der bewusst außerhalb des zu lizenzierenden Systems angesiedelt ist. Er sollte sofern möglich nicht auf dem selben System implementiert sein, da Manipulationen in dem Fall zu einfach zu bewerkstelligen sind.

Ein weiteres, sehr bekanntes Muster ist das Node-Locked License Pattern, das zudem unter dem Namen Named Host License Pattern bekannt ist. Dabei geht es darum, die Anwendung auf eine bestimmte Anzahl von Maschinen zu begrenzen. Abbildung 6 zeigt das Muster in der schematischen Darstellung. Beim Einsatz geht es vor allem um das Vermeiden eines Dongle oder sonstigen Sicherungsmaßnahmen. Denn auch darüber lässt sich eine Software auf eine Maschine begrenzen. Allerdings ist das selten wirklich praktikabel. Beispielsweise in Universitäten, wo im Hochschulnetz eine Software genutzt werden darf, aber eben nur in bestimmten Räumen. Hier manuell, ob per Datei oder Dongle, die Lizenzierung sicherzustellen ist deutlich zu aufwändig. Die Komponente System Registry aus Abbildung 6 ist übrigens nicht wörtlich zu nehmen. Dabei handelt es sich lediglich um einen zentralen Speicher zur Lizenzverwaltung.

Das Node-Locked License Pattern in der schematischen Darstellung (Abb. 6)


Wie bei den schon kurz erwähnten Entwurfsmustern gibt es auch bei den Policy Patterns Muster, die ihrerseits aus weiteren Mustern zusammengesetzt sind. Abbildung 7 zeigt das Schema des Evaluation-Musters. Wie so häufig sind die zusammengesetzten Patterns sehr abstrakt und delegieren die eigentliche Arbeit an die aggregierten Muster.

Das Evaluation-Pattern ist ein Beispiel für ein zusammengesetztes Muster (Abb. 7).

Fazit

Das Thema Lizenzen gehört nicht zu den einfachsten Themengebieten der Softwarebranche. Da ist es nicht verwunderlich, dass es im Rahmen eines Softwareprojekts häufig gar nicht erst zu den notwendigen Vorüberlegungen für ein passendes Lizenzmodell kommt.

Dennoch sollte das Thema nicht zu lange beiseite geschoben werden, da Lizenzen Auswirkungen auf die zu implementierende Software haben können und sich diese Effekte in der Anfangszeit des Projekts besser abschätzen und einplanen lassen.

Fabian Deitelhoff
lebt und arbeitet in Dortmund. Er ist als freier Autor, Pluralsight-Autor, Sprecher und Softwareentwickler im .NET-Umfeld tätig. Er hat ein E-Book über "Implementierung von Lizenzmodellen in .NET" verfasst, in dem sich mehr zum Thema nachlesen lässt.