Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.05.1990 - 

Darf Standard-Software auf spezielle Rechner festgelegt werden?

Trauma der Hersteller: Eigene Software auf fremden Systemen

25.05.1990

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?

Diese Frage wird besonders wichtig, wenn in Zukunft immer mehr standardisierte Systemsoftware als Basis für die Entwicklung von Standardprogrammen verwendet wird, zum Beispiel Unix mit C als Programmiersprache. Diese Frage ist auch schon ohne die Verwendung standardisierter System -software wichtig geworden, zum Beispiel bei Ablösungen von MAI-Anlagen durch Einsatz von bbx 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 verfolgen kann, zeigt die Praxis mancher Softwarehäuser auf, die ihre Programme nur für den Einsatz , auf bestimmten DV -Anlagen freigeben.

Beschränkte Freigabe durch Softwarehäuser

Wenn ein Softwarehaus Software vertreibt, die es unter standardisierter Systemsoftware entwickelt hat, hat es erstmal gar kein Interesse, einen bestimmten Hardware-Hersteller zu fördern. Trotzdem arbeiten solche Softwarehäuser häufig mit der Klausel, daß der Anwender sein Programm nur auf einer DV-Anlage nutzen darf und daß er diese gegen eine andere austauschen darf, wenn das Softwarehaus den Einsatz des Programms 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 Programms unerklärliche Fehlersituationen auftreten. Ihm droht damit zusätzlicher Aufwand erst einmal durch die Störungssuche.

Sodann unterliegt es dem plaktischen Zwang, den Mangel an Kompatibilität derjenigen Anlage, die der Anwender einsetzt und die nun einmal da ist, durch programmtechnische Maßnahmen in seinem Programm zu begegnen. Rein rechtlich müßte der Anwender diesen Aufwand bezahlen. In der Praxis läßt sich das aber nicht vollständig durchsetzen.

Außerdem läuft das Softwarehaus Gefahr, daß sein Ruf beeinträchtigt wird: Der Anwender wird lauter 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ß das Softwarehaus sich 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 ist das berechtigte Interesse des Softwarehauses an einer solchen einschränkenden Klausel anzuerkennen .

Meines Erachtens hat die Sache aber einen Haken für das Softwarehaus: Es dürfte 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 braucht keine anderen Anlagen zu kaufen, um den Test durchführen zu können. Hersteller wollen den Einsatz ihrer 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. Diese Klausel ist dahingehend auszulegen, daß sie die .Nutzung nur in der Weise einschränken will, daß der Anwender das Programm immer nur auf einer Anlage einsetzen darf. Wenn die ursprünglich "bestimmte" Anlage aus Altersgründen oder aus anderen Gründen ausgesondert wird, soll das Nutzungsrecht am Anwendungsprogramm nicht erlöschen.

Nutzung nur auf Anlagen des Herstellers

Selbst wenn man das Gegenteil annehmen würde, würde sich am Ergebnis nichts ändern. 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).

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 Einzelvertrag aufgenommen wird.

Es geht um die Koppelung von Produkten, und zwar nicht in der üblichen Variante der Koppelung bei gleichzeitiger Lieferung, sondern in der Variante, 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.

Zunächst hat der Käufer die Auswahl

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 erst einmal für einen bestimmten Lieferanten entschieden hat, ist er auf diesen angewiesen. Dann mißbraucht der Lieferant die Koppelung, wenn er ohne sachlich rechtfertigenden Grund verlangt, daß die Ersatzbeschaffung für die Nutzung der Software von ihm bezogen werden muß. Die 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.

Ist eine solche Klausel Teil von Allgemeinen Geschäftsbedingungen, kann sie für den Kunden überraschend sein. Ist das der Fall, 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 grober Unbilligkeit unwirksam (° 9 AGB-Gesetz): Typischerweise steht der Wert der Anwendungssoftware etwa im Verhältnis- von 1:2 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 ist. Das gilt auch dann, wenn man in den Preis der Anwendungssoftware die Pflegevergütung einbezieht.

