Zum Inhalt springen

Lizenzierung

Die DOAG als Ansprechpartner

Im Zusammenhang mit den Lizenzverfahren von Oracle treten hin und wieder Probleme oder Unklarheiten auf, die nicht zur Zufriedenheit des Kunden geklärt werden können. Die DOAG unterstützt ihre Mitglieder, um bei diesen Konflikten gute Lösungen herbeizuführen.

01 Feb

Oracle ändert seine Lizenzregelungen für Nutzer der AWS- und Azure-Cloud

Beim Einsatz von Oracle-Produkten auf Microsoft Azure oder Amazon EC2 und RDS müssen Nutzer mit geänderten Lizenzkosten rechnen. In dem kürzlich...

13 Jan

Java SE: Kommerzielle Features müssen explizit aktiviert werden

Grundsätzlich kann Oracles Java Standard Edition (SE) als Programmiersprache und Laufzeitumgebung frei von finanziellen Verpflichtungen gegenüber dem...

26 Apr

Das Lizenzaudit – kein Grund zur Panik

Ralf Appelbaum, Berater bei der TEAM GmbH, beantwortet im Interview mit Dr. Dietmar Neugebauer, Vorstandsvorsitzender der DOAG, die brennenden Fragen...

DOAG Lizenzguide

Der Arbeitskreis Lizenzierung hat unter der Leitung von Michael Paege einen kompakten, digitalen Lizenzguide herausgebracht, in dem die wichtigsten Aspekte der Lizenzierung von Oracle-Software zusammengefasst sind. Diesen können DOAG-Mitglieder kostenfrei herunterladen. 

Mitglieder der SOUG und der AOUG können ihre Version über folgenden Link kostenfrei bestellen.
» Lizenzguide bestellen (für SOUG und AOUG)

Die DOAG informiert zum Thema Lizenzen

Lizenzierung technischer Oracle Produkte

Die Lizenzierung der Oracle-Produkte ist ein relativ komplexes Thema, bei dem sehr viele unterschiedliche Aspekte eine Rolle spielen. Eine Lizenz-Optimierung des Unternehmens kann zu erheblichen Einsparungen führen. Daher lohnt es sich, das Thema aufzugreifen. Hier finden Sie Basis-Informationen zu den unterschiedlichen Lizenz-Modellen.

Eingebettete Software-Lizenz
Die Oracle Datenbank wird in einer Applikation genutzt, ohne dass der Anwender diese verändern kann oder (mitunter) davon weiß.

Application Specific Full Use (ASFU)
Die Oracle Datenbank wird zusammen mit einer Applikation vermarktet. Der Anwender kann auf die Software zugreifen, hat aber keinen direkten Kontakt zu Oracle.

Full Use
Der Anwender kann direkt auf die Software zugreifen und beliebige Applikationen darauf verwenden. 

Named User Plus (NUP)
Benutzeranzahl kann ermittelt werden

Named User Plus sind Einzelbenutzer, die zur Verwendung der Oracle Software berechtigt sind, die auf einem einzelnen oder mehreren Servern installiert ist - unabhängig davon, ob der Benutzer die Programme jemals aktiv verwendet. Ein nicht-benutzerbedientes Gerät zählt ebenfalls als Named User Plus. Automatische Stapelverarbeitung ist zulässig. Alle Personen und nicht-benutzerbetriebenen Geräte mit Programmzugriff müssen lizenziert werden. Die Anzahl der erforderlichen Lizenzen ergibt sich aus der Mindestanzahl oder der Gesamtanzahl der tatsächlichen Benutzer mit Datenbankzugriff (ausschlaggebend ist die größere Zahl).

Prozessor
Benutzeranzahl kann nicht ermittelt werden (z.B. offene Internet-Anwendungen)

