Lizenzmodelle für Software erklärt: unbefristet, Abo, gerätegebunden, schwimmend und mehr

Sie haben ein funktionierendes Desktop-Tool, und einige Leute fragen, ob sie es kaufen können. Bevor Sie einen Preis auf die Produktseite setzen, müssen Sie eine Frage beantworten, die einfach klingt: Was genau kauft der Kunde? Zugang für immer oder für einen Monat? Auf einem Rechner oder auf beliebigen Rechnern, aber jeweils nur einer gleichzeitig? Alle Funktionen oder nur die Grundfunktionen? Die Antwort ist Ihr Lizenzmodell. Es bestimmt Ihren Umsatz, Ihren Supportaufwand und wie viel Arbeit Ihr Lizenzserver leisten muss.

Dieser Leitfaden stellt die kommerziellen Lizenzmodelle vor, mit denen Entwickler tatsächlich verkaufen: unbefristete, Abo-, zeitlich begrenzte und lebenslange Schlüssel, Testversionen, gerätegebundene, schwimmende, sitzplatzbasierte, funktionsbasierte und nutzungsbasierte Lizenzen. Eine Tabelle vergleicht sie, es wird gezeigt, welche Modelle zu Desktop-Tools, Plugins und Gaming-Tools passen, und es wird erklärt, wie Sie jedes Modell mit Prüfungen auf dem Server statt im Client durchsetzen.

Was ist ein Softwarelizenzmodell?

Ein Softwarelizenzmodell ist die Regelsammlung, die festlegt, wie ein Kunde die bezahlte Software nutzen darf: wie lange, auf welchen Geräten, von wie vielen Personen und mit welchen Funktionen. In der Praxis besteht es aus einem Lizenzschlüssel und den Eigenschaften, die auf Ihrem Lizenzserver daran hängen, etwa ein Ablaufdatum, eine Geräte-Obergrenze oder ein Tarifname.

Hilfreich ist, das Modell als vier unabhängige Dimensionen zu betrachten statt als eine Auswahl aus einer Liste. Dauer umfasst unbefristete, Abo-, zeitlich begrenzte und Testlizenzen. Platzierung umfasst gerätegebundene und schwimmende Lizenzen. Menge umfasst Sitzplätze und Gerätezahlen. Umfang umfasst Funktionsstufen und Nutzungsgrenzen. Ein typisches Produkt wählt auf jeder Achse eine Option, und diese Kombination ist das Modell, das Sie verkaufen.

Softwarelizenzmodelle im Vergleich

Die folgende Tabelle stellt die gängigen Modelle nebeneinander. Jede Zeile ist ein Baustein, und die meisten echten Produkte nutzen zwei oder drei davon gemeinsam.

Dauer: unbefristet, Abo, zeitlich begrenzt und Testversion

Die Dauer bestimmt, wann eine Lizenz aufhört zu funktionieren. Sie hat den größten Einfluss auf den Umsatz und ist deshalb meist die erste Entscheidung.

• –Unbefristet. Der Kunde zahlt einmal, und die Lizenz läuft nie ab. Manche Anbieter verlangen zusätzlich Geld für größere Upgrades oder ein Jahr Updates. Das passt zu kleinen, stabilen Dienstprogrammen mit geringen Serverkosten.
• –Abo. Die Lizenz verlängert sich in jedem Abrechnungszyklus und läuft ab, sobald die Zahlungen enden. Das passt zu Produkten, die ständige Updates, gehostete Funktionen oder Support brauchen, denn der Umsatz fließt weiter, während die Kosten entstehen.
• –Zeitlich begrenzter Schlüssel. Ein Schlüssel für eine feste Laufzeit, etwa einen Tag, eine Woche oder 30 Tage, der einfach endet. Er ist beliebt für Werkzeuge, die für ein einzelnes Ereignis oder Projekt gebraucht werden, und in Märkten, in denen Käufer vorausbezahlten Zugang einer wiederkehrenden Abbuchung vorziehen.
• –Lebenslanger Schlüssel. Praktisch eine unbefristete Lizenz, die zusammen mit zeitlich begrenzten oder Abo-Tarifen angeboten wird, meist zum Mehrfachen des Monatspreises.
• –Testversion. Eine kurze, zeitlich begrenzte Lizenz, mit der Käufer das Produkt vor dem Kauf testen können. Ihre Länge sollte dazu passen, wie lange das Produkt braucht, um sich zu bewähren.

Die detaillierten Abwägungen zwischen unbefristeten und Abo-Lizenzen, einschließlich Abrechnungszyklen, Schonfristen und Verlängerungen, behandelt Abo-Lizenzierung für Software. Testversionen haben eigene Fallstricke, die kostenlose Testlizenzen für Desktop-Software durchgeht. Entscheidend ist hier die Durchsetzung: Egal welche Dauer, das Ablaufdatum sollte mit der Uhr des Servers berechnet werden, niemals mit der des Kunden.

Platzierung: gerätegebundene und schwimmende Lizenzen

