12.04.2021 | Peter Mosbauer

Oracle Lizenzierung: Diese typischen Fehler lassen sich vermeiden

„Oracle ist teuer, kompliziert und nur für Großkunden“. Das ist der Ruf von Oracle, mit dem wir häufig in der täglichen On Premises Lizenzierungspraxis von unseren Resellern und deren Endkunden konfrontiert werden. Das stimmt so pauschal natürlich nicht. Dennoch sollte man auf Details achten und Fehler vermeiden, um am Ende eine korrekte und günstige Lösung für den Kunden zu finden, sei dies ein Mittelständler oder ein Großkonzern.

Mir sind in 22 Jahren Lizenzierungspraxis wiederholt Stolperfallen der Oracle Software Lizenzierung begegnet, die man durchaus umgehen kann, wenn man sie kennt. Ich möchte in diesem Artikel daher näher darauf eingehen und Sie für diese typischen, vermeidbaren Fehler sensibilisieren.

These 1: Nicht alles, was technisch möglich ist, ist auch lizenzrechtlich erlaubt.

Oracle vergibt keine Lizenzkeys oder Zertifikate, die den Nutzungsumfang seiner Programme reglementieren. Die Nutzung der Software Programme beruht auf dem Vertrauen, dass sich der Kunde vertragskonform verhalten möge. Ich rate daher jedem Kunden, mit dieser Verantwortung seriös umzugehen.  Zunächst sollte ein Kunde also seine Lizenzverträge kennen und bei der Installation darauf achten, dass er hinterher nicht mehr nutzt als erlaubt ist. So manches Versehen unterläuft dem Kunden bei der Installation, indem er Funktionen aktiviert, die lizenzpflichtig sind. Üblicherweise erwirbt man Optionen und/oder Packs, die erst die Nutzung erweiterter Funktionalitäten erlauben. Und die Optionen und Packs müssen in der Anzahl und Metrik mit dem zugehörigen Produkt übereinstimmen. Z.B. Tuning und Diagnostics Pack zur Datenbank Enterprise Edition. Aber das muss man wissen, um nicht versehentlich in eine unsichtbare Lizenzfalle zu tappen.

Es gibt übrigens kein Downgraderecht bei den Editionen: wenn der Kunde die Datenbank Enterprise Edition lizenziert, aber die kleinere Datenbank Standard Edition 2 installiert, so ist die Nutzung dieser SE2 nicht abgedeckt. Der Kunde ist folglich für die Datenbank SE2 unterlizenziert und müsste bei einem Audit durch Oracle diese Edition unnötigerweise nachlizenzieren.

Die große Mehrheit der Kunden legt nach unserer Erfahrung verstärkten Wert auf eine korrekte Lizenzierung. Die meisten Unterlizenzierungen, denen wir begegnen, beruhen auf Unwissenheit und falschen Annahmen. Typischerweise gehört dazu die irrige Meinung, dass Mutter- und Tochtergesellschaften im In- und Ausland nutzungsberechtigt seien, wenn eine Konzerngesellschaft die Lizenzen erwirbt. Dem ist nicht so. Nur die juristische Person, die den Lizenzvertrag (TOMA oder OMA) unterschreibt, erwirbt das Eigentum am Nutzungsrecht der Programme für seine internen Geschäftszwecke, und auch nur in dem Land, wo diese Gesellschaft als Lizenznehmer ihren Sitz hat. Man kann sich übrigens erweiterte Nutzungsrechte für mehrere Konzerngesellschaften ohne territoriale Beschränkung festschreiben lassen, aber nur vor Erwerb der Lizenzen. Wenn man also seine Lizenzsinne für relevante Details rechtzeitig schärft, lassen sich diese Herausforderungen meist sehr einfach lösen.

Weiterlesen auf Seite 2

These 2: Lizenzregeln folgen nicht bekannten Denkmustern, sondern jeder Hersteller definiert diese individuell.

Hier trifft man oft auf die typische Aussage „aber da läuft ja kein Oracle drauf“. Logisch betrachtet hat der Kunde häufig recht, und aus technologischer Sicht meist auch. Aber es ist der Hersteller, der die Regeln vorgibt. Und bei einem Einsatz von Oracle Software Programmen in virtualisierten Umgebungen gilt, dass die ganze physische Basis lizenzrechtlich zu betrachten ist. Oracle geht also immer vom maximal Möglichen aus. Bei VMware Umgebungen wären das folglich alle ESX Hosts in einem Unternehmen, die man in die lizenzrechtliche Betrachtung einzubeziehen hat. An dieser Stelle sei vor Informationen gewarnt, die man im Internet zuhauf findet, die aber oft ungenau oder gar falsch sind. Man sollte sich als Endkunde vielmehr an einen erfahrenen Oracle Partner wenden, der hierzu ggf. passende Lösungen ausarbeiten kann.