Bei dieser Lizenzmetrik sind alle Prozessoren, auf denen die Oracle Software installiert ist und/oder ausgeführt wird, zu lizenzieren. Der anschließende Zugriff kann durch interne Benutzer sowie Dritte erfolgen. Die zu lizenzierende Anzahl der Kerne bei Mehrkern-Prozessoren ermittelt man wie folgt: Summe aller Kerne auf allen Multicore Chips für jedes Lizenzprogramm × Kernprozessor-Lizenzfaktor. Gebrochene Zahlen sind auf die nächsthöhere Zahl aufzurunden. Die Tabelle zu den Kernprozessor-Lizenzfaktoren finden Sie hier. Sie kann sinnvoll sein, wenn sie wirtschaftlicher als die Named-User-Plus-Metrik ist. Automatische Stapelverarbeitung ist zulässig. Mindestvorgabe für Oracle 10g Database SE One, SE und EE ist ein Prozessor je Server. 

Höchstvorgaben
Die Höchstvorgaben für die jeweilige Edition der Datenbank bestimmen, welche Edition bei gegebener Hardware mindestens lizenziert werden muss. Werden spezielle Funktionalitäten etwa aus einer Edition genutzt, muss auch diese Edition lizenziert werden, auch wenn laut Höchstvorgaben eine "kleinere" Edition machbar wäre.

Für die Bestimmung der machbaren Edition ist die Anzahl der im Server/Cluster vorhandenen Prozessorsockets maßgeblich – egal, ob gefüllt oder nicht gefüllt. Zu lizenzieren sind nur gefüllte Prozessorsockets.

Seit Februar 2007 ist für die Höchstvorgaben der Editionen nur noch die Anzahl der Prozessorsockets des Mainboards maßgebend. Ob Singlecore-, Dualcore- oder Quadcore-Prozessoren verwendet werden, spielt bei der Betrachtung der Höchstvorgaben/Editionen keine Rolle – wohl aber bei der Lizenzierung. 

  • Standard Edition One: 2 Prozessorsockets 

  • Standard Edition: 4 Prozessorsockets 

  • Standard Edition mit RAC:  4 Prozessoren insgesamt (4x1 oder 2x2 CPU-Cluster) Nur bei 10g/11g Nur mit ASM und Oracle ClusterReadyServices 

  • Enterprise Edition:  Keine Höchstvorgaben

Lizenzmodelle von Oracle Business Lösungen

Für die Oracle Applikationen E-Business Suite, Siebel, PeopleSoft und JD Edwards wurden die Lizenzmodelle vereinheitlicht. Es bestehen drei grundsätzliche Lizenzmodelle.

Jedes Produkt aus den Oracle Applikationen ist unter mindestens einem der genannten Lizenzmodelle verfügbar. Die unterschiedlichen Lizenzmodelle ermöglichen dem Kunden ein flexibles und auf seine Bedürfnisse zugeschnittenes Lizenzieren der Applikationsprodukte.

Der Kunde lizenziert genau die Produkte, die er nutzen will. Die Lizenzmetrik beim "Component" Preismodell ist entweder Nutzer- (user-based) oder Kennzahlen-basiert (usage-based). Bei den Nutzer-basierten Metriken wird das jeweilige Produkt für jeden sogenannten Application User (vergleichbar mit einem Named User) oder jeden Beschäftigten (Employee) lizenziert. In der Regel kommt das "Component" Preismodell mit der Nutzer-basierten Metrik für eine kleine Anzahl von Anwendern beziehungsweise beim Einsatz von nur wenigen Applikationsprodukten zum Einsatz.

In der Kennzahlen-basierten (usage-based) Metrik werden einzelne Produkte in Abhängigkeit von Kennzahlen (Umsatzkosten, Anzahl Auftragspositionen …) lizenziert.

Für mittelständische Kunden mit einem Jahresumsatz unter einer gewissen Grenze werden angepasste Preise verwendet.

Mit dem "CAS" Preismodell hat der Kunde die Möglichkeit, Produkte nach seinen Anforderungen zusammenzustellen und diese für sogenannte Custom Suite User (vergleichbar mit Named User) zu lizenzieren. Der Custom Suite User kann alle im für ihn lizenzierten Bündel enthaltenen Produkte nutzen.