Muß das Programm portiert werden und sind deswegen Änderungen nötig, ist zwischen zwei Fällen 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 mehr rechtlich, sondern auch geschäftspolitisch die weitere Betreuung der Programme ablehnen. Eine Gefährdung seines Rufes dürfte er kaum zu befürchten haben, denn die Tatsache, daß das Programm in einer anderen Systemumgebung eingesetzt wird, dürfte auch bei einem DV- Laien zu der Einstellung führen, 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 andere 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, denen auch die bisherige Anlage folgte (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 bedarf dann möglicherweise der Zustimmung durch den Hersteller. Diese Zustimmung darf aber 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 dem 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 ohnehin in Objektcode liefern kann, so daß er dem Anwender Änderungen ohnehin unmöglich machen kann. Dann darf er sie meines Erachtens auch durch eine entsprechende Klausel in der 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 widersprüchliches Verhalten. Soll die Auslieferung im konkreten Fall Änderungen ermöglichen, gilt der Vorrang dieser konkreten Vereinbarung; das Verbot läuft dann leer.

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 Änderungen

Angesichts der Unsicherheit, ob das Änderungsverbot wirklich wirksam ist, könne die Lieferantenseite versuchen, das 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 dem Vorbehalt der Zustimmung des Lieferanten gestellt werden. Solch ein Zustimmungsvorbehalt ist grundsätzlich akzeptabel, weil der Lieferant berechtigte Interessen hat, im Einzelfall Änderungen zu verhindern oder auf die Durchführung Einfluß zu nehmen (zum Beispiel daß ein Konkurrent nicht die Änderungen vornimmt) und seine künftige Verantwortung hinsichtlich der Pflege zu klären.

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 dagegen stehen 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 schon 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 aber um die Freigabe seiner Programme auf ausreichend kompatible Anlagen bemühen. Gerade das aber will er nicht tun .

Der Ruf ist nicht gefährdet

Sollen die Programme auf einen anderen Standard hin portiert werden, dürften 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 also darauf an, ob ein uneingeschränktes Änderungsverbot wirksam ist. Die Gerichte haben das Wort.

Zugangsverbot hilfreich

Ändern darf der Kunde - darf er sich dazu aber auch eines Softwarehauses bedienen? Dieses gewinnt damit Zugang zum Quellcode und damit zum Know-how des Lieferanten. Der mißbräuchlichen Nutzung des Programms ist damit die Tür geöffnet.

Eine Klausel in Allgemeinen Geschäftsbedingungen, daß der Anwender den Quellcode Dritten, auch anderen Softwarehäusern, nicht zur Kenntnis geben darf, läßt sich kaum als grob unfair und damit unwiksam einstufen. Man kann noch darüber diskutieren, ob eine solche Klausel eine Einschränkung haben muß, nämlich daß der Lieferant seine Zustimmung zur Portierung durch einen Dritten dann erteilen wird, wenn von diesem keine Gefahr droht.

Diese Einschränkung dürfte dem Kunden aber kaum etwas nutzen; denn ein Dritter, der die Programme routinemäßig portieren will, dürfte eine Gefahr darstellen. Es gibt also wahrscheinlich einen Weg, die Portierung zu verhindern.

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 urheberrechtlichen innerhalb des bestimmungsgemäßen Gebrauchs und ist deswegen urheberrechtlich zulässig. Er ruft auch nicht die im Zusammenhang mit der Freigabe von Programmen durch .ein Softwarehaus dargelegten Gefahren hervor.

(l) vergleiche Zahrnt, DV-Verträge: Rechtsfragen und Rechtsprechung, 1989, Kapitel 8.2.3(3)

(2) vergleiche Zahrnt (Fu 1), Kapitel 5.3.3.3

* Christoph Zahrnt, Dipl.-Volkswirt, Dr. jur. C. Z., Rechtsanwalt in Neckargemünd, beschäftigt sich ausschließlich mit DV-Verträgen und Rechtsschutz von Software

Empfehlungen an den Programmlieferanten, der die Nutzung seiner Standardprogramme auf seine Hardware beschränken will:

- Eine Klausel, daß die Programme nur auf der Hardware des Lieferanten eingesetzt werden dürfen, nutzt wahrscheinlich nichts.

- Eine Klausel, daß die Programme nur auf denjenigen Anlagen eingesetzt werden dürfen, für die sie freigegeben sind, nutzt nur dann etwas, wenn der Lieferant die Programme auch für solche fremden Anlagen freigibt, auf denen sie risikolos eingesetzt werden können.

- Muß das Programm zwecks Portierung geändert werden, könnte ein Änderungsverbot helfen. Ob das in Allgemeinen Geschäftsbedingungen wirksam ist, ist ungewiß.

- Der wahrscheinlich beste Schutz besteht darin, dem Anwender zu verbieten, die Programme einem Dritten, der die Portierung vornehmen soll, zur Kenntnis zu geben.