Die juristische Einordnung des Vertragspartners

SEITE 1
______________________________________________________________________________________________________
RECHTSÄNWALTE SCHÖNBERGER DIX
12 goldene Regeln
für den Softwarehersteller
_________________________________________________________________________________________________________
RECHTSÄNWALTE SCHÖNBERGER DIX, UNTER SACHSENHAUSEN 35, 50667 KÖLN
 2001 RECHTSÄNWALTE SCHÖNBERGER DIX , WWW.MEDIAJUS.DE
SEITE 2
______________________________________________________________________________________________________
Wir haben es in unserer täglichen Beratungspraxis immer wieder mit bereits gescheiterten
oder kurz vor dem Scheitern stehenden EDV-Projekten zu tun, bei denen es nur noch
darum gehen kann „zu retten, was zu retten ist“. Dies ist dann für den Software-Hersteller
mit Kosten verbunden, die die Kosten für eine konfliktvermeidende Vertragsgestaltung im
Vorfeld regelmäßig um das drei bis vierfache übersteigen.
Wir haben daher für den Software-Hersteller „12 goldene Regeln“ aufgestellt, deren
Beachtung erfahrungsgemäß die Erfolgswahrscheinlichkeit für ein Projekt erheblich
erhöhen, deren Nichtbeachtung andererseits Hauptursache für das Scheitern von Projekten
ist.
Jede Regel wird von uns nachfolgend kurz kommentiert, um Ihnen auch den
entsprechenden Hintergrund zu vermitteln.
1. Regel: Erst der Vertrag, dann die Entwicklung
Häufig werden Software-Entwicklungen bereits begonnen, bevor ein Entwicklungsvertrag
vorliegt, bzw. unterzeichnet ist. Gründe hierfür sind Zeitdruck und ein stillschweigender
Konsens der Parteien, man werde sich schon einigen. Manche Entwicklungshäuser, die
einen bestimmten Auftrag besonders herbeisehnen, meinen mit einer derartigen
Vorgehensweise auch bereits „einen Fuß in der Türe“ zu haben. Die Konsequenzen eines
solchen Vorgehens sind allerdings oft fatal. Es entsteht zum einen ein Zwang zur Annahme
von Bedingungen, die ohne bereits kostenintensivem Projektbeginn nicht angenommen
worden wären. Zum anderen wird die konkrete Vertragsgestaltung auch aufwendiger und
teurer, da Entwürfe regelmäßig durch die realen Verhältnisse überholt werden und
wiederholt der aktuellen Entwicklung angepasst werden müssen.
Es gibt nicht wenige Fälle, in denen aufgrund dieser Vorgehensweise überhaupt nie ein
schriftlicher Vertrag zustande kam. Im Konfliktfall war dann vollends unklar, auf was sich
denn die Parteien verständigt haben.
2. Regel: Vertragsmacht behalten
Auf den ersten Blick erscheint eine Vertragsgestaltung durch den Vertragspartner positiv.
Zum einen lernt man den Vertragspartner schon einmal kennen, denn er gibt mit seinem
Vertragsentwurf eine Visitenkarte über seine Einstellungen ab. Manche Unternehmen
neigen dabei bis hin zur Knebelung dazu, den Vertragspartner möglichst aller Rechte zu
beschneiden, andere Unternehmen sind von Beginn an auf einen fairen Ausgleich aus.
Regelmäßig setzt sich diese Grundeinstellung als Verhalten im Rahmen der
Vertragsdurchführung fort. Auch hier überwiegen jedoch die Nachteile. Wenn der
Vertragspartner Ihnen einen Vertragsentwurf übermittelt, dann gilt der Inhalt des
Vertragsentwurfes als Norm und Ihre Anmerkungen als Änderungswünsche. Die
Durchsetzung von Änderungen ist jedoch schwieriger als das Festhalten an der Norm, denn
ein Eingehen auf Änderungswünsche stellt ein Nachgeben des Vertragspartners dar.
Weiterhin ist in diesem Fall bereits die Struktur vorgegeben und eine Änderung der
Gesamtstruktur des Vertrages kaum mehr möglich. Der Vertragspartner bildet mit dieser
_________________________________________________________________________________________________________
RECHTSÄNWALTE SCHÖNBERGER DIX, UNTER SACHSENHAUSEN 35, 50667 KÖLN
 2001 RECHTSÄNWALTE SCHÖNBERGER DIX , WWW.MEDIAJUS.DE