Auch in Failover- oder Standby-Umgebungen wird die Datenbank auf dem „Backup-Server“ nach Ansicht des Kunden nicht aktiv genutzt, muss aber doch meist lizenziert werden. Hier sollte man sich von Experten erläutern lassen, was Oracle denn genau unter „Failover“, „Standby“ und „Backup“ versteht, bevor man durch die Installation oder den Kauf der Lizenzen Fakten schafft, die man hinterher nur mit Mühe korrigiert bekommt.

Auch ein häufiger Fehler, der sich leicht vermeiden lässt, indem man ein funktionierendes Software Asset Management aufbaut: man hat ähnliche Produkte (z.B. verschiedene Oracle Datenbank Editionen) im Einsatz, aber nur ein Teil der Lizenzen ist bei Oracle mit einem gültigen Wartungsvertrag ausgestattet. Dieser Verstoß gegen das vertraglich verankerte „Matching Service Level“ kann unangenehme Folgen haben in Form einer unerwarteten Nachforderung von Supportgebühren durch Oracle, die man in der Regel nicht im Budget vorgesehen hat.

Das am meisten unterschätzte Thema in der Oracle Lizenzierung ist das des Datentransfers in Verbindung mit der Named User Metrik. Oracle zählt die User am so genannten Multiplexing Frontend, welches sich oft hinter diversen Schnittstellen am Ende einer Datentransferkette verbirgt. Im Zweifel sollte der Kunde hier die Prozessormetrik wählen, wenn er den Nutzerkreis aufgrund der Schnittstellenthematik nicht exakt eingrenzen kann. Man darf eben nicht fälschlicherweise davon ausgehen, dass man die Datenbank hinter einem Bankautomaten mit einer Einzelplatzlizenz ausreichend lizenziert hat, weil immer nur eine Person zu einem bestimmten Zeitpunkt diesen bedienen kann. Die Bank, die leider diese Annahme traf, wurde von Oracle auditiert und musste nachlizenzieren.

These 3: Jede Änderung führt zu einer Neubewertung der Lizenzsituation

Der Klassiker ist hier der Hardwarewechsel. Ich habe am Anfang dieses Jahrtausends zum Teil auf Basis von Megahertz-Taktung Lizenzen verkauft, die in der Regel beim nächsten Rechnertausch nicht mehr gepasst haben. Auch gibt es lizenzrechtliche Hardwaregrenzen zu beachten. Oracle bietet beispielsweise ein Produkt namens Database Standard Edition 2 an, welches auf Maschinen mit maximal zwei Prozessorsockeln laufen darf, die nur mit Single-Chip-Prozessoren bestückt werden dürfen. Technisch läuft die Edition auch auf größeren Maschinen und mit Multi-Chip-Modulen, aber lizenzrechtlich ist das nicht erlaubt. Damit schließt sich hier der Kreis zur ersten These.

Noch ein letzter wichtiger Tipp: auch Ansprechpartner, z.B. beim Hersteller, wechseln gelegentlich. Und mit jedem neuen Ansprechpartner kann sich die Sicht des Herstellers auf eine Lizenzsituation ändern. Lassen Sie sich also lizenzrelevante Aussagen immer schriftlich bestätigen und bewahren Sie den Schriftverkehr gut auf.

Ich habe nur einige typischen Fehler aufgezählt, die uns immer wieder in der täglichen Arbeit begegnen. Um sich wirklich sicher zu sein, dass man am Ende korrekt lizenziert ist, sollte man stets ausgewiesene Experten zu Rate ziehen. Als Reseller zum Beispiel Tech Data als Value Added Distributor, der seit 25 Jahren Oracle Lizenzen vertreibt. Oder als Endkunde einen erfahrenen Oracle Partner, der nachweislich über lizenzrechtliches Know-how verfügt, Ihre Situation mit seiner Expertise analysiert und zu Ihrem Vorteil kommerziell, vertraglich und/oder technisch löst. Auch können Kunden selbst natürlich ihren Teil dazu beitragen, indem sie das Thema Lizenzmanagement ernst nehmen und durch professionelle Handhabung für zuverlässige Transparenz im eigenem Unternehmen sorgen.

Über den Autor

Peter Mosbauer | Website

Peter Mosbauer ist seit 2008 als Product Sales Specialist in der Oracle Abteilung tätig. Zuvor war er in der Distribution und bei zwei Systemhäusern in verschiedenen Positionen im Vertrieb und Produktmarketing aktiv. Sein Fokus lag immer auf der Oracle Software und deren Lizenzierung, wobei er auch fortlaufend technisches und vertriebliches Know-how zu anderen Software Herstellern aufgebaut hat. Neben der Betreuung und Beratung von Oracle Partnern gehören das Herstellermanagement, die Ausarbeitung komplexer technischer Angebote sowie die Durchführung von vertrieblichen und technischen Schulungen zu seinen Aufgaben.

  • Drei Fragen an den Autor

    Was ist deine Funktion bei Tech Data?

    Ich bin Product Sales Specialist

    Wie lange bist du schon beim Unternehmen?

    Inzwischen seit 13 Jahren

    Was für einen Unterschied macht deine Arbeit?

    Die Erfahrung und das Know-how von 22 Jahren im Oracle Business

Zur Specialists Übersicht