Inhaltsverzeichnis

Teil I: Einleitung

Über den Autor

Einleitung

Teil II: Was ist eine Lizenz?

1. Lizenzierung – das unterschätze Thema

2. Softwarelizenzen

3. Warum Lizenzierungen?

4. Eckpunkte einer Lizenzierung

5. Policy Patterns (inklusive den Xamarin-Teil)

6. Lizenzierungs-Attribute

7. Deployment von Lizenzen

8. Lizenzierungs-Prozedur (inkl. Vorsicht vor Änderungen)

9. Nützliche Methoden und Bibliotheken

10. Closed vs. Open Source

Teil III: Bibliotheken und Methoden

1. Das .NET Lizenzmodell

2. Lizenzschlüssel generieren

3. Eindeutiger Fingerabdruck

4. SKGL und Software Protector

5. Rhino Licensing

6. Portable.Licensing

Teil IV: Vergleich der Bibliotheken und Methoden

1. Vergleich für Policy Patterns

2. Vergleich für Lizenzierungs-Attribute

3. Vergleich beim Deployment

4. Vergleich der Lizenzierungs-Prozeduren

5. Vergleich beim Lizenzmanagement und Gegenüberstellung

6. Anwendungsfälle sowie Einsatzgebiete

Teil V: Ausblick und Fazit

1. Eckpunkte für eine eigene Implementierung

2. Lektionen

3. Ausblick und Fazit

Imprint

Über den Autor

Fabian Deitelhoff lebt und arbeitet in Dortmund, der Metropole des Ruhrgebiets. Er studiert derzeit den Masterstudiengang Informatik. Seine Schwerpunkte liegen in der Entwicklung von Visual Studio Erweiterungen, der Analyse und Beschreibung von Open Source Frameworks sowie im Rapid Prototyping. Beruflich ist er als freier Autor, Trainer, Sprecher und Softwareentwickler im .NET Umfeld tätig. Sie erreichen Ihn über seinen Blog www.fabiandeitelhoff.de, per E-Mail unter Fabian@FabianDeitelhoff.de oder auf Twitter als @FDeitelhoff.

Einleitung

Die beiden Themengebiete Lizenzen und Lizenzmodelle sind untrennbar mit der Softwareentwicklung verbunden. Und doch werden die Themen häufig ignoriert oder zu lange beiseitegeschoben. Im Umkehrschluss bedeutet das, dass sich jeder, der Software entwickeln möchte, mit den Themengebieten auseinander setzen muss. Ganz gleich, ob es sich um ein kommerzielles Produkt oder um Open-Source-Software handelt. In den vergangenen Jahren hat sich die Art und Weise, wie über Lizenzen und Lizenzmodelle nachgedacht wird, grundlegend verändert. Es ist nicht mehr notwendig, klobige Disketten zu kopieren, die zudem nur wenige Daten enthalten können. Auch der Kopierschutz von anderen Datenträgern, wie beispielsweise CDs und DVDs, konnte in der Vergangenheit einfacher als gedacht umgangen werden. Zudem fördert die Technologie des Internets den Austausch – auch von großen Datenmengen – in kurzer Zeit. Nie war es einfacher und schneller möglich, Software zu kopieren. Die Cloud, also die zentrale Bereitstellung von Software als Dienst, galt lange als der Heilsbringer schlechthin. Viele Unternehmen setzen verstärkt auf diesen Faktor, bei den Anwendern und Anwenderinnen ist das aber noch nicht vollständig angekommen. Datenskandale, Einbruchaktionen in digitale Systeme, sowie der damit verbundene, massenhafte Diebstahl von beispielsweise Zugangs- und Zahlungsdaten sorgen zusätzlich nicht gerade dafür, die Akzeptanz für Dienste im Internet weiter zu steigern. Alles Gründe, warum die klassische Lizenzierung von Desktop-Systemen noch nicht ausgestorben ist. Die Vergangenheit hat vieles im Bereich der Softwarelizenzen geändert. Kunden und potenziell interessierte Anwender verlangen nach immer flexibleren Möglichkeiten zur Lizenzierung der eingesetzten Software. Damit die Konzeption und Implementierung eines Lizenzmodells so reibungslos wie möglich abläuft, muss einigen Eckpunkten Beachtung geschenkt werden. Dazu gehören beispielsweise verschiedene Policy Patterns, Überlegungen zu Lizenzierungs-Attributen, Deployment und Automatisierung, sowie die Frage, wie die Implementierung technisch auf Basis von .NET und C# realisiert werden kann. Neben der konkreten Realisierung sind auch die Konzepte hinter verschiedenen Lizenzierungsmustern, die gelegentlich als UML-Diagramme visualisiert werden, Gegenstand dieses Buches. Ein durchdachtes Lizenzierungskonzept hört bei der Implementierung aber nicht auf. Lizenzmanagement betrifft immer das ganze Unternehmen, da viele weitere Abteilungen und Mitarbeiter mit den Lizenzen in Berührung kommen. Daher werden auch organisatorische Aspekte betrachtet. Die .NET Welt hat in der Vergangenheit interessante und nützliche Open-Source-Bibliotheken hervorgebracht, mit denen sich Lizenzmodelle einfacher realisieren lassen, als wenn die Implementierung manuell erfolgen würde. Dieses Buch behandelt Themen rund um Softwarelizenzen sowie Lizenzierungsmodelle und zeigt, wie beide erfolgreich dazu genutzt werden können, die eigene Anwendung zu schützen. Große Teile des Inhalts sind vor circa einem halben Jahr als Video-Training bei Pluralsight erschienen. In einigen Teilbereichen ist dieses Buch eine Weiterführung der behandelten Themengebiete und wird zusätzlich dem vielfach geäußerten Wunsch gerecht, die Inhalte auch in gedruckter Form zur Verfügung zu stellen. Neben theoretischen Aspekten wird auch die Implementierung von Methoden und Frameworks gezeigt und daraufhin untersucht, ob deren Einsatz lohnenswert ist. Einige dieser Methoden und Frameworks sind der Unique Finger Print, der Software Protector und Portable.Licensing. Schwerpunktmäßig werden die Themengebiete rund um die Implementierung von Lizenzmodellen für Desktop- oder Netzwerkanwendungen behandelt. Die Lizenzierung von Cloud- oder Web-Diensten gehört nicht zum Fokus dieses devbooks. Viele der Themen sind dennoch allgemeingültig oder übertragbar, da auch bei den genannten Anwendungsgebieten lokale oder verteilte Lizenzen nützlich sind.

Beginnen möchte ich gerne mit einer Aussage, die ich vor einiger Zeit gelesen habe. Leider ist mir die Quelle abhandengekommen. Dennoch lassen mich die Sätze nicht mehr los, weil sie eindrucksvoll beschreibt, warum so viel Software illegal kopiert wird.

