Implementierung von Lizenzmodellen in .NET. Fabian Deitelhoff
Чтение книги онлайн.
Читать онлайн книгу Implementierung von Lizenzmodellen in .NET - Fabian Deitelhoff страница 4
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