Wenn sich Hardware immer mehr über die Anwendungssoftware verkauft: Wie kann der Lieferant seinen Hardware-Absatz sichern? Darf er den Einsatz der von ihm gelieferten Programme auf seine Hardware beschränken, so daß er Ersatzbeschaffungen des Anwenders auf sich lenken kann? Dieser Frage kommt zunehmende Bedeutung zu, wenn in Zukunft immer mehr standardisierte Systemsoftware als Basis für die Entwicklung von Standardprogrammen verwendet wird, zum Beispiel Unix mit C als Programmiersprache.
Dieses Problem existiert schon ohne die Verwendung standardisierter Systemsoftware, zum Beispiel bei Ablösungen von MAI-Anlagen durch den Einsatz von Btx als Cross-Compiler, wobei allerdings auch Modifikationen des Programms erforderlich sind. Siemens sowie AT&T haben Werkzeuge entwickelt, um IBM-Systeme /36 ablösen zu können und den Kunden den Weg zu Unix statt zur AS/400 zu öffnen.
Daß ein Lieferant mit der Bindung an bestimmte Hardware berechtigte Interessen verfolgt, zeigt die Praxis mancher Softwarehäuser, die ihre Programme nur für den Einsatz auf bestimmten DV-Anlagen freigeben.
Beschränkte Freigabe durch Softwarehäuser
Wenn ein Softwarehaus Programme vertreibt, die mit standardisierter Systemsoftware entwickelt wurden, hat es erst einmal gar kein Interesse daran, einen bestimmten Hardwarehersteller zu fördern. Trotzdem arbeiten Softwarehäuser häufig mit der Vertragsklausel, daß der Anwender sein Programm nur auf einer DV-Anlage einsetzen darf, für die das Softwarehaus das Programm freigegeben hat, oder es heißt, daß der Anwender das Programm zunächst auf der vertraglich vorgesehenen Anlage nutzen darf und daß er diese gegen eine andere austauschen darf; wenn das Softwarehaus den Einsatz des Programmes auf dieser anderen Anlage freigegeben hat.
Diese Einschränkung beruht auf der Erfahrung daß nicht alle DV-Anlagen, die einem bestimmten Standard entsprechen sollen, das auch tatsächlich tun. Das Softwarehaus läuft also Gefahr, daß beim Einsatz seines Programmes unerklärliche Fehlersituationen auftreten. Ihm droht damit zusätzlicher Aufwand durch die Störungssuche. Sodann unterliegt er dem praktischen Zwang, dem Mangel an Kompatibilität derjenigen Anlage, die der Anwender einsetzt durch programmtechnische Maßnahmen zu begegnen. Rein rechtlich müßte der Anwender diesen Aufwand bezahlen. In der Praxis läßt sich das aber nicht immer durchsetzen. Außerdem läuft das Softwarehaus Gefahr, daß sein Ruf beeinträchtigt wird: Der Anwender wird vernehmlicher das Vorliegen von Fehlern verkünden als die spätere Richtigstellung. Außerdem wird der Lieferant der "fremden" DV-Anlage sich darauf berufen, daß die Ursache nicht darin liege, daß seine DV-Anlage nicht dem Standard entspräche, sondern daß sich das Softwarehaus nicht an den Standard gehalten habe.
Selbst wenn letzteres stimmt, ist verständlich, daß das Softwarehaus die Programme nur für solche DV-Anlagen freigeben will, auf denen es die Programme vorher erfolgreich getestet hat. Insgesamt muß man das berechtigte Interesse des Softwarehauses an einer solchen einschränkenden Klausel anerkennen.
Meines Erachtens hat die Sache aber einen Haken für das Softwarehaus. Es müßte sich nach Treu und Glauben verpflichten, die Ablauffähigkeit auf in Betracht kommenden Anlagen zu überprüfen und sein Programm für den Einsatz auf diesen Anlagen nach erfolgreichem Test freizugeben. Das Softwarehaus braucht aber nur Anlagen mit einem relevanten Marktanteil zu prüfen, und das auch nur dann, wenn der Aufwand verhältnismäßig ist. Es muß keine anderen Anlagen kaufen, um den Test durchführen zu können.
Herstellerbindung: Portierung nicht nötig
Hersteller wollen den Einsatz der Software meist überhaupt auf ihre Hardware beschränken. Zum Teil verwenden sie dazu die Klausel, daß das Programm nur "auf der bestimmten Anlage" eingesetzt werden kann (das Wort "bestimmt" entspricht dem "designated" aus US-amerikanischen Verträgen).
Diese Klausel hindert den Anwender aber nicht daran, daß Programm auf einer anderen Anlage einzusetzen. Vertragsteile dieser Art sind dahingehend auszulegen, daß sie die Nutzung nur in der Weise einschränken, daß der Anwender das Programm immer nur auf einer Anlage einsetzen darf. Wenn die ursprünglich "bestimmte" Anlage aus Altersgründen oder aufgrund anderer Motivationen ausgesondert wird, soll das Nutzungsrecht am Anwendungsprogramm nicht erlöschen.
Selbst wenn man das Gegenteil annehmen würde, änderte sich am Ergebnis nichts. Eine Klausel, die das Nutzungsrecht an Anwendungssoftware vollständig an die im Vertrag angegebene DV-Anlage bindet, wäre wegen groben Verstoßes gegen Treu und Glauben unwirksam (1).
Nutzungsrecht nicht nur auf Hersteller-Anlagen
Der Hersteller muß also schon ausdrücklich regeln, daß das Programm nur auf einer Ersatzanlage eingesetzt werden darf, die vom Hersteller stammt. Solch eine Klausel ist allerdings wahrscheinlich nach Kartellrecht unzulässig (° 18 Gesetz gegen Wettbewerbsbeschränkungen). Dann kommt es nicht darauf an, daß die Klausel in den Allgemeinen Geschäftsbedingungen enthalten ist oder in den Einzelverträgen aufgenommen wird.
Es geht um die Koppelung von Produkten, und zwar nicht in der üblichen Variante der Koppelung bei gleichzeitiger Lieferung, sondern in der Form, daß die derzeitige Lieferung von Anwendungssoftware zur künftigen Lieferung von Hardware desselben Lieferanten führen muß. Die Koppelung ist bereits bei gleichzeitiger Lieferung höchst bedenklich, wenn sachlich nicht zueinander gehörige Waren abgenommen werden sollen. Hardware plus Systemsoftware und Anwendungssoftware sind aber nicht zueinander gehörige Waren im kartellrechtlichen Sinne.
Anwender darf Standardsoftware ändern
Für den Zeitpunkt der ersten Beschaffung hat der Käufer noch die Auswahl zwischen verschiedenen Kombinationen von DV-Anlagen und Anwendungsprogrammen. Dementsprechend kann man argumentieren, daß der Lieferant hier die Koppelung noch nicht mißbraucht. Wenn der Anwender sich aber für einen bestimmten Lieferanten entschieden hat, ist er auf diesen angewiesen. Dann mißbraucht der Lieferant die Koppelung, wenn er verlangt, daß der Hardware-Ersatz von ihm bezogen werden muß. Das Argument der Rufschädigung reicht dafür nicht aus, weil der Hersteller gar nicht anstrebt, die Software für solche DV-Anlagen freizugeben, auf denen sie auch ohne Rufschädigung eingesetzt werden kann.
Wenn eine solche Klausel Teil der Allgemeinen Geschäftsbedingungen ist, kann sie den Kunden überraschen. Sollte das der Fall sein, ist sie gemäß ° 3 AGB-Gesetz unwirksam. Es kommt hier darauf an, wie deutlich der Hersteller diese Einschränkung macht. Aber selbst, wenn er die Einschränkung deutlich macht, ist die Klausel wahrscheinlich wegen großer Unbilligkeit unwirksam (° 9 AGB-Gesetz).
Typischerweise steht der Wert der Anwendungssoftware etwa im Verhältnis von eins zu zwei zum Wert der DV-Anlage, wenn beides zusammen als Standardlösung erworben wird. Der Anwender würde durch diese Klausel zu einer bestimmten Ersatzbeschaffung gezwungen, die wesentlich teurer als die Anwendungssoftware kommt. Das gilt auch dann, wenn der Preis der Anwendungssoftware die Pflegevergütung einbezieht.
Muß das Programm portiert werden und sind deswegen Änderungen nötig, sind zwei Fälle zu unterscheiden:
- Das Programm soll in eine andere Systemumgebung portiert werden. Der Anwender will also künftig eigene Wege gehen. Der Lieferant kann dann nicht nur rechtlich, sondern auch geschäftspolitisch die weitere Betreuung der Programme ablehnen. Eine Gefährdung seines Rufes durfte er kaum zu befürchten haben, denn durch die Tatsache, daß das Programm in einer anderen Systemumgebung eingesetzt wird, kann auch ein DV Laie erkennen, daß der ursprüngliche Lieferant mit unerklärlichen Fehlern beim Programmeinsatz kaum etwas zu tun hat. Gerade ein Hersteller dürfte über die Identifikation mit seiner Hardware beim Einsatz seiner Programme in einer anderen Systemumgebung kaum noch mit Fehlern in Verbindung gebracht werden.
- Das Programm soll künftig auf einer DV-Anlage eingesetzt werden, die grundsätzlich, aber nicht vollständig denjenigen Standards folgt, auf welchen auch die bisherige Anlage basiert (zum Beispiel: eine Unix-Variante mit der Programmiersprache C wird durch eine andere ersetzt).
Grundsätzlich ist der Anwender berechtigt, erworbene Standardprogramme zu ändern (2). Das gilt auch dann, wenn das Programm urheberrechtlich geschützt ist. Der Anwender benötigt möglicherweise die Zustimmung durch den Hersteller. Sie darf nicht gegen Treu und Glauben verweigert werden. Liefert der Hersteller Quellcode statt Objektcode aus, liegt es nahe, daß er Änderungen und damit auch Portierungen erlauben will. Viele Hersteller aber verbieten den Anwender in ihren Allgemeinen Geschäftsbedingungen, Programme zu ändern, auch wenn sie diese in Quellcode erhalten haben. Ein solches Verbot ist meines Erachtens grundsätzlich wirksam (2).Der Hersteller kann also die Portierung über das Änderungsverbot grundsätzlich verhindern. Für die Zulässigkeit dieses Verbotes spricht insbesondere, daß der Hersteller Programme in compilierenden Sprachen in Objektcode liefern kann, so daß dem Anwender Änderungen ohnehin unmöglich sind. Deshalb darf der Anbieter sie meines Erachtens auch durch eine entsprechende Klausel in den Allgemeinen Geschäftsbedingungen verbieten, ohne schwerwiegend gegen Treu und Glauben zu verstoßen.
Zu bedenken ist allerdings, daß die Auslieferung von Quellcode nicht dazu dienen darf, dem Anwender Änderungen zu ermöglichen. Das wäre ein widersprüchliches Verhalten. Soll die Auslieferung im konkreten Fall Änderungen ermöglichen, gilt der Vorrang dieser konkreten Vereinbarung; das Verbot läuft dann ins Leere.
Man kann gegen das Änderungsverbot auch argumentieren, daß es deswegen zu weit gehe, weil der Anwender ja auf die weitere Betreuung verzichten könne, wenn er das Programm ändere. Meines Erachtens greift diese Überlegung nicht: Beim Änderungsverbot geht es nicht nur um die Verhinderung von Auseinandersetzung zwischen den Parteien wegen unerklärlicher Fehler. Auch der Ruf des Lieferanten könnte wegen solcher Fehler leiden. Weiterhin besteht die Gefahr, daß der Anwender, der selber DV-Laie ist, die Programme Dritten zur Kenntnis bringt. Diese könnten dann Know-how aus dem Programm gewinnen, was der Lieferant berechtigterweise verhindern will.
Zustimmungsvorbehalt für etwaige Änderungen
Angesichts der Unsicherheit, ob das Änderungsverbot wirklich wirksam ist, könnte die Lieferantenseite versuchen, sein Ziel mit Hilfe einer weniger weitgehenden Klausel zu erreichen, die mit größerer Wahrscheinlichkeit wirksam wäre: Änderungen bräuchten nicht verboten zu werden, sondern könnten unter den Vorbehalt der Zustimmung des Lieferanten gestellt werden. Solch ein Zustimmungsvorbehalt ist grundsätzlich akzeptabel, weil der Lieferant ein berechtigtes Interesse daran hat, im Einzelfall Änderungen zu verhindern oder auf die Durchführung Einfluß zu nehmen. Zum Beispiel kann er verhindern wollen, daß ein Konkurrent die Änderungen vornimmt. Auch muß das Softwarehaus seine künftige Verantwortung hinsichtlich der Pflege klären.
Entscheidung richtet sich nach der Interessenlage
Bei einer solchen Klausel könnte der Lieferant allerdings nach Treu und Glauben zur Zustimmung zu Änderungen verpflichtet sein. Die Entscheidung richtet sich nach der Interessenlage. Die Verweigerung ist nur zulässig, wenn keine schutzwürdigen Interessen des Lieferanten dagegenstehen und wenn keine überwiegenden Interessen des anderen die Zustimmung gebieten. Dabei darf das Interesse des Lieferanten, den Absatz seiner Hardware zu fördern, wegen der aufgeführten kartellrechtlichen Bedenken nicht berücksichtigt werden.
Hier sind die oben genannten zwei Fälle zu unterscheiden: Soll das Programm innerhalb des nicht ganz einheitlichen Standards portiert werden, gibt es gute Gründe, dem Einsatz der Programme auf angeblich kompatiblen Anlagen nicht zuzustimmen. Dann muß sich der Lieferant jedoch um die Freigabe seiner Programme auf ausreichend kompatible Anlagen bemühen. Gerade das aber will er nicht tun.
Sollen die Programme auf einen anderen Standard hin portiert werden, dürfen Probleme wie dargelegt kaum auf den Lieferanten zurückfallen. Eine Rufgefährdung ist kaum zu befürchten. Der Lieferant braucht die Programme auch nach der Portierung nicht mehr zu pflegen. Also kann er die Zustimmung kaum verweigern.
Über den Zustimmungsvorbehalt läßt sich die Lieferbindung also kaum erreichen. Es kommt darauf an, ob ein uneingeschränktes Änderungsverbot wirksam ist. Die Gerichte haben hier das letzte Wort.
Erneute Compilierung ist urheberrechtlich zulässig
Ist das Programm nicht in einer interpretativen Sprache, sondern in einer compilierenden geschrieben, muß es meist erneut übersetzt werden, damit es auf der anderen Anlage einsatzfähig ist. Voraussetzung dafür ist selbstverständlich, daß der Anwender das Programm im Quellcode erhalten hat. Das Programm wird durch die erneute Compilierung nicht im urheberrechtlichen Sinne geändert, sondern es wird ein weiterer Typ vom Vervielfältigungsstück hergestellt (ein anderes Objektprogramm). Dieser Vervielfältigungsakt liegt urheberrechtlich innerhalb des bestimmungsgemäßen Gebrauchs und ist deswegen zulässig. Er ruft auch nicht die im Zusammenhang mit der Freigabe von Programmen durch ein Softwarehaus dargelegten Gefahren hervor. +