„Ich finde es nicht überraschend, dass soviel Software geklaut wird. Wir sind eine Kultur von anonymen Dieben. Wir mogeln bei den Steuern, rippen Filme und kopieren Spiele. Warum sollte das in anderen Bereichen des Softwarebusiness anders sein? Ich kenne Menschen, die ihren Lebensunterhalt mit dem Schreiben von Software verdienen und trotzdem die Software anderer klauen, es aber nicht als Diebstahl begreifen. Sie haben eher den Begriff des ‚Teilens‘ im Hinterkopf. Wenn Personen eine Software umsonst bekommen können, werden es einige tun. Immer. Legal oder nicht.“

Diese Aussage ist frei aus dem Englischen übersetzt und nicht von mir. Trotzdem kenne ich den beschriebenen Personenkreis. Vor allem diejenigen, die ihren Lebensunterhalt damit verdienen und dennoch kommerzielle Software von anderen stehlen. Es hat etwas Schizophrenes an sich, zu denken, sich so aus der Gleichung herausnehmen zu können.

Lizenzierung – das unterschätze Thema

Das Thema Lizenzen und Lizenzierungsmodelle treibt jeden Entwickler um. Nicht nur bei kommerzieller Software, sondern auch im Open-Source-Bereich. Wird ein Softwareprodukt verkauft, spielt der finanzielle Aspekt eine sehr große Rolle. Wer möchte schon, dass seine Software „einfach so“ kopiert und genutzt wird? Zum Beispiel bei der einen Ideen, die einen Businessbereich oder einen bestimmten Markt aufrollen könnte. Investitionen wollen geschützt werden. Und das bitte nicht über Softwarepatente, insbesondere wenn sie trivial sind, sondern über eine ausgereifte, durchdachte und kundenfreundliche Lizenzierung sowie ein gutes Lizenzmodell.

Im Open-Source-Bereich ist es eher die Frage, wo der eigene Quelltext zum Einsatz kommen darf und wo nicht. Zusätzlich zu der Frage, ob der eigene Name genannt werden muss und ob eine Veränderung des Source-Codes erlaubt ist.

Schwerpunkt dieses devbooks ist der kommerzielle Einsatz von Software. Denn die Entwicklung eines ausgereiften Softwareprodukts ist teuer. Insbesondere bei der Entwicklung eines vollständig neuen Produktes. Aber auch mit der Zeit fließt immer mehr Aufwand in eine Software. Diese Kosten müssen wieder hereingespielt werden, um die weitere Entwicklung zu finanzieren.

Bei den beschriebenen Frameworks zur Unterstützung und Implementierung von Lizenzmodellen wurde allerdings darauf geachtet, Bibliotheken und Komponenten auszuwählen, die als Open-Source-Software zur Verfügung stehen. Geld einzusparen ist nicht der Hauptgrund. Es geht auch oder vor allem darum, Einblick in die Implementierung nehmen zu können. Im Hinblick auf die Sicherheit ist das nicht zu unterschätzen.

Aus den genannten Gründen gibt es immer einen Zeitpunkt, zu dem die Frage aufkommt, wie das Produkt geschützt werden soll. Welche Lizenzierungsstrategie ist die beste? Welche Möglichkeiten gibt es überhaupt, die eigene Software zu schützen? Diese Fragen sind essentiell, wenn es um den Verkauf von Software geht. Ganz gleich, ob ein Team hinter der Entwicklung steht oder eine einzelne Person.

Lizenzierung im Wandel der Zeit

Die ganze IT-Branche ist ständig im Umbruch. Was auf Technologie im Allgemeinen zutrifft, gilt für Software im Speziellen umso mehr. Denn Software lässt sich leicht beziehungsweise leichter anpassen als andere Komponenten wie beispielsweise Hardware.

Durch den schnellen Wandel hat sich die Frage, wie Softwareprodukte lizenziert werden können, grundlegend geändert.

Bei Disketten in den 70er Jahren war das Unterfangen noch kein so großes Problem. Natürlich wurden auch diese schon kopiert, allerdings war der Markt deutlich kleiner und die Software meistens für größere Unternehmen und spezielle Situationen angepasst. Software in hohem Wert zu kopieren war zwar möglich, allerdings selten praktisch, da es nicht viel Verwendung dafür gab.

In den 80er Jahren änderte sich das schlagartig. Die Computertechnik war immer verbreiteter und auf dem Markt erschien immer mehr Standardsoftware. Und eine Eigenschaft von Standardsoftware ist es nun mal, in vielen Situationen eingesetzt werden zu können. So stieg auch die Verbreitung ebendieser Produkte, was sie zu einem deutlich lohnendere Ziel für Raubkopien machte. Disketten waren nach wie vor einfach zu kopieren und die aufkommende CD war gerade erst im Begriff, in der Musikindustrie als digitaler Speicher für Musik Fuß zu fassen. Vom einfachen Kopieren durch Endanwender ganz zu schweigen. Eine klassische Maßnahme war es damals, Hardware-Keys zur Sicherung der Software zu verwenden. Diese Keys sind vielleicht besser bekannt unter den Namen Hardware-Dongles beziehungsweise einfach nur Dongles. Der USB-Anschluss war zwar noch lange nicht erfunden – er kam erst gegen Mitte der 90er Jahre – doch auch serielle Anschlüsse eignen sich gut dazu, Dongles anzuschließen und über die Software abgefragt zu werden.

Die hohe Verbreitung der Personal Computer führte in den 90er Jahren dazu, dass sich die Art und Weise der Softwarelizenzierung das erste Mal grundlegend ändern musste. Hardware-Dongles sind zwar ein gutes Mittel, für Standardsoftware bedeuten sie aber einen hohen Aufwand und hohe Kosten. Denn jeder Anwender und jede Anwenderin brauchten ebenso einen Dongle. Alleine Windows 95, veröffentlicht im August 1995, wurde in den ersten drei Monaten nach Verkaufsstart 45 Millionen Mal verkauft [1]. OEM Versionen, also direkt beim Kauf von Computern vorinstallierte Versionen von Windows 95, noch gar nicht eingerechnet. All diese Installationen hätten mit einem Dongle abgesichert werden müssen. Dabei schlägt nicht nur die Produktion und der Versand mit hohen Kosten zu Buche, sondern auch die Wartung. Denn auch Hardware-Dongles können Defekte aufweisen und müssen dann ersetzt werden. Ein weiterer Grund, warum diese Art der Lizenzierung immer weiter in den Hintergrund gedrängt wurde. Eine weitere Fehlerquelle konnte und wollte man sich nicht ans Bein binden. Wer als Hersteller von Softwareprodukten also erfolgreich den Sprung von den 80ern in die 90er Jahre schaffen wollte, musste sich etwas anderes einfallen lassen. Herausgekommen ist, bei der überwiegenden Zahl der Hersteller, die sogenannte softwarebasierte Lizenzierung. Dabei sorgt das Produkt selbst dafür, dass der eingegebene Schlüssel den korrekten Erwerb bestätigt. Wie auch immer dieser Schlüssel aussehen mag. Mal sind es mehr, mal weniger Zeichen und auch die Komplexität schwankt, wenn nur Zahlen, nur Buchstaben oder eine Kombination von beidem zum Einsatz kommt.