SEITE 3
______________________________________________________________________________________________________
Struktur jedoch regelmäßig sein Unternehmen, nicht jedoch Ihr Unternehmen sowie dessen
Organisation ab.
3. Regel: AGB´s vor Vertragschluss vereinbaren
Möchten Sie neben dem individuell erstellten Entwicklungsvertrag oder anstelle eines
solchen Entwicklungsvertrages Ihre AGB mit in das Vertragsverhältnis einbeziehen, so
muss diese Einbeziehung in der zutreffenden juristischen Form und rechtzeitig geschehen.
In diesem Bereich sind Fehler an der Tagesordnung. Beachten Sie daher zwingend
Folgendes:
Allgemeine Geschäftsbedingungen müssen spätestens zum Zeitpunkt des
Vertragsabschlusses einbezogen sein. Eine nachträgliche einseitige Einbeziehung ist nicht
möglich. Dies bedeutet, dass entweder die AGB selbst oder ein drucktechnisch deutlich
gestalteter Hinweis auf die eigenen AGB sowie die Nichtakzeptanz fremder AGB auf der
nachträglich erstellten Rechnung nichts bringt. Eine derartige Einbeziehung ist bereits auf
dem ersten Schriftstück, welches an den späteren Vertragspartner übermittelt wird,
dringend zu empfehlen.
4. Regel: Mehr Projektierung, weniger Umprogrammierung
Wir stellen darüber hinaus immer wieder fest, dass Softwareentwickler zu früh mit der
Programmierung beginnen. Es wird bereits begonnen, Programmzeilen zu erstellen, bevor
der konkrete Inhalt des Ergebnisses (vgl. dazu Regel 5), der Projektablauf und die
Einsatzbedingungen der Software (technische Umgebung, Anwendungsumfang etc.)
feststehen. Je weniger Sie jedoch projektieren, umso mehr zeit- und kostenaufwendige
Umprogrammierungen stehen zu erwarten. Diese Regel wird im übrigen vor allem von
deutschen Programmierern nicht beachtet. Japaner und zum Teil auch Amerikaner neigen
– insoweit richtig – wesentlich stärker zu einer extensiveren Projektierungsphase.
5. Regel: Vollständiges Pflichtenheft vereinbaren
Wie dem Softwarehersteller bekannt ist, liegt eines der Hauptprobleme im Rahmen der
Softwareerstellung darin, die Erwartungen des Auftraggebers an die Software zu ermitteln
und umzusetzen. Gerade nicht übereinstimmende Erwartungen an Programminhalte sind
bekanntlich nach Fertigstellung der Software Auslöser für Konflikte. Es ist besonders
entscheidend, ein möglichst umfassendes Pflichtenheft zu vereinbaren, welches die
Funktion hat, letztlich die „Sollbeschaffenheit“ der Software gemeinsam zu ermitteln und
sich auf diese festzulegen. Der Richter fragt im Rahmen eines EDV-Prozesses
üblicherweise zunächst nach dem Pflichtenheft und beurteilt danach ergänzend durch
allgemeine Anforderungen an die Software nach dem Stand der Technik die Frage nach
deren Mangelhaftigkeit. Im Rahmen des Pflichtenheftes sollten die Eigenschaften der
Software so umfassend wie möglich beschrieben werden. Sofern möglich, sollten
Screenshots in das Pflichtenheft aufgenommen werden, ggf. kann auch ein bereits
_________________________________________________________________________________________________________
RECHTSÄNWALTE SCHÖNBERGER DIX, UNTER SACHSENHAUSEN 35, 50667 KÖLN
 2001 RECHTSÄNWALTE SCHÖNBERGER DIX , WWW.MEDIAJUS.DE
