To top
Resources Resources
[Translate to German:]

Nested Product Items

Eine Lösung für verschiedene Anforderungen: Die Nested Product Items erleichtern die Lizenzkonfiguration, vermeiden Inkonsistenzen bei der Lizenzierung modularer Software und garantieren einen reibungslosen Lizenztransfer. Die Schachtelung von Lizenzen gepaart mit Vererbung erfüllen die Wünsche so manchen Produktmanagers und vertreiben die Kopfschmerzen des für Lizenzierung zuständigen Entwicklers.

Redundante Informationen vermeiden

Schaut man sich Lizenzen an, die von Softwareherstellern in CmContainer programmiert werden, findet man häufig bestimmte Einträge in mehreren Lizenzen. Die Jahreslizenz einer Softwaresuite enthält Lizenzen für mehrere Produkte, aber alle haben dasselbe Ablaufdatum. Eine modulare Software, bestehend aus mehreren Lizenzeinträgen (Product Items) hat den gesetzten Wartungszeitraum in jeder Lizenz stehen. Bei der Verlängerung muss man dann für jede Lizenz einzeln diese Werte umprogrammieren. Das ist mühsam und fehleranfällig.

Für diese Anwendungsfälle und andere Anforderungen, die wir später noch kennenlernen werden, wurden die Nested Product Items entworfen. Diese verschachtelten Lizenzeinträge ermöglichen es, gemeinsame Eigenschaften nur einmal zu setzen und doch überall zur Verfügung zu haben. 

Verschachtelung von Lizenzen

Ein Lizenzeintrag, das sogenannte Product Item, kann verschiedene Optionen enthalten. Mit ihnen kann der Softwarehersteller seine Lizenzierung modellieren, wie zum Beispiel:

  • Zeitliche Einschränkungen: Festes Ablaufdatum oder vorgegebener Nutzungszeitraum ab der ersten Benutzung
  • Lizenzanzahl
  • Einheitenzähler: Herunterzählen in variabler Menge, z.B. bei Verwendung einer bestimmten Funktionalität
  • Daten: In verschiedenen Datentypen können geheime Schlüssel, geschützte Informationen oder lesbare Daten hinterlegt werden.

Mit den Nested Product Items besteht jetzt für Lizenzen in einem Universal Firm Code die Möglichkeit, einen Lizenzeintrag unter einen anderen zu hängen. Letzteren nennen wir Module Item. So ein Module Item kann ebenfalls alle Optionen eines Product Items haben; es gibt diesbezüglich keine Einschränkungen. Ein Product Item kann also kein, ein oder mehrere Module Items enthalten. Die Schachtelungstiefe ist 1, das heißt, ein Module Item selbst kann kein untergeordnetes Module Item haben.

Vererbung der Optionen

Das Besondere an dieser Verschachtelung ist, dass die Module Items alle Eigenschaften von ihrem Eltern-Product Item erben. Wenn man aber in einem Module Item eine schon im Eltern-Product Item gesetzte Lizenzoption explizit setzt, überschreibt dieser Wert den geerbten. Es handelt sich also im informationstechnischen Sinne um klassische Vererbung.

Schauen wir uns mal ein konkretes Beispiel an: eine Demo-Lizenz einer Bürosoftware. Die verschiedenen Applikationen (Textverarbeitung, Tabellenkalkulation, Adressdatenbank) sollen 30 Tage getestet werden können. Die Lizenzmodellierung könnte dann so aussehen: ein Product Item „Demo Paket“ mit einem gesetzten Nutzungszeitraum von 30 Tagen und darunter drei Module Items für die drei Applikationen. Startet der Anwender nun die Tabellenkalkulation, wird der im Product Item gespeicherte Nutzungszeitraum angebrochen; der damit festgelegte Startzeitpunkt gilt für alle Module Items.

Geteilte Lizenzbelegung

So wie in diesem Beispiel der Nutzungszeitraum nur einmal vorhanden ist, wird auch die gegebene Lizenzanzahl zentral verwaltet. Die vorhandenen Lizenzen werden abhängig vom verwendeten Zugriffsmodus belegt. Wenn unsere Demo-Lizenz eine Einzelplatz-Lizenz ist, steht im Product Item eine Lizenzanzahl von „1“. Greifen die Softwarepakete mit User Limit (pro gestarteter Applikation eine Lizenz notwendig) zu, kann nur eine der Applikationen gleichzeitig laufen; versucht man, eine weitere zu starten, ist keine Lizenz mehr frei. Sind die Applikationen aber mit Station Share verschlüsselt (alle Zugriffe desselben Rechners teilen sich eine Lizenz), können auch alle Applikationen gleichzeitig laufen.