Die Platzierung bestimmt, auf welchen Rechnern die Software laufen darf. Die beiden wichtigsten Optionen beantworten diese Frage in entgegengesetzter Weise.

Eine gerätegebundene Lizenz ist an einen bestimmten Rechner gebunden. Bei der ersten Aktivierung sendet die Anwendung einen Hardware-Fingerabdruck, der Server speichert ihn zusammen mit dem Schlüssel, und von da an funktioniert der Schlüssel nur auf diesem Rechner. Das bedeutet HWID-Locking und ist die übliche Abwehr dagegen, dass ein Schlüssel in einer Chat-Gruppe gepostet und auf dreißig PCs genutzt wird. Was ist HWID-Locking erklärt Fingerabdrücke, Zurücksetzungen und typische Fehler im Detail.

Eine schwimmende Lizenz, auch gleichzeitige Lizenz genannt, ist an keinen Rechner gebunden. Stattdessen kauft der Kunde einen Pool, etwa fünf, und beliebige fünf Rechner dürfen die Software gleichzeitig ausführen. Schließt ein Nutzer die App, kehrt sein Platz in den Pool zurück. Das passt zu Teams, in denen viele Leute das Tool gelegentlich nutzen, aber selten alle gleichzeitig.

Schwimmende Lizenzen sind schwerer sauber umzusetzen. Der Server muss wissen, welche Sitzungen aktiv sind, daher muss sich die Anwendung regelmäßig melden, und ein Platz, den ein abgestürzter oder getrennter Client hält, muss nach einer Zeitüberschreitung wieder freigegeben werden. Wenn Sie hauptsächlich an Privatpersonen verkaufen, ist die Gerätebindung fast immer der bessere Ausgangspunkt.

Menge und Umfang: Sitzplätze, Funktionsstufen und Nutzung

Sobald Sie wissen, wie lange und wo, bleiben die Fragen, wie viele und wie viel vom Produkt.

• –Sitzplatzbasierte Lizenzen decken eine feste Anzahl benannter Nutzer oder Geräte ab. Eine Lizenz für drei Plätze könnte drei Gerätebindungen an einem Schlüssel erlauben oder drei getrennte Schlüssel, die an einen Käufer ausgegeben werden. Anders als bei schwimmenden Lizenzen werden Sitzplätze zugewiesen statt ausgeliehen. Sie passen gut zu kleinen Studios und zum Verkauf über Wiederverkäufer.
• –Funktionsbasierte Stufen verkaufen dieselbe Anwendung in mehreren Ausbaustufen, etwa Basic und Pro. Die Lizenz teilt der Anwendung mit, welche Stufe sie ausführen darf. So bleibt ein Build und ein Download erhalten, das funktioniert aber nur, wenn sich die Pro-Funktionen nicht einfach durch Patchen eines Flags im Binärcode einschalten lassen.
• –Nutzungsbasierte Lizenzen berechnen, was verbraucht wird: Renderings, Exporte, API-Aufrufe oder Stunden. Der Preis folgt dem Nutzen eng, aber Sie brauchen eine verlässliche Messung auf Ihrem Server und ein Abrechnungssystem, das Zählerstände in Rechnungen umwandelt. Für ein kleines Team ist das ein erheblicher Entwicklungsaufwand.

Welches Lizenzmodell zu Ihrem Produkt passt

Dieselben Modelle gelten für jede Art von Software, aber manche Kombinationen passen zu bestimmten Produkten deutlich besser als andere. Die folgende Tabelle zeigt, was für die Produktarten, die auf PapelShip verkauft werden, meist gut funktioniert.

Gaming-Tools lohnen einen genaueren Blick, weil sie jeden Teil eines Lizenzsystems belasten. Käufer wollen oft kurzen Zugang rund um ein Spiele-Update, Schlüssel werden schnell weiterverkauft oder geteilt, und Builds sind ein ständiges Ziel für Cracker. Kurze zeitlich begrenzte Schlüssel, eine lebenslange Option, strenge HWID-Bindung mit einer Abklingzeit für Zurücksetzungen und die Auslieferung alles Wertvollen erst vom Server ist die Kombination, die sich in diesem Markt am besten bewährt.

Plugins liegen am anderen Ende. Käufer eines Plugins für eine DAW oder eine Design-App erwarten meist, es zu besitzen, und sie wechseln oft zwischen Rechnern. Eine unbefristete Lizenz pro Hauptversion, zwei Geräteaktivierungen und eine unkomplizierte Selbstbedienung für Zurücksetzungen machen die meisten zufrieden.

So setzen Sie jedes Modell auf dem Server durch

Jedes Modell auf dieser Seite lässt sich umgehen, wenn der Client entscheidet. Eine Lizenzdatei mit Ablaufdatum lässt sich bearbeiten, eine Uhr lässt sich zurückstellen, ein Stufen-Flag lässt sich umschalten und ein lokal gespeicherter Sitzplatzzähler lässt sich zurücksetzen. Das Muster, das funktioniert, ist für alle gleich: Die Anwendung sendet ihren Schlüssel und ihren Hardware-Fingerabdruck, und der Server antwortet mit dem, was diese Lizenz im Moment tun darf.

