I imagine what I want to write in my case, I write it in the search engine and I get exactly what I wanted. Thank you!
Valentina R., lawyer
DE
Dieser Text wird nur zu Informationszwecken zur Verfügung gestellt. Eine Zusammenfassung dieses Beschlusses wird im Amtsblatt der Europäischen Union in allen Amtssprachen veröffentlicht.
Nur der englische Text ist verbindlich.
Artikel 8 Absatz 1 Datum: 21.1.2010
EUROPÄISCHE KOMMISSION
Brüssel, den 21.1.2010
K(2010) 142 endgültig
Vom 21/1/2010 zur Feststellung der Vereinbarkeit eines Zusammenschlusses mit dem Gemeinsamen Markt und dem EWR-Abkommen (Sache COMP/M.5529 – Oracle/ Sun Microsystems)
II. DAS ZUSAMMENSCHLUSSVORHABEN
III. DER ZUSAMMENSCHLUSS
IV. GEMEINSCHAFTSWEITE BEDEUTUNG
V. VERFAHREN UND UNTERSUCHUNG
3
4
1.1. Server
1.2. Speicherlösungen
1.3. Betriebssysteme
1.4. EAS
5
vom 21.1.2010
zur Feststellung der Vereinbarkeit eines Zusammenschlusses mit dem Gemeinsamen Markt und dem EWR-Abkommen
(Sache COMP/M.5529 – Oracle/ Sun Microsystems)
(Nur der englische Text ist verbindlich)
(Text von Bedeutung für den EWR)
DIE EUROPÄISCHE KOMMISSION –
gestützt auf den Vertrag über die Arbeitsweise der Europäischen Union,
gestützt auf das Abkommen über den Europäischen Wirtschaftsraum, insbesondere auf Artikel 57,
gestützt auf die Verordnung (EG) Nr. 139/2004 des Rates vom 20. Januar 2004 über die Kontrolle von Unternehmenszusammenschlüssen, insbesondere auf Artikel 8 Absatz 1,
gestützt auf den Beschluss der Kommission vom 3. September 2009, in dieser Sache ein Verfahren einzuleiten,
nachdem den betroffenen Unternehmen Gelegenheit gegeben wurde, sich zu den Beschwerdepunkten der Kommission zu äußern,
nach Stellungnahme des Beratenden Ausschusses zur Kontrolle von Unternehmenszusammenschlüssen,
gestützt auf den Abschlussbericht des Anhörungsbeauftragten in dieser Sache,
IN ERWÄGUNG NACHSTEHENDER GRÜNDE:
ABl. L 24 vom 29.1.2004, S. 1.
ABl. C ... vom ....2010, S.
ABl. C ... vom ....2010, S.
Commission européenne, B-1049 Bruxelles/Europese Commissie, B-1049 Brüssel – BELGIQUE/BELGIË. Telefon: +32 229-91111
6
1. Am 30. Juli 2009 ging die Anmeldung eines Zusammenschlusses nach Artikel 4 der Verordnung (EG) Nr. 139/2004 (nachstehend „EG-Fusionskontrollverordnung“ genannt) bei der Kommission ein, wonach Oracle Corporation („Oracle“ bzw. die „Anmelderin“, USA) im Sinne von Artikel 3 Absatz 1 Buchstabe b der Fusionskontrollverordnung durch Erwerb von Anteilen die alleinige Kontrolle über Sun Microsystems, Inc. („Sun“, USA) erwirbt.
2. Oracle ist eine US-Aktiengesellschaft, deren Stammaktien an der Technologiebörse NASDAQ gehandelt werden. Das Unternehmen entwickelt und vertreibt Software-Lösungen für Unternehmen und damit verbundene Dienstleistungen, u. a. Middleware, Datenbanksoftware und Unternehmenssoftware.
3. Sun ist eine US-Aktiengesellschaft, die Hardware (Server, Desktops, Mikroelektronik und Speichergeräte) und Software anbietet, unter anderem Betriebssysteme, Java-Technik, Middleware, Datenbanksoftware und damit verbundene Dienstleistungen.
4. Oracle beabsichtigt, 100 % der im Umlauf befindlichen stimmberechtigten Anteile von Sun im Gesamtwert von etwa 7,4 Mrd. USD zu erwerben. Zu diesem Zweck hat Oracle einen Vertrag mit seiner 100 %igen Tochtergesellschaft Soda Acquisition Corporation und mit Sun geschlossen, dem zufolge Soda Acquisition Corporation mit Sun fusioniert, wobei Soda Acquisition Corporation als eigenständiges Unternehmen erlischt, während Sun als Unternehmen fortbesteht und eine 100 %ige Tochtergesellschaft von Oracle wird.
5. Oracle wird infolge des Zusammenschlusses die 100 %ige Kontrolle über Sun erwerben. Der Zusammenschluss fällt somit unter Artikel 3 Absatz 1 Buchstabe b der EG-Fusionskontrollverordnung.
6. Es handelt sich um einen Zusammenschluss von gemeinschaftsweiter Bedeutung im Sinne von Artikel 1 Absatz 2 der EG-Fusionskontrollverordnung. Die beteiligten Unternehmen erzielen zusammen einen weltweiten Gesamtumsatz von mehr als 5 Mrd. EUR (Oracle 16,981 Mrd. EUR; Sun 9,582 Mrd. EUR) und einen gemeinschaftsweiten Umsatz von mehr als 250 Mio. EUR (Oracle 4,331 Mrd. EUR, Sun 2,992 Mrd. EUR). Die beteiligten Unternehmen erzielen nicht mehr als zwei Drittel ihres gemeinschaftsweiten Umsatzes in einem einzigen Mitgliedstaat.
7
7. Am 20. April 2009 gab Oracle bekannt, mit Sun einen Vertrag über die Übernahme von Sun durch Oracle geschlossen zu haben. Am 24. April 2009 legte Oracle in einer ersten Sitzung mit der Kommission die Begründung für das Geschäft dar. Am 14. Mai 2009 fand eine zweite Sitzung statt. Am 25. Juni 2009 reichte Oracle einen ersten Entwurf des Formblatts CO ein, zu dem die Kommission am 3. Juli 2009 Fragen und Kommentare vorlegte. Am 24. Juli 2009 reichte Oracle den zweiten Entwurf des Formblatts CO ein, zu dem die Kommission am 28. und 29. Juli 2009 Fragen und Kommentare vorlegte.
8. Während der Phase vor der Anmeldung sandte die Kommission Oracle am 19. Mai, 3. Juli und 29. Juli 2009 Fragen zu, u. a. bezüglich des Marktes für Datenbankprodukte (auch als „Datenbanken“ bezeichnet).
9. Der Zusammenschluss wurde am 30. Juli 2009 angemeldet. Die Kommission sandte am 31. Juli 2009 Auskunftsersuchen an die Wettbewerber und Kunden auf dem Datenbankmarkt. Am 13. August 2009 wurde ein weiteres Auskunftsersuchen an Datenbankkunden gesandt. Darüber hinaus sandte die Kommission verschiedene Auskunftsersuchen an die Anmelderin und an Sun.
10. In einer Sitzung am 20. August 2009 wurde Oracle darüber in Kenntnis gesetzt, dass die Kommissionsdienststellen im Hinblick auf den Datenbankmarkt sowie die stärkere Position von Oracle im IT-Stack ernsthafte Zweifel an der Vereinbarkeit des Zusammenschlussvorhabens mit dem Gemeinsamen Markt und dem EWR-Abkommen hegten.
11. Am 3. September 2009 erließ die Kommission eine Entscheidung, in der sie befand, dass der Zusammenschluss Anlass zu ernsthaften Bedenken hinsichtlich seiner Vereinbarkeit mit dem Gemeinsamen Markt und dem EWR-Abkommen gibt, da der Wettbewerb auf dem Markt für Datenbanken eingeschränkt und die Position des fusionierten Unternehmens im IT-Stack gestärkt werden könnte. Aus diesem Grund beschloss die Kommission, ein Verfahren nach Artikel 6 Absatz 1 Buchstabe c der EG-Fusionskontrollverordnung einzuleiten.
12. Am 26. September 2009 legte Oracle seine vorläufigen schriftlichen Kommentare zu der Entscheidung der Kommission vor, ein Verfahren nach Artikel 6 Absatz 1 Buchstabe c der EG-Fusionskontrollverordnung einzuleiten („Entscheidung nach Artikel 6 Absatz 1 Buchstabe c“). Darin legte das Unternehmen auch dar, der geplante
4 Auskunftsersuchen an Wettbewerber auf dem Datenbankmarkt vom 31. Juli 2009 sowie Auskunftsersuchen an Datenbankkunden vom 31. Juli 2009.
5 Auskunftsersuchen an Datenbankkunden vom 13. August 2009.
6 Der so genannte „IT-Stack“ oder „T Technology Stack” setzt sich aus unterschiedlichen Hardware- und Softwarekomponenten zusammen, die von Unternehmen zur letztendlichen Nutzung von Unternehmenssoftware benötigt werden.
7 Doc_ID 1959.
8
Zusammenschluss werde keine wettbewerbswidrigen Auswirkungen auf den Datenbankmarkt haben. Am 2. Oktober 2009 legte Oracle Feststellungen zur Schadenstheorie der Kommission („Observations on the Commission's Theory of Harm“) vor, worin ausführlicher auf die von der Kommission in ihrer Entscheidung nach Artikel 6 Absatz 1 Buchstabe c aufgeworfenen Fragen eingegangen wurde.
13. Während ihrer eingehenden Untersuchung übermittelte die Kommission mehrere Auskunftsersuchen an Oracle. Das am 13. September 2009 übermittelte erste Auskunftsersuchen bezog sich auf eine Reihe von in der Entscheidung nach Artikel 6 Absatz 1 Buchstabe c aufgeworfenen zentralen Fragen. Nachfolgende Auskunftsersuchen bezogen sich auf Fragen wie die zugrunde liegenden Daten für die Oracle-Datenerfassungssysteme CRM und HQ Apps, interne Dokumente zu der von Oracle durchgeführten Analyse des Wettbewerbs auf dem Datenbankmarkt und insbesondere des durch MySQL ausgeübten Wettbewerbsdrucks und zu der von Oracle verfolgten Strategie für Datenbankensowie die geschäftliche Rechtfertigung für frühere Versuche, MySQL zu erwerben.
14. Am 17. September 2009 sandte die Kommission ein Auskunftsersuchen an Datenbankkunden. Am 18. September 2009 sandte die Kommission ein Auskunftsersuchen an Wettbewerber auf dem Datenbankmarkt, an Datenbankintegratoren sowie an Anbieter von Speicher-Engines. Am 2. Oktober 2009 sandte die Kommission ein weiteres Auskunftsersuchen an Wettbewerber auf dem Datenbankmarkt bezüglich der Positionierung von MySQL durch Oracle. Ferner führte die Kommission mehrere Telefonkonferenzen mit Dritten durch, um in deren schriftlichen Erwiderungen auf die Auskunftsersuchen der Kommission nach Artikel 11 der Fusionskontrollverordnung aufgeworfene Fragen eingehender zu erörtern.
15. Am 28. September 2009 gab die Kommission bei der Firma TAEUS ein Gutachten in Auftrag, das einen Vergleich der technischen Merkmale und der Gesamtbetriebskosten (Total Cost of Ownership, TCO) der von Oracle und Sun und deren Wettbewerbern angebotenen Datenbanken sowie eine Untersuchung der Frage umfassen sollte, ob Oracle technisch in der Lage wäre, Nutzer, die gegenwärtig MySQL verwenden, an
Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009 (doc_ID 2427).
Auskunftsersuchen an Oracle vom 11. September 2009 (doc_ID 2310).
Oracle am 23. September 2009 per E-Mail von einem Mitglied des Sachbearbeiterteams zugesandte Fragen, Auskunftsersuchen vom 8. Oktober 2009 (doc_ID 3327), 12. Oktober 2009 (doc_ID 2984), 14. Oktober 2009 (doc_ID 3058), 13. November 2009 (doc_ID 3858) und 9. Dezember 2009 (doc_ID 5082).
Auskunftsersuchen an Oracle vom 9. September 2009 (doc_ID 1296) und 25. September 2009 (doc_ID 2591), E-Mail vom 2. Oktober 2009 (doc_ID 2265), Auskunftsersuchen vom 8. Oktober 2009 (doc_ID 3327) und 9. Oktober 2009 (doc_ID 3061).
Siehe insbesondere das Auskunftsersuchen an Oracle vom 9. September 2009 (doc_ID 1296).
Auskunftsersuchen an Datenbankkunden vom 17. September 2009.
Auskunftsersuchen an Wettbewerber auf dem Datenbankmarkt vom 18. September 2009.
Auskunftsersuchen an Datenbankintegratoren vom 18. September 2009.
Auskunftsersuchen an Anbieter von Speicher-Engines vom 18. September 2009.
Auskunftsersuchen an Wettbewerber auf dem Datenbankmarkt bezüglich der Positionierung von MySQL durch Oracle vom 2. Oktober 2009.
9
einer Migration zu Datenbanken anderer Hersteller zu hindern. Der Bericht von TAEUS wurde am 11. Oktober 2009 vorgelegt.
Am 21. Oktober 2009 wurde Oracle darüber in Kenntnis gesetzt, dass die Kommission den Erlass einer Mitteilung der Beschwerdepunkte in Erwägung zog, da sie vorläufig zu dem Schluss gelangt war, dass der Zusammenschluss den Wettbewerb auf dem Markt für Datenbanken erheblich beeinträchtigen würde.
Am 29. Oktober 2009 legte Oracle weitere Informationen zur Entkräftung der von der Kommission in ihrer Entscheidung nach Artikel 6 Absatz 1 Buchstabe c geäußerten Bedenken vor, darunter ein Geschäftsplan, den Oracle nach der Anmeldung des Zusammenschlussvorhabens aufgestellt hatte. Die zu diesem Zeitpunkt vorgelegten Informationen änderten nichts an der vorläufigen Beurteilung durch die Kommission, dass der geplante Zusammenschluss den Wettbewerb auf dem Markt für Datenbanken erheblich beeinträchtigen würde.
Am 9. November 2009 übermittelte die Kommission eine Mitteilung der Beschwerdepunkte nach Artikel 18 der EG-Fusionskontrollverordnung an Oracle.
Danach stellten neun Drittunternehmen einen Antrag auf Anhörung und legten ein hinreichendes Interesse dar, um im Sinne von Artikel 18 Absatz 4 der EG-Fusionskontrollverordnung als Dritte angehört zu werden. Sie wurden gebeten, Kommentare zu einer nicht vertraulichen Version der Mitteilung der Beschwerdepunkte abzugeben. Vier von ihnen legten schriftliche Kommentare zur Mitteilung der Beschwerdepunkte vor.
Am 30. November 2009 und am 8. Dezember 2009 sandte die Kommission jeweils ein Sachverhaltsschreiben an Oracle, in denen sie Einzelheiten zu zusätzlichen Beweismitteln darlegte, die seit der Annahme der Mitteilung der Beschwerdepunkte zusammengetragen worden waren. Nach Meinung der Kommission untermauerten diese zusätzlichen Beweismittel die vorläufigen Schlüsse, zu denen sie in der Mitteilung der Beschwerdepunkte gelangt war. Oracle wurde Gelegenheit gegeben, die beiden Schreiben zu beantworten, sollte das Unternehmen dies wünschen. Oracle beantwortete das erste Sachverhaltsschreiben am 8. Dezember 2009.
Eine Erwiderung auf die Mitteilung der Beschwerdepunkte übermittelte Oracle am 3. Dezember 2009.
Auf Antrag der Anmelderin fand am 10. und 11. Dezember 2009 eine Anhörung statt. Sechs Drittunternehmen beantragten ebenfalls die Teilnahme an der Anhörung.
Siehe Aufgabenbeschreibung für TAEUS-Bericht (doc_ID 1906).
TAEUS-Bericht (doc_ID 3011).
Im ersten Sachverhaltsschreiben wurde auf eine Reihe von Fragen einschließlich der folgenden eingegangen: die Zahl der Downloads bestimmter Datenbankprodukte der beteiligten Unternehmen und ihrer Wettbewerber; die Technologie und Funktionalität von MySQL; die von der Kommission durchgeführte Auswertung der von den beteiligten Unternehmen vorgelegten internen Datenbestände sowie die finanziellen Interessen von Oracle nach dem geplanten Zusammenschluss (doc_ID 4656). Das zweite Sachverhaltsschreiben betraf die Ergebnisse einer Umfrage bei Entwicklern, die von einem unabhängigen Markforschungsunternehmen durchgeführt worden war (doc_ID 5060).
10
VI. WETTBEWERBSRECHTLICHE WÜRDIGUNG
A. Einleitung
23. Oracle ist in der Entwicklung, Herstellung und im Vertrieb von Unternehmenssoftware tätig, dazu gehören Middleware, Datenbanksoftware und Unternehmenssoftwaresysteme (Enterprise Applications Systems – EAS) sowie damit verbundene Dienstleistungen. Sun ist in den Bereichen Hardware, u. a. Server und Speicherung, sowie Unternehmenssoftware tätig. Das Unternehmen bietet im Bereich Unternehmenssoftware Betriebssysteme (das eigene Betriebssystem von Sun ist Solaris), Datenbanksoftware und Middleware an.
24. Die Produktangebote von Oracle und Sun sind Teil des so genannten „IT-Stack“ oder „Technology Stack“, also des technologischen Produktpakets, das sich aus den unterschiedlichen Hardware- und Softwarekomponenten zusammensetzt, die für Unternehmen zur letztendlichen Nutzung von Unternehmenssoftware benötigt werden. Hardwareprodukte wie Server, Speichereinheiten und Client-PCs stellen die erste Schicht des Systems dar. Um zu funktionieren, benötigen Server ein Betriebssystem (wie Unix, das quelloffene Linux, Solaris von Sun oder Windows von Microsoft). Datenbanken laufen unter diesen Systemen und ermöglichen die Speicherung und Sortierung von Daten. Die nächste Schicht in dem Stapel ist Middleware. Damit wird eine große Kategorie von Softwareprodukten bezeichnet, welche die Infrastruktur bilden, mit der Anwendungen auf einem Server laufen können, die von einer Reihe von Clients über ein Netzwerk zugänglich sind und in der Lage sind, eine Vielfalt von Informationsquellen zu verbinden. Middleware wird zusammen mit Betriebssystemen und Datenbanken auch als „Infrastruktursoftware“ bezeichnet. Die letzte Schicht des Stapels bildet EAS-Software, welche von Unternehmen für wichtige Geschäftsvorgänge eingesetzt wird, die zur wirksamen Geschäftsführung nötig sind (z. B. Kundenbeziehungsmanagement (Customer Relationship Management, „CRM“),
Planung der Unternehmensressourcen (Enterprise Resource Planning, „ERP“), Lieferkettenmanagement (Supply Chain Management, „SCM“) usw.).
25. Das Zusammenschlussvorhaben führt bei den Produktangeboten von Oracle und Sun zu Überschneidungen im Bereich der Datenbanksysteme und von Middleware. Das Vorhaben könnte außerdem vertikale Effekte erzielen, die mit der Lizenzierung von Java als Inputmedium für Middleware und EAS verbunden sind. Nach der Theorie zu vertikalen und konglomeraten Effekten werden darüber hinaus alle Märkte im Bereich des Technology Stack potenziell betroffen.
26. Der vorliegende Beschluss gliedert sich im Folgenden in vier Abschnitte, welche die Auswirkungen des Vorhabens auf die unterschiedlichen Märkte betreffen, die von dem Zusammenschlussvorhaben potenziell berührt werden (Abschnitt B. Datenbanksysteme, Abschnitt C. Middleware, Abschnitt D. Java und Abschnitt E. IT-Stack).
1. Einführung
1.1. Beschreibung relationaler Datenbanken
Relationale und nicht relationale Datenbanken
27. Bei Datenbanken handelt es sich um Softwareprogramme zur Speicherung, Organisation, Analyse sowie zum Abrufen von in elektronischer Form vorliegenden Informationen, die anstelle herkömmlicher papierbasierter Ablagemethoden verwendet werden. Ein vollständiges Datenspeichersystem besteht aus Datenspeichermedien (z. B. Festplatten), auf denen die Daten physisch gespeichert werden, sowie einem System, mit dem die Organisation, Speicherung, Sicherheit und Integrität der Daten sowie der Zugriff auf diese verwaltet wird („Datenbank-Managementsystem“ oder „DBMS“).
28. Die gängigsten Systeme für die Organisation von Datenbanken sind gegenwärtig relationale Datenbank-Managementsysteme (häufig abgekürzt als „RDBMS“), bei denen die Daten nicht in einer einzigen großen Tabelle, sondern in separaten Tabellen gespeichert werden, zwischen denen dann Beziehungen definiert werden. Dadurch wird es möglich, Daten aus mehreren Tabellen für Abfragen und Berichte miteinander zu kombinieren. Die Technologie relationaler Datenbanken ermöglicht größere, schnellere und effizientere Datenbanken.
29. Daneben existieren andere, nicht relationale Datenbank-Managementsysteme („Nicht-RDBMS“), z. B. objektorientierte Datenbanken. Nicht-RDBMS bieten nicht dieselben Vorteile und sind auch nicht so weit verbreitet wie RDBMS. Sofern nichts anderes angegeben wird, bezieht sich der Begriff „Datenbanken“ im vorliegenden Beschluss auf RDBMS.
Technische Aspekte relationaler Datenbanken
Um mit einem RDBMS „kommunizieren“ zu können, müssen Datenbankadministratoren und/oder Anwendungen eine „Sprache“ verwenden. Die standardisierte Sprache zum Definieren und Bearbeiten (Lesen, Ändern, Löschen) von Daten in einem RDBMS heißt SQL (Structured Query Language). SQL-Befehle (oder Zeichenfolgen für Suchabfragen) werden entweder von Administratoren in ein Tool eingegeben, das die Abfrage an den Datenbankserver übermittelt und dann das Ergebnis in Textform zurückgibt, oder von Softwareanwendungen an das RDBMS übermittelt (auf diese Weise müssen sich Anwendungsentwickler nicht mit den Einzelheiten der Datenspeicherung befassen, sondern können diese allgemein implementieren, indem das RDBMS als Back-End-Speicher verwendet wird).
Obwohl SQL von verschiedenen führenden Normungsgremien und -institutionen (u. a. ANSI und ISO) als Standard verabschiedet worden ist, ist es praktisch unmöglich, auch nur eine Implementierung der offiziellen Definition von SQL zu finden. In fast jedem RDBMS-Produkt werden einige Teile von SQL nicht implementiert, dafür jedoch eigene spezielle Merkmale hinzugefügt, wodurch ein neuer „Dialekt“ geschaffen wird, statt streng einen allgemeinen Standard einzuhalten.
Eine relationale Datenbank setzt sich konzeptionell aus drei verschiedenen Schichten zusammen: der obersten Schicht mit den Tools für die Überwachung und Verwaltung der Datenbank (Unterstützung der Nutzer bei der Arbeit mit den Daten), einer mittleren Schicht, die aus einem zentralen Server besteht, sowie einer dritten Schicht (Speicher-Engine), die für die Verwaltung der Speicherung zuständig ist. In den meisten Fällen sind die drei Schichten in einer Einheit zusammengefasst.
Die meisten Datenbanken sind mit den wichtigsten Betriebssystemen wie Unix, Microsoft Windows, Linux oder Mainframe-Systemen kompatibel. Die einzige Ausnahme bildet die Datenbank von Microsoft, die ausschließlich mit dem proprietären Microsoft-Betriebssystem Windows kompatibel ist.
Datenbanken spielen eine wichtige Rolle bei den Abläufen in zahlreichen Unternehmen und Organisationen, angefangen bei Banken und Börsen bis hin zu Organisationen der öffentlichen Hand und Websites.
Datenbanken sind Teil des so genannten „Technology Stack“, also des technologischen Produktpakets, das sich aus den unterschiedlichen Hardware- und Softwarekomponenten zusammensetzt, die für Unternehmen zur letztendlichen Nutzung von Unternehmenssoftware benötigt werden (siehe Randnummer 24). Datenbanken unterstützen unterschiedlichste Anwendungen, wobei zu den wichtigsten die Onlinetransaktionsverarbeitung (Online Transaction Processing, „OLTP“) und die analytische Onlineverarbeitung (Online Analytical Processing, „OLAP“) sowie Data-Warehousing zählen.
Datenbanken mit Funktionalität für die Transaktionsverarbeitung bieten Nutzern die Gewissheit, dass i) eine eingeleitete Transaktion (Schreibvorgang in der Datenbank) entweder vollständig und korrekt oder gar nicht ausgeführt wird, ii) jede Transaktion von anderen Transaktionen (die ggf. von anderen Nutzern gleichzeitig eingeleitet werden könnten) isoliert wird, so dass die Datenintegrität gewahrt bleibt, und iii) erfolgreich ausgeführte Transaktionen in nichtflüchtigen Speicher geschrieben werden. Diese Eigenschaften von Datenbanktransaktionen werden mit dem Akronym „ACID“ bezeichnet (Atomicity, Consistency, Isolation, Durability¸ zu Deutsch: Atomarität, Konsistenz, Isolation, Dauerhaftigkeit). Dies ist bei allen Systemen wichtig, die Daten im Zusammenhang mit Geschäftsvorgängen verarbeiten (z. B. Börsen- und Banksysteme, E-Commerce, Verkauf von Flugtickets usw.).
Data Warehouses enthalten historische Daten (oftmals in riesigen Mengen), die normalerweise keine erheblichen Änderungen erfahren. Aus diesem Grund müssen für Data-Warehousing optimierte Datenbanken in der Lage sein, große Datenmengen sehr rasch zu lesen. Häufig werden sie für das so genannte „Data Mining“ benötigt, wobei Daten für Business Intelligence, Analyse und andere entscheidungsunterstützende Systeme genutzt werden. OLAP bezeichnet einen Teilbereich des Data-Warehousing, bei dem die Interaktion mit den Daten und die Analyse in Echtzeit stattfinden müssen, so z. B. bei Self-Service-Berichterstellung und -Analyse, wobei Nutzer Daten über eine geeignete Oberfläche abfragen können.
Datenbanken können auch in andere Hardware- oder Softwareprodukte „eingebettet“ werden, so dass sie nicht als eigenständige Produkte an die Endnutzer verkauft werden. Eingebettete Datenbanken werden zu dem Zweck erworben, sie in eine für den Wiederverkauf bestimmte Software oder ein für den Wiederverkauf bestimmtes Gerät einzubinden, was dazu führt, dass der Endnutzer sie nicht von der betreffenden Software bzw. dem betreffenden Gerät unterscheiden oder separat nutzen kann. RDBMS-Anbieter stellen spezielle Versionen ihrer allgemeinen RDBMS-Produkte bereit, die geeignet sind, von unabhängigen Softwareanbietern (Independent Software Vendors, „ISVs“) in deren Anwendungssoftware eingebettet zu werden. RDBMS können auch zum Verkauf in bestimmte Softwareprogramme oder Geräte wie Mobiltelefone, Unterhaltungselektronik, Telekommunikationsgeräte, Industrieanlagen und Fahrzeuge eingebettet werden. Wenn eingebettete Datenbanken vollständig in das fertige Produkt integriert sind, sind sie für den Endnutzer nicht wahrnehmbar.
Datenbankhersteller vertreiben ihre DBMS-Produkte i. d. R. sowohl über direkte als auch über indirekte Vertriebskanäle. Der direkte Vertriebskanal besteht üblicherweise aus den im Außendienst tätigen Vertriebsmitarbeitern des Herstellers sowie zentralen Telefonverkaufsteams, die die Produkte per Telefon und/oder über das Internet verkaufen. Im indirekten Vertriebskanal beauftragen Datenbankhersteller verschiedene Drittunternehmen, um den Vertrieb für unterschiedliche Marktsegmente, Branchen, geografische Gebiete und potenzielle Kunden effizienter und effektiver zu gestalten. Zu den auf diese Weise tätigen Drittunternehmen können Wiederverkäufer, ISVs, Systemintegratoren („SIs“) sowie Anbieter von Hardware- und Infrastrukturprodukten gehören.
Die Marktuntersuchung der zweiten Phase hat gezeigt, dass eine gewisse Unstimmigkeit bezüglich der genauen Bedeutung des Begriffs „eingebettet“ im Zusammenhang mit Datenbanken herrscht. Zwar stimmten zahlreiche der Befragten der von der Kommission vorgeschlagenen Definition zu, jedoch wurde von bestimmten Befragten auch eine alternative Definition vorgeschlagen, bei der die Frage eine Rolle spielt, ob die Datenbank im technischen Sinne tatsächlich in eine Anwendung eingebettet ist oder einfach parallel zu dieser ausgeführt wird. Dies wird anhand des folgenden Zitats aus der Erwiderung von Monty Program Ab (doc_ID 1891) deutlich: „Der Begriff ‚eingebettete Datenbank‘ ist nicht gut definiert. So ist z. B. das Produkt ‚MySQL Embedded‘ eigentlich mit dem Datenbankprodukt ‚MySQL Enterprise‘ identisch, mit der einzigen Ausnahme, dass es zum Einbetten in eine bestimmte Anwendung als Datenspeicher für diese Anwendung lizenziert wird. Üblicherweise ist die Datenbank, technisch gesehen, nicht in die Anwendung eingebettet, sondern wird vielmehr als separater Prozess auf demselben Computer ausgeführt. Sie wird jedoch häufig automatisch über eine einzige Installationsdatei zusammen mit der Anwendung installiert. Die Datenbank könnte sogar auf einem anderen Computer ausgeführt werden. Daneben gibt es Datenbanken, die tatsächlich im technischen Sinne in eine Anwendung eingebettet sind. In diesem Fall können die Daten in der Datenbank ausschließlich von der betreffenden Anwendung genutzt werden und es können keine weiteren Verbindungen mit der Datenbank hergestellt werden, wie dies bei einem separat laufenden Datenbankserverprozess möglich ist.“
Proprietäre RDBMS werden i. d. R. „unbefristet“ lizenziert, und zwar entweder nach der Anzahl benannter Nutzer oder nach der Verarbeitungskapazität des Servers (z. B. bei einer extern zugänglichen Anwendung, bei der keine benannten Nutzer gezählt werden können). Eine Datenbanklizenz ist ohne zeitliche Einschränkung gültig. Eine relativ neue Praxis besteht darin, Kunden optional eine Unternehmenslizenzvereinbarung (Enterprise License Agreement, ELA) anzubieten, mit der die Kunden das Recht erwerben, gegen eine bestimmte Gebühr eine unbegrenzte Anzahl von Lizenzen zu nutzen. Die Gebühren werden üblicherweise auf Basis der voraussichtlichen Nutzung für zwei oder drei Jahre ausgehandelt.
Kundensupport (z. B. Bugfixes und Upgrades) ist wichtig. Dieser wird grundsätzlich von den Softwareanbietern (in eingeschränktem Umfang auch von deren Vertriebspartnern) und unabhängigen Diensteanbietern geleistet. ISVs und andere Drittunternehmen, die auf Basis einer von einem DBMS-Anbieter (wie Oracle) hergestellten Datenbank eigene Produkte erstellen und verkaufen, sind häufig der erste Ansprechpartner bei Kundenproblemen. Sie ermitteln dann, ob das Problem des Kunden durch das eigene Produkt oder durch das DBMS verursacht wurde. Nur im zweiten Fall wird der Kunde direkt an den Hersteller des DBMS verwiesen.
13
In vielen Unternehmen und Organisationen ist ein Datenbankadministrator („DBA“) für den Entwurf, die Implementierung sowie die Wartung und Pflege des DBMS zuständig. DBMS-Anbieter, u. a. Oracle, bieten Schulungs- und Zertifizierungsprogramme für DBAs an. Der DBA, der normalerweise einem IT-Beauftragten (Chief Information Officer, „CIO“) oder technischen Direktor (Chief Technology Officer, „CTO“) in dem Unternehmen oder der Organisation unterstellt ist, arbeitet möglicherweise zusammen mit Kollegen (die als „Entwickler“ tätig sind) an der Entwicklung eines DBMS gemäß den besonderen Anforderungen des Unternehmens bzw. der Organisation oder der entsprechenden Optimierung eines vorhandenen DBMS. Das in einem Unternehmen oder einer Organisation vorhandene Fachwissen im Zusammenhang mit Datenbanken hat einen direkten Einfluss darauf, wie viel Unterstützung durch den DBMS-Anbieter oder andere Dritte benötigt wird.
1.2.Beschreibung der beteiligten Unternehmen und der wichtigsten Wettbewerber
1.2.1.Oracle und seine Datenbankprodukte
Oracle wurde 2005 als Kapitalgesellschaft nach dem Recht des US-Bundesstaats Delaware gegründet und ist Rechtsnachfolger eines ursprünglich im Juni 1977 gegründeten Unternehmens. Das Unternehmen beschreibt sich selbst als „das größte Enterprise-Software-Unternehmen der Welt“ und entwickelt, produziert, vermarktet, vertreibt und bietet Dienstleistungen für Datenbanksoftware und Middleware sowie Anwendungssoftware, die darauf ausgelegt ist, die Kunden des Unternehmens bei der Verwaltung und Ausweitung ihrer Geschäftstätigkeit zu unterstützen.
Oracle ist in die zwei Geschäftsbereiche Software und Services gegliedert, die im Geschäftsjahr 2009 mit 18,877 Mrd. USD und 4,375 Mrd. USD 81 % bzw. 19 % des Gesamtumsatzes des Unternehmens erwirtschafteten. Der Bereich Software ist in zwei Geschäftssegmente unterteilt: i) neue Softwarelizenzen und ii) Updates von Softwarelizenzen und Produktsupport.
Im Bereich Software beliefen sich die Einnahmen aus neuen Softwarelizenzen im Geschäftsjahr 2009 auf 7,123 Mrd. USD bzw. 31 % des Gesamtumsatzes des Unternehmens. Mehr als zwei Drittel dieses Betrags entfielen auf neue Lizenzen für Datenbank- und Middlewareprodukte. Die Einnahmen aus Updates von Softwarelizenzen und Produktsupport beliefen sich im Geschäftsjahr 2009 auf 11,754 Mrd. USD bzw. 50 % des Gesamtumsatzes. Eine detailliertere Analyse des in demselben Zeitraum mit Datenbanken erzielten Umsatzes ergibt einen Gesamtumsatz von […] im Datenbankbereich, der sich aus Umsätzen in Höhe von […] aus neuen Lizenzen und Umsätzen in Höhe von […] aus dem Produktsupport zusammensetzt.
Oracle bietet eine Reihe von DBMS-Produkten an, wobei das RDBMS Oracle Database die wichtigste Rolle spielt. Oracle Database wird in vier Editionen angeboten: Enterprise Edition, Standard Edition, Standard Edition One und Express Edition. Wie von Oracle bestätigt, bauen alle Editionen auf demselben grundlegenden Code auf. Dies bedeutet, dass die Datenbanksoftware des Unternehmens problemlos für den Einsatz auf unterschiedlichsten Systemen, angefangen bei kleinen Servern mit nur einem Prozessor bis hin zu Clustern von Mehrprozessorservern, skaliert werden kann. Es gibt jedoch Unterschiede im Funktionsumfang der einzelnen Editionen, die sich im Preis niederschlagen und von denen es abhängt, in welchen Situationen welche Edition eingesetzt werden kann.
Oracle Database Enterprise Edition ist bei Weitem das umsatzstärkste Datenbankprodukt von Oracle, mit dem eine relationale Datenbank auf unterschiedlichsten Servern in einem Cluster oder eigenständigen Servern unterstützt wird und dessen Verwendungsmöglichkeiten unbegrenzt sind. Die aktuelle Version des Produkts wird unter dem Namen Oracle Database 11g Release 2 Enterprise Edition angeboten. Zusammen mit der Enterprise Edition werden verschiedene optionale Komponenten angeboten, mit denen spezifische Kundenanforderungen in den Bereichen Leistung und Skalierbarkeit, Hochverfügbarkeit, Datensicherheit und Richtlinientreue, Data-Warehousing, Informationsverwaltung und Systemsteuerung abgedeckt werden.
Oracle Database Standard Edition ist in beschränkterem Rahmen als die Enterprise Edition einsetzbar, nämlich nur auf mehreren Servern mit bis zu vier Sockeln.
Oracle Database Standard Edition One ist als Einstiegsprodukt für Kunden konzipiert, die ein mit umfassenden Funktionen ausgestattetes, jedoch kostengünstigeres Produkt benötigen. Durch die Lizenz wird die Nutzung der Datenbank auf einen Server mit höchstens zwei Netzwerkverbindungen beschränkt.
Oracle Database Express Edition („Oracle XE“) ist eine „Ausgangsversion“, die kostenlos zur Weiterentwicklung, Nutzung und Verteilung zur Verfügung gestellt wird. Sie baut auf dem Code von Oracle Database 10g Release 2 auf, also der Vorgängerversion der aktuellen Version 11, auf der die anderen drei Editionen basieren. Wie in der nachfolgenden Tabelle aufgezeigt, hat Oracle die Datenbank-Engine der Express Edition so eingeschränkt, dass nur eine CPU genutzt werden kann. Zudem können mit der Express Edition höchstens 4 GB Nutzerdaten gespeichert werden. Im Gegensatz zu den anderen drei Versionen von Oracle Database kann die Express Edition nicht unter dem Betriebssystem Unix ausgeführt werden.
38Tabelle 1: Überblick über bestimmte Schlüsselfunktionen von Oracle Database
Neben den vier Editionen von Oracle Database bietet Oracle verschiedene spezialisierte Datenbanken an. Oracle Database Lite stellt eine SQL-Datenbank mit geringem Speicherbedarf dar, die eingebettet auf mobilen Geräten verwendet werden kann, damit Unternehmensanwendungen eigenständig oder auch bei nicht ständiger Verbindung mobil genutzt werden können.
Oracle TimesTen In-Memory Database ist eine speicheroptimierte relationale Datenbank für Anwendungen, die eine sofortige Reaktion und sehr hohen Durchsatz erfordern, z. B. Anwendungen im Telekommunikationsbereich, für Kapitalmärkte sowie im Verteidigungswesen. Dieses Produkt kann auch als speicherinterner Datenbankcache für die Oracle-Datenbank verwendet werden, um die Reaktionszeit und den Durchsatz von Nutzeranwendungen zu verbessern.
Oracle Berkeley DB ist eine Familie von quelloffenen, einbettungsfähigen, nicht relationalen Datenbanken, die es Entwicklern ermöglicht, in ihre Anwendungen und Geräte eine schnelle, skalierbare und zuverlässige Datenbank-Engine zu integrieren.
Oracle berechnet eine Lizenzgebühr für die Datenbanksoftware und bietet einen separaten „Wartungsvertrag“ an (in öffentlichen Daten als „Lizenzupdates und Support“ [„license updates and support“] beschrieben). Wie bei jeder Unternehmenssoftware wird die Lizenzgebühr i. d. R. auf Basis eines „Listenpreises“ ausgehandelt und entsprechend den üblichen Kriterien wie dem Volumen angepasst. Der von Oracle für die Wartung berechnete Preis beträgt i. d. R. 22 % der […]*-Lizenz- […]* und wird jährlich neu berechnet. Die Wartung umfasst technischen Support (Telefon, webbasierte Wissensdatenbank), Bugfixes, Updates (d. h. Änderung von Steuersätzen/sonstige Gesetzesänderungen) sowie unbefristete Upgraderechte für alle zukünftigen Versionen der Software, ohne dass eine zusätzliche Lizenzgebühr zu entrichten ist.
Laut der Anmelderin beliefen sich die Einnahmen aus Lizenzen (d. h. ohne Support) für die verschiedenen Editionen von Oracle Database im Geschäftsjahr 2009 auf folgende Beträge: Enterprise Edition […]*; Standard Edition […]*; Standard Edition One […]*. Für andere Datenbankprodukte wurden folgende Lizenzeinnahmen erzielt: Berkeley Database [...]*; Database Lite […]* und TimesTen In Memory […]*.
1.2.2.Sun und seine Datenbankprodukte
13
56.Das wichtigste Datenbankprodukt von Sun ist MySQL. Sun erwarb MySQL 2008 für rund 1 Mrd. USD bei der Übernahme des schwedischen Unternehmens MySQL AB. Sun beschreibt MySQL auf seiner Website als die „populärste Open-Source-Datenbank der Welt“ mit über 11 Millionen aktiven Installationen und 60.000 Downloads pro Tag. MySQL läuft gegenwärtig auf über 20 Plattformen, u. a. Linux, Windows, OS X, Solaris OS, HP-UX, AIX und Netware.
57.Die erste Version von MySQL (die auf zuvor von einem kleinen Kreis von Kunden aus dem Consultingbereich verwendem Programmcode basierte) wurde im August 1996 allgemein verfügbar, zunächst nur für das Betriebssystem Solaris, kurz darauf auch für Linux. Die erste Version für Windows wurde im Januar 1998 veröffentlicht. Der Programmcode, auf dem MySQL basierte, war zu diesem Zeitpunkt bereits über ein Jahrzehnt im Gebrauch. Eine der Anforderungen, für die das Produkt besonders optimiert worden war, war das Data-Warehousing, bei dem vorwiegend Lesevorgänge ausgeführt werden mussten. Dadurch war MySQL insbesondere für Webanwendungen geeignet, ein Bereich, in dem sich das Produkt aufgrund der Unterstützung von Linux besonders gut etablierte, da Webentwickler MySQL als kostenloses RDBMS für ein kostenloses Betriebssystem sehr begrüßten.
58.MySQL ist seitdem unter Ausweitung des Funktionsumfangs weiterentwickelt worden, wodurch das Produkt nun auch für andere Anwendungsbereiche als das Web besser geeignet ist. So wurde MySQL z. B. 2001 mit einer speziellen Programmierschnittstelle ausgestattet, die die Auswahl verschiedener Speicher-Engines wie BerkeleyDB und InnoDB ermöglicht. Dadurch wurde die Funktionalität für die Transaktionsverarbeitung verbessert. 2003 erwarb MySQL das Produkt Cluster von einem zuvor von Ericsson finanzierten Start-Up-Unternehmen. 2005 wurde MySQL 5.0 mit wichtigen neuen Funktionsmerkmalen veröffentlicht (z. B. gespeicherten Prozeduren, Views, Triggern, Informationsschemata und Cursorn). Die aktuelle Version von MySQL ist Version 5.1. Die im Dezember 2008 veröffentlichte Version MySQL 5.1 stellte in gewissen Bereichen eine Verbesserung gegenüber Version 5.0 dar. So können z. B. durch Partitionierung nun extrem große Datenbanken (im Terabytebereich) unterstützt werden. Im April 2009 begannen die Alphatests von MySQL 5.4. In dieser Version soll die Skalierbarkeit für Mehrkern-CPUs verbessert werden.
59.Laut einem der Gründer von MySQL war die Datenbank bis zu dem Zeitpunkt, zu dem sie Transaktionen mittels der modularen Speicher-Engine-Architektur unterstützen konnte, bereits für den Betrieb von schätzungsweise mehreren Millionen Websites eingesetzt worden und daher Softwareentwicklern gut bekannt und sie hatte zahlreiche Anhänger in der FOSS-Community (Free and Open Source Software).
60.Ab 2001 konnte MySQL auch einen raschen Umsatzzuwachs verzeichnen, wobei Lizenzen für die Einbettung zu diesem Zeitpunkt die wichtigste Einnahmequelle darstellten. Dies legt die Vermutung nahe, dass schon zu diesem Zeitpunkt die Fähigkeit des Eigentümers des MySQL-Codes, Umsätze aus dem Verkauf proprietärer Lizenzen zu erzielen, was bei einem „dualen Lizenzierungsmodell“ möglich ist, einen wichtigen Faktor bei der weiteren Entwicklung des Produkts und der Fortentwicklung des Unternehmens darstellte. Dem gegenüber steht bei dem dualen Lizenzierungsmodell die Verteilung des Produkts unter einer kostenlosen Open-Source-Lizenz (oder genauer der GNU General Public License oder GPL v2).
61.Die Tatsache, dass MySQL unter der Open-Source-Lizenz kostenlos verfügbar ist, hat die Verbreitung des Produkts gefördert, und zwar nicht nur unter Webentwicklern, sondern auch unter anderen Mitgliedern der FOSS-Community. Die große Nutzercommunity, die sich rund um MySQL entwickelt hat, insbesondere von Nutzern, die das Produkt unter der GPL v2 nutzen, hat zu Verbesserungen des Quellcodes geführt. Dies zeigt, dass eine symbiotische Beziehung zwischen dem auf der Community basierenden FOSS-Entwicklungsmodell und dem kommerziellen Teil des IT-Sektors entstanden ist. Die Stellung von MySQL als führende Open-Source-Datenbank mit dem größten „Ökosystem“ unter allen Open-Source-Datenbanken wurde auch von Oracle in einem internen Dokument anerkannt.
62.Wie in Randnummer 32 dargelegt, bieten die meisten RDBMS-Anbieter integrierte RDBMS in dem Sinne an, dass die drei Schichten des RDBMS in einer Einheit miteinander kombiniert sind. Bei MySQL hingegen wird ein modularer Ansatz verwendet. Das Besondere daran ist, dass bei MySQL die Schnittstellen/Konnektoren zwischen den drei Schichten dokumentiert sind und durch Software genutzt werden können, die von Dritten entwickelt wurde. Auf diese Weise können die Schichten der Tools und Speicher-Engines angepasst werden. Die konstante Komponente von MySQL-Datenbanken ist der zentrale MySQL-Server, die mittlere Schicht, die unabhängig von den gewählten Tools und der gewählten Speicher-Engine immer gleich bleibt, so dass gewährleistet ist, dass die Datenbank eine MySQL-Datenbank bleibt. Viele für den Einsatz mit einer MySQL-Datenbank geschriebene Anwendungen funktionieren unabhängig von den jeweils konkret verwendeten Tools und/oder Speicher-Engines.
MySQL betont die Attraktivität seiner einzigartigen modularen Speicher-Engine-Architektur, die den Nutzern die Flexibilität bietet, eine Auswahl aus einem Portfolio von für verschiedene Anwendungsbereiche optimierten Speicher-Engines und Tools zu treffen.
MySQL-Datenbank
Tools
Schicht 1
Zentraler Server
Schicht 2
Speicher-Engine 1
Speicher-Engine 2
Speicher-Engine 3
Speicher-Engine 4
Schicht 3
Physischer Speicher
Daten-träger
Die Tatsache, dass die Architektur von MySQL für den Austausch einzelner Bestandteile konzipiert ist, hat zu einem großen Angebot von Speicher-Engines geführt, die in vielen Fällen speziell auf bestimmte Anforderungen zugeschnitten wurden. Neben einer Reihe von Speicher-Engines, die von MySQL selbst entwickelt wurden und angeboten werden (so genannten „nativen“ Speicher-Engines), sind auch Speicher-Engines von Drittanbietern sowie von Entwicklern aus der Open-Source-Community und Community-Mitgliedern, die Tools und Anwendungen zur Unterstützung der Datenbank bereitstellen/lizenzieren, für MySQL erhältlich. Des Weiteren können Nutzer von MySQL intern speziell auf ihre Anforderungen abgestimmte Speicher-Engines entwickeln.
Sun beschreibt auf seiner Website eine Reihe nativer Speicher-Engines, u. a. MyISAM (die Standard-Speicher-Engine von MySQL), Cluster (eine Engine für Datenbanken im Cluster, die sich für Anwendungsbereiche mit höchsten Anforderungen an Benutzerzeit und Verfügbarkeit eignet), Memory (die in Umgebungen, in denen ein extrem schneller Zugriff zum Nachschlagen erforderlich ist, alle Daten im Arbeitsspeicher (RAM) speichert) und Archive (die als Lösung für die Speicherung und das Abfragen großer Mengen von selten verwendeten historischen, archivierten oder Sicherheitsüberprüfungsinformationen beschrieben wird).
Zu den von Dritten entwickelten Speicher-Engines zählen InnoDB (die als transaktionssichere ACID-kompatible Speicher-Engine beschrieben wird) sowie solidDB, NitroEDB, Infobright, Calpont und ScaleDB.
67.MySQL als universell einsetzbare Datenbank ist in verschiedenen Editionen erhältlich:
MySQL Community Server steht auf der Sun-Website zum kostenlosen Download unter der Open-Source-Lizenz General Public License v2 („GPLv2“) zur Verfügung.
MySQL Enterprise ist im Abonnement für Nutzer verfügbar, die von einem fortlaufenden Produktsupport profitieren möchten. MySQL Enterprise beinhaltet zertifizierte Software, Updates und Upgrades, proaktive Benachrichtigungssysteme und virtuelle Ratgeber, die Online-Wissensdatenbank sowie vollständige technische Unterstützungsleistungen für produktive Systeme. Die zertifizierte Software (Datenbankserver, Konnektoren) wird unter der GPL-Lizenz bereitgestellt. Optional können die Kunden auch eine kommerzielle Lizenz wählen.
68.Neben MySQL Enterprise bietet Sun eine eingebettete Version der MySQL-Datenbank mit dem Namen MySQL Embedded Server 5.1 an. MySQL Embedded bietet die meisten Funktionsmerkmale von MySQL, so z. B. die Möglichkeit, mehrere Datenbank-Engines zu nutzen. MySQL Embedded ist unter der kostenlosen Open-Source-Lizenz GPLv2 oder einer kommerziellen Lizenz verfügbar.
Mit MySQL Cluster können mehrere Server gruppiert werden, so dass sie als ein einziger, zuverlässigerer Server mit höherer Kapazität erscheinen und fungieren. MySQL Cluster ist unter der kostenlosen Open-Source-Lizenz GPLv2 oder einer kommerziellen Lizenz in einer der beiden folgenden Editionen verfügbar: MySQL Cluster Standard Edition (SE) und Carrier Grade Edition (CGE). CGE bietet die Möglichkeit, einem aktiven Cluster Server hinzuzufügen, ohne die Anwendung offline zu schalten. Dadurch können Kunden aus der Telekommunikationsbranche die für sie unverzichtbare Zuverlässigkeit, d. h. eine Verfügbarkeit von 99,999 % erreichen.
70.Sun bietet für seine MySQL Enterprise-Produkte vier Leistungsstufen von Supportabonnements an, die je nach angebotener Funktionalität und angebotener Unterstützung im Preis variieren: Basic Support bietet Updates, Patches und E-Mail-Support für zwei Problemfälle zum Preis von 599 USD, im Silver Support erhält der Kunde Support während der Geschäftszeiten zum Preis von 1.999 USD, mit Gold Support wird Support rund um die Uhr zum Preis von 2.999 USD angeboten und mit dem Platinum Support erhält der Kunde für 4.999 USD auch Managementsupport und Beratung.
71.Da es sich bei MySQL um ein Open-Source-Produkt handelt, wird zudem nicht nur von Sun, sondern auch von Wettbewerbern technischer Support für MySQL angeboten. Hierzu zählen: Novell, Red Hat, HP, Monty Program, Percona, Linagora und Mayflower.
72.In der Branche durchgeführte Erhebungen (auf die in Abschnitt 4.3.4.1.2., „Erhebungen“, näher eingegangen wird) zeigen, dass die Verbreitung von Open-Source-Software im Allgemeinen und MySQL im Besonderen in vielen europäischen Ländern sehr hoch ist. Ferner ist zu erwarten, dass die Nutzung von Open-Source-Software in den kommenden Jahren noch intensiver werden wird. So ergab z. B. eine in den nordischen und den Benelux-Ländern durchgeführte Erhebung, dass 44 % der repräsentativen Auswahl mit Open-Source-Software arbeiteten und 46 % davon MySQL implementiert hatten. Dieselbe Erhebung ergab, dass 25 % der Befragten, die noch nicht mit Open-Source-Software arbeiteten, den Einsatz von Open-Source-Software innerhalb der folgenden zwei Jahre planten, während ein Drittel derjenigen, die bereits Open-Source-Software nutzten, für denselben Zeitraum eine Intensivierung der Nutzung von Open-Source-Software anvisierte. Eine zweite Erhebung bezüglich der Nutzung von Open-Source-Software in kleinen und mittleren Unternehmen in sieben europäischen Ländern ergab, dass über 50 % der befragten Unternehmen Open-Source-Software nutzten und diese mehr als 50 % ihrer IT-Infrastruktur ausmachte.
73.Diese Aspekte sind zusammen mit Beispielen aus der Marktuntersuchung, die zeigen, dass Kunden von proprietären auf Open-Source-RDBMS umstellen, ein Indiz für die zunehmende Akzeptanz von Open-Source-Software wie MySQL bei europäischen Unternehmen und Organisationen. Dies ist möglicherweise auch ein Grund dafür, dass diverse europäische Unternehmen Bedenken bezüglich des Zusammenschlussvorhabens geäußert haben.
61Siehe MySQL-Website unter: http://dev.mysql.com/downloads/select.php?id=14 (doc_ID 3029).
62Siehe TAEUS-Bericht, S. 31 (doc_ID 3011).
63Formblatt CO, S. 147.
64Formblatt CO, S. 158.
65TNS Technology – „Open Source Software Barometer 2009 – Nordic and Benelux Report“ (doc_ID 2143).
66TNS Technology – „Open Source Barometer 2009 – European SMB Report“ (doc_ID 2673).
67Siehe z. B. Antwort der schwedischen Nationalpolizei auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1984).
1.2.3 Andere wichtige Wettbewerber
Neben Oracle und Sun bieten noch verschiedene andere Unternehmen RDBMS an. Die wichtigsten Anbieter proprietärer RDBMS nach Oracle sind, gemessen an den anhand der Einnahmen ermittelten Marktanteilen, IBM, Microsoft und Sybase (obwohl letztere Unternehmen eine geringere Marktpräsenz als Oracle, IBM oder Microsoft besitzt). Es gibt zwei weitere Open-Source-RDBMS, nämlich PostgreSQL und Ingres. Die von der Kommission durchgeführte Marktuntersuchung hat jedoch ergeben, dass diese alternativen Open-Source-RDBMS gegenwärtig nicht so weit verbreitet sind wie MySQL.
1.2.3.1. IBM
75.Das wichtigste Datenbankprodukt von IBM ist DB2. Wie Oracle Database ist auch DB2 in verschiedenen Editionen erhältlich, die auf verschiedene Anforderungen der Endnutzer abgestimmt sind. Das „Flaggschiffprodukt“ Enterprise Server Edition wird auf der Website von IBM als „ideal für stabile, hoch leistungsfähige On Demand Lösungen“ [„ideal for high-performing, robust, on-demand enterprise solutions“] beschrieben. Weitere erhältliche Editionen von DB2 sind die Workgroup Server Edition, die „ideal für Abteilungen, Arbeitsgruppen oder mittelständische Unternehmen geeignet“ [„ideal for departmental, workgroup, or medium-sized business environments“] ist, eine Express Edition, die „zu einem attraktiven Einstiegspreis für kleine und mittlere Unternehmen“ [„at an attractive entry-level price for small and medium businesses“] angeboten wird, sowie DB2 Express-C, eine kostenlose Einstiegsedition für die Entwickler und Partner.
IBM bietet noch eine weitere Palette von Datenbankprodukten unter der Marke Informix an. Informix Dynamic Server (IDS) Enterprise Edition bietet laut Beschreibung „uneingeschränkte Skalierbarkeit für höchste OLTP-Leistung... herausragende Zuverlässigkeit, Skalierbarkeit und höchsten Verwaltungskomfort für Unternehmen“ [„unlimited scalability for the highest OLTP performance… outstanding reliability, scalability and manageability for the enterprise“]. Auch die Informix-Datenbank bietet IBM in verschiedenen Editionen an, bei denen einem eingeschränkten Umfang von Features, Funktionalität oder Kapazität i. d. R. durch einen entsprechend niedrigeren Preis Rechnung getragen wird.
Des Weiteren bietet IBM eine speicherinterne relationale Datenbank mit der Bezeichnung solidDB an.
1.2.3.2. Microsoft
Nach Aussage der Anmelderin stellt SQL Server 2008 Enterprise Edition von Microsoft eine umfassende Datenbankplattform dar, die den hohen Anforderungen der Onlinetransaktionsverarbeitung und Data-Warehousing-Anwendungen in Unternehmen gerecht wird. Microsoft bietet seine „Flaggschiff“-Datenbank SQL Server in verschiedenen Editionen an, bei denen einem geringeren Umfang von Features, Funktionalität oder Kapazität i. d. R. durch einen entsprechend niedrigeren Preis Rechnung getragen wird.
Microsoft SQL Server Compact ist für den Einsatz als eingebettete Datenbank zur Entwicklung von Desktop- und mobilen Anwendungen konzipiert und kann kostenlos heruntergeladen werden.
Microsoft ist der weltweit größte Anbieter proprietärer Software und laut einem von der Anmelderin in ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte zitierten Marktbericht ist Microsoft auch der weltweit größte Datenbankanbieter, gemessen am Absatzanteil (wenn auch nicht an den Einnahmen), der größer ist als die Anteile von IBM und Oracle zusammen.
1.2.3.3. Sybase
Sybase ist ein 1984 gegründeter, in den USA ansässiger Datenbankanbieter. Das Unternehmen bietet zwei Produktlinien von RDBMS für Unternehmen an, nämlich Adaptive Server Enterprise (ASE) für erfolgskritische Transaktionen und Sybase IQ für Data-Warehousing-Anwendungen. Daneben werden zwei Produktlinien von eingebetteten RDBMS angeboten, nämlich SQL Anywhere und Advantage Database Server. Sybase bietet auch seine „Flaggschiff“-Datenbank Adaptive Server Enterprise in verschiedenen Editionen an, bei denen einem geringeren Umfang von Features, Funktionalität oder Kapazität i. d. R. durch einen entsprechend niedrigeren Preis Rechnung getragen wird.
1.2.3.4. PostgreSQL
PostgreSQL ist ein Open-Source-RDBMS, das ursprünglich von dem Ingres-Projekt an der University of California, Berkeley, abgeleitet wurde. PostgreSQL wird von einer Reihe von Sponsoren gefördert, die je nach der zeitlichen Dauer und Art ihrer Förderung in vier Stufen unterteilt werden. PostgreSQL unterstützt als RDBMS alle Vorgänge im Unternehmen. Zudem stellt das Produkt eine Entwicklungsplattform dar, auf der interne, für das Web bestimmte oder kommerzielle Softwareprodukte entwickelt werden können, für die ein RDBMS erforderlich ist.
PostgreSQL kann unter allen wichtigen Betriebssystemen, u. a. Linux, UNIX und Windows, eingesetzt werden. PostgreSQL ist in hohem Maße anpassungsfähig, so dass die Nutzer PostgreSQL in jeder gewünschten Form nutzen, ändern oder vertreiben können, und zwar sowohl in Closed-Source- als auch in Open-Source-Form. PostgreSQL wird nicht von einem Unternehmen allein kontrolliert, jedoch haben
68Siehe Antwort von Oracle auf Frage 9 des an Oracle gerichteten Auskunftsersuchens vom 25. September 2009 (doc_ID 2264). Dazu gehören SQL Server Standard, Workgroup, Web, Developer und Express (eine zum kostenlosen Download verfügbare Edition, die für KMU, für Entwickler von Desktop- und kleinen Serveranwendungen sowie für den Weitervertrieb durch ISVs bestimmt ist). Ein Vergleich der verschiedenen Editionen von SQL Server ist auf folgender Seite zu finden: http://www.microsoft.com/sqlserver/2008/en/us/editions.aspx (doc_ID 3028).
71IDC, „Server and Workload Forecasts and Analysis Study 2002-2010“, Juli 2007, zitiert in der Erwiderung von Oracle auf die Mitteilung der Beschwerdepunkte, S. 53 und 69 (doc_ID 4828).
72Siehe Antwort von Sybase auf Frage 2 des an Wettbewerber auf dem Datenbankmarkt gerichteten Auskunftsersuchens vom 31. Juli 2009 (doc_ID 966).
73Siehe Antwort von Oracle auf Frage 9 des an Oracle gerichteten Auskunftsersuchens vom 25. September 2009 (doc_ID 2264).
74Eine Liste der Sponsoren ist auf der PostgreSQL-Website unter http://www.postgresql.org/about/sponsors (doc_ID 5220) zu finden.
mehrere Unternehmen, darunter EnterpriseDB und Greenplum, proprietäre Produkte auf Basis von PostgreSQL entwickelt.
1.2.3.5. Ingres
83.Ingres ist eine Open-Source-Datenbank für Unternehmen, die kommerziell von Ingres Corporation („Ingres“) unterstützt wird. Die Ingres-Datenbank bietet laut einschlägigen Angaben Transaktionsverarbeitung mit hohem Volumen, Hochverfügbarkeit, Unterstützung mehrerer Plattformen sowie Sicherheit für erfolgskritische Anwendungen.
84.Ingres verwendet ein duales Lizenzierungsmodell. Die Open-Source-Version der Ingres-Datenbank ist nach Maßgabe der Bestimmungen der GPL kostenlos für Endnutzer verfügbar („Open-Source-Version“). Die kommerzielle Version der Ingres-Datenbank ist nach Maßgabe der Bestimmungen der proprietären Lizenz von Ingres für zahlende Kunden verfügbar („kommerzielle Version“). Der Hauptunterschied zwischen der Open-Source-Version und der kommerziellen Version besteht darin, dass die kommerzielle Version den internen Qualitätssicherungsprozess von Ingres durchläuft. Für die kommerzielle Version übernimmt Ingres daher eine Gewährleistung und haftet im Fall einer Urheberrechtsverletzung.
1.2.3.6. Sonstige RDBMS-Anbieter
85.Der RDBMS-Markt ist dadurch gekennzeichnet, dass neben den Hauptanbietern von proprietären und Open-Source-RDBMS zahlreiche weitere Anbieter aktiv sind, von denen viele sich auf bestimmte Marktsegmente oder Nischen spezialisiert haben. Zu diesen Anbietern zählen beispielsweise Teradata, ein für seine Data-Warehousing-Funktionen bekanntes Unternehmen, SAS (Geschäftsanalyse) und Fujitsu. In Analystenberichten sind zahlreiche weitere RDBMS-Anbieter aufgeführt, jedoch sind deren einnahmenbezogene Marktanteile unbedeutend.
75Siehe konsolidierte Antwort von Oracle auf das Auskunftsersuchen vom 13. September 2009 (doc_ID 2264). Gemäß der unternehmenseigenen Werbung ist EnterpriseDB der führende Anbieter von für Unternehmen geeigneten Produkten und Dienstleistungen auf Basis von PostgreSQL. Das Unternehmen wurde 2004 mit dem Ziel gegründet, eine einzelne, erschwingliche Datenbank zu schaffen, die für die Integration mit führenden kommerziellen DBMS kompatibel sein sollte. Als technologisches Fundament wählte das Unternehmen PostgreSQL, da sich PostgreSQL seit über 20 Jahren in umfangreichen kommerziellen Systemen bewährt hatte, über eine lebendige Entwicklercommunity verfügte und als die beste erhältliche Open-Source-Datenbank bekannt war. Siehe http://www.enterprisedb.com/company/enterprisedb.do (doc_ID 5222).
76Laut der unternehmenseigenen Werbung ist Greenplum Database eine Software-Lösung, die auf die Unterstützung des Data-Warehousing der nächsten Generation sowie auf analytische Verarbeitung in großem Maßstab ausgelegt ist. Greenplum Database bietet eine branchenweit führende Leistung zu geringen Kosten für Unternehmen, die Terabyte bis Petabyte von Daten zu verwalten haben. In Greenplum Database kommt eine für Business Intelligence und analytische Verarbeitung optimierte Shared-Nothing-MPP-Architektur (Massively Parallel Processing, massiv-parallele Verarbeitung) zum Einsatz. Siehe http://www.greenplum.com/products/greenplum-database/ (doc_ID 5221)
2. Marktabgrenzung
2.1. Abgrenzung des sachlich relevanten Marktes
86.Wie in der Entscheidung nach Artikel 6 Absatz 1 Buchstabe c festgestellt, hat sich die Kommission erst in einer früheren Entscheidung mit der Frage der Abgrenzung des sachlich relevanten Marktes für Datenbanken befasst, und zwar im Zusammenhang mit einem Fusionskontrollverfahren in der Sache IBM/Informix. In dieser Sache wurde die genaue Abgrenzung des sachlich relevanten Marktes jedoch letztendlich offen gelassen.
87.In der vorliegenden Sache ergab die von der Kommission durchgeführte Marktuntersuchung der ersten Phase zwar, dass Datenbanken sowohl aus Lieferanten- als auch aus Nutzersicht differenzierte Produkte darstellen, jedoch wurde „kein geeigneter Ansatz für die Abgrenzung des Datenbankmarktes aufgezeigt. Im Gegenteil lieferte sie Hinweise auf eine fortdauernde Substituierbarkeit von Datenbanken und somit auf bestehenden Wettbewerb.“ [„…did not identify a single appropriate approach to delineating the database market. On the contrary it pointed towards a continuum of database substitutability and hence competition.“]
88.Diese Schlussfolgerung deckte sich somit mit dem Vortrag der Anmelderin zum Zeitpunkt der Anmeldung, demzufolge „eine geeignete Marktabgrenzung für Datenbanken alle Datenbankprodukte umfasst, was der gängigen Praxis bei Analysten und Datenbankanbietern entspricht“ [„the appropriate market definition for database includes all database products, which is consistent with the practices of analysts and database distributors“].
89.Oracle trug vor, eine Abgrenzung des sachlich relevanten Marktes für Datenbanken nach anderen Kriterien, z. B. nach Betriebssystemen, „stünde im Widerspruch zu der Art und Weise, in der Kunden Software wählen, der Art und Weise, in der Datenbanksoftware entwickelt wird, und der früheren Entscheidungspraxis der Kommission sowohl in Fusionskontrollsachen als auch in Fällen im Zusammenhang mit Artikel 82“ [„…would be at odds with the manner in which customers choose software, at odds with the way database software is developed and at odds with considerable Commission precedent in both merger and Article 82 cases“]. Wie ein Wettbewerber bemerkte, trug Oracle selbst in einem früheren Fall (Oracle/PeopleSoft) vor, die künstliche Segmentierung oder „Aufgliederung“ („tiering“) eines Softwaremarktes nach Absatz und Marktsegment (z. B. große Unternehmen mit komplexen Funktionsanforderungen) sei nicht angemessen.
90.Oracle bekräftigte in der ersten Reaktion auf die Entscheidung nach Artikel 6 Absatz 1 Buchstabe c seine Auffassung, dass RDBMS zu einem einzigen relevanten sachlichen Markt gehören. In seinem Vortrag vom 26. September 2009 erklärte das Unternehmen, „Oracle stimmt dem Schluss zu, dass der sachlich relevante Markt alle RDBMS umfasst (Entscheidung, Randnummer 22)“ [„Oracle agrees with the finding that the relevant product market encompasses all RDBMS (Decision para. 22)“]. Eine Woche später änderte die Anmelderin jedoch ihre Meinung und trug vor, für eingebettete Datenbanken sei ein eigenständiger Markt zu definieren.
91.Aus den in Abschnitt 2.1.1. dargelegten Gründen ist es nicht angebracht, zwecks der Bewertung des Zusammenschlussvorhabens einen eigenständigen sachlich relevanten Markt für eingebettete Datenbanken oder sogar unterschiedliche sachlich relevante Märkte je nach Betriebssystem, Kundengruppe oder anderen in der Entscheidung nach Artikel 6 Absatz 1 Buchstabe c genannten Kriterien zu definieren.
92.Im Gegenteil deckt der sachlich relevante Markt im vorliegenden Fall alle RDBMS ab, wenn auch verschiedene Produkte differenziert werden können und Teilsegmente des Gesamtmarktes zu identifizieren sind, in denen sich die Wettbewerbsdynamik möglicherweise anders darstellt.
2.1.1. Eingebettete und nicht eingebettete RDBMS
93.Oracle trug in seiner detaillierten Antwort auf die Entscheidung nach Artikel 6 Absatz 1 Buchstabe c vor, dass eingebettete Datenbanken oder zumindest speziell für die Einbettung in Softwareprogramme oder Geräte entwickelte Datenbanken als eigenständiger Markt zu behandeln seien.
94.Oracle machte geltend, der vorgeschlagene Markt für eingebettete Datenbanken solle sich sowohl auf relationale als auch auf nicht relationale Datenbanken erstrecken. Obwohl dies der von Oracle eingenommenen Position bezüglich des RDBMS-Marktes, aus dem nicht relationale DBMS ausgeschlossen sind, widerspricht, legte das Unternehmen weder aus der Nachfrage- noch aus der Angebotsperspektive dar, warum die Unterscheidung im Segment für eingebettete Datenbanken nicht gelten sollte. Vielmehr stellte Oracle fest, Analytiker wie IDC würden in ihren Berichten zu eingebetteten Datenbanken die Einnahmen aus relationalen und nicht relationalen DBMS zusammenfassen und die Kommission habe die Richtigkeit dieser Vorgehensweise implizit bestätigt, indem sie Berkeley DB von Oracle (ein nicht relationales DBMS) in Randnummer 30 der Entscheidung der Kommission nach Artikel 6 Absatz 1 Buchstabe c „in den relevanten Markt“ einbezogen habe.
95.Oracle trug ferner in seiner detaillierten Antwort auf die Entscheidung nach Artikel 6 Absatz 1 Buchstabe c vor, viele der Feststellungen der Kommission im Hinblick auf den Gesamtmarkt für RDBMS hätten für einen eigenständigen Markt ausschließlich für eingebettete Datenbanken keine Gültigkeit.
96.Das Unternehmen stellte fest, dass zahlreiche DBMS-Produkte speziell zur Einbettung in Softwareprogramme oder Geräte entwickelt worden seien und die Struktur des Marktes für eingebettete Datenbanken sowie die von verschiedenen Wettbewerbern angebotene Auswahl sehr speziell und in hohem Maße anwendungsspezifisch seien. Oracle räumte jedoch ein, dass es eine gewisse Überschneidung zwischen eingebetteten und nicht eingebetteten Datenbanken gibt, da einige RDBMS-Anbieter eingebettete Versionen ihrer allgemeinen RDBMS-Produkte an ISVs liefern, die diese zusammen mit Anwendungssoftware verkaufen. Oracle legte dar, diese Art von eingebetteten Datenbanken könne als zu dem allgemeinen RDBMS-Markt gehörend betrachtet werden, quantifizierte jedoch nicht die möglichen Auswirkungen auf die für i) RDBMS und ii) eingebettete Datenbanken angegebenen Marktanteile.
97.Oracle machte geltend, dass das Vorhaben im Hinblick auf eingebettete Datenbanken nicht in demselben Maße zu einer Konzentration führen würde, wie dies auf dem Gesamtmarkt für Datenbanken zu beobachten sei, denn die Hauptakteure auf dem RDBMS-Markt (Oracle, IBM und Microsoft) „... stehen laut IDC als Anbieter von eingebetteten DBMS an erster, dritter bzw. fünfter Stelle und besitzen zusammen einen Marktanteil von [40-50]* %, was etwas mehr als der Hälfte der von der Kommission angegebenen Marktanteile dieser Unternehmen am RDBMS-Markt entspricht“ [„…respectively the first, third and fifth firms in the Embedded DBMS Software market according to IDC, with a combined share of [40-50]* %, just over half the revenue share the Commission claims these firms have in the RDBMS market“].Das Unternehmen trug vor, MySQL sei mit einem Marktanteil von lediglich [0-5]* % nach Angabe von IDC kein bedeutender Anbieter eingebetteter DBMS. Des Weiteren stellte
84Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009 (doc_ID 2427). Die Kommission stellt fest, dass Randnummer 30 der Entscheidung der Kommission nach Artikel 6 Absatz 1 Buchstabe c in den Abschnitt zur wettbewerbsrechtlichen Würdigung, genauer in einen Teil der Entscheidung fällt, in dem die Palette der von Oracle angebotenen Datenbankprodukte beschrieben wird. Die Randnummer folgt auf den Abschnitt zum sachlich relevanten Markt für Datenbanken, in dem die Kommission überzeugende Hinweise darauf gefunden hat, dass der sachlich relevante Markt alle RDBMS umfasst [„the relevant product market encompasses all RDBMS“]. Die Behauptung der Anmelderin, die Kommission habe Berkeley DB (ein nicht relationales DBMS) in den sachlich relevanten Markt eingeschlossen, ist daher irreführend, und zwar insofern, als der sachlich relevante Markt in der Entscheidung der Kommission nach Artikel 6 Absatz 1 Buchstabe c als alle RDBMS umfassend definiert wurde und kein separater sachlich relevanter Markt für eingebettete Datenbanken (unabhängig davon, ob relational oder nicht relational) in Erwägung gezogen wurde. Ferner beziehen sich nachfolgende Erörterungen des sachlich relevanten Marktes in der Entscheidung einschließlich der Marktanteile der Datenbankanbieter (basierend z. B. auf Daten von IDC und in Randnummer 41 der Entscheidung der Kommission nach Artikel 6 Absatz 1 Buchstabe c genannt) ausschließlich auf RDBMS. Mit anderen Worten sind in den Umsatzzahlen und Marktstellungen von DBMS-Anbietern alle nicht relationalen DBMS ausgeschlossen, eingebettete RDBMS hingegen eingeschlossen.
100.Oracle aus verschiedenen Gründen die Bedeutung in Frage, die die Kommission den Bedenken beimisst, die von einigen Kunden aus der Telekommunikationsbranche im Segment der eingebetteten Datenbanken geäußert wurden. Erstens machte das Unternehmen geltend, diese Kunden würden ein Nischenprodukt kaufen. Zweitens war es der Auffassung, die Produkte der beteiligten Unternehmen seien „keine engen Substitute, ja, oftmals gar nicht austauschbar“ [„not strong substitutes and are often not interchangeable at all“]. Schließlich trug Oracle vor, es gebe eine recht große Zahl von Wettbewerbern, die ähnliche Datenbanken anbieten, und es „wäre irreführend, so vorzugehen, als sei das spezialisierte Nischenprodukt Teil des allgemeinen RDBMS-Marktes“ [„it would be misleading to proceed as if the specialized, niche product is part of the general RDBMS market“].
98.Eine eingebettete Datenbank ist eine Datenbank, die in eine Anwendung integriert werden kann, welche Zugriff auf gespeicherte Daten erfordert. Die Datenbank ist i. d. R. für die Endnutzer der Anwendung „nicht sichtbar“ und bedarf nur geringer oder gar keiner laufenden Wartung. Allgemein ausgedrückt, werden eingebettete Datenbanken als Teil eines Produktangebots eines ISVs (Drittanbieter von Software) oder OEMs (Originalgerätehersteller von Hardware) integriert (gebündelt), verkauft und unterstützt, wobei eine entsprechende Lizenz des Datenbankanbieters gilt.
99.Eingebettete Datenbanken laufen üblicherweise, ohne dass ein Datenbankadministrator sie über die Verwaltungs-APIs (Application Program Interface, Anwendungsprogrammierschnittstelle) steuert. Es werden unterschiedlichste eingebettete Datenbanken angeboten, da es auch eine Vielzahl unterschiedlicher Möglichkeiten für das Einbetten einer Datenbank gibt, so z. B. in mobilen Geräten, Unterhaltungselektronik, Desktopanwendungen, Unternehmenssoftware, Messeinrichtungen, Telekommunikationsgeräten, Industrieanlagen, Fahrzeugen usw. Eines der befragten Unternehmen in der Marktuntersuchung der zweiten Phase stellte Folgendes fest:
86.„Die Einbettung ist unverzichtbar, wenn ein ISV sein Angebot an einen Kundenkreis richtet, zu dem technisch nicht sehr versierte Nutzer gehören, denen kein Systemadministrator zur Verfügung steht. Zudem ist sie die einzige Möglichkeit, ein ‚gebrauchsfertiges‘ Gerät wie ein Mobiltelefon oder Navigationssystem anzubieten.“ [„Embedding is indispensable if an ISV targets an audience including technically non-sophisticated users who do not have access to a system administrator. It is also the only way to provide a "turnkey" device such as a mobile telephone or navigation system.“]
100.Wie die Anmelderin selbst einräumte, ist „... eine eingebettete Datenbank kein anderes Produkt als eine nicht eingebettete Datenbank oder eine Datenbank für Unternehmen. Alle Datenbankprodukte von Oracle werden sowohl eingebetteter als auch nicht eingebetteter Form genutzt, wobei die Mischung der Nutzungsformen je nach Produkt und Kundenanforderungen variiert.“ [„… an embedded database is not a different product than a non-embedded or enterprise database. All of Oracle's database products are used in both embedded and non-embedded contexts, with the mix of use varying depending on the product and the customer's requirements.“] Damit wird implizit bestätigt, welche Schwierigkeiten es bereitet, für wettbewerbsrechtliche Zwecke eine geeignete Abgrenzung zwischen eingebetteten und nicht eingebetteten Datenbanken zu treffen sowie den Grad der angebotsseitigen Substituierbarkeit der beiden Datenbanktypen zu bestimmen.
101.Die Marktuntersuchung hat gezeigt, dass die Wahl einer Datenbank für den Einsatz in eingebetteter Form in hohem Maße von der jeweiligen Anwendung abhängig ist. In diesem Zusammenhang haben verschiedene Befragte angegeben, dass die Möglichkeit der Nutzung einer bestimmten angebotenen Datenbank als eingebettete Datenbank von den Geschäftsanforderungen und -parametern des Kunden abhänge, die nicht unbedingt flexibel seien. Dabei wird als Beispiel ein Mobiltelefon angeführt, in dem eine Datenbank mit geringem Speicherbedarf die logische Wahl wäre. In anderen Zusammenhängen sind jedoch die geschäftlichen oder technischen Anforderungen weniger streng, so dass eine breitere Palette von Datenbanken in Erwägung gezogen werden kann.
102.Obwohl nach Meinung einer Mehrheit der Kunden eingebettete und nicht eingebettete Datenbanken nicht miteinander im Wettbewerb stehen, räumte eine größere Zahl der Kunden ein, dass eine von einem Kunden als eingebettete Datenbank genutzte Datenbank von einem anderen Kunden in nicht eingebetteter Form genutzt werden könnte. Daran wird erneut die Schwierigkeit deutlich, für wettbewerbsrechtliche Zwecke eine klare Abgrenzung zwischen eingebetteten und nicht eingebetteten Datenbanken zu treffen.
89.Siehe Antwort von Oracle auf Frage 20 des an Oracle gerichteten Auskunftsersuchens vom 11. September 2009 (doc_ID 1649). In seiner Antwort trägt Oracle vor, Oracle Database (alle Editionen) sei vorwiegend für die Nutzung in Unternehmen konzipiert, werde jedoch gelegentlich auch eingebettet; Oracle Berkeley DB werde überwiegend in eingebetteter Form genutzt, während Oracle TimesTen In-Memory Database und Oracle Database Lite ungefähr in gleichem Umfang in Unternehmen und in eingebetteter Form genutzt würden. In seiner Antwort auf Frage 27 des oben genannten Auskunftsersuchens legte Oracle dar, dass MySQL zwei Produkte für die Nutzung in eingebetteter Form anbiete: MySQL Embedded und MySQL Cluster. Es wird festgestellt, MySQL Embedded stelle einfach ein „Rebranding“ von MySQL dar, das speziell auf den Markt für OEM/eingebettete Datenbanken abziele und im Hinblick auf den Quellcode, die APIs und die Funktionsmerkmale mit MySQL Server (Versionen Enterprise oder Community) identisch sei. MySQL Cluster wird für spezialisierte Anwendungsbereiche in der Telekommunikationsbranche angeboten. Der gesamte Code von MySQL Cluster ist auch in MySQL Server enthalten. Sowohl MySQL Embedded als auch MySQL Cluster sind unter einer kommerziellen Lizenz und auf Open-Source-Basis verfügbar.
90.Siehe z. B. die Antworten von IBM und Monty Program AB auf Frage 12 des an Wettbewerber auf dem Datenbankmarkt gerichteten Auskunftsersuchens (doc_ID 2044 bzw. doc_ID 1891).
91.Siehe Antwort von IBM auf Frage 12 des an Wettbewerber auf dem Datenbankmarkt gerichteten Auskunftsersuchens (doc_ID 2044).
92.Siehe Antworten auf Frage 18 des an Datenbankkunden gerichteten Auskunftsersuchens (doc_ID 2320).
93.Siehe Antworten auf Frage 17 des an Datenbankkunden gerichteten Auskunftsersuchens (doc_ID 2320).
30
31
32
104.Auf Grundlage der in den vorstehenden Randnummern erörterten Elemente gelangte die Kommission bei der Annahme der Mitteilung der Beschwerdepunkte zu der vorläufigen Schlussfolgerung, dass eine Abgrenzung eigenständiger sachlich relevanter Märkte für eingebettete und nicht eingebettete Datenbanken nicht angemessen wäre. Diese Schlussfolgerung wurde nachfolgend durch einige Drittunternehmen untermauert, die Kommentare zu der nicht vertraulichen Version der Mitteilung der Beschwerdepunkte vorlegten. Die Anmelderin selbst bestritt die Erkenntnisse der Kommission in ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte nicht. Daher ist die Kommission nach wie vor der Auffassung, dass für die Zwecke des vorliegenden Beschlusses eine Abgrenzung eigenständiger sachlich relevanter Märkte für eingebettete und nicht eingebettete Datenbanken nicht angemessen wäre.
2.1.2.Abgrenzung des sachlich relevanten Marktes auf Basis anderer Kriterien
105.Die von der Kommission durchgeführte Marktuntersuchung der ersten Phase ergab verschiedene Merkmale von Datenbankprodukten, anhand derer möglicherweise eine weitere Abgrenzung des Datenbankmarktes möglich wäre, wobei kein einzelnes Kriterium vorherrschend ist. Neben der im vorangegangenen Abschnitt 2.1.1. dargelegten Unterscheidung zwischen der Nutzung von Datenbanken in eingebetteter und nicht eingebetteter Form wurden in der Entscheidung nach Artikel 6 Absatz 1 Buchstabe c u. a. folgende Kriterien genannt:
-− Typ der Anwendung, z. B. Datenbanken für Webanwendungen, Datenbanken für analytische Onlineverarbeitung (Online Analytical Processing, OLAP) und Datenbanken für Onlinetransaktionsverarbeitung (Online Transaction Processing, OLTP)
-− Kompatibilität mit der bestehenden IT-Infrastruktur des Kunden
-Unterscheidung zwischen universell einsetzbaren Datenbanken und spezialisierten Datenbanken, z. B. für Data-Warehousing
-− Unterscheidung zwischen erfolgskritischen und nicht erfolgskritischen Anwendungen
106.Die Marktuntersuchung der zweiten Phase erbrachte keinerlei neuen Elemente, aus denen die Kommission den Schluss ziehen kann, dass eines oder mehrere der in Randnummer 105 aufgeführten Kriterien eine geeignete Grundlage für die Abgrenzung eines sachlich relevanten Marktes bilden würde, der enger gefasst wäre als ein alle RDBMS umfassender Markt. Diesem Schluss wurde seitens der Anmelderin nicht widersprochen, wobei die einzige Ausnahme in der in ihrer Erwiderung auf die Entscheidung nach Artikel 6 Absatz 1 Buchstabe c vertretenen Auffassung besteht, es sei ein eigenständiger sachlich relevanter Markt für eingebettete Datenbanken (einschließlich relationaler und nicht relationaler Varianten) zu definieren.
107.Zwar zeigten die Antworten auf die Marktuntersuchung der zweiten Phase erneut, dass der RDBMS-Markt aus unterschiedlichen Blickwinkeln untersucht werden kann, wobei jeweils Teilsegmente identifiziert werden könnten, so z. B. nach Kundentyp und/oder der Art der Nutzung einer bestimmten Datenbank in dem betreffenden Unternehmen, jedoch hat die Marktuntersuchung keine ausreichenden Belege dafür erbracht, dass diese Teilsegmente als eigenständige sachlich relevante Märkte zu betrachten wären. In diesem Zusammenhang sei bezüglich der Angebotsseite erneut darauf hingewiesen, dass zwar gewisse Datenbankanbieter möglicherweise eine Differenzierung ihrer Produkte anstreben, indem sie diese in verschiedenen Editionen oder Versionen anbieten, die angeblich bestimmte Nischenmärkte abdecken, der diesen Versionen zugrunde liegende Code jedoch im Wesentlichen identisch ist. Dies legt den Schluss nahe, dass alle entsprechenden Produkte in Übereinstimmung mit der Bekanntmachung der Kommission über die Definition des relevanten Marktes im Sinne des Wettbewerbsrechts der Gemeinschaft zu ein und demselben sachlich relevanten Produktmarkt gehörend zu erachten sind. Des Weiteren können diese Teilsegmente insofern nicht als eigenständige Märkte betrachtet werden, als keine klare Grenze zwischen ihnen erkennbar ist. Tatsächlich besteht nicht immer Einvernehmen bezüglich der Frage, wie bestimmte Begriffe zu definieren sind. Dies kann anhand der Unterscheidung zwischen erfolgskritischen und nicht erfolgskritischen Nutzungsarten verdeutlicht werden.
108.Unter dem Gesichtspunkt der Kompatibilität einer Datenbank mit der bestehenden IT-Infrastruktur eines Kunden stellten zwar einige Befragte fest, die von Microsoft angebotene Datenbank könne nur unter den Microsoft-Betriebssystemen eingesetzt werden und würde daher für Kunden, die ein anderes Betriebssystem nutzen, keine überzeugende Option darstellen, andere Befragte gaben jedoch an, sie würden sich bei der Wahl einer Datenbank an ihren Geschäftsanforderungen orientieren und daher unabhängig von dem in ihrem Unternehmen verwendeten Betriebssystem entscheiden.
Gleichzeitig sei erneut darauf hingewiesen, dass die meisten RDBMS-Anbieter mehrere Betriebssystemplattformen unterstützen.
2.1.3.Schlussfolgerung zur Abgrenzung des sachlich relevanten Marktes
109.In Anbetracht der Ergebnisse der Marktuntersuchungen der ersten und zweiten Phase der Untersuchung wird in der vorliegenden Sache der Schluss gezogen, dass der sachlich relevante Produktmarkt im vorliegenden Fall alle RDBMS umfasst. Aufgrund der Differenzierung von RDBMS sollten jedoch verschiedene Teilsegmente des Gesamtmarktes für RDBMS bei der Bewertung der Auswirkungen des Vorhabens auf die Wettbewerbssituation berücksichtigt werden.
2.2.Abgrenzung des räumlich relevanten Marktes
Die Anmelderin vertritt die Auffassung, dass es sich bei dem räumlich relevanten Markt um einen Markt mit weltweiter Ausdehnung handelt.
100In einer früheren Entscheidung gelangte die Kommission zu dem Schluss, dass es sich bei dem Markt für Datenbanken mindestens um einen EWR-weiten Markt, wahrscheinlich jedoch um einen weltweiten Markt handelt.
Die Marktuntersuchung in der vorliegenden Sache hat bestätigt, dass es sich bei dem räumlich relevanten Markt um einen Markt mit weltweiter Ausdehnung handelt, da die IT-Branche globaler Natur ist und Datenbanken überall erworben und genutzt werden können und jede beliebige Datenbanksoftware an jedem geografischen Standort lizenziert und installiert werden kann.
Bei dem räumlich relevanten Markt für RDBMS handelt es sich daher um einen Markt mit weltweiter Ausdehnung.
2.3.Schlussfolgerung zur Marktabgrenzung
Der relevante Markt im Rahmen dieses Beschlusses ist daher der weltweite RDBMS-Markt.
3.Merkmale und Struktur des Marktes
3.1.Marktgröße und Marktanteile
115.Der nach Einnahmen bemessene Wert des weltweiten RDBMS-Marktes belief sich 2006 auf rund 16,4 Mrd. USD, 2007 auf 18,8 Mrd. USD und 2008 auf 20,5 Mrd. USD. Bei den Einnahmen aus RDBMS ist ein erhebliches Wachstum zu verzeichnen. Unternehmen aus allen Wirtschaftssektoren stellen zunehmend höhere Anforderungen an die Verwaltung der Daten, die im Alltagsgeschäft erzeugt werden. Nach Aussage eines Branchenbeobachters war die steigende Nachfrage nach Datenbanken zwischen 2003 und 2007 „auf höhere Investitionen in Business Intelligence zum Zweck der Optimierung von Prozessen und der Entscheidungsfindung im Unternehmen, auf die Tatsache, dass ursprünglich zur Einhaltung von Gesetzen und Vorschriften dienende Datenverwaltungsprojekte nun auch zur Optimierung der Geschäftsführung genutzt wurden, sowie auf die schiere Zunahme von Geschäftsdaten sowohl im Hinblick auf ihren Umfang als auch auf das Speichervolumen, wodurch größere Datenbanken mit besseren Leistungsmerkmalen und höherer Skalierbarkeit erforderlich wurden, zurückzuführen“ [„driven by increasing investments in business intelligence aimed at streamlining processes and business decision making; data management projects used originally for compliance purposes, now also used for better business management; sheer growth of business data, in size and retained volume, requiring larger databases with better performance and scalability characteristics“].
116.Laut verschiedenen Berichten von Analytikern ist in den nächsten Jahren ein weiteres Wachstum der Einnahmen aus RDBMS zu erwarten. Obwohl die weltweite Wirtschaftskrise sich auf die Art und Weise ausgewirkt hat, in der Unternehmen ihr IT-Budget aufwenden, ist kein Rückgang der Investitionen zu erwarten, sondern vielmehr wird davon ausgegangen, dass die Investitionen in den nächsten Jahren konstant bleiben oder sogar steigen werden. Gartner berichtet, „ein Grund dafür liegt in der Erkenntnis des wahren Werts der IT und in nachweisbaren Ergebnissen aus dem Einsatz des Data Warehouse im Hinblick auf die Umgestaltung von Geschäftsprozessen (was u. a. zu höherer Produktivität und Rentabilität führt) sowie die Eröffnung neuer Geschäftschancen“ [„one reason for this is the realization of the real value of IT and demonstrable results from the use of the data warehouse to transform business process (increasing productivity and profitability) and to create new competitive business opportunities“].
117.Nach Schätzung von Forrester wird „der DBMS-Markt bis 2012 um jährlich 8 % wachsen, da Unternehmen neue Anwendungen in Betrieb nehmen, vorhandene Anwendungen erweitern und ein immer größeres Datenvolumen zu bewältigen haben“ [„the DBMS market will grow at 8% annually through 2012 as enterprises deploy new applications, expand existing ones, and deal with increasing data volume“].
Gartner und IDC geben auf Grundlage der Einnahmen von 2008 die folgenden weltweiten Marktanteile an:
99.Siehe Gartner-Bericht „RDBMS Software Market Surpasses $17 Billion in 2007“ (doc_ID 162).
100.Siehe Entscheidung der Kommission vom 19. Juni 2001 in der Sache M.2460 – IBM/Informix.
101.IDC, „Worldwide RDBMS vendor analysis“, S. 4 (doc_ID 600).
102.IDC, „2007 vendor analysis“, S. 4 (doc_ID 602).
103.Antwort von Oracle auf das an Oracle gerichtete Auskunftsersuchen vom 25. September 2009, S. 5 (doc_ID 2123).
36
37
38
Tabelle 2: Marktanteile der Datenbankanbieter bezogen auf die Einnahmen
Gartner IDC Datenbankanbieter Einnahmen Marktanteil Einnahmen Marktanteil (Mio. USD) (Mio. USD) [40-50]* % [40-50]* %[…] * […]* […]* [20-30]* % […]* [20-30]* % […]* […]* [10-20]* % [10-20]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* % [5-10]* % [5-10]* % 100 % 100 %
IBM
Microsoft
Sybase
[…] *
[…] *
[…] *
[…] *
[18.000 – 20.000]*
Quelle: Gartner – „Database worldwide shares by vendor“ – 2008 IDC – „Worldwide Database Management Systems 2009-2013 Forecast and 2008 Vendor Shares“ – Juli 2009
[…] *
[…] *
[…] *
[20.000 – 22.000]*
Teradata
Sun (MySQL)
Sonstige
Insgesamt
119.Der Datenbankmarkt ist in hohem Maße konzentriert: Oracle, IBM und Microsoft kontrollierten, bezogen auf die Einnahmen 2008, zusammen rund [80-90]* % des Marktes.
120.Während der nach den Einnahmen bemessene Anteil von Oracle am Gesamtmarkt für Datenbanken für 2008 auf zwischen [40-50]* % und [40-50]* % geschätzt wird, erscheint der Marktanteil von Sun mit MySQL bei der Berechnung auf Grundlage der Einnahmen gering.
121.Allerdings spiegeln auf Grundlage der Einnahmen ermittelte Marktanteile die Wettbewerbsposition von MySQL und anderen Open-Source-RDBMS auf dem Markt nicht in angemessener Weise wider. Da MySQL vorwiegend kostenlos unter einer GPL-Lizenz vertrieben wird, werden durch die Mehrheit der Installationen keine direkten Einnahmen für Sun generiert. Direkte Einnahmen werden in begrenztem Maße durch kommerzielle Lizenzen und Abonnements sowie durch Supportdienstleistungen erzielt.
122.Andererseits stehen keine Daten zu der anhand von aktiven Installationen bemessenen Gesamtgröße des Datenbankmarktes zur Verfügung, da Open-Source-Anbieter nicht nachprüfen können, ob die Open-Source-Datenbank nach dem Download tatsächlich installiert und genutzt wird. Nach Aussage der Anmelderin ist Sun zwar die Anzahl von Downloads von MySQL bekannt (rund 60.000 Downloads pro Tag), jedoch verfügt das Unternehmen nicht über präzise Informationen über die tatsächliche Anzahl von MySQL-Installationen. Sun schätzt, dass es 11 Mio. aktive Installationen von MySQL gibt.
123.Daneben ist laut Gartner MySQL die am häufigsten genutzte Open-Source-Datenbank. Insgesamt steht MySQL unter allen genutzten Datenbanken an dritter Stelle hinter Microsoft SQL Server und Oracle, jedoch vor IBM DB2 und Sybase.
124.Im Rahmen ihrer Untersuchung wurden der Kommission auch Beweise in Form einer von einem unabhängigen Marktforschungsunternehmen durchgeführten Erhebung vorgelegt, welche die zunehmende Nutzung von MySQL unter Entwicklern und IT-Managern in der Region EMEA (Europa, Nahost und Afrika) belegt. Im Rahmen der Erhebung gaben in der Region EMEA 2009 insgesamt 45,6 % der Befragten an, dass MySQL die Datenbank war, die sie im vergangenen Jahr am häufigsten genutzt hatten. Damit lag MySQL an zweiter Stelle hinter Microsoft SQL mit 48,3 %, gefolgt von Oracle auf einem weit abgeschlagenen dritten Platz mit 25,7 %. Die Auswertung derselben Frage unter dem Gesichtspunkt der Unternehmensgröße ergab, dass in Unternehmen mit mehr als 1.000 Mitarbeitern am häufigsten Oracle und Microsoft genutzt wurden (43,9 %), während bei kleineren Unternehmen mit weniger als 100 Mitarbeitern MySQL vorherrschte (54,4 %).
125.Laut derselben Erhebung ist MySQL die am häufigsten genutzte Datenbank bei Entwicklern angepasster Anwendungen, Systemintegratoren und Wiederverkäufern (Value Added Reseller, VAR), wobei 55 % der Entwickler MySQL und 49 % Microsoft SQL Server nannten. Auch von unabhängigen Softwareanbietern (Independent Software Vendor, ISV) und Originalgeräteherstellern (Original Equipment Manufacturer, OEM) wird MySQL häufig genutzt.
126.Die zunehmende Nutzung von MySQL in der Entwicklercommunity wird auch durch Kommentare auf der MySQL-Website belegt, denn dort heißt es, „MySQL hat laut dem Marktforschungsunternehmen Evans Data in zwei Jahren um 25 % zugelegt. Der Marktanteil ist von 32 % 2004 auf 40 % 2006 gestiegen.“ [„according to Evans Data research firm, MySQL has gained 25% in two years. Its market share has increased from 32% in 2004 to 40% in 2006“].
127.All diese Aspekte lassen den Schluss zu, dass die Bedeutung von MySQL für den Wettbewerb viel größer ist, als der sehr geringe auf Grundlage der Einnahmen bemessene Marktanteil vermuten lässt. Folglich wäre die Marktstellung aller anderen Unternehmen, u. a. Oracle, schwächer, als aus ihren auf Grundlage der Einnahmen bemessenen Marktanteilen abzulesen ist.
3.2.Marktzutrittsschranken
128.Der RDBMS-Markt ist durch verschiedene Zutrittsschranken im Zusammenhang mit der Technologie, der Erfordernis, sich durch Zuverlässigkeit einen Namen zu machen, sowie den hohen Umstellungskosten gekennzeichnet, die Kunden bei der Migration ihrer Daten zu einem anderen Datenbankprodukt zu tragen haben.
129.Die grundlegende Technologie, auf der RDBMS aufbauen, wurde in den 70er-Jahren erfunden und bildet nach wie vor den Kern der Produkte von RDBMS-Anbietern. Dies bedeutet jedoch nicht, dass es bei Datenbankprodukten keine Innovationen gäbe. Die Datenbankbranche muss sich fortlaufend auf immer höhere und sich wandelnde Anforderungen an Datenbanken einstellen.
130.Die Unternehmen, die gegenwärtig mit proprietären Produkten auf dem Markt vertreten sind (Oracle, IBM, Microsoft), investieren und forschen seit 20 bis 30 Jahren auf diesem Gebiet, wodurch sie die ausgereiften, hoch anspruchsvollen Produkte entwickeln konnten, die sie heute auf dem Markt anbieten. Bei der Entwicklung von Datenbanken sind hohe, langfristige Investitionen erforderlich, um schrittweise Verbesserungen bei Geschwindigkeit, Zuverlässigkeit und Sicherheit zu erzielen.
131.Das Flaggschiffprodukt von Oracle, Oracle Database 11g (2007), ist das Ergebnis einer schrittweisen Weiterentwicklung der Vorgängerversionen 10g (2003) und 9i (2001). Oracle selbst trug vor, das Unternehmen „hat die meisten bedeutenden Innovationen in der Datenbanktechnologie in den letzten dreißig Jahren herbeigeführt, hat zweistellige Milliardenbeträge in die Entwicklung von Datenbanktechnologien investiert und beschäftigt die meisten Datenbankentwickler weltweit“ [„is responsible for most of the major innovations in database technology over the past thirty years, has spent tens of billions developing database technologies and has the largest group of database developers in the world“].
132.Infolgedessen hat es in den letzten Jahren keinen bedeutenden Neuzugang auf dem Markt oder Rückzug vom Markt gegeben.
133.Die Ergebnisse der Marktuntersuchung haben gezeigt, dass Datenbanksoftware von zentraler Bedeutung ist und daher zuverlässig arbeiten muss, insbesondere in erfolgskritischen Anwendungen. Einer der Faktoren, die es den drei wichtigsten Anbietern von Datenbanken (Oracle, IBM und Microsoft) erlauben, ihre Marktstellung zu behaupten, ist die Risikoaversion bestimmter Unternehmen und ihre Loyalität gegenüber den großen Datenbankanbietern, die als Garanten für höhere Zuverlässigkeit und besseren Support wahrgenommen werden. Diesen Faktor bezeichnet Oracle als „anbieterseitige Hürde bei der Verbreitung“ [„vendor barrier to adoption“].
134.Die Ergebnisse der Marktuntersuchung bestätigen, dass es einen gewissen „Widerstand“ gibt: RBS äußerte im Hinblick auf die eigene Infrastruktur die Erwartung, „die großen Anbieter (z. B. IBM, Oracle und Microsoft) werden sich den Support- und Servicevorschlägen stellen. Open-Source-Lösungen können genutzt werden, müssen jedoch von den Hauptakteuren unterstützt werden (vergleichbar mit der Art und Weise, in der Linux sich verbreitet hat)“ [„[…] the major vendors (e.g. IBM, Oracle, Microsoft) to underwrite the support and service propositions. Open Source solutions can be deployed but they need to be endorsed by the major players (much in the same way Linux has become widely adopted)“].
135.Es ist zu beachten, dass Entwickler von RDBMS-Anbietern häufig als wichtige Akteure angesehen werden, da sie für Innovationen offen sind und mit neuen Produkten experimentieren und somit u. U. die Kaufentscheidungen in den Unternehmen, in denen sie tätig sind, beeinflussen. Eine besonders wichtige Rolle spielen Entwickler bei der Einführung von Open-Source-Produkten. Normalerweise wird ein Open-Source-Produkt zunächst in geringem Umfang ausprobiert und kann seine Vorteile unter Beweis stellen, bevor es aufgrund dieser Vorteile umfassender eingeführt wird.
136.Die Migration zu einer neuen Datenbank ist in den meisten Fällen mit hohem Aufwand und hohen Kosten verbunden. Die folgenden Schritte sind bei einer Migration auszuführen (in umgekehrter Reihenfolge nach Wichtigkeit aufgeführt):
Verschieben der eigentlichen Daten. Die Daten selbst sind der wichtigste Vermögenswert, da sie i. d. R. die zentralen Informationen des Unternehmens umfassen, z. B. Kundendaten, Nutzerdaten, Rechnungsinformationen, Forschungsdaten, Konten usw. Im schlimmsten Fall müssen Daten manuell neu erstellt oder geändert werden, was für ein Unternehmen möglicherweise aus Kostengründen nicht in Frage kommt, insbesondere dann, wenn viele Terabyte Daten vorhanden sind.
Portieren oder Neuerstellen der Schemata, die den Inhalt der Daten und die Beziehungen zwischen den Daten für den Datenbankverwalter beschreiben. Zwar sorgen Standards (wie SQL2003) für große Übereinstimmungen zwischen Datenbankschemasprachen, jedoch ist in keinem RDBMS der gesamte Standard umgesetzt und in allen RDBMS sind spezielle Erweiterungen implementiert. Aus diesem Grund ist es außer in ganz einfachen Fällen nicht möglich, einfach ein Schema von einer Datenbank in eine andere zu kopieren. Normalerweise müssen bei jeder Migration alle Schemadefinitionen Zeile für Zeile manuell untersucht werden. Eine Inkompatibilität der Schemasprachen (wobei ein Schema, grob definiert, Elemente wie gespeicherte Prozeduren und Trigger umfasst) stellt bereits ein Hindernis für die Migration von einem RDBMS zu einem anderen dar, wobei der Lizenzierungsstatus unerheblich ist.
117Siehe Antwort von RBS auf Frage 17 des an Datenbankkunden gerichteten Auskunftsersuchens vom 31. Juli 2009 (doc_ID 643).
118Siehe Antwort von Renault auf das an Datenbankkunden gerichtete Auskunftsersuchen vom 17. September 2009 (doc_ID 1831).
119Siehe z. B. das von Sun vorgelegte Dokument mit dem Titel „Preliminary Comments from Greg Papadopoulos (CTO, Sun) on Monty Program AB's Submission on Disruptive Innovation“ (doc_ID 2900).
120Der TAEUS-Bericht gibt in diesem Zusammenhang an, dass die wirkungsvollste Möglichkeit, einen Kunden von der Migration zu einem anderen RDBMS abzuhalten, darin besteht, die Daten des Kunden an das vorhandene System zu binden (doc_ID 3011).
Neuerstellen der Software zur Verwaltung der Datenbankinfrastruktur, z. B. Lastenausgleich, Clusterbildung, Replikation und Backup. Diese Infrastruktur ist in keiner Weise standardisiert und muss aller Wahrscheinlichkeit nach für eine neue Datenbank von Grund auf neu erstellt werden, es sei denn, ein Nutzer verwendet zufällig Produkte, die mehr als nur ein RDBMS-Produkt unterstützen. Für ein einfaches RDBMS, das nur einmal auf einem Server ausgeführt wird, ist dies i. d. R. eine einfache Aufgabe. In einem großen Unternehmen oder bei einer Website mit einem Cluster aus Dutzenden von Datenbankservern mit Lastenausgleich, Replikation, Hotswapping, geografischer Verteilung und anderen Merkmalen hingegen ist diese Aufgabe u. U. mit sehr hohem Aufwand verbunden.
Darüber hinaus sind IT-Mitarbeiter oder DBAs üblicherweise speziell für die Unterstützung eines Typs von Datenbanksystem im Unternehmen geschult: Umschulungen oder Neueinstellungen sind für jedes Unternehmen kostspielig. Daher bevorzugen Kunden nach der Einführung des Produkts tendenziell ein „stabiles“ Modell, bei dem einfach die Lizenz verlängert wird und die interne wie externe Unterstützung unverändert bleibt. Selbst wenn seine Anforderungen steigen, wendet sich der Kunde eher zwecks Erweiterung (Skalierung) des vorhandenen RDBMS an den ursprünglichen Anbieter, als sich nach einem anderen Angebot umzusehen. Da sich die Datenbank im Zentrum des IT-Systems befindet, hängen alle Typen von Unternehmensanwendungen von dem Datenbanksystem ab. Dadurch entsteht eine „Erbmasse“ im Datenbankbereich, „Legacy“ genannt, welche die Bindung an einen Anbieter fördert.
Datenbankkunden entscheiden sich deshalb nur selten für eine Migration ihrer vorhandenen Datenbanken. Somit überrascht es nicht, dass mehrere der im Rahmen der von der Kommission durchgeführten Marktuntersuchungen befragten Unternehmen auf die bei einer Datenbankmigration anfallenden hohen Umstellungskosten und die dabei entstehenden Schwierigkeiten hingewiesen haben.
3.3.Ausgereiftheit des Datenbankmarkts
3.3.1.Komplexität der Datenbankprodukte
139.Proprietäre Datenbanken haben inzwischen ein sehr hohes technisches Niveau erreicht, das nicht unbedingt dem Bedarf aller Kunden entspricht. Einige Kunden haben zwar durchaus extrem hohe Anforderungen, die nur durch die erweiterten Funktionsmerkmale proprietärer Datenbanken erfüllt werden können, jedoch scheint es, als würden andere Kunden Produkte mit komplizierten, nicht benötigten Funktionsmerkmalen erwerben, die hohe Gesamtbetriebskosten verursachen.
121TAEUS-Bericht, S. 81 ff. (doc_ID 3011).
122Dies ist ein spezielles Funktionsmerkmal, mit dem die Arbeitslast gleichmäßig auf zwei oder mehr Computer, Netzwerkverbindungen, CPUs, Festplatten oder andere Ressourcen verteilt wird, um die Ressourcen optimal zu nutzen, den Durchsatz zu maximieren, möglichst kurze Reaktionszeiten zu erzielen und Überlastungen zu vermeiden.
123Beim Hotswapping können Komponenten ohne Unterbrechung des Systembetriebs ausgetauscht werden.
124Siehe die Antworten auf Frage 12 des an Datenbankkunden gerichteten Auskunftsersuchens vom 31. Juli 2009, insbesondere die Antworten von Ericsson (doc_ID 688); Sabre (doc_ID 1104); Google (doc_ID 1147); Aruba (doc_ID 795); Vodafone (doc_ID 819); France Telecom (doc_ID 757) und Citigroup (doc_ID 951).
In einem von einem Wettbewerber vorgelegten MySQL-Dokument wird erläutert, „Anbieter proprietärer Datenbanken fügen seit Jahren neue Funktionsmerkmale hinzu, die, wenn überhaupt, nur selten genutzt werden. [...] Diese fortlaufende Erweiterung um unnötige Funktionsmerkmale hat zu übermäßig komplizierten Systemen geführt, die langsamer, ressourcenintensiver, schwieriger zu warten und fehleranfälliger sind.“ [„[F]or years, proprietary database companies have been adding new features that are seldom, if ever, used. […] the continued addition of unnecessary features has resulted in overly complicated systems that are slower, more resource intensive, harder to maintain and more prone to failure“].
126Oracle selbst […]*
3.3.2.Margen bei Anbietern proprietärer Datenbanken
142Die Anbieter proprietärer Datenbanken erzielen gegenwärtig sehr hohe Margen beim Verkauf von Datenbanken. Ein Hinweis auf die Margen von Oracle findet sich in einem internen Dokument von Oracle, in dem das prognostizierte Ergebnis vor Zinsen und Steuern (EBIT) für die vergangenen 12 Monate (LTM) mit insgesamt 46,2 % für 2009 beziffert wird. Zwei Beschwerdeführer geben die Bruttomargen von Oracle bei den Supportdienstleistungen für Datenbanken mit rund 90 % an. Ferner betont einer dieser Beschwerdeführer unter Anführung eines Zitats von Safra Catz, Co-President von Oracle, dass Oracle aus Supportdienstleistungen besonders hohe Einnahmen erzielt.
3.3.3.Erwartung in Bezug auf die weitere Verbreitung von Open-Source-Datenbanken
Sowohl Gartner als auch Datamonitor haben in den letzten Jahren ein vermehrtes Interesse an relationalen Datenbank-Managementsystemen auf Open-Source-Basis festgestellt. Laut Gartner werden Open-Source-Datenbanken immer häufiger eingesetzt. Zwischen 2007 und 2008 stiegen die Einnahmen der Anbieter von Open-Source-RDBMS um 49,2 %, verglichen mit einem Gesamtmarktwachstum von 11,9 % und einem Vorjahresniveau von 42,4 %. Allerdings haben Open-Source-RDBMS bemessen an den Einnahmen nur einen Anteil von rund 0,84 % am Gesamtmarkt für RDBMS. Gartner geht ferner davon aus, dass sich das Wachstum von Open-Source-RDBMS fortsetzen wird und die Einnahmen aus Open-Source-Datenbanken bis 2014 auf über 1 Mrd. USD steigen werden. Dies weist auf eine Tendenz zur vermehrten Nutzung der Open-Source-Produkte im geschäftlichen Umfeld hin, denn „die einzigen Unternehmen, die ein Interesse an Abonnementsupport haben, würden diesen für Produktionsanwendungen nutzen“ [„the only parties interested in subscription support would be using it for production applications“].
Die ausschlaggebenden Faktoren für eine verstärkte Nutzung von Open-Source-Datenbanken sind i) die höhere technische Reife der Open-Source-DBMS-Engines, ii) die Verfügbarkeit von Managementsoftware und iii) geringere Gesamtbetriebskosten.
Laut Datamonitor blicken Kunden, die eine in hohem Maße transaktionsorientierte Lösung für ein erfolgskritisches Umfeld benötigen, auf dem ausgereiften RDBMS-Markt „nicht über die gängigen kommerziellen Angebote von Microsoft, IBM und Oracle hinaus. Allerdings ist der Markt für Open-Source-Datenbanken inzwischen ein fruchtbarer Boden für die Erfüllung der nächsten Stufe von Anforderungen und ermöglicht in vielen Fällen die weitere Verwendung von im Laufe der Jahre entwickelten Anwendungen, die erfolgskritisch, von großem Umfang und hoch leistungsfähig sind. Ein Grund dafür ist die technische Reife der Open-Source-Produkte selbst.“ [„typically look no further than the current major commercial offerings from Microsoft, IBM, and Oracle. However, the open source database market has become fruitful ground for the next tier of requirements and in many cases is still running applications developed over the years that are business critical, of significant scale, and high performance. One reason for this is the maturity of the open source products themselves.“]
Vereinbarkeit des Zusammenschlusses im Datenbankbereich mit dem Gemeinsamen Markt
Der vorliegende Abschnitt ist wie folgt strukturiert:
– In Abschnitt 4.1 werden die Auffassungen der Anmelderin dargelegt.
– In Abschnitt 4.2 werden die rechtlichen Voraussetzungen und deren Anwendung auf die Besonderheiten des weltweiten Datenbankmarktes dargelegt.
– In Abschnitt 4.3 wird die Wettbewerbssituation vor dem Zusammenschluss analysiert.
– In Abschnitt 4.4 wird die Wettbewerbssituation nach dem Zusammenschluss bewertet.
4.1.Auffassung der Anmelderin
147.Oracle ist der Auffassung, der geplante Zusammenschluss werde keine wettbewerbswidrigen Auswirkungen auf den Datenbankmarkt haben.
148.Der Ausgangspunkt der Erwägungen von Oracle ist, dass es nur zu wettbewerbswidrigen Auswirkungen kommen könne, wenn Oracle und MySQL in engem Wettbewerb miteinander stünden. In der Anmeldung stellt Oracle fest, dass bedeutende nicht koordinierte Wirkungen nur möglich seien, wenn die beteiligten Unternehmen miteinander in besonders engem Wettbewerb um eine große Kundengruppe stünden.
133Formblatt CO, Seite 88.
43
149.Oracle ist der Auffassung, die beteiligten Unternehmen stünden in keinem engen Wettbewerb miteinander und ihre jeweiligen Produkte würden entgegengesetzte Marktsegmente bedienen. Oracle und MySQL würden kaum miteinander um dieselben Datenanwendungen konkurrieren. Ferner seien in den wenigen Segmenten des Datenbankmarktes, in denen MySQL und Oracle tatsächlich miteinander im Wettbewerb stünden, zahlreiche bedeutende Wettbewerber präsent. Oracle trägt ferner vor, aufgrund der Open-Source-Natur von MySQL-Datenbanken nicht in der Lage zu sein, nach dem Zusammenschlussvorhaben MySQL abzuwerten, und zudem keinerlei Anreiz zu haben, MySQL zu schaden oder das Produkt abzuwerten.
150.Oracle machte im Formblatt CO geltend, die geeignete Marktabgrenzung im Datenbankbereich sei ein alle Datenbankprodukte umfassender Gesamtmarkt, und verwies in erster Linie auf von Gartner und IDC bereitgestellte Marktinformationen, die auf Einnahmen basieren. Neben den beteiligten Unternehmen, deren geschätzte Marktanteile 48,9 % bzw. 43,5 % (Oracle) und 0,4 % bzw. 0,2 % (MySQL) betragen, führen Gartner und IDC IBM (21,9 % bzw. 21,7 %) und Microsoft (16,6 % bzw. 19,5 %) als wichtigste Wettbewerber an. Außerdem werden Sybase und Teradata mit Marktanteilen unter 5 % genannt. Im Hinblick auf die Marktstellung von MySQL gibt Oracle an, die Gesamtzahl von MySQL-Installationen nicht schätzen zu können, erinnert jedoch daran, dass Sun die Gesamtzahl der aktiven Installationen auf 11 Millionen schätzt. Als Wettbewerber, die Open-Source-Alternativen zu MySQL anbieten, nennt Oracle Ingres und PostgreSQL.
151.Bezüglich des Konzentrationsgrads des Marktes führt Oracle an, dass der Herfindahl-Hirschman Index (HHI) laut Daten von IDC nach dem Zusammenschluss bei rund 2809 liegen würde, wobei das HHI-Delta 27 betragen würde. Oracle verwies darauf, dass sich der Kommission bei einem Deltawert unter 150 i. d. R. keine horizontalen Wettbewerbsbedenken stellen.
152.Oracle macht ferner geltend, dass das Zusammenschlussvorhaben selbst dann, wenn ein Wettbewerb zwischen den Datenbankangeboten von Oracle und MySQL festgestellt würde, aufgrund der Eigenschaften von MySQL als Open-Source-Produkt keine wettbewerbswidrigen Auswirkungen auf den Datenbankmarkt hätte. Aufgrund der GPLv2-Lizenz würde Oracle durch das Zusammenschlussvorhaben nicht in die Lage versetzt, den Output zu reduzieren, da der Open-Source-Code von MySQL bereits außerhalb des Einflussbereichs von Sun liegt. Sollte Oracle die Weiterentwicklung von MySQL einstellen oder MySQL abzuwerten versuchen, so würde sich MySQL sehr wahrscheinlich von einem unternehmensgeführten zu einem communitygeführten Open-Source-Projekt nach Art von Linux entwickeln. Alternativ könnten MySQL-Nutzer zu Unternehmen, die Ableger von MySQL wie MariaDB oder Percona anbieten, abwandern oder andere Open-Source-Produkte einsetzen. Zudem könnte Oracle die Entwicklung von Ablegernvon MySQL nicht verhindern und die Anbieter solcher Ableger würden tragfähige Geschäftsmodelle entwickeln, ohne kommerzielle Lizenzen zu benötigen.
153.Seine Anreize betreffend führt Oracle an, dass eine Abwertung von MySQL einen erheblichen Schaden für Oracle nach sich ziehen würde, da das Ansehen des Unternehmens leiden würde und viele Unternehmen, die sowohl die Produkte von Oracle als auch die von MySQL nutzen, ihre grundsätzliche Loyalität gegenüber Oracle überdenken würden, und zwar im Hinblick auf alle Oracle-Produkte.
154.Oracle bekräftigte in seiner Erwiderung auf die Mitteilung der Beschwerdepunkte viele seiner Beschwerden. Das Unternehmen betonte, MySQL übe keinen bedeutenden Wettbewerbsdruck auf die Datenbankprodukte von Oracle aus, sondern sei eher ein Ergänzungsprodukt. Zur Untermauerung seiner Position führte Oracle zahlreiche Zitate aus Analytikerberichten und Antworten von Kunden auf die Auskunftsersuchen der Kommission an. Oracle legte ferner die Ergebnisse einer Analyse vor, die seiner Meinung nach zeigen sollten, dass die Datenbanken von Oracle und MySQL unterschiedliche Anforderungen im Zusammenhang mit der Arbeitslast erfüllen und warum aufgrund der Architektur von MySQL nicht zu erwarten sei, dass sich ein engerer Wettbewerb zwischen MySQL und Oracle Database 11g entwickeln könne, da letztere in erster Linie für Unternehmensanwendungen konzipiert sei.
4.2.Rechtliche Voraussetzungen und deren Anwendung auf die Besonderheiten des weltweiten Datenbankmarktes
155.Gemäß Artikel 2 Absatz 2 und 3 der EG-Fusionskontrollverordnung hat die Kommission zu prüfen, ob durch ein Zusammenschlussvorhaben wirksamer Wettbewerb im Gemeinsamen Markt oder in einem wesentlichen Teil desselben erheblich behindert würde, insbesondere durch Begründung oder Verstärkung einer beherrschenden Stellung.
156.In den Leitlinien der Kommission zur Bewertung horizontaler Zusammenschlüsse im Rahmen der Verordnung des Rates über die Kontrolle von Unternehmenszusammenschlüssen („Horizontale Leitlinien“) wird zwischen zwei wesentlichen Arten unterschieden, auf die Zusammenschlüsse zwischen tatsächlichen oder potenziellen Wettbewerbern auf demselben relevanten Markt den wirksamen Wettbewerb erheblich behindern können, nämlich nicht koordinierten Wirkungen und koordinierten Wirkungen. Nicht koordinierte Wirkungen können den wirksamen Wettbewerb erheblich behindern, indem wichtiger Wettbewerbsdruck für ein oder mehrere Unternehmen beseitigt wird, die dadurch ihre Marktmacht erhöhen, ohne auf ein koordiniertes Verhalten zurückgreifen zu müssen. In dieser Hinsicht werden in den horizontalen Leitlinien nicht nur der unmittelbare Verlust des Wettbewerbs zwischen den fusionierenden Unternehmen, sondern auch der möglicherweise durch die Fusion bedingte Rückgang des Wettbewerbsdrucks auf die übrigen Unternehmen des betreffenden Marktes genannt.
157.Die horizontalen Leitlinien enthalten eine Auflistung von Faktoren, die u. U. beeinflussen können, ob spürbare nicht koordinierte Wirkungen von einem Zusammenschluss zu erwarten sind, so z. B. hohe Marktanteile der fusionierenden Unternehmen, die Tatsache, dass die fusionierenden Unternehmen nahe Wettbewerber sind, die begrenzten Möglichkeiten für Kunden, zu einem anderen Anbieter überzuwechseln, oder die Beseitigung einer wichtigen Wettbewerbskraft durch den Zusammenschluss. Diese Liste von Faktoren ist jedoch keine erschöpfende Aufzählung. Ferner müssen nicht alle Faktoren gegeben sein, damit spürbare horizontale Wirkungen angenommen werden können.
158.In den horizontalen Leitlinien wird ferner anerkannt, dass bestimmte Unternehmen trotz eines relativ geringen Marktanteils eine wichtige Wettbewerbskraft darstellen können. Ein Zusammenschluss unter Beteiligung eines solchen Unternehmens könnte die Wettbewerbsdynamik in einer spürbar wettbewerbswidrigen Weise verändern, insbesondere, wenn es sich um einen bereits konzentrierten Markt handelt. Dies kommt bei der Bewertung des Zusammenschlussvorhabens in der vorliegenden Sache besonders zum Tragen.
159.Abschließend vergleicht die Kommission laut den horizontalen Leitlinien bei der Bewertung der wettbewerblichen Auswirkungen eines Zusammenschlusses die Wettbewerbsbedingungen, die sich aus der angemeldeten Fusion ergeben, mit den Bedingungen, wie sie ohne den Zusammenschluss herrschen würden. Zur Klärung der Frage, ob der Zusammenschluss eine bedeutende Änderung der Marktbedingungen verursachen würde, muss die Kommission daher eine vorausschauende Analyse durchführen, in der sie die Perspektiven für den Wettbewerb nach einem möglichen Zusammenschluss mit den Perspektiven ohne den Zusammenschluss vergleicht.
160.In der vorliegenden Sache erachtet Oracle die Schadenstheorie der Kommission als ungewöhnlich, ohne Präzedenz und letztlich nach der EG-Fusionskontrollverordnung unrechtmäßig.
161.Insbesondere behauptet Oracle, die Kommission habe sich bislang fast immer darauf konzentriert, eine beherrschende Stellung und die Intensität des Wettbewerbs nachzuweisen, wohingegen sie in der vorliegenden Sache keinen von beiden Aspekten nachzuweisen versuche. Laut Oracle hätte ein Zusammenschluss selbst in den Fällen, in denen die Kommission ihre Schadenstheorie auf der Beseitigung einer wichtigen Wettbewerbskraft durch die Übernahme eines Einzelgängers aufgebaut habe, eine beherrschende Stellung begründet oder verstärkt oder der Einzelgänger sei ein naher Wettbewerber des erwerbenden Unternehmens gewesen. Ferner trägt Oracle vor, in den horizontalen Leitlinien seien nur zwei Faktoren genannt, die möglicherweise eine wichtige Wettbewerbskraft begründen, nämlich, dass der Einzelgänger entweder ein jüngst in den Markt eingetretenes Unternehmen, von dem zu erwarten ist, dass es in Zukunft spürbaren Wettbewerbsdruck ausübt, oder ein innovatives Unternehmen ist. Oracle bekräftigt, dass in der vorliegenden Sache keine dieser Voraussetzungen erfüllt sei.
162.Die Kommission ist der Auffassung, dass die im vorliegenden Beschluss dargelegte Schadenstheorie vollständig mit den rechtlichen Voraussetzungen gemäß der EG-Fusionskontrollverordnung und den horizontalen Leitlinien im Einklang steht.
163.Erstens ist die Kommission gemäß der neuen vertieften Prüfung, die durch die neugefasste EG-Fusionskontrollverordnung eingeführt wurde (vgl. Artikel 2 Absatz 2 und 3), nicht mehr in allen Fällen verpflichtet, die Begründung oder Verstärkung einer beherrschenden Stellung nachzuweisen, um einen Zusammenschluss für mit dem Gemeinsamen Markt unvereinbar zu erklären. Wie in den horizontalen Leitlinien ausdrücklich festgestellt, muss die Kommission bei ihrer Bewertung jede erhebliche Behinderung eines wirksamen Wettbewerbs berücksichtigen, die als Folge eines Zusammenschlusses zu erwarten ist. Wie in der EG-Fusionskontrollverordnung erläutert, können über das Konzept der beherrschenden Stellung hinaus Zusammenschlüsse, die zur Beseitigung wichtiger Wettbewerbszwänge, die von den fusionierenden Parteien vorher gegeneinander ausgeübt wurden, sowie zu einer Verringerung des Wettbewerbsdrucks auf die verbleibenden Wettbewerber führen, selbst bei geringer Wahrscheinlichkeit einer Abstimmung zwischen den Mitgliedern des Oligopols eine erhebliche Behinderung des Wettbewerbs darstellen.
164.Zweitens muss die Kommission entgegen den Behauptungen von Oracle nicht zum Zweck der Bewertung des vorliegenden Falls dartun, dass die beteiligten Unternehmen auf dem relevanten Markt die wichtigsten Wettbewerber füreinander sind. Die Intensität des Wettbewerbs ist nur einer der in den horizontalen Leitlinien genannten Faktoren, die u. U. beeinflussen können, ob spürbare nicht koordinierte Wirkungen von einem Zusammenschluss zu erwarten sind.
165.Drittens ist aus den horizontalen Leitlinien ebenfalls entgegen dem Vortrag von Oracle nicht abzuleiten, dass ein Zielunternehmen eines Zusammenschlusses nur dann eine wichtige Wettbewerbskraft darstellt, wenn es erst jüngst in den Markt eingetreten oder innovativ tätig ist. Aus dem Wortlaut des relevanten Abschnitts der horizontalen Leitlinien geht klar hervor, dass die dort aufgeführten Faktoren oder Szenarien lediglich als Beispiele für Zusammenschlüsse angeführt werden, durch die eine wichtige Wettbewerbskraft beseitigt wird. Diese Liste ist nicht als eine erschöpfende Aufzählung anzusehen. Zwar wird in den horizontalen Leitlinien der analytische Ansatz der Kommission bei ihrer Bewertung horizontaler Fusionen erläutert, jedoch können nicht alle möglichen Ausprägungen dieses Ansatzes aufgezeigt werden.
166.Im Rahmen des geplanten Zusammenschlusses würde Oracle, der größte und stärkste Anbieter von proprietären Datenbanken, der erhebliche Marktmacht besitzt, MySQL als die größte Open-Source-Datenbank übernehmen.
167.Insgesamt muss die Kommission unter Anwendung der rechtlichen Voraussetzungen auf den geplanten Zusammenschluss bewerten, ob dieser den wirksamen Wettbewerb spürbar behindern könnte, indem wichtiger Wettbewerbsdruck beseitigt würde, insbesondere auf die Anmelderin, die dadurch ihre Marktmacht erhöhen würde. Daher muss die Kommission in ihrer eingehenden Untersuchung für die Zwecke des vorliegenden Beschlusses die Art und das Maß des von MySQL vor dem geplanten Zusammenschluss ausgeübten Wettbewerbsdrucks untersuchen sowie prüfen, inwiefern dieser Wettbewerbsdruck nach dem Zusammenschluss beseitigt würde und in welchem Maße andere tatsächliche oder potenzielle Wettbewerber auf dem Datenbankmark nach dem Zusammenschluss Wettbewerbsdruck auf Oracle ausüben würden.
Die vorliegende Sache weist besondere Aspekte auf, die insbesondere auf den Open-Source-Charakter von MySQL zurückzuführen sind und die Bewertung jeder dieser Fragen beeinflussen:
-- Erstens untersuchte die Kommission unter Berücksichtigung der Besonderheiten des Datenbankmarktes und der Marktstellung von Oracle, ob MySQL möglicherweise aufgrund seines Open-Source-Charakters einen besonderen Wettbewerbsdruck auf Oracle und andere Anbieter proprietärer Datenbanken ausübt und somit eine „wichtige Wettbewerbskraft“ darstellt.
-- Zweitens, obgleich bei jedem horizontalen Zusammenschluss anzunehmen ist, dass zwei Produkte, die bislang Konkurrenzprodukte waren, dies nach dem Zusammenschluss als Eigentum desselben Unternehmens nicht mehr sind, muss die Kommission für die Zwecke des vorliegenden Beschlusses in Anbetracht des Open-Source-Charakters von MySQL weiter gehen und bewerten, inwiefern Oracle in der Lage sein und sich dazu veranlasst sehen könnte, MySQL nach dem Zusammenschluss abzuwerten oder zu beseitigen.
-- Drittens muss sich die Kommission in Anbetracht der Art des möglicherweise von MySQL auf Oracle und andere Anbieter proprietärer Datenbanken ausgeübten Wettbewerbsdrucks zum Zwecke der Einschätzung der Wahrscheinlichkeit, dass nach dem Zusammenschluss der Wettbewerbsdruck zeitnah und in hinreichendem Maße durch einen Marktneuzugang ersetzt wird, bei ihrer Bewertung auf die verbleibenden Open-Source-Anbieter, insbesondere auf PostgreSQL, sowie auf die möglichen Neuzugänge von Ablegern von MySQL (oder die Bedrohung durch solche Ableger) konzentrieren.
-- Im Hinblick sowohl auf die wahrscheinlichen Möglichkeiten und Interessen von Oracle im Hinblick auf die Abwertung oder Beseitigung von MySQL als auch auf die Wahrscheinlichkeit, dass nach dem Zusammenschluss der Wettbewerbsdruck zeitnah und in hinreichendem Maße durch einen Marktneuzugang ersetzt wird, müssen die öffentlichen Ankündigungen von Oracle vom 14. Dezember, die am 11. Dezember 2009 an die Kommission übermittelt wurden, angesichts der Besonderheiten der Branche für Open-Source-Software ebenfalls berücksichtigt werden.
Art und Maß des vor dem Zusammenschluss von MySQL ausgeübten Wettbewerbsdrucks
169.Wie in Abschnitt 4.4 unten dargelegt, gelangt die Kommission auf der Grundlage aller in der Akte enthaltenen Unterlagen zur Schlussfolgerung, dass das Vorhaben den Wettbewerb auf dem Gemeinsamen Markt nicht erheblich beeinträchtigen wird, was den weltweiten Datenbankmarkt anbelangt.
Art und Ausmaß des von MySQL vor dem Zusammenschluss ausgeübten Wettbewerbsdrucks
170.Βezüglich der Situation vor dem Zusammenschluss (siehe Abschnitt 4.3) ergab die Untersuchung der Kommission, dass MySQL die größte Open-Source-Datenbank darstellt. Ferner besitzt MySQL anscheinend das Potenzial, einen wichtigen und zunehmenden Wettbewerbsdruck auf Oracle und andere Anbieter proprietärer Datenbanken auszuüben, was u. a. durch die spezielle modulare Architektur von MySQL, sein von niedrigen Preisen und dem Nichtbestehen einer Bindung an einen Anbieter gekennzeichnetes Geschäftsmodell und andere auf seinen Open-Source-Charakter zurückzuführende Vorzüge bedingt ist. Die Art dieses Wettbewerbsdrucks hat zudem einen dynamischen Aspekt, da die spezielle modulare Architektur von MySQL Innovationen durch Dritte begünstigt, die Speicher-Engines entwickeln, mit denen die Funktionalität von MySQL für bestimmte High-End-Anwendungen erweitert wird.
171.Die Untersuchung der Kommission ergab, dass MySQL in einigen wichtigen Segmenten (insbesondere im KMU-Segment oder Low-End-Segment und in einigen Teilen des Segments für eingebettete Datenbanken) potenziell einen starken Wettbewerbsdruck auf Oracle ausüben kann, jedoch übt MySQL nicht in allen Segmenten des Datenbankmarkts (insbesondere im High-End-Segment) Wettbewerbsdruck auf Oracle aus. In jedem Fall steht Oracle weiterhin dem Wettbewerbsdruck durch zahlreiche andere Anbieter proprietärer Datenbanken, darunter Microsoft, IBM und Sybase, gegenüber.
Für Oracle nach dem Zusammenschluss möglicherweise bestehende Möglichkeiten und Anreize zur Abwertung oder Beseitigung von MySQL
172.Auf die Möglichkeiten und Anreize von Oracle im Hinblick auf die wahrscheinliche Entwicklung von MySQL nach dem Zusammenschluss wird in Abschnitt 4.4.1 eingegangen.
173.Es ist zu erwarten, dass Oracle Database und MySQL nach dem Zusammenschluss nicht mehr miteinander konkurrieren würden, da sie von demselben Unternehmen angeboten würden. Es sind gewisse Bedenken geäußert worden, Oracle könnte MySQL nicht mehr unter einer GPL-Lizenz anbieten, die GPL-Version von MySQL abwerten oder nicht weiterentwickeln oder einen von Speicher-Engines von Drittanbietern ausgehenden Wettbewerbsdruck dadurch verhindern, dass die Schnittstelle geändert wird oder den Anbietern von Speicher-Engines die kommerziellen Lizenzen, die zur Vermarktung proprietärer Versionen von Speicher-Engines für MySQL erforderlich sind, nicht mehr erteilt werden.
174.Die Untersuchung der Kommission ergab jedoch, dass die wahrscheinlichen Möglichkeiten und Anreize für Oracle, MySQL nach der Übernahme von Sun durch Oracle als Wettbewerbskraft auf dem Datenbankmarkt zu beseitigen, aufgrund der Quelloffenheit von MySQL eingeschränkt wären.
175.In diesem Zusammenhang zieht die Kommission in ihrer Bewertung auch die öffentliche Ankündigung durch Oracle am 14. Dezember vor dem Hintergrund der Besonderheiten der Branche für quelloffene Software in Betracht. Besonders MySQL zeichnet sich durch ein dynamisches Ökosystem aus.
176.Nach der Anhörung in der vorliegenden Sache am 14. Dezember 2009 gab Oracle zehn Zusagen an die Nutzer, Kunden und Entwickler von MySQL öffentlich bekannt.
1. Weitere Verfügbarkeit von Speicher-Engine-APIs. Oracle wird die modulare Speicher-Engine-Architektur von MySQL pflegen und regelmäßig verbessern, sodass die Nutzer über die Flexibilität verfügen, um aus einem Portfolio nativer und von Drittanbietern angebotenen Speicher-Engines zu wählen.
Der Begriff „modulare Speicher-Engine-Architektur von MySQL“ bezeichnet die gegenwärtig bei MySQL praktizierte Nutzung öffentlich verfügbarer, dokumentierter Programmierschnittstellen, die es Anbietern von Speicher-Engines ermöglicht, ihre Speicher-Engines in den MySQL-Datenbankserver zu integrieren. Die Dokumentation wird mit der gegenwärtig von Sun bereitgestellten Dokumentation übereinstimmen.
2. Anspruchsverzicht. Als Urheberrechtsinhaber wird Oracle die aktuelle Politik von Sun ändern und gegenüber niemandem durchsetzen oder mit der Durchsetzung drohen, dass Speicher-Engine-Implementierungen von Drittanbietern unter der GPL veröffentlicht werden müssen, da sie die Anwendungsprogrammierschnittstellen implementiert haben, die als Bestandteil der modularen Speicher-Engine-Architektur von MySQL zur Verfügung stehen.
Zur Implementierung der Anwendungsprogrammierschnittstellen, die als Bestandteil der modularen Speicher-Engine-Architektur von MySQL zur Verfügung stehen, verlangt Oracle von Drittanbietern von Speicher-Engines keine kommerzielle Lizenz.
Oracle wird diese Zusage in die vertraglichen Verpflichtungen gegenüber Speicheranbietern einbinden, die gegenwärtig über eine kommerzielle Lizenz von Sun verfügen.
3. Lizenzzusagen. Nach Beendigung des aktuellen MySQL-OEM-Vertrags wird Oracle Speicher-Engine-Anbietern, die gegenwärtig eine kommerzielle Lizenz von Sun besitzen, eine Verlängerung ihres Vertrags zu denselben Bedingungen und mit einer Laufzeit maximal bis zum 10. Dezember 2014 anbieten.
Oracle wird diese Zusage in die vertraglichen Verpflichtungen gegenüber Speicheranbietern einbinden, die gegenwärtig über eine kommerzielle Lizenz von Sun verfügen.
4. Selbstverpflichtung zur Weiterentwicklung von MySQL unter der GPL. Oracle wird MySQL weiterhin verbessern und nachfolgende Versionen von MySQL, einschließlich Version 6, unter der GPL zur Verfügung stellen. Oracle wird keine neue, verbesserte Version von MySQL Enterprise Edition herausgeben, ohne gleichzeitig eine neue, ebenso verbesserte Version von MySQL Community Edition, die unter der GPL lizenziert ist, herauszugeben. Oracle wird den Quellcode aller Versionen von MySQL Community Edition weiterhin kostenlos öffentlich verfügbar machen.
5. Nicht obligatorischer Support. Die Kunden werden keine Supportdienstleistungen von Oracle als Vorbedingung für die Erteilung einer kommerziellen Lizenz für MySQL erwerben müssen.
6. Höhere Investitionen in die Forschung und Entwicklung für MySQL. Oracle verpflichtet sich, für die fortlaufende Entwicklung von MySQL (GPL-Version und kommerzielle Version) zur Verfügung zu stellen. Oracle wird in jedem der nächsten drei Jahre mehr Mittel für die Forschung und Entwicklung (F&E) im globalen Geschäftsbereich MySQL (MySQL Global Business Unit) aufwenden, als Sun im letzten Geschäftsjahr vor dem Zusammenschluss aufwandte (24 Mio. USD).
7. Beratungsgremium bestehend aus MySQL-Kunden. Spätestens sechs Monate nach dem ersten Jahrestag des Zusammenschlusses wird Oracle ein aus Kunden bestehendes Beratungsgremium ins Leben rufen und mit angemessenen Mitteln ausstatten. Dieses Gremium wird insbesondere Endnutzer und Kunden aus dem Bereich der eingebetteten Datenbanken umfassen und soll hinsichtlich der Prioritäten bei der MySQL-Entwicklung und anderer für MySQL-Kunden bedeutsamer Fragen beratend tätig sein und entsprechende Rückmeldungen geben.
8. MySQL-Beratungsgremium für Speicher-Engine-Anbieter. Spätestens sechs Monate nach dem Jahrestag des Abschlusses wird Oracle ein Beratungsgremium für Speicher-Engine-Anbieter einrichten und finanzieren, um Hinweise und Feedback zu MySQL-Entwicklungsprioritäten und anderen wichtigen Themen für MySQL-Speicher-Engine-Anbieter bereitzustellen.
Oracle hat öffentlich angekündigt, sich bis zum fünften Jahrestag des Zusammenschlusses weltweit an all diese Zusagen zu halten. Darüber hinaus hat Oracle bereits Maßnahmen ergriffen, um drei dieser Zusagen rechtsverbindlich in die bestehenden Verträge von Sun mit Anbietern von Speicher-Engines aufzunehmen.
177.Die öffentliche Ankündigung, in der Oracle den Nutzern, Kunden und Entwicklern von MySQL spezifische Zusagen bezüglich des Managements und der Weiterentwicklung von MySQL nach dem Zusammenschluss macht, stellt keine formellen Abhilfemaßnahmen gemäß der Mitteilung der Kommission über zulässige Abhilfemaßnahmen nach der Verordnung (EG) Nr. 139/2004 des Rates sowie der Verordnung (EG) Nr. 802/2004 der Kommission(„Mitteilung über Abhilfemaßnahmen“) dar.
178.Die Kommission verfolgt eine seit langem etablierte und kohärente Praxis bezüglich der Abhilfemaßnahmen, die erforderlich sind, um einen Zusammenschluss zu genehmigen, wenn am Ende der Untersuchung wettbewerbsrechtliche Bedenken bestehen. Diese Praxis wird in der Mitteilung über Abhilfemaßnahmen detailliert erläutert. Sie wurde bei unzähligen Entscheidungen angewandt, die gemäß der EG-Fusionskontrollverordnung erlassen wurden. Die Verpflichtungen der beteiligten Unternehmen müssen in angemessenem Verhältnis zu den festgestellten Wettbewerbsproblemen stehen und diese vollständig beseitigen.
179.Laut Randnummer 13 der Mitteilung über Abhilfemaßnahmen müssen, wenn die Verpflichtungen die Voraussetzungen der Mitteilung über Abhilfemaßnahmen erfüllen sollen, eine wirksame Umsetzung und die Möglichkeit gegeben sein, die Umsetzung zu kontrollieren. Anderenfalls wären solche Verpflichtungen als bloße Absichtserklärungen der beteiligten Unternehmen und nicht als bindende Auflagen anzusehen, da eine Zuwiderhandlung mangels wirksamer Kontrollmechanismen nicht zum Widerruf der Entscheidung nach der EG-Fusionskontrollverordnung führen könnte.
180.Diese Grundsätze gelten in vollem Umfang in jedem Fall, in dem die Kommission wettbewerbsrechtliche Bedenken geäußert hat. Anders stellt sich die Situation jedoch dar, wenn die Kommission aufgrund des Sachverhalts zu dem Schluss gelangen kann, dass der Zusammenschluss keinen Anlass zu wettbewerbsrechtlichen Bedenken gibt.
181.In diesem Zusammenhang stellen nach Auffassung der Kommission die an die Öffentlichkeit und insbesondere an die Open-Source-Community gerichtete öffentliche Ankündigung von Oracle vom 14. Dezember und die in der Folge bereits ergriffenen Maßnahmen zur teilweisen Umsetzung dieser Ankündigung Fakten dar, die die
a storage engine vendor advisory board, to provide guidance and feedback on MySQL development priorities and other issues of importance to MySQL storage engine vendors.“]
9.MySQL-Referenzhandbuch. Oracle wird weiterhin ein qualitativ dem gegenwärtig von Sun bereitgestellten Referenzhandbuch entsprechendes MySQL-Referenzhandbuch pflegen, aktualisieren und kostenlos zum Download anbieten.
10.Beibehaltung der Supportoptionen für Kunden. Oracle wird sicherstellen, dass Endnutzer und Kunden aus dem Bereich der eingebetteten Datenbanken, die ein Entgelt für MySQL-Supportabonnements entrichten, ihre Abonnements je nach Wunsch von Jahr zu Jahr oder für mehrere Jahre verlängern können.
Kommission in der vorliegenden Sache neben allen anderen ihr vorliegenden Elementen bei der Bewertung der Auswirkungen des Zusammenschlussvorhabens auf den Datenbankmarkt berücksichtigen muss.
182.Obwohl die öffentliche Ankündigung von Oracle mit Ausnahme der Punkte 1, 2 und 3 (siehe Randnummer 184) für Oracle nicht rechtsverbindlich ist, sorgen nach Auffassung der Kommission die extremen Besonderheiten von Open-Source-Software und das MySQL umgebende dynamische Ökosystem für einen selbstdurchsetzenden Mechanismus, durch den sichergestellt wird, dass Oracle weder die Möglichkeiten noch Anreize hätte, von seinem angekündigten zukünftigen Verhalten abzuweichen. Ansehen und Vertrauen sind für den Sponsor eines Open-Source-Projekts, das auf die Beiträge eines großen Ökosystems von Nutzern, Entwicklern und Kunden angewiesen ist, äußerst wichtig. Nach dem Zusammenschluss wird Oracle zum Sponsor einer Reihe bedeutender Open-Source-Projekte von Sun, darunter Java, MySQL und OpenSolaris, und wird insofern das Vertrauen der Open-Source-Community gewinnen und langfristig erhalten müssen. Diesbezüglich ist zu erwarten, dass alle öffentlichen Zusagen von Oracle, die auf die Beruhigung von MySQL-Nutzern, Entwicklern und Anbietern von Speicher-Engines abzielen, von der Open-Source-Community einer sehr kritischen Prüfung unterzogen werden.
183.In diesem Zusammenhang sei festgestellt, dass die öffentliche Ankündigung zu einem großen Teil die Zusagen enthält, die Monty Widenius, Gründer von MySQL und Inhaber von Monty Program AB, in seinem Blog vom 13. Dezember 2009 von Oracle gefordert hat. Die lebhafte Debatte nach den öffentlichen Ankündigungen von Oracle zeigt, wie lebendig die Open-Source-Community rund um MySQL ist und dass diese in der Lage ist, mögliche erhebliche Abweichungen seitens Oracle von den öffentlichen Zusagen zu erkennen und hinreichende Druckmittel bereitzustellen.
156.In diesem Zusammenhang sollte betont werden, dass wie im Falle von Informationen, die für die Feststellung der Vereinbarkeit eines Zusammenschlusses durch die Kommission von wesentlicher Bedeutung sind, die Kommission das Recht hat, die vorliegende Entscheidung nach Artikel 8 Absatz 6 Buchstabe a der EG-Fusionskontrollverordnung zurückzunehmen, sollte Oracle es versäumen, seine öffentliche Ankündigung einzuhalten. Artikel 8 Absatz 6 Buchstabe a der EG-Fusionskontrollverordnung bezieht sich auf eine andere Situation als Artikel 8 Absatz 4 Buchstabe b und Artikel 8 Absatz 6 Buchstabe b der EG-Fusionskontrollverordnung, in denen der Verstoß gegen eine Bestimmung bzw. eine Verpflichtung im Zusammenhang mit einer Entscheidung im Rahmen einer nach Artikel 8 Absatz 2 angenommenen Entscheidung behandelt wird.
http://monty-says.blogspot.com/2009/12/help-saving-mysql.html. In seinem Blog vom 13. Dezember 2009 brachte Monty Widenius, Schöpfer von MySQL und Inhaber von Monty Program AB, dem Unternehmen hinter dem MySQL-Ableger MariaDB, seine Bedenken bezüglich der Übernahme von MySQL durch Oracle zum Ausdruck, denn Oracle hatte Folgendes nicht zugesagt: - keine Teile, Module oder erforderlichen Tools in Closed-Source-Form hinzuzufügen - die Lizenzgebühren oder Supportpreise für MySQL nicht anzuheben - regelmäßig und zeitnah neue MySQL-Versionen zu veröffentlichen - die duale Lizenzierung fortzuführen und stets erschwingliche kommerzielle MySQL-Lizenzen für diejenigen anzubieten, die diese benötigen, (Speicher- und Anwendungsanbieter) oder MySQL unter einer freizügigeren Lizenz bereitzustellen - MySQL als Open-Source-Projekt zu entwickeln - aktiv mit der Community zusammenzuarbeiten - bereitgestellte Patches zeitnah anzuwenden - Patches, die MySQL gegenüber den anderen Produkten von Oracle konkurrenzfähiger machen, nicht zu diskriminieren - sicherzustellen, dass MySQL auch in einer Weise verbessert wird, die zu einer erhöhten Wettbewerbsfähigkeit von MySQL gegenüber den Hauptangeboten von Oracle führt
184.Die Punkte 1, 2 und 3 seiner öffentlichen Ankündigung hat Oracle sofort umgesetzt und Schreiben an acht Dritte, darunter vier Drittanbieter von Speicher-Engines, verschickt, in denen zugesagt wird, die bestehenden Vertragsbedingungen zu ändern und den betreffenden Inhalt der öffentlichen Ankündigung darin zu wiederholen.
Wie in Abschnitt 4.4 ausführlich dargelegt, wirken sich die öffentliche Ankündigung und ihre teilweise Umsetzung auf die Möglichkeiten und Anreize für Oracle im Hinblick auf die Weiterentwicklung von MySQL nach dem Zusammenschluss aus.
Möglicherweise nach dem Zusammenschluss durch andere Open-Source-Datenbanken und Ableger von MySQL auf Oracle ausgeübter Wettbewerbsdruck
186.Die von der Kommission durchgeführte Untersuchung ergab, dass andere Open-Source-Datenbanken, insbesondere PostgreSQL, möglicherweise das Potenzial besitzen, nach dem Zusammenschluss einen wichtigen Wettbewerbsdruck auf Oracle auszuüben und den gegenwärtig von MySQL ausgeübten Wettbewerbsdruck zeitnah und in hinreichendem Maße zu ersetzen.
187.Zudem legte die von der Kommission durchgeführte Untersuchung den Schluss nahe, dass die Möglichkeit nicht ausgeschlossen werden kann, dass sich auch Ableger von MySQL so entwickeln könnten, dass sie einen gewissen Wettbewerbsdruck auf Oracle ausüben.
4.3.Wettbewerbssituation vor dem Zusammenschluss
4.3.1.Merkmale des Datenbankmarktes
188.Datenbanken unterscheiden sich in ihrem Architekturentwurf. Während die meisten Datenbanken vergleichbare Basisfunktionen bieten und somit bei einfacher Nutzung weitestgehend technisch substituierbar sind, wird im Hinblick auf anspruchsvollere Anwendungen die Substituierbarkeit durch Unterschiede in der technischen Architektur der Datenbanken tendenziell eingeschränkt.
189.Der Markt für Datenbanken ist durch ein hohes Maß an Preisdiskriminierung gekennzeichnet. Datenbankanbieter können dies erreichen, indem sie ihre Datenbanken auf unterschiedliche Weise konfigurieren und damit verschiedene Editionen erstellen. Zu diesem Zweck werden meist bestimmte Funktionsmerkmale deaktiviert oder die Speichergröße der Datenbank wird eingeschränkt. Ferner können die Datenbankanbieter auch eine Preisdiskriminierung ersten Grades vornehmen, wobei sie unmittelbar verschiedenen Nutzern unterschiedliche Preise für ein technisch identisches Produkt berechnen.
190.Es ist festzustellen, dass die Preisdiskriminierung durch die Fähigkeit des Anbieters eingeschränkt ist, die Nutzung der Datenbank genau zu ermitteln (so kann z. B. eine für Webanwendungen erworbene Datenbank durchaus für andere Bereiche genutzt werden, ohne dass der Anbieter dies unbedingt weiß).
191.Ein weiteres Merkmal des Softwaremarktes sind die sehr niedrigen Grenzkosten für Softwarelizenzen. Dadurch entstehen beachtliche Skaleneffekte, die einen starken Anreiz für die Datenbankanbieter darstellen, ein hohes Absatzvolumen zu erreichen.
192.Die starken Skaleneffekte legen in Kombination mit der beträchtlichen Fähigkeit zur Preisdiskriminierung nahe, dass der Wettbewerb um weniger anspruchsvolle Nutzer sehr stark ist. Diese Nutzer verwenden i. d. R. die Grundfunktionen der Datenbanken. Gleichzeitig ist der Wettbewerb um anspruchsvollere Nutzer auf dem Markt für High-End-Datenbanken wahrscheinlich aufgrund der stärkeren funktionalen Differenzierung der Datenbanken eher eingeschränkt.
193.Wie bereits in Abschnitt 3.2.3. dargelegt, sind ein weiteres besonderes Merkmal des Datenbankmarktes die hohen beziehungsspezifischen Kosten auf der Seite des Kunden. Diese Kosten fallen bei der Einführung einer bestimmten Datenbank an und sinken danach. Eine Umstellung führt erneut zu hohen Kosten. Die Kosten entstehen dem Kunden, wenn dieser in datenbankspezifische Schulungen sowie in die Entwicklung von an die betreffende Datenbank angepassten Anwendungen investiert.
194.Dies kann zu einem mit hohen Kosten verbundenen Hold-up-Problem führen, da der Anbieter einen Anreiz hat, den Preis zu erhöhen, nachdem der Kunde auf seine Datenbank festgelegt ist. Sowohl der Datenbankanbieter und als auch der festgelegte Nutzer haben möglicherweise einen Anreiz, dieses Problem zu lösen, jedoch lässt es sich nicht leicht lösen, da glaubwürdige Zusagen in Form langfristiger Verträge kostenintensiv sind. Branchen mit hohen Umstellungskosten sind häufig durch starken Ex-ante-Wettbewerb um den Markt in Form von sehr niedrigen Preisen für Neukunden und höheren Preisen für gebundene Nutzer gekennzeichnet.
195.In der akademischen Literatur ist hinreichend belegt, dass auf zahlreichen Softwaremärkten Netzwerkeffekte eine wichtige Rolle spielen, u. a. auch auf dem Markt für Datenbanken. Netzwerkeffekte bezeichnen die Wirkung, die ein Teilnehmer in einem Netzwerk auf den Nutzen hat, den andere Teilnehmer aus demselben Netzwerk ziehen. Netzwerkeffekte stellen auch eine effektive Marktzutrittsschranke dar. In einem Netzwerk müssen sich viele Personen an einem Projekt beteiligten, damit alle einen Nutzen aus der Beteiligung ziehen können und das Netzwerk im Wettbewerb gegen etablierte Netzwerke bestehen kann. Der Aufbau eines umfangreichen Netzwerks ist aufgrund des hohen Zeitaufwands kostenintensiv und erfordert möglicherweise eine sehr aggressive Preispolitik. Dadurch haben unabhängige Entwickler selbst in einem in hohem Maße konzentrierten Wirtschaftszweig, in dem die etablierten Unternehmen hohe Margen erzielen, ein geringeres Interesse an einem Markteintritt. Folglich sind die Wirtschaftszweige mit starken Netzwerkeffekten häufig in hohem Maße konzentriert.
4.3.2.Oracle als größter und stärkster Anbieter proprietärer Datenbanken
196.Oracle ist mit einem einnahmenbasierten Marktanteil zwischen 43 % und 49 % im Jahr 2008 der führende Anbieter von RDBMS weltweit. Der einnahmenbasierte Marktanteil des Unternehmens ist mehr als doppelt so groß wie der des zweitstärksten Anbieters IBM, der 2008 einen Marktanteil von rund 22 % hatte. Microsoft, der drittgrößte Anbieter von RDBMS, verzeichnete einen Marktanteil zwischen 16 % und 19 %. Kein anderer RDBMS-Anbieter erreichte 2008 einen einnahmenbasierten Marktanteil über 5 %.
197.Mit Ausnahme von Mainframe- und anderen Serversystemen, bei denen die von IBM angebotenen RDBMS am weitesten verbreitet sind, sind die RDBMS-Lizenzeinnahmen von Oracle recht gleichmäßig über die verbleibenden Betriebssystemumgebungen verteilt, nämlich Unix, Windows NT und Linux/Open-Source-Systeme. Somit ist Oracle nicht nur der insgesamt führende Anbieter von RDBMS, sondern auch der führende Anbieter für Unix (49,7 %) und Linux/Open-Source-Umgebungen (66,5 %) sowie der zweitgrößte Anbieter von RDBMS für Windows NT (26,2 %) nach Microsoft (dessen RDBMS nur in der Betriebssystemumgebung Windows NT funktioniert).
Im Gegensatz zu IBM und Microsoft erzielt Oracle einen größeren Anteil seiner Gesamteinnahmen aus RDBMS nicht mit Lizenzen, sondern mit Wartung.
Tabelle 3: Einnahmen aus RDBMS-Produkten weltweit, 2007
Gesamtlizenz-In Prozent der Gesamtein-In Prozent der Gesamtein-nahmen aus RDBMS (Mio.nahmen ausRDBMS USD)RDBMSProdukten (Mio. USD)
3.461
42 %
4.875
58 %
8.336
IBM
2.721
69 %
1.232
31 %
3.953
Microsoft
2.679
77 %
800
23 %
3.479
Das Bild, wie es sich bei RDBMS-Einnahmen darstellt, spiegelt die Situation bei den Gesamteinnahmen des Unternehmens laut seinem Jahresbericht wider, in dem Einnahmen aus Softwarelizenzen und Updates (d. h. Wartung) mit fast der Hälfte der Gesamteinnahmen und neue Softwarelizenzen mit rund einem Drittel angegeben werden. In demselben Bericht stellt das Unternehmen Folgendes fest: „Im Wesentlichen erwerben all unsere Kunden beim Erwerb neuer Softwarelizenzen Updates und Produktsupport. Zudem verlängern praktisch all unsere Kunden ihre Softwarelizenzupdates und Produktsupportverträge jährlich.“ [„Substantially all of our customers purchase software license updates and product support when they acquire new software licenses. In addition, substantially all of our customers renew their software license updates and product support contracts annually.“]
Wie die folgenden Zitate aus den von der Kommission durchgeführten Marktuntersuchungen der ersten und der zweiten Phase zeigen, haben sich einige der Kunden zu der Tatsache geäußert, dass Oracle als Marktführer bei RDBMS hohe Preise für Lizenzen und Support berechnen kann, was nach dem geplanten Zusammenschluss möglicherweise noch besser möglich ist:
(1) „Wir erwarten steigende Kosten/Preise für Lizenzen und Wartung des Oracle-Datenbankprodukts… Oracle wird seine Position als Marktführer ausbauen und Einfluss auf den gesamten Datenbankmarkt nehmen. Verhandlungen werden sich immer schwieriger gestalten (z. B. unflexible Lizenzmodelle für große, als Diensteanbieter tätige Unternehmen, jedes Jahr steigende Supportkosten).“ [„We expect growing costs/prices for licences and maintenance for Oracle database product… Oracle leading market position will grow and will influence the whole database market. Negotiations will become more difficult (e.g. inflexible licence models for large enterprises acting as service provider, growing support costs year by year).“]
(2) „Die Übernahme von Sun wird Oracle in die Lage versetzen, die Kunden zu zwingen, kostspielige und nicht gewünschte Wartungsdienste für mehr Produkte und Dienstleistungen zu akzeptieren... Verizon hat gewöhnlich mehr für die Wartung der Anwendung als für die eigentliche Lizenz gezahlt... Dies ist ein Ergebnis, das alle Oracle-Kunden zwangsläufig akzeptieren müssen. … Oracle scheint eine beherrschende Position einzunehmen, die das Unternehmen im Hinblick auf die Produkte von Sun ausspielen könnte, wenn dieser Zusammenschluss zustande käme.“ [„Oracle's acquisition of Sun will allow Oracle to force customers to accept costly and unwanted maintenance to more products and services…Verizon has customarily paid more for the maintenance of that application than the license itself...This is an outcome that all Oracle customers are forced to accept. ...Oracle would seem to have a dominant position that it could leverage to Sun products if the transaction were consummated.“]
In seiner öffentlichen Ankündigung vom 14. Dezember 2009 erklärte Oracle, es werde MySQL unter der GPL weiterentwickeln und die Erteilung einer kommerziellen Lizenz für MySQL nicht davon abhängig machen, dass die Kunden Supportdienstleistungen erwerben. Dadurch wird Oracle in seinen Möglichkeiten eingeschränkt, hohe Preise für Lizenzen und Support zu berechnen.
4.3.3.MySQL weist bestimmte Merkmale auf, insbesondere in Bezug auf die Technologie und das Geschäftsmodell, die die Art des von MySQL ausgeübten Wettbewerbsdrucks bestimmen. Diese Merkmale werden im Folgenden beschrieben.
4.3.3.1.Technologie
MySQL weist verschiedene spezielle technische Merkmale auf, die sich auf die Art des von MySQL ausgeübten Wettbewerbsdrucks auswirken.
MySQL kann auf allen wichtigen Plattformen genutzt werden, d. h., MySQL ist nicht auf bestimmte Betriebssysteme beschränkt, anders als beispielsweise Microsoft SQL Server, das nur unter Windows läuft.
MySQL hat einen geringen Speicherbedarf, d. h., der Aufwand an Ressourcen (sei es erforderlicher Festplattenspeicher oder Arbeitsspeicher) für die Nutzung der Datenbank ist relativ gering. So hat MySQL z. B. einen erheblich geringeren Speicherbedarf als Oracle Database.
MySQL ist einfach zu installieren. Bezeichnend hierfür ist die Angabe von MySQL, dass der Zeitaufwand für das Herunterladen und Installieren von MySQL 15 Minuten nicht übersteigt. Für die Nutzung und Verwaltung von MySQL ist weniger Fachwissen erforderlich. MySQL wird häufig in einem Paket mit anderen Anwendungen angeboten, so z. B. mit Content Management-Systemen, mit denen Websites schnell und einfach mit MySQL als Back-End-Datenspeicher eingerichtet werden können, ohne dass für die Konfiguration oder den Betrieb von Datenbanken spezielle Schulungen erforderlich wären.
MySQL ist modular aufgebaut, ein Ansatz, der sich von dem Einheitsmodell unterscheidet, das die meisten Anbieter proprietärer Datenbanken, jedoch auch andere Anbieter von Open-Source-Datenbanken wählen.
Das Besondere an dem modularen Aufbau von MySQL ist, dass die Schnittstellen/Konnektoren zwischen den drei Schichten dokumentiert sind und von Software genutzt werden können, die von Dritten entwickelt wurde. Auf diese Weise können die Schichten der Tools und Speicher-Engines angepasst werden. Zwar sind im Lieferumfang von MySQL verschiedene Speicher-Engines (z. B. die Standard-Speicher-Engine MyISAM) und auf Anfrage bestimmte Tools enthalten, jedoch können die Nutzer selbst wählen, welche Speicher-Engine und Tools sie nutzen möchten. Den Kern von MySQL-Datenbanken bildet der MySQL-Server, d. h. die mittlere Schicht, die unabhängig von den gewählten Tools und der gewählten Speicher-Engine immer gleich bleibt, so dass gewährleistet ist, dass die Datenbank eine MySQL-Datenbank bleibt. Auf diese Weise sind die Anwendungen, von denen die Datenbank genutzt wird, bis zu einem gewissen Maß von der Komplexität und den Besonderheiten der Speicher-Engines abgeschirmt. Wenn Anwendungen so entwickelt werden, dass sie mit MySQL genutzt werden können, ist es in vielen Fällen möglich, einfach die zugrunde liegende Speicher-Engine zu ändern, um z. B. eine erhebliche Leistungssteigerung zu erzielen, ohne jedoch die Anwendung anpassen zu müssen.
Für MySQL sind verschiedene Speicher-Engines verfügbar, so dass der Kunde diejenige wählen kann, mit der für die Zielanwendung die höchste Wirkung erzielt werden kann. Zu diesen Speicher-Engines zählen solche, die von MySQL selbst entwickelt wurden (wie MyISAM, Falcon, Cluster usw.), von Partnern entwickelte Speicher-Engines (wie z. B. InnoDB, die nun Oracle gehört), von Dritten entwickelte (und vermarktete) Speicher-Engines sowie von MySQL-Nutzern nach ihren jeweiligen Anforderungen entwickelte angepasste Speicher-Engines.
210.MySQL ist gegenwärtig zu günstigen Bedingungen für diverse Anbieter von Ergänzungsprodukten verfügbar. Eine besonders bekannte Gruppe sind unabhängige Anbieter von Speicher-Engines (neben InnoDB, die Eigentum von Oracle ist), die für High-End-Anwendungen benötigte Funktionen implementieren. Diese Speicher-Engines haben in erheblichem Maße zur Verbesserung von MySQL beigetragen und es ist davon auszugehen, dass sie aller Wahrscheinlichkeit nach auch in Zukunft zur Verbesserung von MySQL beitragen, wenn MySQL in der derzeitigen Form und zu günstigen Bedingungen wie bisher von unabhängigen Eigentümern verfügbar ist.
211.Dank der modularen Architektur und der Verfügbarkeit mehrerer Speicher-Engines kann MySQL somit verschiedene Technologiesegmente des Marktes ansprechen, wodurch die Wettbewerbsfähigkeit von MySQL in diversen Segmenten des Datenbankmarktes gesteigert wird.
4.3.3.2.Funktionalität
212.MySQL ist sehr beliebt für die Implementierung eines Back-End-Speichers für Websites. Auf diesem Markt sind die Funktionsmerkmale der Standard-Speicher-Engine MyISAM i. A. absolut ausreichend.
213.Für die Nutzung als universelle Datenbank fehlen der Standard-Speicher-Engine (MyISAM) verschiedene Funktionsmerkmale, die von entscheidender Bedeutung sind, um im Wettbewerb mit proprietären RDBMS bestehen zu können. Andere Speicher-Engines wie InnoDB, Falcon oder die IBM DB2-Engine für i13 (IBM DB2i) bieten diese Funktionsmerkmale jedoch.
214.InnoDB, die 2005 von Oracle erworben wurde und gemäß einer Vereinbarung mit MySQL weiterhin unter einer dualen Lizenz erhältlich ist, ist gegenwärtig die am häufigsten genutzte Speicher-Engine für die Entwicklung transaktionsorientierter Datenbankanwendungen mit MySQL. Der TAEUS-Bericht gelangt zu dem Schluss, dass es im Bereich von OLTP-Anwendungen eine große Überschneidung zwischen MySQL und Oracle gibt, vorausgesetzt, die Speicher-Engine InnoDB kann weiterhin in MySQL genutzt werden.
215.Eine bedeutende Speicher-Engine für bestimmte High-End-Entwicklungen ist die Cluster-Speicher-Engine, die Teil des von Sun angebotenen Produkts MySQL Cluster ist und MySQL um Clusterfunktionen erweitert. Mit einem Cluster kann die Zuverlässigkeit eines Gesamtcomputersystems erhöht und/oder eine höhere Leistung erzielt werden. In einigen der proprietären High-End-Datenbanken sind Clusterfunktionen erhalten oder können hinzugekauft werden.
216.Mit dem Produkt MySQL Cluster ist MySQL als eingebettete Datenbank in einem Teilsegment des Marktes erfolgreich, das aus Geräteherstellern für Telekommunikationsunternehmen besteht. MySQL Cluster ist als spezielle speicherinterne Datenbank eigens auf die Anforderungen derartiger Nutzer zugeschnitten und umfasst eine Reihe von Funktionsmerkmalen, mit denen die Zuverlässigkeit und Leistung entsprechender Anwendungen verbessert werden können. MySQL Cluster kann jedoch nicht nur von Anbietern im Telekommunikationsbereich genutzt werden.
217.Gegenwärtig bestehen auch technische Einschränkungen bei MySQL. So wäre z. B. für Data-Warehousing eine Standardinstallation von MySQL derzeit erheblich weniger geeignet als eine Standardinstallation von Oracle (einschließlich der entsprechenden von Oracle angebotenen technischen Zusatzfunktionen (Add-Ons)). Dennoch gibt es verschiedene Hinweise darauf, dass MySQL gegenwärtig für Data-Warehousing genutzt werden kann. Zudem sind Produkte von Drittanbietern erhältlich, die mit MySQL kombiniert werden können, um die Wettbewerbsfähigkeit von MySQL in diesem Segment zu stärken.
218.Die Möglichkeiten der horizontalen Skalierung, d. h. der Fähigkeit, zusätzliche Hardwareeinheiten (Server) vollständig in zusätzliche Leistung/Geschwindigkeit umzusetzen, sind nach Auffassung von TAEUS bei MySQL begrenzter als z. B. bei Oracle. Die horizontale Skalierung ist wichtig für Anwendungen, bei denen eine höhere Zuverlässigkeit und Verfügbarkeit erforderlich ist, als ein einzelner Computer (selbst mit redundanten Komponenten) bieten kann, d. h. üblicherweise für transaktionsorientierte Anwendungen.
219.Im Hinblick auf die vertikale Skalierung, d. h. die Nutzung von zusätzlicher Prozessorkapazität auf dem Computer, auf dem die Datenbank installiert ist, scheint die aktuelle Version von MySQL mit wenig zusätzlichem Entwicklungsaufwand für die meisten Anwendungen direkt mit Oracle-Produkten konkurrieren zu können.
220.Was die horizontale Skalierung per Fernzugriff für auf mehreren geografisch verteilten Computern ausgeführte Datenbanken anbelangt, so erachtet TAEUS MySQL als nicht sehr wettbewerbsfähig.
221.In seiner Erwiderung auf die Mitteilung der Beschwerdepunkte legte Oracle einen Bericht eines unabhängigen Experten für Datenbanksysteme vor, der die grundlegenden Unterschiede zwischen MySQL und Oracle 11g untersucht hat. Die wichtigsten Erkenntnisse des Berichts sind, dass Oracle 11g und MySQL sehr unterschiedliche Anforderungen erfüllen, dass es keinen technisch sinnvollen Entwicklungspfad gibt, der MySQL zu einem adäquaten Ersatz für Oracle machen würde, und dass die Kluft zwischen 11g und MySQL in Zukunft wahrscheinlich noch größer werden wird.
222.Oracle behauptet, MySQL könne für transaktionsorientierte Anwendungen nicht genutzt werden. Die Kommission ist jedoch der Auffassung, dass MySQL je nach verwendeter Speicher-Engine durchaus für transaktionsorientierte Anwendungen genutzt werden kann. Erstens gelangt der TAEUS-Bericht zu dem Schluss, dass MySQL in Kombination mit der Speicher-Engine InnoDB für transaktionsorientierte Anwendungen wettbewerbsfähig ist. Zweitens wird MySQL von Kunden als transaktionsorientierte Datenbank genutzt, z. B. von Unternehmen wie Aruba Wireless Network, Deutsche Lufthansa und Sabre Holding.
223.Oracle behauptet ferner, MySQL könne im Segment für Unternehmensanwendungen nicht genutzt werden. Gegenwärtig ist MySQL für keine der als Paket angebotenen High-End-Anwendungen zur Planung der Unternehmensressourcen (SAP, PeopleSoft, Baan usw.) zertifiziert, wodurch die Nutzung von MySQL in diesem Bereich eingeschränkt wird. Allerdings ist ein großer Teil von erfolgskritischen Anwendungen (auch im High-End-Bereich) unternehmensspezifisch entwickelt worden (sei es unternehmensintern oder durch Auftragnehmer). In diesen Fällen kann MySQL genutzt werden.
224.Dass MySQL für die als Paket angebotenen High-End-Unternehmensanwendungen nicht zertifiziert ist, bedeutet keineswegs, dass MySQL unter dem Gesichtspunkt der Architektur für diesen Zweck nicht geeignet wäre.
225.Den Anbietern von Anwendungen entstehen für jede zertifizierte Datenbank Kosten, da die Zertifizierung Änderungen an der Anwendung selbst erforderlich macht, damit diese eine weitere Datenbank nutzen kann. Außerdem sind umfangreiche Tests erforderlich, bevor die Zertifizierung erteilt wird. Nachdem eine Datenbank zertifiziert worden ist, können die Kunden des Anwendungsanbieters mit Recht darauf vertrauen, dass dieser bei Nutzung der Anwendung mit dieser Datenbank auch Support leistet und bei einem Problem den Kunden nicht einfach an den Datenbankanbieter verweist. Diese Überlegung zeigt, dass eine Anwendung zwar möglicherweise so angepasst werden kann, dass sie mit einer bestimmten Datenbank funktioniert, dies jedoch nicht automatisch geschieht. Vielmehr ist eine solche Anpassung das Ergebnis einer wirtschaftlichen Bewertung durch den Anwendungsanbieter, der die Kosten und den Nutzen eines solchen Schrittes gegeneinander abwägt.
226.Auch strategische Erwägungen können bei der Entscheidung eine Rolle spielen. So ist z. B. die Tatsache, dass die eigenen Anwendungen von Oracle MySQL nicht unterstützen, kaum überraschend, da Oracle es doch bevorzugt, wenn die Nutzer sich für seine eigenen Datenbankangebote entscheiden. Bei anderen Anwendungsanbietern ist die Logik u. U. genau umgekehrt, d. h., sie möchten möglicherweise eine kostengünstigere Datenbank als Speicherlösung für ihre eigene Anwendung verfügbar machen, um so bei der Preisgestaltung für die Anwendung flexibler zu sein.
Dies scheint bei SAP der Fall zu sein: „Am 22. April 2003 unterzeichneten SAP und MySQL AB eine Entwicklungsvereinbarung, derzufolge MySQL nach einem Plan mit 12 Meilensteinen MySQL verbessern würde, um die Zertifizierung von MySQL Server für die Ausführung der SAP R/3-Unternehmensanwendungen zu erreichen. […] Das Projekt wurde im Oktober 2005 aufgegeben.“ [„[o]n 22 April 2003, SAP and MySQL AB signed a development agreement, whereby MySQL would enhance MySQL on a schedule with 12 milestones, with the end goal of MySQL server becoming certified to run SAP’s R/3 enterprise applications. […] In October 2005, the project was abandoned.“]Die zeitliche Einordnung dieses Projekts ist von großer Bedeutung, da sie Rückschlüsse auf den wahrscheinlicheren Grund für die Aufgabe der gemeinsamen Entwicklungsbemühungen durch SAP zulässt: Im Oktober 2005 wurde die Übernahme von Innobase, dem Hersteller der Speicher-Engine InnoDB (einer der wichtigsten Speicher-Engines für MySQL), durch Oracle angekündigt. In der Tat […]* , […]*.
228.Da für die Anwendungen von SAP ein transaktionsorientiertes RDBMS erforderlich ist, wäre das Unternehmen durch die Zertifizierung von MySQL für die Nutzung mit den SAP-Anwendungen nicht in die Lage versetzt worden, die Preise von Oracle erheblich zu unterbieten – was das ursprüngliche Motiv für eine Investition in die Weiterentwicklung von MySQL gewesen sein dürfte –, denn wegen InnoDB wären die Implementierungen von MySQL nicht wirklich von Oracle unabhängig gewesen. Zu dem Zeitpunkt, als SAP das Projekt aufgrund der Übernahme von InnoDB durch Oracle stoppte, waren 10 von 12 Meilensteinen bereits erfolgreich erreicht worden.
229.Oracle macht geltend, MySQL sei nicht in der Lage, die vertikale Skalierbarkeit zu verbessern oder eine bessere horizontale Skalierbarkeit über die Anforderungen einer Webdatenbank oder einer Datenbank mit eher bescheidenen Transaktionsanforderungen hinaus zu erreichen. TAEUS ist anderer Meinung: Es seien Verbesserungen in beide Richtungen möglich, wenn es auch sehr viel einfacher und risikoärmer scheine, die horizontale Skalierbarkeit von MySQL zu verbessern, als die vertikale Skalierbarkeit.
185Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), S. 83-84 (doc_ID 2427).
186Doc_ID 3945, S. 1.
187Oracle stellt einfach fest, „SAP erkannte, dass es technisch nicht machbar war, MySQL so zu skalieren, dass es die Arbeitslasten unterstützen könnte, für die die SAP-Anwendungen ausgelegt waren, und kündigte die Entwicklungsvereinbarung aus diesem Grund“ [„SAP concluded that it was technologically not feasible to scale up MySQL to support the workloads for which SAP’s applications were designed, and therefore it cancelled the development agreement“] (Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), S. 84 (doc_ID 2427)); allerdings legt Oracle keinerlei Referenzen oder andere Nachweise für diese Auffassung vor. Tatsächlich scheint es entgegen den Feststellungen von Oracle Hinweise darauf zu geben, dass SAP-Anwendungen in einigen Unternehmen erfolgreich auf Basis von MySQL laufen, „Ziff Davis Enterprise-Peerstone Database Survey“ (doc_ID 973), S. 3.
188Siehe Präsentation von SAP bei der Anhörung am 10. und 11. Oktober 2009.
189Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), S. 76-82 (doc_ID 2427).
61auszubauen, denn dafür wären umfassendere Entwicklungsarbeiten einhergehend mit höheren Risiken erforderlich.
230.Verschiedene Unternehmen entwickeln gegenwärtig Speicher-Engines für MySQL. So gibt z. B. ScaleDB an, eine integrierbare Speicher-Engine anbieten zu wollen, mit der MySQL wie Oracle RAC, ein High-End-Datenbankprodukt, werde arbeiten können. Die Speicher-Engine von ScaleDB wird Funktionsmerkmale bieten, die bislang keine andere MySQL-Speicher-Engine aufweist. Ein anderes Unternehmen, Calpont, entwickelt eine Speicher-Engine für die Nutzung in Analyse- und Data-Warehousing-Umgebungen, die laut Calpont das MySQL-Datenbank-Managementsystem für drei wichtige Data-Warehousing-Märkte verbessern wird: Business Intelligence, Hochleistungsrechnertechnik und Speicheranwendungen. Die Speicher-Engine von Calpont wird für eine Skalierbarkeit auf Hunderte von Terabyte entwickelt.
231.Die Entwicklung dieser Speicher-Engines von Drittanbietern scheint von MySQL als Reaktion auf die Übernahme der Speicher-Engine InnoDB durch Oracle im Oktober 2005 gefördert worden zu sein. […]*.Zudem verwendet MySQL seit MySQL 5.1, das im November 2008 veröffentlicht wurde, eine modulare Speicher-Engine-Architektur, die das dynamische Hinzufügen von Speicher-Engines zu einem vorhandenen MySQL-Server ermöglicht, d. h., weder MySQL noch die Speicher-Engine müssen neu kompiliert werden, um zusammenzuarbeiten.
232.Zusammenfassend ist festzustellen, dass MySQL nicht auf Anwendungen beschränkt zu sein scheint, in denen es als Speicherlösung für Webserver oder Webanwendungen genutzt wird. MySQL kommt in Kombination mit verschiedenen Speicher-Engines in technischer Hinsicht für andere Segmente des Datenbankmarktes in Frage, so z. B. für Data-Warehousing und für die Nutzung in eingebetteter Form. Dennoch räumt die Kommission ein, dass es High-End-Anwendungen gibt, für die MySQL nicht geeignet ist.
233.Da sowohl Speicher-Engines als auch der zentrale MySQL-Server weiterentwickelt werden, dürfte sich der Teil des Gesamtmarktes für Datenbanken, für den MySQL als Option relevant ist, weiter vergrößern. Die modulare Architektur von MySQL bedeutet, dass von MySQL ausgeübter Wettbewerbsdruck nicht nur von dem von Sun angebotenen MySQL ausgeht, sondern auch von dem Ökosystem von Drittanbietern von Speicher-Engines. Wenn im übrigen Teil des vorliegenden Beschlusses auf MySQL Bezug genommen wird, so ist dieser Begriff ggf. auch als das MySQL-Ökosystem umfassend zu verstehen.
190Siehe TAEUS-Bericht, S. 54 (doc_ID 3011).
191Antwort von ScaleDB auf das an Anbieter von Speicher-Engines gerichtete Auskunftsersuchen (doc_ID 2489). Protokoll einer Telefonkonferenz (doc_ID 3036).
192Antwort von Calpont auf das an Anbieter von Speicher-Engines gerichtete Auskunftsersuchen (doc_ID 1939). Protokoll einer Telefonkonferenz (doc_ID 2896).
193(Doc_ID 3126). Siehe auch eine Pressemitteilung von MySQL, „MySQL AB präsentiert neue Open-Source-Datenbank-Engines von Premier-Partnern und aus der Entwicklergemeinde“ [„MySQL to Promote New Open Source DB Engines from its Partners and Dev Community“] (doc_ID 3351), in der ein Zertifizierungsprogramm für Speicher-Engines von Dritten angekündigt wird.
4.3.3.3.Das Open-Source-Geschäftsmodell und das Preismodell von MySQL
234.Datenbanken wie MySQL, die als Open-Source-Software vertrieben werden, basieren auf einem bestimmten Geschäftsmodell. In einem Open-Source-Geschäftsmodell werden die Endnutzer, die Softwareanbieter, die das Produkt als Grundlage für eigene Produkte nutzen, Diensteanbieter und der Inhaber der Urheberrechte am Quellcode miteinander vernetzt. All diese an dem Netzwerk Beteiligten können je nach ihren Fähigkeiten und Interessen als Entwickler tätig werden. Durch den Beitrag eines Entwicklers wird das Produkt sowohl für die Nutzer als auch für die anderen Entwickler verbessert. Unter der Open-Source-Lizenz ist der Quellcode von MySQL zudem für Endnutzer kostenlos zur Nutzung verfügbar, wobei jedoch gewisse Einschränkungen gelten.
235.MySQL wird unter dem dualen GPL-Lizenzierungsmodell zur Verfügung gestellt: Die Kunden haben die Wahl, MySQL Server zu erwerben oder kostenlos eine Open-Source-Lizenz zu erhalten. Zahlenden Kunden wird ein Abonnement in Rechnung gestellt, das die Datenbanklizenz (proprietär oder Open-Source), bestimmte Tools sowie Support umfasst. Die Open-Source-Lizenz hingegen ist kostenlos verfügbar, umfasst keinen Support und entspricht in ihren Bedingungen der GPLv2-Lizenz.
236.Bei GPLv2 besteht die Einschränkung, dass bei der kommerziellen Vermarktung eines Produkts, das unter GPLv2 lizenzierten MySQL-Quellcode in veränderter oder unveränderter Form enthält und somit ein „abgeleitetes Werk” im Sinne des Urheberrechts darstellt, der Code des gesamten kommerziell vertriebenen Produkts offengelegt werden muss. Dies wird als die „virale“ oder „ansteckende“ Wirkung der Open-Source-Version von MySQL bezeichnet. Die GPL-Lizenz ist jedoch mit keinerlei Einschränkungen bei der Endnutzung des Produkts verbunden, so dass das Produkt für die eigene Nutzung beliebig geändert werden kann.
237.Im Rahmen dualer Lizenzierungsmodelle (wie dem von MySQL angewandten), bei denen sowohl kommerzielle als auch GPL-Lizenzen erhältlich sind, können kommerzielle Lizenznehmer den geänderten Code oder Anwendungen/Produkte, in die der ursprüngliche Code eingebettet ist, im Binärformat (d. h. als Closed-Source) vertreiben. MySQL bietet ein spezielles Lizenzmodell für OEM-Kunden/Kunden, die MySQL in eingebetteter Form nutzen und sich nicht an die Bedingungen der GPLv2 halten können oder möchten, sondern eine proprietäre Lizenz für MySQL erwerben.
238.Was die Beiträge zur Entwicklung von MySQL anbelangt, so kann ein mitwirkender Entwickler, der nicht Inhaber der Urheberrechte ist, i. A. aus seiner Verbesserung keine angemessenen Erlöse erzielen, da nur der Inhaber der Urheberrechte kommerzielle Lizenzen ausgeben kann. Zudem kann der Inhaber der Urheberrechte bis zu einem gewissen Grad kostenlos von den Beiträgen der unabhängigen Entwickler profitieren und die Rendite aus deren Investition für sich beanspruchen. Aufgrund der eingeschränkten Möglichkeiten, die sich Entwicklern unter der GPL-Lizenz bieten, selbst von ihren Innovationen wirtschaftlich zu profitieren, sind unabhängige Entwickler weniger motiviert, sich an der Entwicklungsarbeit zu beteiligen. Daher ist es häufig der Inhaber der Urheberrechte, der den größten Beitrag zu dem Code leistet.
194Oracle ist die bekannteste Open-Source-Softwarelizenz, die es nicht nur gestattet, sondern sogar fordert, dass veränderte Versionen von Software, die unter der GPL lizenziert wurde, ebenfalls der GPL unterliegen. Das bedeutet im Wesentlichen, dass Software, die bereits einmal unter der GPL frei verfügbar gemacht wurde, nicht wieder „unfrei“ werden kann, da die Rechte nach der GPL weiter befördert werden. Der Inhaber des Urheberrechts (die Person, die die Software als erste unter GPL freigegeben hat) kann hingegen seine Software unter verschiedenen Lizenzen parallel anbieten (Dual- oder Multilizenzierung).
63selbst von ihren Innovationen wirtschaftlich zu profitieren, sind unabhängige Entwickler weniger motiviert, sich an der Entwicklungsarbeit zu beteiligen. Daher ist es häufig der Inhaber der Urheberrechte, der den größten Beitrag zu dem Code leistet.
239.Aufgrund seines Open-Source-Modells gewährt MySQL im Gegensatz zu Anbietern proprietärer Datenbanken Lizenzen für seine Datenbanksoftware kostenlos. Die einzigen Einschränkungen, die den Nutzern auferlegt werden, sind die auf GPLv2 zurückgehenden. Nur einige MySQL-Nutzer zahlen eine Lizenzgebühr und nur einige Nutzer zahlen für den MySQL-Support. Anbieter proprietärer Datenbanken berechnen i. d. R. eine Lizenzgebühr für ihre Datenbanken. Daneben berechnen sie Supportgebühren und legen den Quellcode ihrer Produkte nicht offen.
240.Selbst für Nutzer, die eine proprietäre Lizenz erwerben, ist die Lizenzgebühr für MySQL häufig erheblich geringer als die für andere proprietäre Datenbanken zu entrichtende Lizenzgebühr. MySQL behauptet, sein Abonnementdienst für MySQL Enterprise werde zu erheblich günstigeren Bedingungen angeboten als proprietäre Angebote. Laut MySQL wird der Dienst pro Server verkauft und nicht nach der Zahl der CPUs, Chips oder Prozessorkerne. Der Preis bei Oracle werde z. B. mit komplizierten Formeln anhand der Prozessorkerne pro Server berechnet, wobei die Nutzer für den Einsatz leistungsstärkerer Hardware zur Kasse gebeten würden.
241.Die Marktuntersuchung der ersten Phase zeigte den sehr großen Preisunterschied zwischen den Datenbankprodukten von Oracle und MySQL. Die Preise einer Lizenz für MySQL Enterprise Edition liegen zwischen 599 USD pro Server und Jahr für MySQL Enterprise Basic und 4.999 USD pro Server und Jahr für MySQL Enterprise Platinum. Die Preise unbefristeter Lizenzen pro Prozessor für die verschiedenen Editionen von Oracle Database liegen zwischen 5.800 USD für Standard Edition One und 47.500 USD für die Enterprise Edition.
242.Es ist zu beachten, dass es sich bei den genannten Preisen um Listenpreise handelt. Die großen Datenbankanbieter räumen i. d. R. vielen Kunden hohe Rabatte auf ihre Datenbanken ein. Im Rahmen eines solchen Rabattsystems können Datenbankanbieter wie Oracle eine Preisdiskriminierung zwischen ihren Kunden vornehmen. Bei einem Vergleich der Listenpreise wird somit die Preisdifferenz zwischen Anbietern proprietärer Datenbanken und Anbietern von Open-Source-Datenbanken überbewertet.
243.Kosten sind für Kunden ein wichtiger Faktor bei der Wahl einer Datenbank. Dies ist durch zwei Erhebungen belegt. In einer von TNS Technology im Auftrag von Sun durchgeführten Erhebung zur Nutzung von Open-Source-Software in kleinen und mittleren Unternehmen wurden am häufigsten (von 60 % der Befragten) die Kosten als wesentliches Motiv für den Einsatz von Open-Source-Software genannt. Dies wird durch eine von TNS Technology im Auftrag von Sun in den nordischen und den Benelux-Ländern durchgeführte Erhebung bestätigt, in der Kosteneinsparungen ebenfalls am häufigsten als Motiv für die Nutzung von Open-Source-Software genannt.
195MySQL – „A guide to lower database TCO“ (doc_ID 130), S. 9. Siehe ferner TAEUS-Bericht (doc_ID 3011), Anhänge B und H.
196Formblatt CO, S. 147 (doc_ID 305).
197Siehe Anhang 1 zu Formblatt CO, S. 14 (doc_ID 307).
198TNS Technology – „Open Source Barometer 2009 – European SMB Report“, S. 12 (doc_ID 2673).
199wurden.Darüber hinaus nannten in der Marktuntersuchung der zweiten Phase zahlreiche Kunden die Gesamtbetriebskosten als einen der zentralen Faktoren bei der Entscheidung für den Einsatz einer kostenlosen Open-Source-Datenbank. Ein Beispiel in diesem Bereich ist, wie Linux den Markt für Betriebssysteme durchdrungen hat.
244.Die Kosten für eine Datenbank sind nicht auf die Lizenzkosten beschränkt. Häufig werden die Gesamtbetriebskosten (Total Cost of Ownership, TCO) einer Datenbank in dem Bestreben berechnet, die Kosten verschiedener Datenbanken miteinander zu vergleichen und Preistransparenz zu erzielen. In die Gesamtbetriebskosten können unterschiedliche Elemente einfließen, z. B. Computerhardware und Programme sowie Betriebskosten (die von Stromkosten und Ausfallzeiten bis hin zu IT-Personal reichen können). Es gibt jedoch keine allgemeinverbindliche Definition der Elemente, die in die Berechnung der Gesamtbetriebskosten einfließen sollten. Obgleich einzuräumen ist, dass eines der wichtigsten „Verkaufsargumente“ für Open-Source-Datenbankprodukte die aufgrund nicht anfallender Lizenzgebühren scheinbar geringen Kosten im Vergleich mit proprietären Datenbankprodukten sind, so sind doch bei der Einführung und anschließenden Nutzung eines Open-Source-Produkts möglicherweise unternehmensinterne Fachkenntnisse erforderlich, ein Faktor, der auch gegen die Kostenersparnisse bei den Lizenzgebühren abzuwägen ist. Zudem werden bei einer auf Basis von Listenpreisen durchgeführten Berechnung der Gesamtbetriebskosten keine Rabatte oder Nachlässe auf Listenpreise berücksichtigt, die ein Anbieter proprietärer Datenbanken möglicherweise Bestandskunden oder potenziellen Kunden anbietet.
245.MySQL gibt auf seiner Website an, MySQL wirke sich laut IDC folgendermaßen auf die Gesamtbetriebskosten aus:
Senkung der Lizenzkosten für die Datenbank um über 90 %
Reduzierung von Systemausfallzeiten um 60 %
Senkung der Ausgaben für Hardware um 70 %
Reduzierung der Kosten für Verwaltung, technische Arbeiten (Engineering) und Support um bis zu 50 %.
246.TAEUS legt eine Gesamtbetriebskostenanalyse der Datenbanken der wichtigsten Anbieter für drei hypothetische Nutzer vor, nämlich ein typisches kleines Unternehmen, ein mittelgroßes Unternehmen sowie ein großes und weiter wachsendes Unternehmen. In die Analyse sind Kosten für den Erwerb des Produkts und drei Jahre Betrieb unter der Prämisse, dass für alle Nutzer Wartungsleistungen erforderlich waren, eingeflossen. Die Analyse basiert auf Listenpreisen ohne mögliche Rabatte.
247.TAEUS kommt zu dem Ergebnis, dass bei dem kleinen Unternehmen die Gesamtbetriebskosten für Oracle leicht unter denen für MySQL liegen. Bei dem mittelgroßen und dem großen Unternehmen bietet sich ein anderes Bild. In dem mittelgroßen Unternehmen belaufen sich die Gesamtbetriebskosten für MySQL auf weniger als 5 % der Gesamtbetriebskosten für Oracle und bei dem großen Unternehmen entsprechen die Gesamtbetriebskosten für MySQL rund 25 % der Gesamtbetriebskosten für Oracle.
248.Insgesamt gelangt TAEUS zu dem Schluss, dass IBM über die gesamte Produktlinie hinweg praktisch identische Funktionsmerkmale anbietet. Wahrscheinlich liegt es zum großen Teil daran, dass die Preise von IBM viel eher konstant sind als die der anderen Anbieter, weshalb IBM bei den kleinsten Systembereitstellungen nicht konkurrieren kann, seine Preise dafür jedoch bei größeren Systembereitstellungen nach und nach immer attraktiver werden.
249.Die Preispolitik von Oracle steht in genauem Gegensatz zu der von IBM. Bei kleineren Systembereitstellungen sind die Preise von Oracle relativ niedrig, steigen jedoch bei größeren Systembereitstellungen steiler an als bei den meisten anderen Anbietern. Bei den größten Systembereitstellungen liegt der Preis von Oracle nur noch hinter dem von Sybase.
250.Bei Sybase erfolgt die Lizenzierung pro Prozessorkern. Dadurch ist die Erhöhung bei größeren Systembereitstellungen extremer als bei Oracle. Bei den kleinsten Systembereitstellungen ist Sybase preislich sehr wettbewerbsfähig. Bei den größten Bereitstellungen liegen die Preise von Sybase weit über denen anderer berücksichtigter Anbieter.
251.MySQL und PostgreSQL können bei den kleinsten Systembereitstellungen preislich konkurrieren und weisen bei den größten Systembereitstellungen die mit Abstand niedrigsten Preise auf. Während die Preisniveaus von MySQL und PostgreSQL unmittelbar miteinander vergleichbar sind, kommt keiner der anderen Anbieter bei einer großen Systembereitstellung auch nur annähernd an eines dieser Softwarepakete heran.
4.3.3.4.Geringere Bindung an einen Anbieter
252.Dass MySQL in Open-Source-Form verfügbar ist, bedeutet, dass MySQL weniger von Hold-ups betroffen ist als Closed-Source-Datenbanken. Der Inhaber der Urheberrechte an der Open-Source-Datenbank ist in seinen Möglichkeiten zur Erhöhung der Preise (genauer gesagt der Gesamtbetriebskosten) für gebundene Kunden eingeschränkt, da der Quellcode kostenlos verfügbar ist und die unabhängigen Entwickler in der Community (oder die Kunden selbst) in der Lage sind, alternative Upgrades und Patches bereitzustellen (selbst wenn diese von geringerer Qualität als die vom Inhaber der Urheberrechte bereitgestellten sind) sowie Support zu leisten.
253.Das Open-Source-Modell von MySQL und die Tatsache, dass jeder den Code überprüfen kann, bedeutet, dass jeder Supportdienstleistungen anbieten kann. Aufgrund der Transparenz des Produktentwurfs können viele Unternehmen mit dem Angebot von Dienstleistungen in Bezug auf das Produkt in den Wettbewerb eintreten, was zu einem recht starken Wettbewerb auf dem Gebiet der Supportdienstleistungen führen dürfte.
254.Auf dem Markt für Supportdienstleistungen für eine bestimmte Open-Source-Datenbank herrscht aller Wahrscheinlichkeit nach ein starker Wettbewerb. Bei Closed-Source-Datenbanken hängt das Ausmaß des Wettbewerbs auf dem Markt für Supportdienstleistungen u. a. von der Fähigkeit des Inhabers der Urheberrechte ab, nur durch den Verkauf von Lizenzen Einnahmen zu erzielen. Wenn der Datenbankanbieter nicht seine gesamten Einnahmen oder den größten Teil davon auf diese Weise erzielen kann, hat er möglicherweise ein Interesse daran, sich auch auf dem Markt für den Support des eigenen Datenbankprodukts ein Monopol zu sichern, statt den Wettbewerb im Zusammenhang mit diesen Leistungen zu fördern.
201Siehe TAEUS-Bericht, S. 68-78 (doc_ID 3011).
263.Abschließend scheint MySQL in technischer Hinsicht in einem Teil des Datenbankmarktes wettbewerbsfähig zu sein. Allerdings weist MySQL auch gewisse Einschränkungen auf, insbesondere die, dass es im High-End-Segment des Datenbankmarktes nicht wettbewerbsfähig ist. Durch seine Eigenschaft als Open-Source-Produkt und sein Preismodell ebenso wie durch seine modulare Architektur und das System der Drittanbieter von Speicher-Engines nimmt MySQL eine besondere Wettbewerbsposition ein. Eine geringere Bindung an einen Anbieter macht das Produkt für die Kunden noch attraktiver. Es ist zu erwarten, dass MySQL weiterentwickelt wird und somit potenziell zu einer dynamischen Wettbewerbskraft wird.
4.3.4.Nachweise für den von MySQL auf Oracle und andere Anbieter proprietärer Datenbanken ausgeübten Wettbewerbsdruck
4.3.4.1.Nachweise in Bezug auf den Gesamtmarkt für Datenbanken
264.Aus der Auswertung in Abschnitt 4.3.3. ergibt sich, dass MySQL unter dem Gesichtspunkt von Technologie und Funktionalität Oracle in Teilen des Datenbankmarktes ersetzen kann und MySQL in diesen Fällen aufgrund seines speziellen Charakters eine besondere Wettbewerbskraft darstellen könnte.
265.In ihrer eingehenden Untersuchung hat die Kommission verschiedene Informationsquellen ausgewertet und Beweise dafür gefunden, dass MySQL vor dem Zusammenschluss auf dem Gesamtmarkt für Datenbanken mit Oracle zu konkurrieren scheint. Diese Informationsquellen umfassen im Einzelnen einen internen Datenbestand von Oracle, HQ Apps, interne Dokumente von Oracle und Sun, Erhebungen sowie
205Rückmeldungen von Wettbewerbern und Kunden von Oracle und MySQL, die die Fragebögen der Kommission beantwortet haben.
4.3.4.1.1.HQ Apps und CRM
266.Die Anmelderin hat zwei Datenbestände vorgelegt, die ihrer Meinung nach belegen, dass MySQL keinen Wettbewerbsdruck auf Oracle ausübt. Die Anmelderin trifft folgende Aussage: „Es kann keinen besseren Beweis für die Kundenwahrnehmung eines engen Wettbewerbs zwischen Datenbankanbietern geben als eine zum Zeitpunkt der Kaufentscheidung erstellte Aufzeichnung der tatsächlich in Erwägung gezogenen Alternativen. Oracle sammelt diesbezügliche Informationen täglich in zwei Formen: a) in die CRM-Datenbank (Customer Relationship Management, Kundenbeziehungsmanagement) von Oracle eingegebene Daten, in denen i. d. R. bei jeder Geschäftschance die Wettbewerber aufgeführt werden, und b) E-Mail-Anfragen von Vertriebsmitarbeitern an eine zentrale E-Mail-Adresse (HQ Apps) zur Einholung der Genehmigung der Geschäftsleitung für Preisnachlässe an Kunden.“ [„there can be no better evidence of a customer's perception of closeness of competition between database vendors than a contemporaneous record of the competitive alternatives actually considered at the time of purchase. Oracle acquires information about this every day in two forms: (a) data entered in Oracle's customer relationship management (or CRM) database, which typically list competitors in any given sales opportunity; and (b) e-mail requests submitted by sales personnel to a centralised email address (HQ Apps) for executive approval of price discounts to customers.“]
267.Die Anmelderin trägt ferner vor, dass beide Datenbestände „beweisen, dass MySQL bei Oracle im Verkaufszyklus selten und in erfolgskritischen Anwendungsbereichen gar nicht genannt wird“ [„prove that MySQL rarely registers with Oracle in the purchasing cycle, and not at all in respect of mission-critical deployments“].Die Anmelderin gibt an, MySQL sei gegenüber Oracle nur in Marktsegmenten wettbewerbsfähig, in denen zahlreiche Drittanbieter präsent seien (z. B. bei eingebetteten Anwendungen für Mobiltelefone und Webanwendungen), weshalb MySQL im High-End-Segment keinen Wettbewerbsdruck auf Oracle ausübe.
268.Die von der Kommission durchgeführte Auswertung von HQ Apps hingegen hat ergeben, dass MySQL und Oracle in einigen Segmenten des Gesamtmarktes für Datenbanken miteinander im Wettbewerb zu stehen scheinen, und zwar im Hinblick auf verschiedene Typen der Datenbanknutzung (Web, transaktionsorientiert, Unternehmensanwendungen, eingebettet), über zahlreiche Sektoren hinweg, um kleine wie um große Unternehmen ebenso wie um kleine und große Projekte. Ferner zeigt HQ Apps, dass in den Segmenten des Gesamtmarktes für Datenbanken, in denen MySQL und Oracle miteinander im Wettbewerb stehen, MySQL einen wichtigen Wettbewerbsdruck auf Oracle auszuüben scheint.
269.In früheren Fällen hat die Kommission oftmals analoge CRM-Daten als ein Element zur Bewertung eines Wettbewerbsdrucks herangezogen. In der vorliegenden Sache legt die von der Kommission durchgeführte Auswertung der CRM-Daten von Oracle den Schluss nahe, dass diese für sich allein betrachtet aus verschiedenen Gründen, möglicherweise auch aufgrund des Open-Source-Charakters von MySQL, nicht unbedingt eine vollkommen realistische Einschätzung des von MySQL ausgeübten Wettbewerbsdrucks ermöglichen (siehe Randnummer 335 bis 362). Dieser Schluss wird durch einen Vergleich mit Daten aus HQ Apps von Oracle untermauert (siehe Randnummer 363 bis 364).
4.3.4.1.1.1.HQ Apps
Beschreibung von HQ Apps
270.HQ Apps ist ein interner Datenbestand („Dataset“) von Oracle, der den Austausch zwischen den Vertriebsteams und der Zentrale von Oracle über nicht standardmäßige Rabatte enthält, die Oracle seinen Kunden anbietet. Dieser Austausch betrifft alle Oracle-Produkte, nicht nur Datenbanken. Die Anmelderin gab an, dass bei Rabatten von mehr als […]* auf den Listenpreis die Genehmigung des zuständigen Teams in der Zentrale eingeholt werden muss, das als „HQ Apps“ (Headquarters Approvals) bezeichnet wird. Dieses Team bearbeitet auch Anfragen bezüglich vom Standard abweichender Vertragsbedingungen, die sich nicht auf den Preis beziehen.Nach Aussage von Oracle erstreckt sich der HQ Apps-Prozess auf alle Vertriebskanäle […]*.
271.Der Anmelderin zufolge handelte es sich bei HQ Apps um eine riesige Sammlung von über […]* unstrukturierter E-Mails, die an eine zentrale E-Mail-Adresse gesendet wurden. Für den Zeitraum zwischen Januar 2008 und Mai 2009 liegen […]* Dokumente vor.
272.Die Kommission forderte Einsicht in alle HQ Apps-Dokumente.
273.Die Anmelderin gewährte Einsicht in HQ Apps-Dokumente, die sich auf mindestens eines der fünf wichtigsten Datenbankprodukte von Wettbewerbern beziehen, nämlich auf MySQL, DB2, SQL Server, Sybase und EnterpriseDB. Die Anmelderin wurde zudem gebeten, jeden weiteren als bedeutend erachteten Wettbewerber in der Suchabfrage zu berücksichtigen.Die Anmelderin trug jedoch vor, „die von Ihnen [der Kommission] geforderten und von uns ausgeführten Suchabfragen sind zwar nicht erschöpfend, sollten jedoch für die von Ihnen [der Kommission] gewünschten Bezugsdaten ausreichend sein“ [„[…] while not exhaustive, the search queries that you have requested and we have executed should be sufficient to provide the benchmark that you seek to establish“].
274.Die vollständige Liste der [30.000 – 40.000]* HQ Apps-Dokumente, die den Suchparametern entsprachen, wurde am 1. Oktober 2009 zur Einsicht vorgelegt.
Auffassung der Anmelderin bezüglich HQ Apps
275.Oracle trug vor, HQ Apps zeige, dass Oracle und MySQL nicht miteinander im Wettbewerb stünden. Diese Auffassung hat Oracle verschiedentlich in der Korrespondenz mit der Kommission bekräftigt. So argumentierte Oracle z. B. in einer E-Mail an die Kommission wie folgt: „[...] Oracle prüfte auf Aufforderung des US-Justizministeriums fast […]* HQ Apps-Dokumente (E-Mails und Anlagen) aus dem Zeitraum Januar 2008 bis Mai 2009. Dabei handelte es sich um alle Dokumente, die für diesen Zeitraum im Ordner für gesendete Objekte des HQ Apps-E-Mail-Kontos vorlagen. Davon enthalten nur […]* Dokumente (das sind [0-5]* % der ausgewerteten Dokumente) irgendeinen Hinweis auf MySQL als tatsächlichen oder potenziellen Wettbewerber. Es ist nur schwer vorstellbar, wie MySQL ein solch enger Wettbewerber von Oracle sein kann, wenn es nur in weniger als [0-5]* % der Angebote von Wettbewerbern und weniger als [0-5]* % der Anfragen nach Preisnachlässen für Oracle-Datenbanken erwähnt wird. Unserer Ansicht nach sind diese Daten höchst aufschlussreich…“ [„[…] at the request of the U.S. Department of Justice, Oracle reviewed nearly […]* HQ Apps documents (email and attachments) covering the period from January 2008 to May 2009, representing all the documents that existed in the "Sent" folder of the HQ Apps email account for that period. Of those, only […]* documents (representing [0-5]*% of the documents analysed) contained any mention of MySQL as an actual or potential competitor. It is difficult to imagine how MySQL is such a close competitor of Oracle when it only shows up in less than [0-5]% of competitive bids and less than [0-5]% of requests for discounts on Oracle databases. In our view, this data is simply insurmountable…“]
276.Andererseits gab Oracle an, dass HQ Apps verschiedene Schwächen aufweise. Nach Aussage des Unternehmens bestand die einzige sinnvolle Art der Suche darin, nach allen Vorkommen von MySQL in der Rechtfertigung [„justification“] für die Einräumung des vom Standard abweichenden Rabatts zu suchen („justification“ ist ein bestimmtes Feld, das jedoch nicht systematisch ausgefüllt wird). Ferner trug die Anmelderin Folgendes vor: „HQ Apps ist nur von begrenztem Nutzen, wenn es darum geht, die Identität und die Häufigkeit der Nennung von Wettbewerbern zu ermitteln. HQ APPS-E-Mails sind unvermeidlicherweise unvollständig und subjektiv. Wenn ein Vertriebsmitarbeiter eine Anfrage an HQ APPS stellt, geht es weder um Vollständigkeit noch um Präzision, wie sie für Aufzeichnungen über den Wettbewerb erforderlich wären, sondern einfach darum, die Genehmigung für einen Abschluss einzuholen, bei dem ein höherer Rabatt als üblich gewährt wird. Folglich kann nicht davon ausgegangen werden, dass die E-Mails an HQ APPS vollständige Angaben zu den jeweils relevanten Wettbewerbern enthalten. Ebenso wenig sollte man sich übermäßig stark darauf verlassen, dass eine E-Mail die tatsächliche Wettbewerbssituation im Zusammenhang mit einem Kunden widerspiegelt.
211Siehe E-Mail von Oracle an die Kommission vom 2 Oktober 2009 (doc_ID 2479).
212Siehe E-Mail von Oracle an die Kommission vom 1. Oktober 2009 (doc_ID 2961).
213E-Mail von Oracle an die Kommission vom 26. August 2009 (doc_ID 1080).
incomplete and subjective. The goal of the sales rep submitting the HQ APPS request is neither completeness nor accuracy for the sake of providing a record of competition, but simply to obtain approval to close a deal at a greater than usual discount. As a result one should not expect the HQ APPS emails to include a complete account for competitors faced, nor should one place undue reliance on the email's ability to capture actual competition within an account.
277.In ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte vertrat Oracle die Auffassung, „die HQ Apps-E-Mails bilden gemäß ihrer Bestimmung nur eine kleine Teilmenge der Geschäftschancen von Oracle ab und sind daher nicht geeignet, die Schlussfolgerungen aus der Auswertung der CRM-Datenbank außer Kraft zu setzen“ [„since the HQ Apps emails are by design a small subset of all Oracle sales opportunities, they cannot overturn the conclusions from the analysis of the CRM database“].
Auffassung der Kommission bezüglich HQ Apps
278.Nach Auffassung der Kommission ist das von Oracle vorgetragene Argument bezüglich der Motive der Vertriebsmitarbeiter zur Angabe unvollständiger und subjektiver Informationen über Wettbewerber nicht hinreichend stichhaltig, um die Beweiskraft von HQ Apps zu schwächen.
279.Zwar ist es möglich, dass Vertriebsmitarbeiter ein Interesse daran haben, das Maß des Wettbewerbs systematisch zu übertreiben, um sicherzustellen, dass die Rabatte gewährt und die Geschäfte zum Abschluss gebracht werden, jedoch wäre ihnen klar, dass die Unternehmenszentrale Rabatte nur auf Grundlage glaubwürdiger Rechtfertigungen gewähren würde. Genau die Vermeidung nicht erforderlicher und kostenintensiver Rabatte auf nicht überzeugende Rechtfertigungen hin ist der Grund, warum diese Anfragen strukturiert gestellt und glaubwürdig gerechtfertigt werden müssen, bevor sie möglicherweise durch die Zentrale genehmigt werden können. Tatsächlich geht aus den E-Mails im HQ Apps-Posteingang eindeutig hervor, dass die Zentrale häufig weitere Details anfordert, bevor sie einen Rabatt genehmigt, und in manchen Fällen auch die Rechtfertigung in Frage stellt. Und selbst wenn angenommen wird, dass Vertriebsmitarbeiter kein Interesse daran hätten, uneingeschränkt objektive Information an HQ Apps zu senden, so würde dies nicht bedeuten, dass die Gesamtzahlen die Referenzwerte in eine bestimmte Richtung verzerren würden.
280.HQ Apps scheint besonders im Hinblick auf den Wettbewerb um Großkunden sehr aussagekräftig zu sein. Wie durch ein internes Dokument von Oracle bestätigt, […]*.
281.Ferner scheint der von MySQL ausgehende Wettbewerbsdruck in HQ Apps eher unterschätzt zu werden. Kunden können vielfach die Open-Source-Software zu geringen Kosten oder unter der GPL-Lizenz kostenlos nutzen, indem sie diese einfach herunterladen. Es liegt nahe, dass die Kunden in vielen dieser Fälle keinen Kontakt mit Vertriebsmitarbeitern aufnehmen, um Rabatte zu erbitten, jedoch trotzdem die Kosten und Funktionsmerkmale verschiedener Alternativen (zumindest implizit) vergleichen.
282.In HQ Apps wird naturgemäß nur eine Teilmenge aller Geschäftschancen erfasst. Dennoch ist dieser Datenbestand von besonderem Interesse, da die Vertriebsmitarbeiter darin den Wettbewerbsdruck sehr viel detaillierter zu erörtern scheinen, als dies in den CRM-Daten von Oracle der Fall ist. Die Aussagekraft von HQ Apps wird nicht dadurch geschmälert, dass dieser Datenbestand kleiner ist als der CRM-Datenbestand.
283.Daher vertritt die Kommission die Auffassung, dass in der vorliegenden Sache der HQ Apps-Datenbestand von Oracle nützliche Informationen über das Ausmaß des auf dem Datenbankmarkt von MySQL auf Oracle ausgeübten Wettbewerbsdrucks enthält.
In HQ Apps genannte Wettbewerber von Oracle
284.Die Kommission führte zunächst Gesamtsuchvorgänge aus, um zu ermitteln, wie häufig die wichtigsten Wettbewerberdatenbanken in den HQ Apps-Dokumenten erwähnt werden. In Anbetracht des der Kommission vorgelegten Auszugs aus den HQ Apps-Dokumenten und des Zwecks der Auswertung sind Vergleiche insgesamt in den Dokumenten am sinnvollsten, in denen mindestens ein Wettbewerberprodukt genannt wird. Diese Überprüfung des Datenbestands ergab einen Satz von [10.000 – 20.000]* Dokumenten.
285.Zudem verwendete die Kommission bei der Suche nicht die Datenbanknamen, sondern die Namen der Wettbewerber von Oracle (z. B. nicht Microsoft, sondern SQLServer). Dadurch wurde verhindert, dass Dokumente gefunden wurden, in denen Microsoft, IBM oder Sun genannt werden, die Rabattanfrage sich jedoch nicht auf Datenbankprodukte bezieht. Das Stichwort „Sun“ ergibt mehr Treffer in der vorgelegten Dokumentsammlung, allerdings besitzt nach Auffassung der Kommission ein solches Suchergebnis keine Aussagekraft bezüglich des von MySQL ausgeübten Wettbewerbsdrucks.
286.Die Gesamtsuchergebnisse aus diesem Datenbestand von [10.000 – 20.000]* Dokumenten lauten wie folgt:
– „MySQL“ wird […]* Mal erwähnt ([20-30]* %).
– „DB2“ von IBM wird […]* Mal erwähnt ([40-50]* %).
– „SQL Server“ von Microsoft wird […]* Mal erwähnt ([30-40]* %).
– „Sybase“ wird […]* Mal erwähnt ([10-20]* %).
– „PostgreSQL“ wird […]* Mal erwähnt ([0-5]* %).
218Die Kommission hat die Anmelderin auch gebeten, alle HQ Apps-Dokumente zur Verfügung zu stellen, um das Ausmaß möglicher Probleme in dieser Frage einschätzen zu können, jedoch hat die Anmelderin die erweiterte Einsicht in ihre HQ Apps-Dokumente abgelehnt.
219So könnte sich „Sun“ z. B. auf den Sonntag (engl. „Sunday“, abgekürzt als „Sun“) statt auf das Unternehmen Sun Microsystems beziehen.
287.In der Gesamtsuche findet sich der Begriff „MySQL“ somit in [20-30]* % der Dokumente, in denen mindestens eine Wettbewerberdatenbank erwähnt wird. DB2 von IBM, die am häufigsten genannte Wettbewerberdatenbank, wird […]* so häufig wie MySQL genannt, SQL Server von Microsoft wird in […]* Dokumenten genannt. Der Anteil der Dokumente, in denen PostgreSQL, der am zweithäufigsten genannte Open-Source-Wettbewerber, genannt wird, beträgt lediglich ein […]* des Anteils von MySQL. Sybase, nach Meinung der Anmelderin ein starker Wettbewerber, wird weniger häufig als MySQL genannt (rund [10-20]* % der Dokumente).
288.Ferner ist in [10-20]* % der Dokumente, in denen mindestens eine Wettbewerberdatenbank genannt wird, tatsächlich MySQL die einzige genannte Datenbank (von den fünf Datenbanken). SQL Server wird in [10-20]* % der Dokumente als einzige Datenbank genannt, DB2 in [30-40]* %, Sybase in [5-10]* % und PostgreSQL in [0-5]* % der Dokumente.
289.Allerdings ist es in einer solchen Gesamtauswertung möglich, dass sich mehrere Dokumente auf denselben Kunden/dieselbe HQ Apps-Anfrage beziehen. Zur Klärung dieser Frage untersuchte die Kommission die HQ Apps-Dokumente, in denen MySQL genannt wird, um zu ermitteln, auf welche Kunden/Geschäftschancen sich die Dokumente beziehen, und eine doppelte Zählung zu vermeiden.
290.Im Rahmen einer eingehenden Auswertung ermittelte die Kommission [200-400]* Kunden (Endnutzer oder Partner), bei denen MySQL genannt wird.
291.Die Kommission forderte die Anmelderin auf, ihrerseits ebenfalls die Kunden zu identifizieren, bei denen in den HQ Apps-Dokumenten die anderen wichtigen Wettbewerberdatenbanken (SQLServer, DB2, Sybase und EnterpriseDB/PostgreSQL) genannt werden, um Referenzwerte für einen aussagekräftigen Vergleich zu ermitteln.
223292.Die Anmelderin gab zunächst an, dass in HQ Apps bei rund [150-300]* Kundennamen Microsoft SQL Server genannt wird, PostgreSQL dagegen nur bei [0-5]*.
224Kunden.Für Sybase nannte die Anmelderin [100-200]* Kundennamen und für IBM DB2 rund [300-600]* Kundennamen.
293.In der Mitteilung der Beschwerdepunkte stellte die Kommission jedoch fest, dass die von der Anmelderin vorgelegten Listen der Kunden, bei denen in HQ Apps DB2, SQL Server, Sybase und Postgres genannt werden, nicht vollständig zu sein schienen und die Zahl der Kunden, bei denen einige dieser Datenbanken als Wettbewerber genannt werden, tatsächlich größer sein könnte.
294.Auf Aufforderung der Kommission zur Bestätigung dieser Zahlen legte die Anmelderin einen Monat nach Annahme der Mitteilung der Beschwerdepunkte, d. h. am 9. Dezember 2009, überarbeitete Listen vor.In den überarbeiteten Listen wurden [500-1000]* Kunden für IBM DB2, [450-900]* Kunden für Microsoft SQL Server, [200-400]* Kunden für MySQL, [150-300]* Kunden für Sybase und [50-100]* Kunden für Postgres aufgeführt.
295.Zudem forderte die Kommission zwecks Ausführung zusätzlicher Prüfungen auf Stichhaltigkeit die Anmelderin auf, eine vollständige Liste von Kunden vorzulegen, für die ein nicht dem Standard entsprechender Rabatt angefordert oder genehmigt wurde. Die Anmelderin gab jedoch an, keine derartigen Aufzeichnungen zu führen.
296.Die Zahlen der Kunden belegen, dass MySQL nicht nur ein unbedeutender Akteur auf dem Datenbankmarkt ist.
297.Zwar erklärte Oracle, „Ingres und EnterpriseDB (PostgreSQL) sind die wettbewerbsfähigsten Open-Source-Datenbanken“ [„Ingres and EnterpriseDB (PostgreSQL) are the most competitive OSS DBs“], jedoch fällt auf, dass in den HQ Apps-Dokumenten, in denen mindestens eine der fünf wichtigsten Wettbewerberdatenbanken genannt wird, MySQL rund 4 Mal häufiger im Zusammenhang mit Kundennamen erscheint als EnterpriseDB (PostgreSQL).
298.Es ist jedoch möglich, dass MySQL in einem HQ Apps-Dokument in einem anderen Zusammenhang als der wettbewerbsbezogenen Rechtfertigung für den Rabatt genannt wird. Zur Klärung dieses potenziellen Problems führte die Kommission eine eingehende Auswertung der Dokumente in Bezug auf MySQL durch. Diese Herangehensweise mag zwar in gewisser Hinsicht subjektiv sein, jedoch gelangte die Kommission zu dem Ergebnis, dass bei [200-400]* von [200-400]* Kunden der Schluss möglich ist, dass MySQL als wettbewerbsbezogene Rechtfertigung für den Rabatt genannt wird.
224Siehe Antwort von Oracle auf das an Oracle gerichtete Auskunftsersuchen vom 12. Oktober 2009, Anhang A (doc_ID 3113) und Anhang D (doc_ID 3114).
225Oracle gab an, es seien [350-700]* Namen, die Kommission hingegen ermittelte einige Doppelzählungen.
226Siehe Antwort von Oracle auf das an Oracle gerichtete Auskunftsersuchen vom 13. November 2009 (doc_ID 5071).
227„Oracle führt weder in seiner CRM-Datenbank noch anderweitig Aufzeichnungen über (dem Standard entsprechende oder nicht entsprechende) Rabatte, die seinen Datenbankkunden (oder anderen Kunden) gewährt wurden“ [„Oracle does not track discounts (standard or non-standard) granted to its database (or other) customers, in its CRM database or otherwise“]; siehe Antwort von Oracle auf per E-Mail am 13. Oktober 2009 gesandte Fragen (doc_ID 2942).
228„Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009, S. 49 (doc_ID 2427).
229Diese Frage stellt sich auch im Zusammenhang mit anderen Wettbewerberdatenbanken, die ebenfalls in den Ergebnissen der Gesamtsuchvorgänge tendenziell zu häufig erscheinen.
299.In den Dokumenten, in denen MySQL genannt wird, erscheint MySQL möglicherweise in unterschiedlichen Zusammenhängen.
300.In einigen Fällen wird MySQL als einziger Wettbewerber, in anderen hingegen zusammen mit anderen Wettbewerberdatenbanken genannt. Selbst in Fällen, in denen MySQL neben anderen Wettbewerberdatenbanken genannt wird, muss MySQL nach Auffassung der Kommission eine wettbewerbsbezogene Rechtfertigung für den Rabatt darstellen, da das Produkt von dem Kunden als sinnvolle Alternative erachtet worden sein muss.
301.In einigen Fällen ist MySQL die gegenwärtig von dem Kunden genutzte Datenbank, die Oracle durch sein eigenes Produkt ersetzen möchte. In anderen Fällen wird gegenwärtig Oracle als Datenbank genutzt und die Vertriebsmitarbeiter argumentieren, der Rabatt sei dadurch gerechtfertigt, dass MySQL drohe, den Platz von Oracle einzunehmen. In einigen Fällen konkurrieren MySQL und Oracle miteinander um eine neue Geschäftschance. In anderen Fällen sieht Oracle langfristig das Risiko, MySQL könne sich bei dem Kunden durchsetzen. Nach Auffassung der Kommission übt MySQL in all diesen Fällen Preisdruck auf Oracle aus.
302.Die Kommission führte auch für SQL Server und für Sybase jeweils eine separate Auswertung der HQ Apps-Dokumente durch. Die dabei ermittelten Zahlen sind mit den zuletzt von der Anmelderin vorgelegten Zahlen vergleichbar.
303.SQL Server wird im Zusammenhang mit [600-1200]* verschiedenen Bestandskunden oder potenziellen Kunden von Oracle genannt. Die Kommission wertete diese Dokumente aus und schätzt, dass bei insgesamt rund [400-800]* Kunden im HQ Apps-Datenbestand SQL Server im Zusammenhang mit einem erbetenen Rabatt oder erbetenen Sonderkonditionen als relevante Alternative in Erwägung gezogen wurde.
230Siehe Antwort von Oracle auf das an Oracle gerichtete Auskunftsersuchen vom 13. November 2009 (doc_ID 5071).
231.Die Kommission extrahierte den in den HQ Apps-Dokumenten rund um die Erwähnung von SQL Server für jeden der Kunden oder Partner von Oracle stehenden Text (es ist zu beachten, dass in mehreren Dokumenten eine Wettbewerberdatenbank mehr als einmal genannt wird). Dabei wurde so vorgegangen, dass Textteile, in den SQL Server als starke Konkurrenz zu Oracle beschrieben wurde, beim Extrahieren vorrangig vor Textteilen behandelt wurden, in den SQL Server i) im Hinblick auf den Wettbewerb nicht genannt wurde oder ii) als schwache Konkurrenz erachtet wurde.
Die Kommission sortierte die Kunden in alphabetischer Reihenfolge und analysierte den extrahierten Text für die ersten [150-400]* Kunden sowie für die Kunden mit den Nummern [250-500]* bis [350-700]*, was eine Menge von [300-600]* Kunden ergab, bei denen Zitate Aufschluss über den Zusammenhang gaben, in denen SQL Server für den betreffenden Kunden genannt wurde.
Für diese [300-600]* Kunden wertete die Kommission den Text aus und stellte fest, dass in [250-500]* Fällen (rund [70-80]* %) SQL Server in einem Zusammenhang erschien, aus dem die Kommission schließen konnte, dass SQL Server tatsächlich im Hinblick auf den angeforderten Rabatt oder besondere Vertragsbedingungen Wettbewerbsdruck ausübte. Diese Herangehensweise mag zwar in gewisser Hinsicht subjektiv sein, jedoch stellt die Kommission fest, dass dieses Verhältnis der Erwähnungen im Wettbewerbskontext vergleichbar ist mit den Ergebnissen, die in einer entsprechenden Auswertung für Dokumente erzielt wurde, in denen MySQL genannt wird (([80-90]* %).
Die Kommission stellt ferner fest, dass SQL Server in einem größeren Anteil der relevanten Dokumente als MySQL in einem anderen Zusammenhang als der Rechtfertigung für einen Rabatt oder für Sonderkonditionen Erwähnung findet.
304.Für Sybase führte die Kommission eine ebensolche Auswertung durch und ermittelte rund [150-300]* Kunden, bei denen Sybase als einer der Wettbewerber von Oracle erwähnt wird.
Qualitative Auswertung von HQ Apps-Dokumenten, in denen MySQL genannt wird
305.In ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte äußerte die Anmelderin die Auffassung, „die ‚qualitative Auswertung‘ von HQ Apps-Dokumenten erbringt nur Einzelbeispiele, nicht jedoch Beweise“ [„the 'qualitative analysis' of HQ Apps documents only serves to provide anecdotes, not evidence“].
306.Die Kommission ist jedoch der Auffassung, dass die Vertriebsmitarbeiter von Oracle, die mit der Wettbewerbssituation bei ihren Kunden bestens vertraut sind, eine glaubwürdige Rechtfertigung für den angeforderten Rabatt vorlegen müssen. Angesichts dieser Tatsache und der hohen Zahl der Zitate ist das, was Oracle als Einzelbeispiele beschreibt, tatsächlich eine aussagekräftige Charakterisierung des Wettbewerbsumfelds.
307.Die Auswertung der HQ Apps-Dokumente, in denen MySQL genannt wird, ergibt zunächst, dass Oracle bei einigen seiner wichtigsten Kunden wahrscheinlich mit MySQL im Wettbewerb steht.
[…] ist der größte Direktkunde von Oracle (d. h. kein Integrator/Partner):
„[…]“
Ähnliche Zitate finden sich für verschiedene große Kunden von Oracle, z. B. […]*.
Ein Großteil der Zitate bezieht sich auf eine bestimmte Anwendung und nicht auf die Gesamtpalette der von diesen Kunden erworbenen Datenbankprodukte. In diversen Fällen dieser Art hat die Kommission Zitate gefunden, die besagen, dass durch die Einräumung eines nicht dem Standard entsprechenden Rabatts, selbst wenn sich der Wettbewerb gegenwärtig auf ein kleines Segment/eine Anwendung beschränkt, verhindern werden könnte, dass MySQL sich bei dem Kunden durchsetzen kann. Dies geht z. B. aus dem Dokument hervor, das sich auf den nicht dem Standard entsprechenden Rabatt für […]* bezieht:
„ […]“
In den Fällen, in denen MySQL in den HQ Apps-Dokumenten genannt wird, geht es sowohl um kleine als auch um große Geschäftschancen, was das Einnahmenpotenzial anbelangt. Bei […]* wird MySQL im Zusammenhang mit dem internationalen Rahmenvertrag (International Frame Agreement) genannt (neben […]*):
„[…]“
Für […]*, einen großen Kunden der Anmelderin, wird in der HQ Apps-Korrespondenz Folgendes festgestellt:
„[…]“
Ferner ist es interessant, dass bei mehreren Kunden die Zitate aus HQ Apps auf einen starken Preisdruck seitens MySQL schließen lassen.
„[…]“
Selbst wenn einige Kunden einräumen, dass die Datenbanken von Oracle gewisse zusätzliche technische Merkmale bieten, ist nach ihrer Auffassung der Preisunterschied sehr hoch:
„[…]“
Einige Zitate legen den Schluss nahe, dass Oracle sich um die dynamischen Auswirkungen seiner Preisentscheidungen sorgt und befürchtet, heute angesichts der Umstellungs- und Schulungskosten auf dem Datenbankmarkt eine aggressive Preispolitik verfolgen zu müssen, um im Wettbewerb mit MySQL bestehen zu können:
„[…]“
Die Vertriebsmitarbeiter von Oracle scheinen auch verschiedentlich der Meinung zu sein, MySQL werde nach der Übernahme von Sun einen größeren Wettbewerbsdruck ausüben, z. B.:
„[…]“
Ein Aspekt, den die Kommission in HQ Apps untersucht hat, ist die Frage, ob sich der Wettbewerbsdruck, den MySQL auf Oracle ausübt, auf die gesamte Bandbreite von Nutzungsarten für Datenbanken (und nicht nur beispielsweise auf die Nutzung in eingebetteter Form) erstreckt.
318.Eine vorläufige Auswertung deutet darauf hin, dass es in vielen Fällen um die Nutzung in eingebetteter Form geht. Allerdings geht aus dem HQ Apps-Posteingang eindeutig hervor, dass es auch zahlreiche Kunden gibt, die nicht beabsichtigen, die Datenbank in eingebetteter Form zu nutzen. So werden z. B. zahlreiche Kunden für Webanwendungen genannt. Dies untermauert auch die Tatsache, dass Oracle auch bei
236Siehe HQ Apps-Dokument Nr. 2597, Kundenname […]*.
237Siehe HQ Apps-Dokument Nr. 91102, Kundenname […]*.
238Siehe HQ Apps-Dokument Nr. 1206, Kundenname […]*.
239Siehe HQ Apps-Dokument Nr. 1265, Kundenname […]*.
240Siehe HQ Apps-Dokument Nr. 1501, Kundenname […]*.
241Siehe HQ Apps-Dokument Nr. 2618, Kundenname […]*.
242Siehe HQ Apps-Dokument Nr. 1460, Kundenname […]*.
243Siehe HQ Apps-Dokument Nr. 45, Kundenname […]*.
Webanwendungen mit MySQL im Wettbewerb steht (bei Kunden wie […]*). Der folgende Auszug stammt aus der HQ Apps-Korrespondenz bezüglich Qualcomm:
244„[…]“
319.Insgesamt wird MySQL in der HQ Apps-Korrespondenz für mehr als [200-400]* verschiedene Kunden genannt. Diese Kunden sind in verschiedenen Bereichen tätig. Sie umfassen u. a. Telekommunikation, Internet, Einzelhandel, , Bank- und Finanzwesen, Regierung, Hochschulwesen usw.
Ferner geht aus Zitaten aus HQ Apps hervor, dass die Vertriebsmitarbeiter von Oracle MySQL in verschiedenen Bereichen wie den folgenden als sinnvolle Alternative betrachten:
KMU-Banken:
245„[…]“
Staatliche Einrichtungen:
246„[…]“
Einzelhandel:
247„[…]“
Spieleentwickler:
248„[…]“
249.Die Wirtschaftsberater von Oracle, RBB Economics,brachten das Argument vor, dass sich ein großer Teil der Geschäftschancen, bei denen Oracle HQ Apps zufolge augenscheinlich mit MySQL konkurriert, auf die Nutzung der Datenbank in eingebetteter Form beziehe. RBB Economics berief sich ferner auf einen starken Wettbewerb im Segment für eingebettete Datenbanken und folgerte, dass die Geschäftschancen im Zusammenhang mit der Nutzung in eingebetteter Form in HQ Apps zum Zwecke der Bewertung des auf dem Gesamtmarkt für Datenbanken von MySQL auf Oracle ausgeübten Wettbewerbsdrucks nicht relevant seien.
322.Die Kommission räumt ein, dass HQ Apps u. U. nicht alle Geschäftschancen von Oracle perfekt abbildet, da darin Geschäftschancen erfasst werden, bei denen Rabatte von mehr als […]* und/oder […]* Bedingungen in Erwägung gezogen werden. Dennoch decken die Geschäftschancen in HQ Apps verschiedene Anwendungsmöglichkeiten von Datenbanken ab, und zwar im Wettbewerb mit verschiedenen anderen Anbietern sowie in Bezug auf Kunden aus unterschiedlichsten Wirtschaftszweigen. Aus diesem Grund liefert die Erörterung der Wettbewerbsbedingungen in HQ Apps-Dokumenten über den eigentlichen Dokumentinhalt hinaus nützliche Informationen.
323.Die Tatsache, dass MySQL in HQ Apps-Dokumenten häufig im Zusammenhang mit der Nutzung in eingebetteter Form erscheint, schwächt nicht die Aussagekraft von HQ Apps-Dokumenten als wertvolle Quelle von Informationen zum Wettbewerbsumfeld sowohl im Hinblick auf den Verkauf von eingebetteten Datenbanken als auch darüber hinaus. Tatsächlich ist die Datenbank von Oracle in vielen Fällen, in denen sie für die eingebettete Nutzung verkauft wird, technisch identisch mit einer Datenbank, die nicht für die eingebettete Nutzung bestimmt ist. Zudem sind bei einem Großteil der Geschäftschancen für Datenbanken zur eingebetteten Nutzung die Wettbewerber, mit denen Oracle konkurriert, ebenso wie die entsprechenden technischen Anforderungen der Kunden vergleichbar mit den Wettbewerbern und den technischen Anforderungen für nicht eingebettete Nutzung. Im Hinblick auf bestimmte zur eingebetteten Nutzung vorgesehene hoch spezialisierte Datenbanken präsentiert sich möglicherweise ein etwas anderes Bild. Die Kommission konnte jedenfalls nicht feststellen, dass sich HQ Apps-Anfragen zur Genehmigung von Rabatten häufig auf eine solche spezielle Nutzung von Datenbanken beziehen.
324.Dennoch führte die Kommission zur Bestimmung des Verhältnisses von Geschäftschancen für eingebettete Datenbanken zu Geschäftschancen für nicht eingebettete Datenbanken bei einigen der wichtigsten Wettbewerber von Oracle eine weitere Auswertung der Dokumente aus dem HQ Apps-Datenbestand durch.
325.Unter Zugrundelegung der von Oracle selbst aufgestellten Definitionen verschiedener Lizenztypen stellte die Kommission fest, dass Oracle oftmals Drittanbietern von Software, die Datenbanken bei der Entwicklung eigener Anwendungen nutzen, Lizenzen für die Nutzung von Datenbanken in eingebetteter Form erteilt. Die Kommission ermittelte drei wesentliche Lizenztypen für Oracle-Datenbanken:
Das Oracle License and Services Agreement (OLSA) ist der Standardvertrag, der für die Lizenzierung von Programmen von Oracle und den Erwerb damit verbundener Dienstleistungen verwendet wird.
Zahlreiche Partner bieten gebrauchsfertige Lösungen auf Basis von ESL-Lizenzen (Embedded Software Licensing) an, bei denen die Oracle-Technologie vollständig in die Anwendung oder das Gerät integriert ist. Laut der Beschreibung von Oracle müssen sich so Endnutzer nicht mit der Installation und der Nutzung von Oracle beschäftigen. Bei der Paketversion haben die Partner die Kontrolle über die zugrunde liegende Oracle-Infrastruktur, die der Endkunde nutzt.
Bei einer ASFU-Lizenz (Application Specific Full Use) handelt es sich um eine eingeschränkte Lizenz, die von einem Lösungsanbieter in Verbindung mit dessen Anwendungspaket verkauft wird.
326.Die Kommission stellte fest, dass sich von […]* (eindeutigen) Dokumenten mit Bezug auf MySQL und einen der drei Standardverträge (OLSA, ESL und ASFU) […]* beziehen.
328.Von […]* (eindeutigen) Dokumenten mit Bezug auf SQL Server und einen der drei Standardverträge […]*.
329.Von […]* (eindeutigen) Dokumenten mit Bezug auf Sybase und einen der drei Standardverträge […]*.
330.Obgleich die Wahrscheinlichkeit, dass sich die Geschäftschancen, bei denen MySQL als Wettbewerber genannt wird, auf die Nutzung in eingebetteter Form beziehen, leicht höher zu liegen scheint als die Referenzwerte für Microsoft oder Sybase, sind die Unterschiede nicht gravierend und keinesfalls groß genug, um die HQ Apps-Auswertung ausschließlich auf das Segment für eingebettete Datenbanken zu beschränken. Zudem lässt der Wettbewerb im Segment für eingebettete Datenbanken möglicherweise Rückschlüsse auf den potenziellen oder tatsächlichen Wettbewerb auf dem Gesamtmarkt für Datenbanken zu.
331.Zusammenfassend untermauert die weitere von der Kommission durchgeführte Auswertung des HQ Apps-Datenbestands die Schlussfolgerung der Kommission, dass der HQ Apps-Datenbestand nützliche Informationen hinsichtlich des Maßes des auf dem Gesamtmarkt für Datenbanken von MySQL auf Oracle ausgeübten Wettbewerbsdrucks liefert.
332.Die Anmelderin argumentierte , dass nur Fälle, in denen MySQL der Hauptwettbewerber von Oracle sei, nützliche Informationen hinsichtlich der Frage liefern, ob MySQL Wettbewerbsdruck auf Oracle ausübt, und dass nur wenige derartige Fälle vorlägen (rund 100).
333.Die Kommission räumt ein, dass in dem Fall, dass der Hauptwettbewerber für eine bestimmte Geschäftschance mit hoher Gewissheit ermittelt werden könnte, dies eine wichtige zu berücksichtigende Information darstellen würde. Jedoch herrscht seitens der Vertriebsmitarbeiter ein gewisses Maß an Unsicherheit bezüglich der Identität des Hauptwettbewerbers. Unter diesen Umständen wäre nicht nur der als Hauptwettbewerber wahrgenommene Wettbewerber von Interesse. In jedem Fall müsste das Ergebnis einer Analyse bezogen auf die Hauptwettbewerber, um von Nutzen zu sein, mit den Ergebnissen für andere Wettbewerberdatenbanken verglichen werden.
334.Ferner ist die Identität des Hauptwettbewerbers in den HQ App-Dokumenten sehr häufig uneindeutig. Jedenfalls hat die Kommission festgestellt, dass in [10-20]* % der relevanten Dokumente MySQL als einzige der fünf Wettbewerberdatenbanken genannt wird, was rund [60-70]* % der Gesamtzahl der relevanten Dokumente entspricht, in denen MySQL Erwähnung findet (allein oder zusammen mit anderen Datenbanken). SQL Server ist die einzige der fünf Wettbewerberdatenbanken, die in [20-30]* % der relevanten Dokumente erwähnt wird, was rund [50-60]* % aller Dokumente entspricht, in denen SQL Server Erwähnung findet.
In Anbetracht dieses Ergebnisses ist es sehr wahrscheinlich, dass ein Vergleich, auch in Bezug auf die Anzahl der Kunden, der Präsenz von MySQL als Hauptwettbewerber mit der von SQL Server oder Sybase Zahlen ergeben würden, die in ihrer Größenordnung mit den Ergebnissen vergleichbar wären, die die von der Kommission durchgeführte und in Randnummer 290 bis 304 beschriebene Auswertung anhand der Gesamtzahl der Kunden ergab.
4.3.4.1.1.2CRM-Daten
335.Die Kommission hat die CRM-Datenbestände (Customer Relationship Management, Kundenbeziehungsmanagement) beider beteiligter Unternehmen erhalten und ausgewertet. In jedem Datenbestand besteht ein Eintrag aus Merkmalen einer Geschäftschance für den Verkauf einer Datenbank durch das entsprechende Unternehmen, die aus der Sicht eines Vertriebsmitarbeiters beschrieben werden.
336.Die Wirtschaftsberater von Oracle, RBB Economics, haben zudem ein Papier mit einer Auswertung der CRM-Daten von Oracle vorgelegt. In diesem Papier wird vorgetragen, die CRM-Daten würden in sich schlüssig beweisen, dass der von MySQL auf Oracle ausgeübte Wettbewerbsdruck unbedeutend sei. Das von RBB Economics vorgebrachte Argument beruht darauf, dass in der CRM-Datenbank relativ selten Marktkontakte zwischen Oracle und MySQL erfasst sind, sowie auf den Ergebnissen verschiedener weiterer Prüfungen.
Die Kommission berücksichtigte in ihrer Bewertung alle in dieser Frage verfügbaren Beweise, darunter auch die CRM-Datenbank. Nach einer sorgfältigen Abwägung der Beweise wird der Schluss gezogen, dass die CRM-Daten nur eine von mehreren Informationsquellen darstellen, dass sie zum Zweck dieser Bewertung u. U. nicht zuverlässig sind und dass die von RBB Economics auf Grundlage der CRM-Auswertung gezogenen Schlüsse im Widerspruch zu anderen vorliegenden Beweisen stehen. Ferner stehen die von RBB Economics aus den CRM-Daten gezogenen Schlüsse im Widerspruch zu gewissen Argumenten, die von den beteiligten Unternehmen selbst vorgebracht wurden. In den folgenden Absätzen werden die Ergebnisse der von der Kommission durchgeführten Auswertung der von beiden beteiligten Unternehmen vorgelegten CRM-Daten dar.
CRM-Daten von Oracle
338.Der von der Anmelderin vorgelegte CRM-Datenbestand deckt den Zeitraum zwischen dem ersten Quartal 2008 und dem vierten Quartal 2009 ab.
339.Der erste von der Anmelderin vorgelegte CRM-Datenbestand umfasste [200.000 – 300.000]* Einträge. Die Kommission identifizierte […]* Geschäftschancen ([30-40]* %), bei denen Datenbankprodukte Teil der Geschäftschance waren. Diese Teilmenge wertete die Kommission weiter aus.
252Die folgenden Merkmale waren bei der Auswertung durch die Kommission von besonderem Interesse: „Primarycompetitor“ (primärer Wettbewerber), „allcompetitors“ (alle Wettbewerber), „allproducts“ (alle Produkte), „accountnames“ (Firmennamen), „opportunityrevenue“ (Einnahmenpotenzial), „opportunitystatus“ (Status der Geschäftschance) und „partnerstranslatednames“ (übersetzte Namen der Partner).
253Siehe von RBB Economics vorgelegtes Papier „Oracle/Sun: An economic assessment of the scope for unilateral effects“, 2. Oktober 2009 (doc_ID 2438).
340.Am 29. Oktober 2009 legte die Anmelderin eine neue Version ihres CRM-Datenbestands vor, die denselben Zeitraum abdeckt wie der ursprüngliche Datenbestand. Der überarbeitete CRM-Datenbestand umfasst [700.000 – 800.000]* Einträge zu Geschäftschancen. Darunter ermittelte die Kommission [200.000 – 300.000]* Einträge, die sich auf Datenbankprodukte nach der Definition von RBB Economics bezogen.
341.Eine Überprüfung des überarbeiteten CRM-Datenbestands von Oracle ergab, dass MySQL/Sun in dieser Teilmenge in […]* Geschäftschancen ([0 – 5]* %) als Wettbewerber genannt wird. Der am häufigsten genannte Wettbewerber ist Microsoft mit Erwähnung in […]* Geschäftschancen ([20-30]* %), gefolgt von IBM in […]* Geschäftschancen ([10-20]* %) und Sybase in […]* Geschäftschancen ([0 - 5]* %). In […]* Geschäftschancen ([50-60]* %) wurde kein Wettbewerber angegeben. Ferner wurde in […]* Einträgen ([0-5]* %) in den CRM-Daten von Oracle ein „lokaler Wettbewerber“ [„local competitor“] und in […]* Einträgen ([0-5]* %) „interne Entwicklung“ [„in-house-development“] als Wettbewerber angegeben.
342.MySQL allein wurde in […]* Einträgen ([0-5]* %) genannt.
343.Die von RBB Economics für denselben Datenbestand vorgelegte beschreibende Statistik ist den Ergebnissen der von der Kommission durchgeführten Auswertung sehr ähnlich. MySQL/Sun erscheint tatsächlich in weniger als [0-5]* % der Geschäftschancen für Datenbankverkäufe als Hauptwettbewerber. Microsoft erscheint in über [20-30]* % und IBM in über [10-20]* % der Geschäftschancen für den Verkauf von Datenbanken. Von den verbleibenden Wettbewerbern wird Sybase in weniger als [0-5]* % der Geschäftschancen als Wettbewerber genannt. Alle anderen Wettbewerber zusammen erscheinen in knapp über [0-5]* % der Geschäftschancen.
344.Der CRM-Datenbestand weist eine Lücke auf, dergestalt nämlich, dass in über [50-60]* % der Geschäftschancen kein Wettbewerber genannt wird. Werden keine systematischen Fehler angenommen, so müssten diese Geschäftschancen aus der Stichprobe entfernt werden, um die Basis zu erhalten, für die die relevante Häufigkeit von Marktkontakten berechnet wurde. Damit würde der Prozentsatz von Marktkontakten zwischen Oracle und MySQL (und in demselben Verhältnis auch zwischen Oracle und anderen Wettbewerberdatenbanken) im Fall von MySQL auf etwa [0-5]* % erhöht.
254Geschäftschancen mit Datenbankprodukten umfassten mindestens eines der folgenden Produkte von Oracle: i) Database Enterprise Edition (Z10), ii) Database Standard Edition (Z58), iii) Standard Edition One (ZW3) und iv) Database (Y49).
255Hierunter fallen Fälle, in denen kein Wettbewerber genannt ist, sowie unbekannte oder nicht identifizierte Wettbewerber.
256Es ist zu beachten, dass die Auswertung durch die Kommission auf der Frage basiert, ob ein Konkurrenzunternehmen als Wettbewerber genannt wurde (in der Variablen „allcompetitors“), und nicht auf einen Hauptwettbewerber beschränkt ist. RBB trägt vor, in Anbetracht dessen, dass der Markt auf Angeboten basiere, seien bei der Bewertung des durch einen Wettbewerber ausgeübten Wettbewerbsdrucks nur Hauptwettbewerber zu berücksichtigen. Die Kommission stellt jedoch fest, dass hierbei Gewissheit über die Rangfolge der Wettbewerber herrschen müsste, was nicht gegeben ist. Ferner werden hier weitere restriktive Annahmen bezüglich der Natur des Wettbewerbs getroffen.
345.Ferner scheint es wahrscheinlich, dass in Fällen, in denen als Wettbewerber „interne Entwicklung“ [„in-house-development“] angegeben ist, vielfach MySQL die Wettbewerberdatenbank ist. Der Grund hierfür liegt darin, dass MySQL aufgrund der geringen Kosten, des in einer starken und weit reichenden Entwicklercommunity vorhandenen Fachwissens und seiner Eigenschaft als Open-Source-Produkt vergleichsweise besser für eine unternehmensspezifische Entwicklung geeignet ist (siehe z. B. Abschnitt 4.3.4.1.2 zum Thema Erhebungen). Dies dürfte zu einer relativ häufigen Nutzung von MySQL für die interne Entwicklung führen. Entsprechend könnte ggf. für „lokaler Wettbewerber“ [„local competitor“] argumentiert werden.
346.Obgleich die Kommission sich in früheren Fällen auf vergleichbare Datenbestände gestützt hat, äußerte sie im vorliegenden Fall eine Reihe von Bedenken bezüglich der Zuverlässigkeit der CRM-Daten bei separater Betrachtung im Hinblick auf das Maß des auf dem Datenbankmarkt von MySQL auf Oracle ausgeübten Wettbewerbsdrucks.
347.Erstens äußerte die Kommission Bedenken bezüglich der Tatsache, dass die CRM-Daten weniger als die Hälfte des Umsatzes von Oracle widerspiegeln. In dem von RBB Economics vorgelegten Dokument wird argumentiert, selbst unter der Annahme, im CRM-Datenbestand sei nicht ein großer Teil des von Oracle erzielten Umsatzes erfasst, gäbe es ex-ante keinen Grund für die Annahme, dass die Ergebnisse im Hinblick auf die Präsenz von Sun verzerrt sein sollten. Dieses Bedenken wurde jedoch durch die Vorlage des überarbeiteten CRM-Datenbestands größtenteils ausgeräumt.
348.Des Weiteren äußerte die Kommission verschiedene Bedenken bezüglich der Zuverlässigkeit der CRM-Daten im Hinblick auf die Charakterisierung des von MySQL und anderer Open-Source-Software ausgehenden Wettbewerbsdrucks.
349.Kunden können vielfach die Open-Source-Software zu geringen Kosten oder unter der GPL-Lizenz kostenlos nutzen, indem sie diese einfach herunterladen. Es liegt nahe, dass die Kunden in vielen dieser Fälle nicht die Vertriebsmitarbeiter von Closed-Source-Anbietern um Angebote bitten, jedoch trotzdem die Kosten und Funktionsmerkmale verschiedener Alternativen (zumindest implizit) vergleichen. Somit scheint es möglich, dass bestimmte Typen von Geschäftschancen, bei denen es sich auch um diejenigen handeln könnte, bei denen MySQL als besonders sinnvolle Alternative erachtet wird, eher nicht in CRM erfasst werden.
250Die beteiligten Unternehmen haben vorgetragen, „es ist nicht möglich, die ‚Gesamtzahl der Geschäftschancen für den Verkauf von Datenbanken‘ zu ermitteln, da viele indirekte Geschäftschancen Oracle erst zur Kenntnis gelangen, wenn sie Oracle durch einen Partner mitgeteilt werden.“ [„it is not possible to determine the "total number of database sales opportunities" since many indirect opportunities are not known by Oracle unless and until they are reported to Oracle by partner“], siehe Antwort von Oracle vom 16. Oktober 2009 auf Frage 1 des an Oracle gerichteten Auskunftsersuchens vom 14. Oktober 2009 (doc_ID 3165). Oracle hat ferner vorgetragen, „nach Schätzung des Unternehmens gehen rund [80-90]* % der gesamten Lizenzeinnahmen von Oracle im Datenbankbereich im Geschäftsjahr 2008 auf im CRM-System erfasste Geschäftschancen zurück“ [„[it] estimates that approximately [80-90]*% of Oracle's total database license revenues in FY 2008 are attributable to opportunities that had been recorded in the CRM System“], siehe Antwort von Oracle vom 16. Oktober 2009 auf Frage 2 des an Oracle gerichteten Auskunftsersuchens vom 14. Oktober 2009 (doc_ID 3165). Es ist jedoch zu beachten, dass sich Oracle auf Lizenzeinnahmen und nicht auf den Gesamtumsatz aus Datenbankverkäufen bezieht. In den CRM-Daten für das Geschäftsjahr 2008 liegt nach Berechnung der Kommission die Obergrenze der in CRM erfassten Geschäftschancen bei rund […]* Mrd. USD, wohingegen der Gesamtumsatz von Oracle im Datenbankbereich bei rund […]* Mrd. USD liegt.
350.Der potenzielle Kunde holt möglicherweise u. a. deshalb kein Angebot ein, weil ihm klar ist, dass Oracle langfristig, wenn der Kunde erst an das Unternehmen gebunden wäre, keinen hinreichend günstigen Preis gewährleisten könnte.
351.Die Tatsache, dass bei solchen Geschäftschancen kein Vertriebsmitarbeiter von Oracle präsent ist, bedeutet nicht, dass MySQL keinen Wettbewerbsdruck auf Oracle ausüben würde. Gäbe es die Open-Source-Alternative nicht, so könnten Oracle und andere Anbieter von Closed-Source-Produkten ihre Preise anheben. Bei solchen Kunden wird durch die Präsenz von MySQL eindeutig ein Wettbewerbsdruck auf Oracle ausgeübt, was jedoch in der CRM-Datenbank nicht zum Ausdruck kommt.
352.In diesem Zusammenhang stellte mindestens ein anderer großer Datenbankanbieter in seinen internen Dokumenten aus der betreffenden Zeit fest, dass seine Vertriebsmitarbeiter sich oftmals nicht der Tatsache bewusst sind, dass MySQL von den Kunden als Alternative zur eigenen Datenbank betrachtet wird. Dies ist eindeutig ein Argument für eine mögliche Verzerrung in den CRM-Daten von Oracle insgesamt und insbesondere im Hinblick auf die Geschäftschancen, bei denen kein Hauptwettbewerber genannt ist.
353.Dass Anlass zu Bedenken besteht, wie von der Kommission geäußert, wird durch ein Interview mit Karin Padir, Vice President von MySQL, vom April 2009 untermauert:
Frage des Interviewers: „Jonathan Schwartz hat in seinem Blog mehrfach erwähnt, dass Mitarbeiter auf der Abteilungsebene von Unternehmen MySQL selbstständig einführen und nutzen, ohne dass es entsprechende Vorgaben oder Richtlinien der IT-Abteilungen gibt. Ist dies tatsächlich der Fall und welche Auswirkungen hat dies?“ [„Jonathan Schwartz has mentioned on his blog several times that people at the departmental level of companies are deploying and using MySQL on their own, without any decree or directives from IT departments. Is this happening, and what are the implications of that?“]
Antwort von Karin Padir: „Ja, das ist tatsächlich der Fall. Wir beobachten das überall. MySQL und andere Open-Source-Technologien verbreiten sich immer mehr und werden in kleineren Anwendungen genutzt. Wenn dann aber diese Anwendungen äußerst erfolgreich sind, werden sie plötzlich zunehmend erfolgskritisch. Wir beobachten, dass die Unternehmen nun Support für diese Anwendungen benötigen und diesbezüglich auf Sun setzen.“ [„Absolutely, we see this happening everywhere. MySQL and other open source technologies are adopted virally and are used in smaller applications. But what happens as these applications become wildly successful, they suddenly become more and more mission critical. What we find is that enterprises are now having to support these applications and are looking at Sun to provide this support.“]
354.RBB Economics befasste sich mit einer möglichen Quelle für eine Verzerrung zu Ungunsten von MySQL in der CRM-Datenbank, nämlich mit der Möglichkeit, dass in den CRM-Daten keine Geschäftschancen mit geringen Umsatzerwartungen erfasst sind. Wenn die relative Häufigkeit der Nennung von MySQL als Wettbewerber bei solchen Geschäftschancen höher ist, würde dies wahrscheinlich eine Verzerrung in Richtung einer zu seltenen Erwähnung von MySQL in den CRM-Daten bedeuten.
258Anhang 8, „Clifford Chance“, S. 10 (doc_ID 3216).
259http://ostatic.com/blog/interview-karen-tegan-padir-mysql-vp-on-this-weeks-mysql-conference
354.Economics zeigte auf, dass die relative Häufigkeit von Kontakten zwischen MySQL und Oracle in allen Umsatzbereichen relativ stabil ist, und schloss aus diesem Ergebnis, dass es sich hier wahrscheinlich nicht um eine Quelle für eine Verzerrung handelt.
355.Das von RBB Economics vorgebrachte Argument ist im Wesentlichen eine Prüfung der Hypothese, dass MySQL bei Geschäftschancen mit geringeren Umsatzerwartungen in engerem Wettbewerb mit Oracle steht. Die von RBB Economics bereitgestellten Informationen geben in gewissem Maße Aufschluss darüber, mit welcher Wahrscheinlichkeit keine Verzerrung dadurch besteht, dass MySQL häufiger bei Geschäftschancen mit geringerem erwarteten Wert im Wettbewerb mit Oracle steht. Dabei wird jedoch nicht dem Bedenken Rechnung getragen, dass Vertriebsmitarbeiter von Oracle bei Geschäftschancen, bei denen Open-Source-Datenbanken in besonderem Maße als Alternative zu Closed-Source-Datenbanken in Erwägung gezogen werden, weniger häufig präsent sind und ihnen diese Geschäftschancen weniger häufig zur Kenntnis gelangen.
356.Die Kommission äußerte auch Bedenken, bei den in der CRM-Datenbank erfassten Vorgängen, bei denen die Identität des Hauptwettbewerbers unbekannt ist, könnte eine Verzerrung zu Ungunsten von Sun bestehen. In Anbetracht des hohen Anteils solcher Einträge würde eine relativ kleine Verzerrung bewirken, dass die effektive Präsenz von MySQL im Verhältnis zur gegenwärtig erfassten Präsenz erheblich höher wäre. Selbst wenn keine derartige Verzerrung bestünde, würde die gegenwärtig durch die CRM-Daten belegte Überschneidung zwischen MySQL und den Datenbanken von Oracle wahrscheinlich dazu führen, dass Oracle nach dem Zusammenschluss im Vergleich zu Sun ein noch geringeres Interesse daran hätte, MySQL weiterzuentwickeln, was zu einer Kannibalisierung der Einnahmen von Oracle führen würde.
357.Zur Entkräftung der Hypothese, eine stärkere Präsenz von MySQL als Wettbewerber bei Geschäftschancen mit geringeren Umsatzerwartungen verstärke diese Verzerrung, zeigte RBB Economics auf, dass die Verteilung der Einnahmen für Geschäftschancen, bei denen der Hauptwettbewerber nicht genannt ist, der Verteilung der Einnahmen für Geschäftschancen, bei denen der Wettbewerber genannt ist, entspricht. Dies lässt laut RBB Economics darauf schließen, dass eine solche Quelle für eine Verzerrung nicht gegeben ist. RBB Economics zeigte ferner auf, dass die relative Häufigkeit von Marktkontakten zwischen MySQL und Oracle zwischen den verschiedenen Datenbankprodukten von Oracle nicht in bedeutendem Maße variiert.
358.Zwar ist das Ergebnis von RBB Economics erneut aufschlussreich hinsichtlich des wahrscheinlichen Nichtbestehens einer Verzerrung bei den Geschäftschancen ohne genannten Wettbewerber in Richtung MySQL aufgrund einer möglicherweise stärkeren Präsenz von MySQL bei Geschäftschancen mit geringeren Umsatzerwartungen, jedoch gibt das Ergebnis keinen Aufschluss über das Nichtbestehen einer Verzerrung zu Ungunsten von MySQL und anderen Open-Source-Anbietern aus anderen möglichen Gründen.
359.Insofern sind die von RBB Economics vorgebrachten Argumente nicht geeignet, die Bedenken der Kommission hinsichtlich der Repräsentativität der Stichprobe zu zerstreuen. Dies gilt insbesondere, da andere empirische und qualitative Informationsquellen wie HQ Apps und Erhebungen häufig ein erheblich anderes Bild ergeben als die CRM-Daten von Oracle. Zudem scheint die Auslegung der Ergebnisse durch RBB Economics mitunter im Gegensatz zu an anderer Stelle von den beteiligten Unternehmen vorgelegten Informationen zu stehen. Daher sind die CRM-Daten in Kombination mit anderen vorliegenden Beweisen zu bewerten.
360.Zudem wurden laut der Anmelderin die beiden Open-Source-Datenbanken Ingres und PostgreSQL „speziell als Ersatz für die wichtigsten proprietären Datenbanken entwickelt“. Oracle trägt zudem vor, „Ingres und PostgreSQL können im Segment für High-End-Unternehmensprodukte viel eher eine disruptive Wettbewerbs-kraft darstellen als MySQL“. Ingres und PostgreSQL erscheinen jedoch in den CRM-Daten von Oracle überhaupt nicht als Wettbewerber. Daher scheint es, als würde MySQL einen erheblich größeren Wettbewerbsdruck ausüben als Ingres und PostgreSQL zusammen, vorausgesetzt, die CRM-Daten von Oracle sind als zuverlässiges Werkzeug für die wettbewerbsrechtliche Würdigung zu erachten.
361.Ebenso wird Sybase, dessen Datenbankgeschäft nach Aussage der Anmelderin „Umsatz in Höhe von 658 Mio. $ generiert hat und damit nur von Oracle, IBM und Microsoft überrundet wird“, nur wenig häufiger als MySQL/Sun als Wettbewerber genannt ([0 - 5]* % gegenüber [0 - 5]* %). Dies legt den Schluss nahe, dass selbst gemäß den CRM-Daten von Oracle, die eine Verzerrung zu Ungunsten von Open-Source-Datenbanken aufzuweisen scheinen, MySQL einen Wettbewerbsdruck auf Oracle ausübt, der mit dem von Sybase ausgeübten vergleichbar ist.
362.Die Kommission hat auch die CRM-Daten von Sun ausgewertet. Diese Daten decken den Zeitraum vom ersten Quartal 2008 bis zum dritten Quartal 2009 ab. Die Datenbank umfasst [18.000 – 19.000]* Einträge zu Geschäftschancen. Allerdings ist in weniger als [0-5]* % der Geschäftschancen ein Wettbewerber angegeben. Diese Daten sind aufgrund der sehr großen Lücken bei der Identifizierung von Wettbewerbern für die Auswertung von geringem Wert. Dennoch ist es aufschlussreich, dass in über [40-50]* % der Einträge, in denen ein Wettbewerber von MySQL genannt wird, dieser Wettbewerber (unter möglichen anderen) Oracle ist.
363.Die Kommission führte auch einen Abgleich zwischen HQ Apps und CRM von Oracle durch. Zu diesem Zweck identifizierte die Kommission [300-400]* Kunden/Partner, für die in HQ Apps-Dokumenten „MySQL“ als Wettbewerber von Oracle erscheint. Die Mehrheit dieser Kunden wurde auch in dem CRM-Daten identifiziert ([200-300]* Kunden/Partner). Allerdings wurde nur bei [20-30]* % ([…]*) dieser Kunden MySQL in den CRM-Daten von Oracle als Wettbewerber genannt.
364.Zudem identifizierte die Anmelderin in HQ Apps [50-100]* Kunden, für die Postgres genannt wird. In den CRM-Daten hingegen wird für keinen Kunden Postgres als Wettbewerber genannt.
365.Dies ist an sich kein schlüssiger Beweis für einen systematischen Fehler in CRM. Allerdings wäre zu erwarten, dass die Vertriebsmitarbeiter, die eine HQ Apps-Anfrage stellen könnten, die betreffende Geschäftschance in den meisten Fällen in CRM erfassen würden. Somit sollte die CRM-Datenbank einen hohen Anteil der Geschäftschancen aus HQ Apps enthalten. Dass dies nicht der Fall ist, ist möglicherweise ein Hinweis darauf, dass die CRM-Datenbank nicht systematisch ausgefüllt wird und eine Reihe von Geschäftschancen ausgelassen werden, bei denen MySQL als Wettbewerber in Erscheinung tritt. Aus diesem Grund ist es ggf. irreführend, ausschließlich aus diesen Daten Schlüsse zu ziehen.
366.Insgesamt liefert nach Auffassung der Kommission die Auswertung der CRM- und HQ Apps-Daten Hinweise darauf, dass in den Segmenten des Gesamtmarktes für Datenbanken, in denen MySQL und Oracle miteinander im Wettbewerb stehen, MySQL das Potenzial besitzt, einen wichtigen Wettbewerbsdruck auf Oracle auszuüben.
367.Da es sich bei MySQL um ein Open-Source-Produkt handelt, spiegelt der einnahmenbasierte Marktanteil von MySQL nicht in hinreichendem Maße die Verbreitung von MySQL und den durch MySQL ausgeübten Wettbewerbsdruck wider. Erhebungsdaten liefern eventuell andere Hinweise auf die Marktpräsenz von MySQL. Im Allgemeinen vertritt die Kommission die Auffassung, dass Erhebungen zur Datenbanknutzung in Unternehmen ein wichtiges Beweismittel darstellen, das zum Zwecke der wettbewerbsrechtlichen Würdigung auszuwerten ist.
260Es sei angemerkt, dass in den CRM-Daten eine besondere Spalte enthalten ist, die sich auf den Partner für die Geschäftschance bezieht. Für den Fall, dass ein Kunde in HQ APPS als Kunde identifiziert und in CRM unter der Variablen „Partner“ zu finden ist, erweiterte die Kommission die Überprüfung um die Partnervariable. Somit geht die Kommission selbst in dem Fall, dass ein in HQ APPS identifizierter Kunde in CRM als Partner erwähnt wird, davon aus, dass es sich möglicherweise um dieselbe Geschäftschance handelt. Darüber hinaus war es nicht möglich, in jedem Fall die genaue Geschäftschance zu identifizieren. In einigen Fällen werden mehrere Kunden und Partner genannt (da in CRM Geschäftschancen erfasst werden). Die Kommission geht davon aus, dass die beiden Datenbestände (HQ APPS und CRM) übereinstimmen, selbst wenn in einer dieser Geschäftschancen in den CRM-Daten von Oracle MySQL erwähnt wird. Die Kommission führte diese Überprüfung zudem für einen Zeithorizont der CRM-Daten (Januar 2008 bis Dezember 2009) durch, der über den Zeitraum für HQ APPS (Januar 2009 bis Mai 2009) hinausgeht. Dieses Verfahren bietet eine sehr viel höhere Chance, dass MySQL in beiden Datenbeständen erwähnt wird.
368.Jedoch konnte die Kommission aus der Auswertung der vorliegenden Erhebungen keine Schlussfolgenderungen in Bezug auf die vorliegende Sache ziehen. Die vorliegenden Erhebungen unterliegen gewissen Einschränkungen und, wichtiger noch, lieferten keine eindeutigen Antworten auf die Fragen, die im Rahmen der gegenwärtigen wettbewerbsrechtlichen Würdigung aufgeworfen wurden. Die Kommission erläutert nachfolgend einige Erkenntnisse, um verschiedene Beschwerden, die von den Parteien während der Untersuchung vorgebracht wurden, zu überprüfen.
369.Eine von TNS durchgeführte Erhebung („TNS-CIO“-Erhebung) beschäftigt sich mit der Nutzung von Open-Source-Software (OSS) in den nordischen Ländern (Schweden, Dänemark, Finnland und Norwegen) sowie in den Benelux-Ländern. Diese im April und Mai 2009 durchgeführte Erhebung basiert auf 310 Befragungen von IT-Beauftragten (Chief Information Officer, CIO) und IT-Managern von 50 Unternehmen, die zu den 500 größten Personen- und Kapitalgesellschaften im jeweiligen Land zählen (in Luxemburg 10 der 70 größten Unternehmen). Die repräsentative Auswahl umfasst zahlreiche verschiedene Wirtschaftszweige unter Ausschluss von Unternehmen mit weniger als 400 Mitarbeitern weltweit.
370.Laut dieser Erhebung wird MySQL in 46 % der Unternehmen in der repräsentativen Auswahl insgesamt genutzt. Diese Zahl variiert je nach Land und reicht von 34 % in Schweden bis 58 % in Norwegen. Zudem variiert sie nach Sektor von 55 % im öffentlichen Sektor bis 48 % in der Fertigungsbranche. MySQL scheint durchgängig in allen Wirtschaftszweigen und Unternehmen verschiedener Größe, darunter die größten Unternehmen, eingesetzt zu werden.
371.Die Erhebung zeigt, dass eine Mehrfachnutzung (d. h. mehrere Datenbanken in einem Unternehmen) eher die Regel als die Ausnahme ist. MySQL wird in rund der Hälfte der Fälle genutzt, in denen Oracle ebenfalls genutzt wird (110 von 211), während Oracle in rund 2/3 der Fälle genutzt wird, in denen auch MySQL genutzt wird.
372.Dass die Mehrzahl der Unternehmen mehrere Datenbanken unterschiedlicher Anbieter nebeneinander nutzen, bedeutet nicht, dass diese nicht substituierbar wären oder dass diese sogar einander ergänzen würden, wie fälschlicherweise während der Untersuchung von verschiedener Seite behauptet wurde. Insbesondere bedeutet die Tatsache, dass MySQL, Microsoft SQL Server und Oracle 11g in ein und demselben Unternehmen genutzt werden, nicht, dass diese Produkte einander ergänzen. Unternehmen optimieren die Nutzung von Datenbanken je nach den unterschiedlichen Funktionsmerkmalen und den Lizenzgebühren. Im Falle eines Preisanstiegs bei der Datenbank von Oracle wären die Nutzer oftmals in der Lage, Oracle zu ersetzen, indem sie die Mischung der genutzten Datenbanken verändern.
373.Die Erhebung zeigt auch, dass in Fällen, in denen MySQL genutzt wird, die Datenbank durchschnittlich 12,2 % der Anwendungen im Unternehmen unterstützt (zwischen 6,4 % in Dänemark und 16,9 % in Belgien), wohingegen der durchschnittliche Wert bei Oracle 41,1 % beträgt (zwischen 36,2 % in Schweden und 49,3 % in Norwegen).
374.Die Tatsache, dass MySQL in 27 % der Fälle in erfolgskritischen Anwendungen genutzt wird (relativ häufiger in den Benelux-Ländern mit 32 % und insbesondere in den Niederlanden mit 37 % als in den nordischen Ländern, wo der Wert bei ca. 20- 22 % liegt, ausgenommen Norwegen mit 33 %), weist in Richtung einer Substituierbarkeit der Datenbanken der beiden Wettbewerber.
375.Im Hinblick auf die vorhersehbare Zunahme bei der Zahl der Datenbanknutzungen scheint dies insgesamt nicht gravierend zu sein (z. B. planen 10 von 210 Oracle-Nutzern die Einführung von MySQL in den nächsten 2 Jahren und 4 von 144 MySQL-Nutzern planen die Einführung von Oracle).
376.Im Rahmen der Erhebung wurden auch Gründe für die Nutzung von MySQL sowie Gründe beleuchtet, die gegen die Nutzung des Produkts sprechen. Die wichtigsten Gründe sind Kosteneinsparungen (27 % aller MySQL-Nutzer), jedoch auch Zuverlässigkeit und Benutzerfreundlichkeit (12 % bzw. 17 % aller Nutzer) sowie Flexibilität (14 % in Norwegen und 15 % in den Benelux-Ländern).
377.Dass die Nutzer Kostensenkungen als Grund für die Einführung von MySQL nennen, weist darauf hin, dass sie MySQL gegen kostenintensivere proprietäre Datenbanken abwägen. Dies ist ein überzeugender Hinweis darauf, dass sie die Produkte als Substitute betrachten. Die Kommission kann nicht erkennen, ob die Datenbanken von Oracle in der durch höhere Kosten charakterisierten Kategorie der proprietären Datenbanken vertreten sind, jedoch scheint dies wahrscheinlich.
378.Die größten Bedenken bei der Einführung von MySQL betreffen den Support (10 % aller MySQL-Nutzer). Dieser Wert liegt unter dem Wert von 20 % der Nutzer von Open-Source-Software im Allgemeinen, die Bedenken äußern. Bedenken hinsichtlich der Zuverlässigkeit bestehen eindeutig nicht (keine einzige Antwort in diesem Sinne). Rund 85 % der Antworten entfallen auf die übrigen Kategorien („Sonstige“, „Weiß nicht“ oder „Nein“). Somit scheinen die Nutzer MySQL als flexibel und zuverlässig wahrzunehmen.
379.Eine von TNS durchgeführte Erhebung („TNS-CIO“-Erhebung) beschäftigt sich mit der Nutzung von Open-Source-Software (OSS) in den nordischen Ländern (Schweden, Dänemark, Finnland und Norwegen) sowie in den Benelux-Ländern. Diese im April und Mai 2009 durchgeführte Erhebung basiert auf 310 Befragungen von IT-Beauftragten (Chief Information Officer, CIO) und IT-Managern von 50 Unternehmen, die zu den 500 größten Personen- und Kapitalgesellschaften im jeweiligen Land zählen (in Luxemburg 10 der 70 größten Unternehmen). Die repräsentative Auswahl umfasst zahlreiche verschiedene Wirtschaftszweige unter Ausschluss von Unternehmen mit weniger als 400 Mitarbeitern weltweit.
380.Laut dieser Erhebung wird MySQL in 46 % der Unternehmen in der repräsentativen Auswahl insgesamt genutzt. Diese Zahl variiert je nach Land und reicht von 34 % in Schweden bis 58 % in Norwegen. Zudem variiert sie nach Sektor von 55 % im öffentlichen Sektor bis 48 % in der Fertigungsbranche. MySQL scheint durchgängig in allen Wirtschaftszweigen und Unternehmen verschiedener Größe, darunter die größten Unternehmen, eingesetzt zu werden.
382.In der „TNS-KMU“-Erhebung nennen 53 % der Befragten, die MySQL nutzen, Kosteneinsparungen als einen der Gründe für den Einsatz von MySQL, 40 % führen Leistung und Skalierbarkeit an und 38 % der Befragten nennen die Tatsache, an keinen Anbieter gebunden zu sein (mehrere Antworten möglich). Dass ein großer Teil der MySQL-Nutzer die Tatsache, an keinen Anbieter gebunden zu sein, als wichtigen Faktor erachtet, ist auf hohe Umstellungskosten sowie auf die Möglichkeit der Anbieter von Closed-Source-Datenbanken, die Preise anzuheben, nachdem der Nutzer die Datenbank eingeführt und implementiert hat, zurückzuführen.
381.Die Erhebung deutet darauf hin, dass MySQL in Zukunft wahrscheinlich noch verbreiteter genutzt wird.
366.Insgesamt liefert nach Auffassung der Kommission die Auswertung der CRM- und HQ Apps-Daten Hinweise darauf, dass in den Segmenten des Gesamtmarktes für Datenbanken, in denen MySQL und Oracle miteinander im Wettbewerb stehen, MySQL das Potenzial besitzt, einen wichtigen Wettbewerbsdruck auf Oracle auszuüben.
368.Jedoch konnte die Kommission aus der Auswertung der vorliegenden Erhebungen keine Schlussfolgenderungen in Bezug auf die vorliegende Sache ziehen. Die vorliegenden Erhebungen unterliegen gewissen Einschränkungen und, wichtiger noch, lieferten keine eindeutigen Antworten auf die Fragen, die im Rahmen der gegenwärtigen wettbewerbsrechtlichen Würdigung aufgeworfen wurden. Die Kommission erläutert nachfolgend einige Erkenntnisse, um verschiedene Beschwerden, die von den Parteien während der Untersuchung vorgebracht wurden, zu überprüfen.
379.Eine von TNS durchgeführte Erhebung („TNS-CIO“-Erhebung) beschäftigt sich mit der Nutzung von Open-Source-Software (OSS) in den nordischen Ländern (Schweden, Dänemark, Finnland und Norwegen) sowie in den Benelux-Ländern. Diese im April und Mai 2009 durchgeführte Erhebung basiert auf 310 Befragungen von IT-Beauftragten (Chief Information Officer, CIO) und IT-Managern von 50 Unternehmen, die zu den 500 größten Personen- und Kapitalgesellschaften im jeweiligen Land zählen (in Luxemburg 10 der 70 größten Unternehmen). Die repräsentative Auswahl umfasst zahlreiche verschiedene Wirtschaftszweige unter Ausschluss von Unternehmen mit weniger als 400 Mitarbeitern weltweit.
380.Laut dieser Erhebung wird MySQL in 46 % der Unternehmen in der repräsentativen Auswahl insgesamt genutzt. Diese Zahl variiert je nach Land und reicht von 34 % in Schweden bis 58 % in Norwegen. Zudem variiert sie nach Sektor von 55 % im öffentlichen Sektor bis 48 % in der Fertigungsbranche. MySQL scheint durchgängig in allen Wirtschaftszweigen und Unternehmen verschiedener Größe, darunter die größten Unternehmen, eingesetzt zu werden.
382.In der „TNS-KMU“-Erhebung nennen 53 % der Befragten, die MySQL nutzen, Kosteneinsparungen als einen der Gründe für den Einsatz von MySQL, 40 % führen Leistung und Skalierbarkeit an und 38 % der Befragten nennen die Tatsache, an keinen Anbieter gebunden zu sein (mehrere Antworten möglich). Dass ein großer Teil der MySQL-Nutzer die Tatsache, an keinen Anbieter gebunden zu sein, als wichtigen Faktor erachtet, ist auf hohe Umstellungskosten sowie auf die Möglichkeit der Anbieter von Closed-Source-Datenbanken, die Preise anzuheben, nachdem der Nutzer die Datenbank eingeführt und implementiert hat, zurückzuführen.
381.Die Erhebung deutet darauf hin, dass MySQL in Zukunft wahrscheinlich noch verbreiteter genutzt wird.
366.Insgesamt liefert nach Auffassung der Kommission die Auswertung der CRM- und HQ Apps-Daten Hinweise darauf, dass in den Segmenten des Gesamtmarktes für Datenbanken, in denen MySQL und Oracle miteinander im Wettbewerb stehen, MySQL das Potenzial besitzt, einen wichtigen Wettbewerbsdruck auf Oracle auszuüben.
368.Jedoch konnte die Kommission aus der Auswertung der vorliegenden Erhebungen keine Schlussfolgenderungen in Bezug auf die vorliegende Sache ziehen. Die vorliegenden Erhebungen unterliegen gewissen Einschränkungen und, wichtiger noch, lieferten keine eindeutigen Antworten auf die Fragen, die im Rahmen der gegenwärtigen wettbewerbsrechtlichen Würdigung aufgeworfen wurden. Die Kommission erläutert nachfolgend einige Erkenntnisse, um verschiedene Beschwerden, die von den Parteien während der Untersuchung vorgebracht wurden, zu überprüfen.
398.Die Antworten auf die Frage zur Nutzung geben für eine bestimmte Anwendung Auskunft über die Verbreitung von Oracle und MySQL für eine bestimmte Nutzungsart und bieten sich an, um daraus auf einen Kopf-an-Kopf-Wettbewerb zwischen Oracle und MySQL zu schließen.
399.Von der Gesamtheit der von den Befragten für eine bestimmte Anwendung verwendeten Datenbanken entfallen 25% auf Oracle und 6% auf MySQL. Auf Postgres (eine andere OSS-Datenbank) entfällt 1 %, wohingegen bei den alternativen kommerziellen Datenbanken 29 % auf Microsoft SQL Server, 6 % auf IBM DB2 und auch 6 % auf Sybase entfallen.
400.MySQL hat bei dieser speziellen Nutzung in Unternehmen sowohl insgesamt als auch in jeder der Kategorien von Unternehmensgrößen einen großen Anteil. Die Anteile von MySQL bei dieser speziellen Nutzung liegen erheblich über denen der anderen Open-Source-Datenbanken.
401.In einer weiteren webbasierten Erhebung, der „Ziff Davis Enterprise-Peerstone Database Survey“, wurden 269 Personen befragt (von denen 201 alle Fragen beantworteten), die größtenteils (zu rund 2/3) IT-bezogene Positionen bekleiden. In der Erhebung sind einige Profile etwas überrepräsentiert, so z. B. Berater und IT-Anbieter (27 %) oder staatliche Einrichtungen/Organisationen ohne Erwerbscharakter (22 %). Die Befragten kommen zumeist aus Nordamerika (81 %) und nur wenige aus Europa (3 %). Die meisten Unternehmen der Befragten sind KMU (55 % mit weniger als 500 Mitarbeitern), wenn auch 15 % der Befragten Unternehmen mit 10.000 Mitarbeitern oder mehr vertreten.
402.Die Erhebung bestätigt, dass MySQL am häufigsten für Webanwendungen (37 % gegenüber Microsoft SQL Server mit 52,1 % und Oracle mit 23,6 % der Befragten) und für angepasste Anwendungen (sowohl unter Verwendung von Java mit 37,7% als auch unter Verwendung von Skriptsprachen mit 66,7 %) genutzt wird. Jedoch wird MySQL auch in bedeutendem Maße für Data-Warehousing (14 %) und für Paketanwendungen außer für die von Oracle (19,3%) genutzt. MySQL bietet nach Meinung von rund 50 % der Befragten unter dem Kostenaspekt (Lizenz, Support und Wartung) die beste Leistung und die Kosten werden als zweitwichtigster Grund für eine in Erwägung gezogene Migration erachtet (extrem wichtig für 44,8 % der Befragten; an zweiter Stelle hinter 48,1 %, die eine bessere Leistung anführten).
403.Dies ist die einzige der Kommission vorliegende Erhebung, die sich unmittelbar und explizit mit den Auswirkungen des geplanten Zusammenschlusses befasst, wenn auch nicht wirklich Datenbanken im Mittelpunkt stehen. Es herrscht bei Weitem keine einhellige Meinung über die Auswirkungen des geplanten Zusammenschlusses. Das eindeutigste Ergebnis ist, dass Oracle mit hoher Wahrscheinlichkeit die Preise für die Produkte von Sun anheben wird (37,7 % halten dies für sehr wahrscheinlich und 24 % für denkbar). Außerdem wird es als wahrscheinlich erachtet, dass Oracle die Produkte von Sun vermehrt proprietär machen wird (26,4 % halten dies für sehr wahrscheinlich und 29,9 % für denkbar). Zudem ist MySQL das Produkt, bei dem es am ehesten keine positiven Auswirkungen für die Verbraucher geben wird (von insgesamt 51,2 % erwarten 18,5 % sehr negative und 32,7 % ein wenig negative Auswirkungen). Hingegen sind 56,8 % der Befragten der Auffassung, dass die Nutzer von Oracle-Datenbanken von dem Zusammenschluss profitieren werden.
404.Ein weiterer von der Kommission ausgewerteter Bericht ist die von Evans Data Corporation (EDC) durchgeführte Erhebung zur Entwicklung in der Region EMEA 2009 („EMEA Development Survey 2009“). Die Ergebnisse dieser Erhebung wurden in vorstehendem Abschnitt 3.1 des vorliegenden Beschlusses dargelegt.
405.Hinsichtlich der Stichhaltigkeit dieser Erhebung ist festzustellen, dass an der Onlineumfrage eine Gruppe von 406 Entwicklern aus der Region EMEA teilnahm, die von EDC aufgrund ihrer Neutralität und Repräsentativität ausgewählt wurden. Diese repräsentative Auswahl von Befragten ist eine Untergruppe einer von EDC erfassten Gruppe von 75.000 Softwareentwicklern aus 85 Ländern. Zwar ist die Zahl der Befragten bei der Erhebung nicht sehr hoch, jedoch scheint die Gruppe der Entwickler, aus der die Befragten ausgewählt wurden, sorgfältig zusammengestellt worden zu sein. Ferner wird die Erhebung seit mehreren Jahren regelmäßig zweimal jährlich durchgeführt und die Ergebnisse der aktuellen Erhebung scheinen mit den Ergebnissen der vorherigen Ausgaben der Erhebung in Einklang zu stehen.
406.Es wurden noch weitere Erhebungen vorgelegt und in Erwägung gezogen, jedoch richtet sich bei diesen das Augenmerk größtenteils oder ausschließlich auf Open-Source-Software insgesamt, weshalb sie von eher geringerem Interesse sind. Hierzu zählt eine im Oktober 2007 veröffentlichte Erhebung der Independent Oracle Users Group (IOUG) („IOUG-Erhebung“), derzufolge eine gegenüber 2006 gestiegene Zahl von Unternehmen (13 % 2007 gegenüber 9 % im Bericht von 2006) angaben, für über die Hälfte ihrer Anwendungen Open-Source-Software zu nutzen. Gegenwärtig geben mehr als ein Drittel der Befragten an, eine Open-Source-Datenbank in der Produktion zu nutzen, wobei fast drei Viertel dieser Gruppe MySQL installiert haben.
407.RBB Economics, die Wirtschaftsberater von Oracle, bewerteten zwei der Erhebungen, nämlich die IOUG-Erhebung (als Anhang 34 zum Formblatt CO) und die TNS-CIO-Erhebung (die von TNS im Auftrag von Sun durchgeführt und von Sun auf Aufforderung der Kommission vorgelegt wurde).
408.RBB Economics stellt die Zuverlässigkeit der Erhebungen insgesamt in Frage, insbesondere unter Verweis auf mögliche Schwächen der Stichprobenmethode und eine entsprechende Verzerrung der Auswahl (d. h., die Gruppe der Befragten sei nicht für die vollständige Grundgesamtheit repräsentativ und die Personen, die an Webumfragten teilnehmen, könnten in erster Linie Nutzer mit aktivem Interesse an Open-Source-Datenbanken sein). Ferner stellt RBB Economics die Relevanz der in diesen Erhebungen gestellten Fragen im Hinblick auf die Bewertung der Art des Wettbewerbsdrucks zwischen Oracle und MySQL in Frage. RBB Economics trägt vor, dazu „wäre ein vollständig anderer Fragenkatalog erforderlich gewesen. Insbesondere hätte ermittelt werden müssen, in welchem Maße Open-Source-Datenbanken und besonders MySQL als möglicher Ersatz für Oracle-Datenbanken wahrgenommen werden.“
409.Die Kommission nimmt die von RBB Economics wegen möglicher Verzerrungen in der Auswahl der Stichproben erhobenen Einwände bezüglich der Nutzung von Erhebungen zum Zwecke dieser Analyse zur Kenntnis. In diesem Zusammenhang hat RBB Economics vorgetragen, Webumfragen und auf die Nutzer von Open-Source-Software abgestellte Erhebungen würden Nutzer anziehen, die ein aktives Interesse an Open-Source-Datenbanken haben. Es ist möglich, dass jede Erhebung für sich betrachtet eine Verzerrung in der Stichprobenauswahl aufweist.
410.Zur Ausräumung der von RBB Economics geäußerten Einwände hat die Kommission eine Reihe unterschiedlicher Erhebungen geprüft, bei denen unterschiedliche Methoden verwendet, unterschiedliche Zielgruppen befragt und unterschiedliche Fragen gestellt wurden. Die Erhebungen scheinen in ihren wesentlichen Ergebnissen in groben Zügen übereinzustimmen, was für ihre Zuverlässigkeit spricht. Zudem legt die Kommission die Antworten auf die einzelnen Fragen nicht so aus, als bezögen sie sich unmittelbar auf die Intensität des Wettbewerbs, sondern entnimmt ihnen verschiedene Elemente für die Bewertung.
411.Ferner führte RBB Economics an, aus den Ergebnissen der Erhebungen könne nicht der Schluss gezogen werden, dass MySQL einen bedeutenden Wettbewerbsdruck auf Oracle ausübe, wenn RBB Economics auch einräumt, dass „bestimmte der Erkenntnisse, auf die die Kommission verweist, möglicherweise auf eine gewisse Substituierbarkeit zwischen Oracle und MySQL schließen lassen“.
412.Die Kommission ist sich der Einschränkungen der Erhebungen bewusst und zieht diese nicht als alleine Informationsquelle für ihre Schlussfolgerungen heran. Vielmehr werden die Erhebungen in erster Linie verwendet, um eine Reihe von seitens der beteiligten Unternehmen während der Untersuchung vorgebrachten Behauptungen zu prüfen. Obwohl diese Erhebungen nützliche Informationen über den potenziellen oder tatsächlichen Wettbewerb liefern können, unterliegen sie auch gewissen Einschränkungen. Ferner gestatten die Ergebnisse der Erhebungen der Kommission keine fundierten Schlussfolgerungen im Rahmen der vorliegenden Bewertung.
413.Die Marktuntersuchung der ersten Phase ergab, dass nahezu die Hälfte der Kunden Oracle und MySQL als direkte Substitute erachten. Alle außer einem Wettbewerber betrachten MySQL und Oracle als aus Nutzerperspektive direkte Substitute, zumindest bis zu einem gewissen Grad.
414.Aus der Marktuntersuchung der ersten Phase ging auch hervor, dass nahezu die Hälfte der Kunden und fast alle Wettbewerber MySQL als einen der Hauptwettbewerber von Oracle und Oracle als einen der Hauptwettbewerber von MySQL erachten. Dennoch erachtete nur ein Kunde und keiner der Wettbewerber MySQL als den engsten Wettbewerber von Oracle.
415.Die Marktuntersuchung der zweiten Phase ergab, dass MySQL nicht nur für Webanwendungen und als Low-End-Universaldatenbank genutzt wird. Eine Reihe von Kunden, die an der Marktuntersuchung teilnahmen, darunter Suzuki, die schwedische Nationalpolizei, Google und bwin, nutzen MySQL als transaktionsorientierte Datenbank und/oder für erfolgskritische Anwendungen.
416.Die Mehrheit der Kunden in der Marktuntersuchung der zweiten Phase (rund 70 % der Kunden, die die betreffende Frage beantwortet haben) gaben zudem an, dass Datenbankanbieter ihrer Meinung nach ihrem Unternehmen höhere Preise für Datenbanken auferlegen können, die für Anwendungen genutzt werden, für die kostenlose Open-Source-Datenbanken als ungeeignet erachtet werden.
417.Mehrere Kunden äußerten Bedenken hinsichtlich des angemeldeten Zusammenschlussvorhabens.
274Siehe Antwort von Suzuki auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1976).
275Siehe Antwort der schwedischen Nationalpolizei auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1986).
276Siehe Antwort von Google auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 2833).
277Siehe Antwort von bwin auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1749).
278Die schwedische Nationalpolizei gab an, sowohl MySQL als auch Oracle in erfolgskritischen Anwendungen zu nutzen. In Zukunft wird sie MySQL für Webanwendungen, CRM, Personalführung und erfolgskritische Anwendungen einsetzen. Zudem plant sie auch die Nutzung von MySQL für Data-Warehousing. Die Führung der schwedischen Polizei hat entschieden, dass für alle neuen IT-Systeme außer für GIS (geografisches Informationssystem) MySQL genutzt werden soll, und gegenwärtig wird bei der schwedischen Nationalpolizei die Migration zahlreicher IT-Systeme zu MySQL durchgeführt (Antwort der schwedischen Nationalpolizei auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1986)). Die Deutsche Börse plant für die Zukunft den Einsatz von MySQL als OLTP-Datenbank für eine Anwendung (Antwort der Deutschen Börse auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1897)). Freenet, ein Mobilfunk- und Festnetztelefonanbieter, gibt an, MySQL für Webanwendungen, CRM, Personalführung und erfolgskritische Anwendungen zu nutzen. Freenet erklärt, dass MySQL 5.1 erweiterte Clusterfunktionen bietet und Tabellen mit Partitionierung unterstützt. Diese Funktionen sind (neben anderen) ausschlaggebend für die Nutzung von MySQL 5.1. Als Alternativen kämen PostgreSQL, Oracle, IBM Informix und IBM DB2 in Frage (Antwort von Freenet auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1990)). Eine kleine Zahl von Kunden aus dem Telekommunikationssektor, z. B. Alcatel Lucent, integrieren MySQL Cluster in die von ihnen verkauften Produkte. Nach Meinung von Alcatel Lucent ist TimesTen von Oracle mit MySQL Cluster vergleichbar (Antwort von Alcatel Lucent auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 2006)).
Die Deutsche Lufthansa äußerte sich wie folgt: „Wir erwarten steigende Kosten/Preise für Lizenzen und Wartung des Oracle-Datenbankprodukts selbst sowie für den MySQL-Support. Oracle wird seine Position als Marktführer ausbauen und Einfluss auf den gesamten Datenbankmarkt nehmen. Verhandlungen werden sich immer schwieriger gestalten (z. B. unflexible Lizenzmodelle für große, als Diensteanbieter tätige Unternehmen, jedes Jahr steigende Supportkosten). Es ist zu erwarten, dass es keine Innovationen bei der MySQL-Datenbank mehr geben wird.“ [„We expect growing costs/prices for licences and maintenance for Oracle database product itself as well as for MySQL support. Oracle leading market position will grow and will influence the whole database market. Negotiations will become more difficult (e.g. inflexible licence models for large enterprises acting as service provider, growing support costs year by year). It is expected that innovations into MySQL database will stop.“ (Siehe Antwort der Deutschen Lufthansa auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1888)).
Bwin, eine große Website für Onlinesportwetten und Glücksspiele, stellt fest, dass es sich u. U. für Oracle lohnen könnte, die Entwicklung einer Open-Source-Version von MySQL einzustellen, und zwar hauptsächlich deshalb, weil MySQL eine solche Marktakzeptanz erreicht hat, dass das Produkt tatsächlich eine Bedrohung für den Verkauf von Oracle-Datenbanken darstellt bzw. diesen stört. (Siehe Antwort von Bwin auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1749)). F-Secure, ein Anbieter von Antivirus- und Computersicherheitssoftware, äußert folgende Meinung: „Unserer Ansicht nach ist MySQL aufgrund seiner funktionierenden Unternehmensstrukturen und des Open-Source-Konzepts der existenzfähigste Konkurrent von Oracle. Die Existenz eines starken, kostengünstigen und mit gutem Support ausgestatteten MySQL führt dazu, dass das teure Oracle Geschäftschancen und Einnahmen einbüßt. Dies gilt umso mehr, als MySQL jetzt dank seiner hervorragenden Geschäftsmodelle immer und immer mehr angepasst wird.“ [„MySQL in our view is the most viable competitor to Oracle due to their functioning business structures and Open Source approach. The existence of a strong, cost-effective and well supported MySQL is causing the very expensively modeled Oracle to lose its business and revenues; even further now as MySQL is being more and more widely adapted due to its excellent business models.“] (Siehe Antwort von F-Secure auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1911)). Verizon Communications, ein Breitband- und Telekommunikationsanbieter, ist besorgt, dass Oracle sich nicht auf die Open-Source-Kultur einlassen wird: „In Anbetracht der Geschichte von Oracle ist Verizon besorgt, dass Oracle die Bedeutung kostenloser Open-Source-Software nicht würdigen wird, insbesondere bei den Produkten, die mit anderen, proprietären Produkten von Oracle konkurrieren und möglicherweise zu einer Kannibalisierung führen. Zudem ist Oracle möglicherweise nicht gewillt, weiterhin kostenlose Open-Source-Produkte weiterzuentwickeln, wenn das Unternehmen nicht in der Lage ist, seine Marktmacht zu nutzen und von den Kunden ‚erforderliche‘ und häufig hohe Wartungsgebühren zu verlangen.“ [„Given Oracle's history, Verizon worries that Oracle will not embrace the importance of free, open-source software, especially of those products which compete with and potentially cannibalise other Oracle proprietary products. Moreover, Oracle may be reluctant to continue to grow free, open source products if it is not able to leverage its market power and impose 'required' often costly, maintenance fees on customers.“] (Siehe Antwort von Verizon auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1937)). MyPoints, eine Werbeagentur, trägt vor, „Oracle könnte den gewinnorientierten Verkauf von Oracle-Datenbanken forcieren und bei den Kosten für MySQL-Entwicklung und -Support sparen. […] Damit würden die Preise bei geringerem Wettbewerb steigen.“ [„Oracle could force sales of Oracle databases for profit and cut expenses associated with MySQL development and support. […] Prices will go up with less competition.“] (Siehe Antwort von MyPoints auf die Fragen 66 und 69 des an Datenbankkunden gerichteten Auskunftsersuchens vom 17. September 2009 (doc_ID 1923)).
418.Es ist jedoch der Tatsache Rechnung zu tragen, dass viele Kunden angegeben haben, dass sie keine Bedenken bezüglich des Zusammenschlussvorhabens hätten, da dies ihrer Ansicht nach keine negativen Auswirkungen auf ihr Unternehmen haben werde.
419.Die von der Kommission durchgeführten Marktuntersuchungen der ersten und der zweiten Phase haben außerdem ergeben, dass viele Unternehmen verschiedene Datenbanken implementiert haben und nun Datenbanken verschiedener Anbieter parallel nutzen. Viele Unternehmen nutzen Datenbankprodukte von Oracle und Sun parallel und betrachten sie nicht als konkurrierende, sondern als sich ergänzende Produkte.
420.Als Bestandteil der Erwiderung auf die Mitteilung der Beschwerdepunkte fügte Oracle 165 Schreiben bei, die zur Unterstützung des Zusammenschlussvorhabens an die Kommission gesendet worden waren. Gleichzeitig wies Oracle darauf hin, dass mehrere Hundert andere Kunden ihre Absicht bekundet hatten, ähnliche Schreiben an die Kommission zu senden. Durch ausgewählte Zitate aus einer Reihe dieser Schreiben, die zusammen mit anderen Kundenzitaten aus Erwiderungen auf das Auskunftsersuchen der Kommission in den Text der Erwiderung eingefügt wurden, wurde der Eindruck erweckt, dass diese Schreiben im Rahmen der Marktuntersuchung der Kommission eingegangen waren.
421.Nahezu alle betreffenden Schreiben gingen nach Annahme der Mitteilung von Beschwerdepunkten ein. Demzufolge gehörten sie zu dem Zeitpunkt, an dem die Mitteilung von Beschwerdepunkten an Oracle adressiert wurde, nicht zu den Akten der Kommission und konnten somit in diesem Dokument nicht berücksichtigt werden.
422.In jedem Fall gibt es Grund zu der Annahme, dass die Beweiskraft der Schreiben fragwürdig ist. Zunächst scheint es, als seien viele der Absender der Schreiben nur deswegen motiviert gewesen, an die Kommission zu schreiben, weil Oracle Kontakt mit ihnen aufgenommen und sie dazu ermutigt hatte. Es wird zwar nicht angedeutet, die Absender der Schreiben hätten für ihre Unterstützung des Zusammenschlussvorhabens eine Gegenleistung von Oracle erhalten, aber es lässt sich nicht behaupten, dass diese Schreiben ein repräsentatives und unvoreingenommenes Beispiel für die Meinung von Datenbankkunden in Bezug auf das Zusammenschlussvorhaben darstellen, das den gleichen Stellenwert hat wie beispielsweise eine Kundenumfrage, die Oracle, wie von den Kommissionsdienststellen mehrfach angeregt, als Nachweis für den Mangel an negativen Auswirkungen des Zusammenschlussvorhabens auf den Datenbankmarkt vorlegen könnte.
Ein großes Softwareunternehmen weist auf Folgendes hin: „Es wäre denkbar, dass Oracle nach dem Zusammenschluss die Lizenzbedingungen für MySQL im Vergleich zu den Lizenzbedingungen von Sun restriktiver gestalten würde.“ [„Post-Transaction, Oracle could potentially render licensing conditions for MySQL more onerous compared to the licensing conditions that Sun offers.“] (Siehe Antwort eines großen Softwareunternehmens auf das an Datenbankkunden gerichtete Auskunftsersuchen vom 17. September 2009, S. 3 (doc_ID 2514)).
423.Zudem sind die Schreiben nicht als Reaktion auf ein Auskunftsersuchen der Kommission gemäß Artikel 11 der EG-Fusionskontrollverordnung eingegangen. Falls die Empfänger dieser Auskunftsersuchen unrichtige oder irreführende Angaben machen, kann die Kommission gemäß Artikel 14 der EG-Fusionskontrollverordnung durch Entscheidung Geldbußen gegen die betreffenden Unternehmen festsetzen; ein vergleichbares Verfahren für „unverlangte“ Einsendungen an die Kommission wie im Falle der unterstützenden Schreiben gibt es nicht.
424.Ähnliche Bemerkungen wie die Bemerkungen zur Angelegenheit der unterstützenden Schreiben können auch für die große Anzahl von E-Mails gelten, die nach der Anhörung bei der Kommission eingingen. In diesen E-Mails, die als Reaktion auf einen entsprechenden Aufruf von Monty Widenius, dem Gründer von MySQL und Eigentümer von Monty Progam AB, in seinem Blog übermittelt worden zu sein scheinen, werden Bedenken hinsichtlich der Auswirkungen des Zusammenschlussvorhabens auf den Wettbewerb im Datenbankmarkt zum Ausdruck gebracht.
425.Es wird zwar eingeräumt, dass Personen das Recht haben, der Kommission ihre Ansichten mitzuteilen. Doch es wäre nicht angemessen, zur wettbewerbsrechtlichen Würdigung eines angemeldeten Zusammenschlusses ausschließlich eine einfache Zählung der Anzahl der Einsendungen, die für oder gegen einen bestimmten Zusammenschluss eingegangen sind, heranzuziehen, wenn diese Einsendungen scheinbar das Ergebnis von koordinierten Kampagnen sind, wie im vorliegenden Fall.
4.3.4.2.Nachweise für den Wettbewerbsdruck in den verschiedenen Segmenten des Gesamtmarkts für Datenbanken
426.Die potenzielle Segmentierung des Gesamtmarkts für Datenbanken unterliegt verschiedenen Kriterien.
427.Die Anmelderin argumentierte, dass der Datenbankmarkt segmentiert sei, dass die Wettbewerbssituation erheblich zwischen den Segmenten schwanke und dass MySQL und Oracle nur in wenigen Segmenten miteinander konkurrieren würden, die klein seien, in denen Oracle nur schwach vertreten sei und in denen viele andere Wettbewerber tätig seien.
428.Wie in Abschnitt 2.1 erwähnt, betrachtet die Kommission den gesamten Datenbankmarkt als sachlich relevanten Markt. Die für den vorliegenden Fall relevante wettbewerbsrechtliche Würdigung ist somit die wettbewerbsrechtliche Würdigung des gesamten Datenbankmarkts.
429.Dennoch wird angesichts der Produktdifferenzierung und der Anregung der Anmelderin, dass ein segmentorientierter Ansatz eine angemessene Basis für die Bewertung des Zusammenschlussvorhabens sei, die Wettbewerbssituation in verschiedenen potenziellen Segmenten des Gesamtmarkts für Datenbanken in Abschnitt 4.3.4.2.1. bis 4.3.4.2.5. einer Bewertung unterzogen.
430.Die Kommission hat die Anmelderin aufgefordert, eine Segmentierung des Datenbankmarkts vorzulegen und die Größe der verschiedenen Segmente im Hinblick auf Einnahmen und Nutzungen zu quantifizieren. Eine Analyse und Quantifizierung der Marktsegmente, eventuell begleitet von einer wettbewerbsrechtlichen Würdigung
bezogen auf jedes der Segmente, gestattet es der Kommission, die wirtschaftliche Bedeutung der Wettbewerbssituation in diesen Marktsegmenten abzuschätzen.
431.Abgesehen von einigen geltend gemachten Daten in Bezug auf das Segment für eingebettete Datenbanken hat die Anmelderin weder eine Einschätzung der wirtschaftlichen Bedeutung der verschiedenen Segmente noch eine quantifizierte wettbewerbsrechtliche Würdigung für diese Segmente vorgelegt.
432.In ihrer Antwort auf die Entscheidung nach Artikel 6 Absatz 1 Buchstabe c hat die Anmelderin einige Argumente in Bezug auf eine Segmentierung des Datenbankmarkts vorgebracht.
433.Die Anmelderin erklärte, dass zur Bewertung des vorgeschlagenen Zusammenschlussvorhabens die Fokussierung auf drei Nutzungsszenarien sowie eine entsprechende Unterscheidung von drei Nutzungsszenarien ausreichend sei: (a) Nutzungen von unternehmenskritischen Unternehmensdatenbanken, (b) Nutzungen von webbasierten und am unteren Ende angesiedelten allgemeinen Datenbanken, (c) Nutzungen von eingebetteten Datenbanken.
434.Am 29. Oktober 2009 und nach wiederholten Aufforderungen vonseiten der Kommission machte die Anmelderin eine weitere Eingabe, die auch einige Argumente im Hinblick auf eine Segmentanalyse enthielt.
435.In dieser Eingabe legte die Anmelderin ihre Sicht im Hinblick auf die Segmentierung des Datenbankmarkts sowie die Wettbewerbslandschaft in den verschiedenen Segmenten dar. Entsprechend der vorgelegten beschreibenden Analyse betrachtet die Anmelderin nachfolgende Segmentierung des Datenbankmarkts als zutreffend: (a) Unternehmensdatenbanken, (b) abteilungsspezifische Datenbanken und Datenbanken in kleineren und mittleren Unternehmen („KMU“), (c) Datenbanken zur Unterstützung von Websites und (d) in Geräte eingebettete Datenbanken.
436.In ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte bekräftigte die Anmelderin ihre Behauptung, mit MySQL im KMU- und Websegment, wo Oracle derzeit nur schwach vertreten sei, besser konkurrieren zu können.
437.Ferner argumentierte die Anmelderin zunächst, dass ihre eigenen Datenbankprodukte und MySQL aufgrund erheblicher technischer Unterschiede nicht bei denselben Anwendungen in direkter Konkurrenz zueinander stehen. Zu einem späteren Zeitpunkt argumentierte die Anmelderin hingegen, dass trotz der Tatsache, dass Oracle und MySQL in den gleichen Marktsegmenten (Webinfrastruktur, KMU und eingebettete Datenbanken) miteinander konkurrieren, die Position von Oracle in diesen Segmenten schwach sei und es viele andere Wettbewerbsalternativen gäbe, sodass sich
438.die Auswahl für den Verbraucher durch das Zusammenschlussvorhabens nicht signifikant verkleinern würde.
439.Abgesehen von der Tatsache, dass die Kommission den gesamten Datenbankmarkt als sachlich relevanten Markt betrachtet, ist zu beachten, dass die verschiedenen Segmente nicht klar voneinander abgegrenzt sind, da die Untersuchung keine klaren Segmentgrenzen ergeben hat. Folglich kann die Größe der verschiedenen Segmente in Bezug auf Einnahmen oder Nutzungen nicht genau beziffert werden. Es gibt zwar Indikatoren für die relative Wichtigkeit der einzelnen Segmente im gesamten Datenbankmarkt, doch die Segmentgrenzen sind nicht eindeutig, und zwischen verschiedenen Segmenten gibt es Überschneidungen.
Die Kommission bewertet daher die nachfolgenden potenziellen Segmente des gesamten Datenbankmarkts: (i) Web, (ii) kleinere und mittlere Unternehmen, (iii) Großunternehmen, (iv) High-End-Segment und (v) eingebettete Datenbanken.
4.3.4.2.1.Websegment
440.Die Untersuchung der Kommission ergab, dass für das Websegment des Datenbankmarkts keine exakte Definition vorhanden ist. Datenbanken könnten beispielsweise als in das Websegment fallend eingestuft werden, da sie bei einer Website als zugrunde liegende Datenbank dienen, aber auch, wenn sie einer Anwendung zuarbeiten, die über eine webbasierte Benutzeroberfläche zugänglich ist. Die Kommission ist daher der Meinung, dass die Grenzen des Websegments unklar sind.
441.Ungeachtet der exakten Definition des Websegments konnte die Anmelderin keine Quantifizierung des Websegments im Hinblick auf Einnahmen oder Nutzungen vorlegen. Die Untersuchung ergab keine sonstigen Anhaltspunkte, die der Kommission eine präzise Quantifizierung des Websegments gestatten. Jedoch ist bei einem beträchtlichen Teil der Websites, insbesondere bei kommerziellen Websites, eine zugrunde liegende Datenbank vorhanden. Gleiches gilt für Intranet-Sites, beispielsweise zur Nutzung einer Anwendung über eine Webschnittstelle. Demzufolge vertritt die Kommission die Auffassung, dass zumindest im Hinblick auf die Nachfrage das Websegment ein nicht unwichtiger Bestandteil des Datenbankmarkts ist.
442.Ein beträchtlicher Anteil der MySQL-Nutzungen im Websegment verwendet MySQL offenbar unter der GPL. Die wettbewerbsrechtliche Würdigung des Websegments kann daher nicht auf Grundlage der Einnahmen erfolgen. Angesichts der unklaren Grenzen ist die wettbewerbsrechtliche Würdigung zudem nur in Annäherung möglich.
443.Die Anmelderin bestätigt, dass Oracle- und MySQL-Datenbanken im Websegment miteinander konkurrieren. Nach Aussage der Anmelderin bildet das Websegment den primären Nutzungszweck für MySQL.
444.Jedoch argumentiert die Anmelderin, dass Oracle kein wichtiger Akteur im Websegment sei und dass nach dem Zusammenschluss viele Konkurrenzalternativen zu Oracle und MySQL verbleiben würden. Darüber hinaus würden die Nutzer im Websegment eine kostengünstige und benutzerfreundliche Datenbank wählen. Microsoft SQL Server wäre häufig Teil der Infrastruktur und somit problemlos verfügbar. Alternativen zu MySQL wären nicht die proprietären Datenbanken wie z. B. Oracle, sondern vielmehr kostenlose Open-Source-Produkte wie PostgreSQL.
445.Die Untersuchung der Kommission hat ergeben, dass MySQL und Oracle beide im Websegment präsent sind. Ferner ergab die Untersuchung, dass MySQL wahrscheinlich stark und die führende Datenbank im Websegment ist. Das Argument der Anmelderin, dass Oracle eine ungeeignete Datenbanklösung für das Websegment und ein unbedeutender Akteur in diesem Segment sei, bestätigte sich nicht. Dagegen bestätigte sich, dass die derzeitige Präsenz von Oracle im Websegment vergleichsweise weniger wichtig ist.
446.Wie in Abschnitt 1.2.2 beschrieben, war das Websegment der Ausgangspunkt für die Entwicklung von MySQL, wobei MySQL traditionell im Websegment vergleichsweise sehr stark ist. Die Kommission vertritt die Auffassung, dass angesichts der Historie von MySQL und der heutigen Bedeutung der LAMP-Plattform wahrscheinlich eine erhebliche Anzahl der 11 Millionen aktiven Installationen von MySQL als dem Websegment zugehörig betrachtet werden könnte.
447.Die Anmelderin verwies auf die Umfrage „State of the Web 2008“ unter Webdesignern und –entwicklern, bei der der Prozentsatz der Nutzer der verschiedenen Datenbanken ermittelt wurde. Laut dieser Umfrage wird MySQL von ungefähr 70 % der Webdesigner und –entwickler verwendet.
448.Ein Wettbewerber legte eine Analyse der Datenbanken, die von 31 der 45 größten Webpräsenzen weltweit verwendet werden, vor. Diese ergab, dass MySQL mit 57 % der Webpräsenzen die am häufigsten verwendete Datenbank war.
449.In der „Ziff Davis Enterprise-Peerstone Database Survey“, die bereits in Abschnitt 4.4.2.1.2 erwähnt wurde, wurde nach der Datenbank gefragt, die nach Ansicht der Befragten die beste Datenbank für Websites oder –portale ist. 35 % der Befragten nannten MySQL als beste Datenbank, sodass MySQL den zweiten Platz hinter Microsoft einnimmt.
99
100
101
290Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009 (doc_ID 2427).
291LAMP ist ein Akronym für ein quelloffenes Webserver-Softwarepaket bestehend aus dem Betriebssystem GNU/Linux, der HTTP-Server-Software Apache, dem Datenbankprogramm MySQL und PHP, einer Web-Skriptsprache.
292Siehe http://www.sun.com/software/products/mysql/ (doc_ID 3375).
293Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009 (doc_ID 2427).
294Antwort von Microsoft auf den an Datenbankwettbewerber gerichteten Fragebogen, S. 21-22 (doc_ID 2013).
295Siehe Frage 9 (doc_ID 973).
102
450.Darüber hinaus legte ein Wettbewerber ein internes Dokument mit einer Übersicht über MySQL vor. In diesem Dokument wird eindeutig der Ursprung und die Stärke von MySQL im Websegment bestätigt.
451.Was die Kunden anbelangt, wird MySQL offenbar auf breiter Ebene für Webnutzungen verwendet. Google, Amazon und Facebook zählen zu den größten Nutzern der Datenbank. Ferner scheinen Kunden wie Google erhebliche unternehmensinterne Fachkenntnisse über MySQL zu besitzen und den Code in erheblichem Umfang anzupassen, was bei MySQL aufgrund des offenen Quellcodes einfacher möglich ist.
452.Daher wird der Schluss gezogen, dass MySQL die führende Datenbank im Websegment zu sein scheint.
453.Gleichzeitig hat die Untersuchung der Kommission ergeben, dass Oracle das Websegment des Datenbankmarkts bedienen kann und bereits im Websegment vertreten ist. Eine Reihe von Kunden gab an, dass sie Oracle für die verschiedensten Anwendungen, einschließlich Web, nutzen.
454.Die Umfrage „State of the Web 2008“, auf die die Anmelderin Bezug nahm, zeigte, dass Oracle bei 9 % der Websites verwendet wird. Damit steht Oracle nun hinter MySQL, Microsoft und PostgreSQL an vierter Position.
455.Eine von einem Wettbewerber erstellte und vorgelegte Analyse der Datenbanken, die von den größten Webpräsenzen weltweit verwendet wird, ergab ferner, dass Oracle mit einem Anteil von 22 % hinter MySQL als am zweithäufigsten genutzte Datenbank folgte.
456.In der „Ziff Davis Enterprise-Peerstone Database Survey“ nannten 13 % der Befragten Oracle als beste Datenbank für Websites oder -portale. Damit steht Oracle hinter Microsoft mit 45,6 % und MySQL mit 35 % an dritter Position.
457.Außerdem belegen Oracle-interne HQ Apps-Dokumente, dass Oracle auch Webunternehmen anvisiert und ferner dass Oracle-Datenbanken scheinbar im Websegment konkurrieren können […]*. Einige wenige Beispiele der in den HQ Apps-Dokumenten erwähnten Unternehmen, die ungeachtet der exakten Nutzung der Datenbank aufgrund ihrer webbasierten Geschäftstätigkeit scheinbar eindeutig in das Websegment fallen, sind […]*.
458.Im Hinblick auf die Position von Oracle im Websegment wird der Schluss gezogen, dass Oracle-Datenbanken im Websegment eingesetzt werden können und dass Oracle ein kommerziell wichtiger Datenbankanbieter im Websegment ist. Allerdings scheinen die Preise von Oracle-Datenbanken deren Attraktivität im Websegment zu verringern.
296Anhang 8 – Clifford Chance (doc_ID 3216).
297Siehe Antwort auf Frage 22 und 23 des an Datenbankkunden gerichteten Fragebogens (Phase II).
298Siehe Protokoll der Telefonkonferenz mit Google (doc_ID 2869).
299Siehe Antwort auf Frage 32 des an Datenbankkunden gerichteten Fragebogens (Phase II).
300Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009, Randnummer 107 (doc_ID 2427).
301Antwort von Microsoft auf den an Datenbankwettbewerber gerichteten Fragebogen, S. 21-22 (doc_ID 2013).
302Siehe Frage 9 (doc_ID 973).
103
Oracle ist im Websegment wesentlich weniger stark vertreten als in anderen Segmenten des Datenbankmarkts und im gesamten Datenbankmarkt.
459.Im Hinblick auf den Wettbewerb im Websegment sind Oracle- und MySQL-Datenbanken substituierbar und wird der Schluss gezogen, dass MySQL, insbesondere in der kostenlosen GPL-Version, einen starken Wettbewerbsdruck auf die in diesem Segment tätigen Anbieter proprietärer Datenbanken, darunter auch Oracle, ausüben kann.
460.Zu den bedeutenden Lieferanten im Websegment zählen neben MySQL und Oracle Microsoft und PostgreSQL sowie bis zu einem gewissen Grad auch IBM.
461.PostgreSQL ist derzeit in gewissem Umfang im Websegment vertreten und scheint in diesem Segment durch MySQL substituierbar.
462.Ferner ergab die Untersuchung der Kommission, dass durch das Websegment der von MySQL ausgeübte Wettbewerbsdruck und die damit verbundenen dynamischen Aspekte verdeutlicht werden können.
463.Das Websegment war der Ausgangspunkt für MySQL. Dies war das erste Segment, in dem MySQL signifikant präsent war. Ein erster dynamischer Aspekt von MySQL ist, dass es die Ausweitung auf andere Segmente des Gesamtmarkts für Datenbanken ausgehend vom Websegment in Angriff nahm. Ein zweiter dynamischer Aspekt ist die Vertrautheit mit einer bestimmten Datenbanktechnologie und die daraus resultierende Marktbedeutung, Standardisierung und Netzwerkeffekte, die durch den Open-Source-Charakter von MySQL signifikant verstärkt zu werden scheint.
464.Die beiden dynamischen Aspekte der Auswirkungen von MySQL auf die Wettbewerbssituation spiegeln sich in einem internen Dokument eines Drittwettbewerbers im Bereich Datenbanken wider, in dem es heißt: „MySQL: „[…] schmerzt“ [„[…] pains“]; „bedroht […] Websites“ [„Threat […] websites “] ; und „Entwickler, die die Nutzung von MySQL vorantreiben“ [„Developers driving MySQL usage“]. In dem Dokument werden ferner die Segmente, in die MySQL den Erwartungen zufolge in den kommenden drei Jahren weiter vordringen wird, sowie die Einnahmen, die durch die Verbreitung von MySQL in diesen Segmenten auf dem Spiel stehen, qualitativ aufgezeigt.
465.Oracle-interne Dokumente liefern ebenfalls Anhaltspunkte für diese beiden dynamischen Elemente. In einem internen Dokument […]*. Weiter unten in dem Dokument wird argumentiert, dass […]*. Das Dokument schließt mit einer Übersicht, in der es heißt, dass die […]*.
466.Darüber hinaus werden diese Erkenntnisse durch das folgende ausgewählte Zitat aus dem Austausch von HQ Apps-Korrespondenz bezogen auf […]* scheinbar bestätigt:
306[…]
467.468. Es wird der Schluss gezogen, dass Entwickler, insbesondere im Websegment, eine wichtige Rolle für den dynamischen Wettbewerb im Gesamtmarkt für Datenbanken zu spielen scheinen und dass sich die Anbieter proprietärer Datenbanken, einschließlich Oracle, dessen bewusst zu sein scheinen.
Schließlich wird die Bedeutung der wettbewerbsrechtlichen Würdigung des Websegments durch die Tatsache, dass die Größe des Websegments, auch wenn derzeit nicht exakt quantifizierbar, im Hinblick auf absolute Einnahmen und relative Einnahmen im Vergleich zum gesamten Datenbankmarkt wahrscheinlich gering ist, nicht geschmälert. Die Erkenntnisse können im Gegenteil die Auswirkungen auf die Wettbewerbssituation, die MySQL im Websegment erreicht hat, sowie die Tatsache veranschaulichen, dass sich durch das Eindringen von MySQL in ein Segment des Datenbankmarkts oder die Präsenz von MySQL in einem solchen Segment die Preise für Datenbanken sehr deutlich verringern können. Bei einem erheblichen Anteil der gegenwärtig kostenlosen Datenbanknutzungen im Websegment drohen infolge des vorgeschlagenen Zusammenschlussvorhabens möglicherweise höhere Preise.
4.3.4.2.2. KMU-Segment
470.Im vorliegenden Abschnitt werden die Auswirkungen des Zusammenschlussvorhabens auf ein Segment des Datenbankmarkts, das Datenbanken für kleine und mittlere Unternehmen („KMU“) beinhaltet, betrachtet.
471.Die Anmelderin nahm Bezug auf ein Marktsegment, das „wechselnd als Low-End-, nicht unternehmenskritisches, mittleres oder KMU-Segment bezeichnet werden“ könnte. Die Untersuchung der Kommission ergab, dass keine von Markteilnehmern vereinbarte Definition für ein solches Segment existiert. Selbst wenn das Low-End- und nicht unternehmenskritische Segment denselben Teil des Gesamtmarkts für Datenbanken abdecken, wären das nicht unternehmenskritische Segment auf der einen Seite und das KMU-Segment auf der anderen Seite nicht unbedingt deckungsgleich. Wenn außerdem einer dieser Bereiche gewählt werden würde, werden von Marktteilnehmern verschiedene alternative Kriterien ausgewählt, um das betreffende Segment zu definieren.
472.Darüber hinaus könnte sich das KMU-Segment, wie für viele andere Segmente des Datenbankmarkts dargelegt, erheblich mit anderen Segmenten überschneiden. Beispielsweise könnte eine Datenbank, die von einem KMU-Kunden erworben wird, gleichzeitig zum Websegment und zum High-End-Segment gehören. Ebenso könnte eine Low-End-Datenbank gleichzeitig in das Großunternehmenssegment fallen.
473.Im vorliegenden Abschnitt wird ein Segment bestehend aus Datenbanken für KMU betrachtet. KMU werden im Allgemeinen anhand von Indikatoren wie Jahresumsatz oder Anzahl der Beschäftigten identifiziert. Selbst wenn jedoch ein Indikator gewählt wird, bleibt der exakte Grenzwert für die Definition von KMU zur Bewertung dieses Zusammenschlussvorhabens unklar. Beispielsweise könnten einige Marktteilnehmer KMU als Unternehmen mit weniger als 1.000, 500 oder 250 Beschäftigten definieren.
307Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009, S. 60 (doc_ID 2427).
105
474.Die Empfehlung 2003/361/EG der Kommission vom 6. Mai 2003 betreffend die Definition der Kleinstunternehmen sowie der kleinen und mittleren Unternehmen enthält eine KMU-Definition. Da diese Definition jedoch nicht weithin von Marktteilnehmern im Datenbankmarkt verwendet wird, scheint es für die Beurteilung des Wettbewerbsdrucks des Zusammenschlussvorhabens in der vorliegenden Sache nicht angemessen zu sein, das KMU-Segment auf dieser Grundlage abzugrenzen.
475.Daher wird der Schluss gezogen, dass die Grenzen des KMU-Segments nicht eindeutig sind.
476.Angesichts der verschiedenen Definitionen des KMU-Segments ist dessen Größe in Bezug auf die Einnahmen und Nutzungen nur schwer zu ermitteln. Die Anmelderin konnte keine Quantifizierung des KMU-Segments vorlegen. Die Untersuchung ergab keine sonstigen Anhaltspunkte, die der Kommission eine präzise Quantifizierung des KMU-Segments gestatten.
477.Obwohl es in der Untersuchung der Kommission keine Anhaltspunkte für eine Schätzung des KMU-Segments im Hinblick auf die Nutzungen gab, können die folgenden Alternativen herangezogen werden, um die Größe dieses Segments in Bezug auf die Einnahmen abzuschätzen.
478.Laut Gartner betrug die auf die Einnahmen bezogene Größe des KMU-Segments, sofern davon ausgegangen wird, dass es sich bei KMU um Unternehmen mit weniger als 500 Beschäftigten handelt, ungefähr 0.9 Mrd. US-Dollar im Jahr 2007.
479.Gartner zufolge betrug die auf die Einnahmen bezogene Größe des KMU-Segments, sofern davon ausgegangen wird, dass es sich bei KMU um Unternehmen mit weniger als 1.000 Beschäftigten handelt, ungefähr 3 Mrd. US-Dollar im Jahr 2007.
480.Die Anmelderin schätzt in einem internen Dokument, dass die auf die Einnahmen bezogene Größe des Datenbanksegments unter Berücksichtigung von Unternehmen mit […]* Beschäftigten im Jahr 2006 […]* betrug.
481.Die Anmelderin schätzt in einem internen Dokument, dass die auf die Einnahmen bezogene Größe des Datenbanksegments unter Berücksichtigung von Unternehmen mit weniger als 100 Mio. US-Dollar Jahresumsatz im Jahr 2006 4,9 Mrd. US-Dollar betrug.
482.Diese Schätzungen verdeutlichen, dass das KMU-Segment einen nicht unwichtigen Anteil der Datenbankeinnahmen ausmacht.
308ABl. L 124, 20.5.2003, S. 36-41.
309Siehe beispielsweise Antwort der Anmelderin vom 11. Oktober 2009 auf Frage 3 des Auskunftsersuchens der Kommission vom 8. Oktober 2009 (doc_ID 2854) sowie Eingabe der Anmelderin vom 29. Oktober 2009 (doc_ID 3498 und 3499).
310Gartner, RDBMS Revenue by customer company size [RDBMS-Einnahmen nach Kundenunternehmensgröße], Anhang 1 der Eingabe von Microsoft vom 6. Oktober 2009 (doc_ID 2654).
311Gartner, RDBMS Revenue by customer company size [RDBMS-Einnahmen nach Kundenunternehmensgröße], Anhang 1 der Eingabe von Microsoft vom 6. Oktober 2009 (doc_ID 2654).
312Oracle Anhang 2.41 SMB Tech Market (doc_ID 1527).
313Oracle Präsentation, Accelerate Your Business with Oracle [Beschleunigen Sie Ihre Geschäfte mit Oracle], S. 3, abrufbar unter http://www.techselect.com/root/smbaccess%20event%20recap/Oracle%20presentation%20-%20SMB.pdf (doc_ID 3428).
106
483.Im Hinblick auf die Nutzungen scheint das KMU-Segment ebenfalls einen nicht unwichtigen Teil des Datenbankmarkts einzunehmen, höchstwahrscheinlich sogar relativ gesehen einen größeren Anteil als in Bezug auf die Einnahmen.
484.Die Anmelderin vertritt die Ansicht, dass das KMU-Segment, obwohl es der wichtigste Bereich sei, in dem die Parteien miteinander konkurrieren, auch der am härtesten umkämpfte Teil des Gesamtmarkts für Datenbanken sei.
485.Es gäbe mindestens sieben bedeutende Wettbewerber, nämlich Oracle, MySQL, IBM, Ingres, Microsoft, PostgreSQL und Sybase.
486.Darüber hinaus argumentiert die Anmelderin, dass Microsoft im KMU-Segment führend sei und dass sich Oracle durch die geplante Übernahme von MySQL im Wettbewerb gegen Microsoft besser positionieren könne.
487.In ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte bekräftigte die Anmelderin diese Behauptungen und erklärte ferner, dass Microsoft eine dominante Position im KMU-Segment des Datenbankmarkts innehabe.
488.Die Untersuchung der Kommission in Bezug auf die Position von MySQL im KMU-SME ergab, dass MySQL in diesem Segment besonders stark zu sein scheint.
489.Aus einem internen Dokument eines Drittwettbewerbers im Bereich Datenbanken geht hervor, dass in kleineren Unternehmen MySQL nun [Name des Unternehmens] überholt hat.
490.Ingres geht davon aus, dass MySQL und Microsoft den größten Anteil am KMU-Segment besitzen. IBM schätzt, dass MySQL basierend auf einem größeren Liefervolumen eine stärkere Präsenz hat.
491.Was die Position von Oracle im KMU-Segment anbelangt, beliefen sich die Datenbankeinnahmen von Unternehmen mit einem Jahresumsatz von weniger als 100 Mio. US-Dollar einem Oracle-internen Dokument zufolge im Jahr 2006 auf ungefähr 2 Mrd. US-Dollar. 2006 entsprach dies 26 % der Datenbankeinnahmen von Oracle. Oracle selbst gibt an, dass es in Bezug auf die Einnahmen im KMU-Segment (identifiziert als Unternehmen mit einem Jahresumsatz von weniger als 100 Mio. US-Dollar) das führende Unternehmen mit einem Marktanteil von ungefähr 40 % sei.
492.Nach den Daten von Gartner ist Oracle im KMU-Segment der größte Anbieter relationaler Datenbanken bezogen auf die Einnahmen von 2007, ungeachtet dessen, ob Kunden mit weniger als 1.000, 500 oder 100 Beschäftigten in Betracht gezogen werden.
293Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009, S. 60 ff. (doc_ID 2427).
294Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009, S. 15 (doc_ID 2427).
295Oracle, Erwiderung auf die Mitteilung der Beschwerdepunkte, S. 110 (doc_ID 4828).
296Anhang 8, „Clifford Chance“, S. 5 (doc_ID 3216).
297Antwort von Ingres auf den Fragebogen zur Positionierung von Datenbanken (doc_ID 2216).
298Antwort von IBM auf den Fragebogen zur Positionierung von Datenbanken (doc_ID 2472).
107
321.321 werden. Angesichts des Arguments der Anmelderin stellt die Kommission ferner fest, dass laut Gartner die Einnahmen von Oracle diejenigen von Microsoft in jeder der verschiedenen betrachteten Kundenkategorien übersteigen.
493.Auch Forrester Wave ist der Ansicht, dass Oracle seinen Schwerpunkt in den vergangenen drei bis vier Jahren durch das Angebot von Oracle Express und Standard Edition One auf das KMU-Segment ausgedehnt hat.
494.IBM schätzt, dass Oracle und Microsoft eine starke Präsenz im KMU-Segment haben.
495.Im Hinblick auf die Positionierung von Oracle im KMU-Segment enthält ein Oracle-internes Dokument eine Vergleichstabelle für die verschiedenen Versionen der Oracle-Datenbank. […]*
496.In demselben Dokument wird außerdem bestätigt, dass Oracle Microsoft und MySQL als seine Hauptkonkurrenten bei bestimmten Kunden betrachtet […]*.
497.Was die wettbewerbsrechtliche Würdigung im KMU-Segment betrifft, bewertete die Anmelderin die Position von MySQL in diesem Segment nicht gründlich. Darüber hinaus quantifizierte sie weder die Marktanteile (Einnahmen oder Nutzungen) noch die Bedeutung des Wettbewerbsdrucks, der von einigen der anderen in Bezug auf das KMU-Segment genannten Datenbankanbieter ausgeübt wird.
498.IBM und Sybase scheinen nicht zu den wichtigen Akteuren im KMU-Segment zu gehören. Im Hinblick auf IBM deutet der TAEUS-Bericht an, dass IBM aufgrund seiner Preisstruktur auf dem Markt für die kleinsten Nutzungen wahrscheinlich keine bedeutende Rolle im Wettbewerb spielt. Die Anmelderin erklärt, dass IBM wie Oracle im KMU-Segment „große Schwierigkeiten hatte, im Wettbewerb zu bestehen“. Die Marktuntersuchung hat ergeben, dass IBM und Sybase in der Regel nicht als gleichauf mit den drei wahrscheinlichsten Unternehmen eingeschätzt werden, die im KMU-Segment führend sind, nämlich Microsoft, Oracle und MySQL. Die Untersuchung hat zwar durchwachsene Ergebnisse hervorgebracht, aber auch ergeben, dass die Position von IBM und vor allem von Sybase im KMU-Segment in der Regel als schwächer bewertet wird als in anderen Segmenten des gesamten Datenbanksegments.
499.Andere Open-Source-Wettbewerber wie PostgreSQL und Ingres scheinen derzeit nicht die gleiche Präsenz auf dem Markt zu besitzen wie MySQL. Dies hat die Marktuntersuchung der ersten Phase der Kommission ergeben. Ihnen fehlt gegenwärtig eine umfassende installierte Basis, eine lebendige Entwickler-Community sowie das gleiche Maß an Sensibilisierung und Beachtung innerhalb der Branche.
In diesem Zusammenhang nimmt die Kommission ferner die Einführung kostenloser oder Low-End-Versionen ihrer jeweiligen Datenbank durch IBM, Oracle, Microsoft und Sybase in den letzten Jahren zur Kenntnis. Die Kommission betrachtet dies als mögliche Reaktion auf die Präsenz insbesondere von MySQL und anderen Open-Source-Produkten sowie auf die Expansion, die vom Low-End-Segment des Datenbankmarkts und teilweise vom KMU-Segment ausging.
4.3.4.2.3. Großunternehmenssegment
501.Die Untersuchung der Kommission deutet darauf hin, dass für das Großunternehmenssegment des Datenbankmarkts keine exakte Definition vorhanden ist. Für die Definition von Großunternehmen können verschiedene alternative Kriterien herangezogen werden, wie beispielsweise die Anzahl der Beschäftigten oder der Jahresumsatz. Auch wenn jedoch ein einzelner Indikator als zutreffend identifiziert wird, würde die exakte Grenze dieses Marktsegments unklar bleiben. Fern müsste geklärt werden, ob sich eine Definition lediglich auf den privaten Sektor beziehen oder aber auch öffentlich-rechtliche Körperschaften einschließen würde.
502.Darüber hinaus könnte sich das Großunternehmenssegment, wie für andere Segmente des Datenbankmarkts in Abschnitt 4.3.4.2 dargelegt, erheblich mit anderen Segmenten überschneiden. Beispielsweise könnte eine Datenbank, die von einem Großunternehmen erworben wird, gleichzeitig zum Websegment und zum High-End-Segment gehören.
503.Die Grenzen des Großunternehmenssegments sind daher nicht eindeutig.
504.Angesichts der unklaren Definition des Großunternehmenssegments ist dessen Größe in Bezug auf die Einnahmen und Nutzungen nur schwer zu ermitteln. Die Anmelderin konnte keine Quantifizierung der Größe des Großunternehmenssegments vorlegen. Die Untersuchung ergab keine sonstigen Anhaltspunkte, die der Kommission eine präzise Quantifizierung der Segmentgröße gestatten.
505.Um jedoch zu einer Abschätzung der Segmentgröße zu gelangen, könnte nach Ansicht der Kommission ein Ansatz darin bestehen, die Größe des Gesamtmarkts für Datenbanken als Ausgangspunkt zu verwenden und die Größe des KMU-Segments davon abzuziehen. Der Rest könnte als Wert für die Größe des Großunternehmenssegments verwendet werden, auch wenn dies ein relativ ungenauer Wert wäre.
506.Wie bereits erörtert, gibt es zahlreiche verschiedene Definitionen für KMU. Demzufolge variiert auch die Definition des KMU-Segments ebenso wie die Abschätzung seiner Größe. Wenn logischerweise der Ansatz bestehend aus der Subtraktion der Größe des KMU-Segments vom Gesamtmarkt für Datenbanken angewandt wird, gilt derselbe Präzisionsmangel auch für das Großunternehmenssegment.
329Siehe beispielsweise Antwort der Anmelderin vom 11. Oktober 2009 auf Frage 3 des Auskunftsersuchens der Kommission vom 8. Oktober 2009 (doc_ID 2854) sowie Eingabe der Anmelderin vom 29. Oktober 2009 (doc_ID 3498 und 3499).
109
507.Obwohl es in der Untersuchung der Kommission keine Anhaltspunkte für eine Schätzung des Großunternehmenssegments im Hinblick auf die Nutzungen gab, können die folgenden Alternativen herangezogen werden, um die Größe dieses Segments in Bezug auf die Einnahmen abzuschätzen.
508.Laut Gartner betrug die auf die Einnahmen bezogene Größe des Großunternehmenssegments, sofern davon ausgegangen wird, dass es sich bei Großunternehmen um Unternehmen mit mehr als 500 Beschäftigten handelt, im Jahr 2007 ungefähr 16,2 Mrd. US-Dollar.
509.Die Anmelderin schätzt in einem internen Dokument, dass die auf die Einnahmen bezogene Größe des Datenbanksegments unter Berücksichtigung von Unternehmen mit mehr als 500 Beschäftigten im Jahr 2006 8,6 Mrd. US-Dollar betrug.
510.Laut Gartner betrug die auf die Einnahmen bezogene Größe des Großunternehmenssegments, sofern davon ausgegangen wird, dass es sich bei Großunternehmen um Unternehmen mit mehr als 1.000 Beschäftigten handelt, im Jahr 2007 ungefähr 14,1 Mrd. US-Dollar.
511.Die Anmelderin schätzt in einem internen Dokument, dass die auf die Einnahmen bezogene Größe des Datenbanksegments unter Berücksichtigung von Unternehmen mit mehr als 100 Mio. US-Dollar Jahresumsatz im Jahr 2006 11,6 Mrd. US-Dollar betrug.
512.Angesichts dieser Schätzungen bezüglich der auf die Einnahmen bezogene Größe des Großunternehmenssegments, machen die Großunternehmen allem Anschein nach insgesamt keinen unerheblichen Anteil der Datenbankeinnahmen aus.
513.Im Hinblick auf die Nutzungen, obwohl relativ gesehen sehr wahrscheinlich geringer als in Bezug auf die Einnahmen, scheint das Großunternehmenssegment einen erheblichen Teil des Datenbankmarkts auszumachen.
514.Die Anmelderin äußerte sich nicht explizit zur Wettbewerbssituation im Großunternehmenssegment. Doch angesichts der von der Anmelderin vorgelegten Unterlagen zum „Unternehmensdatenbanksegment“ hat die Kommission den Eindruck gewonnen, dass die Anmelderin die Ansicht vertritt, dass MySQL im Großunternehmenssegment keine bedeutende Rolle im Wettbewerb spielt.
330Gartner, RDBMS Revenue by customer company size [RDBMS-Einnahmen nach Kundenunternehmensgröße], Anhang 1 der Eingabe von Microsoft vom 6. Oktober 2009 (doc_ID 2654).
331Oracle Präsentation, Accelerate Your Business with Oracle [Beschleunigen Sie Ihre Geschäfte mit Oracle], S. 3, abrufbar unter http://www.techselect.com/root/smbaccess%20event%20recap/Oracle%20presentation%20-%20SMB.pdf (doc_ID 3428).
332Gartner, RDBMS Revenue by customer company size [RDBMS-Einnahmen nach Kundenunternehmensgröße], Anhang 1 der Eingabe von Microsoft vom 6. Oktober 2009 (doc_ID 2654).
333Oracle Präsentation, Accelerate Your Business with Oracle [Beschleunigen Sie Ihre Geschäfte mit Oracle], S. 3, abrufbar unter http://www.techselect.com/root/smbaccess%20event%20recap/Oracle%20presentation%20-%20SMB.pdf (doc_ID 3428).
515.Was die Position von MySQL anbelangt, deuten verschiedene Anhaltspunkte darauf hin, dass MySQL im Großunternehmenssegment stark präsent zu sein scheint.
516.Laut Gartner erzielte MySQL bezogen auf seine Gesamteinnahmen von 56 Mio. US-Dollar im Jahr 2007 Einnahmen in Höhe von 48 Mio. US-Dollar (86 %) mit Kunden mit mehr als 1.000 Beschäftigten und 54 Mio. US-Dollar (96 %) mit Kunden mit mehr als 500 Beschäftigten.
517.Im Hinblick auf den Anteil der Nutzungen von MySQL ergab die Untersuchung der Kommission keine präzisen Schätzungen. Jedoch deuten verschiedene qualitative Anhaltspunkte darauf hin, dass MySQL im Großunternehmenssegment bezogen auf die Nutzungen eine starke Präsenz besitzt.
518.Die TNS-Umfrage über die Verwendung von Open-Source-Software in den nordischen Ländern und den Beneluxstaaten belegt, dass die Verwendung von MySQL in Großunternehmen mit mehr als 2.000 Beschäftigten höher ist.
519.Die sonstigen Ergebnisse der Umfrage, die in Abschnitt 4.3.4.1.2 dargelegt wurden, bestätigen eindeutig die Präsenz von MySQL im Großunternehmenssegment.
520.Ein Wettbewerber legte eine Übersicht über die Fortune 500-Unternehmen vor, in denen MySQL allem Anschein nach verwendet wird. Obwohl dies weder eine quantitative Analyse noch eine Analyse in Bezug auf die Bedeutung von MySQL für die einzelnen Kunden darstellt, verdeutlicht dies, dass ein erheblicher Anteil der Fortune 500-Unternehmen MySQL nutzt.
521.Eine Überprüfung der Fallstudien, die auf der MySQL-Website vorgestellt werden, bestätigt, dass MySQL in Großunternehmen der verschiedensten Branchen verwendet wird.
522.2007 erwog die Anmelderin eine Übernahme von MySQL. Ein Oracle-internes Dokument vom November 2007, das zur Erörterung der potenziellen Übernahme mit den Führungskräften von Oracle verfasst wurde, enthält eine Übersicht über die MySQL-Kunden. Der Kundenstamm umfasste damals 3.700 aktive Kunden, darunter Großunternehmen aus den verschiedensten Branchen, wie beispielsweise Pharma-, Verteidigungs-, Fertigungs-, Telekommunikationsunternehmen usw.
523.Darüber hinaus bestätigt die Bewertung von HQ Apps-Dokumenten, die in Abschnitt 4.3.4.1.1 dargelegt wurde, dass MySQL bei den Großunternehmen präsent ist, dass MySQL im Großunternehmenssegment einen erheblichen Wettbewerbsdruck auf Oracle ausübt und dass die Aussicht, dass MySQL in einzelne Großunternehmen eindringen könnte, für Oracle ein Anlass zur Besorgnis ist.
335Gartner, RDBMS Revenue by customer company size [RDBMS-Einnahmen nach Kundenunternehmensgröße], Anhang 1 der Eingabe von Microsoft vom 6. Oktober 2009 (doc_ID 2654).
336TNS Technology – „Open Source Software Barometer 2009 – Nordic and Benelux Report“ (doc_ID 2143).
337Microsoft – Anhang 5 zur Antwort auf den Fragebogen zur Positionierung von Datenbanken (doc_ID 2658).
338http://www.mysql.com/why-mysql/case-studies/ (doc_ID 3429).
525.Was die Position von Oracle im Großunternehmenssegment anbelangt, scheint Oracle eine bedeutende Datenbank und möglicherweise führend in diesem Segment zu sein. Basierend auf der Eingabe der Anmelderin vertritt Oracle anscheinend die gleiche Ansicht.
526.Laut Gartner belief sich der von Oracle 2007 erzielte Datenbankumsatz bei Kunden mit mehr als 500 Beschäftigten auf ungefähr 7,9 Mrd. US-Dollar, was einem Marktanteil von ungefähr 49 % bezogen auf die Einnahmen entsprach.
527.Betrachtet man Unternehmen mit mehr als 1.000 Beschäftigten berichtet Gartner von einem Oracle Datenbankumsatz von annähernd 7 Mrd. US-Dollar, was einem Marktanteil von ungefähr 49,5 % bezogen auf die Einnahmen entsprach.
528.Wie unter Randnummer 511 erwähnt, werden in einem Oracle-internen Dokument die Datenbankeinnahmen nach Kundengröße abgeschätzt, wobei bei einem Jahresumsatz von 100 Mio. US-Dollar eine Grenze gezogen wird. Dieses interne Dokument zeigt, dass Oracle 2006 ungefähr 5,6 Mrd. US-Dollar Einnahmen aus dem Datenbankverkauf an Kunden mit einem Jahresumsatz von 100 Mio. US-Dollar erzielte. Dies entsprach 74 % der Datenbankeinnahmen, die Oracle 2006 erzielte, und einem Marktanteil von 48,5 % der Datenbankeinnahmen in diesem Segment.
529.Was die anderen Wettbewerber anbelangt, scheint in dem im vorstehenden Absatz genannten Dokument Microsoft als „Anbieter A“ und IBM als „Anbieter B“ genannt zu werden. In diesem Dokument werden keine sonstigen Wettbewerber namentlich erwähnt, sondern die übrigen Wettbewerber als „Sonstige“ zusammengefasst. Die jeweiligen auf die Einnahmen bezogenen Marktanteile im Segment für Kunden mit mehr als 100 Mio. US-Dollar Jahreseinnahmen betrugen 16,2 % für Microsoft, 20,6 % für IBM und 14,7 % für sonstige Unternehmen zusammengefasst.
530.Laut Gartner waren 2007 die auf die Einnahmen bezogenen Marktanteile wie folgt auf Kunden mit mehr als 500 Beschäftigten verteilt: 21 % für IBM, 18 % für Microsoft, 4,1 % für Teradata, 3,1 % für Sybase und 4,8 % für Sonstige.
346Gartner, RDBMS Revenue by customer company size [RDBMS-Einnahmen nach Kundenunternehmensgröße], Anhang 1 der Eingabe von Microsoft vom 6. Oktober 2009 (doc_ID 2654).
4.3.4.2.4. High-End-Segment
532.Die Untersuchung der Kommission deutet darauf hin, dass für das High-End-Segment des Datenbankmarkts keine exakte Definition vorhanden ist. Für die Definition des High-End-Segments könnten verschiedene alternative Kriterien herangezogen werden. Die Kriterien könnten die technische Komplexität der von der Datenbank auszuführenden Aufgaben oder die Ausgereiftheit der Datenbank im Hinblick auf die technologischen Leistungsmerkmale umfassen. Ein anderer Ansatz könnte die Berücksichtigung von Datenbanken sein, deren Verwendung für den Kunden unternehmenskritisch zu sein scheint, d. h. der Kunde würde bei Ausfall der Datenbank signifikante und nicht hinnehmbare Umsatzausfälle oder Kostenanstiege verzeichnen. Auch wenn jedoch ein einzelner Indikator als zutreffend identifiziert wird, würde die exakte Grenze dieses Marktsegments unklar bleiben, da beispielsweise eine Datenbank für einige Kunden unternehmenskritisch sein kann, für andere hingegen nicht.
533.Darüber hinaus könnte sich das High-End-Segment, wie für sämtliche anderen Segmente des Datenbankmarkts in Abschnitt 4.3.4.2 dargelegt, erheblich mit anderen Segmenten überschneiden. Beispielsweise könnte eine als High-End betrachtete Datenbank gleichzeitig auch von einem kleineren oder mittleren Unternehmen erworben werden und auch eingebettet sein. Die Grenzen des High-End-Segments sind daher nicht eindeutig.
534.Angesichts der unklaren Definition des High-End-Segments ist dessen Größe in Bezug auf die Einnahmen und Nutzungen nur schwer zu ermitteln. Die Anmelderin konnte keine Quantifizierung des High-End-Segments vorlegen. Die Untersuchung ergab keine sonstigen Anhaltspunkte, die der Kommission eine präzise Quantifizierung des High-End-Segments gestatten.
535.Obwohl es in der Untersuchung der Kommission keine Anhaltspunkte für eine Schätzung des High-End-Segments im Hinblick auf die Nutzungen gab, können die folgenden Alternativen herangezogen werden, um die auf die Einnahmen bezogene Größe dieses Segments abzuschätzen.
536.Ein sehr konservativer Ansatz könnte darin bestehen, die von Oracle bei bestimmten High-End-Merkmalen erzielten Einnahmen heranzuziehen. Insbesondere die Oracle-Datenbankmerkmale „Real Application Cluster“ („RAC“), Partitionierung und erweiterte Sicherheit scheinen in das High-End-Segment zu fallen. Diese könnten als Ausgangspunkte für die Bedeutung des High-End-Segments in Bezug auf die Einnahmen dienen, auch wenn dies eine unzureichende und sehr konservative Proxy-Variable ist.
346Gartner, RDBMS Revenue by customer company size[RDBMS-Einnahmen nach Kundenunternehmensgröße], Anhang 1 der Eingabe von Microsoft vom 6. Oktober 2009 (doc_ID 2654).
537.Gemäß internen Dokumenten der Anmelderin erzielte Oracle die folgenden Lizenzeinnahmen mit dem Verkauf der jeweiligen Produkte:
• […]*
• […]*
• […]*
538.Insgesamt machten diese High-End-Verkäufe Oracle-Einnahmen in Höhe von […]* in den Jahren 2007/2008 aus.
539.Die Anmelderin argumentiert, dass der Kernmarkt für das Flaggschiff-Datenbankprodukt von Oracle, derzeit Version 11g, bei unternehmenskritischen Datenbanknutzungen liege. MySQL besäße bei unternehmenskritischen Datenbanknutzungen hingegen eine unbedeutende Präsenz und wäre deshalb nicht für Transaktionen und unternehmenskritische Verwendungszwecke geeignet. In ihrer Bewertung des „Unternehmensdatenbanksegments“ wiederholt die Anmelderin ähnliche Argumente. Dabei hebt sie die Ausrichtung von Oracle auf Leistung, Skalierbarkeit, Zuverlässigkeit und Sicherheit und die Unmöglichkeit von MySQL hervor, diese Merkmale anbieten und somit im Segment für Unternehmensdatenbanken konkurrieren zu können. Wahrscheinlich würde die Anmelderin eine ähnliche Meinung vertreten, was das High-End-Segment des gesamten Datenbankmarkts anbelangt.
540.Im Hinblick auf die Position von MySQL im High-End-Segment wurde durch die Untersuchung der Kommission das Argument der Anmelderin nicht bestätigt, dass MySQL im High-End-Segment technisch nicht mithalten kann bzw. dass MySQL in diesem Segment nicht im kommerziellen Wettbewerb steht.
541.Die Untersuchung der Kommission hat zwar ergeben, dass MySQL in ausgewählten Fällen bis zu einem gewissen Grad im High-End-Segment konkurrieren kann, hat aber auch gezeigt, dass MySQL gegenwärtig nicht den bedeutendsten Wettbewerbsdruck ausübt. Es gibt in der Tat einige signifikante Bereiche des Datenbankmarkts gibt, in denen MySQL nicht konkurrieren kann. Dies wurde durch den TAEUS-Bericht und die Ergebnisse der Marktuntersuchung bestätigt.
542.Jedoch muss zunächst unbedingt zwischen jenen Bereichen, die MySQL derzeit aus technischen Gründen nicht bedienen kann, und solchen Bereichen, die MySQL gegenwärtig aus kommerziellen Gründen nicht bedient, unterschieden werden. Solche kommerziellen Gründe könnten die hohen Umstellungskosten, die mit der Migration von einem Datenbankanbieter zu einem anderen verbunden sind, und/oder der risikoscheue Charakter der IT-Einkaufsleiter sein. In diesem Zusammenhang ist ein wichtiger Grund möglicherweise, dass MySQL, mit Ausnahme bestimmter Lösungen kleinerer Anbieter, derzeit nicht zur Verwendung mit den gängigsten Unternehmens-Anwendungssoftware-Produkten zertifiziert ist.
348Oracle […]*, Anhang 1.7, S. 12, Einnahmen für den vorangehenden […]* (doc_ID 1484).
349Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009 (doc_ID 2427).
350Schreiben von Oracle an die Kommission (doc_ID 3498) und Tab1 - Oracle Database Competitive Analysis segment analysis [Tabelle 1 – Segmentanalyse und Wettbewerbsanalyse zu Oracle-Datenbanken] (doc_ID 3499).
543.Zweitens bestätigte der TAEUS-Bericht, dass MySQL gegenwärtig bestimmte Bereiche, wie beispielsweise die Skalierung per Fernzugriff, Authentifizierung und Sicherheit, nicht abdecken kann und dass sich dies in Zukunft angesichts der Technologie von MySQL wahrscheinlich nicht ändern wird. Jedoch zeigte der TAEUS-Bericht auch, dass die technologiebezogenen Beschränkungen von MySQL weniger bedeutend sind als von der Anmelderin in ihrer Argumentation vorgebracht. MySQL könnte sich daher in bestimmten Bereichen des High-End-Segments weiterentwickeln.
544.Drittens ergab die Untersuchung der Kommission, dass MySQL bereits von zahlreichen Kunden, bei denen die Nutzung eindeutig in das High-End-Segment fällt, eingesetzt wird bzw. dass der Einsatz von MySQL in Erwägung gezogen wird. Obwohl die Marktuntersuchung alles in allem bestätigte, dass MySQL derzeit kein signifikanter Mitbewerber in den meisten Bereichen des High-End-Segments ist, zeigte sie auch, dass einige Befragte, die den Fragebogen der Kommission ausgefüllt hatten, MySQL als transaktionale Datenbank nutzen. Darüber hinaus haben einige potenzielle MySQL-Kunden verschiedene Datenbankalternativen basierend auf mehreren Bewertungskriterien bewertet und MySQL als wettbewerbsfähiges Angebot identifiziert, auf in Fällen, in denen Oracle die Alternative wäre.
545.Das Beispiel der Deutschen Börse ist besonders bezeichnend. Angesichts der Tatsache, dass die Anmelderin argumentiert, MySQL sei für transaktionale Zwecke im High-End-Segment ungeeignet, und in ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte der vorläufigen Beurteilung der von der Deutschen Börse vorgelegten Informationen vehement widersprochen hat, ist es sinnvoll, die vorgelegten Informationen von Deutsche Börse Systems („DB“) genauer zu prüfen.
546.DB antwortete auf den an Kunden gerichteten Fragebogen der Kommission (Phase II). In Frage 19 ging es darum, ob Kunden über „ein strukturiertes Bewertungs-/Zertifizierungsverfahren zur Ermittlung von verwendbaren Datenbanken verfügen. Wenn ja, geben Sie bitte an, welche Datenbanken zertifiziert und für welche Verwendungszwecke zertifiziert wurden […].“ [„a structured evaluation/certification process to identify databases that you can use. If yes, please indicate which databases have been certified and for which uses […].“]
DB erwiderte Folgendes:
„Ja. Wir verfügen über ein Bewertungs- (Auswahl-) und Zertifizierungsverfahren, das bei der Auswahl sämtlicher Produkte angewendet wird.
Für universell einsetzbare Datenbanken, transaktionale Datenbanken (OLTP) und Data Warehousing (OLAP): Oracle; Sybase und DB2 (vor einigen Jahren vorgenommen).
Für transaktionale Datenbanken (OLTP) – MySQL; Oracle; Postgres“ [„Yes. We have an evaluation (selection) and certification process in place which is valid for any product selection. For general purpose, transactional databases (OLTP) and Data warehousing (OLAP): Oracle; Sybase and DB2 (done a few years ago). For transactional databases (OLTP) – MySQL; Oracle; Postgres“]
Frage 22, in der es darum ging, wie Datenbanken von Sun innerhalb des Unternehmens eingesetzt werden, wurde von DB wie folgt beantwortet:
„Derzeit verwenden wir MySQL noch nicht in der Produktion, planen dies jedoch (universell einsetzbare Datenbank und OLTP) für die Zukunft.“ [„We are not yet using MySQL in production but plan to do so (general purpose database and OLTP) in the future.“]
Auf Frage 30 a) zu universell einsetzbaren Datenbanken antwortete DB, dass sie MySQL aufgrund des Nichtvorhandenseins bestimmter Funktionen als ungeeignet für „Finanzanwendungen, besonders anspruchsvolle Batchverarbeitung“ [„Financial Application; very heavy batch processing“] einstufen.
Auf Frage 34, mit der nach anderen Datenbanken gefragt wurde, die der Kunde als akzeptablen Ersatz für die erworbenen Oracle-Datenbanken beurteilt, antwortete DB Folgendes:
„Angesichts unserer technischen Anforderungen und Datenbank-Arbeitslasten wären IBM, Sybase und Sun als Alternative in Frage gekommen.
Schlüsselparameter:“
[„Considering our technical requirements and database workload, alternative choice would have been IBM; Sybase; Sun. Key Parameters:“][…]*"
Frage 36, in der gefragt wurde, ob das Unternehmen Bemühungen seitens Oracle, besser geeignete Datenbanken für kleine und mittlere Unternehmen anzubieten, festgestellt hatte, wurde von DB wie folgt beantwortet:
„Wir befinden uns auf dem High-End-Unternehmensmarkt und beschäftigen uns daher nicht mit anderen Marktsegmenten.“ [„We are in the high-end Enterprise market, so not looking at what is happening in other market segments.“]
Auf Frage 69 zu den Auswirkungen und Konsequenzen des Zusammenschlussvorhabens auf den Wettbewerb im Datenbankmarkt antwortete DB Folgendes:
„Sofern Oracle weiterhin MySQL entwickelt/unterstützt, befürchten wir keine negativen Auswirkungen des SUN/Oracle-Zusammenschlusses. Diese Aussage ist auf den Datenbankmarkt beschränkt.“ [„Providing Oracle continues to develop/support MySQL, we do not see a negative impact of the SUN/Oracle transaction. This statement is limited to the Database market.“]
Um bestimmte Bestandteile der Antwort von DB auf den an Kunden gerichteten Fragebogen der Kommission zu klären und sicherzustellen, dass die Antworten von DB weiterhin Gültigkeit hatten, hielten die Kommission und DB am 23. November 2009 eine Telefonkonferenz ab.
Protokoll der Telefonkonferenz mit der Deutschen Börse (doc_ID 5058).
554.In dem Gespräch bestätigte DB, dass die Verwendung der MySQL-Datenbank als Bestandteil der neuen IT-Handelsplattform für die Zukunft geplant ist. DB erläuterte, dass MySQL aufgrund seines Funktionsumfangs, Preises und des Support für eine bestimmte Nutzung vorgesehen sei.
555.DB wies jedoch darauf hin, dass für diese Nutzung von MySQL keine Migration vorhandener Anwendungen erforderlich sei, sondern darin bestehen werde, das bei DB vorhandene Portfolio genutzter Datenbanken um neue MySQL-Datenbanknutzungen zu erweitern.
556.Ferner wies DB darauf hin, dass die Verwendung von MySQL zwar für eine bestimmte Nutzung geplant sei, es jedoch zahlreiche andere Nutzungen mit bestimmten Anforderungen gebe, für die MySQL keine angemessene Lösung anbietet. In diesen Fällen sei MySQL daher kein Ersatz für proprietäre High-End-Datenbanken.
557.DB fügte hinzu, dass sie MySQL aus ihrer Sicht als High-End-Unternehmensnutzer alles in allem als angemessene Lösung für weniger hohe Anforderungen beurteilen. Bei anspruchsvollen Anwendungen mit hohen Anforderungen sei MySQL kein Ersatz für Oracle. Grundsätzlich stuft DB MySQL eher als Ergänzung ein.
558.Ferner erklärte DB, dass in Fällen, in denen MySQL eine angemessene Lösung darstellte, der Hauptgrund für die Wahl von MySQL das Verhältnis zwischen den angebotenen Funktionen und dem Preis gewesen sei.
559.Zudem bekräftigte DB die allgemeine Einschätzung, dass DB keinerlei Bedenken hinsichtlich des Zusammenschlussvorhabens habe, sofern Oracle weiterhin Support für MySQL-Produkte anbietet.
560.Angesichts dieser Informationen und ungeachtet der Tatsache, dass DB – unter bestimmten Bedingungen – keinerlei Einwände gegen das Zusammenschlussvorhaben geäußert hat, haben die folgenden Erkenntnisse, die vorläufig in der Mitteilung der Beschwerdepunkte geäußert wurden, weiterhin Gültigkeit: (i) Der Datenbankbedarf von DB fällt in das High-End-Segment des gesamten Datenbankmarkts, (ii) DB verfügt über ein Bewertungsverfahren für die Datenbankbeschaffung, (iii) DB erklärte, MySQL in Zukunft als universell einsetzbare Datenbank und für OLTP verwenden zu wollen, (iv) die Deutsche Börse plant, MySQL für eine bestimmte Nutzung zu verwenden, für die Oracle und PostgreSQL als alternative Datenbanken in Frage gekommen wären, und (v) dies zeigt, dass MySQL von einer Börse im High-End-Segment, einem Bereich, den MySQL nach der Argumentation der Anmelderin nicht bedienen könne, für transaktionale Zwecke in Erwägung gezogen wird.
355In ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte warf die Anmelderin der Kommission vor, die Informationen der Deutschen Börse in der Mitteilung der Beschwerdepunkte falsch darzustellen (doc_ID 4828; zum Beispiel S. 9 und 27). In Fußnote 8 ihrer Erwiderung verweist die Anmelderin des Weiteren auf und zitiert aus dem „Gesprächsprotokoll zwischen Deutsche Börse und Sophie Moonen und Adrian Lübbert von der Kommission am 24. November 2009, von Deutsche Börse an Oracle bereitgestellt" [„Minutes of conversation between Deutsche Börse and Sophie Moonen and Adrian Lübbert of the Commission on 24 November 2009, provided to Oracle by Deutsche Börse“]. Am 4. Dezember 2009 forderte die Kommission eine Kopie dieses „Protokolls“, das Oracle am 7. Dezember 2009 vorlegte (doc ID 4979). Dieses „Protokoll“ des Gesprächs trägt tatsächlich den Titel "[…]*, Oracle". Die Kommission weist darauf hin, dass eine Kopie dieses „Protokolls“ zeigt, dass (i) es sich nicht um ein freigegebenes Protokoll handelt, sondern lediglich um einen internen Bericht von Oracle zum vermeintlichen Inhalt eines Telefongesprächs zwischen DB und dem für die vorliegende Sache zuständigen Team der Kommission, an dem Oracle nicht beteiligt war, und dass (ii) dieses „Protokoll“, insbesondere die Einleitung, im starken Widerspruch zu einem nicht vertraulichen Protokoll des Gesprächs steht, wie zwischen DB und dem für die vorliegende Sache zuständigen Team der Kommission vereinbart und als Teil der Akte der Kommission vorliegend (doc_ID 5058). Darüber hinaus verweist die Anmelderin in ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte auf ein Telefongespräch vom 24. November 2009, wohingegen das Telefongespräch am 23. November 2009 stattfand.
561.Die Untersuchung der Kommission zeigte ferner, dass MySQL mit MySQL Cluster bereits ein High-End-Datenbankprodukt anbietet. Ein Oracle-internes Dokument bestätigt, .[…]* Wie in Abschnitt 4.3.2.4.5. zum Segment für eingebettete Datenbanken erläutert, ergab die Untersuchung der Kommission, dass MySQL Cluster im Segment für eingebettete Datenbanken und insbesondere im untergeordneten Telekommunikationssegment, das als High-End-Segment betrachtet werden könnte, zu konkurrieren scheint.
562.Viertens wird InnoDB, das Oracle gehört, als transaktionale Speicher-Engine für MySQL, d. h. eine Speicher-Engine zur Nutzung von MySQL für Transaktionen, beworben.
563.Schließlich wird MySQL dank verschiedener Speicher-Engines in naher Zukunft im Hinblick auf die Technologie expandieren und einige der Bereiche, die MySQL derzeit nicht bedienen kann, bedienen können. ScaleDB wird beispielsweise in Kürze eine neue MySQL-Speicher-Engine einführen, die es MySQL gestattet, in gewissem Umfang mit Oracle RAC zu konkurrieren. Außerdem soll Calpont im Januar 2010 eine Speicher-Engine einführen, die MySQL in die Lage versetzt, in gewissem Umfang mit Oracle auf dem Gebiet Data Warehousing in Wettbewerb zu treten. Obwohl dies nicht unbedingt in das High-End-Segment fällt, könnte MySQL in mehreren anspruchsvolleren Bereichen des Data Warehousing, genauer gesagt im Bereich bis zu 30 Terabyte Daten, konkurrieren.
564.Was die Position von Oracle im High-End-Segment betrifft, bestätigte die Untersuchung der Kommission die Behauptung der Anmelderin, dass Oracle eine starke Position besitzt. Die Marktuntersuchung ergab Anhaltspunkte, dass Oracle wahrscheinlich führend im High-End-Segment ist, zumindest was die Einnahmen anbelangt.
Bezogen auf die anderen Datenbankanbieter, die im High-End-Segment tätig sind, zeigte die Untersuchung der Kommission, dass zusätzlich zu Oracle insbesondere IBM und in gewissem Umfang Microsoft und Sybase wichtige Wettbewerber sind. Ferner kann Ingres und bis zu einem gewissen Grad auch PostgreSQL im High-End-Segment für bestimmte Verwendungszwecke konkurrieren und ist bei einigen Anwendungen technisch vielleicht sogar besser geeignet als MySQL. Doch weder Ingres noch PostgreSQL verfügen gegenwärtig über die signifikante installierte Basis von MySQL.
4.3.4.2.5. Segment für eingebettete Datenbanken
566.Wie in Abschnitt 2.1.1 erläutert, handelt es sich bei einer eingebetteten Datenbank um eine mit einer Anwendung integrierbare Datenbank, wobei diese Anwendung auf gespeicherte Daten zugreifen muss und diese Datenbank normalerweise für den Endnutzer der Anwendung „verborgen“ ist. Allgemein ausgedrückt, sind eingebettete Datenbanken Datenbanken, die als Teil des Produktangebots eines dritten unabhängigen Softwareanbieters oder Hardware-OEM auf der Basis einer vom Datenbankanbieter gewährten Lizenz gebündelt, verkauft und unterstützt werden.
567.Die Untersuchung der Kommission deutet darauf hin, dass das Segment für eingebettete Datenbanken nicht klar abgegrenzt werden kann und keine eindeutige Unterscheidung zwischen eingebetteten und nicht eingebetteten Datenbanken möglich ist. Ob eine Datenbank eingebettet oder nicht eingebettet ist, hängt weitgehend davon ab, wie der Kunde die Datenbank zu nutzen gedenkt, und nicht von den technischen Eigenschaften der Datenbank selbst. Eine Datenbank, die von einem Kunden als eingebettete Datenbank verwendet wird, könnte von einem anderen Kunden als nicht eingebettete Datenbank genutzt werden. Zwischen eingebetteten und nicht eingebetteten Datenbanken besteht somit ein erheblicher Grad an angebotsseitiger Substituierbarkeit. Dennoch sind einige Datenbanken speziell auf eingebettete Verwendungszwecke ausgerichtet.
568.Angesichts der Schwierigkeiten bei der Abgrenzung des Segments für eingebettete Datenbanken ist die Größe des Segments für eingebettete Datenbanken des Datenbankmarkts sowohl in Bezug auf die Einnahmen als auch im Hinblick auf die Nutzungen schwer abzumessen. Die Anmelderin legte einen IDC-Bericht vor, in dem der Markt für eingebettete Datenbanken untersucht wurde.
569.IDC definiert den Markt für eingebettete Datenbanken bezogen auf Datenbanken, die an unabhängige Softwareanbieter zur Einbindung in deren Softwareprodukte verkauft werden. Dies schließt relationale und nicht relationale Datenbanken ein. In der Regel sind sie für den Endnutzer nicht sichtbar. In dem IDC-Bericht wird der Gesamtmarkt für eingebettete Datenbanken auf ungefähr 1,97 Mrd. US-Dollar im Jahr 2007 geschätzt, von denen 1,63 Mrd. US-Dollar relationalen Datenbanken zugeschrieben werden können.
570.Die IDC-Zahlen können als Proxy-Variable für den Markt für eingebettete Datenbanken dienen, wenn auch der IDC-Bericht beachtlichen Einschränkungen unterliegt. Zunächst schließt der IDC-Bericht relationale und nicht relationale Datenbanken ein. Wie in Abschnitt 1.1 und 2.1 erläutert, bieten nicht relationale Datenbanken nicht die gleichen Vorteile wie relationale Datenbanken und sind weit weniger verbreitet. Für die Bewertung des vorgeschlagenen Zusammenschlussvorhabens betrachtet die Kommission nicht relationale Datenbanken nicht als Teil des sachlich relevanten Markts. Wenn eine Proxy-Variable für die Größe des Segments für eingebettete Datenbanken aus dem IDC-Bericht abgeleitet werden kann, sollte dies mit den Gesamteinnahmen für eingebettete relationale Datenbanken im Zusammenhang stehen.
360Anhang 2 - IDC – Worldwide Embedded Database Management Systems [Eingebettete Datenbankmanagementsysteme weltweit] (doc_ID 2429).
571.Zweitens werden durch die IDC-Definition für eingebettete Datenbanken scheinbar nicht alle Verkäufe eingebetteter Datenbanken erfasst. Wenn eine Datenbank beispielsweise in einem Produkt eingebettet ist, das von demselben Softwareanbieter, der auch die Datenbank herstellt, entwickelt wurde, dann gilt diese Datenbank in einem solchen Fall als Komponente des Produkts, in dem sie enthalten ist, und die Einnahmen, die dieser speziellen Konfiguration entsprechen, werden nicht der Datenbank zugeschrieben. Auch werden die meisten eingebetteten Datenbanken nicht an unabhängige Softwareanbieter (ISV) verkauft, sondern direkt an die Endnutzer. Solche Einnahmen zählen im IDC-Bericht nicht als Umsatz mit eingebetteten Datenbanken. Es zählen nur solche, die direkt über einen dritten unabhängigen Softwareanbieter verkauft werden. Durch die in dem IDC-Bericht angegebenen Einnahmen für eingebettete (relationale) Datenbanken wird daher allem Anschein nach die Größe dieses Marktsegments unterschätzt. Es ist außerdem unklar, inwieweit durch den IDC-Bericht die Einnahmen für eingebettete Datenbanken, die an OEM verkauft werden, erfasst werden.
572.Im IDC-Bericht ist die eingebettete Verwendung von MySQL und anderen Open-Source-Datenbanken unter Open-Source-Lizenzen wie GPL außerdem nicht berücksichtigt.
573.Es wird der Schluss gezogen, dass durch den IDC-Bericht die Größe des Segments für eingebettete (relationale) Datenbanken wahrscheinlich unterschätzt wird, dies aber einen Anhaltspunkt für dessen Mindestgröße bilden kann. Davon ausgehend betrug die Größe des Segments für eingebettete (relationale) Datenbanken 2007 wahrscheinlich mindestens 1,63 Mrd. US-Dollar. Somit stellt dieses Segment einen nicht unbedeutenden Teil des Datenbankmarkts dar.
574.Laut Informationen, die während der Marktuntersuchung der ersten und zweiten Phase zusammengetragen wurden, scheint innerhalb des Segments für eingebettete Datenbanken ein bedeutendes Teilsegment in Bezug auf Telekommunikationskunden vorhanden zu sein. Diese Kunden haben spezielle Bedürfnisse in Bezug auf eine sofortige Reaktionsfähigkeit und sehr hohen Durchsatz. Zur Größe dieses Teilsegments sind keine Analystendaten verfügbar. Die Anmelderin schätzt, dass dieses Teilsegment in Bezug auf die Einnahmen sehr klein ist, d. h. unter 100 Mio. US-Dollar pro Jahr beträgt.
575.Die Anmelderin erkennt an, dass sowohl Oracle als auch MySQL im Segment für eingebettete Datenbanken präsent sind und dass sich die Lizenzversionen von Oracle und der MySQL-Datenbank unter proprietärer Lizenz in diesem Segment überschneiden. Dennoch vertritt die Anmelderin die Ansicht, dass das Zusammenschlussvorhaben auf der Grundlage des IDC-Berichts keinerlei Wettbewerbsprobleme in diesem Segment verursache, der eigene Marktanteil von Oracle mittelmäßig sei und MySQL diesen Marktanteil kaum erhöhen würde. Darüber hinaus seien mehrere Mitbewerber in diesem Markt vertreten. Der Marktanteil von Oracle beträgt 2007 in Bezug auf die Einnahmen anhand des IDC-Berichts 26,3 %, gefolgt von Progress (13 %), IBM (12 %), Sybase (10 %), Microsoft (10 %), Empress (2 %), Pervasive (1,3 %) und dann MySQL mit einem Marktanteil von nur 1,1 %.
361Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), S. 63 (doc_ID 2427).
362Anhang 2 - IDC – Worldwide Embedded Database Management Systems [Eingebettete Datenbankmanagementsysteme weltweit] (doc_ID 2429).
576.Die Anmelderin bestätigt, dass Oracle und MySQL mit ihren Produktangeboten TimesTen bzw. MySQL Cluster in einem Teilsegment des Segments für eingebettete Datenbanken, d. h. dem Markt für speicherresidente Datenbanken, gegeneinander konkurrieren. Die Kunden in diesem Segment kommen gewöhnlich aus der Telekommunikationsbranche. Dennoch argumentiert die Anmelderin, dass diese Produkte keine nahen Substitute sind.
577.Die Segmente für eingebettete und nicht eingebettete Datenbanken überschneiden sich und Datenbankanbieter bieten häufig eingebettete Versionen ihrer allgemeinen Datenbanken an. Somit bleiben die Erkenntnisse über den von MySQL ausgeübten tatsächlichen und dynamischen Wettbewerbsdruck weitgehend für das Segment für eingebettete Datenbanken gültig.
578.Die Marktuntersuchung ergab, dass die Kunden MySQL als eingebettete Datenbanken verwenden. Dies gilt für MySQL Server ebenso wie für MySQL Cluster. Während der Marktuntersuchung gab ein Kunde an, dass er, obwohl er gegenwärtig MySQL-Datenbanken nicht verwendet, MySQL ernsthaft überprüft, um die Oracle-Datenbank des Unternehmens, die in die verschiedenen Systeme/Produkte/Anwendungen eingebettet ist, zu ersetzen. Aus Sicht dieses Unternehmens kann MySQL die Oracle-Datenbank zur Integration in Systeme, Produkte und Anwendungen ersetzen. Unter anderem wurden die sehr hohen Lizenzgebühren von Oracle als wichtigster Antriebsfaktor für die Beschränkung der Oracle-Datenbanknutzung angegeben.
579.Im Zusammenhang mit der Bewertung des Wettbewerbsdrucks, der von MySQL auf Oracle ausgeübt wird, deuten die HQ Apps-Dokumente an, dass eine erhebliche Anzahl der Rabattanträge für eingebettete Anwendungen zu gelten scheinen.
580In einer Oracle-internen E-Mail […]*, […]*. Oracle ist somit der Ansicht, dass seine gegenwärtigen Datenbankprodukte im Segment für eingebettete Datenbanken mit MySQL konkurrieren.
581.Im Hinblick auf das Argument der Anmelderin, dass das Segment für eingebettete Datenbanken nicht konzentriert sei und dass aus dem vorgeschlagenen Zusammenschlussvorhaben kein Wettbewerbsproblem entstehe, sind die Zahlen aus dem IDC-Bericht nicht für die Bewertung der Wettbewerbssituation in diesem Segment geeignet. Zunächst basiert der IDC-Bericht auf Einnahmen, die von den Datenbankanbietern durch Verkäufe an unabhängige Softwareanbieter erzielt wurden. Dies schließt möglicherweise nicht alle Verkäufe eingebetteter Datenbanken ein und spiegelt somit die Wettbewerbssituation in dem Segment für eingebettete Datenbanken nicht unbedingt korrekt wider.
582.Noch bedeutsamer jedoch ist, dass der IDC-Bericht auch nicht relationale Datenbanken enthält, die kaum mit relationalen Datenbanken wie die Datenbank von Oracle und MySQL vergleichbar sind. Die Kommission ist der Auffassung, dass der Markt für relationale Datenbanken in Übereinstimmung mit den anfänglichen Behauptungen der Anmelderin als relevanter Markt zu betrachten ist. Die Anmelderin hat weder aus Nachfrage- noch aus Angebotssicht dargelegt, warum die Unterscheidung zwischen relationalen und nicht relationalen Datenbanken nicht auf das Segment für eingebettete Datenbanken zutreffen sollte. Alcatel Lucent betont beispielsweise, dass eine der in dem IDC-Bericht enthaltenen nicht relationalen Datenbanken, die einen Marktanteil von 13 % besitzt, eine objektorientierte Datenbank sei, die nicht mit einer relationalen Datenbank verglichen werden könne.
583.Die Marktanteile im Segment für eingebettete Datenbanken, die auf der Basis der Verkäufe von relationalen und nicht relationalen Datenbanken ermittelt wurden, sind somit kein Indiz für die Wettbewerbsfähigkeit eines Anbieters einer relationalen Datenbank im Segment für eingebettete Datenbanken.
584.Obwohl schließlich ein großer Teil der Kunden, die Datenbanken für eingebettete Anwendungszwecke nutzen, eine kommerzielle Lizenz für diese Datenbanken, einschließlich MySQL, erwirbt, gibt es dennoch eine Reihe von Kunden, die die MySQL-Datenbank im Rahmen der GPL einbetten. Durch die auf Einnahmen bezogenen Marktanteile wird somit die Präsenz von MySQL in diesem Segment unterschätzt.
585.In diesem Zusammenhang stellt die Kommission fest, dass die Anmelderin während des Verfahrens Erklärungen abgegeben hat, die bis zu einem gewissen Grad als widersprüchlich betrachtet werden können.
586.Einerseits argumentiert die Anmelderin, dass das Segment für eingebettete Datenbanken mit anderen Märkten vergleichbar ist, in denen der auf Einnahmen bezogene Marktanteil als aussagekräftige und zuverlässige Proxy-Variable für die Bewertung des Wettbewerbs herangezogen werden kann. Nach Auffassung der Anmelderin liegt dies daran, dass für die Einbettung eine kommerzielle Lizenz erforderlich ist und daher die Besonderheiten der Bewertung des Wettbewerbsdrucks, den kostenlose Open-Source-Alternativen ausüben, für das Segment der eingebetteten Datenbanken irrelevant sind.
587Ein internes Dokument der Anmelderin […]*. Dies zeigt, dass sich Oracle der Möglichkeit bewusst ist, dass ein Softwareprodukt an einen Kunden geliefert werden kann, der dann die kostenlose Software unter GPL herunterlädt, um sie in das Softwareprodukt einzubetten, ohne dass die GPL-Beschränkungen verletzt werden.
588.In diesem Zusammenhang stellt die Kommission außerdem fest, dass die Anmelderin zusammen mit ihrer Erwiderung auf die Mitteilung der Beschwerdepunkte die Stellungnahme von Prof. Moglen vorgelegt hat. Randnummer 21 der Stellungnahme impliziert analog zu den Erkenntnissen für Speicher-Engines, die als separate und eigenständige Arbeiten qualifiziert sind, dass MySQL unter der GPL eingebettet werden kann, ohne gegen die GPL-Beschränkungen zu verstoßen. Dies wurde auch von Oracle bei der mündlichen Anhörung bestätigt: „[…]*“
367Antwort von Alcatel Lucent auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 2006).
368[…]* (doc_ID 2719).
369Oracle, Anhang 3 der Antwort auf die Mitteilung der Beschwerdepunkte (doc_ID 4831).
370Bemerkungen von […]* (Oracle) bei der mündlichen Anhörung am 10. Dezember 2009 zwischen 16:33 Uhr und 16:34 Uhr.
589.Zwecks Bewertung des Zusammenschlussvorhabens nimmt die Kommission daher die Ansicht von Oracle zur Kenntnis, dass das Einbetten von MySQL unter der GPL in den meisten Fällen ohne Verstoß gegen die GPL-Bestimmungen (GPLv2) möglich ist.
590.In Bezug auf die wettbewerbsrechtliche Würdigung des Segments für eingebettete Datenbanken stellt die Kommission fest, dass Oracle und MySQL insbesondere im Teilsegment des Markts für Telekommunikationsanbieter aufeinandertreffen. MySQL scheint im Teilsegment für eingebettete Datenbanken einen größeren Marktanteil zu besitzen, was Cluster für Telekommunikationsanbieter anbelangt. Das MySQL-Produkt MySQL Cluster ist eine speicherresidente Datenbank und speziell auf die Anforderungen solcher Anwendungen zugeschnitten. Daneben bietet es zahlreiche Leistungsmerkmale zur Verbesserung der Zuverlässigkeit und Leistung solcher Anwendungen. Telekommunikationsanbieter binden MySQL Cluster in ihre Produkte ein, die dann an den Endkunden weiterverkauft werden.
591Oracle ist in diesem Teilsegment mit seiner Datenbank TimesTen vertreten. Oracle TimesTen ist eine speicherresidente und speicheroptimierte relationale Datenbank speziell für Anwendungen, bei denen in Branchen wie beispielsweise Telekommunikation, Kapitalmarkt und Verteidigung sofortige Reaktionsfähigkeit und sehr hoher Durchsatz zum Anforderungsprofil zählen.
592.Oracle argumentiert, dass TimesTen und MySQL keine nahen Substitute seien. Dies wurde durch die Marktuntersuchung nicht vollständig bestätigt. Alcatel Lucent, ein Anbieter verschiedener Telekommunikationsprodukte, erklärte, dass MySQL Cluster technisch durch Oracle TimesTen, IBM Solid oder Oracle Berkeley DB ersetzt werden könne. Unter gewissen Umständen kann es auch durch Oracle Cluster ersetzt werden. Mit dem Erwerb von MySQL Cluster würde sich die Anzahl der Anbieter in diesem Bereich auf zwei Hauptakteure verringern, nämlich Oracle und IBM (Letzterer jedoch mit einem Produkt, das in Verbindung mit der IBM Suite verwendet werden muss). Nach Ansicht von Alcatel Lucent würde dies dazu führen, dass Oracle in diesem Bereich eine beherrschende Stellung einnimmt. Ferner erklärt Alcatel Lucent jedoch, dass man mittlerweile die Bewertung anderer Open-Source-Datenbanken zur eingebetteten Nutzung in Betracht zieht und vier Alternativen prüft. Es wird betont, dass noch nicht sicher ist, ob überhaupt eines dieser Produkte den Anforderungen gerecht wird. In jedem Fall ist eine Migration sehr kostspielig.
593.Ein weiteres Unternehmen erklärte, dass MySQL Cluster einzigartige Fähigkeiten besitzt und dass aufgrund dessen Oracle TimesTen gegenwärtig der einzige ernsthafte Konkurrent sei. IBM Solid DB wäre nicht damit vergleichbar. Das Unternehmen erwartet, dass der Preiswettbewerb nach dem Zusammenschluss definitiv abnimmt.
594.Im Gegensatz zu diesen Bedenken gab Ericsson, ebenfalls ein wichtiger Akteur im Sektor für Telekommunikationsgeräte, jedoch an, dass es die Datenbankangebote der Zusammenschlussparteien als enge Konkurrenten ansieht. Das Unternehmen nannte Sybase und Xeround als MySQL-Konkurrenten bei diesen Telekommunikationsanwendungen, bei denen kurze Reaktionszeiten erforderlich sind. Demzufolge war Ericsson der Ansicht, dass das Zusammenschlussvorhaben keine Wettbewerbsbedenken auf dem Datenbankmarkt aufwerfen würde, und appellierte an die Kommission, den Zusammenschluss so schnell wie möglich ohne Bedingungen zu genehmigen, um der Unsicherheit rund um die Zukunft von Sun ein Ende zu bereiten.
595.Somit scheinen Oracle-Datenbanken und MySQL Cluster einigen, aber nicht allen Antworten auf die Marktuntersuchung im Teilsegment für Telekommunikation zufolge zu den besten Produkten auf dem Markt zu zählen und enge Konkurrenten zu sein. IBM Solid scheint zwar präsent, aber weniger bedeutend zu sein. Außerhalb des Teilsegments für bestimmte Telekommunikationsnutzungen scheint PostgreSQL eine Alternative zu sein.
596.MySQL wurde anfänglich als Datenbank für Webentwickler eingeführt. Im Laufe der Zeit ist MySQL jedoch auch in den Markt für allgemeine Datenbanken eingedrungen. Der Anfang dieser Entwicklung wurde durch die Verfügbarkeit von BerkeleyDB und InnoDB, zwei „transaktionalen“ Speicher-Engines für MySQL, markiert. Durch das neueste Release, d. h. MySQL 5.1., wurde MySQL um weitere Unternehmensfunktionen ergänzt.
597.Die Marktuntersuchung Phase 1 ergab, dass eine überwiegende Mehrheit der Kunden (mehr als 70 %) und nahezu alle Wettbewerber davon ausgehen, dass MySQL diesen Weg weiterverfolgt und sich weiterentwickelt, sodass es im Laufe der Zeit sogar noch höhere Anforderungen erfüllen kann. Die Befragten bei verschiedenen Umfragen erwarteten/planten, MySQL in Zukunft noch stärker einzusetzen (siehe Abschnitt 4.4.2.1.3).
598.Selbstverständlich werden alle Datenbanken schrittweise um neue Leistungsmerkmale ergänzt und in der Gesamtqualität verbessert. Jedoch scheint MySQL während der letzten Jahre erheblich gegenüber den derzeitigen Marktführern aufgeholt zu haben. Dies zeigt, dass die Wettbewerber von MySQL (sowie zukünftige Kunden) nicht nur mit den aktuellen Leistungsmerkmalen rechnen müssen, sondern auch mit dem wahrscheinlichen Entwicklungspfad von MySQL. Beispielsweise ist es angesichts der Aussicht auf ständig zunehmende Leistungsmerkmale für Kunden durchaus sinnvoll, MySQL in Bereichen einzusetzen, in denen es eindeutig ausreicht, und zwar nicht nur, um eine Lösung für die Probleme in diesen Bereichen zu besitzen, sondern auch, um Erfahrungen zu sammeln und Know-how für mögliche zukünftige Nutzungen in anspruchsvolleren Bereichen zu entwickeln. Zuweilen kann diese Art der Einführung von MySQL für „einfachere“ Aufgaben auch zu der Erkenntnis führen, dass bislang kostenintensivere Datenbanken mit speziellen Leistungsmerkmalen für Aufgaben genutzt wurden, für die MySQL bereits ausreichend wäre.
376Siehe Antwort von Ericsson auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 1902) in der aktualisierten Fassung
377Es ist zu beachten, dass BerkeleyDB keine relationale Datenbank ist.
599.Jedoch ist das Potenzial von MySQL nicht auf seine eigene Entwicklungsarbeit beschränkt. Im Gegenteil wird das dynamische Potenzial von MySQL durch das Vorhandensein mehrerer unabhängiger Anbieter von Speicher-Engines verstärkt. Deren Produkte können, unabhängig davon, ob sie nur im Rahmen einer proprietären Lizenz oder einer dualen Lizenzierung, die mit der von MySQL selbst verwendeten vergleichbar ist, verfügbar sind, mit MySQL kombiniert werden, um eine bessere Leistung oder spezielle Leistungsmerkmale hierfür bereitzustellen. Erhebliche Gewinne im Vergleich zu einer Standardinstallation von MySQL in der von Sun vertriebenen Version können ohne Änderung des vorhandenen MySQL-Codes erzielt werden.
600.Beispielsweise entwickelt Calpont gerade eine modulare Speicher-Engine für das Data Warehousing-Segment, wo MySQL gegenwärtig nur marginal wettbewerbsfähig ist. Die Lösung von Calpont würde es MySQL erlauben, seine Wettbewerbsfähigkeit in Bezug auf Data Warehouses von bis zu Dutzenden Terabyte zu einem äußerst attraktiven Preis zu verbessern.
601.ScaleDB entwickelt gerade eine weitere modulare Speicher-Engine, die darauf ausgelegt ist, das Clustering mit einer Architektur mit gemeinsam genutzter Festplatte zu unterstützen. Durch diese Technologie kann MySQL wie Oracle Real Application Cluster (RAC), einer High-End-Datenbank für Anwendungen, die hohen Durchsatz und hohe Verfügbarkeit erfordern, betrieben werden. Im Zeitraum zwischen dem 3. Quartal des Rechnungsjahres 2007 und dem 3. Quartal des Rechnungsjahres 2008 beliefen sich bei Oracle die Einnahmen mit RAC auf […]*
602.Um die Bedeutung von Speicher-Engines von Drittanbietern abzuschätzen, muss beachtet werden, dass die Interessen von Sun und den Anbietern von Speicher-Engines auf einer Linie liegen. Wenn MySQL dank einer Speicher-Engine besser in einem bestimmten Marktsegment konkurrieren kann, profitiert Sun von der Innovation auf Speicher-Engine-Ebene. Umgekehrt profitieren die Anbieter von Speicher-Engines auch davon, wenn MySQL verfügbar ist (sodass sie sich auf die Speicher-Engine konzentrieren, aber den bekannten und weit verbreiteten MySQL Server als Datenbank-Front-End weiterhin nutzten können) und kontinuierlich gepflegt und weiterentwickelt wird. Da Speicher-Engine-Drittanbieter, die zur Sicherstellung ihrer kommerziellen Rentabilität (zumindest teilweise) am dualen Lizenzsystem teilnehmen, eine kommerzielle Lizenz von MySQL benötigen, um ihren potenziellen Kunden ein integriertes Produkt (MySQL und die Speicher-Engine) anbieten zu können, kann Sun über die Lizenzgebühren direkt am finanziellen Erfolg solcher Anbieter von Speicher-Engines teilhaben.
379Siehe Protokoll der Telefonkonferenz mit ScaleDB, S. 1-2 (doc_ID 3036).
380Siehe Protokoll der Telefonkonferenz mit Calpont (doc_ID 2896).
381Antwort von ScaleDB auf das an Datenbankkunden gerichtete Auskunftsersuchen (doc_ID 2489). MySQL Cluster basiert abgesehen davon, dass es sich um eine speicherresidente Lösung handelt, auf einer Shared-Nothing-Architektur (SN), die eindeutige technische Nachteile gegenüber einer Architektur mit gemeinsam genutzter Festplatte besitzt.
382Oracle, […]* (doc_ID 1484). Laut derselben Quelle entspricht dies […]*. Eine andere Quelle gibt an, dass die Einnahmen mit RAC einer wesentlich höheren Wachstumsrate unterlagen, nämlich durchschnittlich […]* in den vergangenen Jahren, siehe Protokoll der Telefonkonferenz mit ScaleDB, S. 3 (doc_ID 3036).
603.In seiner Antwort auf die Mitteilung der Beschwerdepunkte bestritt Oracle die Wichtigkeit, die Speicher-Engines beigemessen wird. Oracle stellte fest, dass die Mehrheit der Nutzer entweder auf MyISAM, die Standard-Speicher-Engine von MySQL, oder auf InnoDB zurückgreift, „die bereits von Oracle kontrolliert wird und von dem vorliegenden Zusammenschluss daher nicht betroffen sein wird“ [„which is already controlled by Oracle and will thus not be affected by the present Transaction“]. Darüber hinaus stellte Oracle in Frage, inwieweit zukünftige Speicher-Engines angesichts der modularen Architektur von MySQL die Datenbank in die Lage versetzen können, Unternehmensanwendungen zu unterstützen, obgleich Oracle einräumte, dass „die modulare Architektur von MySQL es einer großen Gemeinschaft aus mehreren unkoordinierten Gruppen ermöglicht, eine neue Funktion auf den Markt zu bringen, was für Open Source ideal ist“ [„the modular design of MySQL does enable a large community of multiple, uncoordinated groups to bring a new feature or function to market, which is ideal for open source“] :
604.Es ist richtig einzuräumen, wie Oracle es in der Erwiderung auf die Mitteilung der Beschwerdepunkte getan hat, dass sich die Speicher-Engine-Projekte von Calpont und ScaleDB noch in der Entwicklungsphase befinden. Daher kann zu diesem Zeitpunkt nicht mit Sicherheit festgestellt werden, wann die betreffenden Speicher-Engines vertrieben werden und in welchem Umfang sie die Funktionalität von MySQL erweitern und/oder den Wettbewerbsdruck auf Datenbankprodukte von Oracle verstärken, die womöglich im gleichen Zeitraum verbessert werden. Gleichzeitig würde die Angleichung der Interessen von Drittanbietern von Speicher-Engines und Sun (die mittels Lizenzgebühren direkt am finanziellen Erfolg jedes dieser Speicher-Engine-Anbieter beteiligt werden können) nach wie vor nach dem Zusammenschluss wegfallen, da Oracle als führendes Unternehmen auf dem gesamten Datenbankmarkt jedes Mal finanziell davon betroffen wäre, wenn MySQL durch eine spezialisierte Speicher-Engine in bestimmten Segmenten des Markts weiter vordringt. Die einzige Möglichkeit für Oracle, solche negativen Auswirkungen zu vermeiden, ohne (bestimmte) Speicher-Engines von Drittanbietern völlig lahm zu legen, würde entweder darin bestehen, den Preis für kommerzielle Lizenzen für Anbieter von Speicher-Engines oder den Preis von MySQL so festzusetzen, dass es sämtliche Einnahmeneinbußen aus dem Verkauf seines eigenen Produkts wettmachen könnte. Beide Möglichkeiten würden sehr wahrscheinlich zu wesentlich höheren Preisen für eine Kombination von MySQL mit einer Speicher-Engine eines Drittanbieters gegenüber dem gegenwärtigen Preisniveau führen.
605.Die stufenweise Ergänzung von MySQL um Leistungs- und Qualitätsmerkmale, die bislang nur bei höherpreisigen proprietären Datenbanken anzutreffen waren, sowie die modulare Speicher-Engine-Architektur, die die Nutzung der Innovationen von Drittanbietern gestattet, führen zu einer besonderen Art von Wettbewerbsdruck, der von MySQL auf konkurrierende Datenbankanbieter ausgeübt wird. Die von Oracle, Microsoft und IBM angestrebte Einführung kostenloser Einstiegsversionen ihrer Datenbanken kann als Versuch betrachtet werden, mit dem verhindert werden soll, dass durch das dynamische Wachstum von MySQL, d. h. durch die starke Übernahme unter Entwicklern und neuen Nutzern, die eigene Basis unterminiert wird.
606.MySQL scheint Wettbewerbsdruck auf andere Akteure neben Oracle auszuüben. MySQL scheint häufig neben Oracle auch im Wettbewerb mit anderen Produkten proprietärer Wettbewerber zu stehen, wie durch CRM und HQ Apps angedeutet (siehe Abschnitt 4.3.4.1.1). Darüber hinaus gibt die Anmelderin im Formblatt CO zu, dass „zwischen Oracle und MySQL zahlreiche Wettbewerber auf der Substitutionskette liegen, darunter IBM, Microsoft, Sybase und zwei Anbieter transaktionsorientierter Open-Source-Produkte (Postgres und Ingres)“ [„there are many competitors that lie between Oracle and MySQL on the chain of substitution, including IBM, Microsoft, Sybase and two transaction oriented open-source vendors (Postgres and Ingres)“]. Es scheint somit offensichtlich, dass durch die Präsenz von MySQL Wettbewerbsdruck auf die dazwischen liegenden Wettbewerber, wie von Oracle definiert, ausgeübt wird.
607.In diesem Zusammenhang nimmt die Kommission die Einführung von kostenlosen oder preisgünstigen/Low-End-Versionen in den letzten Jahren zur Kenntnis. Microsoft führte SQL Server Express Edition, eine kostenlose, benutzerfreundliche, schlanke und integrierbare Version von SQL Server ein. IBM bietet IBM DB2 Express Edition an, das sich als idealer Einstiegs-Datenserver positioniert. Sybase bietet nun Sybase ASE Express Edition, eine kostenlose Version seiner Datenbank, an.
608.Die Marktuntersuchung ergab, dass die Anbieter proprietärer Datenbanken MySQL zumindest in einigen Segmenten als Mitbewerber ansehen: IBM betrachtet MySQL als wichtigen Akteur im KMU-Segment, der mit Oracle, Microsoft, Sybase, Progress und Netezza konkurriert, und Microsoft sieht MySQL (und Oracle) als seine stärksten Konkurrenten auf dem Datenbankmarkt an. Sybase bestätigte in einer Telefonkonferenz mit den Kommissionsdienststellen, dass MySQL Wettbewerbsdruck ausübt, da „MySQL bereits ausreichend Leistungsmerkmale bieten würde, um im mittleren Segment des Datenbankmarkts, einem mehrere Milliarden schweren Marktsegment, wirksam zu konkurrieren.“ [„MySQL would already be sufficiently feature-rich to compete effectively in the middle segment of the database market, a multi-billion market segment.“] Darüber hinaus stellt Sybase fest, dass MySQL weiterhin mehr und mehr zu unternehmensspezifischen transaktionalen Funktionen wie die in Oracle, Sybase usw. zu findenden übergeht.
609.Auf der Website von MySQL werden verschiedene Beispiele für die Migration von proprietären Datenbanken zu MySQL in den verschiedenen Segmenten beschrieben. Abgesehen von den Beispielen für die Migration ausgehend von Oracle Datenbanken, migrierte Omaha Steaks ausgehend von DB2, Associated Press und The Phone House Telecom GmbH ausgehend von Informix sowie Sabre und Shinsei Bank ausgehend von
387Formblatt CO, S. 5.
388Antwort von IBM auf Frage 5 des Auskunftsersuchens in Bezug auf die Positionierung von MySQL durch Oracle (doc_ID 2472).
389Antwort von IBM auf Frage 9 des Auskunftsersuchens in Bezug auf die Positionierung von MySQL durch Oracle (doc_ID 2653).
390Siehe Protokoll der Telefonkonferenz mit Sybase (doc_ID 2074).
391Siehe http://www.mysql.com/customers/migration/
392.Mainframe. The Platform und Ticketmaster migrierten ausgehend von Microsoft SQL Server, Lafarge und CNET Networks ausgehend von Sybase.
610.Die Schlussfolgerungen aus der Beurteilung der diversen potenziellen Segmente des gesamten Datenbankmarkts werden unter Randnummer 611 bis 615 dargelegt.
611.Im Websegment scheint MySQL der führende Datenbankanbieter zu sein. Oracle-Datenbanken können das Websegment bedienen, doch gegenwärtig ist Oracle in diesem Segment vergleichsweise schwach vertreten.
612.Im KMU-Segment scheinen MySQL, Oracle und Microsoft die drei führenden Anbieter zu sein. Es gibt eine Reihe von Alternativen, darunter die Open-Source-Alternative PostgreSQL. Die meisten dieser Alternativen haben jedoch einen gewissen Abstand von den drei führenden Anbietern.
613.Im Großunternehmenssegment ist sowohl MySQL als auch Oracle vertreten. In Bezug auf die Datenbankanforderungen scheint dieses Segment jedoch eher unspezifisch zu sein. Je nach den genauen Datenbankanforderungen wird das Segment von diversen alternativen Datenbanken bedient.
614.Im High-End-Segment scheint MySQL aus technischen und kommerziellen Gründen gegenwärtig ein unzureichender Ersatz für Oracle-Datenbanken zu sein. Es wird zwar erwartet, dass MySQL weiter in das Segment vordringt, doch MySQL scheint technische Beschränkungen aufzuweisen.
615.Im Segment für eingebettete Datenbanken scheinen die verschiedenen Absatzkanäle an unabhängige Softwareanbieter und OEMs keine gravierenden Auswirkungen auf die Wettbewerbsituation zu haben. In einigen Bereichen des Segments für eingebettete Datenbanken ist MySQL vertreten und scheint dort im Wettbewerb mit anderen Anbietern zu stehen. Insbesondere scheint MySQL im Teilsegment Telekommunikation ein wichtiger Akteur zu sein. Bei Betrachtung des extrem differenzierten Segments für eingebettete Datenbanken insgesamt scheint allerdings die Angebotsseite vergleichsweise weniger stark konzentriert zu sein, und es gibt Alternativen zu MySQL und Oracle.
616.Wie in Abschnitt 4.3 dargelegt, übt MySQL möglicherweise im Datenbankmarkt einen bedeutenden Wettbewerbsdruck auf Oracle aus. Würden MySQL und Oracle im gleichen Markt oder zumindest in bestimmten Segmenten des Datenbankmarkts konkurrieren, hätte Oracle ein kommerzielles Interesse daran, den Wettbewerb zwischen den beiden Produkten, d. h. Oracle-Datenbanken und MySQL zu unterbinden. Dadurch würde der Wettbewerb in jenen Segmenten, in denen MySQL vor der Übernahme einen beträchtlichen Wettbewerbsdruck auf Oracle ausübte, deutlich geschwächt. Da das Zusammenschlussvorhaben jedoch ein Open-Source-Softwareprodukt betrifft, müssen die Möglichkeiten und Anreize für Oracle im Hinblick auf die Abwertung oder Beseitigung von MySQL sowie die wahrscheinliche künftige Weiterentwicklung von MySQL nach dem Zusammenschluss näher untersucht werden.
617.Durch das Zusammenschlussvorhaben würde die Anmelderin die Urheberrechte am gesamten Quellcode der MySQL-Datenbankprodukte übernehmen. Abgesehen von den Teilen des Codes, die in der Vergangenheit bereits unter der GPL-Lizenz zur Verfügung gestellt wurden, hätte die Anmelderin die Kontrolle über die Entscheidung, ob der Code, der unter den verschiedenen Lizenzmodellen zur Verfügung gestellt wird, erweitert, gekürzt oder geändert wird. Darüber hinaus würde die Anmelderin weitere Rechte erwerben, beispielsweise die Marke, und würde zumindest am Anfang die Arbeitgeberin der MySQL-Mitarbeiter sein, die derzeit bei Sun beschäftigt sind.
618.Nach dem Zusammenschluss könnte Oracle theoretisch beschließen, MySQL-Code im Rahmen der GPL einfach nicht mehr anzubieten. Vorausgesetzt, dass Oracle die Marke MySQL besitzen würde, würde MySQL nach einem solchen Schritt nicht mehr als Open-Source-Produkt existieren, und nur die vorhandenen Open-Source-Lizenzen würden übrig bleiben.
619.Zusammengefasst bedeutet dies, dass gegenüber der Basis der bestehenden Nutzer (und potenziellen zukünftigen Nutzer) von MySQL keinerlei Verpflichtung oder Automatismus bestehen würde, im Laufe der Zeit neue Leistungsmerkmale oder Fehlerkorrekturen kostenlos und außerhalb der bezahlten jährlichen Serviceabonnements zu erhalten.
620.Die Anmelderin könnte außerdem im Laufe der Zeit die Leistungsmerkmale und Funktionen von MySQL, die unter der GPL verfügbar sind, abwerten, auch wenn eine derartige Abwertung der GPL-Version von MySQL mit der Zeit viele aktuelle Nutzer von MySQL unter der GPL dazu bewegen könnte, mit anderen Open-Source-Datenbanken oder einer proprietären Datenbank eines anderen Anbieters zu arbeiten.
621.Die Anmelderin argumentiert, dass es nicht in ihrem kommerziellen Interesse läge, MySQL nach dem Zusammenschlussvorhaben abzuwerten. Ferner erklärt die Anmelderin, dass sie ein kommerzielles Interesse daran hätte, mit der MySQL-Community „verbunden“ zu bleiben, da einige MySQL-Nutzer im Laufe der Zeit womöglich auf eine Datenbank (z. B. ein Oracle-Produkt) umstellen möchten, die verschiedene Arbeitsbelastungen bewältigen kann. Die Anmelderin ist der Ansicht, dass die Bedeutung der MySQL-Abonnement- und -Lizenzeinnahmen für das fusionierte Unternehmen nicht unterschätzt werden sollte. Im Hinblick auf die Strategie nach dem Zusammenschluss trägt die Anmelderin vor, dass sie MySQL so positionieren würde, dass das Produkt mit SQL Server von Microsoft konkurrieren kann, wobei das Web- und das KMU-Segment hier im Vordergrund stehen. Ferner vertritt die Anmelderin die Ansicht, dass jeder Versuch, MySQL abzuwerten, dem Ansehen der Anmelderin beträchtlichen Schaden zufügen würde.
622.Wenn Wettbewerbsdruck festgestellt wurde, ist die Kommission der Ansicht, dass diese Argumente für sich genommen nicht ausreichen, um eine erhebliche Beeinträchtigung des wirksamen Wettbewerbs nach dem Zusammenschluss auszuschließen.
623.Es ist offensichtlich, dass das fusionierte Unternehmen im Falle von zwei konkurrierenden Produkten, die vor dem Zusammenschluss einen bedeutenden Wettbewerbsdruck aufeinander ausgeübt haben, nach dem Zusammenschluss einen Anreiz hat, die Überschneidung zu verringern.
624.Die Kommission ist jedoch nicht der Meinung, dass der Anmelderin daran gelegen sein könnte, das Angebot von MySQL sofort einzustellen. Dies ist in erster Linie darauf zurückzuführen, dass die Ingenieure und der Kundenstamm von MySQL in der Tat wertvolles Kapital für Oracle darstellen können. Darüber hinaus könnte sich ein solches Verhalten in der Tat negativ auf den Ruf der Anmelderin als führendes Open-Source-Unternehmen sowie ihren Ruf als Softwareanbieter insgesamt auswirken.
625.Oracle hat ferner das Argument vorgebracht, dass es bei der Weiterführung von InnoDB, einem quelloffenen Datenbankprodukt und meistverwendete Speicher-Engine für MySQL, das 2005 von Oracle übernommen wurde, als Indikator dafür herangezogen werden sollte, dass Oracle nach dem Zusammenschlussvorhaben mit MySQL auf die gleiche Weise verfahren wird. Die Kommission hat die internen Dokumente von Oracle in Bezug auf die Übernahme und Verwaltung von InnoDB gesichtet. Anhand dieser Auswertung lässt sich mit Sicherheit sagen, wie Oracle vorträgt, dass Oracle InnoDB weiterhin entwickelt und unter der GPL zur Verfügung stellt. Jedoch zeigen diese Dokumente auch, dass Oracle Pläne hatte, seinen Entwicklungsschwerpunkt auf Closed-Source-Versionen von InnoDB zu verlagern und überwiegend in neue Merkmale zu investieren, die nicht unter der GPL zur Verfügung gestellt werden sollten. Darüber hinaus muss man sich bewusst machen, dass die Anreize für Oracle in Bezug auf InnoDB nicht unbedingt die gleichen waren wie diejenigen nach der Übernahme von MySQL. Insgesamt lässt sich sagen, dass der Umgang von Oracle mit InnoDB, obwohl dies nicht mit der wettbewerbsrechtlichen Würdigung im Hinblick auf MySQL im Zusammenhang steht, die von Oracle eingenommene Position in diesem Verfahren nicht direkt und eindeutig unterstützt.
626.Jedoch hat die Kommission im Anschluss an die Antwort der Anmelderin auf die Mitteilung der Beschwerdepunkte alle Elemente, die zu diesem Zeitpunkt in der Akte zur vorliegenden Sache vorhanden waren, erneut bewertet.
627.Die Akte zur vorliegenden Sache enthält die öffentliche Ankündigung, die Oracle am 14. Dezember 2009 herausgab, um MySQL-Kunden, -Nutzer und -Entwickler hinsichtlich der künftigen Weiterentwicklung von MySQL nach dem Zusammenschluss zu beruhigen.
628.Wie in Abschnitt 4.2 erläutert, kann die öffentliche Ankündigung von Oracle in zwei Kategorien eingeteilt werden: (i) Punkt 1, 2 und 3 der öffentlichen Ankündigung von Oracle, die Oracle unmittelbar durch Zusendung von Schreiben an achte Dritte umgesetzt hat, in denen zugesagt wird, dass die bestehenden Vertragsbedingungen nach dem Zusammenschluss geändert und diese somit für Oracle gegenüber diesen Parteien rechtsverbindlich festgelegt werden; und (ii) die übrigen Punkte der öffentlichen Ankündigung von Oracle, bei denen es sich um rein einseitige Erklärungen ohne Rechtsverbindlichkeit für Oracle handelt.
629.Die Ankündigung insgesamt sowie ihre teilweise Umsetzung stellen Fakten dar und sind in der Akte der Kommission zur vorliegenden Sache enthalten. Zur Bewertung der vorliegenden Sache muss die Kommission die Punkte der ersten Kategorie in Betracht ziehen, da sie insoweit rechtsverbindliche Zusagen darstellen, als sie in Schreiben, die Oracle an Dritte übermittelt hat, umgesetzt wurden. Aufgrund der extremen Besonderheiten der Open-Source-Branche betrachtet die Kommission die Punkte der zweiten Kategorie ebenfalls als relevant.
630.Im übrigen Teil dieses Abschnitts wird erläutert, inwiefern die öffentliche Ankündigung von Oracle, die fünf Jahre nach Abschluss des Zusammenschlussvorhabens gültig ist, für die Bewertung der Möglichkeiten und Anreize der Anmelderin, MySQL nach dem Zusammenschlussvorhaben abzuwerten oder dessen Entwicklung auf bestimmte Segmente zu fokussieren, relevant ist, insbesondere aufgrund der Besonderheiten von Open-Source-Software.
631.Im Rahmen der öffentlichen Ankündigung sicherte die Anmelderin für mindestens fünf Jahre nach Abschluss des Zusammenschlussvorhabens Folgendes zu:
395„Verpflichtung, MySQL in der Zukunft unter der GPL zu verbessern. Oracle wird MySQL weiterhin verbessern und nachfolgende Versionen von MySQL, einschließlich Version 6, unter der GPL zur Verfügung stellen. Oracle wird keine neue, verbesserte Version von MySQL Enterprise Edition herausgeben, ohne gleichzeitig eine neue, ebenso verbesserte Version von MySQL Community Edition, die unter der GPL lizenziert ist, herauszugeben. Oracle wird weiterhin den Quellcode aller Versionen von MySQL Community Edition kostenlos veröffentlichen.“ [„Commitment to enhance MySQL in the future under the GPL. Oracle shall continue to enhance MySQL and make subsequent versions of MySQL, including Version 6, available under the GPL. Oracle will not release any new, enhanced version of MySQL Enterprise Edition without contemporaneously releasing a new, also enhanced version of MySQL Community Edition licensed under the GPL. Oracle shall continue to make the source code of all versions of MySQL Community Edition publicly available at no charge.“]
632.Angesichts dieser öffentlichen Ankündigung ist zu erwarten, dass die Anmelderin den MySQL-Code nach dem Zusammenschlussvorhaben weiterhin unter der GPL anbietet. Darüber hinaus wird die Anmelderin durch Anbieten von MySQL unter der GPL die Patentlizenz, die indirekt in der GPL enthalten ist, auf ihren eigenen Patentbestand ausweiten. Dadurch wird gleichzeitig die theoretische Beschränkung ausgeräumt, mit der GPL-basierte Ableger von MySQL ohne die öffentliche Ankündigung konfrontiert gewesen wären (Abschnitt 4.4.3 enthält eine ausführliche Beurteilung von Ablegern). Es ist zu erwarten, dass die Anmelderin MySQL unter der GPL nicht abwerten wird, sondern die GPL-Version zeitgleich mit der proprietären Version von MySQL verbessern wird.
633.Hinsichtlich der Gültigkeit der Zusagen von Oracle von fünf Jahren ist dieser Zeitraum lang genug, um die Verfügbarkeit einer verbesserten MySQL-Version sicherzustellen, bis andere Anbieter von Open-Source-Datenbanken, möglicherweise einschließlich Ablegern von MySQL, ihre Marktposition weiterentwickelt haben.
634.Sun bietet gegenwärtig „Abonnements“ für „MySQL Enterprise“ an, durch die MySQL-Kunden im Rahmen der GPL zur Verfügung gestellt wird, die aber bezahlte kommerzielle Unterstützung und Schadloshaltung von Kunden gegenüber Klagen wegen der Verletzung geistiger Eigentumsrechte durch Dritte beinhalten. Zahlreiche Unternehmen, die MySQL intern verwenden, benötigen sowohl kommerzielle Unterstützung als auch Schadloshaltung, was bei kommerzieller Software Standard ist.
635.Durch entsprechende Festsetzung der Preise für solche Abonnements könnte die Anmelderin sicherstellen, dass ihre Gesamteinnahmen durch die Verfügbarkeit der GPL-Version von MySQL nicht negativ beeinträchtigt werden, was die kommerziellen Kunden anbelangt.
636.Die Kommission nimmt jedoch die folgenden Aspekte der öffentlichen Ankündigung der Anmelderin zur Kenntnis:
397.Oracle betont zu Recht, dass „Kunden überwiegend die Community-Version von MySQL Server benutzen. Dies schließt Kunden ein, die MySQL Enterprise lizenzieren“ [„consumers overwhelmingly use the community edition of MySQL Server. This includes consumers who license MySQL Enterprise“], Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), S. 89 (doc_ID 2427). Sun quantifiziert diese Informationen und schätzt, dass weniger als 1 % aller Abonnenten den Erhalt von MySQL Enterprise im Rahmen einer proprietären Softwarelizenz wünschen, S. 3 (doc_ID 2293).
398.In der Tat besitzen viele Unternehmen interne Vorschriften, die die Benutzung von Software verbieten, für die keine kommerzielle Unterstützung und Schadloshaltung gegenüber Klagen wegen der Verletzung geistiger Eigentumsrechte durch Dritte erhältlich ist. Dies fällt in der Bereich der Risikominderung. „Bei entsprechender Befragung gaben viele Unternehmen an, dass sie in Bezug auf offenen Quellcode ernsthaft befürchten, für die von ihnen eingesetzten Open-Source-Produkte keine Unterstützung erhalten zu können“ [„When polled, many enterprises claim that a significant fear they have, in terms of open source, is not being able to get support for the open source products they deploy“], Oracle, Competitive Intelligence, PostgreSQL, Mai 2008, S. 1 (doc_ID 1488).
„Support nicht obligatorisch Kunden werden nicht verpflichtet sein, als Voraussetzung für den Kauf einer kommerziellen MySQL-Lizenz Supportdienstleistungen von Oracle zu erwerben.“ [„Support not mandatory. Customers will not be required to purchase support services from Oracle as a condition to obtaining a commercial license to MySQL.“]
und
„MySQL-Referenzhandbuch. Oracle wird weiterhin ein MySQL-Referenzhandbuch ähnlicher Qualität verwalten, aktualisieren und kostenlos als Download zur Verfügung stellen.“ [„MySQL Reference Manual. Oracle will continue to maintain, update and make available for download at no charge a MySQL Reference Manual similar in quality.“]
und
„Kundenauswahl für Support beibehalten. Oracle wird sicherstellen, dass Endnutzer und Kunden eingebetteter Datenbanken, die für MySQL-Supportabonnements zahlen, in der Lage sind, ihr Abonnement je nach Kundenpräferenz für ein oder mehrere Jahre zu verlängern.“ [„Preserve Customer Choice for Support. Oracle will ensure that end-user and embedded customers paying for MySQL support subscriptions will be able to renew their subscriptions on an annual or multi-year basis, according to the customer’s preference.“]
Die Untersuchung der Kommission hat ergeben, dass für die große Mehrheit von Supportangelegenheiten MySQL-Support von Drittanbietern erhältlich ist. Angesichts der öffentlichen Ankündigung ist sichergestellt, dass alternative Quellen für MySQL-Support zur Verfügung stehen. Das MySQL-Referenzhandbuch, das möglicherweise für die Bereitstellung von Support erforderlich ist, wird weiterhin verfügbar sein, wie es derzeit der Fall ist. Darüber hinaus haben dritte Unternehmen, die MySQL unter der GPL vertreiben, und Drittanbieter von Support ebenfalls die Möglichkeit, Kunden gegenüber Klagen wegen der Verletzung geistiger Eigentumsrechte durch Dritte schadlos zu halten.
638.Demzufolge ist es offenbar unwahrscheinlich, dass die Anmelderin ein Interesse daran hat, die Supportpreise in dem Zeitraum, für den die öffentlichen Zusagen gelten, anzuheben, da sie wahrscheinlich weiterhin mit anderen Anbietern von Supportdienstleistungen konkurrieren muss.
639.Im Hinblick auf proprietäre Versionen von MySQL wird die Anmelderin unabhängig von technischen Erwägungen nach dem Zusammenschluss grundsätzlich in der Lage sein, die Preise und Lizenzbedingungen für MySQL unter proprietären Lizenzen zu kontrollieren.
640.Doch aufgrund der Tatsache, dass durch die öffentlichen Zusagen der Anmelderin gewährleistet ist, dass MySQL unter der GPL weiterhin verfügbar ist, dass die GPL-Version von MySQL weiterhin gleichzeitig verbessert wird und dass Kunden die Möglichkeit haben, Support auszuwählen, hat ein solches Verhalten angesichts der begrenzten Anzahl von Kunden der proprietären Version von MySQL ohne vergleichbare Alternativen wahrscheinlich nur begrenzte Gesamtauswirkungen.
641.Hinsichtlich der Gültigkeit der öffentlichen Zusagen von Oracle von fünf Jahren ist dieser Zeitraum lang genug, um Oracle in seinen Möglichkeiten einzuschränken, die Preise zu erhöhen und die Lizenzbedingungen von MySQL unter proprietären Lizenzen zu verschlechtern, bis andere Anbieter von Open-Source-Datenbanken, möglicherweise einschließlich Ablegern von MySQL, die MySQL möglicherweise ersetzen können, ihre Marktposition weiterentwickelt haben.
642.MySQL übt ebenfalls einen dynamischen Wettbewerbsdruck auf die Anmelderin und andere Anbieter proprietärer Datenbanken aus. MySQL hat durch seine modulare Architektur und insbesondere die Fähigkeit, verschiedene Speicher-Engines (potenziell von anderen Anbietern bereitgestellt) parallel (und seit Version 5.1 dynamisch) zu unterstützen, gezeigt, dass es in diversen Bereichen des gesamten Datenbankmarkts Wettbewerbsdruck ausüben kann.
643.Drittanbieter von Speicher-Engines sind abhängig von der technischen Möglichkeit, ihre Produkte mit dem Hauptdatenbankserver von MySQL koppeln zu können, und der kommerziellen Möglichkeit, ihre Produkte im Rahmen eines geeigneten Lizenzmodells zusammen mit MySQL ausliefern zu können.
644.Nach dem Zusammenschluss wäre Oracle in der Lage, jeglichen Wettbewerbsdruck, der gegenwärtig durch Speicher-Engines von Drittanbietern ausgeübt wird, zu kontrollieren und einzudämmen. Erstens könnte Oracle aus technischer Sicht verhindern, dass Speicher-Engines von Drittanbietern in Verbindung mit MySQL funktionieren, indem es die Schnittstellen, die diese Interaktion gegenwärtig unterstützen, ändert. Zweitens kann sich Oracle ferner weigern, MySQL-Code an die betreffenden Drittparteien zu lizenzieren und/oder seinen MySQL-Kunden den Betrieb von MySQL in Verbindung mit bestimmten Speicher-Engines von Drittanbietern im Rahmen der Softwarelizenz zu erlauben. Drittens könnte Oracle den Support für MySQL-Nutzer einstellen, die Speicher-Engines von Drittanbietern einsetzen.
400Siehe beispielsweise Antwort von Calpont, einem Speicher-Engine-Anbieter, auf Frage 8 und 13 des an Speicher-Engine-Anbieter gerichteten Auskunftsersuchens (doc_ID 3664).
401Calpont begann aufgrund der Unsicherheit im Hinblick auf die von Oracle verfolgten Pläne, die Möglichkeiten der Verwendung von Monty Program Ab auszuloten, was in einem Telefongespräch mit dem für die vorliegende Sache zuständigen Team erläutert wurde: „Calpont leitete Diskussionen über eine Absichtserklärung mit Monty Program Ab (Anbieter eines MySQL-Forks, MariaDB) ein, um die Möglichkeit der Kombination von MariaDB mit der Calpont Speicher-Engine als alternative Lösung zu MySQL auszuloten. Calpont zieht diese Option wegen seiner Bedenken in Bezug auf den Vertrag mit Sun und den in Zukunft möglichen Absichten, die Oracle bei MySQL verfolgt, weiterhin ernsthaft in Erwägung. Als auf die GPL begrenzter Fork kann Monty Program jedoch keine kommerzielle Lizenz für seine auf MySQL basierende Datenbanktechnologie anbieten. Die Gründe, warum Calpont sich auch mit Maria DB beschäftigt, liegen in seinen Befürchtungen, dass Oracle nach dem Zusammenschluss andere und vielleicht noch restriktivere Bedingungen als die von Sun auferlegten Bedingungen festlegen und somit sein Geschäft mit Nutzern, Vertriebspartnern und Branchenanalysten unterminieren könnte.“ [Calpont initiated Letter of Intent discussions with Monty Program Ab (provider of a MySQL fork, MariaDB) in order to explore the possibility of combining MariaDB and the Calpont storage engine as an alternative solution to MySQL. Calpont continues to seriously consider this option because of its concern with the Sun contract and Oracle’s future possible intentions with MySQL. However, being a fork limited to the GPL, Monty Program cannot provide a commercial license to its database technology based on MySQL. The reasons why Calpont also looks at Maria DB is their fear that post-merger Oracle might impose different and even more restrictive conditions than those proposed by Sun, thereby undermining their business with Users, channel partners and industry analysts.“], S. 1 (doc_ID 2896).
645.Die Kommission nimmt jedoch die folgenden Aspekte der öffentlichen Ankündigung der Anmelderin zur Kenntnis:
„Fortgesetzte Verfügbarkeit von Speicher-Engine-APIs. Oracle wird die modulare Speicher-Engine-Architektur von MySQL pflegen und regelmäßig verbessern, sodass die Nutzer über die Flexibilität verfügen, um aus einem Portfolio nativer und von Drittanbietern angebotenen Speicher-Engines zu wählen.
Die modulare Speicher-Engine-Architektur von MySQL bedeutet das derzeitige Verfahren, öffentlich verfügbare, dokumentierte Anwendungsprogrammierschnittstellen zu verwenden, um den Speicher-Engine-Anbietern die Kommunikation mit dem MySQL-Datenbankserver zu ermöglichen. Die Dokumentation wird mit der derzeit von Sun bereitgestellten Dokumentation übereinstimmen.“ [„Continued Availability of Storage Engine APIs. Oracle shall maintain and periodically enhance MySQL’s Pluggable Storage Engine Architecture to allow users the flexibility to choose from a portfolio of native and third party supplied storage engines. MySQL’s Pluggable Storage Engine Architecture shall mean MySQL’s current practice of using, publicly-available, documented application programming interfaces to allow storage engine vendors to “plug” into the MySQL database server. Documentation shall be consistent with the documentation currently provided by Sun.“]
und
„Keine Durchsetzung. Als Urheberrechtsinhaber wird Oracle die aktuelle Politik von Sun ändern und gegenüber niemandem durchsetzen oder mit der Durchsetzung drohen, dass Speicher-Engine-Implementierungen von Drittanbietern unter der GPL veröffentlicht werden müssen, da sie die Anwendungsprogrammierschnittstellen implementiert haben, die als Bestandteil der modularen Speicher-Engine-Architektur von MySQL zur Verfügung stehen.
Zur Implementierung der Anwendungsprogrammierschnittstellen, die als Bestandteil der modularen Speicher-Engine-Architektur von MySQL zur Verfügung stehen, verlangt Oracle von Drittanbietern von Speicher-Engines keine kommerzielle Lizenz.
Oracle gibt diese Verpflichtung in Vertragsverpflichtungen gegenüber Speicher-Engine-Anbietern weiter, die gegenwärtig über eine kommerzielle Lizenz von Sun verfügen.“ [„Non-assertion. As copyright holder, Oracle will change Sun’s current policy and shall not assert or threaten to assert against anyone that a third party vendor’s implementations of storage engines must be released under the GPL because they have implemented the application programming interfaces available as part of MySQL’s Pluggable Storage Engine Architecture. A commercial license will not be required by Oracle from third party storage engine vendors in order to implement the application programming interfaces available as part of MySQL's Pluggable Storage Engine Architecture. Oracle shall reproduce this commitment in contractual commitments to storage vendors who at present have a commercial license with Sun.“]
MySQL. Die Gründe warum Calpont auch looks at Maria DB is their fear that post-merger Oracle might impose different and even more restrictive conditions than those proposed by Sun, thereby undermining their business with Users, channel partners and industry analysts.“], S. 1 (doc_ID 2896).
und
„Lizenzverpflichtung. Nach Beendigung des aktuellen MySQL-OEM-Vertrags wird Oracle Speicher-Engine-Anbietern, die gegenwärtig eine kommerzielle Lizenz von Sun besitzen, eine Verlängerung ihres Vertrags zu denselben Bedingungen und mit einer Laufzeit maximal bis zum 10. Dezember 2014 anbieten.
Oracle gibt diese Verpflichtung in Vertragsverpflichtungen gegenüber Speicher-Engine-Anbietern weiter, die gegenwärtig über eine kommerzielle Lizenz von Sun verfügen.“ [„License commitment. Upon termination of their current MySQL OEM Agreement, Oracle shall offer storage vendors who at present have a commercial license with Sun an extension of their Agreement on the same terms and conditions for a term not exceeding December 10, 2014. Oracle shall reproduce this commitment in contractual commitments to storage vendors who at present have a commercial license with Sun.“]
646.Die Anmelderin hat somit öffentlich erklärt, dass sie die modulare Speicher-Engine-API von MySQL für fünf Jahre weiter unterstützen wird und für Drittanbieter von Speicher-Engines, die diese API implementieren, auf die GPL-Bestimmungen hinsichtlich einer freien Lizenz verzichtet. Der von Oracle zugesagte Anspruchsverzicht ist nicht so zu verstehen, dass alle Fälle, in denen bei einer Speicher-Engine eines Drittanbieters diese API implementiert wird, einen Verstoß gegen die GPL darstellen. Es ist daher zu erwarten, dass es Drittanbietern von Speicher-Engines erlaubt wird, ihren Kunden eine Kombination aus MySQL unter der GPL und der Speicher-Engine (auch unter einer proprietären Lizenz) als integriertes Produkt anzubieten.
647.Zudem hat Oracle auch erklärt, dass alle bestehenden kommerziellen Lizenzverträge zwischen Sun und Drittanbietern von Speicher-Engines zu denselben Bedingungen für eine Frist von fünf Jahren verlängert werden. Der Zeitraum, für den die öffentlichen Zusagen gelten, bietet Speicher-Engine-Anbietern die Möglichkeit, ihr Geschäft weiterzuentwickeln und so eine Marktposition zu erlangen, die auch am Ende des Zeitraums noch wettbewerbsfähig ist.
648.Darüber hinaus wurden der Kommission Kopien der acht Schreiben zur Verfügung gestellt, die die Anmelderin an Dritte gesendet hat, darunter auch an vier Drittanbieter von Speicher-Engines. Die Schreiben, die für Oracle rechtsverbindlich sind, geben den relevanten Inhalt der öffentlichen Zusagen der Anmelderin wieder und stellen einen Tatsachenbeleg für den ersten Schritt zur Umsetzung der öffentlichen Zusagen dar.
649.Diese Aspekte der öffentlichen Ankündigung und deren teilweise Umsetzung gegenüber Dritten verringern sehr wahrscheinlich die Möglichkeiten der Anmelderin, Merkmale von Produkten zu benachteiligen, die auf MySQL basieren, oder Drittanbieter von Speicher-Engines, einschließlich jener Produkte, die mit Oracle-Datenbanken auf dem Markt konkurrieren, auszugrenzen.
650.Die Anmelderin erklärte außerdem, dass sie Beratungsgremien für MySQL-Kunden und für Anbieter von Speicher-Engines einrichten und beibehalten werde:
„MySQL-Beratungsgremium für Kunden. Spätestens sechs Monate nach dem Jahrestag des Abschlusses wird Oracle ein Beratungsgremium für Kunden einrichten und finanzieren, darunter insbesondere für Endnutzer und Kunden eingebetteter Datenbanken, um Hinweise und Feedback zu MySQL-Entwicklungsprioritäten und anderen wichtigen Themen für MySQL-Kunden bereitzustellen.“ [„MySQL Customer Advisory Board. No later than six months after the anniversary of the closing, Oracle will create and fund a customer advisory board, including in particular end users and embedded customers, to provide guidance and feedback on MySQL development priorities and other issues of importance to MySQL customers.“]
und
„MySQL-Beratungsgremium für Speicher-Engine-Anbieter. Spätestens sechs Monate nach dem Jahrestag des Abschlusses wird Oracle ein Beratungsgremium für Speicher-Engine-Anbieter einrichten und finanzieren, um Hinweise und Feedback zu MySQL-Entwicklungsprioritäten und anderen wichtigen Themen für MySQL-Speicher-Engine-Anbieter bereitzustellen.“ [„MySQL Storage Engine Vendor Advisory Board. No later than six months after the anniversary of the closing, Oracle will create and fund a storage engine vendor advisory board, to provide guidance and feedback on MySQL development priorities and other issues of importance to MySQL storage engine vendors.“]
651.Schließlich erklärte die Anmelderin, dass die Ausgaben für Forschung und Entwicklung zu MySQL erhöht werden:
„Erhöhung der Ausgaben für Forschung und Entwicklung zu MySQL. Oracle verpflichtet sich, für die fortlaufende Entwicklung von MySQL (GPL-Version und kommerzielle Version) zur Verfügung zu stellen. In den nächsten drei Jahren wird Oracle für die Forschung und Entwicklung (F&E) im globalen MySQL-Geschäftsbereich mehr ausgeben, als Sun im letzten Geschäftsjahr vor dem Abschluss des Zusammenschlussvorhabens ausgegeben hat (24 Mio. US-Dollar).“ [„Increase spending on MySQL research and development. Oracle commits to make available appropriate funding for the MySQL continued development (GPL version and commercial version). During each of the next three years, Oracle will spend more on research and development (R&D) for the MySQL Global Business Unit than Sun spent in its most recent fiscal year (USD 24 million) preceding the closing of the transaction.“]
652.Es ist zu erwarten, dass durch diese Teile der öffentlichen Ankündigung in Kombination mit der Zusage, MySQL in Zukunft zu verbessern, die Weiterentwicklung von MySQL-Produkten in beträchtlichem Umfang gewährleistet ist und dass dabei die Anforderungen und Wünsche von Verbrauchern und Speicher-Engine-Anbietern berücksichtigt werden.
653.Hinsichtlich der Gültigkeit der Zusagen von Oracle von fünf Jahren ist dieser Zeitraum lang genug, um die Weiterentwicklung von MySQL-Produkten sicherzustellen, bis andere Anbieter von Open-Source-Datenbanken, einschließlich Ablegern von MySQL, ihre Marktposition weiterentwickelt haben.
654.Daher ist die Kommission insgesamt der Auffassung, dass die öffentliche Ankündigung der Anmelderin und deren teilweise Umsetzung Fakten darstellen, die bei der Beurteilung der wahrscheinlichsten Entwicklung von MySQL nach dem Zusammenschluss zu berücksichtigen sind. Wie in Abschnitt 4.2 erläutert, vertritt die Kommission die Ansicht, dass die Besonderheiten von Open-Source-Software und das zugehörige dynamische Ökosystem einen selbstregulierenden Mechanismus darstellen, wodurch gewährleistet wird, dass Oracle nicht in der Lage ist und kein Interesse daran hat, von dem für die Zukunft angekündigten Verhalten abzuweichen.
655.Für den führenden Akteur in einem Open-Source-Projekt und den Mittelpunkt eines Open-Source-Ökosystems spielt der Ruf eine wichtige Rolle. Wenn der führende Akteur in einem Open-Source-Projekt, der im Mittelpunkt eines Open-Source-Ökosystems steht, seinem eigenen Ruf schadet und das Vertrauen der Open-Source-Community verliert, besteht ein höheres Risiko des Verlustes von Netzwerkeffekten durch Fragmentierung und Neuorientierung der Community. Somit riskiert der führende Akteur, die Kontrolle über eine bis dato relativ einige Community zu verlieren und dem Open-Source-Projekt Schaden zuzufügen, da sich das Ökosystem möglicherweise neu orientiert und einem anderen führenden Akteur zuwendet.
656.Ferner bewirken die Besonderheiten der Softwareindustrie und insbesondere des Datenbankmarkts, dass dem Ruf eines Anbieters ein noch größerer Stellenwert beigemessen wird als in anderen Wirtschaftssektoren. Zusätzlich zu den in der Softwarebranche vorherrschenden Netzwerkeffekten treffen Datenbanknutzer und -kunden Nutzungsentscheidungen, die zukunftsorientiert sind und langfristige Auswirkungen auf ihre Tätigkeit haben. Die Glaubwürdigkeit und der Ruf eines Anbieters zum Zeitpunkt der Nutzungsentscheidung kann daher in der Datenbankbranche als noch wichtiger betrachtet werden, und ein Anbieter, dessen Ruf beschädigt ist, läuft Gefahr, bei künftigen Nutzungsentscheidungen im Wettbewerb benachteiligt zu sein. Eine Beschädigung des Rufs von Oracle infolge der schlechten oder unzureichenden Weiterführung von MySQL hätte daher wahrscheinlich nachteilige Auswirkungen auf das proprietäre Softwaregeschäft von Oracle.
657.Durch das Zusammenschlussvorhaben wird die Anmelderin zum „Eigentümer“ anderer Open-Source-Produkte wie Java, OpenSolaris und OpenOffice. Die Anmelderin bietet bereits einige Open-Source-Produkte wie Oracle Enterprise Linux und Oracle VM an. Nach dem Zusammenschluss hat die Anmelderin mit Sicherheit weiterhin Interesse am Erfolg einer Reihe von Open-Source-Produkten, insbesondere von Java oder Linux. Demzufolge hat der Ruf der Anmelderin in der Open-Source-Community insgesamt nach dem Zusammenschluss einen hohen Stellenwert.
658.Angesichts der obigen Erwägungen wird der Schluss gezogen, dass die Anmelderin nach dem Zusammenschluss alles in allem wahrscheinlich nicht die Möglichkeit und den Anreiz hätte, MySQL abzuschaffen.
4.4.2Möglicher Wettbewerbsdruck anderer Open-Source-Datenbanken auf Oracle
659.Im Rahmen der Prüfung des Zusammenschlussvorhabens muss die Kommission auch untersuchen, in welchem Maße die Anbieter anderer Datenbanken den bislang von MySQL ausgeübten Wettbewerbsdruck aufrechterhalten könnten, falls MySQL nach dem Zusammenschluss vom Markt genommen würde.
660.Der neue Wettbewerbsdruck könnte entweder von einer anderen Open-Source-Datenbank, die, obwohl sie bereits heute auf dem Markt konkurriert, ihr Angebot ausweiten und an die von MySQL eingenommene Wettbewerbsposition rücken könnte (dieser Abschnitt), oder von einem Ableger von MySQL, d. h. einem neuen Wettbewerber, der in den Markt eintritt und mit dem vorhandenen MySQL-Produkt beginnt und die Entwicklung und Unterstützung dieses Produkts fortsetzt (Abschnitt 4.4.3), ausgeübt werden.
661.MySQL übt aufgrund seines Geschäftsmodells und der Tatsache, dass es sich um Open-Source-Software handelt, einen besonderen Wettbewerbsdruck aus, der sich von dem Wettbewerbsdruck anderer Anbieter proprietärer Datenbanken unterscheidet. Es steht außer Frage, dass Oracle auch nach dem Zusammenschluss dem harten Wettbewerb anderer Anbieter proprietärer Datenbanken, wie z. B. IBM, Microsoft, Sybase und anderen, deren Datenbankangebote in Abschnitt 1.2.3 beschrieben wurden, ausgesetzt sein wird. In dem im Abschnitt 4.3.4.4. dargelegten Maße scheint MySQL jedoch ein besonderes Potenzial zur Ausübung von Wettbewerbsdruck nicht nur auf Oracle, sondern auch auf andere Anbieter proprietärer Datenbanken zu haben. Die Bewertung der Kommission konzentriert sich dabei auf den Wettbewerbsdruck, den andere Anbieter von Open-Source-Datenbanken potenziell auf Oracle und andere Anbieter proprietärer Datenbanken ausüben könnten.
662.Die Anmelderin argumentiert, dass die Datenbankprodukte Ingres und PostgreSQL eigentlich ebenfalls unter Open-Source-Lizenzen erhältlich und MySQL überlegen seien, insbesondere in Bezug auf die komplexere Nutzung in Unternehmen mit Ausrichtung auf die bestehenden Kunden von Oracle. Wenn daher ein quelloffenes Datenbankprodukt Wettbewerbsdruck auf Oracle ausüben könnte, wären dies Ingres und PostgreSQL und nicht MySQL.
663.Einige Aspekte der unternehmerischen und technischen Historie der Datenbanken Ingres und PostgreSQL sollten hier erwähnt werden. Die University of California, Berkeley, entwickelte die Datenbanksoftware unter dem Namen Ingres („Interactive Graphics Retrieval System“) in den siebziger Jahren, teilweise mit öffentlichen Mitteln. Die Datenbank und ihr Quellcode waren zu einem moderaten Preis und unter der BSD-Lizenz, d. h. einer freizügigen Open-Source-Lizenz, erhältlich, die es dem Lizenznehmer gestattete, den lizenzierten Code in eigene proprietäre Produkte zu integrieren. Dieser Datenbankcode bildete den Kern für viele der heutigen Wettbewerber auf dem Datenbankmarkt.
664.Einige Personen, die in Berkeley an Ingres gearbeitet hatten, entwickelten das Produkt NonStopSQL für Tandem Computers, das nach der Übernahme von Tandem durch Compaq und die Übernahme von Compaq durch HP heute weiterhin kommerziell vertrieben wird. Andere Programmierer von Ingres gründeten 1979 das Unternehmen Britton Lee Inc., um ein RDBMS in Verkehr zu bringen. Britton Lee wurde 1990 von Teradata, einem führenden Anbieter von Data Warehousing-Datenbanktechnologie, übernommen. Ein Teil dieser Programmierer gründete 1984 Sybase, das ebenfalls ein RDBMS in Verkehr brachte und lange Zeit der Hauptkonkurrent von Oracle auf dem Datenbankmarkt war.
665.1980 wurde Relational Technology Inc. (RTI), später umbenannt in Ingres Corporation, gegründet. Dieses Unternehmen verwandelte den Ingres-Code in ein kommerzielles Produkt. Ingres Corporation wurde 2005 von dem Unternehmen Computer Associates übernommen und abgespalten. 2006 gab dieses Unternehmen eine Version seines Datenbankprodukts unter der GPL frei und folgte einem dualen Lizenzierungsansatz, der mit dem von Sun bei MySQL angewandten Ansatz vergleichbar ist, d. h. es vertreibt Ingres auch unter einer kommerziellen Lizenz.
666.Wiederum in Berkeley begann Mitte der achtziger Jahre die Entwicklung einer Datenbank „post-Ingres“, darunter durch Personen, die bislang bei RTI gearbeitet hatten. Deren Produkt wurde wechselnd Postgres und PostgreSQL (nach der Ergänzung um SQL-Funktionen) genannt und wie zuvor bei Ingres wurden Unternehmen gegründet, die kommerzielle Produkte basierend auf dessen im Rahmen einer BSD-Lizenz erhältlichen Quellcode entwickelten. Ein solches Unternehmen, Illustra, wurde in den neunziger Jahren von Informix, nun zu IBM gehörend, übernommen. Die Entwicklung von PostgreSQL als Open-Source-Projekt im Rahmen der BSD-Lizenz wird fortgesetzt.
667.2004 wurde EnterpriseDB gegründet und vertreibt ein Produkt, das auf dem PostgreSQL-Code unter der BSD-Lizenz basiert. Während EnterpriseDB einige seiner Entwicklungen zum Open-Source-Projekt, im Rahmen dessen PostgreSQL gepflegt wird, beiträgt, sind die wichtigen kommerziellen Produkte von EnterpriseDB an proprietäre Lizenzen geknüpft. Der damalige CEO von EnterpriseDB erklärte im Jahr 2007, dass die GPL, da sie Lizenznehmer zum Weitervertrieb nur unter der GPL zwingt, dem Lizenzgeber ermögliche, seine Technologie zu kontrollieren, selbst wenn er es als quelloffenes Produkt freigibt und parallel dazu kommerzielle Lizenzen anbietet, wohingegen dies für Software, die unter einer BSD-Lizenz freigegeben wird, nicht gelte, da hier ein Lizenznehmer den Code unter einer BSD-Lizenz als proprietär festlegen und somit aus den Investitionen und Entwicklungen des Lizenzgebers Kapital schlagen könne.
668.Zusammenfassend folgt Ingres seit 2006 dem gleichen Geschäftsmodell wie MySQL. Das wichtigste Datenbankprodukt von EnterpriseDB ist gegenwärtig ein proprietäres Angebot, das auf frei verfügbarem Code basiert, dessen wichtigste Leistungsmerkmale (z. B. in Bezug auf die Kompatibilität mit den Datenbanken von Oracle) nicht kostenlos erhältlich sind.
669.Wie aus den Umfragen, den internen Dokumenten der beteiligten Unternehmen und den Analystenberichten ersichtlich, scheint insbesondere die Marktposition von Ingres in erheblichem Maß auf seinem bestehenden Kundenstamm, der aus einer 25 Jahre währenden Unternehmensgeschichte herrührt und den überwiegenden Anteil der von Ingres erzielten Einnahmen mit RDBMS ausmacht, zu basieren.
670.Im Hinblick auf PostgreSQL ist festzustellen, dass obwohl es in zahlreichen Marktstudien nicht einmal erwähnt wird und weitaus weniger häufig als MySQL in
dennoch mächtige Wahrheit über kommerziellen Open-Source-Code ist, dass die GPL ein hervorragendes Druckmittel für die kommerzielle Wertschöpfung darstellt. Im Gegensatz zu den meisten Open-Source-Projekten, die unter der GPL oder einer ähnlichen Lizenz lizenziert werden, ist PostgreSQL ein Projekt mit BSD-Lizenz. Wie die meisten von Ihnen wissen, gehört BSD zu den freizügigsten Lizenzen, die es jedem erlaubt, alles mit dem Code zu tun, also praktisch ohne Einschränkungen ist. Mit anderen Worten bietet die BSD-Lizenz überhaupt keinen kommerziellen Schutz, ob gegenüber Wettbewerbern oder potenziellen Kunden. Bei der BSD-Lizenz kann jeder den Code verwenden und damit tun, was er möchte.“ [„We originally planned simply to take the same approach as most other open source companies, which is a dual-licensing strategy. With a dual-licensing approach, the company is protected by a GPL (or similar) license, because both competitors and potential customers who wish to embed/link with the GPL software must also GPL their own code. Since most competitors/customers don’t wish to do so, they are willing instead to pay for a commercial license. This simple yet subtle point is at the heart of the success of nearly every commercial open source organization. […] [T]he subtle yet powerful truth about commercial open source is that the GPL is an excellent enforcement mechanism for creating commercial value. Now, unlike most open source projects, which are licensed under the GPL or similar license, PostgreSQL is a BSD-licensed project. As most of you know, BSD is among the most permissive licenses, allowing anyone to do anything with the code, with virtually no restrictions. In other words, the BSD license provides no commercial protection whatsoever, either from competitors or potential customers. With the BSD, anyone can take the code and do anything they wish.“] Der Autor fährt fort und erläutert, dass EnterpriseDB, da es das PostgreSQL-Projekt nicht ins Leben gerufen habe, die erneute Freigabe des Codes unter der GPL nicht in Erwägung ziehe. (Ingres Corporation hatte exakt diesen Schritt unternommen, hatte sein Produkt aber mehr als ein Jahrzehnt lang als proprietäre Version zur Verfügung gestellt, als es dies tat.)
In der Tat hat EnterpriseDB IBM dazu verleitet, eine Lizenz für diese Technologie zu erwerben, http://www.enterprisedb.com/company/news_events/press_releases/2009_09.do, gedruckt am 13. Oktober 2009 (doc_ID 2967).
Für 2007 vermeldete Ingres RDBMS-Einnahmen in Höhe von 28 Mio. US-Dollar, IDC, Worldwide Relational Database Management Systems 2007 Vendor Shares [Relationale Datenbankmanagementsysteme – Marktanteile 2007 weltweit], S. 4 (doc_ID 2432). Gartner berichtet in Bezug auf Ingres von Einnahmen in Höhe von 41,4 Mio. US-Dollar im Jahr 2007 und 54,8 Mio. US-Dollar im Jahr 2008, Gartner, Open-Source DBMS 2009; Gaining in Maturity and Use [Open-Source-DBMS 2009; Zunehmende Reife und Benutzung], S. 3 (doc_ID 2276).
In einem kürzlich vorgelegten Gartner-Bericht werden die Einnahmen von EnterpriseDB mit 12,5 Mio. US-Dollar im Jahr 2008 angegeben, Gartner, Open-Source DBMS 2009; Gaining in Maturity and Use [Open-Source-DBMS 2009; Zunehmende Reife und Benutzung], S. 3 (doc_ID 2276). Ebenso scheint das Data Warehouse-Produktangebot von Netezza auf PostgreSQL aufgebaut zu sein, jedoch ist die Bewertung seines nur mit RDBMS erzielten Umsatzes nicht so einfach möglich. Eine gemeldete Summe ist 49 Mio. US-Dollar im Jahr 2007, IDC, Worldwide Relational Database Management Systems 2007 Vendor Shares [Relationale Datenbankmanagementsysteme – Marktanteile 2007 weltweit], S. 4 (doc_ID 2432).
de HQ Apps-Dokumenten erscheint, seine Präsenz in diesem Datenbestand nicht als unbedeutend abgetan werden kann.
671.Die Kommission erhielt im Rahmen der fortgesetzten Untersuchung nach Annahme der Mitteilung der Beschwerdepunkte ferner Daten von verschiedenen Datenbankanbietern, darunter MySQL und PostgreSQL, in Bezug auf die Anzahl der Gelegenheiten, bei denen einige ihrer Produkte heruntergeladen wurden. Die im Rahmen dessen erhaltenen Daten in Bezug auf PostgreSQL sind jedoch mit Vorsicht zu behandeln, da sie nicht alle Gelegenheiten beinhalten, bei denen die Datenbank möglicherweise heruntergeladen wurde (beispielsweise als Teil eines Softwarepakets oder von Servern, für die keine Daten vorlagen). Infolgedessen wird die tatsächliche Marktpräsenz von PostgreSQL eventuell durch die Daten unterrepräsentiert. Ungeachtet der vorstehenden Erwägungen können die Download-Zahlen für PostgreSQL, obwohl erheblich geringer als für MySQL bezogen auf einen vergleichbaren Zeitraum, nicht als unbedeutend angesehen werden.
672.Darüber hinaus ergab die Marktanalyse, dass PostgreSQL, wenn auch nicht Ingres, das Potenzial besitzt, im Hinblick auf den ausgeübten Wettbewerbsdruck rechtzeitig die Rolle von MySQL zu übernehmen.
In Bezug auf PostgreSQL betonte die Mehrheit der Befragten bei den an Datenbankkunden, Datenbankwettbewerber und Datenbankintegratoren gerichteten Auskunftsersuchen der Komission, dass es gute Leistungsmerkmale, insbesondere für Unternehmensanwendungen, biete. Obwohl sich manche Kunden wegen des Fehlens eines starken Unternehmenssponsors für das Open-Source-Projekt PostgreSQL und der daraus folgenden (zumindest wahrgenommenen) mangelnden Verfügbarkeit von für Unternehmen geeigneter Unterstützung und Dienstleistungen für das Produkt besorgt zeigten, äußerte die Mehrheit die Ansicht, dass PostgreSQL MySQL erwartungsgemäß als Wettbewerbskraft auf dem Datenbankmarkt ersetzen könnte, sollte es Oracle versäumen, nach dem Zusammenschlussvorhaben eine Open-Source-Version von MySQL zu entwickeln. Obwohl sich die Schätzungen in einigen Fällen auf 10 Jahre oder auch nur 1 Jahr beliefen, gaben viele Befragte an, dass eine solche Entwicklung ihren Erwartungen zufolge mehrere Jahre dauern werde. Nach Ansicht von EnterpriseDB, einem im Jahr 2004 gegründete Unternehmen, das sein wichtigstes Datenbankprodukt auf PostgreSQL aufbaut, beträgt der entsprechende Zeitrahmen 2 bis 4 Jahre, wobei „seit Jahren Nutzer von MySQL zu PostgreSQL migrieren“ [„the migration of users from MySQL to PostgreSQL has been happening for years“].
674.In Bezug auf Ingres waren weniger Befragte überzeugt, dass Ingres einen Ersatz für den von MySQL auf Oracle ausgeübten Wettbewerbsdruck darstellen könnte. Die Entscheidung der Ingres Corporation aus dem Jahr 2006, den Quellcode unter der GPL zur Verfügung zu stellen, wird nicht als sehr erfolgreich angesehen. Insbesondere wurde das völlige Fehlen einer Open-Source-Community, die an dem Ingres-Code arbeitet und dazu beiträgt, festgestellt.
675.Ingres und PostgreSQL sind seit Jahrzehnten auf dem Markt. Ihr Erfolg ist beschränkt, besonders im Vergleich zu MySQL. Allerdings war der Erfolg von MySQL vielleicht einer der Faktoren, die ein größeres Wachstum von PostgreSQL, insbesondere im Websegment des Datenbankmarkts, verhindert haben. So könnten Änderungen von Oracle am Status von MySQL neue Marktchancen für Produkte auf der Grundlage von PostgreSQL oder für Ingres eröffnen und die Verbreitung dieser Produkte erhöhen, wie von verschiedenen Befragten im Rahmen des Auskunftsersuchen der Kommission in der Tat bestätigt.
676.Die Anmelderin selbst argumentierte, dass diese Produkte bereits heute für Unternehmen geeignete Produktleistungsmerkmale aufweisen, die in MySQL nicht oder zumindest nur in Ansätzen vorhanden sind. Ingres Corporation und PostgreSQL konzentrieren ihre Bemühungen seit Jahren auf das Unternehmenssegment und haben in anderen Marktsegmenten nur begrenzten Erfolg. Im Websegment würde insbesondere PostgreSQL vom Wegfall des Wettbewerbers MySQL profitieren.
677.Angesichts des Vorgenannten wird der Schluss gezogen, dass insbesondere PostgreSQL (oder eine andere auf diesem Code basierende Datenbank) stärkeren Zulauf erfahren könnte, wenn Oracle Änderungen am Status von MySQL vornimmt, und sogar den von SQL derzeit auf dem Datenbankmarkt ausgeübten Wettbewerbsdruck bis zu einem gewissen Grad ersetzen könnte.
4.4.3Möglicher Wettbewerbsdruck von MySQL-Ablegern auf Oracle
Es ist möglich, dass viele Unternehmen nach dem Zusammenschluss erfolgreich in den Datenbankmarkt eindringen und zu profitablen Unternehmen avancieren, indem sie Unterstützungsleistungen für MySQL oder einen Ableger dieses Produkts anbieten (unabhängig davon, ob sie selbst einen solchen Ableger anbieten). Dies bedeutet jedoch nicht, dass diese Unternehmen einzeln oder gemeinsam das Potenzial dazu haben, einen Wettbewerbsdruck auszuüben, der dem von MySQL gleichkommt.
679.Niemand bestreitet, dass es keine rechtlichen Möglichkeiten gibt, Ableger von MySQL zu verhindern. Dies bedeutet, dass jedes Unternehmen die Möglichkeit hat, den Quellcode der aktuell unter der GPL verfügbaren Version von MySQL zu kopieren und (eventuell mit Änderungen) als neues Produkt anzubieten. Ein derartiges Unternehmen gälte als Marktneuzugänger. Es sind bereits mehrere Ableger von MySQL entstanden, z. B. MariaDB, Percona und Drizzle.
680.Die Mehrzahl der Kunden, die im Rahmen eines Auskunftsersuchens in der Marktuntersuchung in der ersten Phase antworteten, vertrat die Auffassung, dass durch den Open-Source-Charakter von MySQL nicht mit Wettbewerbsverzerrungen zu rechnen ist. Die Mehrheit der Kunden traute Angeboten wie Maria DB zu, sich als starker Wettbewerber auf dem Datenbankmarkt zu etablieren.
681.Um einen erheblichen Wettbewerbsdruck auf die etablierten Marktteilnehmer ausüben zu können (einschließlich anderer Open-Source-Datenbanken), muss ein Marktneuzugänger auf der Grundlage eines MySQL-Ablegers verschiedene Hürden in wirtschaftlicher, technischer und urheberrechtlicher Sicht überwinden. Diese Hürden und deren jeweilige Bedeutung werden in den folgenden Unterabschnitten analysiert.
4.4.3.1Wirtschaftliche Hürden
682.Ein Forker von MySQL, d. h. ein Unternehmen, das den unter der GPL verfügbaren Quellcode von MySQL kopiert, kann ein Produkt auf dieser technischen Basis freigeben. Jedoch erlangt ein solches Unternehmen dadurch, dass es lediglich eine (anders benannte) Kopie einer bestehenden Datenbank zum Herunterladen auf einer Website zur Verfügung stellt, nicht automatisch über Nacht eine internationale Marktpräsenz und einen Wettbewerbsdruck, der mit der aktuellen Situation von MySQL vergleichbar ist.
683.Das 1995 gegründete Unternehmen MySQL AB war bis zur Übernahme durch Sun im Februar 2008 auf fast 400 Beschäftigte angewachsen. Ein Unternehmen, das eine vergleichbare Wettbewerbskraft auf dem Datenbankmarkt werden möchte, müsste parallel einen eigenen Markennamen und Technologie entwickeln, sodass es von den Marktteilnehmern und zukünftigen Kunden anerkannt wird.
684.Hierzu müsste ein solches Unternehmen in der Lage sein, den Ableger mit eigenen technischen Kenntnissen zu entwickeln (da es nicht einfach davon ausgehen kann, dass nach dem Zusammenschluss Patches und Updates von Oracle an sie weitergereicht werden), um als eigenständiges Produkt anerkannt zu werden. Es muss eine globale Vertriebs- und Unterstützungsorganisation aufbauen, da insbesondere die erweiterte Nutzung von Datenbanken, ein Gebiet, in das MySQL einzudringen begonnen hat, intensive und umfangreiche Unterstützung – potenziell weltweit und rund um die Uhr – erfordert. In der Tat würden viele Kunden ein Datenbankprodukt, für das keine Unterstützung dieser Art verfügbar wäre, erst gar nicht in Betracht ziehen.
685.Es scheint keine „Abkürzung“ für Marktneuzugänge zu geben, d. h. keinen Weg, um sich als Wettbewerbskraft zu etablieren, ohne auf dem Markt einige Jahre präsent und erfolgreich zu sein. Neuzugänge auf dem Datenbankmarkt können nur organisch wachsen, da die Kunden die Fähigkeiten eines Anbieters bewerten können möchten, bevor sie signifikante Ressourcen in eine Geschäftsbeziehung einfließen lassen. Daher ist der Datenbankmarkt durch viele langjährige Beziehungen zwischen Anbietern und Kunden gekennzeichnet, da viele Datenbankinstallationen seit mehreren Jahren in Benutzung sind und Kunden während der gesamten Nutzungsdauer dieser Datenbanken Unterstützung benötigen. Infolgedessen achten die Kunden bei potenziellen neuen Lieferanten auf finanzielle Stabilität und bisherige Erfahrungen als wichtige Voraussetzung für das Eingehen einer wichtigen Geschäftsbeziehung.
686.Datenbankanbieter benötigen somit Referenzen, die von zufriedenen Kunden zur Verfügung gestellt werden, sowie eine Erfolgsbilanz als Nachweis für ein wachsendes und finanziell stabiles Geschäft, um erfolgreich neue Kunden, insbesondere Kunden mit umfassenden und speziellen Unterstützungsanforderungen, zu akquirieren. Diese Notwendigkeit nimmt mit der Wichtigkeit und missionskritischen Bedeutung der fortgesetzten Verfügbarkeit und Funktion des betreffenden Datenbankprodukts aus Sicht des Kunden zu. Selbst erfolgreiche Unternehmen benötigen Zeit zum Aufbauen einer Erfolgsbilanz sowie zum Sammeln von Referenzen und die Bedeutung eines Datenbankanbieters im Wettbewerb kann nicht einfach proportional durch die Einstellung mehrerer Ingenieure (oder Vertriebskräfte) auf einmal erhöht werden.
687.Wie die Anmelderin betont, existieren bereits verschiedene Ableger von MySQL. Die Unternehmen oder Entwicklungsteams, die diese Ableger herstellen und pflegen, sind gegenwärtig sehr klein: Laut Homepage beschäftigt Percona (das XtraDB, einen Ableger von InnoDB, freigegeben hat) maximal sieben Entwickler; Monty Program AB (das MariaDB, einen Ableger von MySQL, hergestellt) hat „gegenwärtig 15 Mitarbeiter, von denen mehr als die Hälfte vollzeitbeschäftigte Entwickler sind“; Drizzle, ein anderer Ableger von MySQL, begann im April 2008 und ist ein Hobbyprojekt, das von einem Sun Ingenieur geleitet wird, wohingegen OurDelta.org lediglich Quellcode-Builds, aggregiert aus verschiedenen Quellen, ohne eigene Entwicklung oder Kommerzialisierung zur Verfügung stellt.
688.Gegenwärtig sind sämtliche Unternehmen und Projekte von technischem Input in Form von MySQL-Software-Patches und -Updates aus dem vorgelagerten Bereich abhängig. Angesichts der öffentlichen Zusagen von Oracle, MySQL im Rahmen der GPL weiter zu verbessern, ist davon auszugehen, dass dieser Input so lange fortgesetzt wird, wie die Zusagen von Oracle Bestand haben. Erweiterungen des MySQL-Codes, die Oracle nicht zur Verfügung stellt, müssten von den Ableger-Anbietern selbst entwickelt werden.
689.Diese Notwendigkeit gilt jedoch völlig unabhängig von einem möglichen Zusammenschluss. Die Tatsache, dass es mehrere MySQL-Ableger gibt, ist sogar unter anderem darin begründet, dass die jeweiligen Entwickler nicht vollkommen mit der Reihenfolge und Geschwindigkeit, in der Sun die MySQL-Codebasis um neue Funktionen ergänzte, zufrieden waren. Darüber hinaus verfolgen die Anbieter der unterschiedlichen Ableger unter Umständen jeweils ganz konkrete und spezifische Verbesserungen der MySQL-Datenbank. Die Kooperation zwischen diesen Anbietern wäre daher eine Möglichkeit, eventuelle Unzulänglichkeiten des nach dem Zusammenschluss von Oracle unter der GPL bereitgestellten Codes auszugleichen.
690.Die Beweismittel in der Akte der Kommission lassen keine endgültige Schlussfolgerung bei der Frage zu, ob diese Ableger oder andere neue Ableger von MySQL in der Lage wären, die Beschränkungen, denen sie als Marktneuzugänge unterliegen, mit auf dem Markt praktisch noch völlig unbekannten Markennamen und Produkten schnell zu überwinden.
691.Das Beispiel von EnterpriseDB ist in dieser Hinsicht jedoch äußerst lehrreich. Das allgemeine Datenbankangebot des 2004 gegründeten Unternehmens EnterpriseDB basiert auf einem Ableger eines bekannten Open-Source-Datenbankprodukts (PostgreSQL). Das Unternehmen erwirtschaftete 2008 einen Umsatzerlös von 12,5 Mio. US-Dollar. EnterpriseDB spielt zwar noch keine bedeutende Rolle in den Oracle-internen CRM- und HQ Apps-Daten (was darauf hindeutet, dass es zurzeit noch keinen bedeutenden Wettbewerbsdruck ausübt), aber das Unternehmen konnte IBM und kürzlich auch Red Hat als Geldgeber gewinnen, und das Produkt ist bei einigen Branchenanalytikern hoch angesehen.
692.Der Aufbau von Anerkennung, Loyalität und Reputation für ein Produkt und eine Marke auf einem Softwaremarkt wie dem Datenbankmarkt, beides für die Aussichten eines Marktneuzugangs von Bedeutung, erfordert mehr als nur ein Produkt, das die verschiedensten technischen Anforderungen erfüllt. Der Erfolg des Produkts hängt auch davon ab, ob der Marktneuzugang in der Lage ist, die verschiedenen Netzwerkeffekte, die bei Softwareprodukten in der Regel auftreten, zu erzeugen und davon zu profitieren.
693.Ein Netzwerkeffekt ist vorhanden, wenn sich durch die zunehmende Verwendung eines Softwareprodukts der Produktwert für jeden erhöht, d. h. sowohl für seine gegenwärtigen als auch für seine potenziellen Nutzer, was zu weiterer Nutzung führt. Ein Softwareprodukt wie beispielsweise ein RDBMS wird von Entwicklern, Systemintegratoren, Softwareanbietern und Endnutzern verwendet. All diese Gruppen sind von Netzwerkeffekten in dem Sinne betroffen, dass die Größe jeder Gruppe Einfluss auf die Größe der anderen Gruppen und schließlich auf die Nutzung der RDBMS hat.
694.Je mehr Endnutzer beispielsweise ein Softwareprodukt einsetzen, desto interessanter wird es, Expertenwissen über dieses Produkt zu besitzen, da es die beruflichen Chancen erhöht. Die Verfügbarkeit ausgebildeter Fachkräfte, die mit dem Produkt vertraut sind, wirkt sich positiv auf die Anzahl der Endnutzer aus, da potenzielle Endnutzer eher geneigt sind, in ein Produkt zu investieren, wenn sie sicher sein können, dass ausreichendes Know-how verfügbar ist. Eine verbesserte Übernahme durch die Endnutzer und mehr Know-how führen zu einem stärkeren Anreiz und verbesserten Möglichkeiten für die Systemintegratoren und Softwareanbieter, das Datenbankprodukt in ihre eigenen Produkte zu integrieren und einzubetten, da ihre Kunden vermehrt danach fragen und die Einbindung schätzen.
430Gartner, Open-Source DBMS 2009; Gaining in Maturity and Use [Open-Source-DBMS 2009; Zunehmende Reife und Benutzung], S. 3 (doc_ID 2276).
431.In Anhang 3, Randnummer 35 der Erwiderung auf die Mitteilung der Beschwerdepunkte betrachtet Prof. Moglen dies (d. h. die Notwendigkeit, einen neuen Namen für einen Fork zu etablieren, da es sich beim ursprünglichen Namen um eine geschützte Marke handelt) offensichtlich nicht als schwerwiegendes Problem. Die von ihm aufgeführten Beispiele (GAIM/Pidgin und Phoenix/Firebird/Firefox/Iceweasel) sind mit dem Fall von MySQL jedoch nicht direkt vergleichbar. Es stimmt zwar vielleicht, dass das Markenrecht ein stumpfes Schwert bei der Beschränkung der Entwicklung von Gemeingut ist, aber bei einer Bewertung der Wettbewerbsfähigkeit geht es weniger darum, ob allgemein verfügbare Software entwickelt werden kann, als um die Frage, ob das Produkt einen Wettbewerbsdruck auf andere Anbieter auf dem Markt ausüben kann.
432.Zu „Markentreue“ siehe Entscheidung der Kommission 98/327/EG in der Sache IV/M.833 – The Coca-Cola Company/Carlsberg A/S (ABl. L 145 vom 15. Juni 1998, S. 41, Erwägungsgründe 72 und 73; zu Unternehmensreputation siehe Entscheidung der Kommission 2002/156/EG in der Sache SCA/Metsä Tissue (ABl. L 57 vom 27. Februar 2002, S. 1, Erwägungsgründe 83 und 84).
433.Ein klassisches Beispiel eines Netzwerkeffekts ist das Telefonnetz: Der Wert, den ein Telefon einem potenziellen neuen Telefonnutzer bietet, wächst mit der Zahl der installierten Telefone, d. h. jeder neue Telefonnutzer erhöht die Wahrscheinlichkeit, dass aktuelle Nichtnutzer ebenfalls die Technologie übernehmen.
695.Wie aus dieser Beschreibung hervorgeht, verstärkt sich der Prozess selbst und es entsteht im Laufe der Zeit ein „Ökosystem“ für die Technologie bestehend aus den verschiedenen Arten von Nutzern sowie abgeleiteten und komplementären Produkten.
696.Die verschiedenen Datenbankprodukte, die miteinander konkurrieren, sind alle mit solchen Netzwerkeffekten verbunden. Deren Ökosysteme überlappen sich, sodass Nutzer, Integratoren und Entwickler verschiedene RDBMS verwenden können. Jedoch ist die Kapazität (und der Bedarf) jedes einzelnen Endnutzers, Entwicklers und Systemintegrators begrenzt und die Ökosysteme der konkurrierenden Datenbanken konkurrieren daher automatisch gegeneinander. Wenn das Ökosystem eines Produkts wächst, muss das System eines anderen Produkts kleiner werden, zumindest kurzfristig.
697.Dies impliziert, dass bei verschiedenen Ablegern von MySQL die Situation entstehen würde, dass sie (auch mit der von Oracle nach dem Zusammenschlussvorhaben angebotene Version von MySQL) um dieselben raren Ressourcen konkurrieren. Beispielsweise konzentriert sich ein Hauptdatenbankentwickler möglicherweise lieber auf einen einzigen Ableger, als seine Zeit auf verschiedene Codebasen aufteilen zu müssen. Jeder Endnutzer kann bei einer spezifischen Anwendung nur einen Ableger verwenden, selbst wenn mehrere Ableger zur Auswahl stehen. Gleiches gilt für Systemintegratoren und Softwareanbieter. Eine derartige Fragmentierung könnte nur verhindert werden, wenn sich alle beteiligten Parteien darauf einigen würden, gemeinsam an nur einem Ableger zu arbeiten oder aus Kompatibilitätsgründen in allen Ablegern die gleichen APIs zu implementieren.
698.Es gibt bereits eine gewisse Zusammenarbeit unter den MySQL-Forkern. Dies deutet darauf hin, dass die jeweiligen Netzwerkeffekte der verschiedenen Ableger von MySQL zu einem erheblichen Grad auch in den anderen Ablegern zur Verfügung stehen. Darüber hinaus bedeutet die öffentliche Zusage von Oracle, mindestens fünf Jahre lang MySQL im Rahmen der GPL weiterzuentwickeln, dass die Einheitlichkeit eines allgemeinen MySQL-Ökosystems, in dem Entwickler und Nutzer von MySQL selbst und den verschiedenen proprietären und als Open-Source-Software angebotenen Ablegern und Add-Ons erhalten bleibt.
699.Die vorstehenden Argumente sind nicht von der Art des Unternehmens abhängig, das MySQL-Ableger entwickelt. Sie gelten daher in gleicher Weise für aktuelle Nutzer von MySQL, die die Anmelderin als potenzielle Forker identifiziert hat. Großunternehmen würden solch einen Versuch nur dann wagen, wenn sie dies als profitablen Weg ansehen, und auch sie würden Zeit benötigen, um Glaubwürdigkeit und Reputation unter den anvisierten Kunden aufzubauen.
700.Es trifft jedoch zu, dass eine anders lautende unternehmenspolitische Entscheidung bei Oracle im Hinblick auf den MySQL-Kauf die Wettbewerbsaussichten eines MySQL-Ablegers eines etablierten Softwareunternehmens erheblich verbessern würde. Nach dieser Logik steigt die Wahrscheinlichkeit, dass Oracle keine Schritte unternimmt, die sich negativ auf MySQL auswirken, oder dass das Ökosystem der MySQL-Ableger durch einen starken Neuzugang gestärkt wird.
701.Insgesamt gesehen kann nicht geleugnet werden, dass ein MySQL-Forker ein Unternehmen auf einer Grundlage aufbauen müsste, die aus nichts mehr als einem allgemeinen und nicht differenzierten Produkt besteht. Das Produkt ist zwar gewiss wichtig, aber der Geschäftserfolg hängt letztlich auch von anderen geschäftlichen Aspekten ab, beispielsweise einer ausreichenden Finanzausstattung, dem richtigen Marketing und Kundendienst usw.
4.4.3.2Technische Hürden
702.Das Forken einer Softwareentwicklung bedeutet, dass der betreffende Quellcode zu einem bestimmten Zeitpunkt kopiert und das Produkt anschließend unabhängig von der Weiterentwicklung der Quelle, von der der Quellcode kopiert wurde, entwickelt wird.
703.Das Starten eines Ablegers ist technisch gesehen unproblematisch. Der Quellcode von MySQL ist unter der GPL von Sun sowie von anderen Quellen im Internet zum Download verfügbar. Jedoch verwandelt sich das reine Kopieren des Softwarecodes nicht in ein erfolgreiches Geschäft und schon gar nicht in Geschäft, das einen Wettbewerbsdruck auf einen weltweiten Marktführer wie Oracle ausüben kann.
704.Es gibt kleine Unternehmen, die Beratung und Unterstützungsleistungen für Datenbanksoftware, einschließlich MySQL, anbieten. Es kann davon ausgegangen werden, dass solche Dienstleistungen auch Installationsunterstützung enthalten, wenn dies von Kunden gewünscht wird. Ein Unternehmen, das sich selbst darauf beschränkt, Nutzern bei der Verwendung des Produkts eines Datenbankanbieters zu helfen, kann nicht als Wettbewerbsdruck auf den Datenbankanbieter selbst angesehen werden, selbst wenn es MySQL in manchen Fällen technisch betrachtet durch Kopieren des Quellcodes „geforkt“ haben mag.
705.Unternehmen, die im Datenbankgeschäft als Wettbewerber gegenüber etablierten Anbietern rentabel sein möchten, müssten Mitarbeiter mit umfangreichen Fachkenntnissen in der Datenbanktechnologie insbesondere und im kommerziellen Softwaregeschäft im Allgemeinen haben. Beispielsweise müsste ein neues Unternehmen Binärversionen seines Produkts für alle wichtigen Computerplattformen, die bei den potenziellen Kunden in Benutzung sind, entwickeln und bereitstellen.
434.Eine Analogie aus der Welt der nicht digitalen Waren kann vielleicht helfen, die Hemmnisse, mit denen ein Forker konfrontiert ist, zusammenzufassen: Es gibt zahlreiche physikalische Produkte, die nicht (mehr) durch Patente oder andere geistige Eigentumsrechte abgedeckt sind, durch die Dritte daran gehindert werden, in die Fertigung solcher Produkte einzusteigen (beispielsweise Möbel aus Holz). Jedoch würde niemand behaupten, dass auf allen Märkten, auf denen solche physikalischen Produkte konkurrieren, ein im Wesentlichen perfekter Wettbewerb herrscht, da dabei die Bedeutung außer Acht gelassen wird, die der Sicherstellung von Lieferanten und Input, dem Aufbau einer Reputation, dem Sammeln von Erfahrungen und Fachkenntnissen sowie allem anderen, was zum Aufbau eines erfolgreichen Geschäfts erforderlich ist, zukommt. Nicht alle Unternehmen, die dies versuchen, haben Erfolg.
435.Im Open-Source-Bereich und insbesondere im Hinblick auf MySQL gibt es auch eine andere Art von Fork, der nicht unbedingt auf eine unabhängige Entwicklung abzielt, sondern angepasste Versionen der Codebasis, die vom ursprünglichen Projekteigentümer bereitgestellt wurde, zur Verfügung stellt. Beispielsweise bietet ourdelta.org MySQL-Quellcode mit verschiedenen Patches und Ergänzungen von Dritten, die von MySQL/Sun nicht in den offiziellen Quellbaum von MySQL aufgenommen wurden.
436.Diese Anforderung ist alles andere als trivial. Monty Program verweist in den Anmerkungen von Monty Program AB zur Mitteilung der Beschwerdepunkte darauf, dass „die Entwicklung funktionaler und qualitativ hochwertiger Versionen eines Forks eine Kunst für sich ist, die praktisch Sun Microsystems vorbehalten ist“, dass die eigenen Anstrengungen bislang nur zu Beta-Versionen geführt haben und dass zur Einrichtung einer technischen Infrastruktur für den Fork-Support „Millionen Euro benötigt werden“.
706.Würde ein solches Unternehmen nur auf Änderungen/Ergänzungen/Korrekturen an seinem Produkt, die aus dem vorgelagerten Bereich, d. h. vom ursprünglichen Anbieter oder einem anderen Forker, stammen, setzen und diese dann integrieren, könnte es wohl maximal als Weiterverteiler des Produkts des ursprünglichen Anbieters betrachtet werden, jedoch eindeutig nicht als Wettbewerber auf dem betreffenden Markt.
707.Es gibt jedoch unter Umständen einen vielversprechenden Nischenmarkt für Forker, die auf Code aus dem vorgelagerten Bereich (das in einem gewissen Maße von Oracle bereitgestellt würde, da das Unternehmen öffentlich angekündigt hat, Verbesserungen von MySQL noch mindestens fünf Jahre lang kostenlos unter der GPL zur Verfügung zu stellen) zurückgreifen, aber ihre eigenen Entwicklungsanstrengungen auf spezielle MySQL-Funktionen konzentrieren. Durch die Gültigkeitsfrist der öffentlichen Zusagen von Oracle könnte ein solcher Anbieter von Ablegern entsprechende Geschäftsmodelle ausreichend analysieren und etablieren, so dass er eine Marktposition erlangen könnte, die auch nach Ablauf der öffentlichen Zusagen eine solide Geschäftsgrundlage darstellt.
708.Ein Forker, der auf dem Datenbankmarkt lukrativ konkurrieren möchte, muss selbst auch die Fähigkeit besitzen, den Quellcode der Software zu pflegen, d. h. er muss ein Fehlermeldesystem für seine Kunden sowie technisches Know-how für die Behandlung und Korrektur von Fehlern bereitstellen. Selbst auf kurze Sicht muss er ferner in der Lage sein, das Produkt weiterzuentwickeln und es an neu auftretende Anforderungen und technische Innovationen, die in der Branche verzeichnet werden, anzupassen.
709.Dies liegt daran, dass das Produkt ohne eine solche Weiterentwicklung und Innovation bald veraltet sein wird und die Kunden es dann nicht mehr als mögliche Option für neue oder fortgesetzte Nutzungen betrachten. Diese Anforderung führt zu einem noch größeren Finanzbedarf bei dem Versuch der Anbieter von Ablegern, sich auf dem Datenbankmarkt zu etablieren. Wie jedoch die Drittanbieter von Speicher-Engines gezeigt haben, ist Risikokapital eingebettet in einen GPL-Kontext problemlos verfügbar, wenn ein überzeugendes Geschäftsmodell zugrunde liegt.
710.Die Anmelderin bringt außerdem vor, dass es bei anderen Marktakteuren, nämlich MySQL-Großnutzern wie Google oder Facebook, Anreize zur Übernahme von Verantwortung für kontinuierliche Investitionen in die Entwicklung von MySQL gibt – insbesondere, wenn Oracle selbst weniger Entwicklungsarbeit leisten würde als erwartet. Die Anmelderin argumentiert ferner, dass solche Großnutzer von MySQL bereits all diese notwendigen Fachkenntnisse besitzen und daher als Neulinge in das Datenbankgeschäft basierend auf einem Ableger von MySQL einsteigen könnten – auch wenn Google bereits zu verstehen gegeben hat, dass es auf dem Markt für Datenbanken nicht aktiv ist. Jedoch hat Google MySQL für unternehmensinterne Zwecke technisch geforkt und weiterentwickelt und seine Ergänzungen MySQL und Dritten zur Verfügung gestellt. In seinen Antworten auf die Auskunftsersuchen sowie in einem anschließenden Telefongespräch hat Google keinerlei Absicht, derzeit in den Datenbankmarkt einzutreten, bestätigt. Jedoch kann sicherlich die Möglichkeit nicht ausgeschlossen werden, dass Google in diesem Punkt seine Meinung ändert, insbesondere wenn Oracle bezüglich MySQL eine Entscheidung treffen würde, die auf Teilen des Marktes zu einer Unterversorgung führen würde.
437Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), Abschnitt V.B.4. (doc_ID 2427).
438Siehe Protokoll der Telefonkonferenz mit dem für die vorliegende Sache zuständigen Team, S. 1 (doc_ID 2869).
711.Schließlich ist zu beachten, dass für viele Kunden die erste Frage die Anwendungen betrifft, die sie ausführen möchten, und nicht die Datenbank, auf der sie diese Anwendungen ausführen möchten. Die Wahl der Datenbank ist daher in erheblichem Maß von den gewählten Anwendungen abhängig. Einige kleinere Anbieter von Unternehmensanwendungen haben begonnen, ihre Produkte zur Verwendung mit MySQL zu zertifizieren. Dies gilt jedoch nicht für die großen Anwendungsanbieter wie Oracle und SAP (allerdings verfolgte SAP von 2003 bis 2007 mit recht großem Aufwand ein Projekt zur MySQL-Zertifizierung). Eine ähnliche Zertifizierung würde de facto automatisch jedem MySQL-Ableger gewährt, der die Kompatibilität hinsichtlich der Hauptdatenbankfunktionen wahrt (beispielsweise im Hinblick auf die SQL-Syntax für Datenbankabfragen).
712.Anwendungsanbieter zögern eventuell oder sind sogar nicht in der Lage, verschiedene „Richtungen“ von MySQL gleichzeitig zu zertifizieren, und bleiben angesichts dessen möglicherweise bei der „offiziellen“ Version, selbst wenn diese von Oracle bereitgestellt und nicht mehr aktiv weiterentwickelt wird. Dennoch können sich Nutzer dieser Anwendungen darauf verlassen, dass sie einen kompatiblen Ableger von MySQL nutzen. Nach gleicher Argumentation empfiehlt es sich für die Anbieter von Ablegern, maximale Kompatibilität zwischen der „offiziellen“ Version von MySQL und verschiedenen Ableger herzustellen und damit auch zum allgemeinen MySQL-Ökosystem beizutragen.
713.Insgesamt kann gefolgert werden, dass MySQL-Ableger beim Einstieg in den Datenbankmarkt vor sehr ähnlichen technischen Hürden stehen wie andere Unternehmen, die sich auf diesem Markt etablieren möchten. Allerdings darf nicht vergessen werden, dass ein Ableger seine Geschäftstätigkeit auf dem Quellcode eines vollständigen Produkts aufbauen kann. Schließlich wären für die Entwicklung einer vergleichbaren Software erhebliche Investitionen erforderlich.
Darüber hinaus gäbe es für Drittanbieter einen Anreiz, auf dem Datenbankmarkt aktiv zu werden und einen MySQL-Ableger anzubieten – insbesondere, wenn die Nutzer beim MySQL-Angebot von Oracle bestimmte Funktionen, einen guten Support oder ein besseres Preis-Leistungs-Verhältnis vermissen würden. Dies wäre eventuell als Ergänzung zu vorhandenen Ablegern oder zusätzlich zu den Anbietern, die bereits im MySQL-Ökosystem etabliert sind (beispielsweise Anbieter von Speicher-Engines), möglich. Die öffentlichen Zusagen von Oracle ermöglichen es potenziellen Forkern, neue Produkte auf den Markt zu bringen, da die GPL-Codebasis einschließlich der Updates und Patches aus dem vorgelagerten Bereich noch einige Jahre von Oracle bereitgestellt wird.
4.4.3.3Urheberrechtliche Hürden
715.Die Anmelderin argumentiert mit Verweis auf Beispiele erfolgreicher Ableger, dass es keinen Grund gibt, warum ein MySQL-Ableger keinen Erfolg auf dem Markt für Datenbanken haben sollte. Das prominenteste Beispiel, das von ihr genannt wird, ist das Betriebssystem Linux.
716.Wenn jedoch in der Tat ein erfolgreicher Ableger des Linux-Kernels existieren sollte, ist dieser nicht erfolgreich, da in diesem Verfahren kein solcher Ableger konkret genannt wurde. Die Situation in Bezug auf Linux sieht so aus, dass viele verschiedene Unternehmen als Weiterverteiler von (unterschiedlichen) Versionen des Linux-Kernels zusammen mit sonstiger Software, die häufig ebenfalls unter der GPL verfügbar ist, tätig sind. Der Weitervertrieb als solches ohne Änderung des Quellcodes ist nicht das Gleiche wie Forking, u. a. weil keine speziellen technischen Fähigkeiten benötigt werden, wenn der Code nicht weiterentwickelt wird.
717.Red Hat ist beispielsweise im Grunde ein Dienstleister, der ein Produktpaket zusammen mit Unterstützung und Dienstleistungen sowie einer Schadloshaltung gegenüber Klagen wegen Verletzung geistiger Eigentumsrechte durch Dritte anbietet, das Unternehmen die Verwendung eines Open-Source-Produkts wie beispielsweise Linux vereinfacht. Es kommt für viele Unternehmen wegen des Fehlens solcher Eigenschaften nicht in Frage, die Übernahme von Open-Source-Software ernsthaft in Erwägung zu ziehen, wie die Marktuntersuchung bestätigt hat.
718.Ein weiteres Beispiel ist der Apache Webserver. Diese Open-Source-Software wird von der Apache Foundation, einem gemeinnützigen Unternehmen, unter einer freizügigen Open-Source-Lizenz angeboten, d. h. der Quellcode der Software steht Lizenznehmern wie bei der GPL zur Verfügung, jedoch sind die Lizenznehmer in der nachgelagerten Nutzung des Codes nicht so gebunden, wie dies bei der GPL der Fall ist.
719.Apache kann beispielsweise in ein kommerzielles Produkt, das unter einer proprietären Lizenz verfügbar gemacht wird, integriert werden. Zahlreiche Unternehmen nutzen den Apache Webserver und verknüpfen ihn mit ihren Produkten, darunter auch IBM und Oracle selbst. Da sie Einnahmen aus dieser Nutzung erzielen, liegt ihnen daran sicherzustellen, dass die Entwicklung dieses Produkts fortgesetzt wird. Aus diesem Grund bezahlt ein Unternehmen wie IBM einige Entwickler, die Vollzeit an Code arbeiten, der dann der Apache Foundation zur Verfügung gestellt wird und somit für jedermann zur kostenlosen nachgelagerten Nutzung verfügbar ist.
720.Jedoch sollte nicht außer acht gelassen werden, dass dieses Geschäftsmodell nur funktioniert, da der Apache Webserver im Rahmen einer freizügigen Open-Source-Lizenz verfügbar ist (es würde unter der GPL nicht funktionieren, da IBM und andere ihn nicht so in ihren proprietären Produkten verwenden könnten, wie sie dies heute tun): Die BSD-Lizenz gestattet jedem die duale oder rein proprietäre Lizenzierung, während durch die GPL alle Nutzer, außer dem ursprünglichen Urheberrechtsinhaber, auf eine reine GPL-Lizenzierung beschränkt werden.
721.Insgesamt scheint es demnach, dass es im Gegensatz zu den Angaben der Anmelderin nicht gerade häufig vorkommt, dass ein Ableger einer wichtigen Software, die unter der GPL verfügbar ist, mit dem Ziel, ein kommerziell erfolgreiches Produkt zu schaffen, gegen die Wünsche des Projekteigentümers (und Urheberrechtsinhabers) entwickelt wird. Es trifft zu, dass Prof. Moglen auf die GCC-
722.und EGCS-Compiler, auf GNU Emacs und Xemacs, die Content-Management-Systeme Mambo und Joomla sowie Samba und Samba-TNG verweist. Da jedoch keines der Ableger-Produkte (und auch keines der Forking-Produkte) aus dieser Beispielliste jemals so im kommerziellen Mittelpunkt stand wie MySQL, ist fraglich, in wieweit ein Ableger in diesem Fall dem ursprünglichen Produkt, den MySQL-Versionen von Oracle nach dem Zusammenschluss, Konkurrenz machen könnte.
723.Ein Bericht von The 451 Group, der von der Anmelderin eingereicht wurde, zeigt, dass Open-Source-Unternehmen sehr unterschiedliche Geschäftsmodelle verfolgen. Die Auswirkungen der Stärken und Schwächen der verschiedenen Geschäftsmodelle auf Open-Source-Basis könnten je nach Eigenschaften der verschiedenen speziellen Softwaremärkte, die von den einzelnen Anbietern anvisiert werden, unterschiedlich ausfallen.
724.Leider wird in dem Bericht von The 451 Group nicht zwischen den verschiedenen Arten von Open-Source-Produkten, die von den Unternehmen, die auf die zugrunde liegende Umfrage geantwortet haben, in Verkehr gebracht werden, unterschieden. Diese Informationen wären von Interesse gewesen, da der Datenbankmarkt im Vergleich zu anderen Softwaremärkten einige spezielle Eigenschaften aufweist, die die Möglichkeit der Anwendung einer dualen Lizenzierung (d. h. Code wird unter proprietären Lizenzen und unter Open-Source-Lizenzen angeboten) wichtiger erscheinen lassen als auf anderen Märkten.
725.Die Marktuntersuchung hat in beiden Phasen ergeben, dass zahlreiche Akteure auf dem Datenbankmarkt die Unfähigkeit, eine duale Lizenzierung anzuwenden, als gravierendes Hemmnis für einen MySQL-Ableger betrachten würden. Diese Unfähigkeit würde im Wesentlichen verhindern, dass der Ableger auf dem Markt für eingebettete Datenbanken eine Rolle spielt, da die Kunden fast immer eine Nicht-GPLv2-Lizenz wünschen. Dieser Sektor hat in den vergangenen Jahren einen erheblichen Anteil der Einnahmen bei MySQL ausgemacht. Diese Einnahmen ermöglichen wiederum Investitionen in die Weiterentwicklung der Produkte.
Darüber hinaus lässt sich das „klassische“ Open-Source-Geschäftsmodell, das ausschließlich auf GPL basiert, nicht so einfach auf verschiedene andere Bereiche übertragen: Sowohl im High-End-Data-Warehousing-Bereich als auch im Hochzuverlässigkeits-Segment (in dem Oracle RAC anbietet) ist die Anzahl der potenziellen Kunden sehr begrenzt und umfasst im Wesentlichen Großunternehmen. Um in diesem Bereich rentabel zu sein, müssen Anbieter in der Lage sein, hochklassige Unterstützung, die rund um die Uhr und potenziell weltweit verfügbar ist, bereitzustellen. Selbst die Entwicklung von Produkten für diesen Bereich kann sehr kostspielig sein, da diese aufgrund ihrer Besonderheiten nicht von der allgemeinen
444Anhang 3, Randnummer 43 der Erwiderung auf die Mitteilung der Beschwerdepunkte.
445Anhang 9 zu Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), The 451 Group, Open Source is Not a Business Model [Open Source ist kein Geschäftsmodell] (doc_ID 2436).
Die Anmelderin verweist darauf, dass MySQL in Bezug auf die Einnahmen im Segment für integrierte Datenbanken nur über einen sehr kleinen Marktanteil verfügt und dass dieser Markt stark umkämpft ist (Erwiderung auf die Mitteilung der Beschwerdepunkte, Randnummer 343). Das Argument im Haupttext hängt jedoch nicht von der speziellen Struktur des Segments, sondern eher von der Tatsache ab, dass ein auf zwei Arten lizenziertes Datenbankprodukt Zugang zu diesem Segment und somit zumindest das Potenzial hat, Einnahmen aus diesem Umstand zu generieren. Bei einem Datenbankprodukt, das nur unter GPL vertrieben wird, ist dies nicht der Fall.
Open-Source-Community bereitgestellt werden. Daher ist bei der Finanzierung der anfänglichen Entwicklungen häufig Risikokapital von Nöten. Aus diesen Gründen weisen die in diesem Bereich tätigen Anbieter darauf hin, dass ein reines Open-Source-Geschäftsmodell aufgrund mangelnder Finanzierungsmöglichkeiten wahrscheinlich
447nicht rentabel wäre.
726Die Anmelderin argumentiert dennoch, es könne nicht davon ausgegangen werden, dass die Beschränkung eines MySQL-Forkers auf einen einheitlichen Lizenzierungsansatz basierend auf der GPL Version 2 die Wahrscheinlichkeit verringern würde, dass ein solcher Forker ein Produkt auf der Grundlage der GPL-Version von MySQL auf den Markt bringt, das ähnlich attraktiv ist wie die ursprüngliche MySQL-Version. Darüber hinaus betont die Anmelderin, dass viele erfolgreiche Open-Source-Unternehmen, einschließlich MySQL, die GPL Version 2 nutzen.
727Als Urheberrechtsinhaber kann Sun/MySQL sein Produkt jedoch auch unter einer anderen Lizenz zur Verfügung stellen. Dies wird als duale oder Multi-Lizenzierung bezeichnet. Sie empfiehlt sich, um die Anforderungen der Kunden besser zu erfüllen und/oder die Investitionen und Innovationen des Urheberrechtsinhabers bezogen auf sein Produkt besser zu schützen. Ein Marktneuzugänger auf der Grundlage eines Ablegers des MySQL-Codes könnte schlicht und ergreifend kein auf der dualen Lizenzierung basierendes Geschäftsmodell verwenden. Die in der Akte zur vorliegenden Sache enthaltenen Informationen belegen, dass der Anreiz und die Fähigkeit eines solchen Marktneuzugängers, sein Produkt hinreichend weiterzuentwickeln und dadurch mit Oracle (und anderen Datenbankanbietern) in den Wettbewerb zu treten und aus Wettbewerbssicht an die Stelle von MySQL zu treten, durch diese Beschränkung erheblich verringert werden könnten.
447Siehe Antworten von Calpont und ScaleDB auf das an Anbieter von Speicher-Engines und Datenbankwettbewerber gerichtete Auskunftsersuchen.
448Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), Abschnitt V.B.2. (doc_ID 2427), und Randnummer 342 der Erwiderung auf die Mitteilung der Beschwerdepunkte. In seinen internen Dokumenten scheint Oracle die Bedeutung der dualen Lizenzierung als Geschäftsmodell sehr wohl zu schätzen und sich bewusst zu sein, dass Forkern ein signifikanter Teil der Kunden vorenthalten wird, indem es angibt, dass […]* (doc_ID 2917).
449Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), 2. Oktober 2009 (doc_ID 2427).
450Dies ist ein wesentlicher Unterschied zwischen dem ursprünglichen Urheberrechtsinhaber und einem GPL-Lizenznehmer. Diese Situation darf nicht, wie dies von den beteiligten Unternehmen getan wird, mit einer Situation verglichen werden, in der die betreffende Technologie, die von einem Unternehmen benutzt wird, vollständig verfügbar ist, sodass gegenwärtige oder zukünftige Wettbewerber „problemlos auf die Technologie zugreifen können“ [„ha[ve] easy access to the technology“], da die Bewertung in der Sache COMP/M.4091 Linde/Spectra, die von den beteiligten Unternehmen erwähnt wird, völlig anders hätte ausfallen können, wenn der vollständige Zugang zu dieser Technologie von der Lizenzerteilung durch die Zustimmung der fusionierenden Unternehmen in der Sache Linde/Spectra abhängig gewesen wäre, Oracle, „Observations on the Commission's Theory of Harm“ (Feststellungen zur Schadenstheorie der Kommission), S. 46 (doc_ID 2427).
451In Anhang 3 der Erwiderung auf die Mitteilung der Beschwerdepunkte versucht Prof. Moglen zu argumentieren, dass MySQL bislang besser mit einem allein auf GPLs basierenden Geschäftsmodell gefahren wäre und dass dies auch nach dem Zusammenschluss mit Oracle der Fall wäre. Angesichts des erheblichen kommerziellen Erfolgs von MySQL durch die duale Lizenzierung, der – vielleicht mit Ausnahme des Linux-Kernels – wenigen anderen Open-Source-Produkten geglückt ist, bieten Prof. Moglens heuristische und theoretische Argumente weder einen überzeugenden Beleg dafür, dass ein Fork von MySQL erfolgreich wäre, noch widerlegen sie das Argument, dass die duale Lizenzierung tatsächlich eines der Fundamente für den großen Erfolg von MySQL darstellt.
728Die Anbieterin argumentiert darüber hinaus, dass es zwar zutrifft, dass […]* % der Einnahmen von MySQL gegenwärtig mit proprietären Lizenzen und Abonnements erzielt werden, aber dass es dennoch wichtig wäre, den Betrag der Einnahmen zu betrachten, „bei dem eine andere Lizenz als eine GPL erforderlich ist“ [„that require[s] a non-GPL license“], da „lediglich Lizenzen für eingebettete Produkte von Sun nicht im Wettbewerb mit einem Anbieter von Ablegern stehen können“ [„[o]nly Sun's embedded MySQL license bookings are immune from challenge by a fork vendor“].
729Jedoch fragen viele Datenbankkunden selbst in Situationen, in denen die Verwendung von Software unter der GPL rechtmäßig möglich wäre, ohne irgendwelche unerwünschten Wirkungen auszulösen, nach Nicht-GPL-Lizenzen, wie sich bei der Marktuntersuchung herausgestellt hat. Die Datenbankanbieter sind sich ihrerseits dessen bewusst und wissen daher, dass sie in der Lage sein müssen, solche Nicht-GPL-Lizenzen solchen Kunden (ebenfalls) anzubieten, um dauerhaft wettbewerbsfähig zu bleiben.
730Die Anmelderin bringt ferner folgendes Argument als Anzeichen dafür vor, dass eine geforkte Version von MySQL keinerlei Probleme bei der Erschließung einer kommerziellen Nutzerbasis hätte: Im Rahmen des gegenwärtigen Abonnementmodells von Sun für MySQL Enterprise entscheiden sich mehr als 99 % der Kunden dafür, die MySQL-Software unter der GPL zu erhalten. Die Anmelderin argumentiert, dass dies darauf hindeutet, dass ein Softwareprodukt, das ausschließlich auf der GPL aufgebaut ist, am Markt bestehen könne.
731Jedoch sieht das von Sun angebotene Abonnement für MySQL Enterprise auch die Schadloshaltung des Lizenznehmers gegenüber Klagen wegen Verletzung geistiger Eigentumsrechte durch Dritte vor, wenn eine von MySQL zertifizierte Binärversion von MySQL verwendet wird. Dies bedeutet, dass die Schadloshaltung, die von vielen kommerziellen Nutzern bei jeder Art von Software gefordert wird, um das Risiko einer Haftbarmachung für die Verletzung geistiger Eigentumsrechte zu verringern, nicht greift, falls der Lizenznehmer den Quellcode zu MySQL selbst kompiliert oder in irgendeiner Weise ändert. Nur Binärversionen, d. h. kompilierte Versionen von MySQL wie von Sun bereitgestellt, fallen unter die Schadloshaltung.
Im Hinblick auf alle praktischen Zwecke wird das Abonnement hierdurch einem proprietären Softwarelizenzvertrag sehr ähnlich, in dem normalerweise jegliche Schadloshaltung für den Fall, dass der Lizenznehmer in das vom Lizenzgeber gelieferte Softwareprodukt „eingreift“, ausgeschlossen wird. Ein MySQL-Ableger auf der Grundlage der GPL müsste die gleiche Schadloshaltung ermöglichen, wenn die Bedenken von Unternehmenskunden berücksichtigt werden sollen.
732Die Situation wird jedoch noch komplizierter, wenn ein MySQL-Ableger eines Drittanbieters und somit eine modifizierte MySQL-Version mit einer vergleichbaren Schadloshaltung angeboten wird. Diese Schadloshaltung müsste im Wesentlichen auch die Rechte der MySQL-Besitzer an ihrem geistigen Eigentum samt Patenten umfassen, da die Lizenznehmer des Forkers nicht für den gesamten vom Forker erhaltenen Code in direkter GPL-Beziehung zum MySQL-Besitzer stehen, sondern nur für den Code, der vom ursprünglichen Lizenzgeber stammt.
733Diese Problem würde bei der einfachen Weiterverteilung des MySQL-Codes unter der GPL, der von MySQL (oder dessen Eigentümer) selbst kopiert wurde, nicht auftreten. Nehmen wir beispielsweise an, dass der Eigentümer von MySQL ein Patent über einen Anspruch Z für ein Softwaremerkmal besitzt und MySQL dieses Softwaremerkmal implementiert und dann die Implementierung unter der GPL freigibt. In diesem Fall würde jeder Lizenznehmer, wie die Anmelderin wiederholt im Rahmen des Verfahrens argumentiert hat, im Wesentlichen zusammen mit der GPL eine unwiderrufliche Patentlizenz erhalten. Diese implizite Lizenz wäre jedoch auf die Nutzung beschränkt, die durch das Patent für den Code in seiner ursprünglichen Version im Rahmen der GPL abgedeckt ist. Wenn der Lizenznehmer diesen Code nun in irgendeiner Weise ändert, wodurch eine andere Nutzung oder Implementierung des Anspruchs Z hinzukommt, ist er für Patentverletzungen in Bezug auf den Code, den er dem ursprünglich unter der GPL erhaltenen Code hinzugefügt hat, haftbar.
734Lässt man die öffentliche Ankündigung von Oracle beiseite, könnte Oracle theoretisch entscheiden, MySQL überhaupt nicht unter der GPL zur Verfügung zu stellen (im Wesentlichen, indem verhindert wird, dass jemand den Code unter dieser Lizenz erhält). In einer solchen Situation müssten MySQL-Forker auch die Patente von Oracle (und hiervon dürfte Oracle im Datenbankbereich einige mehr haben als Sun) berücksichtigen. Dies könnte Oracle die Möglichkeit eröffnen, sämtliche Forker von MySQL zu verklagen.
Dies gilt gleichermaßen für sämtliche geistigen Eigentumsrechte Dritter. In der Tat trägt der ursprüngliche Entwickler einer Software, die unter der GPL freigegeben wird, offensichtlich die volle Verantwortung für das Softwareprodukt und unterliegt somit eventuell Klagen wegen der Verletzung geistiger Eigentumsrechte durch Dritte. In Anhang 3, Randnummer 37 der Erwiderung auf die Mitteilung der Beschwerdepunkte äußert Prof. Moglen aus Sicht des US-amerikanischen Patentsystems „Zweifel“ ["doubtful"] im Hinblick auf die Analyse des Haupttexts in Bezug auf das hypothetische Leistungsmerkmal Z. Davon abgesehen, dass er nicht einmal eine Einschätzung zum Patentsystem der Länder, für die die Europäische Kommission zuständig ist, abgibt, sollte auch darauf verwiesen werden dürfen, dass einer der größten Experten zum Thema GPL keine eindeutige Meinung hierzu äußert. Außerdem spricht Prof. Moglen nur von „einer genauen Kopie des durch Patente abgedeckten Codes, die von einem Teil einer Codebasis in einen anderen kopiert wurde“ ["a literal copy of the patent-covered code duplicated from one portion of the codebase to another"], wohingegen im Haupttext deutlich von „einer anderen Nutzung bzw. Implementierung“ ["another use or implementation"] des Leistungsmerkmals die Rede ist. Solange es bei diesem Problem keinen Präzedenzfall gibt – und Prof. Moglen führt keinen solchen Fall auf – kann nicht ausgeschlossen werden, dass betroffene Unternehmen potenzielle rechtliche Risiken vermeiden und weniger Möglichkeiten zum Forking nutzen.
Dieser Punkt wird von Prof. Moglen in Anhang 3, Randnummer 38 der Erwiderung auf die Mitteilung der Beschwerdepunkte bestritten: In Bezug auf Abschnitt 6 der GPL Version 2 „erhalten im Gegensatz zu den
735Dieses Problem kann vergleichsweise klein bleiben, solange der Ableger sich sehr stark an die Quelle anlehnt, aus der er entwickelt wurde (da dann das Material, das Gegenstand von Verletzungsklagen sein könnte, sehr begrenzt wäre), würde aber tendenziell zunehmen, wenn sich der Ableger im Laufe der Zeit immer weiter von seiner ursprünglichen Quelle entfernt.
736Die gleiche Begründung gilt für sämtliche Ableger von MySQL und verdeutlicht ein weiteres Ergebnis der Marktuntersuchung der ersten und zweiten Phase. Mehrere Befragte haben betont, dass die reine Drohung von Oracle, einen potenziellen zukünftigen Wettbewerber, wie beispielsweise einen Forker von MySQL, der sich in gewissem Umfang als erfolgreich erweisen könnte, oder einen Speicher-Engine-Anbieter, der die Kundennachfrage nach High-End-Leistung zu äußerst niedrigen Preisen in speziellen Segmenten, z. B. im Data Warehousing-Segment, erfüllt, rechtlich zu belangen, eine enorm abschreckende Wirkung hätte. Beispielsweise haben die beiden Speicher-Engine-Anbieter ScaleDB und Calpont bestätigt, dass Risikokapitalgeber, die die Bereitstellung von Finanzmitteln für sie in Erwägung zogen, nach der Ankündigung der Übernahme von Sun durch Oracle die Risiken in diesem
Schlussfolgerungen der Mitteilung der Beschwerdepunkte [Randnummer 766] alle Empfänger des Codes von jedem, unabhängig von der fortlaufenden Verfügbarkeit dieses Codes von Oracle, automatisch eine Urheberrechtslizenz vom Urheberrechtsinhaber“ [“[c]ontrary to the conclusion of the SO [paragraph 766], all recipients of the code from anyone, regardless of the continued availability of that code from Oracle, receive automatically a copyright license from the copyright holder”]. Dieser Abschnitt der GPL Version 2 besagt jedoch, dass „der Empfänger automatisch eine Lizenz vom ursprünglichen Lizenzgeber enthält“ [“the recipient automatically receives a license from the original licensor”], nicht jedoch von allen Unternehmen, die in Zukunft eventuell das Urheberrecht erwerben, aber den Code nicht selbst unter der GPL verteilen. Dies ist genau das im Haupttext erwähnte Szenario.
Wenn selbst bei einer reinen Kopie des Codes von MySQL eine Anschuldigung wegen Verletzung von Oracle-Patenten erhoben werden könnte, hätte Oracle diese Patente selbstverständlich bereits vor dem Zusammenschluss gegenüber MySQL geltend machen können. Jedoch ist dies zumindest nach der Übernahme von Sun möglicherweise keine gangbare Möglichkeit mehr, da Sun insgesamt ebenfalls ein umfangreiches Patentportfolio besitzt und Oracle eventuell kein Interesse daran hat, eine Runde gegenseitiger Patentverletzungsklagen einzuläuten. Große Patentportfolios gelten als Frieden sichernd zwischen den großen Akteuren in der Branche, und zwar durch glaubhafte Bedrohung der geistigen Eigentumsrechte entsprechend der „gegenseitig gesicherten Zerstörung“: „Nur weil die großen Unternehmen mit ihren Patenten bezogen aufeinander und die weltweiten Technologien wie das Internet niemals zu weit gehen, bedeutet dies nicht, dass kleinere Unternehmen oder Open-Source-Entwickler nicht angegriffen werden. Sie werden angegriffen. [...]* Schon die reine Drohung reicht aus, um ein Unternehmen davon abzuhalten, ein Programm zu entwickeln oder in Verkehr zu bringen, wenn es keinen Rechtsschutz oder nicht die notwendige Finanzausstattung besitzt, um einen Patentstreit vor Gericht auszufechten.“ [„[J]ust because the big companies may never go too far with their patents with each other and worldwide technologies such as the Internet doesn't mean that smaller companies or open-source developers wont be attacked. They will be. [...]* Just the mere threat is enough to stop a company from developing or marketing a program if it doesn't have the legal protection or deep pockets needed to fight a patent battle in the courts.“], http://www.eweek.com/c/a/Linux-and-Open-Source/Software-Patents-and-Mutually-Assured-Destruction/, gedruckt am 13. Oktober 2009 (doc_ID 2977).) Obwohl Sun und sogar MySQL in ihren letzten unabhängigen Jahren eventuell genügend Substanz gehabt hätten, um sich bei Patentstreitigkeiten nicht zu beugen, müsste dies außerdem nicht unbedingt für die gegenwärtigen (wie z. B. MariaDB) oder zukünftigen Forker von MySQL gelten.
460Zusammenhang als Begründung dafür angeführt haben, dass sie zu diesem Zeitpunkt von einer Investition absehen.
737Im Lichte der öffentlichen Ankündigungen von Oracle sollte den Szenarien in den vorangehenden drei Absätzen allerdings nicht zu viel Beachtung geschenkt werden. Falls Oracle die öffentliche Ankündigung, mindestens fünf Jahre lang einige Versionen von MySQL unter der GPL zur Verfügung zu stellen, nicht wahr machte, würde sich dies mit hoher Wahrscheinlichkeit negativ auf das Ansehen des Unternehmens auf zahlreichen Softwaremärkten auswirken.
738Ebenso sind Forker vielleicht in ihrer Möglichkeit eingeschränkt, bisherige MySQL-Entwickler, die Oracle verlassen, anzulocken. Selbst wenn Oracle weiterhin eine Version von MySQL unter der GPL anbieten würde, würde das Unternehmen sehr wahrscheinlich in mehreren Schritten dafür sorgen, dass diese von einer proprietären MySQL-Version hinsichtlich Kompatibilität und direkter Ersetzbarkeit abweicht. Dies wird in den öffentlichen Ankündigungen von Oracle nicht einmal implizit ausgeschlossen. Oracle könnte problemlos dafür sorgen, dass alle Entwickler den Quellcode der GPL- und der proprietären Version zu sehen bekommen, Letzteres vielleicht sogar nicht auf eine proprietäre Version von MySQL beschränkt, sondern möglicherweise auch auf den Quellcode der anderen proprietären Datenbanken von Oracle ausgeweitet.
739Es ist bekannt, dass durch diese Praxis die betreffenden Entwickler für zukünftige Open-Source-Arbeiten bei einem Forker von MySQL „diskreditiert“ wären. Dies liegt daran, dass ein Forker von MySQL, der auf die Nutzung der GPL für die zukünftige Entwicklung von MySQL beschränkt ist, nicht riskieren könnte, solche Entwickler für Arbeiten an seinem Code einzusetzen, da er auf der Grundlage, dass die Entwickler Quellcode gesehen haben, der eine ähnliche oder dieselbe Funktionalität abdeckt, aber proprietär ist und nicht unter einer Open-Source-Lizenz zur Verfügung gestellt wurde, Gefahr laufen könnte, wegen Urheberrechtsverletzung verklagt zu werden.
Schließlich muss ebenfalls erwähnt werden, dass das Handbuch für MySQL nicht unter der GPL oder einer ähnlichen Lizenz freigegeben wird. Sun/MySQL behält sich gegenwärtige alle Rechte an dem Handbuch vor und erlaubt lediglich eine
463Weiterverteilung ohne Änderungen und zusammen mit MySQL selbst. Dies bedeutet, dass ein Forker, der seinen Ableger mit einem Handbuch anbieten möchte (was absolut notwendig erscheinen würde, nicht nur bei kommerziellen Nutzern), dieses komplett neu erstellen müsste. Obwohl sicher möglich, ist dies keine leichte Aufgabe angesichts der Möglichkeit von Klagen wegen Urheberrechtsverletzung seitens des Eigentümers von MySQL (und somit des Inhaber des Urheberrechts an dem Handbuch).
741Diese Bedenken sind jedoch durch die öffentliche Ankündigung seitens Oracle, das Handbuch weiterhin kostenlos bereitzustellen, ausreichend entkräftet worden. Eine weitere Beruhigung von Forkern, die das Handbuch verwenden möchten, könnte die Tatsache sein, dass – wie die Anmelderin betont – weder Oracle noch Sun jemals Prozesse um Urheberrechtsverletzungen bei Handbüchern angestrengt haben.
742Ein Forker von MySQL wäre auf die GPL beschränkt und könnte sein Produkt (außerdem) nicht unter einer kommerziellen Lizenz freigeben. Dies hat Auswirkungen auf Speicher-Engines von Drittanbietern, da diese Anbieter bei ihrem Geschäftsmodell von der Verfügbarkeit solcher kommerziellen Lizenzen abhängig sind. Wie unter Randnummer 721 bis 723 dargelegt, ist in vielen Segmenten des Datenbankmarkts eine reine Open-Source-Strategie für Anbieter von Speicher-Engines, die ihre Investitionen und ihr geistiges Eigentum schützen müssen, ungeeignet.
743Speicher-Engine-Drittanbieter können daher ihre Produkte nur unter einer proprietären Lizenz verfügbar machen. Hierdurch entsteht wiederum ein Problem, wenn lediglich eine GPL-Version von MySQL erhältlich ist. In vielen Fällen werden die Anbieter proprietärer Speicher-Engines durch Bestimmungen der GPL Version 2 daran gehindert, ein integriertes Produkt (MySQL-Hauptserver plus proprietäre Speicher-Engine) an seine Kunden zu liefern, was den Wert ihrer Marktposition erheblich schmälert.
Darüber hinaus scheint selbst im Hinblick auf den reinen Vertrieb proprietärer Speicher-Engines für MySQL keine Rechtssicherheit zu bestehen. Obwohl von einigen Seiten die Ansicht vertreten wird, dass beide Probleme durch Entwicklung einer Schnittstelle zwischen dem MySQL-Hauptserver und der Speicher-Engine ScaleDB im
463Diese Dokumentation darf nicht in irgendeiner Form oder auf irgendeinem Datenträger veröffentlicht oder verteilt werden, ausgenommen, die Dokumentation wird auf ähnliche Weise, wie sie von Sun verbreitet wird (d. h. auf elektronischem Weg zum Herunterladen auf einer Website zusammen mit der Software) oder auf einer CD-ROM oder einem ähnlichen Datenträger verteilt, jedoch vorausgesetzt, dass die Dokumentation zusammen mit der Software auf demselben Datenträger verbreitet wird. Jegliche sonstige Nutzung, wie beispielsweise jegliche Verbreitung gedruckter Kopien oder Nutzung dieser Dokumentation, ganz oder in Teilen, in einer anderen Publikation bedarf der vorherigen schriftlichen Zustimmung eines autorisierten Vertreters von Sun Microsystems, Inc. Sun Microsystems, Inc. und MySQL AB behalten sich sämtliche Rechte an dieser Dokumentation, die oben nicht ausdrücklich gewährt werden, vor.
465Rahmen einer BSD-Lizenz gelöst werden könnte , wird von anderer Seite angezweifelt, dass dies ein gangbarer Weg wäre. Laut Calpont gibt es für Speicher-Engines von Drittanbietern so gut wie keine Möglichkeit, ohne proprietäre Lizenz für MySQL kommerziell erfolgreich zu sein, unabhängig von der juristischen Auslegung der Bestimmungen der GPL. Dies liegt daran, dass bei Fragen rund um die GPL die Wahrnehmung der Marktteilnehmer und insbesondere der Kunden offensichtlich wichtiger (und wahrnehmbarer) ist als die tatsächlich relevanten Präzedenzfälle.
745Angesichts der obigen Erläuterungen wären Drittanbieter von Speicher-Engines für MySQL auf den ursprünglichen Eigentümer von MySQL zwecks Bereitstellung proprietärer Lizenzen, die die Bereitstellung integrierter Produkte mit einer Kombination aus MySQL und einer Drittanbieter-Speicher-Engine ermöglichen, angewiesen, wenn sie wettbewerbsfähig bleiben möchten. Dies könnte Probleme im Rahmen des Zusammenschlussvorhabens verursachen, da Oracle als etablierter Marktführer auf dem Datenbankmarkt ganz andere Anreize in Bezug auf die Speicher-Engines von Drittanbietern für MySQL haben wird, als dies gegenwärtig bei Sun der Fall ist.
746Insgesamt würde die Nichtverfügbarkeit kommerzieller Lizenzen für einen Ableger von MySQL auch den Anreiz für Investitionen in neue und modernere Speicher-Engine-Technologie massiv hemmen, da die Anbieter von Speicher-Engines gezwungen wären, ein auf der GPL Version 2 basierendes Geschäftsmodell zu übernehmen. Die modulare Architektur von MySQL, die die Entwicklung unabhängiger Speicher-Engines unterstützt, ist ein wichtiger Aspekt der potenziellen Attraktivität von MySQL im Hinblick auf ein breites Spektrum von verschiedenen kommerziellen Anforderungen.
465Nach meinem Verständnis können kommerzielle Speicher-Engines eine OSS Glue-Schicht bilden, die die Speicher-Engines (mehrfach) abruft. Diese OSS Glue-Schicht könnte mit Berkeley DB, PostgreSQL and Ingres zusammenarbeiten und ist somit datenbankunabhängig. Eine solche OSS Glue-Schicht könnte mehrere kommerzielle Speicher-Engines abrufen, sodass dies unabhängig von der Speicher-Engine wäre. Somit werden die beiden Teile (MySQL und Speicher-Engine) nicht als ein Produkt betrachtet. Dies erfüllt einen weiteren Aspekt des Puffers zwischen GPL und kommerzieller Lizenz. Mit Open Source Glue, das X DBMS und Y Speicher-Engines unterstützt, und durch die quelloffene Gestaltung des Glue, ist man auf einem guten Weg.
464Erwiderung auf die Mitteilung der Beschwerdepunkte, Randnummer 356.
Der Erfolg spezieller Engines erhöht daher die Attraktivität von MySQL und umgekehrt und schließlich den Wettbewerbsdruck, den MySQL (oder Ableger von MySQL) auf Oracle und andere Datenbankanbieter ausübt.
747Diese Bedenken werden durch die öffentliche Ankündigung von Oracle, laufende Verträge zwischen Sun/MySQL und den Anbietern von Speicher-Engines zu proprietären Lizenzen mindestens fünf Jahre lang zu den gleichen Konditionen fortzuführen, in ausreichendem Maße entkräftet. Da Oracle den betroffenen Speicher-Engine-Anbietern bereits vertragliche Änderungen zugesagt hat, besteht nicht einmal die theoretische Möglichkeit des Rückzugs von dieser Ankündigung. Andere und zukünftige Speicher-Engine-Anbieter könnten von der öffentlichen Zusage profitieren, mit der Oracle auf die GPL-Bestimmungen hinsichtlich einer freien Lizenz für Drittanbieter-Speicher-Engines mit der modularen Speicher-Engine-API von MySQL verzichtet.
748Oracle bringt vor, dass jüngste Ankündigungen von Amazon zeigen, dass der Marktzutritt eines Ablegers von MySQL möglich und einfach ist und auch geschieht. Tatsächlich biete Amazon jedoch auf die eigene Cloud-Computing-Plattform aufgesetzte Datenbankdienste an, d. h. Services zur Unterstützung der Kunden in der Cloud Computing-Umgebung bei der Nutzung von MySQL. Dieses Angebot kann daher aus technischer Sicht nicht als Ableger von MySQL bezeichnet werden, sondern es stellt vielmehr einen Weitervertriebsdienst dar.
749Nach Ansicht der Kommission verweist die Anmelderin zu Recht darauf hin, dass das Angebot von Amazon bis zu einem gewissen Grad mit dem Angebot von Sun/MySQL in Konkurrenz steht, insbesondere, da es auf der GPL-Version von MySQL basiert und daher nicht zu Einnahmen für Sun/MySQL führt. Es ist jedoch fraglich, in welchem Maße Amazon in der Lage wäre, ein solches Serviceangebot aufrechtzuerhalten, wenn das Unternehmen sich nicht auf die von Sun/MySQL bereitgestellten GPL-basierten MySQL-Updates und -Patches aus dem vorgelagerten Bereich verlassen könnte. Dennoch ist es gewiss möglich, dass das Unternehmen, sollte es nicht weiter mit diesen Patches aus dem vorgelagerten Bereich versorgt werden, einen eigenen MySQL-Ableger erstellt und fortführt.
4.4.3.4Schlussfolgerung
750Zum Abschluss der Untersuchung der Kommission lässt sich feststellen, dass trotz der Hürden in wirtschaftlicher, technischer und urheberrechtlicher Sicht, denen Ableger ausgesetzt sind, die Möglichkeit nicht ausgeschlossen werden kann, dass auch MySQL-Ableger entwickelt werden, die zu einem gewissen Grad einen Wettbewerbsdruck auf Oracle ausüben.
4.5Bindung von Kunden, die von MySQL migrieren, an eine proprietäre Datenbank
751Einige Wettbewerber, die Beschwerden vorgebracht haben, argumentieren, dass Oracle die Möglichkeit und den Anreiz hätte, MySQL-Kunden, die auf eine andere Datenbank umstellen möchten, um ihre wachsenden funktionalen Anforderungen abzudecken, hin zur Migration zur Oracle Datenbank zu lenken. MySQL wird von vielen Unternehmen als Einstiegsdatenbank verwendet. Da einige dieser Unternehmen wachsen, benötigen
sie unter Umständen ab einem gewissen Punkt für bestimmte Vorgänge proprietäre Datenbanken wie diejenigen von IBM oder Oracle.
752Die sich beschwerenden Wettbewerber behaupten, dass Oracle unter Ausnutzung seiner Kontrolle über MySQL technologische Änderungen vornehmen oder kommerzielle Verknüpfungen mit MySQL-Nutzern schaffen würde, um MySQL-Kunden die Umstellung auf eine nicht von Oracle stammende proprietäre Datenbank zu erschweren. Beispiele für potenzielle technologische Änderungen liegen im Bereich der verfügbaren/unterstützten Datentypen, der Transaktionskonsistenz und insbesondere der Unterstützung derselben Tools für die Datenbankadministration. Wenn diese Bereiche zwischen den Produkten von Oracle und MySQL stärker aneinander angeglichen werden, lässt sich eine Migration problemloser umsetzen.
753Die Marktuntersuchung der ersten Phase hat ergeben, dass obwohl die Wettbewerber alles in allem die Möglichkeit seitens Oracle sehen, eine solche Strategie einzuschlagen, das Feedback der Kunden zu dieser Schadenstheorie nicht schlüssig ist, da ungefähr die Hälfte der Kunden diese Möglichkeit sieht und ungefähr die Hälfte nicht. Kunden und Wettbewerber erwarten, dass eine solche Strategie profitabel wäre, wenn Oracle die Möglichkeit dazu hätte. Angenommen, Oracle hätte die Möglichkeit, bleibt es dennoch unklar, ob die Auswirkungen auf die Migration einen Vorteil für MySQL- und Oracle-Nutzer oder einen Nachteil für die Mitbewerber von Oracle darstellen würden.
754In Bezug auf die konkretere Frage nach den technischen Möglichkeiten von Oracle, die Migration der gegenwärtigen MySQL-Nutzer zu einer Nicht-Oracle-Datenbank zu verhindern oder zu behindern, gaben im Rahmen der Marktuntersuchung der zweiten Phase die meisten Kunden und Wettbewerber an, dass Oracle nicht die Möglichkeiten hätte, die Migration zu einer Nicht-Oracle-Datenbank zu verhindern oder zu behindern.
755Daher wird der Schluss gezogen, dass Oracle nicht die Möglichkeit hat, die Migration von MySQL-Kunden, die zu einer proprietären Datenbank eines anderen Anbieters wechseln möchten, zu verhindern oder zu behindern. Wenn Oracle die Möglichkeit hätte, die Migration von MySQL-Kunden zu Oracle Datenbanken zu vereinfachen, kann dies eher als Vorteil für MySQL- und Oracle-Nutzer als als Nachteil für den Wettbewerb auf dem Datenbankmarkt angesehen werden.
4.6Schlussfolgerung
756Die ausführliche Untersuchung der Kommission kommt zu dem Schluss, dass MySQL vor dem Zusammenschluss potenziell einen entscheidenden und wachsenden Wettbewerbsdruck auf Oracle und andere Anbieter proprietärer Datenbanken in den Segmenten des Datenbankmarkts, in denen es aktiv ist – insbesondere in den Segmenten Web, KMU und eingebettete Datenbanken – ausübt.
757Daraus kann jedoch nicht notwendigerweise auf die Bedeutung des Wettbewerbsdrucks von MySQL nach dem Zusammenschluss geschlossen werden, da es angesichts der Unterlagen in der Akte, insbesondere des Open-Source-Charakters von MySQL, der öffentlichen Ankündigung von Oracle vom 14. Dezember 2009 und deren teilweise Umsetzung, unwahrscheinlich ist, dass Oracle die Möglichkeit und/oder den Anreiz hätte, sich des von MySQL vor dem Zusammenschluss ausgeübten Wettbewerbsdrucks zu entledigen.
758Darüber hinaus fehlt der Open-Source-Datenbank PostgreSQL zurzeit zwar noch ein großes Ökosystem (auch hinsichtlich Verfügbarkeit und Support), wird aber dennoch mit großer Wahrscheinlichkeit in der Lage sein, den gegenwärtig von MySQL ausgeübten Wettbewerbsdruck bis zu einem gewissen Grad zu ersetzen. Ferner kann die Möglichkeit nicht ausgeschlossen werden, dass auch andere neu entwickelte MySQL-Ableger einen gewissen Wettbewerbsdruck auf Oracle ausüben.
Daher wird der Schluss gezogen, dass das Zusammenschlussvorhaben in der Gesamtbetrachtung nicht zu einer erheblichen Einschränkung des wirksamen Wettbewerbs auf dem weltweiten Datenbankmarkt führen wird.
C. Middleware
1. Sachlich relevanter Markt
760Sowohl Oracle als auch Sun sind im Sektor Middleware tätig. Middleware bezeichnet eine breite Palette von Softwareprodukten, die eine Infrastruktur für den Betrieb von Anwendungen auf einem Server zur Verfügung stellen, von einer Vielzahl von Clients über ein Netzwerk zugänglich sind und in der Lage sind, eine Vielfalt von Informationsquellen zu verbinden.
Die Tätigkeiten der beteiligten Unternehmen im Bereich Middleware umfassen insbesondere: (i) Anwendungsserver; (ii) Webserver; (iii) Identity und Access Management; (iv) Anwendungsintegration (Enterprise Service Bus), Vorgangsverwaltung, Prozessautomation, Software für Geschäftsprozessverwaltung (Business Process Management); (v) Adapter und Verbindungsstücke, Portale; (vi) Collaboration Software und (vii) Virtualisierungssoftware. Die von Oracle und Sun angebotenen Middleware-Produkte sind als Einzelkomponenten oder als Teil von umfangreicheren Middleware-Paketen verfügbar. Einige der Middleware-Produkte von Sun sind Open-Source-Produkte.
762Die Anmelderin vertritt die Auffassung, dass alle Arten von Middleware zu einem einzigen sachlichen Markt gehören. In der jüngsten Entscheidung in der Sache Oracle/BEA ließ die Kommission die Definition des sachlichen Markts offen, stellte jedoch fest, dass die Marktuntersuchung zu dem Ergebnis kam, dass Middleware nach dem Endnutzungszweck der Produkte unterteilt werden kann.
763Im vorliegenden Fall hat die Marktuntersuchung ergeben, dass Middleware von Kunden sowohl als Bestandteil eines Pakets als auch als Einzelprodukt erworben wird, was auch die Tatsache widerspiegelt, dass die meisten Middleware-Produkte auf verschiedenen relevanten Hardware- bzw. Betriebssystemplattformen verfügbar sind (mit Ausnahme der Produkte von Microsoft, die nur für Betriebssysteme von Microsoft zur Verfügung stehen). Die meisten Kunden gaben an, dass Middleware-Produkte eines bestimmten Anbieters in der Regel auf bestimmte Bereiche oder Funktionen von Middleware beschränkt sind.
764Die Marktuntersuchung ergab auch, dass die meisten Kunden und Wettbewerber die Ansicht vertreten, dass quelloffene Middleware-Produkte mit nicht quelloffenen Middleware-Produkten konkurrieren. Daraus wird deutlich, dass die meisten Kunden beim Kauf von Middleware sowohl quelloffene als auch proprietäre Lösungen erwägen.
Die genaue Definition des sachlichen Markts für Middleware kann für die vorliegenden Sache offen gelassen werden, da das vorgeschlagene Zusammenschlussvorhaben nach keiner der möglichen Marktdefinitionen Anlass zu ernsthaften Bedenken hinsichtlich seiner Vereinbarkeit mit dem Gemeinsamen Markt gibt.
2. Räumlich relevanter Markt
Die Anmelderin vertritt die Auffassung, dass es sich bei dem Markt für Middleware um einen Markt mit weltweiter Ausdehnung handelt.
In der Sache Oracle/BEA bewertete die Kommission die Auswirkungen des Vorhabens auf den Markt für Middleware insgesamt und auf dessen Teilsegmente unter der Annahme einer weltweiten geografischen Ausdehnung.
Die Marktuntersuchung im der vorliegenden Sache hat bestätigt, dass der Markt für Middleware ein weltweiter Markt ist.
Im Rahmen dieses Beschlusses wird als räumlich relevanter Markt für den Middlewaremarkt insgesamt und dessen Teilsegmente von einem weltweiten Markt ausgegangen.
3. Wettbewerbsrechtliche Würdigung
3.1. Einseitige Wirkungen
3.1.1. Gesamtmarkt für Middleware
770Der weltweite Markt für Middleware hatte im Jahr 2007 ein Volumen von rund 9,7 Mrd. EUR und verzeichnete im selben Jahr ein Wachstum von 17 %. Tabelle 4 unten enthält eine von IDC vorgenommene Schätzung der Marktanteile (weltweite Marktanteile auf der Grundlage der Einnahmen) von Oracle, Sun sowie ihren wichtigsten Wettbewerbern auf dem Gesamtmarkt für Middleware.
Tabelle 4: Marktanteile Software für Anwendungsbereitstellung 2006-2007
Marktanteile in Prozent 2006 2007 [20-30]* % [20-30]* % [10-20]* % [10-20]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* % [30-40]* % [30-40]* %
Anbieter
IBM Oracle SWIFT Microsoft Sterling Commerce TIBCO Sun Sonstige
771Die Anmelderin trägt vor, dass das Zusammenschlussvorhaben den wirksamen Wettbewerb im Bereich Middleware nicht wesentlich beeinträchtigen würde. Oracle gibt hierzu an, dass das fusionierte Unternehmen weiterhin einem starken Wettbewerbsdruck vonseiten des Marktführers IBM ausgesetzt sein werde und auch von Microsoft sowie von großen Unternehmen, die reine Middleware-Produkte anbieten, wie etwa TIBCO, sowie von verschiedenen Open-Source-Lösungen. Der Marktanteil von Sun werde außerdem den Marktanteil von Oracle am Gesamtmarkt für Middleware-Produkte nur unwesentlich erhöhen. Die Anmelderin trägt außerdem vor, dass Oracle und Sun keine sehr engen Wettbewerber im Bereich Middleware und dass ihre Middleware-Produkte für unterschiedliche Zwecke konzipiert seien.
772Die Angaben von IDC zu den Marktanteilen deuten darauf hin, dass der Zuwachs an Marktanteilen, der sich aus dem vorgeschlagenen Vorhaben ergibt, unwesentlich sein wird und dass der gemeinsame Marktanteil weit unter 25 % liegen wird. Bei einer Reihe der Middleware-Produkte von Sun handelt es sich jedoch um Open-Source-Produkte (d. h. dessen Anwendungsserver GlassFish, der GlassFish Web Space Server, das GlassFish Web Stack und das Open SSO Enterprise, ein Identity Management Programm), einnahmenbezogene Marktanteile geben daher den Wettbewerbsdruck, den die Produkte von Sun auf Oracle ausüben, möglicherweise nicht vollständig wieder.
773Die Marktuntersuchung hat ergeben, dass Sun zwar in einigen Teilsegmenten substituierbare Produkte anbietet, dennoch ganz eindeutig kein bedeutender Wettbewerber auf dem Gesamtmarkt für Middleware ist. Die meisten Kunden betrachten Oracle und Sun nicht als enge Wettbewerber im Bereich Middleware.
Die Marktuntersuchung hat darüber hinaus ergeben, dass auf dem Markt für Middleware ein starker Wettbewerb herrscht und dass das fusionierte Unternehmen sich weiterhin dem Wettbewerb einer Reihe bedeutender Marktteilnehmer gegenüber sieht, insbesondere von IBM und Microsoft, jedoch ebenso von Lieferanten von Open-Source-Programmen wie Red Hat (JBoss) und dem Verbund um das freie Projekt Apache. Auch hat keiner der Kunden oder Wettbewerber Befürchtungen geäußert, dass die Middleware-Produkte von Sun in einem Ausmaß ausgebaut werden könnten, dass sie eine stärkere Konkurrenz für Produkte anderer Anbieter im Bereich Middleware (oder jedenfalls zu stärkeren Wettbewerbern der Produkte von Oracle) darstellen könnten.
3.1.2. Teilsegmente für Middleware
775Was die verschiedenen Teilsegmente für Middleware anbelangt, übersteigt der gemeinsame Marktanteil von Oracle und Sun den Wert von 15 % nur bei den Produkten (i) Middleware für Anwendungsserver , (ii) Unternehmensportale und (iii) Middleware für Integrations- und Prozessautomatisierung (im Besonderen ESB und BPMS).
3.1.2.1. Software für Anwendungsserver
Tabelle 5 unten zeigt die von IDC erstellte Schätzung der Marktanteile weltweit für Oracle, Sun und ihre wichtigsten Wettbewerber im Bereich Middleware für Anwendungsserver.
Tabelle 5: Marktanteile Middleware für Anwendungsserver 2006-2007
Marktanteile in Prozent 2006 2007 [40-50]* % [40-50]* % [20-30]* % [20-30]* % [5-10]* % [5-10]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* % [10-20]* % [10-20]* %
Anbieter
IBM Oracle Microsoft Fujitsu Hitachi Sun Sonstige
Die Definition von IDC für Middleware für Anwendungsserver umfasst Softwareplattformen für Anwendungsserver sowie Transaktionsmonitore (Transaction Processing Monitor – „TPM“). Diese beiden Teilsegmente haben eine eng miteinander verbundene Funktionalität, welche die Produktangebote in einigen Fällen substituierbar macht. Die von IDC für das Jahr 2007 ermittelten Marktanteile im Bereich TPM betrugen für IBM [70-80]* %, für Oracle [10-20]* % und für Sun [0-5]* %.
Tabelle 6 unten gibt die Schätzungen von IDC der Marktanteile weltweit von Oracle, Sun und ihren wichtigsten Wettbewerbern in Bezug auf Softwareplattformen für Anwendungsserver an.
Tabelle 6: Marktanteile Softwareplattformen für Anwendungsserver 2006-2007
Marktanteile in Prozent 2006 2007 [30-40]* % [30-40]* % [20-30]* % [20-30]* % [10-20]* % [10-20]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* % [10-20]* % [10-20]* %
Anbieter
Oracle IBM Microsoft Fujitsu Micro Focus Sun Sonstige
779Die Anmelderin trägt vor, dass die Softwareplattform für Anwendungsserver von Sun die Position von Oracle nur unwesentlich verstärken würde und dass sich das fusionierte Unternehmen weiterhin im Wettbewerb mit einer Reihe von Akteuren behaupten müsste, darunter IBM, Microsoft und Open-Source-Wettbewerber (wie JBoss und Apache Tomcat). Die Anmelderin trägt weiter vor, dass Oracle und Sun bei Anwendungsservern in keinem besonders engen Wettbewerb miteinander stehen und dass ihre Anwendungsserver verschiedenen Zwecken dienen.
Laut Gartner basieren Serversoftwareprodukte vorwiegend entweder auf .NET, das an eine strikte Bündelung mit Microsoft-Produkten gebunden ist, oder auf der Java Enterprise Edition, das von verschiedenen Anbietern verwendet wird. Lösungen, die auf einer dieser beiden konkurrierenden Plattformen basieren, sind marktbeherrschend, stehen jedoch zu einem gewissen Teil mit älteren TPM- und ORB-Produkten im Wettbewerb, wie PHP, Ruby, Java Advanced Intelligent Networks (JAIN) und Java Service Logic Execution Environment (JSLEE).
781Obwohl die Zahlen der Marktanteile, die IDC nennt, darauf hinweisen, dass der Marktanteil von Oracle infolge des Zusammenschlusses nur geringfügig steigen wird, könnte davon ausgegangen werden, dass die einnahmenbasierten Marktanteile den Druck, der von den Open-Source-Produkten von Sun auf die von Oracle ausgeübt wird, nicht getreu wiedergeben. Nach den von IDC erhobenen Zahlen der Marktanteile von Softwareplattformen für Anwendungssoftware wird der Marktanteil von Sun nach seiner jüngsten Initiative, sein Anwendungsserverprodukt GlassFish als Open-Source-Produkt anzubieten, nur geringfügig schrumpfen. Sun berichtete von einem Rückgang seines Marktanteils von [0-5]* % im Jahre 2006 auf [0-5]* % im Jahre 2007. Auch die höhere dieser beiden Zahlen würde den Marktanteil von Oracle nur unwesentlich steigern. Es weist auch nichts darauf hin, dass der „reale“ Marktanteil der Produkte von Sun stärker angestiegen ist, jedoch aufgrund der Verfügbarkeit in Open-Source-Form nicht erhoben wurde.
Die Marktuntersuchung hat auch bestätigt, dass aus Kundensicht die Produkte von Sun im Segment Anwendungsserver nicht als nahe Substitute für die Produkte von Oracle gelten. Wird eines der beteiligten Unternehmen als Anbieter eines nahen Substituts für die Produkte des anderen beteiligten Unternehmens angegeben, so werden gleichzeitig auch andere Wettbewerber als Anbieter naher Substitute genannt. Die Marktuntersuchung hat ergeben, dass der Markt von einem sehr starken Wettbewerb mit vielen in Frage kommenden aktiven Anbietern geprägt ist und dass das fusionierte Unternehmen weiterhin im Wettbewerb mit einer Reihe von Marktakteuren wie IBM, Microsoft, SAP und Fujitsu bestehen muss, sogar in dem (gewissermaßen künstlich verengten) Segment der Softwareplattformen für Anwendungsserver. Die Marktuntersuchung hat auch gezeigt, dass Open-Source-Produkte, wie etwa die JBoss-Produkte von Red Hat, einen bedeutenden Wettbewerbsdruck in dem Segment der Anwendungsserver ausüben. Des Weiteren äußerte sich keiner der Kunden oder Wettbewerber dahingehend, dass ein Ausbau der Middleware-Produkte von Sun in einem Ausmaß zu erwarten sei, der ihre Wettbewerbsposition gegenüber den Produkten der anderen Marktteilnehmer in dem Segment Anwendungsserver (oder jedenfalls gegenüber den Produkten von Oracle) verstärken würde.
3.1.2.2. Unternehmensportale
Tabelle 7 unten zeigt die von IDC erstellte Schätzung der Marktanteile von Oracle, Sun und ihren wichtigsten Wettbewerbern in dem Segment Unternehmensportale.
Tabelle 7: Marktanteile Software für Unternehmensportale 2006-2007
Marktanteile in Prozent 2006 2007 [20-30]* % [20-30]* % [20-30]* % [20-30]* % [10-20]* % [10-20]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* % [10-20]* % [10-20]* %
Anbieter
Oracle IBM Microsoft SAP VB Sun Sonstige
784Die Anmelderin trägt vor, dass der Marktanteil von Sun bei der Software für Unternehmensportale nicht zu einer wesentlichen Steigerung des Marktanteils von Oracle führen werde und dass das fusionierte Unternehmen weiterhin im Wettbewerb mit etlichen Marktteilnehmern stehen würde. Nach Angaben der Anmelderin stehen Oracle und Sun bei Unternehmensportalprodukten nicht in einem besonders engen Wettbewerb zueinander und dienen ihre Unternehmensportalprodukte verschiedenen Zwecken.
Der Marktanteil von Oracle im Segment Unternehmensportale liegt bei knapp über [20-30]* %. Die Zahlen von IDC zu den Marktanteilen weisen auch darauf hin, dass die Steigerung des Anteils von Oracle durch das vorgeschlagene Zusammenschlussvorhaben gering ausfallen wird. Diese Ergebnisse erscheinen zuverlässig, selbst angesichts der Tatsache, dass Marktanteile auf der Grundlage von Einnahmen den Wettbewerbsdruck, den die Open-Source-Portalprodukte von Sun ausüben, nicht vollständig abbilden. Weder die Marktuntersuchung noch andere Quellen lassen darauf schließen, dass der Anteil der Unternehmensportalsoftware von Sun stärker ausgedehnt werden könnte, als aus den Zahlen zu den Marktanteilen von IDC hervorgeht. Die Marktuntersuchung ergab auch, dass die Portalsoftware von Oracle und von Sun keine nahen Substitute im Segment Unternehmensportale darstellen. Die Marktuntersuchung bestätigte außerdem auch, dass auf dem Markt ein starker Wettbewerb mit vielen in Frage kommenden Anbietern herrscht und dass das fusionierte Unternehmen im Segment Unternehmensportale weiterhin im Wettbewerb mit etlichen großen Marktteilnehmern stehen wird, in erster Linie mit IBM, Microsoft, SAP und Computer Associates. Des Weiteren äußerte sich keiner der Kunden oder Wettbewerber dahingehend, dass ein Ausbau der Produkte von Sun in einem Ausmaß zu erwarten sei, der ihre Wettbewerbsposition gegenüber den Produkten der anderen Marktteilnehmer in dem Segment Unternehmensportale (oder jedenfalls gegenüber den Produkten von Oracle) verstärken würde.
3.1.2.3. ESB-Software
Tabelle 8 unten zeigt die von IDC erstellte Schätzung der Weltmarktanteile von Oracle, Sun und ihren wichtigsten Wettbewerbern im ESB-Segment.
Tabelle 8: Marktanteile ESB- und Connectivity-Middleware 2006-2007
Marktanteile in Prozent 2006 2007 [20-30]* % [20-30]* % [10-20]* % [10-20]* % [10-20]* % [10-20]* % [10-20]* % [5-10]* % [5-10]* % [5-10]* % [20-30]* % [20-30]* %
Anbieter
IBM Oracle Software AG TIBCO Sun SAP Microsoft Sonstige
787Nach den Angaben der Anmelderin wird das vorgeschlagene Zusammenschlussvorhaben den wirksamen Wettbewerb im Segment ESB-Software nicht wesentlich beeinträchtigen. Die Anmelderin führt insbesondere an, dass IBM nach dem Zusammenschluss Marktführer bleiben wird, während andere Marktteilnehmer weiterhin einen Wettbewerbsdruck auf das fusionierte Unternehmen ausüben werden. Laut Anmelderin befindet sich das ESB-Segment im Wachstum und die Open-Source- sowie JBoss-Produkte von MuleSource und Red Hat werden von IDC als stark genug bezeichnet, um gute Alternativen zu kommerziellen Lösungen darzustellen. Die Anmelderin trägt außerdem vor, dass Oracle und Sun keine sehr engen Wettbewerber im Bereich ESB-Software und dass ihre ESB-Software für unterschiedliche Zwecke konzipiert seien.
Neben dem relativ geringen gemeinsamen Marktanteil der Produkte der beteiligten Unternehmen (selbst wenn berücksichtigt wird, dass die für den Marktanteil von Sun angegebenen Zahlen nicht ganz genau sind, da einige der Produkte von Sun quelloffen sind) ergab die Marktuntersuchung, dass aus Kundensicht die Produkte von Sun nicht die nächsten Substitute für die Produkte von Oracle im ESB-Segment darstellen. Wird eines der beteiligten Unternehmen als Anbieter eines nahen Substituts für die Produkte des anderen beteiligten Unternehmens angegeben, so werden gleichzeitig auch andere Wettbewerber als Anbieter naher Substitute genannt. Die Marktuntersuchung bestätigte den starken Wettbewerb auf dem Markt mit vielen in Frage kommenden Anbietern und ergab, dass sich das fusionierte Unternehmen in dem ESB-Segment weiterhin dem Wettbewerb etlicher starker Marktteilnehmer wie IBM, TIBCO, Software AG, Microsoft und Progress Software wird stellen müssen. Produkte von Open-Source-Anbietern wie etwa die JBoss-Produkte von Red Hat führen nach den Ergebnissen der Marktuntersuchung ebenfalls zu einem starken Wettbewerbsdruck im ESB-Segment. Des Weiteren äußerte sich keiner der Kunden oder Wettbewerber dahingehend, dass ein Ausbau der Produkte von Sun in einem Ausmaß zu erwarten sei, der ihre Wettbewerbsposition gegenüber den Produkten der anderen Marktteilnehmer in dem ESB-Segment (oder jedenfalls gegenüber den Produkten von Oracle) verstärken würde.
3.1.2.4. Middleware zur Prozessautomatisierung (BPMS)
Tabelle 9 unten gibt die von IDC erstellte Schätzung der weltweiten Marktanteile von Oracle, Sun und ihren wichtigsten Wettbewerbern im Segment BPM-Systeme an.
Tabelle 9: Marktanteile Middleware zur Prozessautomatisierung 2006-2007
Marktanteile in Prozent 2006 2007 [5-10]* % [10-20]* % [10-20]* % [10-20]* % [5-10]* % [5-10]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* % [0-5]* %
Anbieter
Oracle IBM ACI Worldwide TIBCO Software AG Adobe Sun Pegasystems Microsoft Sonstige
790Die Anmelderin trägt vor, dass der Marktanteil von Sun im Bereich der BPMS-Produkte den Marktanteil von Oracle in diesem Bereich nicht wesentlich vergrößern wird und dass das fusionierte Unternehmen weiterhin im Wettbewerb mit etlichen anderen Marktteilnehmern stehen wird.
791Neben dem relativ geringen gemeinsamen Marktanteil der Produkte der beteiligten Unternehmen (selbst wenn berücksichtigt wird, dass die für den Marktanteil von Sun angegebenen Zahlen nicht ganz genau sind, da einige der Produkte von Sun quelloffen sind) ergab die Marktuntersuchung, dass aus Kundensicht die Produkte von Sun nicht die nächsten Substitute für die Produkte von Oracle im Bereich des BPMS-Segments darstellen. Wird eines der beteiligten Unternehmen als Anbieter eines nahen Substituts für die Produkte des anderen beteiligten Unternehmens angegeben, so werden
489Formblatt CO, Seite 111, Tabelle 11 nach IDC, Worldwide Process Automation Middleware 2007 Vendor Shares [Middleware zur Prozessautomatisierung – Marktanteile 2007 weltweit], September 2008.
gleichzeitig auch andere Wettbewerber als Anbieter naher Substitute genannt. Die Marktuntersuchung bestätigte den starken Wettbewerb auf dem Markt mit vielen in Frage kommenden Anbietern und ergab, dass das fusionierte Unternehmen sich weiterhin dem Wettbewerb etlicher starker Marktteilnehmer wie IBM, TIBCO, Pegasystems, Software AG und SAP wird stellen müssen. Produkte von Open-Source-Anbietern wie etwa die JBoss-Produkte von Red Hat führen den Ergebnissen der Marktuntersuchung zufolge ebenfalls zu einem starken Wettbewerbsdruck im BPMS-Segment. Des Weiteren äußerte sich keiner der Kunden oder Wettbewerber dahingehend, dass ein Ausbau der Produkte von Sun in einem Ausmaß zu erwarten sei, der dessen Wettbewerbsposition gegenüber den Produkten der anderen Marktteilnehmer in dem BPMS-Segment (oder jedenfalls gegenüber den Produkten von Oracle) verstärken würde.
3.3. Schlussfolgerung
792Angesichts der obigen Ergebnisse kann daher geschlossen werden, dass der geplante Zusammenschluss den effektiven Wettbewerb auf dem Gesamtmarkt für Middleware oder einem seiner möglichen Teilsegmente nicht nennenswert beeinträchtigt.
D. Java
1. Java als Inputfaktor für Softwareanwendungen
793Java ist eine Entwicklungsumgebung, die vor etwa 20 Jahren von Sun entwickelt wurde. Eine Entwicklungsumgebung ist ein Softwareplattform, mit deren Hilfe Entwickler Softwareanwendungen entwickeln und weiter ausbauen können. Entwicklungsumgebungen bestehen gewöhnlich aus drei Elementen: (a) einer Programmiersprache, (b) einer Reihe von Standard-„Bibliotheken“ (Implementierungen allgemeiner Funktionalitäten, die von neuer Software verwendet werden können und daher nicht jedes Mal „neu erfunden“ werden müssen, wenn ein Entwickler eine neue Anwendung schreibt, wie etwa die Funktionalität zum Schreiben von Daten auf die Festplatte) und (c) anderen Programmen zum Schreiben, Testen und Ausführen der Anwendungen. Die wichtigsten dieser Elemente werden im Folgenden beschrieben.
794Ein wesentliches Merkmal der Java-Entwicklungsumgebung ist die Tatsache, dass sie offen ist, also unabhängig von dem zugrunde liegenden Betriebssystem oder der Hardware, auf der Java-basierte Anwendungen laufen. Das Motto von Java lautet: „write once, run anywhere“ [Einmal schreiben, überall ausführen können]. Java schafft diese neutrale Lösung durch eine Schnittstellensoftware, die sogenannte Java Virtual Machine ("JVM"), welche den Java-Code ausführt. Da es JVM für unterschiedliche Computer, Geräte und Architekturen gibt (z. B. JVM für Windows, Linux, Unix und andere), müssen Java-Anwendungen selbst nicht verändert (portiert) werden, um auf anderen Plattformen verfügbar zu sein.
795Obwohl es für viele Teile von Java Open-Source-Implementierungen gibt, kontrolliert Sun die wichtigsten damit verbundenen geistigen Eigentumsrechte, für die Softwareentwickler, insbesondere Entwickler von Middleware und EAS, Lizenzen erwerben müssen. Sun hat daher die Kontrolle über einen wichtigen Inputfaktor für Unternehmen, die Software mit Hilfe der Programmiersprache Java entwickeln.
796Die wichtigste andere Entwicklungsumgebung ist .NET, die proprietäre und geschlossene Umgebung von Microsoft. .NET kann nur zur Entwicklung von Software
verwendet werden, die auf Windows läuft, während die Java-Software auf den meisten Betriebssystemen laufen kann.
797Es liegen keine Präzedenzfälle der Kommission zur Definition eines Markts für Entwicklungsplattformen vor, frühere Fälle jedoch beziehen sich auf „Entwicklungswerkzeuge“oder auf Java und .NET als Plattformen zur Entwicklung von Middleware, ohne jedoch die Entwicklungsumgebung als gesonderten Markt anzusehen.
Wettbewerb zwischen Entwicklungsplattformen
798Java ist für Entwickler attraktiv, da es „agnostisch“ ist, was bedeutet, dass es auf jeglicher Kombination aus Betriebssystem und Hardware (Plattform) ausgeführt werden kann, für das eine JVM geschaffen wurde. Entwickler können daher eine Einzelversion ihrer Anwendung erstellen und sich sicher sein, dass diese ebenso auf sämtlichen Plattformen ausgeführt werden kann.
799Die wichtigste andere Entwicklungsumgebung ist Microsoft .NET, die auf den Programmiersprachen Visual C# oder Visual Basic basiert. Es gibt auch andere Programmiersprachen, die routinemäßig dazu verwendet werden, um Anwendungen zu erstellen und für die es auch Entwicklungsumgebungen und Klassenbibliotheken mit fortgeschrittenen Funktionalitäten gibt, z. B. C oder C++, PHP, Ruby on Rails, Grails, Python oder Perl.
800Die Anmelderin legte die Ergebnisse der Studien vor, die von IDC und InfoTech Research Group zur Bewertung der herausragenden Stellung von JAVA und .NET als Entwicklungsplattformen durchgeführt wurden. In der Studie von IDC(von Microsoft unterstützt) wurden die Befragten gebeten, die Anwendungsplattformen zu nennen, die in ihren Unternehmen gegenwärtig oder vermutlich in Zukunft genutzt werden. .NET wurde am häufigsten als Anwendungsplattform für unternehmenskritische Anwendungen in 22,8 % der befragten Unternehmen genutzt, während Java am häufigsten als Anwendungsplattform für unternehmenskritische Anwendungen in 20,8 % der befragten Unternehmen verwendet wurde. Dann folgten IBM Mainframe Plattformen (z. B. CICS) mit 14 % der Nutzungen, Oracle Anwendungsplattformen wurden in 5,8 % der befragten Unternehmen verwendet, obwohl unklar ist, ob sich diese Zahl auf die Oracle-Datenbank, auf den Java-basierten Anwendungsserver oder auf beide bezieht. Die IDC-Studie ergab hinsichtlich der zukünftigen Nutzungen, dass .NET weiterhin an erster Stelle stehen wird (mit 30,2 %) vor Java (24,8 %). Die Studie von InfoTech aus dem Jahre 2007 erhob Daten von rund 2000 Unternehmen. Sie wurden nach ihren Präferenzen in Bezug auf die Anwendungsentwicklungsumgebung befragt. Folgende Antworten waren möglich: „Ausschließlich .NET“, „Ausschließlich Java“, „Vorzugsweise .NET“, „Vorzugsweise Java“ und „Sonstige“. Die Hälfte (49 %) der befragten Unternehmen nutzten vorzugsweise .NET, 12 % nutzten ausschließlich .NET (verglichen mit 20 %, die vorzugsweise Java nutzten, und 3 %, die ausschließlich Java nutzten). InfoTech schlussfolgerte, dass „der Kampf zwischen Java und .NET zu einem heiligen Krieg wird. IT-Manager, die bei der Unterstützung und Ausdehnung ihrer Anwendungsumgebungen von diesen Entwicklungsplattformen abhängig sind, zögern
immer stärker, beide anzuwenden. Sie werden zu einer Entscheidung gezwungen: .NET oder Java. Doch welche von beiden? Die Analyse von InfoTech zeigt, dass die Marktdynamik klar auf .NET weist. […] Die Ergebnisse zeigen, dass .NET eindeutig vorgezogen wird, ganz unabhängig von der Unternehmensgröße oder der Branche.
Im Gegensatz dazu hat die Marktuntersuchung ergeben, dass viele Softwarefirmen die Entwicklungsumgebung Java vorziehen, insbesondere, weil sie eine allgemeine Norm darstellt und weil Java auf jedem Betriebssystem und jeder Hardware genutzt werden kann (siehe Randnummer 854 und 855).
Die Java-Entwicklungsplattform ist (im weitesten Sinne) aufgrund ihrer besonderen Merkmale eine einzigartige Grundlage für Softwareentwickler. Java stellt als Technologie auch das Zentrum einer offenen Community von Softwareentwicklern dar, die von Sun im Java Community Process („JCP“) strukturiert wurde (siehe Randnummer 811 ff.) und für die eine Reihe von Regeln gelten. Die Technologie steht in begrenztem Maße unter einer Open-Source-Lizenz kostenlos zur Verfügung (die OpenJDK-Plattform, die binären Versionen der JRE usw.), die Grundlage als solche kann jedoch nicht als „proprietär“ oder von Sun „kontrolliert“ betrachtet werden. Die geistigen Eigentumsrechte für einige Nutzungen von Java liegen bei Sun, das seine Rechte entgeltlich an viele Softwareentwickler (unter anderem Hersteller von Middleware und EAS) lizenziert.
Obgleich Java nicht die einzige Entwicklungsplattform ist, stellt sie jedoch einen wichtigen Inputfaktor bei der Erstellung von Anwendungssoftware dar. Unter Randnummer 847 bis 861 wird ausgeführt, dass Java ein wichtiger Inputfaktor für viele Unternehmen, die Middleware und Unternehmenssoftware entwickeln, darstellt.
2. Geistige Eigentumsrechte an Java werden mit weltweiter Geltung vergeben
Fast alle Befragten der Marktuntersuchung bestätigten, dass die Lizenzen für Java geografisch nicht eingegrenzt sind und im Allgemeinen weltweit gelten.
Für die Zwecke dieses Beschlusses kann davon ausgegangen werden, dass die Lizenzierung von Java auf weltweiter Basis stattfindet.
3. Wettbewerbsrechtliche Würdigung
3.1. Java – Überblick
3.1.1. Die Programmiersprache Java für Java-Anwendungssoftware und das Java-Entwicklungskit (Java Development Kit)
Die Programmiersprache Java ist für Personen und Unternehmen frei zugänglich, auch zur Entwicklung kommerzieller Anwendungen. Programmentwickler können das Java-Entwicklungskit (Java Development Kit – „JDK“) verwenden, um Java-Anwendungssoftware zu schreiben (also Software, die eine bestimmte Funktionalität bereitstellt, wie etwa Customer Relationship Management).
Das JDK ist ein Softwarepaket für Entwickler, das die Java-Laufzeitumgebung (Java Runtime Environment – „JRE“, zu Einzelheiten siehe Abschnitt 3.1.2.) sowie eine Reihe von Bibliotheken mit ihren Programmierschnittstellen, einen Java Compiler und zusätzliche Dateien, die zum Schreiben und Testen von Java Applets und Anwendungen erforderlich sind (z. B. WebStart), enthält.
3.1.2. Die Java-Laufzeitumgebung (Java Runtime Environment)
Die Java-Laufzeitumgebung („JRE“) ist ein Bestandteil der Java-Plattform, das zur Ausführung von Programmen erforderlich ist, die in der Programmiersprache Java geschrieben wurden. Praktisch gesehen ist die JRE das, was Nutzer gewöhnlich herunterladen, um Java auf ihrem Computer zu „installieren“. Die JRE ist Teil des JDK und besteht aus zwei Elementen:
(a) der virtuellen Maschine von Java (Java Virtual Machine – „JVM“). Dabei handelt es sich im Wesentlichen um einen virtuellen Computer, der im realen Computer läuft und der für die Ausführung des Java-Bytecodes verantwortlich ist; und
(b) einer Bibliothekssammlung, welche die in einer zertifizierten JRE zur Verfügung stehenden Funktionalitäten festlegt (beispielsweise komplexe mathematische Formeln oder Funktionalitäten zur Verarbeitung von Datenreihen und Tabellen).
809Unternehmen können entweder eine direkte Lizenz von Sun für die JRE erwerben oder ihre eigene Version der JRE entwickeln, um sie zur Nutzung mit ihrer eigenen Java Anwendungssoftware zu optimieren. Im letzteren Fall muss ein Unternehmen von Sun eine Lizenz für das Java-Kompatibilitätspaket (Java Compatibility Kit – „JCK“) erwerben, ein weiterer Teil der Java-basierten Software, der eine Reihe von Tests enthält, die belegen, dass die unternehmenseigene Version der JRE mit der Java Plattformspezifikation konform ist. Ein Unternehmen ist auf eine solche Zertifizierung angewiesen, denn die Kunden verlangen diese in der Regel, um sicher zu gehen, dass
494Eine Programmierschnittstelle (Application Programming Interface – „API“) zeigt ausführlich, wie ein Programm eine Funktionalität nutzen kann, die bereits programmiert wurde, d. h. eine Funktionalität, die in diesem Fall in eine Java-Bibliothek eingebettet ist. Sie listet dazu alle Funktionen auf, die aus dem neuen Programm abgerufen werden können, legt die Anzahl und die Art der Parameter fest, die diese Funktionen erwarten, und beschreibt deren Rückgabewert(e).
495Im Zusammenhang mit der Computerprogrammierung ist ein Compiler für die Übersetzung eines in einer höheren Programmiersprache wie C++ geschriebenen Computerprogramms in die Maschinensprache der zugrunde liegenden technischen Plattform zuständig. Der Compiler sorgt also dafür, dass das Programm ausgeführt werden kann. Java-Compiler sorgen für die Kompilierung des Java-Quellcodes in Java-Bytecode, d. h. die Sprache der Java Virtual Machine (Java-Bytecode kann direkt auf einer Java Virtual Machine ausgeführt werden).
496Ein Java-Applet ist ein Java-Programm, das nur im Kontext einer Webseite ausgeführt werden kann. Applets sind in der Regel sehr kleine Programme mit einem sehr begrenzten Funktionsumfang.
497Java WebStart ermöglicht die Ausführung von Java Applets unabhängig von einem Webbrowser. WebStart ist ebenfalls Teil der JRE.
498die von ihnen erworbene Software „Java-kompatibel“ ist. Eine Java-Zertifizierung bewirkt eine automatische Lizenzierung aller Rechte am geistigen Eigentum, die für eine Implementierung der Spezifikation der nach JCP erstellten Java-Plattform erforderlich sind, vorausgesetzt, die Inhaber dieser Rechte am geistigen Eigentum waren an der Erstellung als Mitglied der entsprechenden Expertengruppe beteiligt (siehe Randnummer 811 ff.).
499Drei Plattformeditionen der JRE gibt es: (1) Die Java Standard Edition („JSE“), welche die grundlegenden Bibliotheken enthält und eine Java-Plattform zu allgemeinen Zwecken darstellt, die in Desktops, PCs, Servern und ähnlichen Geräten Verwendung finden; (2) die Java Enterprise Edition („JEE“), die im Vergleich zur JSE zusätzliche Funktionalitäten für hochwertige Unternehmensserveranwendungen umfasst; und (3) die Java Micro Edition („JME“) mit dem Schwerpunkt auf mobilen Geräten und eingebetteten Systemen (z. B. Mobiltelefone, Beistellgeräte, so genannte Set-Top-Geräte, sowie Kameras).
811Java wird nach dem Java Community Process („JCP“) entwickelt, einem Verfahren zur Entwicklung und Prüfung von Spezifikationen der Java-Technologie. Das JCP wurde 1998 eingerichtet und besteht aus einer Sammlung bilateraler Verträge (Java Specification Participation Agreements – „JSPA“), die Sun mit den verschiedenen Mitgliedern des JCP (bestehend aus Einzelpersonen, Unternehmen oder anderen Gruppen, die als „Interessengruppen“ in Bezug auf die Java-Entwicklungsplattform betrachtet werden) abgeschlossen hat. Es handelt sich hierbei weder um eine Organisation noch um ein Leitungsgremium von Java, sondern vielmehr um ein partizipatives Verfahren zur Festlegung von Standards rund um Java. Zurzeit besteht es aus 1.200 Mitgliedern. Wichtige Wettbewerber sowohl von Sun als auch von Oracle sind zurzeit in dem JCP vertreten: IBM, SAP AG, Hewlett Packard, Oracle selbst, Cisco Systems, Adobe Systems Inc., RedHat und Unternehmen wie Google, Motorola, Intel (Wettbewerber von Sun im Bereich Mikroprozessoren) und Philips.
498Die Zertifizierung ist wichtig, da nur mit ihr nachgewiesen werden kann, dass die betreffende Java-Implementierung vollständig und korrekt ist, d. h. Java-Software auf gleiche Weise ausführen kann wie alle anderen konformen Implementierungen. Es wäre daher wesentlich schwieriger, eine nicht zertifizierte Java-Implementierung zu verkaufen, da potenzielle Kunden Mängel bei der Konformität befürchten könnten. Konformität spielt für Kunden eine große Rolle, die eine Software mit der Fähigkeit zur Ausführung von Java-Programmen erwerben, da so sichergestellt ist, dass die bestehenden Programme unverändert in der neuen JRE erneut verwendet werden können.
499Wie oben in Erwägungsgrund 788 erläutert, stellt eine Plattform einen Rahmen dar, innerhalb dessen eine Software ausgeführt wird: Er besteht im Allgemeinen aus einer Programmiersprache, einem Compiler und häufig einer umfassenden Bibliothek von Funktionalitäten, die in neuen Programmen verwendet werden können. Im Falle von Java gehört auch eine Laufzeitumgebung dazu, denn Java-Programme wurden nicht für die zugrunde liegende Computerplattform (d. h. die Hardware zusammen mit dem Betriebssystem) kompiliert, sondern für die Java Virtual Machine, also einen in Software implementierten Computer, der in allen unterstützten Computerplattformen gleich ist (d. h. es gibt eine Java Virtual Machine für Windows auf den Intel PCs, für Sun Solaris auf SPARC-Hardware usw.).
Die Referenzimplementierung für das JEE ist GlassFish, der Anwendungsserver von Sun. GlassFish wird unter zwei Open-Source-Lizenzen angeboten (der GPL und der Common Development and Distribution License). Sun vertreibt GlassFish kommerziell (d. h. immer noch als OSS, jedoch zugeschnitten auf Unternehmen mit dem Ziel, verbundene Supportdienstleistungen wie Beratung und Training zu verkaufen) unter dem Namen Sun GlassFish Enterprise Server.
812Ziel des JCP ist es, die Kompatibilität abgeleiteter Entwicklungen sicherzustellen. Insbesondere soll gewährleistet werden, dass Java von jedermann zur Erstellung eines breiten Spektrums von Anwendungen verwendet werden kann (z. B. Datenbanken, Anwendungsservern, E-Mail-Clients, Textverarbeitungsprogrammen, Spiele usw.), die auf mehreren Plattformen laufen (wie Windows, Linux, Unix). So sind beispielsweise Anbieter von Mobiltelefonen und Entwickler von Spielen an einem gemeinsamen Standard für Spiele, die in mobilen Geräten verwendet werden, auf der Grundlage von Java interessiert. Das JCP gewährleistet, dass eine bestimmte Anzahl von Regeln entwickelt, implementiert und (obligatorisch) lizenziert wird, die bestimmen, wie ein bestimmter Typ von Spielen (beispielsweise mit bestimmten audiovisuellen Merkmalen) von allen einschlägigen Inhabern geistiger Eigentumsrechte, die an dem Verfahren beteiligt sind.
813Das JCP wird von zwei Exekutivausschüssen gesteuert (Executive Committee – „EC“), von denen eines für die JSE und die JEE und das andere für die JME zuständig sind. Die Amtszeit der Exekutivausschussmitglieder dauert drei Jahre. Die Hauptaufgabe der JCP-Exekutivausschüsse ist die Anerkennung neuer Java Standards (so genannter Java Specification Requests – „JSR“). Sie sollen gewährleisten, dass neue Entwicklungsspezifikationen sich nicht überschneiden oder im Widerspruch zueinander stehen, und sie sollen prüfen, ob die Spezifikationen die Anforderungen der Wirtschaft erfüllen.
814Jedes Exekutivausschuss besteht aus 16 Mitgliedern. Die derzeitigen Mitglieder des SE- und des EE-Exekutivausschusses sind (alphabetisch geordnet) die Folgenden: Apache, Eclipse, Ericsson, Fujitsu, Google, HP, IBM, Intel, Werner Keil, Doug Lea, Nortel, Oracle, RedHat, SAP, SpringSource und Sun.
815Jedes der 1.200 JCP-Mitglieder kann in einen der Exekutivausschüsse gewählt werden. Für die Ausschussmitglieder gibt es zwei Auswahlverfahren: Ratifizierung und Wahl. Zehn der 16 Ausschussmitglieder werden ratifiziert, fünf gewählt und Sun hat einen ständigen Sitz. Den Vorsitz eines jeden Exekutivausschusses hat ein Mitglied des Programmmanagements (Program Management Office – „PMO“), also ein Mitarbeiter von Sun, inne.
Die ratifizierten Mitglieder (10 von insgesamt 16 Mitgliedern) werden von Mitgliedern des JCP aus den vom PMO vorgeschlagenen Kandidaten gewählt und der Kandidat wird mit der einfachen Mehrheit der Abstimmenden ratifiziert. Werden die Kandidaten in der Abstimmung nicht ratifiziert, schlägt das PMO so lange neue Kandidaten vor, bis die Anzahl der zu besetzenden Sitze erreicht ist.
Die gewählten Mitglieder (fünf von insgesamt 16 Mitgliedern) werden in einer allgemeinen Abstimmung aus den Mitgliedern des JCP gewählt, die sich zur Wahl stellen. Die Kandidaten, die die meisten Stimmen auf sich vereinigen, werden für den zu besetzenden Sitz gewählt.
816Das PMO unterstützt die Mitglieder des JCP. Das PMO ist für das Tagesgeschäft des JCP zuständig und auch für den Vorsitz der JCP-Exekutivausschüsse verantwortlich. Das PMO besteht zurzeit aus sechs Mitarbeitern von Sun.
817Die Hauptaufgabe der Exekutivausschüsse besteht darin, die JSR zu prüfen. Seit dem Start des JCP gab es bereits mehr als 300 JSR. Für jeden JSR sind bestimmte Schritte einzuhalten, die im Folgenden beschrieben werden.
Einleitungsphase: Jedes Mitglied des JCP kann eine neue Spezifikation oder eine wichtige Änderung einer bestehenden Spezifikation vorschlagen. Der Spezifikationsvorschlag, der JSR, wird dem PMO vorgelegt, der ihn dann auf der Webseite veröffentlicht, um Anmerkungen der Öffentlichkeit einzuholen, und ihn dann an den zuständigen Exekutivausschuss zur Prüfung und Genehmigung weiterleitet.
Prüfung des Anfangsentwurfs (Early Draft Review): Wurde der JSR zur Entwicklung angenommen, wird das Mitglied, das den JSR vorgeschlagen hat, zum Spezifikationsführer ernannt und die JCP-Mitglieder berufen eine Gruppe von Sachverständigen (die „Expertengruppe“), die den ersten Entwurf der Spezifikation erarbeitet. Der Erstentwurf wird dann dem JCP und dem Exekutivausschuss zur Prüfung (Early Draft Review) vorgelegt. Der Entwurf kann entsprechend der im Rahmen dieser Prüfung eingegangenen Anmerkungen für den nächsten Schritt weiter ausgearbeitet werden. Jetzt legt der Spezifikationsführer dem Exekutivausschuss die Lizenzbedingungen für die Referenzimplementierung ("RI") und das Technologiekonformitätskit ("TCK") vor. Die Verpflichtung, die Geschäftsbedingungen einer Lizenzvergabe der TCK voranzukündigen, wurde als Bestandteil des neuen JCP-Verfahrens, das am 16. Juni 2009 in Kraft trat, festgelegt. Diese
505Das beinhaltet die Organisation der Sitzungen der Exekutivausschüsse, die Arbeit mit den Specification Leaders („Spezifikationsführer“ siehe unten, Randnummer 192 b) und den Expertengruppen zu verschiedenen JSR, das Führen der Mitgliederlisten für das JCP und die Pflege der JCP-Website (siehe auch http://jcp.org/en/press/pmo/pmo_profiles/commFocusPMO-curran).
506Die Liste aller JSR ist auf der JCP-Webseite unter der folgenden Adresse abrufbar: http://jcp.org/en/jsr/all. Die Liste enthält eine kurze Beschreibung der Spezifikation und den Namen des Spezifikationsführers. Seit 2007 gab es 22 JSR (8 von Sun initiiert) und zwei von ihnen (JSR323 und JSR 324) wurden abgelehnt. Die Ergebnisse der Abstimmungen und die Anmerkungen der abstimmenden Mitglieder des Exekutivausschusses sind unter http://jcp.org/en/jsr/results?id=4601 und http://jcp.org/en/jsr/results?id=4516 abrufbar.
507Die Referenzimplementierung ist eine Musterimplementierung der Spezifikation. Das TCK besteht aus einer Reihe von Tests, die sicherstellen, dass eine bestimmte Implementierung mit der Spezifikation konform ist.
508Siehe http://jcp.org/en/procedures/jcp2. Abschnitt 1.2.1 lautet wie folgt: "Das Unternehmen oder die Organisation des Spezifikationsführers ist für die Referenzimplementierung (RI) und das Technologiekonformitätskit (TCK) verantwortlich sowie für die Lizenzvergabe nach Bestimmungen, die
frühzeitige Bekanntgabe soll es dem Exekutivausschuss ermöglichen, die Bedingungen der Lizenzvergabe bei der Abstimmung über den JSR zu berücksichtigen.
Öffentlicher Entwurf (Public Draft): Der öffentliche Entwurf wird anschließend zur Prüfung durch die Öffentlichkeit bekannt gemacht und jeder kann Anmerkungen zu dem Entwurf abgeben. Sämtliche Kommentare und Anmerkungen der Allgemeinheit können für den vorgeschlagenen endgültigen Entwurf herangezogen werden. Die endgültige Annahme erfolgt durch Mehrheitsbeschluss des Exekutivausschusses. Nach der Annahme wird die endgültige Spezifikation mit der RI und dem TCK verfügbar gemacht und als Teil des Java-Standards veröffentlicht (die Abstimmungsergebnisse sind auf der JCP-Website einsehbar).
818Die Abstimmungsergebnisse der Exekutivausschüsse werden veröffentlicht. JSR sind genehmigt, wenn die Mehrheit mit „Ja“ gestimmt hat, vorausgesetzt, dass mindestens fünf „Ja“-Stimmen vorliegen. Zwei Ausnahmen von dieser Regel gibt es, in denen eine qualifizierte Mehrheit von zwei Dritteln notwendig ist: (a) ein Beschluss, mit dem eine Entscheidung auf erster Ebene über eine TCK-Anfechtung (wenn ein TCK-Nutzer den Spezifikationsführer dazu auffordert, die Zweckmäßigkeit und Richtigkeit eines bestimmten Tests zu erläutern) aufgehoben werden soll; und (b) die Annahme von JSR für neue Spezifikationen der Plattformedition oder von JSR, die Änderungen an der Java-Programmiersprache vorschlagen. Im zweiten Fall muss auch Sun mit „Ja“ stimmen. Sun verfügt also mit anderen Worten über ein Vetorecht hinsichtlich bedeutender Plattformveränderungen (an den „Umbrella Specifications“, also Dachspezifikationen JSE, JEE und JME).
819Alle Änderungen des JCP oder seiner Verfahren unterliegen dem unter Randnummer 817 erläuterten JSR-Verfahren, jedoch mit folgendem Unterschied: Änderungen des JCP oder der JSPA-Dokumente können nur von einem Mitglied des Exekutivausschusses initiiert werden, nicht jedoch von einem Mitglied des JCP. Der Vorschlag wird dann beiden Exekutivausschüssen zur Annahme im üblichen Abstimmungsverfahren vorgelegt.
820In Anhang 1 des Formblatts COführte die Anmelderin Beispiele für Entscheidungen zu JSR und Abstimmungen des Exekutivausschusses seit 2007 an, die nicht das von Sun favorisierte Ergebnis erzielten (Sun stimmte bei JSR291 mit Nein, der Vorschlag wurde jedoch angenommen, bei JSR225 enthielt sich Sun der Stimme und der Vorschlag wurde angenommen).
Die kürzlich mit JCP 2.7 eingeführten Verfahrensänderungen erfolgten inmitten des Streits zwischen Apache und Sun über Apache Harmony (siehe Erörterung unter Randnummer (f) ff.) und der Ernennung von Patrick Curran zum Vorsitzenden des
509mit den Lizenzierungsrichtlinien zur Nutzung im Rahmen des JCP übereinstimmen. Der Spezifikationsführer legt dem EC die Bestimmungen, nach denen das RI und das TCK lizenziert werden, spätestens zu Beginn der JSR-Prüfung vor. Der Spezifikationsführer hat vollständige Kopien der Lizenzen vorzulegen, die genutzt werden sollen, eine Zusammenfassung lediglich einiger Bestimmungen ist nicht ausreichend.
511PMO. Patrick Curran wollte eine Reihe von Veränderungen des JCP in Gang setzen (unter Anderem im Bereich Governance und Transparenz). Die Exekutivausschüsse hatten mehrfach vor der Beilegung des Streits mit Apache geäußert, nicht zu einer Reform des JCP bereit zu sein.2008 kam es jedoch zu einer Reihe von Diskussionen, die schließlich in der Wartungsdurchsicht von JSR215 mündeten, womit die Version 2.7 des JCP-Prozessdokuments eingeführt wurde.
Vor der Implementierung des neuen Verfahrens, das die vollständige Veröffentlichung der Lizenzbedingungen für RI und TCK durch den Spezifikationsführer vor der Annahme einer neuen Spezifikation erfordert, hatten viele Mitglieder der Exekutivausschüsse im Februar 2009 öffentlich erklärt, dass sie diese Bedingungen bei ihrer Abstimmung über die Annahme der endgültigen Spezifikation für die neue Plattformedition von Java EE (JSR 316 für Java EE Version 6) genau verfolgen würden).In der Abstimmung über die öffentliche Prüfung stimmte RedHat mit Ja, merkte jedoch an: „Der Spezifikationsführer der Spezifikation EE6 hat bestätigt, dass EE6 keinerlei Nutzungseinschränkung enthalten wird (...), das ist eine gute Nachricht. In Ermangelung einer ausdrücklichen JSPA-Vorschrift, die dies für einen (von Sun Microsystems oder anderen) vorgeschlagenen JSR untersagt, erwarten wir insbesondere vom Spezifikationsführer, klar über diesen Aspekt informiert zu werden, und wir werden diese Antwort bei unserer Stimmabgabe berücksichtigen.“ [„The spec lead of the EE6 specification has confirmed that the EE6 would contain no field of use restriction […] this is a good thing. However in the absence of an explicit JSPA rule that would forbid [it] […] for any submitted JSR (by Sun Microsystems or not) we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.“] Intel merkte dazu an: „Bis zur endgültigen Abstimmung über die JSR EE6 erwarten wir eine Erklärung, dass die TCK für EE6 die Nutzungsbereiche nicht einschränken und keine Implementierung anderer Elemente erfordern wird, die nicht auch in der Spezifikation selbst erforderlich sind (...) und keine andere Lizenz notwendig machen wird, die die Nutzung der JCP-Spezifikationen einschränken.“ [„By the time EE 6 JSRs come to Final Ballot, we expect a statement that the EE 6 TCK license does not restrict field of use, does not require implementing anything other than what is required in the spec itself […] and does not require any other license that restricts field of use of JCP Specs“].
3.1.4.Geistige Eigentumsrechte und Lizenzierung von Java
Bestimmungen nach den JSPA
823Die zwischen Sun und jedem der JC-Mitglieder unterzeichneten JSPA bestimmen den Rahmen zur Lizenzierung der geistigen Eigentumsrechte an einer bestimmten JSR. Die JSPA werden für die Dauer eines Jahres unterzeichnet und automatisch verlängert, sofern nicht eine der Parteien den Vertrag (mit einer Kündigungsfrist von 60 Tagen) kündigen möchte. Für alle eingeleiteten oder zur Entwicklung genehmigten JSR gibt es jedoch für die Dauer des Vertrags eine Klausel, die das Fortbestehen regelt (Artikel 10 und 13 der JSPA). Die vertraglichen Pflichten der Parteien bleiben bei Kündigung des Vertrags für diese JSR hinsichtlich Abschnitt 4, 5, 6, 9, 11 und 12 der JSPA weiter bestehen.
824Nach Abschnitt 4 der JSPA gewährt jedes JC-Mitglied, das an der Arbeit einer Expertengruppe teilnimmt, dem Spezifikationsführer eine unbegrenzte, vollständig bezahlte und unwiderrufliche Lizenz für die Urheberrechte, Geschäftsgeheimnisse, Patente und sonstige geistige Eigentumsrechte im Zusammenhang mit den Beiträgen dieser Mitglieder zu der Spezifikation. Der Spezifikationsführer erhält also als Lizenznehmer ein ganzes Bündel von geistigen Eigentumsrechten, die zur Implementierung der JSR erforderlich sind.
Im Gegenzug bestimmen die JSPA die Pflichten des Spezifikationsführers hinsichtlich der Art der Lizenzierung der Java-Spezifikationen. Die JSPA bestimmen insbesondere die Bedingungen, nach denen der Spezifikationsführer die Lizenzen der grundlegenden geistigen Eigentumsrechte an Parteien vergibt, die eine Implementierung auf der Grundlage des Quellcodes oder eine unabhängige Implementierung erstellen möchten. In beiden Fällen muss die vom Lizenznehmer neu geschaffene Implementierung den Konformitätstest (TCK) bestehen, um das vollständige Paket an geistigen Eigentumsrechten vom Spezifikationsführer zu erhalten. Solche Konformitätstests werden verlangt, um die Kompatibilität zu bewahren (d. h. sicherzustellen, dass jede Implementierung mit der Spezifikation übereinstimmt). Die wichtigsten Lizenzverpflichtungen in diesen beiden Fällen sind wie folgt:
Unabhängige Implementierung: Die Rahmenbedingungen, nach denen die geistigen Eigentumsrechte des Spezifikationsführers für unabhängige Implementierungen an einen Lizenznehmer übergehen, werden in Artikel 5.B und 5.C der JSPA festgelegt. Der Spezifikationsführer muss Lizenzen der betreffenden Rechte am geistigen Eigentum an jeden vergeben, dessen Implementierung den Konformitätstest besteht (d. h. Lizenzvergabepflicht).Die TCK-Lizenz, auch wenn sie von der RI gesondert ist, unterliegt immer der Verpflichtung zu fairen, angemessenen und nicht diskriminierenden (fair, reasonable and non-discriminatory = "FRAND") Bestimmungen, siehe Artikel 5 F.I. Eine solche Lizenz darf das Recht des Lizenznehmers, die Spezifikation zur Erstellung oder zum Vertrieb einer unabhängigen Implementierung zu nutzen, nicht einschränken.
514Eine auf einer RI basierende Implementierung verwertet Teile des RI-Quellcodes wieder, für den der Lizenznehmer alle geistigen Eigentumsrechte erhält, während der Code einer unabhängigen Implementierung von dem Lizenznehmer von Grund auf neu geschrieben wurde, jedoch basierend auf den Bedingungen der Spezifikation. Unabhängige Implementierungen werden auch „Clean Room“ (Reinraum-) oder „Clone“ (Klon-) Implementierungen genannt.
515In JSPA – Artikel 5.B heißt es: "Dem Spezifikationsführer wird für jede nach einer neuen JSR erstellten Spezifikation das Recht gewährt, eine dauerhafte, nicht ausschließliche, weltweit gültige, vollständig bezahlte, gebührenfreie, unwiderrufliche Lizenz nach deren lizenzierbaren Urheberrechten […] an jeden zu vergeben, der eine unabhängige Implementierung der Spezifikation erstellen und/oder vertreiben möchte. Eine solche Lizenz wird die Erstellung und den Vertrieb unabhängiger Implementierungen gestatten, vorausgesetzt solche Implementationen (a) setzen die Spezifikation(en) einschließlich der erforderlichen Schnittstellen und Funktionalitäten um; (b) bewirken keine Veränderung, Einschränkung, Ausdehnung oder Erweiterung in irgendeiner Form des Namensraums des Lizenznehmers oder beinhalten öffentliche oder geschützte Paketklassen, Java-Schnittstellen, Felder oder Methoden, innerhalb derer der Namensraum des Lizenzgebers anders als in der Spezifikation gefordert bzw. in ihr autorisiert implementiert wird; und (c) die TCK für diese Spezifikation bestehen.
der Art der Lizenz, die mit der unabhängigen Implementierung verbunden ist (siehe Randnummer 831 des vorliegenden Beschlusses)
Implementierung auf der Grundlage der RI: Der Rahmen, innerhalb dessen die geistigen Eigentumsrechte vom Spezifikationsführer auf einen Lizenznehmer für die Implementierung auf der Grundlage des RI übergehen, werden in Artikel 5.F der JSPA geregelt. Der Spezifikationsführer muss RI und TCK zu fairen, angemessenen und nichtdiskriminierenden Bedingungen jeglichen Interessenten anbieten (d. h. Lizenzvergabepflicht). Der Spezifikationsführer kann auch keine zusätzlichen Konformitätshürden einführen. Die Bedingungen der fairen, angemessenen und nicht diskriminierenden Lizenzvergabe sind in Bezug auf bestehende vergleichbare Lizenzen und frühere Lizenzbestimmungen auszulegen.
826Sun ist als Spezifikationsführer der JSE und der JEE-Spezifikationen Inhaber der Urheberrechte beider. Sun war auch Spezifikationsführer für viele wichtige Spezifikationen der Java ME-Plattform, jedoch waren andere Unternehmen wie Nokia, Vodafone, Motorola und andere ebenfalls Spezifikationsführer etlicher Schlüsseltechnologien, die Bestandteil von Java ME sind.
827Um eine eigene JRE zu zertifizieren, muss ein Unternehmen von Sun die Lizenz für ein TCK erwerben. Dasselbe Unternehmen ist möglicherweise am Erwerb einer weiteren Lizenz von einem anderen Spezifikationsführer interessiert, um Zugang zur Funktionalität einer bestimmten Spezifikation zu erhalten. Die Spezifikationen, die von anderen Spezifikationsführern als Sun entwickelt wurden, sind wertvolle Zusatzfunktionen, jedoch zur Entwicklung einer kommerziellen Anwendung nicht unbedingt erforderlich.
3.1.4.2Verfahren zur Lizenzvergabe
828Sun verwendet gegenwärtig vier grundlegende Verfahren der Lizenzvergabe für Java-Technologie.
Zunächst bietet Sun Open-Source-Lizenzen an. So ist beispielsweise das OpenJDK, eine Implementierung der JSE, unter der GPL verfügbar, der zufolge alle weiteren Verteilungen der betreffenden Software in veränderter oder unveränderter Form ebenfalls unter der GPL zu erfolgen haben. Verändert ein Nutzer das JDK (indem er z. B. den Quellcode des Java-Compilers ändert, der den Java-Quellcode in den Java-Bytecode, der auf der JVM läuft, übersetzt, was zu schnelleren Kompilationen und zu Bytecodes von geringerem Umfang führt) und möchte dieses weiterverteilen, muss er den veränderten Quellcode ebenfalls unter der GPL zur Verfügung stellen. Diese
Bedingung gilt für Veränderungen am JDK selbst, jedoch nicht für Programme, die mit dem OpenJDK geschrieben wurden, d. h. einem Programm, das in Java geschrieben und mit dem Java-Compiler des OpenJDK kompiliert wurde. Dieses kann in dieser Form verteilt werden, also in dem Bytecode mit oder ohne den begleitenden Quellcode, ohne die Anforderung, bestimmte Lizenzen oder Lizenzbedingungen anzuwenden.
Zweitens bietet Sun eine kommerzielle Lizenz an, für die der Lizenznehmer von Sun Folgendes erhält: (i) die Implementierungen des Quellcodes für eine oder mehrere Java-Spezifikationen (namentlich die RI des Spezifikationsführers); (ii) die entsprechenden Spezifikationen selbst; (iii) die TCK und (iv) eine gewisse technische Unterstützung. Einige Java-Technologien enthalten als Teil der kommerziellen Vereinbarungen Lizenzen für Marken, um kompatible Implementierungen zu kennzeichnen (also das Recht, ein Produkt als „Java-kompatibel“ zu kennzeichnen). Unternehmen, die eine solche Lizenz suchen, wären in der Lage, die entsprechende RI als Ausgangspunkt zu verwenden, von dem aus sie den Quellcode verändern und damit ihre eigene Implementierung erstellen (Lizenznehmer können sich jedoch auch dafür entscheiden, eine neue Implementierung von Grund auf neu zu erstellen, also ohne Nutzung des Quellcodes der RI). Unternehmen wie Oracle, IBM, SAP und Nokia verfügen über kommerzielle Lizenzen. Der SE-Quellcode steht kostenlos zur Verfügung, die binäre Weiterverteilung ist jedoch gebührenpflichtig für Nutzungen, die über Desktop-Computer oder Server zu allgemeinen Zwecken hinausgehen. Es gibt drei verschiedene Arten kommerzieller Lizenzen: Technology License and Distribution Agreement (TLDA), Sun Community Source License (SCSL) und Java Development License (JDL). Von der kommerziellen Lizenz von Sun gibt es unterschiedliche Versionen, TLDA war die erste und JDL ist die neueste. Die JDL sollte eine Lizenz mit einer einfacheren Sprache anbieten, fand jedoch keine breite Nutzung, da Sun das OpenJDK ungefähr um die gleiche Zeit freigab.
Drittens bietet Sun eine Mischung von gebührenfreien und kommerziellen Lizenzen für unabhängige Implementierungen an. In diesen Fällen möchte der Lizenzgeber die Java-Spezifikationen implementieren, jedoch keine Lizenz für die entsprechende Implementierung erwerben. Die Spezifikationen selbst stehen zur Lizenzierung zur Verfügung, typischerweise ohne Gebühr, für die entsprechenden TCK müssen dann jedoch üblicherweise Lizenzen auf kommerzieller Basis erworben werden. Unternehmen wie Apache, RMI und ObjectWeb erstellen unabhängige Implementierungen von Java-Spezifikationen.
Viertens bietet Sun gebührenfreie Lizenzen für Binärversionen der Java-Laufzeitumgebung (JRE) und des Java-Entwicklungskits (JDK) an. Binärversionen der JRE und des JDK sind kostenfrei bei Sun erhältlich. „Binär“ bedeutet, dass diese Programme in ihrer „ausführbaren“ oder betriebsbereiten Form geliefert werden, ohne dass der Nutzer Kompilierungen oder Veränderungen durchführen muss (oder kann). Die Binärversionen für die RI können in ein Produkt integriert werden, in diesem Fall ist jedoch kein TCK erforderlich, da die RI nicht verändert wurde.
Sun bietet das Binary License and Redistribution Agreement (BLRA) an, eine Lizenz zur OEM-Weiterverteilung des Binärcodes für Programme, die auf Sun Java ausführbar sind (JRE/J2SE und bestimmte Java-ME-Implementierungen). Nach dem BLRA muss die Sun-Implementierung vollständig und unverändert verwendet werden. Das BLRA findet in erster Linie zusammen mit kommerziellen Lizenzen gegen eine Gebühr Anwendung, wird jedoch auch für den Nutzungsbereich der freien „allgemeinen EDV“ JRE/J2SE genutzt (siehe Randnummer 831).
TCK-Lizenzen werden im Allgemeinen in Verbindung mit breiter gefassten kommerziellen Verträgen vergeben, welche die Nutzung der geistigen Eigentumsrechte und der Dienstleistungen von Sun zusätzlich zur Nutzung der TCK beinhalten. Bei diesen Vereinbarungen kann es sich um eine TLDA (Technology License and Distribution Agreement) oder SCSL (Sun Community Source License) handeln, die in der Regel mit der Implementierung und dem Support von Sun zusammengefasst ist („gebündelte Lizenz“). Für unabhängige Implementierungen stellt Sun „Einzellizenzen“ für TCK zur Verfügung („Einzel“, da die TCK ohne die RI und ohne jegliche zusätzliche Leistungen lizenziert wird). Die Einzellizenzen für TCK stehen gemeinnützigen Unternehmen kostenlos und allen sonstigen Unternehmen gegen Gebühr zur Verfügung.
3.1.4.3Fälle, in denen eine TCK-Lizenz erforderlich ist
835Diese Diskussion zeigt, dass TCK-Lizenzen hauptsächlich in zwei Fällen erforderlich sind: ein Anbieter möchte (a) die RI modifizieren oder (b) eine unabhängige (also nicht auf dem Quellcode der RI aufbauende) Implementierung erstellen und die Produkte als kompatibel mit Java SE, Java EE oder Java ME gekennzeichnet vertreiben. Jedes Unternehmen, das Anwendungen in Java entwickelt (d. h. alle Arten von Software, die Funktionalitäten direkt für den Endnutzer bereithalten), kann seine Programme frei verteilen, ohne eine TCK-Lizenz erwerben zu müssen. Der Grund dafür ist der, dass sie den Quellcode der RI weder nutzen noch verändern und auch keine vollständig neue Implementierung der betreffenden Spezifikation erstellen, damit auch keinen TCK durchlaufen müssen, um die Kompatibilität nachzuweisen. Diese Unternehmen müssen keine Lizenz für das geistige Eigentum von Sun erwerben.
836Im Falle von Java SE ist die am weitesten verbreitete Implementierung die binär ausführbare RI, die auch unter der Bezeichnung Sun HotSpot JVM bekannt ist. Die HotSpot JVM ist die Grundlage der JRE, die zur Ausführung der Java-Anwendung verwendet wird. Anbieter von Anwendungen können sowohl die HotSpot JVM als auch die JRE kostenfrei erhalten, wenn sie diese zusammen mit ihrem Softwareprodukt als Paket vertreiben wollen. Nur wenige Unternehmen modifizieren die JRE zum Zwecke der Unterstützung von Desktop-Programmen (wie etwa für Webbrowser, die in Java geschrieben sind, oder um die Webbrowser in die Lage zu versetzen, Java-Applets auszuführen), da die von Sun erhältlichen Implementierungen für die Zwecke gewöhnlich ausreichen. Es gibt daher nur sehr wenige Lizenznehmer des Java SE TCK. Anbieter wollen unter Umständen die Java SE RI modifizieren, um die JVM für die spezifische, von ihnen angebotene Prozessorarchitektur zu optimieren (im Falle von Serveranbietern) oder die JVM an die spezifischen Konfigurationen anzupassen (im Falle der sonstigen Anbieter). Beispiele für Serveranbieter, die die Java SE RI modifiziert haben, sind IBM, wo man für die eigenen Großrechner und PowerPC-Prozessoren eine optimierte JVM erstellte, und HP, das für seine PA-RISC-Architektur eine optimierte JVM baute.
837Im Falle von Java EE wird eine TCK-Lizenz hauptsächlich von Anbietern von Anwendungsservern verwendet, die sich für eine Modifizierung des Quellcodes der RI entschieden haben oder selbst eine vollständig neue Implementierung bauen, um ihren Anwendungsserver im Hinblick auf die Leistung, Skalierbarkeit, das Clustering, das Transaktionsmanagement, Message Queuing und andere Parameter von anderen abzuheben. Die Notwendigkeit, Veränderungen an der Java EE RI vorzunehmen, erklärt sich durch die Tatsache, dass es sich bei der RI (GlassFish von Sun) um einen voll funktionsfähigen, kommerziellen Anwendungsserver handelt und nicht – wie im Falle der Java SE JVM – lediglich um eine Komponente eines größeren Produkts. Anbieter von Anwendungsservern (wie Oracle oder IBM) benötigen in der Regel eine Lizenz für Java EE TCK. Einige wenige Befragte, die auf dem Middleware-Markt tätig sind, bestätigten in der Marktuntersuchung, dass die von Sun gelieferte „Basis“-RI für den Grad der Komplexität und Differenziertheit ihres Produkts nicht ausreichend ist.
3.1.4.4Einschränkungen der Nutzungsbereiche
Einige TCK-Lizenzen enthalten so genannte „Einschränkungen der Nutzungsbereiche“ (Field of Use Restrictions – „FOUR“), die dem Lizenznehmer bei der Verwendung der Implementierungen, deren Kompatibilität mit der Java-Spezifikation durch TCK getestet wird, Einschränkungen auferlegen. So kann in einer Lizenz zum Beispiel bestimmt werden, dass der Lizenznehmer getestete Implementierungen von Java SE nicht zur Nutzung auf Mobilgeräten zur Verfügung stellen darf. Die Anmelderin gibt an, dass mit dieser Vorgehensweise die Einheitlichkeit der Java-Implementierung für jede Java-Umgebung sichergestellt werden soll. Nutzungseinschränkungen (FOUR) schaffen Abgrenzungen zwischen den Plattformen (JSE, JEE und JME). Solche Einschränkungen sorgen beispielsweise dafür, dass auf Java-fähigen Mobilgeräten ausschließlich JME installiert wird und daher die Anbieter von JME-basierten Anwendungen sicher sein können, dass ihre Anwendung nur einmal geschrieben werden muss und auf allen Java-fähigen Mobilgeräten ausgeführt werden kann. Könnte Sun die Nutzung von JSE-Implementierungen auf mobilen Endgeräten nicht verhindern, so könnten Hersteller damit beginnen, JSE anstelle von JME auf mobilen Endgeräten zu installieren. Dies würde zu zweierlei Auswirkungen führen: a) Sun würde die Möglichkeit verlieren, ein Entgelt für die Nutzung von JME auf mobilen Endgeräten zu verlangen, da die Gerätehersteller eine potenziell freie Alternative zu JSE hätten, und b) Anwendungsentwickler könnten sich aufgrund der Unterschiede zwischen JSE und JME nicht sicher sein, dass alle Anwendungen auf allen mobilen Endgeräten laufen. Die Anziehungskraft von Java als Anwendungsplattform für mobile Endgeräte wäre infolge einer solchen Aufsplitterung stark beeinträchtigt.
839Sun hat bei Java SE stets zwischen allgemeiner und eingebetteter Verarbeitung unterschieden. In der Praxis zahlen Lizenznehmer von Java SE für die allgemeine Datenverarbeitung keine Gebühren, zur Weiterverteilung des Quellcodes von Java SE für „eingebettete Nutzung“ wird jedoch eine Gebühr verlangt. Das Ziel der „Bedingung zu allgemeinen Datenverarbeitungszwecken“ stellt einen Schutz für Sun dar, um Lizenzgebühren für eingebettete Nutzungen von Java SE verlangen, die Kompatibilität von Java ME gewährleisten und Lizenzgebühren für Java ME verlangen zu können.
841Die Einschränkung des Nutzungsbereichs in der Lizenz für Java EE würde eine funktionale Beschreibung des betreffenden Softwareprodukts bzw. der betreffenden Reihe von Softwareprodukten bedingen. Eine Lizenz für das Java EE TCK könnte beispielsweise festlegen, dass die Lizenz für das TCK nur zum Testen der Kompatibilität eines bestimmten Produkts X des Lizenznehmers vergeben wird, das den Java EE Standard implementiert, sie könnte auch festlegen, dass diese Implementierung nicht in mobilen Endgeräten genutzt werden darf. Java EE wird im Allgemeinen für Anwendungsserversoftware, Webserversoftware und ähnliche Softwareprodukte lizenziert, deren Charakter bereits den Nutzungsbereich eingrenzen.
Java ME deckt ein großes Spektrum an Anwendungen ab und Sun hat Einschränkungen des Nutzungsbereichs auferlegt, um seine Lizenzbedingungen für die unterschiedlichen Nutzungen von Java ME anzupassen. Sun kann so die Entwicklung neuer Technologien fördern, gleichzeitig jedoch Lizenzeinnahmen aus etablierten kommerziellen Nutzungen erzielen. So enthalten Java ME Lizenzen Bestimmungen zu Nutzungsbereichen, die zwischen PDA, Blu-Ray-DVD-Spielern, Smart Phones, Set-Top-Geräten usw. unterscheiden.
3.2Klagen Dritter – Risiko der Abschottung auf dem Vorleistungsmarkt („Input Foreclosure“)
843Beschwerdeführer haben der Kommission ihre Beobachtungen zu den möglichen wettbewerbsschädigenden Auswirkungen des geplanten Zusammenschlusses in Bezug auf Java vorgetragen. Sie beklagen das Risiko, dass Oracle nach dem Zusammenschluss eine Strategie der Abschottung auf dem Vorleistungsmarkt fahren wird, indem es zum Nachteil seiner nachgelagerten Wettbewerber auf den Märkten für Middleware und EAS die Kontrolle über Java ausübt. Einige Befragte der Marktuntersuchung äußerten ähnliche Befürchtungen. Die unter der folgenden Randnummer erörterten potenziellen Missbrauchstatbestände umfassen sowohl die von den Beschwerdeführern als auch von einigen Befragten der Marktuntersuchung geäußerten Beschwerden.
Die Beschwerdeführer tragen in Bezug auf Java folgende Beschwerden vor:
(a) Java stellt für Softwareentwickler einen bedeutenden Inputfaktor dar (so ist dies insbesondere die einzige plattformübergreifende Softwareentwicklungstechnologie im Gegensatz zu .NET, die nur auf Windows-basierten Systemen verfügbar ist).
(b) Oracle wäre in der Lage, den JCP zu kontrollieren und ihn so zu lenken, dass er Oracle begünstigt (ähnlich wie Sun den Behauptungen zufolge den JCP zum eigenen Vorteil kontrolliert hat). Aufgrund seines ständigen Sitzes, seiner Kontrolle über das PMO und der Mehrheit der Stimmen in beiden Exekutivausschüssen wäre Oracle dann außerdem in der Lage, Entscheidungen des JCP in eine für sich selbst vorteilhafte Richtung zu „lenken“.
(c) Oracle hätte die Möglichkeit, nachgelagerte Wettbewerber zu benachteiligen, in dem es die Lizenzierung von Java an seine nachgelagerten Wettbewerber verknappt (durch die Verweigerung der Lizenz, durch Beschränkungen der Lizenzen, Änderung der Anforderungen seiner TCK-Lizenz, durch die Verzögerung der Verfügbarkeit von Java-Lizenzen für Wettbewerber, durch eine technische Benachteiligung der Wettbewerber, die gezielte Auswahl der zu zertifizierenden Produkte, durch die Verzögerung der Zertifizierung oder durch eine Preiserhöhung der Java-Lizenzen).
(d) Oracle könnte die Entwicklung neuer Java-Spezifikationen zum ausschließlichen Vorteil der eigenen Software fördern, wodurch die Software der nachgelagerten Wettbewerber von Oracle an Effizienz oder Wettbewerbsfähigkeit einbüßen würde. Insbesondere die „Steuerung“ des JCP gibt dem fusionierten Unternehmen die Möglichkeit, bestimmte Projekte entweder zu beschleunigen oder zu verzögern sowie zu entscheiden, wer in den Vorsitz eines Ausschusses, der die Richtung des Standards festlegt, gewählt wird.
(e) Oracle hätte einen größeren Anreiz als Sun, den JCP zum eigenen Vorteil zu lenken und sich selbst gegenüber seinen nachgelagerten Wettbewerbern zu begünstigen, weil es im Gegensatz zu Sun eine starke Präsenz auf den Anwendungsmärkten besitzt und weil Sun Software als Motor zur Steigerung der Hardwarenachfrage einsetzte, wohingegen Oracle in erster Linie ein Softwareunternehmen ist.
(f) Was die Auswirkungen solcher möglicher Strategien auf den Markt betrifft, würde es vermutlich zu einer erheblichen Beeinträchtigung der Wettbewerbsfähigkeit nachgelagerter Wettbewerber von Oracle kommen, wenn das neue fusionierte Unternehmen eine Strategie der Marktabschottung zu deren Nachteil einschlägt. Die Beeinträchtigung des Wettbewerbs auf den Märkten für Middleware und EAS würde schließlich zu einem Preisanstieg und einer Verringerung der Innovationen für Kunden führen.
Die Beschwerden von Dritten sowie die Befragten der Marktuntersuchung verwiesen auf den Apache-Harmony-Streit als Beispiel für die Möglichkeiten und das Interesse von Oracle, nach dem Zusammenschluss eine dieser unterschiedlichen Marktabschottungsstrategien einzuschlagen.
Die Apache Foundation ist eine nicht auf Gewinn ausgerichtete Organisation zur Unterstützung der Entwicklung von Open-Source-Software. Apache verfolgt den Zweck, auf der Grundlage eines gemeinschaftlichen Prozesses freie Softwareprodukte für Unternehmen zu entwickeln und anzubieten und diese Nutzern unter der „pragmatischen“ Apache-Lizenz zur Verfügung zu stellen. Apache möchte seine eigene, unabhängige, lizenzfähige Implementierung der Java-SE-Spezifikation, die Harmony genannt wird, entwickeln.
Der Apache-Harmony-Streit betrifft die Beschränkungen des Nutzungsbereichs, die Sun in Bezug auf die Lizenzvergabe für das JCK auferlegt hat, welche erforderlich ist, um die eigene Implementierung des J2SE von Apache zertifizieren zu lassen.
Im September 2008 schlug Sun Bedingungen für eine Einzel-TCK-Lizenz vor, die wie folgt lauteten: „Dem Lizenznehmer ist die Nutzung der mit diesem Vertrag erworbenen TCK-Lizenz ausschließlich (a) auf Servern zu allgemeinen Zwecken und (b) auf Desktop- und Laptop-Computern zu allgemeinen Zwecken gestattet, um die Implementierung der Java SE 6 Spezifikation des Lizenznehmers zu testen.“ [„Licensee can only use the TCK licensed hereunder on (a) general purpose servers and (b) general purpose desktop and laptop computer to test Licensee's implementation of the Java SE 6 specification.“] Diese Bedingungen sahen außerdem vor, dass nachgelagerte Produkte (also Server, Desktop- oder Laptop-Computer, die nicht zu allgemeinen Zwecken dienen), die von Apache-Lizenznehmern oder -Unterlizenznehmern vertrieben werden und auf Harmony basieren oder davon abgeleitet wurden, erneut gegen die geltende Java TCK getestet werden.
Die Anmelderin beschreibt den Streit als branchenübliche Verhandlung zwischen Sun (dem Lizenzgeber) und Apache (dem Lizenznehmer) über die Möglichkeit, die Apache nach den Abschnitten 5.F.III und 5.B der JSPA zur Verfügung stehen, seinen eigenen Kunden Produkte zu liefern, die unter Verwendung der gebührenfreien Java SE Lizenzen erstellt wurden (nach denen Apache laut JSPA als nicht gewinnorientierte Organisation gilt), wobei zu den Kunden auch die Unterstützer des Apache-Projekts gehören, wie IBM, Intel, Microsoft, Google und andere, welche damit die Notwendigkeit umgehen, selbst Java-Lizenzen zu erwerben. Laut Anmelderin würde eine Zustimmung zu den von Apache geforderten Lizenzbedingungen (d. h. ohne die Beschränkung der Nutzungsbereiche) dazu führen, dass (a) die Einkommensquelle aus Java SE versiegen würde (da ausschließlich kommerzielle Lizenzen für kommerzielle eingebettete Nutzungen im Gegensatz zu der gebührenfreien Lizenzvergabe von Java SE für allgemeine Datenverarbeitungszwecke gewährt werden), und dass (b) die Einkommensquelle aus Java ME versiegen und die Kompatibilität vernichtet würde (da die Vereinbarung Hersteller von mobilen Endgeräten unverzüglich dazu veranlassen würde, auf Harmony/Java SE umzusatteln, was zu einer Zersplitterung von Java ME führen würde, da Java ME und SE nicht kompatibel sind). Außerdem entrichten alle Lizenznehmer von Sun für die eingebettete Nutzung von Java SE eine Lizenzgebühr, während Apache eine kostenfreie Lizenz erwerben möchte, die seinen kommerziellen Unterstützern zu Gute käme. Das würde eine Benachteiligung der derzeitigen Lizenznehmer von Sun für Java SE zur eingebetteten Nutzung bedeuten.
850Es ist keine Stellungnahme der Kommission in der Angelegenheit des Streits erforderlich, da dieser Streit zwischen den betroffenen Parteien noch anhängig ist und auf einer ganz spezifischen Sachlage beruht. Die Kommission hat ihn jedoch bei der Beurteilung dessen berücksichtigt, inwieweit das fusionierte Unternehmen dazu in der Lage ist und inwiefern es dazu einen Anreiz hat, eine Abschottung auf dem Vorleistungsmarkt zu bewirken.
3.3Einschätzung der Kommission zu dem Risiko der Abschottung auf dem Vorleistungsmarkt
851Die verschiedenen Elemente, auf denen die Missbrauchstatbestände der vertikalen Abschottung beruhen ((a) bis (f) unter Randnummer. 844), wurden angesichts der Ergebnisse der Marktuntersuchung analysiert.
852Die Analyse der Kommission führt zu dem Schluss, dass der geplante Zusammenschluss im Hinblick auf die Lizenzvergabe für Rechte an geistigem Eigentum in Bezug auf die Java-Entwicklungsumgebung und auf die nachgelagerten Gesamtmärkte für Middleware und für EAS keine erhebliche Beeinträchtigung des wirksamen Wettbewerbs auf dem Gemeinsamen Markt darstellen würde.
3.3.1Lizenzierung von geistigen Eigentumsrechten an Java als bedeutender Inputfaktor
853Oracle erwirbt durch den Zusammenschluss die wichtigsten geistigen Eigentumsrechte an der Java Entwicklungsplattform (insbesondere an Java SE, Java EE und Java ME).
Etliche Wettbewerber von Oracle erwerben zurzeit Lizenzen für geistige Eigentumsrechte (entweder kommerzielle Lizenzen oder Lizenzen für Binärversionen der betreffenden Spezifikation) an Java von Sun, um ihre Middleware- und EAS-Anwendungen zu entwickeln.
854Die Marktuntersuchung bestätigte, dass Java-Lizenzen einen bedeutenden Inputfaktor für Softwareprogrammierer darstellen. Die im Zuge der Marktuntersuchung eingegangenen Antworten betonen die einzigartigen Merkmale von Java als Entwicklungsplattform (universell bekannte Sprache, Plattformunabhängigkeit, branchenüblich, leichte Programmierung, Webzentriertheit). Java verfügt über grundlegende Unterscheidungsmerkmale, weshalb es eine starke Alternative zur proprietären .NET-Plattform von Microsoft darstellt. Andere Programmiersprachen (C, C++, C#, PHP) oder Entwicklungsplattformen werden von gut der Hälfte der Befragten als mögliche Alternativen zu Java genannt (insbesondere C# in Kombination mit der .NET-Plattform). Diese Alternativen sind jedoch im Allgemeinen zu wenig flexibel, nicht so einfach in der Nutzung oder auch nicht so anpassungsfähig und verfügen nicht über die aktive Unterstützung der Community wie Java.
855Unbedingt zu beachten ist die Ansicht der meisten Befragten, wonach die Bedeutung von Java in seinem weit verbreiteten standardisierten Ansatz liegt, der den entscheidenden Faktor seiner Stärke gegenüber der proprietären .NET-Plattform darstellt.
856Einige Befragte der Marktuntersuchung sind Lizenznehmer der geistigen Eigentumsrechte an Java, stehen jedoch im Bereich Middleware nicht im direkten Wettbewerb mit Oracle. Es gibt Anbieter von Betriebssystemen wie Google (Android OS für mobile Endgeräte), Unternehmen, die Lizenzen der JME JRE zur Einbettung in mobilen Endgeräten erwerben, damit diese auf Java-Anwendungen laufen können (France Telecom, Motorola oder Sony Ericsson) oder EAS-Wettbewerber wie Q3, Salesforce, SAGE, Infor, SAS, Avaya und QAD. Ein EAS-Anbieter würde in der Regel die binäre (kostenlose) Version der JRE erwerben (siehe Randnummer 832), um diese gemeinsam mit seinem Softwareprogramm zu versenden, damit seine Kunden das Programm auf seinem System ausführen können. Die Marktuntersuchung zeigte auch, dass einige EAS-Anbieter keine Lizenz für die JRE erwerben, sondern ihre Kunden bitten, diese gesondert (kostenlos) herunterzuladen. Daher erscheint jede mögliche Abschottungsstrategie, die Oracle einschlagen könnte, von begrenzter Auswirkung auf die nachgelagerten EAS-Wettbewerber, da diese nur eingeschränkt von den kommerziellen Java-Lizenzen abhängig sind.
Andererseits wird aus den Antworten der Konkurrenten von Oracle im Middleware-Segment deutlich, dass die Wettbewerber von Oracle im Bereich Middleware-Produkte kommerzielle Lizenzen benötigen (siehe Randnummer 827) für das Java Technology Compatibility Kits (TCK) – entweder zur Modifizierung des Quellcodes einer Referenzimplementierung oder für die unabhängige Implementierung, um die Softwareprodukte, deren Kompatibilität mit den Spezifikationen der Java-Plattform zertifiziert wurden, kommerziell vertreiben zu können (das ist insbesondere für Anwendungsserversoftware von Bedeutung). Es herrscht eine Nachfrage nach kommerziellen Lizenzen bei den nachgelagerten Wettbewerbern im Markt für Middleware, die ihre eigenen Implementierungen (oder Verbesserungen bestehender Implementierungen) der betreffenden Java-Technologie entwickeln müssen, da die frei verfügbaren Versionen der Implementierungen von J2EE-Middleware-Produkten (OpenJDK oder Binärversionen) für ihre Zwecke nicht ausreichend sind.
857Wettbewerber von Oracle, die zurzeit Java-Lizenznehmer und mögliche Leidtragende der Abschottung sind
858Die wichtigsten Wettbewerber von Oracle, die zurzeit Lizenzen von Sun zur Entwicklung und Weiterverteilung ihrer Produkte benötigen, werden unter den folgenden Randnummern zusammen mit ihren aktuellen Lizenzvereinbarungen aufgeführt. Hierzu muss man die aktuellen Lizenzvereinbarungen, die diese Unternehmen mit Sun abgeschlossen haben, sowie das Ausmaß ihres Zusammenspiels im Wettbewerb mit Oracle kennen. Je schärfer der Wettbewerb zwischen Oracle und einem Konkurrenten ist, desto größer wird der Anreiz, diesen Rivalen abzuschotten, da eine solche Abschottung dazu führen wird, dass mehr Kunden von den Softwareangeboten des Wettbewerbers auf Oracle-Produkte umschwenken.
859IBM – IBM ist der größte Lizenznehmer von Java und gleichzeitig der wichtigste Konkurrent von Oracle im Bereich Middleware (Oracle und IBM stehen sich auch in anderen Märkten als Konkurrenten gegenüber). Sun und IBM haben im Oktober 1996 ein TLDA mit einer Laufzeit von 20 Jahren miteinander abgeschlossen (d. h. es läuft in sieben Jahren ab, im Oktober 2016). IBM ist daher für die Dauer von sieben Jahren vor jeglichen Änderungen der Lizenzbedingungen geschützt. Das umfasst auch neue Versionen der Java-Plattformen, die IBM jährlich mit einer entsprechenden Frist kündigen kann, während Sun lediglich aus wichtigem Grund kündigen kann. IBM benötigt eine Java EE TCK-Lizenz, da es WebSphere anbietet, eine unabhängige ("Reinraum") Implementierung der Java EE Plattformspezifikation. IBM ist Mitglied des JCP-Exekutivausschusses für Java SE/EE.
860SAP ist ein bedeutender Wettbewerber von Oracle im Bereich Unternehmensanwendungen, aber auch Konkurrent im Bereich Middleware. SAP verfügt über SCSL-Lizenzen für Java SE (insbesondere für die JRE), Java EE und Java ME. All diese Lizenzen laufen in drei Jahren aus (Oktober 2012). SAP genießt Schutz vor einer Änderung der Lizenzbedingungen für weitere drei Jahre. SAP erläutert, dass es die Lizenz der JRE erworben hatte, um seinen Kunden volle Garantie zu geben (da das Herunterladen der JRE von Sun diesen Kunden nicht direkt eine volle Garantie von Sun gewährleistet) und weil die JVM von Sun nur zwei von 16 Betriebssystemplattformen, die SAP unterstützen, unterstützt wird (Intel und Sparc). SAP hatte daher beschlossen, den JVM-Code von Sun in die SAP-Software einzubetten, und portierte ihn auf die 16 Betriebssysteme, die SAP unterstützt. SAP erwarb die Lizenz für Java EE TCK, um seine eigene Implementierung auf der Grundlage der Java EE-Spezifikationen zu entwickeln, insbesondere seine Anwendungsplattform NetWeaver, die auf Java basiert. SAP ist Mitglied des JCP-Exekutivausschusses für Java SE/EE.
861RedHat ist ein Open-Source-Unternehmen und Wettbewerber von Oracle im Bereich Middleware. Sein Produkt JBoss ist ein vollständiger Java-EE-Anwendungsserver, und es bietet auch ein Java-EE-Entwicklungswerkzeug an. RedHat verfügt über eine Einzel-TCK für Java EE, die im November 2010 ausläuft. Es verfügt auch über eine dauerhafte Operating System Distribution License für Java SE.
862Sybase ist ein Wettbewerber von Oracle im Bereich Middleware. Es bietet einen kompletten Java EE Anwendungsserver, genannt Jaguar, und ein Java-EE-Entwicklungswerkzeug an. Die Java TLDA von Sybase läuft im Mai 2013 aus.
863Tibco, Kabira und Novell sind kleinere Wettbewerber im Middleware-Segment mit einer Lizenz für JRE von Sun.
864Fujitsu ist ein kleinerer Wettbewerber von Oracle im Middleware-Segment. Fujitsu verfügt über etliche Lizenzen von Sun: Java ME, Java SE und Java EE sind allesamt dauerhaft verlängerte TLDA, die jährlich automatisch verlängert werden. Der Anwendungsserver von Fujitsu wird Interstage genannt. Fujitsu benötigt auch die Java SE TCK-Lizenz für Produkte, die gegenwärtig nicht mit Oracle konkurrieren. IBM ist Mitglied des JCP-Exekutivausschusses für Java SE/EE.
865Siemens (über seine Tochtergesellschaft Cinterion Wireless Modules) verkauft Software für Produktlebenszyklusmanagement mit Java-Fähigkeiten. Siemens ist daher allenfalls in einem sehr spezifischen Untersegment des gesamten Softwaremarkts aktiv und sein Produkt gilt nur als „Middleware“ für ganz spezifische Kundenanwendungen. Siemens steht auf dem allgemeinen Markt für Middleware nicht mit Oracle oder IBM im Wettbewerb. Siemens ist Mitglied des JCP-Exekutivausschusses für Java ME und hat Java ME als Lizenz von Sun mit einer TLDA, die in diesem September ausläuft, erworben.
866Einige andere Wettbewerber von Oracle benötigen eine Java EE TCK-Lizenz, da sie Anwendungsserver anbieten. Dabei handelt es sich nach den von der Anmelderin vorgelegten Angaben um folgende Anbieter: Borland (verkauft Borland AppServer), Caucho Technologies (verkauft den Resin-Anwendungsserver, der auf Servlet-Funktionalität beschränkt ist), Hitachi (verkauft einen kompletten Java EE Anwendungsserver unter dem Namen Cosminexus), IronFlare (verkauft einen kompletten Java EE Anwendungsserver, der zuvor Orion Anwendungsserver genannt wurde) und NEC (verkauft einen kompletten Java EE Anwendungsserver unter dem Namen WebOTX).
867Die Marktuntersuchung bestätigte weitgehend, dass die Wettbewerber von Oracle im Bereich Middleware-Produkte kommerzielle Lizenzen für Java Technology Compatibility Kits (TCK) benötigen, um Software zu vertreiben, deren Kompatibilität mit der Java-Plattformspezifikation zertifiziert wurde (insbesondere für Anwendungsserversoftware).
3.3.2Kontrolle des JCP und folglich der Lizenzvergabe der geistigen Eigentumsrechte an Java durch Oracle
868Die Möglichkeit, eine Abschottungsstrategie zu betreiben, hängt entscheidend von dem rechtlichen und verfahrensrechtlichen Rahmen ab, innerhalb dessen das JCP arbeitet und an das Oracle nach dem Zusammenschluss gebunden sein wird.
869Die Beschwerden und Angaben der im Rahmen der Marktuntersuchung Befragten beruhen auf der Annahme, dass Oracle, nachdem es die Kontrolle über Sun erworben hat, auch das JCP kontrollieren würde und folglich auch die Lizenzvergabe von geistigen Eigentumsrechten in Verbindung mit Java, insbesondere der TCK.
870Diese Befürchtungen beruhen auf den folgenden kumulativen oder alternativen Annahmen: (i) Oracle würde die Kontrolle über das PMO ausüben (siehe Randnummer 810) und somit als „Zugangskontrolle“ für alle neuen Spezifikationen der Plattformen auftreten, die von seinen Wettbewerbern vorgeschlagen werden könnten. (ii) Es würde Einfluss auf das Abstimmungssystem innerhalb der Exekutivausschüsse nehmen (über seinen Dauersitz und eine „Stimmenmehrheit“ – siehe Randnummer 808), so dass es stets über eine Stimmenmehrheit verfügt, daher das gesamte Verfahren zu seinem eigenen Vorteil „steuern“ würde. (iii) Da die Exekutivausschüsse nur über neue Spezifikationen abstimmen können, hätte Oracle die Möglichkeit, Java zu seinem eigenen Vorteil außerhalb des JCP-Rahmens zum Nachteil seiner Wettbewerber und/oder der gesamten Community zu entwickeln. (iv) Da es über ein Vetorecht bezüglich der Entwicklung jeglicher Dachspezifikationen und jeglicher Modifikationen der das JCP bestimmenden Regeln verfügt (siehe Randnummer 812 und 813), wäre es in der Lage, die gesamte Java Community ausschließlich zum eigenen Vorteil zu kontrollieren und zu steuern. (v) Es wäre in der Lage, jegliche Anträge anderer Mitglieder der Exekutivausschüsse abzuschmettern, wie dies Sun angeblich in der Vergangenheit getan hatte, und die Entscheidungen zum JCP stets alleine zu treffen.
3.3.2.1Beeinflussung durch den PMO
Die JCP Prozessdokumente bestätigten das Vorbringen der Anmelderin, dass das PMO keine Befugnisse zur Einleitung, Ablehnung, Verzögerung, Blockierung oder Verhinderung der Einreichung eines JSR hat. Das JCP 2 Prozessdokument in der Fassung 2.7 vom 15. Mai 2009, das beschreibt, welche formalen Verfahren im Entwicklungsprozess der Java-Spezifikationen zu befolgen sind, sieht Folgendes vor: „Geht ein JSR ein, so wird das PMO diesem eine Nummer zuordnen, das JSR dem entsprechenden Exekutivausschuss zuordnen (oder beiden Exekutivausschüssen, falls dies von dem Antragsteller gewünscht wird), seine JSR-Seite erstellen, die vorgeschlagene JSR öffentlich bekannt machen und die JSR-Prüfung einleiten. Kommentare zu dem JSR sind an die E-Mail-Adresse zu senden, die auf der JSR-Seite angegeben ist. Alle eingegangenen Kommentare werden auf der JSR-Seite verfügbar gemacht (ähnliche Kommentare können zusammengefasst werden) und an den Exekutivausschuss zur Berücksichtigung weitergeleitet. Mitglieder, die an einer Teilnahme an den Expertengruppen interessiert sind (falls das JSR angenommen wird), sollten sich mit der Einreichung eines Nominierungsformblatts bei dem PMO melden. Wie in Abschnitt 1.1.5 beschrieben, wird die Prüfungsdauer entweder 2 oder 4 Wochen in Anspruch nehmen.“ [„When a JSR is received, the PMO will give it a tracking number, assign the JSR to the appropriate EC (or both ECs if so requested by the submitter), create its JSR Page, announce the proposed JSR to the public, and begin JSR Review. Comments on the JSR should be sent to the e-mail address listed on the JSR Page. All comments received will be made available from the JSR Page (similar comments may be consolidated) and forwarded to the EC for its consideration. Members who are interested in joining the Expert Group (should the JSR be approved) should identify themselves by submitting a nomination form to the PMO. As described by section 1.1.5 the review period will be either 2 or 4 weeks.“]
Die Verfahrensregeln stellen es nicht ins Ermessen des PMO, auszuwählen, welche Spezifikationen der Community zur Kommentierung vorgeschlagen werden. Das Verfahren scheint vielmehr weitgehend „automatisiert“ zu sein. Daneben prüfte die Kommission das Vorbringen der Anmelderin, wonach „der PMO Antragstellern zwar gelegentlich Ratschläge zur Durchführung des JSR-Verfahrens gibt (wie etwa „die Annahme könnte scheitern, wenn Sie keine Unterstützung von Mitgliedern des Exekutivausschusses eingeworben haben und wenn sie nicht die wichtigsten Vertreter der Branche als Mitglieder der Expertengruppe angegeben haben“), aber doch nicht die Macht hat, die Einreichung oder die Weiterbearbeitung eines JSR abzulehnen, zu verzögern oder in anderer Weise zu beherrschen.“ [„[W]hile the PMO may occasionally advise submitters with respect to navigating the JSR process (e.g., “if you haven't canvassed for support among Executive Committee members, and if you haven't lined up the major industry players as Expert Group members then you may not be approved”), it has no power to disapprove, delay or otherwise control the filing or progression of a JSR“].
3.3.2.2Einflussnahme durch Stimmenmehrheit in den Exekutivausschüssen
Was das Abstimmungssystem in den Exekutivausschüssen anbelangt, hat eine Minderheit der Befragten sich kritisch dazu geäußert, dass Sun die Macht habe, die Entscheidung im Exekutivausschuss entweder durch eine angebliche „Stimmenmehrheit“ oder durch seinen ständigen Sitz und seinen Vorsitz zu beeinflussen. Es trifft zwar zu, dass Sun stets über einen Sitz in den Exekutivausschüssen verfügt und auch den jeweiligen Vorsitz inne hat (siehe Randnummer 809), jedoch verfügt es in den gewöhnlichen Abstimmungen über neue Spezifikationen nur über eine direkte Stimme in jedem Ausschuss, genau wie alle anderen Mitglieder auch. Bei der Behauptung, alle Mitglieder des Exekutivausschusses, die von Sun nominiert wurden, folgten bei ihrer Stimmabgabe einheitlich den Anweisungen von Sun, handelt es sich um eine reine Spekulation. Zunächst nominiert Sun mögliche Kandidaten, das bedeutet jedoch nicht automatisch, dass diese die erforderliche Stimmenmehrheit erhalten, um als Mitglied des Exekutivausschusses ratifiziert zu werden. Entscheidet sich die Mehrheit der Mitglieder des JCP, einen von Sun nominierten Kandidaten nicht zu ratifizieren, ist Sun dazu verpflichtet, einen anderen möglichen Kandidaten zu wählen. Das zeigt, dass das gesamte JCP die Kontrolle über die Ernennung der zehn Kandidaten von Sun hat, nicht allein die direkte Stimme der anderen fünf Mitglieder.
Zweitens scheint es allgemeine Zustimmung zu dem folgenden Vorbringen der Anmelderin zu geben: „Es gibt etliche wichtige Akteure innerhalb der Branche, ohne die das JCP viel weniger wirkungsvoll wäre, selbst für die ureigenen Interessen von Sun, und wodurch wiederum Java weniger lebendig und aktiv wäre und damit natürlich auch weniger anziehend für Entwickler. Sun hat daher kaum eine andere Wahl, als dafür zu sorgen, dass diese Unternehmen in den Exekutivausschüssen vertreten sind“ [„There are certain major players within the industry whose absence from the JCP would make the JCP significantly less effective, including for Sun's own interests, which, in turn, would make Java less vibrant and, therefore, less attractive to developers. Therefore, Sun has little choice but to ensure that these companies are represented on the Executive Committees“]. Sun hat einige Mitglieder benannt, die seine unmittelbaren Wettbewerber sind, wie IBM und HP und auch die Apache Foundation inmitten des Apache-Harmony-Streits. Die aktuelle Liste der nominierten Mitglieder ist (i) im SE/EE-Exekutivausschuss: Apache, Eclipse Foundation, Ericsson, Fujitsu, Google, HP, IBM, Intel, Nortel, Oracle, RedHat, SAP, SpringSource und zwei Einzelpersonen sowie Sun; und (ii) im ME-Exekutivausschuss: Aplix, Ericsson, IBM, Orange, Motorola, Nokia, Philips, Qisda, RIM, Samsung, Siemens, Sony Ericsson, Time Warner Cable, Vodafone und eine Einzelperson sowie Sun. Bemerkenswert ist jedoch, dass sich unter den Dritten, die sich über das Vetorecht bzw. die absolute Mehrheit von Sun in den Exekutivausschüssen beklagten, Unternehmen befinden, die selbst Mitglieder des Ausschusses sind und von Sun nominiert wurden (siehe Fußnote 521).
Die Mehrheitsregelung zu JSR-Vorschlägen ist eindeutig. Wenn beispielsweise ein bestimmter JSR-Vorschlag, der die Verbesserung oder Erweiterung des Anwendungsservers eines Wettbewerbers zum Ziel hat, von einem anderen Anbieter (und Wettbewerber) eingereicht wird und in dem EE-Exekutivausschuss mit Mehrheitsbeschluss angenommen wird, wäre das fusionierte Unternehmen nicht in der Lage, diesen einseitig abzulehnen.
3.3.2.3Entwicklung von Java außerhalb des Rahmens des JCP
Einige wenige Befragte erklärten – in relativ allgemeinen Formulierungen –, dass Oracle in der Lage sein werde, außerhalb des JCP zu seinem eigenen Vorteil neue Spezifikationen zu entwickeln oder neue Java-Entwicklungen zu erstellen. Diese Beschwerde hat nur in Bezug auf die Auswirkungen des Zusammenschlussvorhabens auf den Wettbewerb Bedeutung, da ein solches Verfahren von Oracle eingesetzt würde, um seine nachgelagerten Wettbewerber auszuschließen.
Die Anmelderin trug dazu vor: „Seit seiner Einführung im Jahre 1998 als offenes, partizipatives Verfahren zur Entwicklung und Prüfung der Spezifikationen der Java-Technologie und ihrer entsprechenden Referenzimplementierungen und Testserien hat das JCP die Entwicklung der Java-Plattform in Zusammenarbeit mit der internationalen Community der Java-Entwickler gefördert. Ohne die weit verbreitete Akzeptanz dieser Spezifikationen und der weit verbreiteten Nutzung von Produkten, die diese Spezifikationen implementieren, könnte Java nicht wirksam mit .NET um die Gunst der Anwendungsentwickler konkurrieren“ [„[S]ince its introduction in 1998 as an open, participative process for developing and revising the Java technology specifications and their corresponding reference implementations and test suites, the JCP has fostered the evolution of the Java platform in cooperation with the international Java developer community. Without the widespread adoption of these specifications and the widespread deployment of products that implement the specifications, Java could not compete effectively with .NET for the attention of application developers“]. Zweck des JCP ist es, ein breit aufgestelltes, offenes, von der Branche betriebenes Standardisierungsentwicklungsverfahren auf der Grundlage der Java-Plattform zu erhalten. Der wesentliche Wert von Java besteht in seiner gemeinsamen und weit verbreiteten Standardisierung. Dies bedeutet, dass wenn eine bestimmte Spezifikation in diesem Verfahren angenommen wurde, jede Implementierung eines beliebigen Entwicklers im Hinblick auf die spezifizierten Java-Merkmale identisch ist. Eine Software, die in einer spezifischen Implementierung eines Java-Standards läuft (z. B. in J2EE), wird folglich in allen Implementierungen laufen, die mit diesem Standard kompatibel sind, was die Möglichkeiten, die Software wieder zu verwenden, erweitert, den Wert der Java-Kenntnisse von Programmierern erhöht, die Kosten des Wechsels zwischen verschiedenen Java-Providern verringert, d. h. die Bindung an den Anbieter schwächt oder ganz auflöst, und schließlich zu Kostensenkungen führt. Dieses zentrale Merkmal, „write once, run everywhere“ [Einmal geschrieben, läuft überall], das die grundlegende Bedeutung von Java gegenüber der .NET-Umgebung darstellt, wurde in den Antworten, die auf die Marktuntersuchung eingegangen sind, weithin bestätigt. Die Vorstellung, dass Oracle von dem Community Process abrücken wollte, um proprietäre Spezifikationen außerhalb des Verfahrens zu entwickeln, würde daher den Interessen von Java und von Oracle widersprechen.
878In einer Antwort im Rahmen der Marktuntersuchung wurde die Entwicklung von JavaFX als Beispiel dafür genannt, wie Sun/Oracle von dem Verfahren „abrücken“ könnten, um eine eigene „proprietäre Erweiterung von Java“ zu entwickeln. Die Kommission gelangte insbesondere aufgrund der Erläuterung der Anmelderin dennoch zu dem Schluss, dass dieses Beispiel nicht relevant ist, um zu veranschaulichen, wie Sun/Oracle eine „eigene proprietäre Erweiterung von Java“ entwickeln könnte. Die Anmelderin trug hierzu vor: „Sun vertritt nicht die Ansicht, dass es sich bei JavaFX um eine „prioritäre, Sun-eigene Erweiterung von Java“ handelt. Es handelt sich weder um eine Plattform noch um eine Erweiterung im Sinne des JCP, da es nicht innerhalb des „kontrollierten“ oder „öffentlichen“ Namensraumes definiert ist, wie alle Java-Spezifikationen, auch ersetzt JavaFX bestehende Java-Plattformen nicht, sondern wird eher zusätzlich zu diesen implementiert. JavaFX sollte man sich eher sowohl als Produkt– als Anwendung für Entwickler, die umfangreiche graphische Fähigkeiten bietet und eine zugrunde liegende Java-Plattform auf gleiche Weise nutzen kann, wie dies eine an Merkmalen reiche Anwendung tun kann, die von IBM, SAP oder von einem der Wettbewerber von Oracle entwickelt wurde, und das solche Anwendungen entwickelt und vermarktet – als auch als Skriptsprache wie JavaScript, ASP, JSP, PHP, Perl, Tcl und Python vorstellen. Eine Skriptsprache ist eine einfache Programmiersprache, die meist im Internet verwendet wird, um einer Webseite Funktionalitäten hinzuzufügen. JavaFX (...) wurde von Sun als Konkurrenz zu Silverlight von Microsoft und Flash Technologies von Adobe entwickelt. Die Tatsache, dass Silverlight und Flash bedeutende Wettbewerber von JavaFX sind, räumt alle möglichen wettbewerbsrechtlichen Bedenken bezüglich des proprietären Charakters von JavaFX aus. JavaFX verfügt über keine Marktmacht und kann daher nicht als Mechanismus zur Abschottung eingesetzt werden.
535Siehe nicht vertrauliche Antwort von Microsoft auf den Fragebogen zu Java, Antwort auf Frage 28.
Außerdem trifft es zu, dass die Existenz des JCP als solches Sun und Oracle in Zukunft nicht davon abhalten wird, proprietäre Produkte auf der Grundlage der eigenen geistigen Eigentumsrechte von Sun an Java zu entwickeln. Die Beschwerdeführer legten keine Anhaltspunkte vor, aus denen sich schließen ließe, dass eines dieser potenziellen Produkte – die jedoch unbekannt bleiben – einen bedeutenden Inputfaktor für Produkte der Wettbewerber darstellen könnte. Ohne eine solche Schlussfolgerung, die eine grundlegende Voraussetzung für mögliche Analysen von Bedenken vertikaler Wettbewerbsschädigung darstellt, bleiben abstrakte Überlegungen darüber, was Sun/Oracle außerhalb des JCP entwickeln könnte, reine Spekulation und sollten bei der Beurteilung der Kommission keine Berücksichtigung finden.
3.3.2.4Kontrolle der Entwicklungen von „Dachspezifikationen“ über das Vetorecht von Oracle
Der konkretere Einwand, der sich aus dem Vetorecht von Sun/Oracle bei Entscheidungen über bedeutende Plattformaktualisierungen ableitet (bezüglich der „Dachspezifikationen“ JSE, JEE und JME) – siehe Randnummer 812 – beruht anscheinend darauf, dass Wettbewerber diese „Macht“ als Gefahr wahrnehmen, wenn die Entscheidungen von Oracle möglicherweise die Entwicklungen dahingehend beeinflussen, die eigenen nachgelagerten Produkte von Oracle zu begünstigen.
Es erscheint unwahrscheinlich, dass Oracle die Möglichkeit hätte, mit seinem Vetorecht zu bedeutenden Plattformaktualisierungen eine Abschottungsstrategie einzuschlagen. Erstens führt die Anmelderin an, dass das Verfahren, welches zur Entwicklung einer Dach-JSR führt, zwar von Sun als Spezifikationsführer geleitet wird, jedoch immer unter Beteiligung anderer „Experten“ erfolgt (siehe Randnummer 811), die ihre geistigen Eigentumsrechte entsprechend der JCP-Regeln gewähren. Zu den Dachspezifikationen im Besonderen unterbreitet die Anmelderin eine vollständige Liste aller Experten, die ebenfalls ihre geistigen Eigentumsrechte zu der Spezifikation beisteuern, und bestätigt damit, dass Sun nicht der einzige Inhaber von geistigen Eigentumsrechten ist. Alle von Sun/Oracle vorgeschlagenen möglichen Entwicklungen, welche den nachgelagerten Wettbewerb beeinträchtigen könnten, könnten leicht in einem frühen Stadium aufgedeckt werden und die Experten könnten jederzeit ihre geistigen Eigentumsrechte zurückhalten, sollten sie mit der von Oracle vorgeschlagenen Richtung nicht übereinstimmen.
Zweitens: Selbst wenn es dem fusionierten Unternehmen gelänge, eine „Oracle-freundliche“ Spezifikation für die Plattformedition zu Wege zu bringen, muss nach den Regeln des JCP jede bedeutende Änderung der Dachspezifikation von einer Zweidrittelmehrheit und der Stimme von Sun verabschiedet werden. Das bedeutet, dass jegliche Entwicklung der Dachspezifikationen im gewöhnlichen, transparenten JCP-Verfahren analysiert werden muss und die qualifizierte Mehrheit in dem entsprechenden Exekutivausschuss erfordert, in dem viele nachgelagerte Wettbewerber von Oracle einen Sitz haben. Alleine dieses Element kann als ausreichender Nachweis dafür angesehen werden, dass Oracle keine einseitigen wettbewerbsbeschädigenden Entwicklungen der Dachspezifikation durchsetzen könnte.
Drittens bleibt durch die Tatsache, dass nach den gegenwärtigen JCP Oracle der Spezifikationsführer für alle Dachspezifikationen wäre, die Regelung unberührt, dass die mit allen Spezifikationen verbundenen Lizenzverpflichtungen dieselben wären (Pflicht zur Lizenzvergabe, FRAND-Bedingungen), wie die nach den JSPA für alle anderen JSR geltenden Vorgaben.
Viertens besteht eine „Fortbestandspflicht“ (Artikel 10 und 13 der JSPA) für alle JSR, die während der Geltungsdauer der Vereinbarung geschlossen wurden. Die vertraglichen Pflichten der Parteien bleiben bei Kündigung des Vertrags für diese JSR hinsichtlich Abschnitt 4, 5, 6, 9, 11 und 12 der JSPA weiter bestehen.
Selbst wenn die JCP/JSPA zurzeit Sun und in Zukunft Oracle ein Vetorecht bezüglich der Entwicklung von Dachspezifikationen einräumen, so kommt die Kommission dennoch zu dem Schluss, darin keine Möglichkeit einer eventuellen Marktabschottungsstrategie zum Nachteil der nachgelagerten Wettbewerber von Oracle erkennen zu können.
3.3.2.5Ablehnung von Anträgen anderer Mitglieder der Exekutivausschüsse/des JCP durch Oracle, um jegliche Entwicklungen des Verfahrens zum eigenen Nachteil zu verhindern
Unter Randnummer 7 von Anhang 3 des JCP2-Prozessdokuments werden die Aufgaben und Zuständigkeiten des Exekutivausschusses aufgezählt, darunter „die Beratung des PMO und der JCP-Community, um eine wirkungsvolle Arbeit der Organisation zu fördern und die Entwicklung von Java-Plattformen und -Technologien zu steuern. Eine solche Beratung kann auf verschiedenen Wegen erfolgen, beispielsweise in Form der Veröffentlichung von Weißbüchern, Berichten oder Kommentaren, soweit der Exekutivausschuss eine Darstellung seiner Auffassung oder der Auffassung beider Exekutivausschüsse für zweckdienlich erachtet“ [„provide guidance to the PMO and JCP Community to promote the efficient operations of the organization and to guide the evolution of Java platforms and technologies. Such guidance may be provided by mechanisms such as publishing white papers, reports, or comments as the EC deems appropriate to express the opinions of one or both Executive Committees“].
Die in den Beschwerden genannten „Anträge“ sind Ergebnis der internen Beratungen, die in dem üblichen Diskurs im Rahmen des JCP stattfinden. Die Anmelderin stellt die Sachlage dar, dass etliche Anträge, gegen die Sun gestimmt hatte oder bei denen es sich bei der Stimmabgabe enthalten hatte und in denen etliche Mitglieder ihrem Wunsch Ausdruck verliehen, bestimmte Lizenzbedingungen zu ändern (September 2007, Dezember 2007 Nr. 2, April 2009) oder „Anbieter-unabhängige JCP“ forderten (Dezember 2007 Nr. 1), schlicht und einfach die Meinung der jeweiligen Exekutivausschüsse darstellten und keinerlei Maßnahmen erforderten.
Es lässt sich nur schwer erkennen, inwiefern im Rahmen des JCP die Tatsache, dass bestimmte Anträge nicht in konkrete Änderungen des JCP bzw. der JSPA umgesetzt wurden, ausschließlich der Haltung von Sun zuzuschreiben wäre. Jegliche „Entwicklung“ des Verfahrens muss sich in einer Veränderung des JCP oder der JSPA niederschlagen, um eine konkrete Auswirkung auf die Mitglieder zu haben. Die für das JCP geltenden Regeln bestätigen in dieser Hinsicht das Vorbringen der Anmelderin, wonach „(...) eine Veränderung des JCP selbst dem JSR-Prüfprozess unterliegt. Vorgeschlagene Änderungen werden genau wie ein Vorschlag zur Ergänzung oder Änderung eines technischen Standards behandelt. Diese verfahrenstechnischen Änderungen erhalten eine JSR-Nummer und unterliegen demselben mehrschichtigen Verfahren aus Prüfung, Kommentaren und Annahme als technische Spezifikationen. Kein einzelnes JCP-Mitglied (auch nicht Sun oder Oracle) könnte daher ohne die in diesem Fall erforderliche Zustimmung beider Exekutivausschüsse das JCP so ändern, dass es andere Mitglieder benachteiligen würde.“ [„[…] modifying the JCP itself is subject to the JSR review process. Proposed modifications are treated just like a proposal to add or change a technical standard. These procedural changes are assigned a JSR number and subject to the same multiple levels of review, comment, and approval as are technical specifications. No individual JCP member (including Sun or Oracle) could, thus, modify the JCP in a manner that would disadvantage other members without approval, in this case, by both Executive Committees.“]. Weiter: „Überarbeitungen des JCP, der JSPA (...) werden durchgeführt, indem ein JSR angenommen wird, dass den Java Community Process mit den folgenden Änderungen durchlaufen hat: (a) Nur Mitglieder der Exekutivausschüsse können ein JSR zur Überarbeitung eines dieser Dokumente initiieren; (b) jeder Exekutivausschuss muss den JSR [mit einfacher Stimmenmehrheit] annehmen; (c) die Expertengruppe besteht aus beiden Exekutivausschüssen und ein Mitglied des PMO ist Spezifikationsführer; und (d) es ist keine Referenzimplementierung und kein Technology Compatibility Kit abzuliefern und kein Einspruchsverfahren für das TCK festzulegen“ [„Revisions to the JCP, the JSPA […] are carried out via the adoption of a JSR using the Java Community Process with the following changes: (a) only Executive Committee members can initiate a JSR to revise one of these documents; (b) each Executive Committee must approve the JSR [with a simple majority of votes]; (c) the Expert Group consists of both Executive Committees with a member of the PMO as Specification Lead; and (d) there is no Reference Implementation or Technology Compatibility Kit to be delivered and no TCK appeals process to be defined“].
889Selbst wenn diese Ausführungen ohne Belang wären und wenn die „Verwerfung“ von Anträgen mit beratendem Charakter durch Sun irgendwelche konkreten Auswirkungen auf die Entwicklung des JCP hätte, wird noch nicht deutlich, inwiefern dies wettbewerbsschädigend für die nachgelagerten Wettbewerber sein könnte. Die einzige Möglichkeit für Sun/Oracle, theoretisch eine Benachteiligung nachgelagerter
539Siehe Antwort der beteiligten Unternehmen auf Frage 27 des Auskunftsersuchens der Kommission vom 5. August 2009.
Wettbewerber zu betreiben, besteht in den Lizenzbedingungen, die es seinen Lizenznehmern auferlegt.
890Es ist daher der Schluss zu ziehen, dass sämtliche Annahmen, auf deren Grundlage Beschwerdeführer und Befragte behaupteten, Sun/Oracle hätte die Möglichkeit, das JCP zu kontrollieren und den Entscheidungsprozess hin zu Entwicklungen zu steuern, die Oracle zum Nachteil seiner nachgelagerten Wettbewerber begünstigen würden, in der Sache unbegründet sind und zurückzuweisen sind.
3.3.3Möglichkeit von Oracle, nachgelagerte Wettbewerber durch eine ungünstigere Gestaltung der Lizenzvergabe für Java zu benachteiligen
891Die Befragten der Marktuntersuchung sowie die Beschwerdeführer erhoben zahlreiche Bedenken hinsichtlich der potenziellen Möglichkeiten von Oracle, durch eine Verschlechterung der Lizenzbedingungen für die verschiedenen Teile der Java-Plattform nachgelagerte Wettbewerber zu benachteiligen.
892Ohne Zweifel wird das fusionierte Unternehmen die geistigen Eigentumsrechte an einigen proprietären Merkmalen von Java kontrollieren, für die einige der Wettbewerber von Oracle auf nachgelagerter Ebene Lizenzen erwerben müssen.
893Zunächst sei daran erinnert, dass Unternehmen die Anwendungen (EAS) entweder in Java oder in anderen Programmiersprachen erstellen, keine TCK-Lizenz benötigen, unabhängig von der von den Entwicklern verwendeten Java-Plattform (EE, SE oder ME), um mit Oracle auf dem Gesamtmarkt für EAS zu konkurrieren. Die Marktuntersuchung bestätigte im Wesentlichen, dass diese Unternehmen in erster Linie entweder ihre Programme einschließlich der JRE in der ausführbaren freien Binärversion des entsprechenden JSR vertreiben, sofern sie dies wünschen, oder dass sie den Kunden dazu auffordern, die entsprechende JRE kostenfrei direkt von der Webseite von Sun herunterzuladen. Da sie den Quellcode der Referenzimplementierung weder nutzen noch verändern, ist es zur Zertifizierung der Java-Kompatibilität nicht erforderlich, dass sie Implementierungen mit TCK testen. Die Anmelderin führte aus, dass aus diesem Grund EAS-Anbieter nicht TCK-Lizenznehmer sind, wenn sie nicht ebenfalls Java-Applikationsserver oder Entwicklungswerkzeuge herstellen. So berichtete beispielsweise Infor, dass es „keine eigenen JRE entwickelt, da seine Geschäftslösungen auf der freien binären JRE basieren, die von Sun bereitgestellt wird. Kunden von Infor müssen die JRE von Sun herunterladen, um die Geschäftslösungen von Infor ausführen zu können.“
894Die Marktuntersuchung bestätigte insbesondere, dass, wie in Randnummer 819 erläutert, „nur die Anbieter TCK-Lizenzen benötigen, die den Quellcode der Referenzimplementierung verändern oder unabhängige Implementierungen erstellen möchten und die ihre Plattformprogramme als Java-kompatibel vertreiben möchten“. Hierbei handelt es sich im Wesentlichen nur um Anbieter von Anwendungsservern, da diese sich dazu entschlossen haben, den Quellcode der Referenzimplementierung zu verändern, um „ihre Anwendungsserver in Bezug auf Parameter wie Leistung, Skalierbarkeit, Clustering, Transaktionsverwaltung, Message Queuing und andere zu differenzieren. Dafür sind Änderungen des Quellcodes notwendig, da die Java EE Referenzimplementierung, die auf dem Anwendungsserver GlassFish von Sun basiert, ein voll funktionsfähiger, handelsüblicher Anwendungsserver ist und nicht lediglich ein Bestandteil eines größeren Produkts, wie das bei der Java SE JVM der Fall wäre. Angesichts des breiten Umfangs der Java EE Spezifikation erfordert fast alles, was an der Software mit dem Ziel der Differenzierung des eigenen Anwendungsservers verändert wird, eine Veränderung des Quellcodes und daher eine TCK-Lizenz. Das erklärt auch, warum Anbieter von Anwendungsservern fast immer über eine Java EE TCK-Lizenz verfügen – und warum fast jeder Java EE TCK-Lizenznehmer Anwendungsserver baut.
895Die Kommission untersuchte zwei Möglichkeiten, wie das fusionierte Unternehmen die Abschottung gegenüber Wettbewerbern betreiben könnte: (i) Das fusionierte Unternehmen könnte die Lizenzvergabe für Java an seine nachgelagerten Wettbewerber einschränken, indem es entweder eine Verlängerung verweigert oder bestehenden Lizenzen Einschränkungen auferlegt. (ii) Das fusionierte Unternehmen könnte die Lizenzvergabe für Java an seine nachgelagerten Wettbewerber einschränken, indem es eine Verlängerung verweigert, bestehenden Lizenzen Einschränkungen auferlegt, die Zertifizierung verzögert oder die Preise für zukünftige Java-Lizenzen anhebt.
3.3.3.1Ungünstigere Gestaltung bestehender Java-Lizenzen
896Oracle wird alle derzeitigen Lizenzvereinbarungen erben, die Sun mit nachgelagerten Wettbewerbern von Oracle geschlossen hat (siehe Beschreibung unter Randnummer 822 ff. sowie 852 ff.). Oracle wird somit an die Bestimmungen dieser Vereinbarungen gebunden sein. Die JSPA betreffend wird Oracle durch seine Lizenzverpflichtungen nach den FRAND-Bedingungen gebunden sein (siehe Randnummer 819). Selbst wenn Oracle solche JSPA zum Datum der Verlängerung kündigen würde, so blieben doch seine Lizenzverpflichtungen für sämtliche JSR, deren Ursprung vor oder während der JSPA liegt (Artikel 10 und 13 der JSPA), weiter bestehen.
897Wie aus der Beschreibung von Java-Lizenznehmern, die Wettbewerber von Oracle sind, hervorgeht, verfügen die wichtigsten Wettbewerber von Oracle, IBM und SAP über bestehende Lizenzvereinbarungen, die ihren Zugang zu geistigen Eigentumsrechten an Java für mindestens drei Jahre regeln (bis 2012 für SAP und bis 2016 für IBM). Die JEE-Lizenz von RedHat läuft im November 2011 aus, seine SE-Lizenz ist dauerhaft. Die anderen Unternehmen sind kleinere Wettbewerber von Oracle mit begrenzten Anteilen auf den Märkten für Anwendungsserver bzw. Middleware.
898Um die Lizenzbedingungen dieser Wettbewerber zu beeinflussen, müsste Oracle die Vereinbarungen einseitig vor Ablauf kündigen und damit einen Rechtsstreit riskieren. Das erscheint sehr unwahrscheinlich. Ganz allgemein gilt außerdem, dass Lizenznehmer Zugang zu Aktualisierungen (sowohl der RI als auch des TCK) haben, solange die jährlichen Support- und Lizenzgebühren bezahlt sind. Diese Updates werden jedoch von den zwischen Sun und dem Lizenznehmer ausgehandelten Bedingungen abhängen. Im Fall von IBM ist kein Abschluss neuer Lizenzvereinbarungen erforderlich, wenn eine neue Plattform auf den Markt kommt, solange diese neue Plattform in die Parameter einer „Java-Umgebung“ passt (d. h. über eine JVM und Kernklassen verfügt).
899Die Marktuntersuchung bestätigte, dass in den meisten Fällen Sun nicht über das Recht verfügt, laufende Verträge einseitig zu kündigen und dass akzeptiert wird, dass neue Bedingungen gleichzeitig mit dem Abschluss neuer Verträge ausgehandelt werden können.
900Das fusionierte Unternehmen wird daher allem Anschein nach keine Möglichkeit haben, kurzfristig die Bedingungen für Java-Lizenzen seiner Wettbewerber im Bereich EAS (wie z. B. SAP) zu beeinflussen, und wird auch mittel- bis langfristig nicht in der Lage sein, die Java-Lizenzbedingungen seiner wichtigsten Wettbewerber im Segment Middleware (wie beispielsweise IBM) zu beeinflussen.
901Angesichts des Vorstehenden wird der Schluss gezogen, dass Oracle nicht in der Lage sein wird, die laufenden Verträge über Lizenzen für geistige Eigentumsrechte an Java zu verändern.
3.3.3.2Ungünstigere Gestaltung zukünftiger Java-Lizenzen
902Es wurde vorgebracht, dass das fusionierte Unternehmen im Rahmen des JCP die Möglichkeit hat, die Bedingungen, unter denen Java-Lizenzen künftig für neue JSR vergeben werden, zu verändern, insbesondere könnte es diese Bedingungen zum Nachteil seiner nachgelagerten Wettbewerber verändern.
903Auch in diesem Fall wird Oracle alle JSPA mit den 1.200 JCP-Mitgliedern, in denen seine Verpflichtungen geregelt sind, die es in Bezug auf die Lizenzbedingungen der JSR einzuhalten hat (Pflicht zur Lizenzvergabe, FRAND-Bedingungen), erben. Darüber hinaus ist der Spezifikationsführer nach dem neuen JCP 2.7 Verfahren (in Kraft seit Juni 2009, siehe Randnummer 811) dazu verpflichtet, weitere Informationen über die Lizenzbedingungen für unabhängige Implementierungen oder Implementierungen auf der Basis der RI offenzulegen. Solche Bedingungen werden von den Mitgliedern des Exekutivausschusses bei ihrer Abstimmung über zukünftige JSR beurteilt und erwogen. Etliche Mitglieder der EE/SE-Exekutivausschüsse – RedHat, IBM, Intel – haben bereits öffentlich erklärt, dass sie prüfen werden, ob die Java EE6 TCK-Lizenz Einschränkungen der Nutzungsbereiche enthält, und dies bei ihrer Abstimmung über die Annahme der endgültigen Spezifikation berücksichtigen. Viele Befragte bestätigten im Rahmen der Marktuntersuchung, dass all diese Bedingungen, die im Rahmen des JSR-Verfahrens mit den Lizenzen verbunden sind, offen zu legen sind.
904Die Beschwerdeführer haben in diesem Zusammenhang die Befürchtung geäußert, dass Oracle den TCK-Lizenzen Einschränkungen der Nutzungsbereiche auferlegen könnte, um seine nachgelagerten Wettbewerber zu benachteiligen. Ein kurzer Überblick über die Rechte und Pflichten, die mit der Lizenzvergabe von TCK an Dritte verbunden sind, ist notwendig, um den Hintergrund und die Stichhaltigkeit einer solchen Behauptung zu verstehen.
905Konkret sorgt das gesamte JCP/JSPA-Rahmenwerk dafür, dass Softwareentwickler, die eine eigene unabhängige Implementierung oder eine Änderung des Quellcodes der Referenzimplementierung entwickeln und die Java-Kompatibilität ihrer Produkte für sich beanspruchen wollen, vom Spezifikationsführer alle einschlägigen geistigen Eigentumsrechte anfordern und erhalten können. Der Spezifikationsführer ist dazu verpflichtet, die Lizenzen für diese Rechte zu vergeben.
906Im Fall von unabhängigen Implementierungen besagt Abschnitt 5.B - (a) der JSPA, dass die unabhängige Implementierung die Schnittstellen und Funktionalitäten der JSR vollständig implementieren muss: Die Implementierung muss daher alle Merkmale der Spezifikation spiegeln und zumindest alle in der Spezifikation vorgesehenen Funktionalitäten leisten. Nur teilweise übereinstimmende Implementierungen sind im Gegensatz dazu untersagt, da ansonsten alle anderen Anwendungen, die sich auf das Vorhandensein bestimmter API verlassen (siehe Fußnote 482) und in der JSR beschrieben sind, jedoch in der Implementierung fehlen, nicht laufen würden, womit die Kompatibilität und der Anspruch eines offenen Standards des JCP ausgehebelt würde. Nach Abschnitt 5.B - (b) ist auch die Abweichung von konventionellen Namen, die durch die JSR vergeben wurden, untersagt, damit „Aufrufe“ von jeglicher Anwendung an die richtige Stelle innerhalb der Plattformimplementierung gelenkt werden. Nach Abschnitt 5.B - (c) muss schließlich die Implementierung die entsprechende TCK bestehen, um sicherzustellen, dass die Implementierungen wie in den JSR vorgesehen funktionieren. Die Lizenz für das TCK (siehe Randnummer 818) muss stets zu FRAND-Bedingungen vergeben werden. Die Beschwerdeführer haben in diesem Zusammenhang die Befürchtung geäußert, dass Oracle zum Nachteil seiner nachgelagerten Wettbewerber an die Lizenzen für TCK Einschränkungen der Nutzungsbereiche knüpfen könnte. Schließlich gewährleistet Abschnitt 5.C jenseits spezifischer Bedingungen zur Wechselseitigkeit und zum Schutz von Patentrechten, welche in keiner Weise die Möglichkeiten eines Lizenznehmers zur Konkurrenzfähigkeit zu berühren scheinen und die weder von Beschwerdeführern noch von Befragten als kritische Punkte genannt wurden, dass der Spezifikationsführer keine vertragliche Bedingung oder Klausel einführen kann, welche das Recht des Lizenznehmers einschränken oder einengen würde, die Spezifikation zu nutzen oder eine unabhängige Implementierung zu erstellen oder zu vertreiben.
907Ein Entwickler einer unabhängigen Implementierung wird daher sein Produkt testen und lizenzieren lassen und das Produkt muss alle in der JSR vorgesehenen Funktionalitäten ausführen können.
908Zu den Pflichten des Spezifikationsführers zur Lizenzvergabe hinsichtlich der Referenzimplementierung und des entsprechenden TCK sieht wiederum Abschnitt 5.F.I der JSPA vor, dass der Spezifikationsführer Lizenzen der Referenzimplementierung und des TCK zu FRAND-Bedingungen an alle Interessierten vergeben muss. Nach Abschnitt 5.F.II muss der Spezifikationsführer außerdem den nachgelagerten Lizenzgebern die Möglichkeit geben, kompatible Binärversionen der
auf der Referenzimplementierung basierenden Implementierungen zu vertreiben und die Referenzimplementierung als Teil einer kompletten Binärimplementierung der entsprechenden Spezifikation zu vertreiben, die die Kompatibilitätsstandards 5 (a) – (c) erfüllt (siehe Randnummer 901).
909Dem Spezifikationsführer ist es untersagt, zusätzliche Kompatibilitätshürden einzuführen, die über diejenigen hinausgehen, die für die Spezifikation erforderlich sind. In Abschnitt 5.F.IV heißt es hierzu: „Dem Spezifikationsführer ist es im Rahmen der vorgenannten Lizenz untersagt, zusätzliche Vertragsbedingungen oder Klauseln zur Kompatibilität einzuführen, welche die Rechte des Lizenznehmers einschränken oder einengen würden, von der [Referenzimplementierung] abgeleitete Produkte zu erstellen oder zu vertreiben.“ [„the Spec Lead shall not include as part of the foregoing license any additional contractual condition or covenant concerning compatibility that would limit or restrict the rights of any licensee to create or distribute products derived from the [Reference Implementation].“] Diese Bestimmung entspricht Abschnitt 5.C der JSPA bezüglich der unabhängigen Implementierungen. Abschnitt 5.F.IV untersagt also dem Spezifikationsführer ausdrücklich jegliche Behinderung der Kompatibilität einer Implementierung auf der Grundlage der Referenzimplementierung. Anders ausgedrückt kann also ein Spezifikationsführer nicht verlangen, dass eine Implementierung eines Lizenznehmers weitere Anforderungen erfüllen muss, die über diejenigen hinausgehen, die in der JSR ausgeführt wurden. Folglich wäre ein FOUR, das die Möglichkeit von Lizenznehmern zur Bestätigung der Kompatibilität mit einer JSR – also dem eigentlichen Kern von Java – einschränken würde, undenkbar.
910Oracle wäre also bei der Vergabe der TCK-Lizenzen an seine Wettbewerber in den unter Randnummer 906 bis 909 genannten Fällen nicht in der Lage, die hinter der JSR stehenden Bedingungen bzw. die Technologie ungünstiger zu gestalten oder selektiv zu verändern. Die bindenden Bestimmungen der JSPA sind in dieser Hinsicht eindeutig. Oracle und auch jeder Spezifikationsführer ist verpflichtet, die beschriebenen Rechte zu den unter Randnummer 906 bis 909 erwähnten Bedingungen nicht nur an alle Interessierten zu vergeben, die ein JSPA unterzeichnet haben, sondern auch an alle anderen Interessierten (siehe JSPA, Abschnitt 5.B und 5.F.I), die darum ersuchen.
911Vor diesem Hintergrund könnte Sun/Oracle zwar Beschränkungen der Nutzungsbereiche einführen, jedoch weder festlegen, welche Technologie der Lizenznehmer erhält, noch Hindernisse für die Kompatibilität einbauen, noch unfaire, unangemessene oder diskriminierende Lizenzbedingungen anwenden. Jeder Verstoß gegen die Verpflichtung zu fairen, angemessenen und nicht diskriminierenden Bedingungen würde sofort in einem frühen Stadium des Spezifikationsverfahrens aufgedeckt werden und könnte im Exekutivausschuss entsprechend abgelehnt werden.
912Keiner der Beschwerdeführer bzw. der Befragten der Marktuntersuchung machte konkrete Angaben dazu, wie eine Einschränkung des Nutzungsbereichs im Hinblick auf die JCP/JSPA-Kriterien gestaltet sein müsste, um eine Abschottung gegen nachgelagerte Wettbewerber von Oracle zu bewirken. Die Tatsache, dass Oracle, wie gegenwärtig Sun, die Nutzung der Implementierungen, deren Kompatibilität mit der Java-Spezifikation durch den TCK getestet wurde, für (jeden) J2EE TCK-Lizenznehmer einschränken könnte (siehe Randnummer 836), stellt an sich keinen Nachweis für eine Abschottung dar. Der Grund für die legitime Entscheidung von Sun, die Nutzung der unterschiedlichen Plattformeditionen der Java-Dachspezifikationen voneinander abzugrenzen, besteht aus der Sicht von Sun in der Notwendigkeit, seine
913Einnahmen aus bestimmten Arten von Lizenzen zu sichern (also die Gebühren für alle JME-Lizenzen im Gegensatz zu den Möglichkeiten der OpenJDK-Lizenzen für allgemeine Zwecke für das JSE) und die Kohärenz und Kompatibilität in der Java-Umgebung zu gewährleisten. Der entscheidende Wert von Java besteht darin, dass es offen und standardisiert ist. Dafür zu sorgen, dass jede Spezifikation in jeder Plattform mit der Plattform selbst konsistent ist und nicht zu Überschneidungen mit anderen Plattformen führt, die einen Bruch des Standards bewirken könnten, stellt eine völlig berechtigte Art und Weise dar, einen solchen Wert zu erhalten.
914Der Apache-Harmony-Streit, der infolge der von Sun vorgeschlagenen FOUR in Verbindung mit der TCK für die Implementierung der J2SE von Apache (siehe Randnrn. 839 via 844) entstanden ist, ist ein Beispiel dafür, wie wachsam die Community im Hinblick auf alle Einschränkungen reagiert, die eine Behinderung für Entwicklungen darstellen könnten, die für Wettbewerber oder Kunden von Sun/Oracle als bedeutsam erachtet werden könnten. Selbst wenn die verschiedenen „Anträge“, die zum JCP eingebracht worden waren, formell nicht implementiert wurden, stellt die Annahme der neuesten Aktualisierung des JCP im Juni 2009 das wichtigste Ergebnis des von den Mitgliedern auf die Vorgehensweise von Sun ausgeübten Drucks dar. Die Verpflichtung aller Spezifikationsführer, sämtliche Bedingungen der Lizenzen offen zu legen, stellt einen entscheidenden Schritt in Richtung einer größeren Transparenz des JCP dar.
915Sollte das fusionierte Unternehmen die Lizenzbedingungen ungünstiger gestalten, müssen die den Wettbewerbern zur Verfügung stehenden Alternativen ebenfalls ausgelotet werden. Die Möglichkeit kann nicht ausgeschlossen werden, dass bei einer ungünstigeren Gestaltung der Lizenzbedingungen durch das fusionierte Unternehmen ein Lizenznehmer einen anderen Anbieter wählt, wie beispielsweise für JEE den WebSphere Anwendungsserver von IBM. IBM verfügt über Lizenzen, die eine Unterlizenzierung seiner Implementierungen gestatten. In diesem Fall würde WebSphere nur eine Alternative für die Wettbewerber im Bereich Anwendungsserver darstellen, die eine bestehende Implementierung von JEE (in diesem Fall WebSphere) verwenden (und möglicherweise anpassen) möchten, während jedoch Entwickler, die ihre eigene unabhängige Implementierung erstellen wollen, dennoch eine Lizenz von Sun/Oracle benötigen.
916In Bezug auf die Möglichkeit, dass das fusionierte Unternehmen die Wettbewerber durch hohe Preise der Java-Lizenzen benachteiligen könnte, ist anzumerken, dass das Risiko nur für Lizenzen außerhalb des JCP besteht, da RI- und TCK-Lizenzen des fusionierten Unternehmens entsprechend dem JCP bzw. den JSPA stets zu FRAND-Bedingungen gewährt werden müssen. Die Marktuntersuchung ergab, dass die Lizenzgebühren für Java einen minimalen prozentualen Anteil an den Gesamtkosten der endgültigen „Softwareprodukte“ ausmachen – im weiteren Sinne, womit alle möglichen Ergebnisse der Java-Lizenzen umfasst werden sollen –, nämlich rund 1 %. Selbst wenn also das fusionierte Unternehmen höhere Preise für diese Lizenzen verlangt, die über die nach JCP/JSPA vorgeschriebenen Grenzen gehen, um damit die Kostenstruktur der Wettbewerber wirklich zu beeinträchtigen, so müsste es zu erheblichen Preissteigerungen greifen. Dies erscheint jedoch nicht realistisch, da die zukünftigen Lizenznehmer solche Lizenzen dann ganz einfach nicht unterzeichnen würden, sondern eher die RI und das TCK nach den von JCP garantierten FRAND-Bedingungen erwerben würden.
Mit einer RI- und einer TCK-Lizenz verfügt ein Softwareunternehmen über alle erforderlichen geistigen Eigentumsrechte, um die Java-Plattformsoftware zu programmieren und zu nutzen, während die in umfangreicheren Lizenzen (wie in der von IBM) enthaltenen zusätzlichen Elemente Aspekte betreffen (wie die Nutzung von Java-Marken), die für den nachgelagerten Wettbewerb nicht von entscheidender Bedeutung sind.
917Angesichts des Vorstehenden wird der Schluss gezogen, dass das fusionierte Unternehmen nicht über die Möglichkeit verfügen wird, sich durch eine ungünstigere Gestaltung der Java-Lizenzbedingungen gegen Wettbewerber auf nachgelagerter Ebene abzugrenzen.
3.3.4Möglichkeiten von Oracle, die Entwicklung neuer Java-Spezifikationen zum ausschließlichen Vorteil seiner eigenen Software zu begünstigen
918Die Beschwerdeführer brachten auch vor, dass das fusionierte Unternehmen die Entwicklungen von Java-Spezifikationen einseitig zum Nutzen ihrer eigenen Software begünstigen könnte und damit die Funktionsfähigkeit und Wettbewerbsfähigkeit der Software nachgelagerter Wettbewerber von Oracle beeinträchtigen würde.
919Jedes Mitglied des JCP kann auf eigene Initiative neue Java-Spezifikationen entwickeln. Diese neuen Spezifikationen müssen dennoch von den leitenden Organen des JCP validiert werden. Jede JSR durchläuft das unter Randnummer 812 beschriebene Verfahren und ist von der Stimme aller 16 Mitglieder des entsprechenden Exekutivausschusses abhängig, unter denen sich einige der potenziell von der Abschottung Betroffenen befinden.
920Die Marktuntersuchung hat gezeigt, dass es möglich und gelegentlich unausweichlich ist, dass bestimmte Spezifikationen Funktionalitäten bestimmter Anwendungen stärker optimieren als von anderen Anwendungen. Die Möglichkeit, eine Technologie zum Nutzen einer einzigen Anwendung zu optimieren, erscheint jedoch eher unrealistisch. Zudem würde eine eindeutige „Ausrichtung“ zu Gunsten eines bestimmten Produkts leicht vom entsprechenden Exekutivausschuss erkannt, worauf dieser mit einer Ablehnung der Spezifikation durch Mehrheitsbeschluss reagieren könnte.
921Die in dem JCP verankerten wechselseitigen Kontrollen sowie die Tatsache, dass zahlreiche direkte Wettbewerber von Oracle auf der Ebene der Exekutivausschüsse präsent sind und jederzeit als gegenläufige Strategie eine Spezifikation vorschlagen können, die bestimmte Produkte begünstigen könnte, die sich von Oracle unterscheiden, verdeutlichen zudem, dass Oracle kaum in der Lage sein wird, eine solche Strategie einzuschlagen.
921Interessant ist in diesem Zusammenhang ein Beschluss, der von Oracle in der JCP-Sitzung im Dezember 2007 eingebracht wurde und dem mit Ausnahme von Sun, das sich enthielt, alle Mitglieder des Exekutivausschusses zugestimmt hatten. „Sinn des Exekutivausschusses ist es, das JCP zu einer offenen, unabhängigen, anbieterneutralen Standardisierungseinrichtung zu formen, an dem alle Mitglieder zu gleichen Bedingungen teilnehmen und das durch folgende Merkmale gekennzeichnet ist:“ [„It is the sense of the Executive Committee that the JCP become an open independent vendor-neutral Standards Organization where all members participate on a level playing field with the following characteristics:“]
• „die Kosten für die Entwicklung und das Management werden von den Mitgliedern getragen“ [„members fund development and management expenses“];
• „es ist eine juristische Person mit einer Satzung, einem geschäftsführenden Organ, einer Mitgliederschaft usw“ [„a legal entity with by-laws, governing body, membership, etc.“];
• „neue, einfachere Grundsätze zu geistigen Eigentumsrechten, die die größtmögliche Anzahl von Implementierungen gestattet“ [„a new, simplified IPR Policy that permits the broadest number of implementations“];
• „stringente Kompatibilitätsanforderungen“ [„stringent compatibility requirements“];
• „Ziel ist die Förderung des Java-Programmierungsmodells“ [„dedicated to promoting the Java programming model“];
Der Exekutivausschuss erhält außerdem die Aufgabe, einen Plan zu erstellen, nach dem ein solcher Übergang so bald wie möglich mit der geringstmöglichen Unterbrechung für die Java-Community vollzogen werden kann“ ["Furthermore, the EC shall put a plan in place to make such transition as soon as practical with minimal disruption to the Java Community"]
922Diese Erklärung untermauert das wiederholte Vorbringen von Oracle, wonach es sich als Unternehmen stets für ein Modell der offenen und kompatiblen IT-Plattform eingesetzt habe.
3.3.5Anreize für Oracle, sich gegenüber seinen nachgelagerten Wettbewerbern abzugrenzen
923In der Marktuntersuchung teilten etliche Softwareanbieter mit, dass ihrer Ansicht nach für Oracle der Anreiz bestünde, eine Abschottung auf dem Vorleistungsmarkt einzuleiten, indem es die Kosten der Konkurrenten für den Zugang zu Java erhöht. Diese Softwareanbieter befürchteten insbesondere, dass Oracle die Lizenzbedingungen verschlechtern könnte, indem es den Lizenzen Beschränkungen auferlegt, die Anforderungen seiner TCK-Lizenzen ändert, die Lizenzgebühren erhöht, die Java-Lizenzen für Wettbewerber nur verzögert zur Verfügung stellt, die Wettbewerber technisch benachteiligt, bei der Entscheidung, welche Produkte zertifiziert werden, selektiv vorgeht oder die Zertifizierung verzögert.
924Das Produktportfolio von Oracle unterscheidet sich von demjenigen von Sun. So ist Oracle ein führender Anbieter von Datenbanksystemen, Middleware und Softwareanwendungen, während Sun nur in einer begrenzten Anzahl der Märkte tätig ist, in denen auch Oracle aktiv ist. Java stellt jedoch einen wichtigen Inputfaktor für zahlreiche dieser Produkte dar, insbesondere für Middleware und für Softwareanwendungen, sowohl von Oracle als auch etlicher seiner Wettbewerber.
925Daher besteht die Möglichkeit, dass sich durch diesen Zusammenschluss die Motivation des fusionierten Unternehmens wandelt, etwa durch eine Steigerung der Kosten, die Konkurrenten für den Zugang zu Java aufwenden müssen, eine Abschottung auf dem Vorleistungsmarkt zu bewirken. Eine solche Abschottung würde potenziell Verbraucher schädigen, da es einige Wettbewerber ausschließen oder an den Rand drängen würde, die Marktmacht des fusionierten Unternehmens auf verbundenen Märkten stärken würde und höhere Preise bei einigen Softwareprodukten zur Folge hätte.
926Die Kommission hat zur Beurteilung der Motivation, eine Abschottung auf dem Vorleistungsmarkt zu bewirken, den potenziellen Nutzen und die potenziellen Kosten für das fusionierte Unternehmen aus einem solchen Verhalten untersucht.
927Der potenzielle Nutzen, den das fusionierte Unternehmen aus einer solchen Abschottung ziehen würde, bestünde in einer verbesserten Wettbewerbssituation gegenüber den Konkurrenten, die Java als wichtigen Inputfaktor für die entsprechenden konkurrierenden Anwendungen und Middleware-Produkte nutzen. Ausgeschlossene Wettbewerber wären entweder gezwungen, höhere Kosten für einen entscheidenden Inputfaktor zu akzeptieren, oder eine kostspielige und langwierige Neufassung ihrer Anwendungen vorzunehmen, um nicht länger auf Java angewiesen zu sein. Die ausgeschlossenen Wettbewerber könnten aber auch versuchen, auf einen anderen, Java ähnlichen Rahmen auszuweichen, der nicht von den geistigen Eigentumsrechten des fusionierten Unternehmens abhängt.
928Java ist ein etablierter und weit verbreiteter Rahmen für Softwaresysteme und die Kompatibilität von Softwareprodukten mit Java ist folglich von besonders großem Wert für Kunden. Sollte es gelingen, die Wettbewerber erfolgreich von dem Zugang zu Java auszuschließen, könnte die Folge – auch bei Wettbewerbern, die die Kosten für eine Neuprogrammierung ihrer Anwendungen nicht scheuten – sein, dass sie sich nicht länger auf Java stützen, da sie dem fusionierten Unternehmen weniger Wettbewerbsdruck entgegensetzen können, weil ihre Kunden nicht Java-kompatible Softwareprodukte unabhängig von ihren jeweiligen Funktionalitäten vermutlich weniger schätzen.
929Die Kosten, die das fusionierte Unternehmen für eine Abschottung der Wettbewerber auf sich nehmen müsste, sind auf der anderen Seite jedoch potenziell beträchtlich.
930Die Abschottung könnte für das fusionierte Unternehmen einen Einkommensverlust zur Folge haben, da die Java-Lizenzen, die gegenwärtig an die Wettbewerber vergeben werden, ausgeschlossen wären. Dies wäre vermutlich kein sehr beträchtlicher Verlust, da wenige Unternehmen aktuell Java-Lizenzen benötigen und erwerben. Daher ist dies nicht der entscheidende Faktor auf der Kostenseite der Analyse der Anreize. Streng wirtschaftlich gesehen belaufen sich die Lizenzeinnahmen von Sun in Verbindung mit Java auf schätzungsweise […]*. Oracle erwirtschaftete im Gegensatz dazu 2007 Einnahmen von […]* im EAS-Segment (Marktanteil [5-10]* %) und […]* im Marktsegment Middleware (Marktanteil [10-20]* %). Die Abschottung nachgelagerter Wettbewerber würde daher zu relativ begrenzten Verlusten bei den Lizenzen für geistige Eigentumsrechte an Java führen, die Attraktivität der Produkte von Wettbewerbern Oracles auf den EAS- oder Middleware-Märkten jedoch erheblich mindern.
Noch bedeutsamer wären die Folgen einer Abschottung von Wettbewerbern durch den Verlust der Unterstützung, die Java zurzeit bei den Kunden genießt. Dieser
932Wirtschaftszweig ist durch starke Netzwerkeffekte gekennzeichnet und der Wert, den die Java-Kompatibilität von Anwendungen für Kunden darstellt, hängt von der breiten Anerkennung von Java als Rahmen für Softwareentwicklung ab. Die starken Netzwerkeffekte in Verbindung mit Java gingen zusammen mit dem Verlust der Unterstützung der Community für Java verloren, wenn eine solche Abschottungsstrategie gefahren würde.
933Nach einer erfolgreichen Abschottung der Wettbewerber wird das fusionierte Unternehmen kaum in der Lage sein, den Status, den Java zurzeit genießt und der aus den Netzwerkeffekten einer breiten Community aktiver unabhängiger Entwickler und Softwareanbieter erwachsen ist, zu erhalten. Das würde zu einem erheblichen Wertverlust der Java-kompatiblen Anwendungen und von Java als Rahmen für Anwendungsentwicklungen selbst führen. Java-Kompatibilität stellt zurzeit ein entscheidendes Wertversprechen und einen wichtigen Wettbewerbsfaktor für etliche Softwareprodukte von Oracle dar, die infolge einer Abschottung zumindest teilweise geschwächt würden.
934Der Java-Rahmen und die Java-Kompatibilität stellen zurzeit einen wesentlichen Wettbewerbsfaktor für die Java-basierten und Java-kompatiblen Lösungen von Oracle im Vergleich zu anderen Softwareanbietern wie etwa Microsoft dar, die sich nicht in diesem Ausmaß auf Java und die Java-Kompatibilität stützen, sondern ihre Anwendungen eher auf anderen Rahmen aufbauen (z. B. .NET). Diese könnten daher von einer solchen Abschottung profitieren.
935Die Abschottung und die sich daraus ergebenden Verluste in Form von Netzwerkeffekten würden die Wettbewerbsfähigkeit der Softwareprodukte des fusionierten Unternehmens selbst beeinträchtigen im Vergleich zu anderen Softwareanbietern, die sich auf andere Rahmen stützen. Diese Faktoren würden also dazu führen, dass die Wettbewerbsfähigkeit des fusionierten Unternehmens gegenüber zumindest einigen bedeutenden Wettbewerbern durch die Abschottung erheblich geschwächt würde.
936Als Folge der Versuche, Wettbewerber auszugrenzen, könnten zudem Ableger von Java auftauchen, da Softwareanbieter sich um Alternativen bemühen würden. Dies würde den Zweck der Abschottung, die Kosten der Konkurrenten zu steigern, in gewissem Maße aushebeln, da diese weiterhin Ableger von Java als Inputfaktor für ihre Softwareentwicklung verwenden könnten. Noch mehr ins Gewicht fiele jedoch die Aufsplitterung und die Auflösung des Java-Standards, der den Verlust der Netzwerkeffekte zur Folge hätte und den Wert der Java-Kompatibilität von Anwendungen weiter reduzieren würde. Unter den am meisten von solchen Auswirkungen betroffenen Anwendungen wären höchstwahrscheinlich auch die Java-kompatiblen Anwendungen des fusionierten Unternehmens. Die daraus resultierende Auflösung des Java-Standards würde jedoch den Wert der Java-kompatiblen Anwendungen sowohl der ausgegrenzten Wettbewerber als auch des fusionierten Unternehmens gegenüber solchen Wettbewerbern schwächen, die sich nicht in erheblichem Ausmaß auf den Java-Rahmen stützen und ihre Wertversprechen auf proprietären Alternativen aufbauen.
Alles in allem wird der Schluss gezogen, dass der Nutzen einer solchen Abschottung des Zugangs zu Java die Kosten eines solchen Verhaltens für das fusionierte Unternehmen wahrscheinlich nicht übersteigen würde und dass für das fusionierte Unternehmen daher kein Anreiz zu einer solchen Abschottung besteht.
3.3.6Auswirkungen auf den Markt
Angesichts der Tatsache, dass Oracle wahrscheinlich nicht in der Lage ist oder sich dazu veranlasst sieht, sich gegenüber seinen nachgelagerten Wettbewerbern abzuschotten, ist eine Prüfung der Auswirkungen des Zusammenschlussvorhabens auf einen wirksamen Wettbewerb nicht erforderlich. Jedoch ist erneut anzumerken, dass Oracle mit der Übernahme der Stellung von Sun im JCP ein großes Interesse daran haben wird, dass Java technisch auf dem neuesten Stand sowie als offenes, transparentes und standardisiertes Verfahren einheitlich bleibt. Die Auswirkungen auf den Markt könnten daher positiver Natur sein, die Stellung von Java stärken und Vorteile für den Wirtschaftszweig und für die Verbraucher mit sich bringen.
3.4Schlussfolgerung
938Da Oracle angesichts des Vorstehenden nicht in der Lage sein wird oder sich veranlasst sehen wird, seine nachgelagerten Wettbewerber auszuschließen, wird der Schluss gezogen, dass das Zusammenschlussvorhaben – was die Lizenzvergabe für die Rechte am geistigen Eigentum in Verbindung mit der Java-Entwicklungsumgebung betrifft – nicht zu einer signifikanten Beeinträchtigung des wirksamen Wettbewerbs führt.
E.IT-Stack
Sachlich relevanter Markt
939Abgesehen vom Datenbank- und Middleware-Markt, die bereits in Abschnitt B und C des vorliegenden Beschlusses erläutert wurden, sind Oracle und Sun auch auf dem Markt für Server, Speicherlösungen, Betriebssysteme und EAS tätig.
1.1Server
940Die Anmelderin vertritt die Ansicht, dass der relevante Markt für Server in drei Segmente für Low-End-, Mid-Range- und High-End-Server unterteilt werden sollte.
Die Marktuntersuchung der Kommission in ihrer vorangegangenen Entscheidung in der Sache HP/Compaq hat ergeben, dass eine Abgrenzung des sachlich relevanten Markts nach Preisspanne sachdienlich wäre.550 Die Definition des sachlichen Markts wurde letztendlich offen gelassen. Im Rahmen des vorliegenden Beschlusses kann die exakte Definition des sachlichen Markts offen gelassen werden.
1.2Speicherlösungen
942Nach Meinung der Anmelderin existiert ein einziger Markt für Speicherlösungen, der alle Arten von Datenträgern, die zu Speicherungszwecken genutzt werden, umfasst.
943Im Hinblick auf Speicherlösungen hat die Kommission in einer zurückliegenden Sache potenzielle sachliche Märkte getrennt nach verwendetem Speichermedium (wie z. B. Festplatte, optische Platte und Band) identifiziert. Im Rahmen des vorliegenden Beschlusses kann die exakte Definition des sachlichen Markts in Bezug auf Speicherlösungen offen gelassen werden.
550Siehe Entscheidung der Kommission in der Sache M.2609 – HP/Compaq vom 31. Januar 2002.
551Siehe Entscheidung der Kommission vom 26. August 2005 in der Sache M.3866 – Sun/Storagetek.
1.3. Betriebssysteme
944Die Anmelderin betrachtet als relevanten Markt den Markt für Serverbetriebssysteme, unterteilt in die Betriebssysteme für drei unterschiedliche Arten von Servern, nämlich Betriebssysteme für Einstiegs- oder Arbeitsgruppenserver, Mid-Range-Server und High-End-Server.
945In der Entscheidung in der Kartellsache Microsoft definierte die Kommission die Märkte für Betriebssysteme, insbesondere den Markt für Arbeitsgruppenserver-Betriebssysteme, unter Anwendung eines funktionalen Ansatzes, d. h. verschiedene Serverbetriebssysteme wurden demselben Markt zugeordnet, wenn sie die gleiche Funktionalität bereitstellten, auch wenn sie auf verschiedenen Prozessoren liefen oder unterschiedlichen „Familien“ von Betriebssystemen angehörten (wie z. B. Unix oder Windows).
Im Rahmen des vorliegenden Beschlusses kann die exakte Definition des sachlichen Markts im Hinblick auf Betriebssysteme offen gelassen werden.
1.4. EAS
947In der Entscheidung in der Sache Oracle/Peoplesoft definierte die Kommission den EAS-Markt als Unterkategorie von Unternehmensanwendungssoftware (im Gegensatz zu Verbrauchersoftware) bestehend aus: (i) Unternehmensanwendungen und (ii) Dienste in Bezug auf die Implementierung und Nutzung solcher Software (dies kann Integrations-, Unterstützungs- und Wartungs-, Schulungs- und/oder Hostingdienste beinhalten). Ferner stellte die Kommission fest, dass der EAS-Markt in verschiedene Kategorien „je nach ihrer Funktionalität“ unterteilt werden könnte, wie beispielsweise Unternehmensressourcenplanung (Enterprise Resource Planning – „ERP“), Management der Kundenbeziehungen (Customer Relationship Management – „CRM“) und Lieferkettenmanagement (Supply Chain Management – „SCM“), gelangte aber lediglich zu dem Schluss, dass für zwei Unterkategorien von ERP (Finanzverwaltungssysteme (Financial Management Systems – „FMS“) und Personalverwaltungssysteme (Human Resources – „HR“)) getrennte Märkte vorhanden seien.
Im Rahmen des vorliegenden Beschlusses kann die exakte Definition des sachlichen Markts im Hinblick auf EAS offen gelassen werden.
2. Räumlich relevanter Markt
949Die Anmelderin trägt vor, dass die räumlich relevanten Märkte für Server, Speicherlösungen und Betriebssysteme eine weltweite Ausdehnung besitzen.
552Siehe Entscheidung der Kommission vom 24. April 2004 in der Sache COMP/C-3/37.792 – Microsoft .
553Siehe Entscheidung der Kommission vom 26. Oktober 2004 in der Sache M.3216 – Oracle/Peoplesoft, Randnummer 15.
554Siehe Entscheidung der Kommission vom 26. Oktober 2004 in der Sache M.3216 – Oracle/Peoplesoft, Randnummer 18.
In früheren Fällen gelangte die Kommission zur Ansicht, dass die Märkte für Server, Speicherlösungen und EAS zumindest EWR-weit sind. In der Entscheidung Oracle/Peoplesoft stellte die Kommission ebenfalls fest, dass der räumlich relevante Markt für EAS zumindest EWR-weit ist, ließ die Marktdefinition aber letztlich offen. Die Kommission stellte in der Kartellsache Microsoft fest, dass die Märkte für Betriebssysteme weltweit sind. Für den vorliegenden Beschluss kann die exakte geografische Ausdehnung der Märkte für Server, Speicherlösungen, EAS und Betriebssysteme offen gelassen werden.
3. Wettbewerbsrechtliche Würdigung
3.1. Position der beteiligten Unternehmen im so genannten „Technology Stack“
951Die geschätzten Marktanteile des fusionierten Unternehmens in den verschiedenen Ebenen des Technology Stack sind auf der Grundlage einer breit gefassten Marktdefinition mindestens wie folgt.
Tabelle 10: Marktanteile von Oracle und Sun – 2007
Oracle Sun - [10-20]* % % - [5-10]* % (2006) % [0-5]* % (2008) [0-5]* % (2007) -
Hardware/Server Betriebssystem Datenbanken [40-50]* % (2008) [10-20]* % (2007) % [5-10]* %
Middleware Unternehmens-anwendungssoftware Quelle: IDC
952Die Anmelderin zufolge sind die wichtigsten Wettbewerber im Hardware-/Servermarkt IBM, HP und Dell, im Markt für Betriebssysteme IBM, Microsoft, Linux und HP und im Markt für EAS-Software IBM, SAP und Microsoft.
953Das fusionierte Unternehmen wird neben IBM als einziges Unternehmen alle Elemente des Technology Stack anbieten und intern herstellen. Ferner wird das fusionierte Unternehmen im Datenbankbereich Marktführer sein. Jedoch werden auf jeder Ebene des Stack weiterhin Wettbewerber verbleiben.
3.2. Abschottung des Zugangs konkurrierender Datenbankanbieter gegenüber Kunden, die das Betriebssystem Solaris von Sun nutzen
954Die Kommission prüfte die Frage, ob Oracle durch den Erwerb des Betriebssystems Solaris von Sun seine Kontrolle über den Markt für Datenbanken weiter verstärken könnte. Im Rahmen dieser Schadenstheorie bewertete die Kommission, ob Oracle die Möglichkeiten und auch die Anreize hätte, die Kompatibilität des Betriebssystems Solaris mit konkurrierenden Datenbanken einzuschränken, um Kunden, die dieses Betriebssystem nutzen, zur Migration zur Datenbank von Oracle zu bewegen. Dieses Argument wurde von einem der Beschwerde führenden Wettbewerber vorgebracht.
555Siehe Entscheidung der Kommission vom 31. Januar 2002 in der Sache M.2609 – HP/Compaq und Entscheidung der Kommission vom 26. August 2005 in der Sache M.3866 – Sun/Storagetek.
955Es erscheint jedoch unwahrscheinlich, dass eine solche Vorgehensweise für Oracle von Vorteil sein könnte und dass Oracle somit Anreize besäße, auf diese Vorgehensweise zurückzugreifen. Der Marktanteil des fusionierten Unternehmens am Markt für Betriebssysteme beträgt weniger als [5-10]* % und ist somit beschränkt. Wenn das fusionierte Unternehmen die Kompatibilität von Solaris mit anderen Datenbanken als der eigenen verschlechtern würde, würden einige Kunden Solaris gegen ein anderes Betriebssystem eintauschen, um Stagnation zu vermeiden.
956Die Marktuntersuchung zeigt, dass obwohl die Mehrheit der Kunden glaubt, dass es technisch möglich wäre, die Kompatibilität von Solaris mit anderen Datenbanken zu verschlechtern, die Mehrheit auch der Ansicht ist, dass Oracle diesem Ansatz wahrscheinlich nicht folgen wird. Die Verschlechterung der Kompatibilität von Solaris hätte durch den verringerten Umsatz mit Solaris negative Auswirkungen auf das fusionierte Unternehmen und dessen Gewinne. Die Wettbewerber sahen mehrheitlich keine Probleme einer potenziellen vertikalen Abschottung der Datenbankanbieter.
957Ferner kann die technische Verknüpfung der Produkte miteinander auch als effizient betrachtet werden, da es die Integration der verschiedenen Komponenten des Technology Stack vereinfacht und somit die mit den IT-Systemen verbundenen Integrationskosten und -Risiken seitens der Kunden verringert werden.
958Daher wird der Schluss gezogen, dass die vertikale Integration des fusionierten Unternehmens im Datenbankmarkt sowie im Markt für Betriebssysteme wahrscheinlich nicht zu einer Abschottung des Markts für andere Datenbankanbieter führen wird.
3.3. Bewertung der konglomeraten Effekte
959Das fusionierte Unternehmen wird ein vollständig vertikal integriertes Unternehmen im Bereich Hardware/Software sein. Die Beschwerdeführer haben vorgebracht, dass das fusionierte Unternehmen wahrscheinlich die Gelegenheit nutzen wird, seine Wettbewerber auf dem Software- oder Hardwaremarkt auszugrenzen. Insbesondere wird behauptet, dass das fusionierte Unternehmen die Kompatibilität eines seiner Produkte auf einer Ebene des Technology Stack mit Produkten von Wettbewerbern auf anderen Ebenen beschränken könnte. Das fusionierte Unternehmen könnte beispielsweise die Kompatibilität seines Betriebssystems Solaris mit der Hardware oder Software von Wettbewerbern herabsetzen. Dies würde dazu führen, dass Kunden, die Solaris verwenden, andere Elemente aus dem Stack (Server, Datenbanken, Software) des fusionierten Unternehmens kaufen, und zwar selbst zu höheren Preisen.
960Es scheint jedoch unwahrscheinlich, dass das fusionierte Unternehmen von einer solchen Vorgehensweise profitieren könnte. Auf allen Ebenen des Technology Stack, ausgenommen Datenbanken, ist der Marktanteil von Oracle begrenzt und kann kaum ausgenutzt werden. Wenn das fusionierte Unternehmen beispielsweise die Kompatibilität mit anderen Servern als den Servern des fusionierten Unternehmens einschränken würde, besteht die Wahrscheinlichkeit, dass Kunden Solaris eher gegen ein anderes Betriebssystem eintauschen. Im Hinblick auf Datenbanken bestünde im Falle der Verknüpfung der Datenbanken von Oracle mit anderen Produkten der Ebene die Gefahr, dass wertvollere Kunden auf anderen Ebenen abspringen, wo die Bruttomargen geringer sind (beispielsweise betragen die Bruttomargen von Sun bei Hardware ungefähr […]*, während die Bruttomargen von Oracle im Softwarebereich ungefähr bei […]* liegen).
961Die Marktuntersuchung zeigt, dass eine Mehrheit der Kunden die Ansicht vertritt, dass das fusionierte Unternehmen nicht in der Lage wäre, seine Wettbewerber aufgrund seiner Präsenz im gesamten Stack auszugrenzen. Obwohl der Zusammenschluss als erheblicher Umbruch für die IT-Branche angesehen wird, sehen die Befragten den Wettbewerb von anderen Anbietern, die im gesamten Stack oder in größeren Teil davon präsent sind.
962Ferner kann die technische Verknüpfung der Produkte miteinander auch als effizient betrachtet werden, da es die Integration der verschiedenen Komponenten des Technology Stack vereinfacht und somit die mit den IT-Systemen verbundenen Integrationskosten und -Risiken seitens der Kunden verringert werden. Laut Marktuntersuchung teilen die Kunden insgesamt diese Ansicht.
963Es erscheint unwahrscheinlich, dass die vertikale Integration des fusionierten Unternehmens im Technology Stack negative Effekte mit sich bringen wird. Die Marktuntersuchung ergab keinerlei Anhaltspunkte, dass das Zusammenschlussvorhaben alles in allem konglomerate wettbewerbsschädigende Wirkungen hervorrufen würde.
3.4. Schlussfolgerung
964Auf der Grundlage der vorangegangenen Erwägungen wird der Schluss gezogen, dass das Zusammenschlussvorhaben aufgrund der Präsenz des fusionierten Unternehmens im IT-Stack zu keiner erheblichen Einschränkung des wirksamen Wettbewerbs führen würde.
HAT FOLGENDEN BESCHLUSS ERLASSEN:
Artikel 1
Artikel 1Der angemeldete Zusammenschluss, dem zufolge Oracle Corporation im Sinne von Artikel 3 Absatz 1 Buchstabe b der Verordnung (EG) Nr. 139/2004 die alleinige Kontrolle über Sun Microsystems Inc. erwirbt, ist mit dem Gemeinsamen Markt und dem EWR-Abkommen vereinbar.
Artikel 2
Dieser Beschluss ist gerichtet an:
Oracle Corporation 500 Oracle Parkway United States of America CA 94065 Redwood Shores
Brüssel, den 21.1.2010
Für die Kommission (unterzeichnet) Neelie KROES Mitglied der Kommission
212