Im CAS Modell müssen Lizenzminima und andere Restriktionen beachtet werden. Für mittelständische Kunden mit einem Jahresumsatz unter einer gewissen Grenze werden angepasste Preise verwendet.

Müssen viele Anwender (interne oder externe) lizenziert werden, lässt sich mit dem "Enterprise Applications" Preismodell die gesamte Organisation mit Lizenzen der gewünschten Produkte versorgen. Dieses Preismodell kann für große Organisationen oder unübersichtliche Strukturen von Vorteil sein. Das "Enterprise Applications" Preismodell hat mehrere Metriken. Die am häufigsten eingesetzten Kennzahlen-basierten Metriken beziehen sich auf den Gesamtumsatz pro Jahr, die Anzahl der Beschäftigen oder die Umsatzkosten (Cost Of Goods Sold). Es müssen weitere Restriktionen (Minima …) eingehalten werden.

Gebrauchtlizenzen

Beim Kauf und Verkauf von sogenannten Download-Gebrauchtlizenzen ist die Rechtslage noch unübersichtlich und vor allem nicht abschließend geklärt. Deswegen rät die DOAG hier zu einer genauen Prüfung und wird auf DOAG Online über zukünftige Entwicklungen informieren.


Audits

Oracle kann im Rahmen eines Audits überprüfen, wie Oracle-Produkte in einem Unternehmen genutzt werden, und ob die tatsächliche Nutzung der Produkte bezüglich installierter Editionen, Optionen, Hardware, Prozessoren und Nutzerzahlen den Lizenzverträgen entspricht. Hier finden Sie alles Wissenswerte darüber und wie Sie sich im Falle eines solchen Audits am besten verhalten. 

Bei einem Audit wird überprüft, wie Oracle-Produkte in einem Unternehmen genutzt werden und ob die tatsächliche Nutzung der Produkte bezüglich installierter Editionen, Optionen, Hardware, Prozessoren und Nutzerzahlen den Lizenzverträgen entspricht.

Oracle hat dafür eine eigene Abteilung "License Management Services" (LMS), die auch in Deutschland in den Oracle Niederlassungen ansässig ist, organisatorisch jedoch zur Abteilung Finance der Oracle EMEA-Organisation gehört. Darüber hinaus sind auch einige Oracle-Partner von LMS zertifiziert, in deren Auftrag Audits durchzuführen.

Im Oracle Lizenz- und Service-Vertrag (OLSA), dem jeder Kunde beim Lizenzkauf zustimmen muss, ist im Abschnitt O. "Sonstige Bedingungen" folgendes festgelegt: "Oracle darf Ihre Nutzung der Programme prüfen (Audit), vorausgesetzt, Oracle kündigt die Prüfung 45 Tage im Voraus schriftlich an. Zudem verpflichten Sie sich, für Ihre nicht von Ihren Lizenzrechten gedeckte Nutzung der Programme anfallende Gebühren nach schriftlicher Aufforderung nachzuentrichten. Wenn diese Zahlung nicht erfolgt, ist Oracle berechtigt, Ihre technische Unterstützung, Ihre Lizenzen und/oder diesen Vertrag außerordentlich zu kündigen. Sie erklären sich damit einverstanden, dass Oracle nicht für Kosten einzustehen hat, die Ihnen durch Ihre Mithilfe bei Oracles Audit entstehen."

Meist werden Audits von Oracle eingeleitet. Dass hierbei ein – woher auch immer stammender – Verdacht auf vermeintliche Unterlizenzierung bei einem Kunden Auslöser für ein Audit sein kann, ist eine Vermutung. So können beispielsweise angefragte und verhandelte, dann aber nicht gekaufte Lizenzerweiterungen einen solchen Verdacht auslösen. Allerdings spricht die organisatorische Trennung von Vertrieb und LMS in unterschiedlichen Organisationen dafür, dass LMS nicht verlängerter Arm des Oracle Vertriebs ist.