1. 01

   Dauer

   Speichern Sie Lizenzbeginn und Laufzeit auf dem Server und vergleichen Sie bei jeder Prüfung mit der Serverzeit. Geben Sie das Ablaufdatum niemals als etwas heraus, das der Client allein auswertet.

2. 02

   Gerätebindung

   Senden Sie bei jeder Prüfung einen Hash stabiler Hardwarekomponenten. Der Server bindet ihn bei der ersten Nutzung und lehnt Abweichungen ab, mit einem Weg zur Zurücksetzung und einer Abklingzeit für echte Hardwarewechsel.

3. 03

   Sitzplätze und Geräte

   Zählen Sie die Bindungen pro Schlüssel auf dem Server und lehnen Sie das nächste Gerät ab, sobald die Grenze erreicht ist. Geben Sie getrennte Schlüssel pro Platz aus, wenn Käufer einzelne Nutzer verwalten wollen.

4. 04

   Schwimmende Pools

   Verfolgen Sie aktive Sitzungen auf dem Server, verlangen Sie regelmäßige Check-ins und geben Sie einen Platz frei, wenn eine Sitzung abläuft, damit abgestürzte Clients Lizenzen nicht dauerhaft blockieren.

5. 05

   Funktionsstufen

   Verkaufen Sie jede Stufe als eigenes Produkt oder eigenen Schlüsseltyp und liefern Sie die Konfiguration, Strings oder Dateien, die eine Stufe braucht, erst aus, nachdem der Server diese Stufe bestätigt hat.

6. 06

   Nutzung

   Zählen Sie die Nutzung dort, wo die Arbeit stattfindet, auf Ihrem Server, statt einem Zähler zu vertrauen, den der Client meldet.

Legen Sie außerdem fest, wie sich die App verhält, wenn sie den Server nicht erreichen kann. Im Zweifel sollte sie den Zugriff verweigern, das ist der sichere Standard. Wenn Kunden offline arbeiten müssen, erlauben Sie ein kurzes Zeitfenster, gemessen ab der letzten Antwort des Servers, und niemals länger als die verbleibende bezahlte Laufzeit. Die allgemeine Begründung, warum Entscheidungen auf dem Server bleiben sollten, steht in clientseitiger Schutz gegen serverseitige Geheimnisse.

Lizenzmodelle mit qPapel Auth umsetzen

qPapel Auth ist das Lizenzsystem von PapelShip für C-, C++- und C#-Anwendungen und ist um das serverseitige Muster oben herum aufgebaut. Lizenzschlüssel tragen ihre Dauer in sich, sodass unbefristete, Abo-, zeitlich begrenzte und Testschlüssel jeweils einen aktuellen Status anzeigen. Die HWID-Sperre bindet Schlüssel an einen Rechner, mit Abklingzeiten für Zurücksetzungen, damit ehrliche Kunden ohne Ticket auf neue Hardware wechseln können.

Sitzungen sind verschlüsselt und signiert, und serverseitige Strings und Dateien werden erst nach einer gültigen Prüfung ausgeliefert. So sichern Sie eine Funktionsstufe mit etwas ab, das der Client nicht fälschen kann. Remote-Einstellungen erlauben es, das Verhalten ohne neuen Build zu ändern, und eigene Schlüsselformate mit KeyMask geben jedem Modell ein erkennbares Präfix, etwa TRIAL- oder PRO-, was den Support erleichtert. Auf der Laufzeitseite machen Anti-Tamper-, Anti-Debug-, Anti-VM- und Prozess-Sperrlisten den Client schwerer zu patchen, und Binary Trace hilft Ihnen, die Quelle eines durchgesickerten Builds zu finden.

Auf der Verkaufsseite liefert der PapelShip-Shop Lizenzschlüssel beim Checkout sofort aus und unterstützt Abos, sodass der Schlüssel, den ein Käufer erhält, bereits zum bezahlten Tarif passt. Die Übersicht zur Softwarelizenzierung zeigt, wie die Teile zusammenspielen, und Preise beginnen mit einem kostenlosen Tarif.

Wählen Sie das einfachste Modell, das Ihre Kunden akzeptieren

Ein Lizenzmodell ist zuerst eine Produktentscheidung und erst danach eine technische. Gehen Sie davon aus, wie Kunden die Software tatsächlich nutzen: wie lange sie sie brauchen, auf wie vielen Rechnern sie arbeiten und welche Funktionen sie gegen Aufpreis kaufen würden. Wählen Sie auf jeder Achse eine Option und widerstehen Sie dem Drang, schwimmende Pools oder nutzungsabhängige Abrechnung hinzuzufügen, bis Käufer danach fragen.

Was Sie auch wählen, setzen Sie es an einer Stelle durch. Wenn Ablauf, Bindungen, Sitzplätze und Stufen alle vom Server entschieden werden, ist das spätere Ändern Ihres Modells eine Konfigurationsänderung statt eines neuen Releases, und die Regeln, die Sie verkaufen, sind die Regeln, denen Ihre Software tatsächlich folgt.