SEITE 4
______________________________________________________________________________________________________
bestehendes Handbuch in das Pflichtenheft einbezogen werden. Wenn sich die
Vertragsparteien an dieser Stelle besondere Mühe geben, minimieren sie ein späteres
Prozessrisiko deutlich.
6. Regel: „Mile-Stones“ setzen
Nicht nur die Ermittlung des Inhalts der zu entwickelnden Software, sondern auch das
Aufstellen einer Zeitplanung ist besonders wichtig. Zu Beginn eines Projekts bestehen
regelmäßig nur sehr vage Vorstellungen über den zeitlichen Umfang der Entwicklung. Ohne
Zeitplanung kollidiert dann der regelmäßig frühe Einsatzwunsch des Auftraggebers mit den
zeitlichen und personellen Möglichkeiten des Softwareentwicklers. Wird zudem kein
konkreter Zeitplan als Teil des Projektplans aufgestellt, neigen Software-Hersteller zu einem
verspäteten Beginn der Entwicklung nach dem Motto: „Das kriegen wir schon noch hin“.
Der zu einem späteren Zeitpunkt entstehende Zeitdruck führt dann insbesondere zu
Fehlern im Rahmen der Programmierung mit der weiteren Konsequenz von
Gewährleistungsprozessen. Im Rahmen der Zeitplanung sollten sogenannte „Mile-Stones“
gesetzt werden. Es sollte genau definiert werden, welches Entwicklungsstadium zu
welchem Zeitpunkt erreicht werden muss. Auf diese Weise erkennen die Vertragsparteien
frühzeitig, wie es um die Entwicklungsfortschritte des Projekts bestellt ist. Weiterhin sollten
diese „Mile-Stones“ möglichst in sich abgeschlossene Entwicklungsschritte definieren, an
die eine Teilabnahme geknüpft werden kann. Diese Teilabnahme kann wiederum mit der
Vereinbarung von Teilzahlungen verbunden werden. Auf diese Weise können die
Vertragsparteien eine gerechte Verteilung von Leistung und Gegenleistung erreichen,
gleichzeitig zu einem frühen Zeitpunkt problematische Punkte im Rahmen der Entwicklung
erkennen und diese frühzeitig beseitigen.
7. Regel: Systemumgebung und Schnittstellen definieren
Ein weiterer Streitpunkt ist im nachhinein häufig die Frage, welche Ursache ein
aufgetretener Fehler hat. Liegt der Fehler an dem vertragsgegenständlichen Programm,
einem Programm, welches mit diesem zusammenarbeitet oder an der Hardware? Eine
derartige Frage hat im Streitfall der Sachverständige zu entscheiden, eine vertragliche
Vorbeugung gibt es hier nicht. Allerdings können in diesem Bereich zumindest Teilprobleme
von Beginn an ausgeräumt werden. Häufig zeigt sich ein Fehler deshalb, weil
Kompatibilitäts- oder Schnittstellenprobleme auftauchen. In diesem Fall wird es ohne
konkrete Vereinbarung schwierig, die Verantwortlichkeit hierfür zu bestimmen. Da Gerichte
dazu tendieren, eher den Anwender zu schützen, besteht daher auch hier besonderer
Regelungsbedarf.
_________________________________________________________________________________________________________
RECHTSÄNWALTE SCHÖNBERGER DIX, UNTER SACHSENHAUSEN 35, 50667 KÖLN
 2001 RECHTSÄNWALTE SCHÖNBERGER DIX , WWW.MEDIAJUS.DE
SEITE 5
______________________________________________________________________________________________________
8. Regel: Schadenersatzansprüche beschränken
Der Software-Hersteller haftet in den Fällen, in denen er einen Mangel verschuldet hat
grundsätzlich auf Schadenersatz. Da die EDV das „Herz“ der meisten Unternehmen
darstellt, können Mängel zu auch im Verhältnis zum Auftragswert unverhältnismäßig hohen
Schäden führen. Es ist deshalb dringend zu empfehlen, Schadenersatzansprüche im
Bereich des Grades des Verschuldens und des Schadensumfanges zu beschränken. Der
Software-Hersteller sollte sich einräumen lassen, dass er nur für Vorsatz und grobe
Fahrlässigkeit auf Schadenersatz haftet, nicht jedoch für leichte Fahrlässigkeit. Bereits diese
Haftungsbeschränkung führt in den meisten Fällen zu einem vollständigen Ausschluss von
Schadenersatzansprüchen, da ein grob fahrlässiges Verhalten des Software-Herstellers
eher selten ist. Weiterhin sollten auch Haftungshöchstgrenzen, etwa bezogen auf den
doppelten
oder
dreifachen
Auftragswert,
vereinbart
werden.
Sofern
die
Vertragsbedingungen AGB darstellen, muss in diesem Bereich das AGBG und dessen
Beschränkungen zugunsten des Verbrauchers und in Teilen des Kaufmanns beachtet
werden.
9. Regel: Nutzungsrechte sichern
Während es sich von selbst versteht, dass der Softwarehersteller sich im Falle des Verkaufs
auch von Fremdsoftware entsprechende Lizenzen sichern muss, wird diese Sicherung
regelmäßig im Bereich der Nutzungsrechte für die zu entwickelnde „eigene“ Software
vergessen. Hierbei gilt es das Folgende zu beachten:
Diejenige Person oder die Personen, die die konkrete Software entwickeln sind Urheber
bzw. Miturheber der Software. Das Urheberrecht kann auch nicht übertragen werden,
sondern haftet der Person bzw. den Personen an. Übertragbar sind jedoch entsprechende
Nutzungsrechte an der Software. Während bei Entwicklungen im Rahmen von
Arbeitsverhältnissen grundsätzlich angenommen wird, dass die Nutzungsrechte dem
Arbeitgeber zur Verwertung zustehen, ist dies bei Entwicklung durch freie Mitarbeiter oder
Subunternehmer nicht so. Wird also keine Vereinbarung über die Gewährung von
Nutzungsrechten getroffen, so wird eine solche Gewährung allenfalls stillschweigend
anzunehmen sein. Rechtsunsicherheiten sind hier groß. Deshalb sollte sich das zu
vertreibende Unternehmen von Freiberuflern oder Subunternehmern zwingend und
ausdrücklich in einem eigenen schriftlichen Vertrag die Nutzungsrechte an der Software
einräumen lassen. Zur Sicherheit sollte dies auch gegenüber Arbeitnehmern im Rahmen
des Arbeitsvertrages oder im Rahmen eines gesonderten Vertrages geregelt werden. Wer
hier untätig bleibt, schafft sich enormes Gefahrenpotential, da immer wieder aufgrund
anderer Anlässe Streitigkeiten mit den Subunternehmern oder den – ehemaligen – freien
Mitarbeitern auftreten, welche diese Regelungslücke dann zum Anlass nehmen, um
erhebliche Nachforderungen zu stellen.
_________________________________________________________________________________________________________
RECHTSÄNWALTE SCHÖNBERGER DIX, UNTER SACHSENHAUSEN 35, 50667 KÖLN
 2001 RECHTSÄNWALTE SCHÖNBERGER DIX , WWW.MEDIAJUS.DE