Diese softwarebasierte Lizenzierung ist die am weitesten verbreitete Lizenzierungsart. Zumindest in der Hinsicht, dass ein – wie auch immer gearteter – Schlüssel bei der Installation der Software eingegeben werden muss. Hin und wieder, beispielsweise bei Windows, ist es auch möglich, den Schlüssel nach der Installation anzugeben. Dann läuft das Produkt in einer Art Testversion. Zwar ohne funktionelle Beschränkungen, aber zeitlich begrenzt.

Mit der immer stärkeren Verbreitung von Internetanschlüssen ist im neuen Jahrtausend eine weitere Lizenzierungsart hinzugekommen. Softwareschlüssel sind immer noch stark verbreitet und dominieren den Markt. Allerdings werden diese Schlüssel nicht mehr nur von der Software an sich – mithilfe von Algorithmen, überprüft – sondern auch bei Online-Servern verifiziert. Dieser Umstand wird von vielen Kunden gerne auch als Online-Zwang bezeichnet: Viele Produkte laufen ohne Internetverbindung gar nicht mehr. Entweder es wird eine Verbindung bei der Installation des Softwareproduktes benötigt oder sogar während der kompletten Laufzeit. Gerade Letzteres ist in der Spieleindustrie sehr stark verbreitet und führt zu regelrechten Anfeindungen der Spieler Community gegenüber den Herstellern. Ein eindringliches und gleichzeitig abschreckendes Beispiel ist hier die sogenannte Rootkit-Funktion [2] eines Kopierschutzes von Sony BMG, wobei es sich zwar um den Schutz von CDs handelt, dennoch eignet sich das Beispiel gut um aufzuzeigen, wieviel Unternehmen und Konzerne bereit sind zu unternehmen, um das Kopieren von Datenträgern und Produkten zu unterbinden. Der Online-Zwang führt auch regelmäßig dazu, dass Produkte nicht mehr installiert oder genutzt werden können. Das passiert dann, wenn die Online-Dienste vom betreffenden Hersteller abgeschaltet werden [3].

Nichtsdestotrotz hat dieses Vorgehen keinen signifikanten Einfluss auf die Möglichkeit gehabt, Produkte zu kopieren und sämtliche Schutzmaßnahmen zu umgehen. Gerade im Bereich der Computerspiele werden die Schutzmaßnahmen von Produkten sehr schnell nach der Veröffentlichung umgangen und ohne ebendiese Sicherheitsmaßnahmen von der Community veröffentlicht. Wie bei jeder Innovation beziehungsweise Investition kommt es also auch bei der Lizenzierung darauf an, wie hoch der Kostenaufwand gegenüber dem Nutzen ist. In diese Rechnung muss auch der Schaden einberechnet werden, der entstehen kann, wenn eine schlecht umgesetzte oder zu restriktive Sicherheitsmaßnahme ehrliche Käufer und Käuferinnen vom Einsatz des Produktes abhalten. Auch das ist eine Größe, die nicht unterschätzt werden darf.

Bedingt durch die großen Fortschritte in den Bereichen Rechenleistung, Speicherkapazität und Bandbreite, gab es in den letzten Jahren einen regelrechten Boom beim sogenannten Cloud-Computing. Damit werden eine ganze Reihe neuer Lösungen möglich. Zum einen ist es möglich, die Validierung von Software-Lizenzschlüsseln in die Cloud auszulagern. Dieses Vorgehen ähnelt den bereits erwähnten Online-Services, nur dass jetzt die Validierung nicht mehr zwingend auf selbst gehosteten Servern durchgeführt wird. Zugegeben, das ist ein kleiner Unterschied. Schon deutlicher fallen die Unterschiede auf, wenn andere Dienste in Betracht gezogen werden. Beispielsweise Software as a Service (SaaS) [4] oder Platform as a Service (PaaS) [5]. In beiden Fällen ist es möglich, je nach Ausgestaltung und Anforderungen des eigenen Produktes, die Dienstleistungen auch in der Cloud anzubieten. Die Themenbereiche Lizenzierung und Lizenzmodelle verschieben sich somit ebenfalls in die Cloud. Lizenzen können nun ganz einfach an Log-ins gebunden werden. Entweder für einzelne Arbeitsplätze oder für komplette Organisationen. Es ist kein Softwareschlüssel mehr notwendig. Von einem Dongle oder ähnlichem ganz zu schweigen. Zusätzlich sind weitreichende Analysen möglich. Welche Produkte in der Cloud werden am häufigsten genutzt? Welche Features am meisten und welche gar nicht? All diese Daten fallen natürlich auch bei Lizenzmodellen im klassischeren Desktopbereich an. Grundsätzlich ist es auch möglich, diese zu sammeln und auszuwerten. Der Aufwand, der hierfür getrieben werden muss, ist aber ungleich höher. Von einer Internetverbindung, die diese Daten auch nach draußen lässt, ganz abgesehen.

Welches Vorgehen beziehungsweise System in der Vergangenheit auch immer genutzt wurde. Sicher ist, dass gute Lizenzmodelle und ein mindestens ebenso gutes Lizenzmanagement vorhanden sein müssen, wenn mit dem direkten Verkauf der Software Geld verdient werden soll. Gute und auf das Produkt abgestimmte Dienstleistungen helfen dem Absatz sicherlich auch. Allzu häufig wird ein Produkt aber trotzdem über Umwege beschafft, um Lizenzkosten zu sparen und dieses Geld dann in die Einarbeitung ohne externe Hilfe zu stecken.

Ebenso wichtig ist es auch, für die Zukunft gerüstet zu sein. Wer mit seinem Softwareprodukt den erfolgreichen Sprung aus einem Jahrzehnt ins nächste schaffen möchte, muss auf die Veränderungen des IT-Marktes eingehen. Nicht selten bedeutet das, mehrere Strategien zur Lizenzierung zu verfolgen und anzubieten, um flexibler auf Kundenwünsche reagieren zu können.

Auf viele Aspekte davon geht dieses Buch ein und zeigt praktische Lösungsansätze, mit denen ein Lizenzmodell etabliert werden kann.

