Implementierung von Lizenzmodellen in .NET, Teil 1

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).