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.
In diesem Buch stecken viel Wissen, Empfehlungen, Tipps, Tricks und Ideen, um ein Lizenzmodell mit der Sprache .NET zu implementieren. Dennoch ist damit noch nicht Schluss, denn es gibt noch viele weitere Möglichkeiten, ein Lizenzmodell umzusetzen oder zu erweitern, um die kennengelernten Probleme auszumerzen.
In naher Zukunft ist es mein Ziel, genau diese Aspekte auch in einem Buch abzudecken. Nach Möglichkeit die beispielhafte Implementierung aller Policy Patterns, um die Eigenschaften und Eigenarten besser herauslösen zu können. Zudem möchte ich gerne die Probleme und Fragen angehen, die einige Muster offen lassen. Denn ein Muster ist auch nur genau das: eine Vorlage. Die konkrete Umsetzung kann davon abweichen und muss das in der Praxis auch sehr häufig.
In welchem Rahmen diese Weiterentwicklung passiert, ist mir noch nicht ganz klar. Das kommt auch darauf an, wie das Feedback zu meinen Arbeiten rund um die Implementierung von Lizenzmodellen in .NET ausfällt. Scheuen Sie sich also nicht, mir Feedback zu geben.
Als Fazit bleibt mir noch zu sagen, dass Lizenzmodelle spannender sein können, als vielleicht am Anfang vermutet. Sie bieten aber auch viele Fallstricke. Sowohl bei der eigenen Implementierung, als auch bei der Integration einer bekannten Methode oder Bibliothek.
Insbesondere Portable.Licensing hat das Zeug, viele Schwierigkeiten zu meistern und ich hoffe, die Bibliothek wird sich auch in Zukunft weiterentwickeln, um noch weitere Einsatzszenarien abzudecken.
Den kompletten Quellcode finden Sie zum Download unter www.developer-media.de/Quellcode_Implementierung-von-Lizenzmodellen-in-.NET_.zip.
[1]: Verkaufszahlen zu Windows 95:
http://www.winhistory.de/more/win95.htm
[2]: Heise-Meldung zur Rootkit-Funktion des Sony-Kopierschutzes:
http://www.heise.de/newsticker/meldung/Sony-BMGs-Kopierschutz-mit-Rootkit-Funktionen-143366.html
[3]: Info-Seite von EA zu Server-Abschaltungen:
http://www.ea.com/de/1/service-updates
[4]: Software as a Service auf Wikipedia:
http://de.wikipedia.org/wiki/Software_as_a_Service
[5]: Platform as a Service auf Wikipedia:
http://de.wikipedia.org/wiki/Platform_as_a_Service
[6]: Übersichtsseite zu Lizenzvereinbarungen von Blizzard:
http://eu.blizzard.com/de-de/company/legal/
[7]: Studie zur weltweiten Softwarepiraterie:
http://globalstudy.bsa.org/2011/
[8]: Martin Fowler zu Feature Toggles:
http://martinfowler.com/bliki/FeatureToggle.html
[9]: Security by Obscurity auf Wikipedia:
http://de.wikipedia.org/wiki/Security_through_obscurity
[10]: Webseite von Balsamiq:
https://balsamiq.com/
[11]: Webseite von Mite:
http://mite.yo.lk/
[12]: Xamarin-Forum zu den Lizenzänderungen:
http://forums.xamarin.com/discussion/9902/xamarin-license-is-not-perpetual-anymore
[13]: Build-Tool FAKE:
http://fsharp.github.io/FAKE/index.html
[14]: Blog von Steffen Forkmann:
http://www.navision-blog.de/blog/steffen-forkmann-ueber-mich/
[15]: License Generator auf CodePlex:
http://licensekeygenerator.codeplex.com/
[16]: Unique Finger Print auf CodePlex:
http://www.codeproject.com/Articles/28678/Generating-Unique-Key-Finger-Print-for-a-Computer
[17]: Die SKGL-Bibliothek auf CodePlex:
http://skgl.codeplex.com/
[18]: Software Protector auf CodePlex:
http://softwareprotector.codeplex.com/
[19]: GitHub-Repository zu Rhino Licensing:
https://github.com/ayende/rhino-licensing
[20]: Blog von Ayende Rahien:
http://ayende.com/blog/
[21]: Webseite der hibernating rhinos:
http://hibernatingrhinos.com/
[22]: Das RSA-Kryptosystem auf Wikipedia:
http://de.wikipedia.org/wiki/RSA-Kryptosystem
[23]: Webseite zu Portable.Licensing:
http://dev.nauck-it.de/projects/portable-licensing
[24]: Webseite von Daniel Nauck:
http://www.rootbash.com/home/
[25]: Der ECDS-Algorithmus auf Wikipedia:
http://de.wikipedia.org/wiki/Elliptic_Curve_DSA
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.
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.
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.