Was ist überhaupt eine Lizenz?

Bevor es konkret um die Realisierung von Lizenzmodellen mithilfe von .NET Bibliotheken und Frameworks geht, wird das Thema Lizenz aus Sicht von Software eingegrenzt.

Die Frage, was eine Lizenz überhaupt ist, lässt sich auf mehreren Ebenen beantworten. Zunächst einmal zum Wort an sich. Licentia kommt aus dem Lateinischen und bedeutet Freiheit oder Erlaubnis. Licere bedeutet erlaubt sein. Als typische Verbindungen listet der Duden zu „Lizenz“ Wörter wie neu, begehrt, teuer, gültig, erforderlich und staatlich auf. Alles Dinge, mit denen eine Lizenz häufig assoziiert wird.

Im Allgemeinen bezieht sich eine Lizenz auf eine erteilte Erlaubnis. Wie auch immer diese aussehen mag, was sie enthält und worauf sich dieses Erlaubte bezieht. Eine sehr bekannte Lizenz ist beispielsweise die „Lizenz zum Töten“ vom berühmten aber fiktiven Geheimagenten des britischen Geheimdienstes MI6 James Bond alias 007. Diese Lizenz besagt, dass der Geheimagent nicht gerade zimperlich mit seinen Gegnern umzugehen pflegt.

Aber unter der Lizenz wird auch das Dokument verstanden, welches diese Erlaubnis erteilt oder allgemein die Informationen enthält. Beispielsweise eine Datei, ein ausgedrucktes Dokument, eine Scheckkarte oder ähnliches. Die Lizenz zum Fahren eines Fahrzeuges kann zum Beispiel durch die PKW-Klasse B ausgedrückt werden, wie es die EU Führerscheinklassen vorsehen. Damit ist aber eben nicht nur die Erlaubnis gemeint. Diese Lizenz bezieht sich aber auch auf das Dokument, heute in Form des Scheckkartenführerscheins. Dieses muss beim Führen eines Fahrzeuges mitgeführt werden, wie es so schön heißt. Eine Lizenz ist demnach gleichzeitig eine Erlaubnis, in der Regel etwas tun zu dürfen, sowie ein bestimmtes Dokument, meistens in irgendeiner beglaubigten und damit anerkannten Form.

Zusammengefasst ist eine Lizenz also ein rechtliches Mittel, um bestimmte Nutzungsrechte zu erteilen. Zunächst völlig losgelöst von einer bestimmten Sache, einem bestimmten Medium oder Ähnlichem.

Unterschiede zu Softwarelizenzen

Diese Sachverhalte treffen auch auf Lizenzen im Softwarebereich zu. Die Nutzungsrechte unterscheiden sich aber häufig grundlegend von denen anderer Produkte, für die Lizenzen vergeben werden. Bei Software handelt es sich bei diesen Nutzungsrechten normalerweise um die Erlaubnis, eine Software zu nutzen oder den Quelltext in irgendeiner Form weiterzuverwenden. Beides trifft sowohl auf komplette Produkte, Komponenten oder den nicht fertig kompilierten Quelltext zu.

Am häufigsten ist sicherlich ein Lizenzabkommen, dass die Nutzung der Software durch Endanwender gestattet. Sie wird, in verschiedenen Formen, nahezu zu jedem Softwareprodukt mitgeliefert. Von der Shareware bis hin zur vollständigen Enterprise-Lösung.

Eine der meistbekanntesten Softwarelizenzen ist ebenso eine Vereinbarung für Endanwender. Gemeint ist die „End User License Agreement“, kurz EULA. Übersetzt bedeutet die Abkürzung „Endbenutzer-Lizenzvertrag“. Sie wird jedem Computernutzer bekannt vorkommen, da die Annahme dieser Vereinbarung so gut wie jeder größeren Softwareinstallation vorgeschaltet ist.

So häufig gesehen die meistens EULAs auch sind, so verhasst sind sie ebenfalls. Der Großteil der Anwender wird sie beim Auftauchen auch direkt wieder wegklicken. Gelesen werden die mitunter sehr umfangreichen Dokumente wohl eher selten.

Und bei den EULAs hört es nicht auf. Ganz im Gegenteil ist das nur die Spitze des Eisbergs. Viele Hersteller zeigen ihren Kunden und Kundinnen beim erstmaligen Start ihrer Anwendung einen ganzen Haufen von Lizenzvereinbarungen. Ein von mir oft genutztes Beispiel ist der Spielehersteller Blizzard Entertainment (Activision Blizzard) und das vom diesen Studio veröffentlichte Computerspiel World of Warcraft. Spielern werden nach der Installation ganze fünf Lizenzvereinbarungen [6] zur Annahme vorgelegt. Nicht nur die Endbenutzerlizenzvereinbarung, die der EULA entspricht, sondern auch die folgenden Lizenzvereinbarungen:

Nutzungsbestimmungen

Servicekündigung

Anti-Cheating-Vereinbarung

Connect-Nutzungsbestimmungen

Besonders interessant ist die sogenannte Anti-Cheating-Vereinbarung. Darin steht, dass sowohl der Arbeitsspeicher des gerade geöffneten Blizzard-Spiels, als auch der Spiele-Prozess und die Windows Prozessliste gescannt und die Informationen an Blizzard weitergeleitet werden. Das soll verhindern, dass Spieler und Spielerinnen Cheat-Programme nutzen, also sich Vorteile im Spiel verschaffen. Gerade bei Online-Programmen, und die sind im Spielebereich sehr häufig vertreten, wächst die Zahl der Lizenzvereinbarungen rasant an.

Aus Sicht der Situation in Deutschland gesehen ist interessant, dass EULAs, die erst bei der Installation zu sehen sind, keine Gültigkeit haben. Sie sind für den Käufer also vollkommen wirkungslos. Dieser Umstand gilt auch dann, wenn der Anwender bei der Installation einen Haken setzt oder eine Schaltfläche drückt, auf der „Ich stimme der Lizenzvereinbarung zu“ oder ähnliches steht. Der einfache Grund dafür ist: Lizenzbedingungen, die nicht vor dem Kauf vereinbart sind, gelten nach deutschem Recht nicht. Ein Umstand, der sowohl den meisten Anwendern als auch Unternehmen nicht bekannt ist oder von letzteren auch gerne verschwiegen wird. Der Kasten „Rechtliches zu Softwarelizenzen“ enthält dazu einige Infos am Rande, die für das Verständnis von Lizenzen und EULAs nützlich sind.

Rechtliches zu Softwarelizenzen

Softwarelizenzen sind nichts anderes als Verträge und für Verträge gilt ganz allgemein der Grundsatz der Vertragsfreiheit. Das bedeutet, dass sich der Lizenzgeber und der Lizenznehmer über den Umfang der Lizenzvereinbarung und der damit übertragenen Rechte beliebig einigen dürfen.