Audits können aber auch vom Kunden selbst initiiert werden, falls der Kunde im Laufe der Zeit den Überblick über vorhandene Lizenzen und Lizenznutzung verloren hat, beispielsweise in stark dynamisch wachsenden Unternehmen oder wegen eines Personalwechsels im Lizenz-Management.

Jeder Kunde hat seine spezielle Situation, auf die natürlich eingegangen wird. Generell läuft ein Audit wie folgt ab:

  • Oracle kündigt das Audit schriftlich an 
  • Vorbesprechung beim Kunden mit Klärung aller Fragen 
  • Erstellen einer Übersicht über Server, Datenbanken und Applikationen gemeinsam mit dem Kunden
  • Gegebenenfalls Installation der Mess-Skripte und -Routinen auf den Servern des Kunden, um das Nutzungsverhalten mitloggen zu können. Diese Mess-Routinen laufen typischerweise für etwa zwei Wochen und sammeln diverse Login-, User- und Session-Daten, die anschließend von LMS ausgewertet werden.
  • Abgleich der Mess-Ergebnisse mit dem Kunden, um ein gemeinsames Bild zu bekommen 
  • Abgleich der ermittelten Nutzung mit dem vorhandenen Lizenzbestand beziehungsweise den aktuellen Lizenzierungsregeln 
  • Erstellung des abschließenden Berichts

Konstruktive Mitarbeit ist hilfreich. Auch und gerade bei aufgedeckten Unterlizenzierungen kann eine konstruktive Mitarbeit und der Wille, diese – oft in Unkenntnis – entstandenen Unterlizenzierungen zu beseitigen, in Verhandlungen dazu führen, dass Oracle auf seine berechtigten und laut OLSA vertraglich vereinbarten Nachzahlungen verzichtet.

Es gab schon mehrere Fälle, in denen seitens LMS die tatsächliche Nutzung beim Kunden zwar korrekt mit den aktuellen Lizenzierungsregeln abgeglichen wurde, ein Abgleich mit dem vertraglich vereinbarten Lizenzbestand und den Sonderregeln aber nicht stattgefunden hat. So kam es seitens Oracle zu hohen Nachforderungen, die aber keinen Bestand hatten, weil der Kunde über einen ungekündigten Altvertrag verfügte, der eine solche Nutzung auch zuließ.

Falls der Kunde die Ergebnisse des Audits anzweifelt, sollte er eine zweite Meinung eines hinsichtlich Lizenzierung sehr erfahrenen Oracle-Partners einholen. Die DOAG hilft bei der Vermittlung solcher Partner.

Natürlich ist vorbeugend ein sauberes Lizenz-Management unter Nutzung von Enterprise-Architecture-Übersichten und -Werkzeugen und die daraus resultierende korrekte Lizenzierung der beste Schutz vor einem Audit. Wer als Kunde auf Knopfdruck darstellen kann, dass er korrekt lizenziert ist, braucht auch kein Audit zu fürchten.

Fragenkatalog

Mit Ihrem Einverständnis veröffentlichen wir Ihre Fragen anonymisiert auf dieser Seite. 