Verwendung ohne Veränderung

Bei der geschützten Applikation gibt es meist keinen Änderungsbedarf. Wenn ein Softwarehersteller jetzt schon seine modulare Software über verschiedene Product Items abbildet, kann er einfach die Lizenzeinträge umorganisieren. Für den Lizenzzugriff in der Software ist es egal, ob die benötigte Lizenz in einem Product Item oder in einem Module Item hinterlegt ist. Die Zugriffe aus der Applikation, sei es über den AxProtector oder eines der APIs, sehen die effektive Lizenz, also das Module Item inklusive der vererbten Eigenschaften. Das gilt genauso für die Kryptographie: Ob ein Schlüssel im Eltern-Product Item oder im Module Item programmiert ist, wirkt sich bei der Verwendung des Schlüssels nicht aus. In beiden Fällen kommt bei gleichen Eingabeparametern das gleiche Ergebnis heraus.

Abgrenzung

Um insbesondere bei modularer Software sicherzustellen, dass alle Lizenzzugriffe im selben Nested Product Item bleiben, kann man Module Items die Eigenschaft mitgeben, dass diese nur verwendet werden dürfen, wenn aus diesem Prozess heraus bereits das Eltern-Product Item belegt worden ist. Ein weiteres Beispiel: Ein Spielehersteller bringt eine Truck-Simulationssoftware sowie einen Straßenbahnsimulator auf den Markt. Für beide Produkte bietet er optional eine Erweiterung für Multi-Monitor-Unterstützung an. Es handelt sich technisch um ein und dasselbe Modul, also dieselbe Dll, und ist daher auch mit den gleichen Lizenzparametern geschützt. Wenn ein Anwender für die Truck-Simulation die Multi-Monitor-Unterstützung kauft, soll er diese auch nur dort verwenden dürfen. Startet er den Straßenbahnsimulator, so muss er sich dort weiterhin mit einem Monitor begnügen. Das technisch umzusetzen ist bislang mit viel Handarbeit verbunden gewesen: In die Lizenz musste man dazu eine zusätzliche Kennung einbauen, die auf das berechtigte Hauptprodukt verweist; beim Zugriff musste man dann den kompletten CmContainer durchsuchen und analysieren. All das wird mit Nested Product Items viel einfacher: Einfach die Lizenz für die Multi-Monitor-Unterstützung als Module Item zur Lizenz der Truck-Simulation dazu programmieren und die Eigenschaft setzen, dass der Zugriff nur bei vorheriger Belegung des Product Items erlaubt ist.

Unzertrennlich

Ein Product Item bildet mit den untergeordneten Module Items eine untrennbare Einheit. Aktiviert man ein solches Product Item in der CodeMeter License Central, sieht man genau einen Eintrag für das Produkt, und man kann es nur komplett abholen. Technisch erfolgt die Absicherung und Programmierung eines Product Items durch ein ausgestelltes Zertifikat. Ein Nested Product Item mit einem Product Item und untergeordneten Module Items wird ebenfalls durch genau ein Zertifikat programmiert. Diese Unteilbarkeit des Nested Product Items spart damit außerdem Speicherplatz bei der Übertragung und Abspeicherung im CmContainer.

Wird zum Beispiel eine modulare Software, bestehend aus einem Product Item mit mehreren Module Items, ausgeliehen, so leiht man einfach das Product Item aus – die Module Items kommen automatisch mit. Bei einer eventuellen Aufteilung, zum Beispiel der Lizenzanzahl im Rahmen des License Transfers, bezieht sich diese Aufteilung immer nur auf das Product Item. Beim Transfer der Lizenz werden alle Module Items eins-zu-eins mitgegeben. Damit werden zusammengehörende Lizenzeinträge nie auseinandergerissen und nach einem Transfer kann man sicher sein, dass die übertragene Lizenz auch erwartungsgemäß beim Empfänger funktioniert; schließlich trägt sie alle notwendigen Lizenzen in sich.

So hat der Produktmanager als Herrscher über die Lizenzen eine weitere, praktische Option, um die Lizenzierungsanforderungen gradlinig umsetzen zu können.