Für Standardsoftware gilt in der Regel das Friss-oder-stirb-Prinzip. Denn wer Millionen Stück seiner Standardsoftware verkauft, kann nicht mit jedem einzelnen Endverbraucher über die Nutzungsrechte im Einzelnen verhandeln. Wie der Anwender den Inhalt des Lizenzvertrags zu Gesicht bekommt, spielt dabei keine Rolle. Entweder im Installationsprogramm selbst, auf der Verpackung oder auf dem Kaufvertrag. Damit die Lizenzbedingungen gültig werden, ist lediglich notwendig, dass sie vor Vertragsabschluss vereinbart wurden. Und das ist in den meisten Situationen nicht der Fall.

In Online-Shops ist das beispielsweise schon Gang und Gäbe. Bevor der Download beginnt, werden die Lizenzbedingungen dem Kunden vorgehalten, der sie dann bestätigen muss. Ansonsten ist kein Download möglich.

Verschiedene Sichtweisen

Bisher wurde eine Lizenz aus einer bestimmten Perspektive betrachtet. Es kann sich dabei um die verschiedensten Dokumente handeln, die bestimmte Rechte gewähren oder explizit untersagen. Aus Softwaresicht handelt es sich dabei um Nutzungsrechte. Die Softwareentwicklung ist es aber, die eine weitere Sichtweise beinhaltet. Denn bis jetzt ist eine Lizenz nichts weiter als etwas Organisatorisches: ein rechtliches Mittel mit Nutzungsrechten. Aber wie sieht die technische Betrachtung aus? Gerade im Hinblick auf ein Softwareprodukt ist das zu berücksichtigen. Daran können viele Entwicklungen und Produkte scheitern, weil sie es dem Kunden erschweren, ein Produkt schlicht und ergreifend zu nutzen.

Beim Thema Führerschein ist das kein großes Problem, um erneut dieses Beispiel zu bemühen. Zunächst gab es etliche Jahrzehnte lang den Papierführerschein, der umgangssprachlich nur Lappen genannt wird. Dann wurde auf das Scheckkartenformat umgestellt.

Bei der Software hat sich das im Lauf der Zeit auch geändert, wie das Kapitel zu Lizenzen im Wandel der Zeit schon angerissen hat. Technisch gesehen gibt es viele Möglichkeiten, eine Lizenz zu realisieren. Die folgende Liste enthält nur einige Möglichkeiten, die Entwicklern und Entwicklerinnen ad-hoc bei dem Thema in den Sinn kommen:

Dateien

Hardware-Dongle

Hardware-basiert

Online-basiert

Cloud-basiert

Spezielle Zeichenketten

Transparente Verfahren

Natürlich überlappen sich diese Bereiche und streng genommen kann alles als Datei oder spezielle Zeichenkette aufgefasst werden. Es geht aber nicht so sehr um die Betrachtung aus Sicht einer Programmiersprache, sondern um die technische Konzeption. Soll das Produkt durch eine Lizenzdatei geschützt werden oder gibt der Kunde eine 12-stellige Zeichenkette ein, bestehend aus alphanumerischen Zeichen. Das alles sind technische Fragen zur Realisierung, die im Vorfeld geklärt werden müssen oder die sich aus der Konzeption des Produkts heraus ergeben. Wer einen Cloud-basierten Dienst plant, wird die Kunden sicherlich keinen Lizenzschlüssel eingeben lassen. Die Verknüpfung mit Benutzerkonten ergibt hier deutlich mehr Sinn. Zudem macht die organisatorische Sicht deutlich, dass es häufig von der Konzeption einer Softwarelösung abhängt, welche Lizenzierung überhaupt zum Einsatz kommen kann oder welche zu bevorzugen ist. Ein Hardware-basiertes Lizenzmodell zum Beispiel, das die Hardware der Maschinen zur Berechnungen der Lizenzinformationen heranzieht, kann in einem Mehrbenutzerumfeld auf den ersten Blick zwar Sinn ergeben, erschwert aber vielleicht die Administration und Wartung dieser Lösung. Werden, nur um ein Beispiel zu nennen, 1.000 Arbeitsplätze eingesetzt, fällt hier und da sicherlich die ein oder andere Hardwarekomponente mit einem Defekt aus. Dann ist eine Re-Lizenzierung notwendig. Vielleicht sogar mithilfe eines telefonischen Supports, weil sich dieser Konflikt nicht direkt über ein Online-Portal lösen lässt. Dieser Umstand kann eine IT-Abteilung sehr gut beschäftigen. Unnötigerweise, sei dazu gesagt.

Windows-Benutzer kennen dieses Problem. Schon bei Windows 7 und Vorgängern ist die Lizenz an verschiedene Merkmale der eingebauten Hardware gebunden. Wird eine Untermenge dieser Komponenten getauscht, meldet sich Windows beim nächsten Neustart mit der Meldung, dass die Aktivierung fehlt. Diese muss dann nachgeholt werden, was häufig nicht ohne einen Telefonanruf gelingt.

Bei Windows 8 ist das Problem noch verschärfter. Zumindest im Bereich der OEM-Rechner. Damit sind Komplettrechner mit vorinstalliertem Windows 8 gemeint. Anders als bei Windows 7 OEM-PCs fehlt bei der Windows 8-Variante der Aufkleber am PC-Gehäuse, der die Lizenzinformationen enthält. Allen voran der Produkt-Schlüssel, der zur Installation beziehungsweise Aktivierung notwendig ist. Bei der Erstinstallation von Windows 8 muss dann kein Produkt-Schlüssel mehr vom Kunden eingegeben werden, da dieser aus den ACPI-Tabellen des Systems ausgelesen wird. Was sich zunächst komfortabel anhört, hat einen entscheidenden Nachteil. Diese Tabellen befinden sich nämlich in der Firmware des Mainboards. Wird das Mainboard getauscht, ist damit auch keine gültige Lizenz mehr vorhanden. Hier ist der Kunde auf ein Austausch-Mainboard des OEM-Herstellers angewiesen, das ebenfalls einen passenden Produkt-Schlüssel enthält. Denn Microsoft speichert auf seiner Seite einen Hash-Wert, der sich aus der Hardware des Systems ergibt. Bei der Aktivierung wird nun geprüft, ob der Lizenzschlüssel tatsächlich mit dem Hash-Wert übereinstimmt, um so zu prüfen, ob die Lizenz auch tatsächlich auf der Hardware installiert wird, zu der sie ausgeliefert wurde. Dieses Verfahren kommt einem Hardware-Dongle gleich. Das Vorgehen wird noch für reichlich Diskussionen sorgen, denn es beschränkt auch den Gebrauchthandel von Software, der ausdrücklich erlaubt ist. Das hat der Europäische Gerichtshof im Urteil vom 03. Juli 2012 bestätigt. Der EuGH stellt darin fest, dass gebrauchte Software weiterverkauft werden darf, unabhängig davon, wie sie erworben worden ist. Erfreulicherweise gilt das auch für Software, die durch einen Download erworben wurde. Auch das Recht auf spätere Aktualisierung dieser Software ist dadurch nicht beeinflusst. Auch Volumenlizenzen, also mehrere Lizenzen im Paket, dürfen aufgeteilt und einzeln weiterverkauft werden. Der Bundesgerichtshof hat im Urteil vom 17. Juli 2013 das Urteil vom EuGH bestätigt (Aktenzeichen I ZR 129/08).

