Allenthalben beginnen hektische Arbeiten in Umstellungsprojekten. Wenig Beachtung finden dabei rechtliche Fragen, die die Aufgabe schnell zum Scheitern bringen könnten: Muß der Anbieter von RZ-Dienstleistungen die Umstellung im laufenden Vertrag überhaupt ausführen oder zumindest als Zusatzleistung anbieten? Oder darf man selbst erforderliche Codeänderungen an Lizenzsoftware ohne Zustimmung vornehmen? Welche Gewährleistung übernehmen Tool-Anbieter? Und was ist zu tun, wenn die anzupassenden Sourcen undokumentiert oder teilweise nicht mehr auffindbar sind? Dürfen sie aus dem Objektcode der Lizenzsoftware dekompiliert werden?
Anpassung ist Teil der Wartungsleistung
Ein häufig auftretendes Problem beschäftigt sich mit der Frage, ob ein Wartungsanbieter grundsätzlich auch die Umstellungsarbeiten vornehmen muß. Die laufende Systemwartung umfaßt keineswegs zwingend immer auch komplexe Anpassungsleistungen wie die Datumsumstellung oder Euro-Anpassung. Vielmehr wäre im Einzelfall zu prüfen, was die Vertragsparteien jeweils vereinbart haben oder was mangels ausdrücklicher Vereinbarungen für den Anbieter vorhersehbar zur Leistung gehören sollte. Wenn der Anbieter die umfassende Betreuung einer erkennbar datumsabhängigen Anwendung, die zum Beispiel 1997 installiert und mindestens fünf Jahre genutzt werden kann, zugesichert hat, ist er zur Anpassung ohne Zusatzvergütung als Teil der Wartungsleistung verpflichtet.
Das wartungstypische bloße Aufrechterhalten der Funktionalität einer Anwendung verpflichtet aber in der Regel nicht zu solchen Änderungsleistungen. Am Anfang von Verhandlungen ist also sorgfältig zu prüfen, was der Anbieter schon aus laufenden Verträgen abzudecken hat und inwieweit er - zusätzlich in Rechnung gestellte - Änderungen oder Erweiterungen anbietet. Er muß grundsätzlich nicht von vornherein Zusatzleistungen wie etwa Versionen für das Jahr 2000 entwickeln und im Angebot haben. Ein Grund mehr, rechtzeitig nach den Planungen des Anbieters zu fragen.
Bei Abschluß eines neuen Vertrags über die Entwicklung von Software oder deren Überlassung und Anpassung ist dringend zu empfehlen, den Jahrtausendwechsel zu vereinbaren.
Von Anfang an ist das wichtig, um Schwierigkeiten bei der Anpassungsverpflichtung oder Anpaßbarkeit der Software aus dem Weg zu gehen. Konkret bedeutet dies, daß die Software ausschließlich ein vierstelliges Datenfeld für die Jahreszahl im jeweiligen Anwendungszusammenhang aufweisen muß. Bereits kontraktierte Projekte nachzubessern, kann Zusatzkosten verursachen. Und diese fallen umso höher aus, je später die Korrekturen im Verlauf des Entwicklungsprozesses erfolgen.
Keine Abnahme ohne Akzeptanz von 1. 1.
Fehlt es in bestehenden Verträgen an ausdrücklichen Regelungen, so ist die Umstellung vom Anbieter dennoch zu leisten, wenn sich, ähnlich wie bei der Wartung, folgende Frage bejahen läßt: Gehört die Datumsumstellung zum vertraglich vorausgesetzten Gebrauch der zu entwickelnden Software, da diese erkennbar über den Jahrtausendwechsel genutzt werden soll? In diesem Fall sollte keine Schlußabnahme erfolgen, wenn das System das Datum "1.1.2000" nicht akzeptiert.
Als Gegenbeispiel läßt sich die Jahressteuer-Software, die nur für jeweils einen steuerlichen Veranlagungszeitraum ausgelegt ist, anführen. Hier bleibt dem Anwender nichts anderes übrig, als eine neue Version zu erwerben. Weder muß der Anbieter die vorhandene Software anpassen, noch darf der Kunde selbst Änderungen vornehmen - sofern sie überhaupt technisch möglich sind.
Updates häufig Sache des Anwenders
Es empfiehlt sich, Datums- und Euro-Umstellung dann zu kombinieren, wenn ohnehin eine ausführliche Analyse vorhandener Programme notwendig ist. Tools, die beide Aufgaben übernehmen, existieren bisher aber nicht. Ein erheblicher Teil der Umstellungen muß also individuell erfolgen.
Die richtige, datumsgerechte Auslegung der Anwendungssoftware eines Anbieters nützt wenig, wenn die Datumssteuerung über die Systemsoftware eines anderen Anbieters läuft und diese nicht angepaßt wurde beziehungsweise ein Update (noch) nicht verfügbar ist.
Weder Tool- noch Umstellungsanbieter haften für die Verfügbarkeit notwendiger Systemsoftware aus dritter Quelle. Updates sind, wenn nichts anderes vereinbart ist, Sache des Kunden.
Soweit dieser Software - zeitlich unbegrenzt verfügbar und gegen Einmalvergütung - gekauft hat, ist er grundsätzlich berechtigt, Änderungen daran vorzunehmen. Das gilt auch für die Datumsanpassung. Meist untersagt der Software-Anbieter als Lizenzgeber allerdings jegliche Eingriffe, wie es etwa Codeänderungen wären. Verstößt der Anwender gegen diese Bestimmungen, kommt dies einer Urheberrechtsverletzung gleich.
Nur bei geringfügigen Anpassungen, die die urheberrechtlich geschützte Gestalt des Programms nicht verändern, sind Ausnahmen zulässig. Datenfelderweiterungen sind aber fast zwangsläufig mit Eingriffen in den Programmcode an vielen Stellen und zuweilen mit Änderungen der Programmlogik verbunden. Das sind Gestaltsveränderungen, die der Zustimmung des Anbieters bedürfen. Während der Garantiezeit kann durch Eingriffe von seiten des Kunden die Gewährleistung sofort erlöschen - auf jeden Fall dann, wenn die Änderung bestimmte Fehlerrisiken begründet.
Ist der Quellcode eines umstellenden Lizenzprogramms nicht verfügbar, darf der Kunde den Objektcode nicht von sich aus dekompilieren, um in den rückerschlossenen Statements die notwendigen Anpassungen vorzunehmen.
Dies gilt für Standardsoftware genauso wie für Individualsoftware. Im Einzelfall immer dann, wenn das Recht zum Dekompilieren nicht ausdrücklich im Vertrag steht oder zumindest zum bestimmungsgemäßen kundenseitigen Gebrauch gehört. Das dürfte aber eine seltene Ausnahme sein.
Die Anwender sollten also keinesfalls Aufträge an Drittfirmen vergeben, bevor nicht mit dem Softwarehersteller geklärt ist, ob er diesen Änderungen und dem erforderlichen Dekompilieren zustimmt.
Kunde darf Laufzeitsperren nicht deaktivieren
Unabhängig davon ist ein Dekompilieren gemäß Paragraph 69e Urhebergesetz (UrhG) nur zulässig, um Informationen über Schnittstellen zur Erstellung anderer Programme zu gewinnen. Die Datumsumstellung ist aber in der Regel nicht primär ein schnittstellenbezogenes Problem, sondern muß unmittelbar und grundsätzlich schnittstellenunabhängig im Code des jeweiligen vorhandenen Programms erfolgen. Auf den genannten Paragraphen kann sich damit eine Dekompilierbefugnis bei der Datumsumstellung grundsätzlich nicht berufen.
Der Kunde darf freilich auch ohne Zustimmung ein Programm bearbeiten oder ändern, um Fehler zu beseitigen. Allerdings nur, soweit dies für die bestimmungsgemäße Programmbenutzung erforderlich ist (Paragraphen 69c Nr. 2 und 69d Absatz 1 UrhG). Jedoch ist ein gegenwärtig voll funktionsfähiges Programm nicht allein deshalb fehlerhaft, weil es zur Jahrtausendwende zu erweitern ist. Anders verhält es sich jedoch, wenn diese Umstellungsmöglichkeit zum Leistungsspektrum des Systems gehört.
Ebenso ist es dem Kunden untersagt, Laufzeitsperren zu deaktivieren, die etwa eine Nutzung über den 31.12.1999 hinaus technisch unterbinden. Gesperrte Programmteile dürfen weder abgeschaltet noch umgangen werden. Wie im übrigen auch das Abschalten einer Dongle-Abfrage unzulässig ist (dazu siehe OLG Karlsruhe NJW-CoR 1996, S. 186).
Erfolgt die Umstellung durch den Anbieter nicht rechtzeitig, haftet er auf Schadensersatz wegen Nichterfüllung. Im Falle, daß es zu Verzögerungen bei den betroffenen Programmen kommt, beschränkt sich seine Haftung auf diesen Teilverzug - es sei denn, die gesamte Anwendung hängt von den noch nicht umgestellten Programmen ab.
Diverse Ansprüche auf Nachbesserungen
Bei fehlerhaften Modifikationen stehen dem Kunden Gewährleistungsrechte aus dem Werkvertragsrecht zu. Er hätte damit diverse Ansprüche: auf Nachbesserungen, Vergütungsnachlässe (meist wenig hilfreich), "Wandlung" (Rückgängigmachen des Vertrages, wobei die Zeit für neue Projekte dann sehr knapp werden kann) oder Schadensersatz (bei Verschulden des Anbieters).
Angesichts überlasteter Gerichte können Prozesse allerdings Jahre dauern, insbesondere bei umfänglicher Beweisaufnahme und Begutachtung durch Sachverständige. Rechtskräftige Urteile wären dann erst nach dem Jahr 2000 zu erwarten. Eine für viele Unternehmen existenzbedrohende Aussicht.
Schwierig ist es auch, Mängel an den Tools nachzuweisen: Sind diese überhaupt vorhanden? Wirken sie sich gerade bei der konkreten Umstellung aus? Bis wann hätte spätestens ein Fehlerbeseitigungs-Update ausgeliefert werden müssen? Sind Bugs vielleicht darauf zurückzuführen, daß Umstellungsfehler unterliefen oder die Programme nicht geeignet sind? Sichern kann sich der Kunde hier nur durch klare Anforderungskriterien und Abnahmetests, die im Vertrag präzise und nachvollziehbar festgelegt sein müssen.
Kontrollen schon beim Beginn des Vertrages
Umstellungsprojekte mit der Deadline 31. Dezember 1999 lassen sich also im Falle von Störungen zumeist nicht auf dem Rechtsweg retten. Der Anwender muß die notwendigen Kontrollen bereits bei Beginn in den Vertrag in kontrollfähiger Form aufnehmen. Standardverträge reichen hier nicht aus.
Außerdem wird die Zeit für notwendige Projektentscheidungen allmählich knapp. Läuft das Umstellungsprojekt etwa 24 Monate, ist mit Vorbereitungszeiten von sechs Monaten für die Auftragsausschreibung zu rechnen und eine etwa gleichlange Phase einzuplanen, die Verzögerungen auffängt. Das bedeutet, daß die Vertragsverhandlungen für ein Jahr-2000-Projekt seit Jahresbeginn laufen müßten.
Fragen an Anbieter
Individuelle Umstellungsstrategien verlangen entsprechend sorgfältig ausgearbeitete Projektkonzeptionen. Wichtige Fragenkomplexe sind hier:
- Bietet der Dienstleister eine konkrete Umstellung mit voller werkvertraglicher Haftung an oder nur ein Tool nach Kaufrecht? Berät der Anbieter nicht nur über die Vorzüge, sondern auch über die Leistungsgrenzen seines Werkzeugs? Kein Tool kann nämlich eine vollständige Umstellung leisten. Existieren bereits erfolgreich abgeschlossene Referenzprojekte?
- Wie läßt sich verhindern, daß getestete Programme durch individuelle Anpassungen instabiler und damit anwendungsriskanter werden? Läßt sich die bevorstehende Euro-Anpassung mit der Datumsumstellung verbinden?
- In welchem Umfang lassen sich standardisierte Tools einsetzen? Welche Programme und Datenbestände (zum Beispiel aus dem Cobol-Bereich) erfassen sie nicht? Was kostet die individuelle Umstellung dieser "Inseln"? Übernimmt der Tool-Anbieter auch solche Umstellungen? Läuft die Gewährleistung nur sechs Monate ab Erwerb des Werkzeugs, oder läßt sie sich vertraglich bis zum Abschluß des Umstellungsprojekts verlängern?
- Muß der Kunde, wenn besondere Vereinbarungen fehlen, auf eigenes Risiko alle umzustellenden Programme finden, auflisten und auf ihre Eignung untersuchen, oder trägt der Anbieter das Risiko? Was kosten diese Vorarbeiten für die Erstellung eines Umstellungspflichtenheftes, was die eigentliche Umstellung?
- Darf der Kunde die - getrennt vergüteten - Ergebnisse solcher Vorarbeiten dazu verwenden, einen anderen Anbieter zu beauftragen? Lassen sich unternehmensinterne Umstellungsarbeiten mit der Anbieterleistung ausreichend präzise abstimmen? Sollte zusätzlich veralteter Code ausgemustert werden?
- Werden Umstellungsprojekte qualitätsgesichert vorgenommen, insbesondere transparent dokumentiert?
- Akzeptiert der Anbieter für den Fall von Projektverzögerungen angemessene Vertragsstrafen?
- Wann ist spätestens mit einem Umstellungsprojekt zu beginnen, damit es sich bei üblichen Vorlaufzeiten und Terminverzögerungen doch noch rechtzeitig abschließen läßt?
Angeklickt
So dringend die Umstellungsarbeiten den Verantwortlichen auch auf den Nägeln brennen mögen, ist doch davon abzuraten, einfach loszulegen und an den Bits zu manipulieren. Die Aufmerksamkeit sollte nicht nur den Arbeitsmethoden und -verfahren gelten, sondern auch rechtliche Aspekte verdienen eine eingehende Analyse. Denn bei vielen Änderungen könnte es sich um Eingriffe in die Rechte anderer, nämlich der Softwarelieferanten, handeln. Eine Reihe rechtlicher Fragen im Kontext einer Umstellung ist in der Regel in den Verträgen zwischen Anbietern und Anwendern ungeklärt. Dies könnte etliche langwierige Nachverhandlungen nach sich ziehen.
*Dr. Frank Koch ist Rechtsanwalt in München.