Fragen: Fall 1: Der Kunde hat zwei physische Server (je 2 Sockets, jeder Socket ist bestückt), die mit VMware virtualisiert sind, um mit VMotion Technologie komplette virtuelle Maschinen im laufenden Betrieb von einem Server auf einen anderen zu verschieben (alternativ auch Hyper V mit Live-Migration. Die Datenbank läuft prinzipiell immer nur über einen Server, beim Umschalten jedoch für einen kurzen Zeitraum auf beiden, danach auf dem anderen. Der Kunde möchte 4 Prozessorlizenzen DB SE1 lizenzieren. Ist dies möglich?

Fall 2: Der Kunde hat zwei physische Server (je 2 Sockets, jeder Socket ist bestückt). Die zwei Server bilden einen Ressourcen-Pool, d.h. sie hängen im SAN. Die Datenbank läuft immer nur über einen Server. Fällt dieser aus, wird die DB in dem zweiten Server gebootet (VMware DRS + HA) – (Alternativ auch Hyper V mit Cluster). Zu einem bestimmten Zeitpunkt wird also die DB immer nur die Power von 2 CPU haben. Der Kunde möchte 4 Prozessorlizenzen DB SE1 lizenzieren. Ist dies möglich?

Der Unterschied der beiden Fälle ist nur in dem Automatikverfahren VMotion/Live-Migration. Mit der Lizenz SE ist man auf der sicheren Seite, der Wunsch besteht aber die kostengünstigere Variante der SE1 zu nehmen, die jedoch maximal 2 Sockets voraussetzt. Also ist die Frage ob jede physikalische Hardware einzeln zählt oder nicht, dies würden wir im Fall 2 so sehen, im Fall 1 ist das fragwürdig.

Antwort: Das gesamte Cluster muss lizenziert werden. Dies ist eine grundsätzliche Regel bei Softpartitionierung, der VMWare und HyperV zugerechnet werden. Die Art der Automatisierung ist hierbei für die Lizenzierung unerheblich. Sofern in dem Cluster kein Server über mehr als zwei Prozessorsockel verfügt, kann – wenn es von der Funktionalität her reicht – die DB SE1 lizenziert werden. Dies muss allerdings für alle bestückten Prozessorsockel geschehen.

Aufgrund der vorliegenden Informationen können wir feststellen: Somit wäre die Lizenzierung bei beiden Varianten mit 4 Prozessoren DB SE1 machbar.

Frage: Woran erkennt der Oracle Auditor, welche Version tatsächlich lizenziert ist (Selects, Abfragen,…)?

Antwort: Die Edition der Datenbank ist erkennbar, wenn man sich per SQL*Plus anmeldet, oder auch mittels eines Select auf die Spalte BANNER der View V$VERSION. Welche Ermittlung genau bei einem Oracle Audit passiert, ist uns im Detail nicht bekannt.

--

Frage: Wie kann man eine benutzerdefinierte Installation als Standard Edition (One) durchführen?

Antwort: Eine SE/SE1 kann nur korrekt als solche installiert werden, wenn man im Installer "Standard Edition" auswählt. Sobald man "Custom" auswählt, wird als Ergebnis immer eine Enterprise Edition erzeugt. Um eine SE One zu installieren, muss man eine SE-Installation durchführen, dies aber auf einem Server mit maximal 2 physikalischen Prozessorsockeln.

--

Frage: Wenn eine Installation als Enterprise Edition erkannt wurde, wie kann man diese auf eine Standard Edition downgraden?

Antwort: Per Export, Neuinstallation und Import.

Frage: Wir planen, eine Datenbank auf einen neuen Windows Server umzuziehen. Unser Serveradmin-Team hat Windows-Server mit zwei Intel-CPUs mit jeweils 12 Kernen standardisiert. Man könnte jedoch im BIOS eine CPU und die Hälfte der Kerne der anderen CPU abschalten. Muss man trotzdem für 2 CPUs mit jeweils 12 Kernen Oracle EE Lizenzen kaufen, oder wären Lizenzen für 1x6 Kerne ausreichend, wenn man die restlichen Kerne über BIOS deaktiviert?

Antwort: Das Abschalten von Prozessoren/Cores wird seitens Oracle nicht als Hardpartitioning gewertet und dient somit nicht zur Reduktion der zu lizenzierenden Prozessoren. Es müssen also alle in dem Server enthaltenen Cores zur Ermittlung der zu lizenzierenden Prozessoren gezählt werden.

Frage: Ein Unternehmen hat vor einigen Jahren eine Lizenz Oracle Enterprise 40 NUP für eine Datenbank Version 9.2 erworben. Darf mit dieser Lizenz ein Upgrade auf die Version 10.2 oder 11.2 erfolgen?

Antwort: Ja, sofern diese Lizenz bis heute unter Support ist. Wenn die Lizenz ohne Support erworben wurde, darf nur die damals eingespielte Version verwendet werden.

Frage: Wenn man eine Lizenz für die Oracle Enterprise Edition hat (Prozessor oder NUP), muss dann die Enterprise Edition installiert sein oder geht auch die Standard Edition?

Antwort: Wenn die Enterprise Edition lizenziert ist, muss auch die Datenbank Enterprise Edition installiert sein. Standard Edition und Standard Edition One sind eigenständige Produkte, die nicht in der Lizenz der Datenbank Enterprise Edition enthalten sind.

Frage: Ein Unternehmen sucht nach Informationen, wie mit dem Thema "Oracle Lizenzierung" im Umfeld Live Partition Mobility bei AIX umzugehen ist. Gibt es hier eine offizielle Information von Oracle?

Antwort: Außer dem bekannten Partitioning-Dokument gibt es keine zusätzlichen Aussagen. Die DOAG empfiehlt für Fälle, in denen die geplante Architektur nicht aus den beschriebenen Dokumenten zweifelsfrei ableitbar ist, diese durch Oracle schriftlich bestätigen zu lassen, indem ein Advisory Service durch den Oracle-Vertrieb oder einen qualifizierten Partner von Oracle License Management Service (LMS) durchgeführt wird.

Frage: Bezüglich einer bereits beantworteten Frage zu Data Guard gibt es noch eine Nachfrage: Verhält sich dieser Sachverhalt genauso, wenn man mit der Standard Edition oder Standard Edition One ein „Unmanged Standby“-System aufbaut (d.h. automatisiert die angefallenen Archivelogs von Server 1 nach Server 2 verschiebt und dort recovert)? In diesem Fall sind es ja zwei Server mit jeweils einer laufenden Datenbank. Wenn man also für den „produktiven“ Server eine CPU-Lizenz Standard Edition hat, ist dann auch eine CPU-Lizenz Standard Edition für die zweite Maschine erforderlich? Bei NUP-Lizenzierung müssten dann bei 10 NUP für den „produktiven“ Server auch 10 NUP für den „standby“ Server lizenziert werden?

Antwort: Bei Standby-Szenarien muss der sekundäre Server immer mit derselben Metrik lizenziert sein wie der primäre Server. Die Technik des Standby-Verfahrens (Data Guard oder unmanaged oder per Drittprodukt) spielt dabei keine Rolle

Frage: Welche Besonderheiten sind beim Einsatz einer Oracle-Datenbank in einer virtuellen Umgebung zu beachten, wenn man nach NUPs lizenzieren möchte?

Antwort: Die Oracle-Lizenzierung in einer virtualisierten Umgebung hängt zunächst einmal von der verwendeten Virtualisierungslösung ab. Gängige x86-Virtualisierungslösungen wie VMWare, Xen oder HyperV werden von Oracle ausschließlich als Softpartitionierung anerkannt. Das bedeutet, dass bei Verwendung einer solchen Virtualisierungslösung alle Prozessoren eines Servers und auch eines Serververbunds zu lizenzieren sind.

Demgegenüber sind bei Hardpartitionierung nur zugewiesene Prozessoren zu lizenzieren. Hier bietet Oracle mit der Oracle VM eine Virtualisierungslösung, die je nach Installationsvariante sowohl als Hard- als auch als Softpartitionierung anerkannt wird.

Bei VMWare/Xen/HyperV müssen also alle Prozessoren lizenziert werden. Ob das nun Auswirkungen für die angefragte NUP-Lizenzierung hat, hängt wiederum von den zu lizenzierenden Produkten ab. Bei Produkten, die eine Minimumbedingung pro Prozessor haben (z.B. DB EE mit 25 NUP pro Prozessor, IAS- und WLS Editionen mit 10 NUP pro Prozessor) müssen also alle lizenzpflichtigen Prozessoren/Cores gezählt, summiert und gegebenenfalls mit dem Prozessorfaktor multipliziert werden, was die zu lizenzierende Anzahl an Prozessoren ergibt. Bei den Produkten mit Minimumbedingung ist nun diese Zahl mit dem Minimumfaktor zu multiplizieren. 

Frage: Ein Unternehmen hat letztes Jahr eine größere Firma in den USA gekauft. Dort existieren auch Oracle Datenbanken mit entsprechenden Wartungsverträgen, die demnächst verlängert werden sollen. Da das Unternehmen von einem im letzten Jahr ausgelaufenen ULA noch genügend Datenbank-Lizenzen übrig hat, überlegt man, die Lizenzen der neu erworbenen Firma stillzulegen, das heißt, die Wartungsverträge zu kündigen und die Datenbanken unter dem eingenen Lizenzset laufen zu lassen. Wie verhält es sich mit den stillgelegten Lizenzen? Kann man die irgendwann wieder "reaktivieren" oder sind diese endgültig weg. Muss man bei einer Reaktivierung die Wartungsgebühren aus der "passiven Zeit" nachzahlen?

Antwort: Das ist insgesamt ein spannendes und schwieriges Thema. Die Fragen können wir hier auch nur allgemein beantworten, denn es gelten die zwischen dem Unternehmen beziehungsweise der übernommenen amerikanischen Firma und Oracle geschlossenen Verträge. Dazu kommen unterschiedliche Urheberrechtsgegebenheiten in den USA und hier. Grundsätzlich erwirbt man mit dem Kauf einer perpetual Lizenz ein zeitlich nicht eingeschränktes Nutzungsrecht für diese Software (perpetual = immerwährend). Somit ist die Lizenz – für die zum Zeitpunkt des Wartungsendes verwendete Version – auch nach Auslaufen der Wartung gültig. Sollte nach einer solchen Stilllegung die Wartung wieder reaktiviert werden, so ist der Support für den Zeitraum der Stillegung nachzuzahlen sowie eine zusätzliche "Re-Instatement-Gebühr" von 50 Prozent der Support-Kosten.

Aber: Im OLSA gibt es seit etlichen Jahren einen Passus, der fordert, dass alle Lizenzen eines Lizenz-Sets (ein Lizenz-Set kann gleichartige Produkte oder auch alle Produkte aus einem Kauf bzw. einer CSI-Nummer enthalten) den gleichen Support-Level haben müssen. Hiermit soll der Trick verhindert werden, dass ein Kunde ein großes produktives System betreibt und dafür Patches und Problem-Support bekommt, aber nur ein kleines Entwicklungssystem unter Support hat. Deshalb verlangt Oracle eine Löschungsbestätigung für solche Systeme, für die der Support nicht verlängert wird, wenn noch andere Produkte des License Set unter Support stehen. Und dies wird seit einigen Jahren auch sehr deutlich von Oracle verfolgt, indem Kunden, die die Löschungsbestätigung nicht an Oracle senden, keine Support-Verlängerung der anderen im License Set befindlichen Produkte angeboten bekommen. Dadurch ist es für Kunden auch nicht mehr möglich, stabile Altsysteme, die schon lange keine Support mehr benötigen, für die gegebenenfalls auch kein Error-Correction-Support mehr erhältlich ist, und die nur noch eine begrenzte Lebenserwartung haben, aus dem Support zu nehmen und die Support-Kosten dafür einzusparen. Die DOAG hat über zwei Jahre mit Oracle über dieses Thema diskutiert und diese Vorgehensweise als Kompromiss erreichen können. Hier lauert also ein nicht unbeträchtliches Risiko, das ohne die komplette Lizenz- und Vertrags-Situation zu kennen, von uns nicht beurteilt werden kann.

Darüber hinaus gibt es gelegentlich die vertraglichen Einschränkungen, dass Lizenzen nur in bestimmten Ländern eingesetzt werden dürfen. Auch ist die vertragliche Situation zu prüfen, ob ein Einsatz der Lizenzen in USA möglich ist.

Frage: Eine Datenbank läuft in einem Unternehmen seit Jahren CPU-lizenziert. Über einen langen Zeitraum wurde hierfür ein Anwendungsprogramm entwickelt, das nun auch externen Kunden zur Verfügung steht. Jeder Benutzer verbindet sich über das Programm (mittels OCI) direkt mit der Datenbank. Es handelt sich also nicht um eine webbasierte Anwendung. Gelten solche Connects nur innerhalb einer Firma oder auch über das Firmengelände hinaus?

Antwort: Eine mittels der Prozessor-Metrik lizenzierte Datenbank darf von beliebig vielen Anwendern benutzt werden. Hierbei dürfen diese auch von extern zugreifen. Eine Prozessor-Lizenz ist zwingend notwendig, wenn beispielsweise eine frei zugängliche Web-Anwendung auf die Oracle-Datenbank zugreift.

Frage: Ein Unternehmen plant eine zentrale Datenbank auf einer separaten Hardware für die Entwickler. Jeder Entwickler hat dort seine persönlichen Entwicklungsschemas. In verschiedenen Dokumenten ist nicht herauszufinden, ob das gegen die kostenfreie OTN-Lizenz verstößt. Insbesondere wegen folgendem Satz „It also limits the use of the downloaded product to one person“ in diesem Dokument.

Antwort: Es müssen für alle Entwickler Lizenzen erworben werden, da die Nutzung der OTN-Lizenzen über die Einschränkung des OTN-Agreements hinausgeht. OTN sagt aus, dass eine Lizenz zum Beispiel nur von einer Person auf einem Rechner benutzt werden darf. „The programs may be installed on one computer only, and used by one person in the operating environment identified by us. You may make one copy of the programs for backup purposes“.

--

Frage: In der OTN-Lizenz findet sich folgender Satz: „continue to develop your application after you have used it for any internal data processing, commercial or production purpose without securing an appropriate license from us, or an Oracle reseller”. Bedeutet das, wenn man die Development-Datenbank als Produktions-Datenbank verwendet und auf dieser weiterentwickelt, diese natürlich zu lizenzieren ist? Im Falle, dass die Development-Datenbank eine reine Development-Datenbank bleibt und man auf eine eigene Produktions-Datenbank deployed, bleibt dann die Development-Datenbank unter OTN kostenfrei und man muss nur die Produktions-Datenbank lizenzieren?

Antwort: Sobald die Anwendung über den Status des Prototypen hinausgeht beziehungsweise hinausgegangen ist, müssen für die Entwickler entsprechende Lizenzen erworben werden. Es spielt dabei keine Rolle, ob die Development-Datenbank auf einem separaten Server als reine Entwicklungsumgebung oder zusammen mit der Produktionsumgebung läuft. Zitat aus den Lizenzbestimmungen: „You may not continue to develop your application after you have used it for any internal data processing, commercial or production purpose without securing an appropriate license from us, or an Oracle reseller.”

--

Frage: Das Unternehmen betreibt einen zentralen Build-Server, der auch automatische Unit-Tests durchführt. Einige dieser Tests betreffen Komponenten mit Datenbank-Funktionalität. Ist diese Datenbank als Development-Datenbank zu sehen und über OTN kostenfrei oder ist dies bereits eine Test-Datenbank und somit voll zu lizenzieren?

Antwort: Hier handelt es sich um eine voll zu lizenzierende Testumgebung, da der Status des „Prototyping“ schon überschritten wurde.

Ihr Ansprechpartner

Michael Paege Stellv. Vorstandsvorsitzender, Vorstand Querschnittsgruppen (Competence Center & Regio), Leiter Competence Center Lizenzierung Zum Profil