Weitere Informationen zum Gebrauchthandel und Windows 8 fasst der Kasten „Windows 8 und das Strafrecht“ zusammen.

Windows 8 und das Strafrecht

Das Urteil vom Europäischen Gerichtshof hat ein klares Ausrufezeichen Richtung Softwarehersteller gesetzt. Das Urteil stellt Software, die vom Erstkäufer mittels Download bezogen wurden, den Anwendungen gleich, die auf Datenträgern ausgeliefert wurden.

Microsoft schlägt hier im Hinblick auf Windows einen neuen Weg ein. Wie schon erwähnt, hat das mit der technischen Realisierung zu tun, den Lizenzschlüssel an das Mainboard zu koppeln und den Schlüssel an sich auch nur noch verschlüsselt in der Hardware abzulegen. Diese Konzeption macht ein Weiterverkauf der gebrauchten Lizenz unmöglich.

Wie so häufig in diesen Fällen dauerte es nicht lange, bis ein findiger Entwickler ein Programm veröffentlichte, das diesen Lizenzschlüssel aus der Hardware ausliest. Der anonyme Entwickler war auch so schlau, den Quelltext nicht zu veröffentlichen, sodass die Lücke im Nachhinein nicht oder nicht so schnell geschlossen werden kann.

Trotzdem könnte es beim Weiterverkauf dieser Lizenzen Probleme geben. Denn laut Strafrecht, genauer gesagt § 202a des Strafgesetzbuches (StGB), ist das „Ausspähen von Daten“ untersagt. Für die verschlüsselten Lizenzschlüssel dürfte so eine Sicherung gelten.

Letztlich bleibt die Frage offen, ob Microsoft gegen Erfinder solcher Tools vorgeht. Durchaus im Bereich des Möglichen ist aber, dass Microsoft die so als Gebrauchtsoftware weiterverkauften Lizenzschlüssel nicht anerkennen wird, da sie als Ergebnis einer Straftat gewonnen wurden. Weiterhin ist möglich, dass solche Lizenzschlüssel bei der nächsten Online-Aktivierung von Microsoft deaktiviert werden.

Arten von Softwarelizenzen

Es gibt viele mögliche Softwarelizenzen, die für ein Softwareprodukt gewählt werden können. Zunächst ist die Unterteilung zwischen Open Source und kommerzieller Software notwendig. Und zwar in der Hinsicht, dass die Software als Produkt verkauft werden soll – unabhängig von möglichen Dienstleistungen. Denn auch viele Open-Source-Projekte sind kommerziell sehr erfolgreich, weil sich gute Dienstleistungen um die Software etabliert haben.

Abbildung 1 zeigt eine schematische Darstellung verschiedener Lizenzierungsmodelle für Software, sowohl für freie als auch für kommerzielle Software. Ursprünglich stammt diese visuelle Zusammenfassung von Chao-Kuei und wurde seitdem durch viele weitere Personen aktualisiert.

Abbildung 1 | Verschiedene Kategorien von Softwarelizenzen.

Jede der Lizenz-Gruppen, die in der Abbildung zu sehen sind, haben andere Anforderungen an die Lizenzierung und das dahinterliegende Modell. Dieses Buch beschäftigt sich mit den Details der Lizenzierung für die rechte Seite, also für den proprietären Bereich, dargestellt durch die rote Umrandung.

Natürlich ist es ebenfalls möglich, in einer Open-Source-Software ein Lizenzmodell zu implementieren. Die Vorteile sind aber marginal bis gar nicht vorhanden. Zumindest aus Sicht eines Softwareentwicklers nicht, denn der Quelltext des Produkts steht frei zum Download zur Verfügung. Es ist somit möglich, die lizenzierten Teile der Anwendung zu ändern und dann neu zu kompilieren, um die Komponenten auch ohne gültige Lizenz nutzen zu können. In der Praxis ist das zwar wiederum etwas eingeschränkt, da nicht alle Anwender und Anwenderinnen einfach den Quelltext ändern können, um eine neue Version der Software zu erzeugen. Trotzdem würden in kürzester Zeit Versionen ohne Lizenzierung auftauchen. Ein Problem, das auch kommerzielle Softwareprodukte und Hersteller nach wie vor plagt.

Freie Software wird im Übrigen häufig missverstanden. Im Hinblick auf die Abbildung 1 dieses Buches ist mit dem Begriff freie Software die Freiheit gemeint, nicht der Preis. Softwarehersteller verwenden – insbesondere im Englischen – häufig den Begriff freie Software, um sich auf den Preis zu beziehen. Beispielsweise ist damit gemeint, dass eine Software kostenlos zum Download zur Verfügung steht und kostenlos genutzt werden kann. Das hat mit Open Source aber in der Hinsicht nichts zu tun, als dass der Quelltext frei zur Verfügung steht und im Rahmen der gewählten Lizenz im Sinne der Freiheit angepasst werden darf.

Warum lizenzieren?

Die Frage nach einer Lizenzierung bei kommerziellen Produkten hat das Buch bisher indirekt beantwortet. Die kurze Antwort lautet: um Geld zu verdienen. Viele Geschäftsmodelle basieren darauf, Lizenzen für eine Software zu verkaufen. Zum einen, um direkt von diesen Einnahmen leben zu können, zum anderen aber auch, um ergänzende Dienstleistungen zum Produkt anzubieten. Das sind die beiden Hauptgeschäftsfelder, mit denen die meisten Softwareunternehmen ihr Geld verdienen. Und die Dienstleistungen sind stark an die Verkäufe gekoppelt. Sicherlich möchte niemand einem Kunden eine Consulting-Leistung verkaufen, wenn dieser das zugehörige Produkt vorher kopiert statt gekauft hat.

Produkte zu verkaufen fällt aber schwer, wenn sie jeder kopieren kann – insbesondere dann, wenn es weitere Hersteller geschafft haben, ähnliche Produkte auf den Markt zu bringen.