SEITE 6
______________________________________________________________________________________________________
10. Regel: Zeitschlösser vereinbaren
Grundsätzlich darf ohne ausdrückliche Vereinbarung ein entwickeltes und geliefertes
Programm keine Programmsperren enthalten. Andererseits haben Software-Hersteller
häufig das Problem, dass sie nach Übergabe bzw. Abnahme der Software kein richtiges
Druckmittel mehr an der Hand haben, mit dem sie ihren Vertragspartner zur Zahlung von
(Rest-)Werklohn bewegen können. Der Auftraggeber kann jedoch bereits unbegrenzt mit
der Software arbeiten und hat allenfalls das Problem, dass ihm kein Update zur Verfügung
gestellt wird. Daher sollte in den Fällen, in denen nach Gesamtübergabe der Software noch
erhebliche Zahlungen ausstehen, ausdrücklich nur eine „beschränkte Lizenz“ dergestalt
vereinbart werden, dass der Software-Hersteller nach einer bestimmten Frist und
Nichtzahlung berechtigt ist, das Programm per Programmsperre abzuschalten.
11. Regel: Handbuch liefern
EDV-Anwender kommen häufig zu uns, weil sie Probleme mit ihrer Software haben und
stehen vor der Schwierigkeit, dass entsprechende Gewährleistungsrechte verjährt
erscheinen. In diesem Fall gibt es noch eine Chance. Hat der Software-Hersteller das
Programm, nicht jedoch ein Handbuch geliefert, so hat er seine Leistungsverpflichtungen
aus einem EDV-Kaufvertrag noch gar nicht erfüllt. und die Verjährung beginnt noch nicht zu
laufen. Die Lieferung eines Handbuchs gehört im EDV-Kaufrecht zu den Leistungspflichten
des Verkäufers. Achten Sie also zwingend darauf, dass mit der entsprechenden Software
auch ein Handbuch geliefert wird.
12. Regel: Quellcode nicht herausgeben
Soweit möglich, sollte schließlich der Quellcode der zu entwickelnden Software nicht
herausgegeben werden. Wir haben es regelmäßig mit Fällen zu tun, in denen der Besitzer
des Quellcodes die Software mit leichten Veränderungen unter anderem Namen selbst auf
den Markt bringt. In diesem Fall ist es sehr kostenintensiv, den tatsächlichen Missbrauch
des Quellcodes nachzuweisen. Der Software-Hersteller sollte daher möglichst darauf
drängen, den Quellcode nicht herauszugeben. Um den berechtigten Interessen des
Auftraggebers an einer Sicherung des Programms bei Insolvenz des Herstellers gerecht zu
werden.
(RA Peter Schönberger)
_________________________________________________________________________________________________________
RECHTSÄNWALTE SCHÖNBERGER DIX, UNTER SACHSENHAUSEN 35, 50667 KÖLN
 2001 RECHTSÄNWALTE SCHÖNBERGER DIX , WWW.MEDIAJUS.DE