Die Software Alliance hat das letzte Mal im Jahr 2011 eine weltweite Studie [7] herausgebracht, in der globale Zahlen zur Softwarepiraterie veröffentlicht wurden. Weltweit liegt der Anteil der Benutzer, die Raubkopien verwenden, bei 42 %. Das bedeutet, dass vier von zehn Anwendern Raubkopien nutzen. In West-Europa liegt der Anteil bei 32 %. In Zentral- und Ost-Europa gar bei 62 %. Zustande gekommen sind diese Zahlen durch Umfragen unter Anwendern. Die genaue Frage lautete „Wie oft greifen Sie auf Raubkopien oder auf Software zurück, die nicht vollständig lizenziert ist?“ Anzukreuzen waren die folgenden Antworten. In Klammern steht die Häufigkeit, mit der eine Antwort angekreuzt wurde.

Die ganze Zeit über (5 %)

Häufig (9 %)

Hin und wieder (17 %)

Selten (26 %)

Niemals (38 %)

Keine Antwort (5 %)

Das sind erschreckende Zahlen. Für viele Anwender und Anwenderinnen ist es jedoch völlig normal, Raubkopien zu nutzen. Der Markt für diese Raubkopien wurde im Jahr 2011 auf 63 Milliarden Dollar geschätzt.

Aus Sicht der Softwaretechnik spricht aber noch ein weiterer Vorteil für ein durchdachtes Lizenzierungsmodell. Die Rede ist von einer reduzierten Komplexität, die allerdings selten mit Lizenzen in Verbindung gebracht wird. Folgender Hintergrund ist dafür verantwortlich: Viele Softwareprodukte existieren in mehreren Versionen. Viele Anwendungsszenarien und Einsatzfelder erlauben es nicht, nur die jeweils aktuelle Softwareversion anzubieten. Auch ältere Produktversionen müssen vorhanden sein. Teilweise mit beträchtlichem Aufwand für Wartung und Pflege.

Ein anderer Aspekt sind unterschiedliche Versionen für verschiedene Kunden. Beispielsweise bei der Anzahl und Ausgestaltung der Funktionen. Ohne durchdachtes Lizenzmodell müssten diese Unterschiede manuell gehandhabt werden. Beispielsweise um ein spezielles Feature für bestimmte Kundengruppen zu deaktivieren, weil es nur für einen einzelnen Kunden implementiert wurde. Das tritt häufiger auf als gedacht. Die Regel sollte zwar sein, dass alle Funktionen für die Allgemeinheit zur Verfügung stehen, aber nicht immer ist das möglich oder sinnvoll.

In die gleiche Richtung gehen verschiedene Produktversionen. Beispielsweise eine Home-, eine Professional- und eine Enterprise-Version, wie sie viele Hersteller anbieten. Diese manuell zu realisieren ist sehr viel Aufwand. Ohne Lizenzmodell kommen häufig sogenannte Feature-Branches zum Einsatz. Hierbei wird im System zur Versionsverwaltung ein eigener Branch für eine Funktion angelegt. Nicht nur, um die Entwickler vom Hauptzweig zu trennen, sondern auch, um verschiedene Versionen durch einen Buildprozess zu unterschiedlichen Versionen zusammenzufügen. Das hört sich abenteuerlich an und häufig ist es das auch. Denn dieses Vorgehen kann sehr schnell aus dem Ruder laufen. Viele Funktionen für viele Kunden aufzuteilen übersteigt schnell eine gewisse Komplexitätsgrenze, sodass sehr viel Zeit im Tagesgeschäft für die Verwaltung der unterschiedlichen Kundenversionen investiert werden muss.

Auch ein weiterer Aspekt taucht häufig nicht auf dem Radar auf, wenn es um die Implementierung eines Lizenzmodells geht. Dadurch, dass verschiedene Bereiche einer Software durch Lizenzen beziehungsweise durch Eigenschaften einer Lizenz unterschiedlich gehandhabt werden sollen, muss auch die Implementierung darauf reagieren. Nicht selten führt das dazu, dass die Software modularisierter konzipiert und implementiert wird, als das ohne Lizenzmodell der Fall wäre. Denn Module lassen sich hervorragend durch Lizenzen absichern und sich dadurch leicht aktivieren beziehungsweise deaktivieren. Ebenfalls von Vorteil ist, dass dadurch die einzelnen Features oder Bereiche bei der Installation beziehungsweise beim Ausliefern der Software voneinander getrennt sind. Nicht jede Feature muss gleich von Anfang an mitinstalliert werden. Das sind Vorteile, die durch ein durchdachtes Lizenzierungs-Konzept erreicht werden können.

Der Kasten „Was sind Feature-Toggles?“ gibt einen kleinen Exkurs zu sogenannten Feature-Toggles, die Martin Fowler [8] und andere bereits im Jahr 2010 beschrieben haben. Dieses Konzept ist bei der Implementierung hilfreich, wenn bestimmte Bereiche beziehungsweise Funktionen einer Software getrennt zur Verfügung stehen sollen. Der Kasten gibt auch Tipps zu Frameworks und Bibliotheken, die den Aufwand Feature-Toggles zu implementieren deutlich verringern.

Was sind Feature-Toggles?

Unter einem Feature-Toggle wird eine Methode verstanden, bestimmte Entwicklungsstände zu verwalten. Diese werden als Feature bezeichnet. Ein verwandtes Konzept sind die sogenannten Feature-Branches. Diese haben den gleichen Hintergrund, nämlich verschiedene Softwarestände eines Produkts voneinander zu trennen. Ein Feature-Branch ist eine tatsächliche Verzweigung im Versionsverwaltungssystem, zum Beispiel Git oder Subversion. Ein Feature-Toggle ist ein Stück Quelltext, der es ermöglicht die verschiedenen Funktionen zu aktivieren oder zu deaktivieren. Grundsätzlich reicht dafür eine if-Abfrage.

In der Praxis könnte es also sein, dass die Funktion A schon fast komplett ist und in Kürze ausgeliefert wird. Funktion B aber noch nicht, also wird diese Funktion zunächst über einen Schalter, den Toggle, vor den Anwendern verborgen.

Dieses Vorgehen ist wichtig bei der agilen Entwicklung von Software. Hier sollen im Continuous-Integration-Prozess die Code-Bestandteile eines Entwicklerteams so schnell wie möglich in die Software einfließen, damit der Code von Anfang an mitgetestet wird. Ist eine Funktion aber noch nicht komplett, kann das für Ärger sorgen.

Diese Toggles sollten allerdings nur während der Entwicklung von Zwischenversionen genutzt werden. Der Einsatz in einem Release kann wieder zu deutlich erhöhter Komplexität sorgen, da sich im Code unter Umständen viele Verschachtelungen befinden. Zudem sind viele Features so einfach gehalten, dass sie mit einer einfachen Abfrage aus der Anwendung herauslösbar sind. Beispielsweise wenn Änderungen des Datenmodells oder externen Dienste notwendig sind. Daher gibt es auch viel Kritik an der Technik der Feature-Toggles.

Interessierten stehen in der .NET Welt viele verschiedene Bibliotheken zur Verfügung, die bei der Implementierung von Feature-Toggles helfen. Hilfreiche Bibliotheken sind unter anderem NFeature, FeatureToogle, FeatureSwitcher und nToogle. Alle mit unterschiedlichen Ansätzen und Vorgehensweisen. Mein Favorit ist bisher die Bibliothek FeatureSwitcher. Bei Interesse an der Methodik der Feature-Toggles ist es aber sinnvoll, einen kurzen Blick auf alle genannten Bibliotheken zu werfen.

Verschiedene Anwender-Typen

Das vorherige Kapitel hat die Frage, warum Lizenzen beziehungsweise ein Lizenzierungsmodell wichtig sind, aus einem eher technischen Blickwinkel betrachtet. Wie das Buch aber hoffentlich schon deutlich gemacht hat, gibt es immer zwei Seiten der Medaille. So auch bei der Frage, warum ein Lizenzmodell notwendig sein kann. Nämlich aus organisatorischer Sicht, die sich um die potenziellen Anwender sowie Anwenderinnen und damit auch potenzielle Kunden und Kundinnen dreht.

Einem Softwareentwickler begegnen sehr schnell viele unterschiedliche Typen von Benutzern. Damit ist keine Einteilung nach Fachkenntnis oder ähnlichem gemeint, die Anwender mitbringen können. Es geht eher um die Art und Weise, wie Endanwender zu kommerzieller Software stehen. Können sie sich vorstellen, ein Produkt zu kaufen? Oder wird es bei der erstbesten Gelegenheit kopiert? Häufig ist dieses Phänomen bei App Stores diverser Hersteller zu beobachten. Kostenfreie Apps werden zuhauf heruntergeladen. Deutlich weniger Anwender sind aber bereit, eine abgespeckte Lite-Version in eine Vollversion umzuwandeln, auch wenn die angebotenen Funktionen nützlich sind. Selbst in der Regel kleine Beträge schrecken viele Nutzer ab. Bei hochpreisigen Produkten verstärkt sich dieser Faktor noch einmal.

Abbildung 2 zeigt ein Diagramm mit verschiedenen Kategorien für Anwender.

Abbildung 2 | Anwenderkategorien mit fiktiver prozentualer Verteilung.

Um konkrete Prozentwerte geht es hier gar nicht. Diese sind auch schwer zu erheben und meines Wissens nach gibt es keine großangelegte Studie, die diese Zahlen ermittelt. Das Diagramm soll nur ein Gefühl dafür vermitteln, welche verschiedenen Kategorien von Anwendern auf Entwickler zukommen, wenn es um den Vertrieb einer kommerziellen Software geht.

Alle Anwender – egal welcher Kategorie – gehen mit einer anderen Denkweise und Einstellung an die Überlegung heran, eine Software zu kaufen oder nicht. Ein Lizenzmodell muss auf der einen Seite das Softwareprodukt gegen einen einfachen Diebstahl schützen. Gleichzeitig aber auch nicht zu abschreckend und kompliziert sein, um potenzielle, ehrliche Käufer von einem Kauf abzuhalten.

Der gelbe Bereich kennzeichnet die Benutzergruppe, die sich eine Software finanziell nicht leisten kann. Egal wie nützlich oder gut die Anwender das Produkt auch finden mögen. Es ist kein Geld da. Der Vertrieb kann versuchen, diese Gruppe mit Rabatten oder sonstigen Marketing-Aktionen zu ködern, allerdings wird es niemals gelingen, alle Anwender dieser Gruppe in zahlende Kunden zu verwandeln.

Zur blauen Kategorie zählen die schwierigsten Anwender und Anwenderinnen. Sie haben kein Interesse an einem Softwareprodukt, da sie es nicht für wertvoll oder sinnvoll genug halten. Daher zählen Personen in dieser Gruppe auch nicht zu den zahlenden Kunden. Hier ist es nicht leicht, über ein Lizenzmodell neue Interessenten zu gewinnen. Eine Möglichkeit ist, eine modulare Software anzubieten, bei der nur die benötigten Funktionen und Komponenten bezahlt werden müssen. Wie schon erwähnt, ist eine Modularisierung von Software etwas, das durch ein Lizenzmodell erreicht werden kann. Trotzdem kann es immer noch sein, dass sich die Anwender nicht in die grüne Kategorie transferieren lassen. Hier helfen nur innovative Funktionen und ausgereifte Dienstleistungen. Eine Lizenzierung an sich stößt hier an seine Grenzen.

Die orange Gruppe, die eine Software aus Angst bezahlt, ist etwas ambivalent. Sie wissen zwar, dass die Software wichtig ist und ihnen nützt, sie kaufen diese aber nicht, weil sie die Arbeit des Herstellers honorieren. Sie zahlen schlicht aus dem Grund, um einer Strafverfolgung oder anderen, weniger schlimmen Folgen zu entgehen. Beispielsweise könnte die Software mitten im produktiven Betrieb den Dienst versagen, weil ein Lizenzschlüssel als ungültig erkannt wird. Da dieser Ausfall einen deutlich höheren Schaden verursachen kann und die betreffende Anwendergruppe das weiß, wird das Produkt lieber käuflich erworben. Ziel sollte es sein, so viele Anwender wie möglich aus der orangen in die grüne Kategorie zu verschieben.

Die grüne Kategorie enthält Anwender enthalten, die für eine Software zahlen, weil sie diese wertschätzen und wissen, was sie von ihr haben. Diese Gruppe macht jeden Unternehmer glücklich. Diese können das ein oder andere Problem mit dem Produkt verschmerzen, da sie zu schätzen wissen, was sie an der Software haben. Folglich sollte dieser Bereich so groß wie möglich sein.

Die letzte Gruppe von Anwendern ist in der grauen Kategorie zusammengefasst. Hier befinden sich alle Anwender, die starkes Interesse an der Software haben, diese aber nicht käuflich erwerben, weil eine Raubkopie sehr einfach anzufertigen ist. Damit ist diese Anwendergruppe auch gleichzeitig das Hauptziel für ein Lizenzmodell, denn das simple Kopieren eines Produkts soll durch die Lizenz erschwert werden. Nicht nur rechtlich, sondern vor allem auch technisch. Diese Gruppe klein zu halten ist das Hauptziel jedes Softwareunternehmens,