Michael Wächter *Was bedeutet Überlassung von Standardsoftware: Ablieferung von Software, Einräumung eines Nutzungsrechts oder Softwareeinführung beim Kunden?- zugleich eine kritische Anmerkung zu BGH, Urteil vom 22.12.1999 - VIII ZR 299/98 (NJW 2000, 1415 ff. = CR 2000, 207 ff. mit Anmerkung von Peter Chrocziel = JurPC Web.-Dok. 70/2000) "Ablieferung" von Standardsoftware -JurPC Web-Dok. 242/2000, Abs. 1 - 155 |
I.Ausgangslage: Betrachtungsweisen der Softwareüberlassung |
1. Tragweite der BGH-Entscheidung |
| Die BGH-Entscheidung wurde mit Spannung erwartet. Denn sie befaßt sich mit der Frage der Vertragserfüllung bei Überlassung von "Standardsoftware". Zu fragen ist indes, inwieweit dieser Entscheidung rechtliche Bedeutung bei Streitfällen der Vertragsdurchführung der Softwareüberlassung im Rahmen einer Einführung von Standardsoftware zukommt. Und viel wesentlicher: auf welche realen Sachverhalte in der EDV-Branche trifft sie zu? | JurPC Web-Dok.
242/2000, Abs. 1 |
| Zur Behandlung dieses Spannungsfelds wird in diesem Beitrag die "Normalfallstruktur"(1) von Software-Einführungsprojekten zur besseren Erläuterung der rechtlichen Überprüfung von Fragestellungen zur Softwareüberlassung dargestellt. Dabei wird der Aussagegehalt der BGH-Entscheidung im Rahmen der Interessenlage von Softwarehäusern als Lizenzgeber und Kunden als Auftraggeber gespiegelt. Denn diese werden, auch wenn sie Profi-Anwender sind, komplexe Standardsoftware mit einer Vielzahl von Funktionalitäten nach §§ 433 ff., 459 ff. als auch nach § 377 HGB faktisch nicht prüfen können, weil es ihnen im Stadium der Ablieferung der Software subjektiv nicht möglich ist. | Abs. 2 |
| Dies hat für solche Softwarehäuser, die selbst keine Einführungsprojekte durchführen, zur Konsequenz, daß sie einen sicheren Lizenzumsatz verbuchen können. Für Softwarehäuser, welche ihre Standardsoftware einführen, ergibt sich eine andere Situation, denn diese werden beim Kunden erfolgreich installieren müssen. Der Erfolg der Installation wird an den Auswirkungen für den Kunden gemessen. Dazu dient sehr häufig das Prinzip der Severity-Klassen. | Abs. 3 |
| Installiert der Kunde, hat er dem Softwarehaus den erfolgreichen Abschluß der Installation schriftlich innerhalb einer bestimmten Frist mitzuteilen. Die Erklärung darf regelmäßig bei Mängeln nachfolgend definierter Severity-Klassen 1 oder 2 verweigert werden. Das heißt: die Vertragserfüllung bemißt sich an den Folgen für die Datenverarbeitung des Kunden. | Abs. 4 |
Installiert das Softwarehaus, ist die Installation erfolgreich
durchgeführt, sobald das Softwarehaus die Betriebsbereitschaft der
Programme an Hand ihrer Testdaten vorgeführt hat. Programme sind
betriebsbereit, wenn keine Fehler der nachfolgend definierten Severity-Klassen 1
oder 2 vorliegen:
| Abs. 5 |
| Bei Betrachtung in der Softwarebranche üblicher Mechanismen zur Festlegung einer Vertragserfüllung führt die rechtsdogmatische Klarheit des BGH zu rechtlichen Ungleichbehandlungen "an sich" gleicher Sachverhalte. | Abs. 6 |
| Je größer die Marktmacht eines Softwarehauses, und je weniger es Interessen seiner Kunden berücksichtigt, desto stärker seine Rechtsposition. Vereinbart es vertraglich die Herstellung eines Echtbetriebs als Systemhaus(2) nach Durchführung eines Einführungsprojekts, desto schlechter die Rechtsposition. | Abs. 7 |
2. Diskussionspunkte im EDV-Recht |
Die Frage der Softwareüberlassung hat viele Facetten und
wird je nach Perspektive der Betrachtung
| Abs. 8 |
| Der BGH hat entschieden, daß die vertraglich geschuldete Lieferung von Standardsoftware bereits dadurch erfolgt ist, daß die Software "in den Machtbereich des Kunden" gebracht wurde. | Abs. 9 |
| Die Entscheidung des BGH ist rechtsdogmatisch trennscharf, betrifft aber nicht den Kernpunkt der Interessenlage von Kunden, welche die Standardsoftware "in den Echtbetrieb" bekommen möchten. Der BGH geht rechtspositivistisch vor und entscheidet durch Zuordnung zu einem Teil des Besonderen Schuldrechts: dem Kaufvertragsrecht. | Abs. 10 |
| Bezüglich der Investitionsentscheidung und Interessenlage bevorzugen Kunden heute allerdings in der Praxis der Softwareüberlassung eine betriebswirtschaftliche Betrachtungsweise für den Einsatz von Standardsoftware, welche vertraglich durch Verfahren des Projektmanagements zur Softwareeinführung abgesichert wird. Dies betrifft die Festlegung des eigentlichen Vertragsgegenstandes. | Abs. 11 |
| Das bedeutet: Mit dem Gang zum Gericht wird im EDV-Recht ein "neues Terrain" betreten und es wird "über andere", nämlich rechtsdogmatisch dem Bürgerlichen Gesetzbuch zuordenbare Sachverhalte diskutiert. | Abs. 12 |
| Die betriebswirtschaftliche Betrachtungsweise im Wirtschaftsleben soll nachfolgende typische vertragliche Regelung zur Überlassung von Standardsoftware verdeutlichen: | Abs. 13 |
| Für den Fall der Entwicklung einer XY-Standardanwendung durch das Softwarehaus besteht für den Kunden das Optionsrecht, diese Standardsoftware unter Rückvergütung der Differenz zu den Entwicklungskosten einzusetzen, wobei auf diese Differenz dann eine jährliche Reduktion von 20 % vom Zeitpunkt der Abnahme der ursprünglichen Anwendung an, berechnet wird. | Abs. 14 |
| An einem konkreten Beispiel verdeutlicht, bedeutet diese Regelung folgendes: | Abs. 15 |
| Der Kunde zahlt für eine Entwicklung DM 150.000,-. 3 Jahre später wird dieses entwickelte Modul Standard und kostet nach Liste DM 50.000,-. Der Kunde gibt fiktiv das Entwicklungsmodul zurück und erwirbt die Lizenz am Standardmodul. Die Differenz beträgt hiermit DM 100.000,- zwischen beiden Modulen. Pro Jahr werden für das Einzelnutzungsrecht des Entwicklungsmoduls 20% vom - vom Softwarehaus zurückzuerstattenden - Betrag von DM 100.000,- abgezogen. Bei 3 Jahren wären dies 3 X 20% = DM 60.000,-. Das Softwarehaus müßte dem Kunden DM 40.000,- zurückerstatten. | Abs. 16 |
| Vor diesem Hintergrund steht die Praxis der Softwareüberlassung zwischen der Aussage des BGH, welcher einer Sonderregelung für die Softwarebranche eine Absage erteilt, und Aussagen der rechtswissenschaftlichen Literatur, in welcher ein zweigeteiltes Bild gezeichnet wird. Dort wird einerseits zwar davon gesprochen, daß "Software gekauft werde", aber andererseits "die Hersteller von Software aber darüber hinaus daran interessiert seien, sog. Lizenzverträge abzuschließen"(3). Diese verschiedenen Realitäten sind in Einklang zu bringen. | Abs. 17 |
3. Die verschiedenen Betrachtungsweisen |
| In der EDV-Literatur wird Autoren, welche Vertragsmechanismen der Softwarebranche beschreiben, zum Teil vorgeworfen, sie betrieben Lobbyismus in einem negativen Sinne, indem sie interessengeleitete Beiträge verfassten(4). Es fragt sich freilich, welche Interessen im einzelnen dargestellt werden. Auch dieser Punkt läßt sich nicht eindimensional bestimmen. | Abs. 18 |
| Im übrigen ergibt sich die Darstellung von Interessen regelmäßig aus einmal gefundenen Kompromißformeln, die unter beteiligten Vertragspartnern als gangbare bzw. "angemessene" Regelungen empfunden wurden. Mithin geht es vor diesem Hintergrund um eine Annäherung zwischen Problemlösungskonzepten der Softwarebranche und Regelungsvorgaben von Gesetz und gerichtlichen Entscheidungen, welche zu beachten sind. | Abs. 19 |
| Einen Beitrag zur Versachlichung der Thematik kann in einem solchen Diskussionsstand die Offenlegung der unterschiedlichen Betrachtungsperspektiven bzw. -weisen leisten. Dies verdeutlicht auch das Erkenntnisinteresse bzw. die Perspektive der Sachbehandlung. Aus Sicht der Softwarebranche ist die Problemlösungskapazität des Kauf- und z. T. auch des Urheberrechts für die zu behandelnden Sachfragen zu dünn, um Geschäftsvorgänge umfassend regeln und die Interessenlagen von Kunden und Softwarehäusern abbilden zu können. | Abs. 20 |
| Die juristische Problembehandlung in der Praxis der Softwareüberlassung muß deshalb in weitem Umfang betriebswirtschaftliche Gesichtspunkte berücksichtigen sowie Entscheidungszwänge beider Vertragspartner. Die idealtypische juristische Zuspitzung auf rechtsdogmatische Kategorien greift im Wirtschaftsleben aufgrund immer komplexer werdender Geschäftsvorfälle zu kurz. | Abs. 21 |
| Insofern ist der Streit im EDV-Recht auch ein solcher zwischen Autoren, die sich an traditionellen rechtlichen Leitbildern orientieren und eine rechtliche Fragestellung "als Außenstehender" rechtlich einordnen und bewerten, und solchen, die als Unternehmensjuristen und beratende Anwälte "produktive Problemlösungsvorschläge" im operativen Tagesgeschäft machen müssen. | Abs. 22 |
Softwareüberlassung wird nach der Beobachtung des
Verfassers heute in Rechtswissenschaft, Rechtsprechung und Praxis der
Softwarebranche anhand und innerhalb von zwei Gegensatzpaaren diskutiert:
| Abs. 23 |
Diese Diskussion wird heute flankiert durch zwei weitere
Diskussionsstränge, welche auf rechtlichen Rahmenbedingungen für
Unternehmen und betriebswirtschaftlichen Mechanismen beruhen:
| Abs. 24 |
| Hohe Anforderungen hinsichtlich der Software werden zu Wettbewerbsargumenten für die Unternehmen ebenso wie Sicherheit, nicht in Haftung genommen zu werden. Zu berücksichtigen ist hier deshalb auch die "corporate governance"-Diskussion, deren Teilaspekt der Unternehmensüberwachung(7) die vertragliche Gestaltung und die Überwachung der Vertragsrealisierung im besonderen auch des Kunden ist. | Abs. 25 |
| Die Softwareüberlassung muß vor diesem Hintergrund nicht nur mit Blick auf Risiken der Investitionsentscheidung des Kunden, sondern auch vor dem Hintergrund der Lebensfähigkeit von Unternehmen und deren Bewältigung unternehmerischer Risiken betrachtet werden(8). | Abs. 26 |
| Anders gewendet bedeutet dieser Befund auch, daß die Rechtsinformatik neben ihren vielfältigen und sich aus ihrer Historie ergebenden Aufgabenstellungen(9), einen Beitrag zu einem Vermittlungsweg zwischen traditionellem Recht und technischen Erfordernissen leisten soll, indem vertragliche Erfordernisse aufgrund von Technik in das Recht der Softwareüberlassung einfließen. Dieser Ansatz wird im Folgenden (unter II. bis V.) anhand von Regelungskonzepten der Softwarebranche aufgegriffen. | Abs. 27 |
II. Kerntatbestand: Einräumung eines Nutzungsrechts |
1. Softwareüberlassung zwischen Verwendungs- und Ideenschutz |
| Angesichts dieses Befunds zur Beschreibung der Softwareüberlassung und ihrer technischen Erfordernisse werden nachfolgend diejenigen Kriterien behandelt, welche ein tragfähiges Konzept für einen ausgewogenen Interessenausgleich für Lizenzgeber und Lizenznehmer im Rahmen der Softwareüberlassung darstellen. | Abs. 28 |
| Wesentlicher Faktor für eine vorausschauende Anpassung an ein Marktumfeld und technische Entwicklungen ist die Lizenzpolitik eines Unternehmens, welche heute in der Branche in weitem Umfang durch die Definition von Usern gesteuert wird(10). Softwareüberlassung ist damit zwischen betrieblichen Erfordernissen von Kunden sowie dem Bedürfnis der Softwarebranche, den Umfang der Überlassung an den Umfang des wirtschaftlichen Nutzens für den Kunden zu koppeln. | Abs. 29 |
| Das bedeutet: es geht auch bei der Gestaltung von Verträgen um die Festlegung der Vertragsinhalte und um die Vermeidung "regulatorischer Risiken", soweit sie sich auf die Einhaltung der jeweils einschlägigen gesetzlichen Rahmenbedingungen beziehen. Vor diesem Hintergrund bedeutet das Urteil des BGH eine neue Festlegung rechtlicher Risiken, da der BGH einen Sachverhalt in einer Weise rechtlich einordnet, der sich am kaufmännischen, nicht technischen Teil der Überlassung, d.h. der Installation und ggf. Einführung der Standardsoftware orientiert. | Abs. 30 |
| Pointiert ausgedrückt: Damit hat sich der BGH bewußt "gegen den technischen Sachverhalt" und für die Systematik der Vertragstypologie des BGB entschieden, während sich das Wirtschaftsleben und die Vertragsjurisprudenz aufgrund der Natur des Geschäfts für den kaufmännischen Sachverhalt auf Basis der technischen und betrieblich-organisatorischen Erfordernisse der Vertragsdurchführung und deren Risiken entscheiden muß(11). Die rechtliche Bewertung des BGH erfaßt damit nur einen Teilaspekt. Fraglich ist, ob eine solche Entscheidung aus Gründen der Rechtssicherheit geboten war. Ich meine nicht. | Abs. 31 |
| Bei Softwareüberlassung im wirtschaftlichen Kontext geht es heute um die effektive Realisierung "unternehmenskritischer Anwendungen". Angesichts dieser Dimension hat sich in der Praxis im übrigen auch die Zuordnung des Schutzes von Computerprogrammen zum Urheberrecht "als allein selig machende Lösung" nicht (in vollem Umfang) bewährt(12). | Abs. 32 |
| Ein weiteres kommt hinzu: Im Kampf der Softwarehäuser untereinander um Marktanteile spielen heute Überlegungen des Marken- und Patentschutzes eine immer wesentlichere Rolle. Hier werden ggf. zugunsten des Patentinhaber Verwertungsrechte in Form eines "temporären Verwertungsmonopols" begründet(13). Auf der anderen Seite der Bewegung stehen wirtschaftliche Initiativen der "open source"-Bewegung als Lizenzpolitik. Diese sollen - ebenso wie das Patentrecht - der weltweiten Verbreitung von Innovation dienen(14). Softwareüberlassung orientiert sich damit an dynamischen Marktprozessen. | Abs. 33 |
2. Vertragliche Festlegung des Nutzungsumfangs |
| Angesichts dieser Überlegungen ist in der Kundenbeziehung zwischen Lizenzgeber und Lizenznehmer die Bestimmung des Nutzungsrechts von zentraler Bedeutung. Hierbei räumt der Lizenzgeber dem Auftraggeber bei Standardsoftware regelmäßig das nicht ausschließliche Recht ein, die erworbene Lizenz an der Software in dem "im Vertrag festgelegten Umfang", für Zwecke der Abwicklung unternehmenseigener Geschäftsvorfälle zu nutzen. | Abs. 34 |
| Die Höhe der Überlassungsvergütung richtet sich nach dem im Programmüberlassungsschein festgelegten Nutzungsumfang und der vertraglich vereinbarten maximalen Anzahl zulässiger User. | Abs. 35 |
| Erhöht der Auftraggeber/Kunde den vereinbarten Nutzungsumfang, so ist er regelmäßig verpflichtet, einen Aufpreis für die im Nutzungsumfang erweiterte Überlassung der Software zu bezahlen, dessen Höhe entweder individualvertraglich vereinbart ist oder sich aus der Preisliste des Lizenzgebers ergibt. | Abs. 36 |
| Damit spielt die "Branchenüblichkeit" der Softwareüberlassung in diesem Markt eine zentrale Rolle. Die Software wird nicht lediglich "abgeliefert", sondern mit einem vertraglich ausgefeilten Konzept überlassen. | Abs. 37 |
Die vertraglichen Module ergeben sich im Rahmen eines solchen
Konzepts wie folgt:
| Abs. 38 |
| Bei entsprechendem Know-how beider Vertragspartner werden viele rechtliche Fragestellungen und Probleme über eine lang erarbeitete Erfahrungskette des Lizenzgebers, d.h. der "Frequently Asked Questions" (FAQs) einer Beantwortung und Lösung im jeweiligen Vertragsverhältnis zugeführt. | Abs. 39 |
3. CPU-Klausel und technische Softwarefreigabe |
| Typischerweise wird in Allgemeinen Geschäftsbedingungen geregelt, daß Software nur auf der vertraglich vereinbarten EDV-Anlage eingesetzt werden darf, welche der Lizenzgeber für die Software freigegeben hat. Der Auftraggeber wird in diesem Zusammenhang auch verpflichtet, den Lizenzgeber über eine Veränderung des technischen Software-Umfeldes zu unterrichten. | Abs. 40 |
| Vor diesem Hintergrund wird dem Kunden z.B. auch das Recht eingeräumt, die Software (das Lizenzmaterial) bei einem Ausfall des bezeichneten Computersystems vorübergehend auf einer anderen Ausweichanlage zu gebrauchen. | Abs. 41 |
| CPU-Klauseln beschreiben von daher technische Voraussetzungen für die Nutzung von Software, sie können aber auch dazu dienen, den Nutzungsumfang der Software für den Kunden vertraglich festzulegen. Dies betrifft freilich im wesentlichen processor based Verträge, bei denen die Höhe der Lizenz an die Größe der Maschine geknüpft ist (z.B. dem Kunden ist das Nutzungsrecht eingeräumt, die im Programmüberlassungsschein aufgeführten Software-Systeme auf der EDV-Anlage AS/400, 9406 Modell 320, Maschinen Nr. XYZ für eigene Zwecke zu nutzen). | Abs. 42 |
| Bei einem Umstieg auf eine größere Maschine hat der Kunde mit dem Softwarehaus einen Upgrade-Vertrag abzuschließen und eine entsprechende Lizenzgebühr zu entrichten. Eine solche Nutzungsberechtigung des Kunden entspricht einer inhaltlichen Beschränkung des Teilhaberechts, vereitelt aber nicht den bestimmungsgemäßen Gebrauch der Software (die "implied use rights")(15). | Abs. 43 |
| Anerkennt man den Grundtatbestand, daß Softwarehäuser den Nutzungsumfang an der Software mit den Kunden vereinbaren können - und man muß dies im Rahmen der Privatautonomie der Vertragsparteien nach Auffassung des Verfassers auch tun -, so hinkt auch der Vergleich des Erwerbs einer Lizenz mit dem Erwerb eines Pkw, "den der Käufer so schnell fahren kann wie er will"(16). | Abs. 44 |
| Eine andere Frage als die Erweiterung des Nutzungsumfangs der Software ist die Berechtigung des Auftraggebers, die Software-Systeme vorübergehend auf einer anderen EDV-Anlage zu nutzen, wenn dies bei Ausfall der vereinbarten Anlage oder aus anderen zwingenden Gründen zeitweise nicht möglich ist. Bei dieser technischen Bedeutung der CPU-Klausel muß also sichergestellt sein, daß bei Rechnerausfall bzw. in einer Ausnahmesituation der Kunde die Software auf einem Rechner nutzen kann. Das Softwarehaus wird hierfür ggf. auch einen temporären Code vergeben. | Abs. 45 |
| Der Auftraggeber darf also die EDV-Anlage durch eine andere von ihm genutzte EDV-Anlage ersetzen, wenn der Einsatz der Software-Systeme auf dieser Anlage seitens des Lizenzgebers technisch freigegeben ist. Ist eine andere Version der Software erforderlich und muß der Lizenzgeber diese ggf. liefern, erfolgt die Lieferung regelmäßig gegen gesonderte Vergütung. | Abs. 46 |
| Der Auftraggeber ist im übrigen auch berechtigt, nach Vertragsschluß ein Mehrfachnutzungsrecht an den Software-Systemen oder an Teilen davon zu erwerben. Eine Mehrfachnutzung tritt ein, wenn der Vertragsgegenstand gleichzeitig auf mehreren Anlagen oder mehrfach auf einer Anlage mit verschiedenen Anwendungsdatenbanken produktiv genutzt wird. | Abs. 47 |
| Der vertraglich vereinbarte Nutzungsumfang ist von daher von der technischen Nutzungsmöglichkeit der Software zu trennen. Wesentlich ist aus Sicht des Verfassers bei beiden Themen, daß es bei der CPU-Klausel nicht um das Thema der Vereitelung einer Eigentumsverschaffung geht(17). | Abs. 48 |
4. Verwendungsschutz der Software |
| Der Verwendungsschutz der Software ist das klassische Thema der EDV-rechtlichen Literatur. | Abs. 49 |
| Die Standardsoftware ist regelmäßig mit Benutzerdokumentation auf Datenträgern gespeichert und wird - soweit nichts anderes vereinbart wird - auch auf diese Weise geliefert. Das branchenübliche Prozedere sieht hier im Rahmen einer vertraglichen Vereinbarung im allgemeinen wie folgt aus: | Abs. 50 |
| Der Lizenzgeber wird dem Auftraggeber nach Anforderung bei der Inbetriebnahme der Software Unterstützungsleistungen (Einsatzvorbereitung, Installation, Einweisung, Schulung oder Beratung) gewähren. Übernimmt der Lizenzgeber die Installation der Software, bestätigt der Auftraggeber die erfolgreiche Durchführung. Der Auftraggeber überprüft die Software unter seinen Einsatzbedingungen, bevor er sie produktiv einsetzt. | Abs. 51 |
| Die erforderlichen Maßnahmen zum Programmschutz trifft der Lizenzgeber. Er wird sich auch das Recht vertraglich absichern, den Einsatz der Software von der Eingabe eines Programmschlüssels, z.B. der Nummer der benutzten Zentraleinheiten, abhängig zu machen, bevor sie nicht vollständig bezahlt ist. | Abs. 52 |
| Aus Sicht der Softwarehäuser ist wesentlich, daß der Auftraggeber ausdrücklich anerkennt, daß die Software sowie die Software- und Benutzerdokumentation, auch in künftigen Releases, urheberrechtlich geschützt sind und Betriebsgeheimnisse des Lizenzgebers bzw. des jeweiligen Herstellers darstellen. Soweit Quellprogramme geliefert werden, darf der Auftraggeber diese Dritten nur mit vorheriger Zustimmung des Lizenzgebers zugänglich machen. | Abs. 53 |
| Der Auftraggeber ist berechtigt, eine Vervielfältigung der Software zu Sicherungszwecken vorzunehmen. Die Benutzerdokumentation kann der Auftraggeber im Rahmen der Zweckbestimmung des Vertragsverhältnisses vervielfältigen. Beide Berechtigungen zur Vervielfältigung sollen ausschließlich dem eigenen Gebrauch des Auftraggebers dienen. | Abs. 54 |
| Wesentlich ist heute eine Festlegung für die Überlassung von Standardsoftware: Soweit der Auftraggeber selbst Modifikationen oder Erweiterungen vornimmt oder durch Dritte vornehmen läßt, wird der Lizenzgeber dadurch nicht gehindert, die Software "ebenso weiterzuentwickeln". | Abs. 55 |
| Deshalb wird der Lizenzgeber den Quellcode der Modifikationen oder Erweiterungen des Auftraggebers nur mit dessen Zustimmung verwenden. Teilweise wird deshalb zwischen Auftragnehmer und Lizenzgeber vereinbart, daß für die Weitergabe von Software-Bestandteilen, die nicht im Standard der Software vorhanden sind, an Neukunden des Lizenzgebers es hierfür einer Zustimmung des Auftraggebers bedarf. | Abs. 56 |
| Für den Fall, daß der Auftraggeber seine Zustimmung erteilt, verpflichtet sich das Softwarehaus einen im Einzelfall zu definierenden anteiligen Betrag der vom Auftraggeber an das Softwarehaus gezahlten Entwicklungsleistung an den Auftraggeber zurückzuerstatten (siehe dazu das Beispiel oben unter I.2.). | Abs. 57 |
| Wenn der Auftraggeber den Umfang seines Nutzungsrechts unberechtigt erweitert oder schwerwiegend zum Nachteil des Lizenzgebers gegen seine Verpflichtungen zum Programmschutz verstößt, kann der Lizenzgeber das Nutzungsrecht aus wichtigem Grund widerrufen. In weniger schweren Fällen wird der Lizenzgeber vorher eine Nachfrist zur Abhilfe setzen. | Abs. 58 |
| Das Nutzungsrecht im vertraglich vereinbarten Umfang darf nicht an einen anderen Anwender veräußert werden, es sei denn der Auftraggeber verzichtet auf die Nutzung der Software in vollem Umfang und der vom Auftraggeber vorgesehene neue Anwender verpflichtet sich vor Einräumung des Nutzungsrechts gegenüber dem Lizenzgeber durch rechtsgültige Erklärung, daß er sich zum Programmschutz verpflichtet und den vereinbarten Umfang des Nutzungsrechtes an dem Programm durch Übernahme der vertraglichen Verpflichtungen des alten Auftraggebers gegenüber dem Lizenzgeber anerkennt. | Abs. 59 |
| Im internationalen Kontext ist für Softwarehäuser eine Regelung wesentlich, wonach aufgrund inländischer bzw. ausländischer gesetzlicher Bestimmungen der Export der Software in einige Länder nicht gestattet oder von Genehmigungen abhängig sein kann. | Abs. 60 |
| Der Auftraggeber verpflichtet sich hierbei, alle entsprechenden Rechtsvorschriften einzuhalten und dem Lizenzgeber rechtzeitig vor dem Export in ein Land, in welchem die Berechtigung zur Installation und Nutzung der Software nicht sicher ist oder auch die Einhaltung dieser Allgemeinen Geschäftsbedingungen nicht gewährleistet ist, schriftlich zu unterrichten. Auf Verlangen des Lizenzgebers verpflichtet sich der Auftraggeber, die Software im Land der vertraglich mit ihm vereinbarten Installation zu belassen. | Abs. 61 |
| Der Lizenzgeber gewährleistet, daß die Software der Benutzerdokumentation entspricht und bei vertragsgemäßer Nutzung nicht mit Fehlern behaftet ist, die ihre Tauglichkeit aufhebt oder mindert. Es wird darauf hingewiesen, daß es nach dem Stand der Technik nicht möglich ist, Fehler in Software unter allen Anwendungsbedingungen auszuschließen. | Abs. 62 |
| Angesichts dessen ist der Lizenzgeber auch berechtigt, die Tauglichkeit der Software in erster Linie durch Nachbesserung zu gewährleisten. Hierzu wird der Auftraggeber das Softwarehaus im Rahmen des Zumutbaren unterstützen, im besonderen Maschinen- und Leitungszeit zur Verfügung stellen. | Abs. 63 |
| Der Lizenzgeber ist verpflichtet, Fehler zu beseitigen. Kommt der Lizenzgeber mit der Beseitigung von Fehlern in Verzug, kann der Auftraggeber eine angemessene Frist für die Beseitigung von Fehlern mit der Androhung setzen, nach nutzlosem Fristablauf die Beseitigung der Fehler abzulehnen. Verstreicht die Frist, ohne daß die Fehler beseitigt werden und schlägt die Fehlerbeseitigung endgültig fehl, kann der Auftraggeber unter den gesetzlichen Voraussetzungen Herabsetzung der Vergütung oder Rückgängigmachung des Vertrags oder Schadensersatz verlangen. | Abs. 64 |
| Die Gewährleistungsfrist beträgt X Monate gerechnet ab Installation durch das Softwarehaus bzw. ab einer Woche nach Lieferung, wenn der Auftraggeber installiert. Die Erweiterung des Nutzungsumfangs führt nicht zu einer neuen Gewährleistungsfrist für die Software. | Abs. 65 |
| Der Lizenzgeber hinterlegt bei einer Bank, als Treuhänderin für Auftraggeber, die beiden letzten freigegebenen Releases der eigenen Software-Standardprogramme im Quellcode. Bei Software, die ausdrücklich als solche von Vorlieferanten, Drittanbietern bzw. als Add-On gekennzeichnet ist, gewährleistet der Lizenzgeber regelmäßig nur, daß sie die Eigenschaften hat, die für den Betrieb der Programme vom Lizenzgeber erforderlich sind. | Abs. 66 |
| Für diese Programme kann der Lizenzgeber gegebenenfalls einen Pflegevertrag vermitteln. Da der Lizenzgeber in einem solchen Fall regelmäßig keinen Zugang zum Quellcode hat, kann er auch keine Pflicht zur Fehlerbeseitigung übernehmen, sondern wird sich um Korrekturmaßnahmen des Vorlieferanten und um Umgehungsmaßnahmen bemühen. | Abs. 67 |
| Ferner wird das Softwarehaus dem Auftraggeber bei Zurverfügungstellung neuer Softwarestände bzw. Releases erforderlichenfalls die Umstellungshilfen des Vorlieferanten bereitstellen. Wenn diese Maßnahmen nicht dazu ausreichen, daß der Auftraggeber die Software insgesamt in zumutbarer Weise einsetzen kann, wird er eine Nachfrist setzen. Interesse des Softwarehauses wird dabei sein, zuvor die Software eines geeigneten anderen Anbieters anzubieten. | Abs. 68 |
III. Projektarbeit: Softwareeinführung und Anpassungsprogrammierung |
1. Konzeption eines Softwareprojekts |
| Für den Fall, daß ein Softwarehaus eine branchenspezifische Standard-Softwarelösung für einen Kunden erstellt, entstehen Aufwände für Anpassungsprogrammierung. Solche Erfordernisse für eine Projektrealisierung zur Einführung von Standardsoftware behandelt das Urteil des BGH im Rahmen seiner eng gefaßten Fragestellung nicht. | Abs. 69 |
| Handelt es sich bei der Einführung eines integrierten und im "Realtime-Mode" arbeitenden Softwaresystems um eine organisatorische Neuorientierung in der Ablauf- und in der Regel auch Strukturorganisation, so wird - überspitzt ausgedrückt - beim Kunden nicht einfach ein "Bleistift abgeliefert". | Abs. 70 |
| Diese Aufgabe und die Realisierung von Unternehmenszielsetzungen, z.B. Integration der Informationsverarbeitung im Rahmen der betrieblichen Auftragsabwicklung, Verbesserung der Planungs- und Steuerungsmethoden und in der Folge einen rationelleren Auftragdurchlauf und verbesserte Materialverfügbarkeit erfordern eine projektorientierte Arbeitsweise und beim Kunden die Bereitschaft, die betriebliche Organisation mit den einzusetzenden Betriebsmitteln zu optimieren. | Abs. 71 |
| Damit klaffen formaljuristische Positionen wie die Beschreibung der "Ablieferung von Software" und die Projektwirklichkeit auseinander. Die Ablieferung der Software - so vorliegende These - verläuft "in der Zeit", weshalb das BGH-Urteil für eine Vielzahl von Fallgestaltungen nicht anwendbar ist bzw. für EDV-spezifische Streitfragen nicht zutrifft. | Abs. 72 |
| In einer Übersicht kann die Struktur eines Softwareprojekts wie folgt veranschaulicht werden: | Abs. 73 |
 |
2. Projektmanagement und Entscheidungsstruktur |
| Zur Sicherstellung eines Einführungsprojekts für Standardsoftware ist ferner ein Projektmanagement mit Projektbearbeitungsmethoden erforderlich. | Abs. 74 |
| In diesem Rahmen trägt das Softwarehaus gemeinsam mit dem Kunden die Verantwortung zur Erreichung der formulierten Ziele. Denn Voraussetzung ist, daß der mit ihm festgelegte Leistungsumfang unter Mitwirkung der Mitarbeiter des Kunden im Projekt erbracht wird. | Abs. 75 |
| EDV-Projekte muß man also organisieren und managen. Dazu werden Entscheidungsebenen z.B. wie folgt festgelegt: | Abs. 76 |
 |
| Eine Projektstruktur kann hierbei z.B. wie folgt aussehen: | Abs. 77 |
 |
| Aufgaben des Lenkungsausschusses sind im wesentlichen die strategische Ausrichtung der Projektarbeit, das Projekt-Controlling und die Entscheidung offener Arbeitspunkte und bereichsübergreifender Fragestellungen. Die Projektleitung hat die Aufgabe, alle Projektaktivitäten zu koordinieren und stellt die fachliche problemorientierte Entscheidungsebene dar. | Abs. 78 |
3. Informationsstruktur der Projektarbeit |
| Um die Ergebnisse und die zu treffenden Maßnahmen aus der Projektarbeit transparent zu machen, ist es erforderlich, eine Informationsstruktur aufzubauen, die allen Beteiligten und den Entscheidungsträgern die notwendigen Informationen zur Verfügung stellt. | Abs. 79 |
  |
4. Projektphasen und Projektstruktur ("Simulation und Planspiel") |
| Die Projektdurchführung orientiert sich an einer Projektphasenbeschreibung. Die Inhalte der Projektphasen sind nachfolgend in ihren wesentlichen Elementen dargestellt (hierbei spielt es keine Rolle, daß hierzu in der Softwarebranche unterschiedliche Terminologien verwandt werden): | Abs. 80 |
a. ) Informationsphase |
Für eine erfolgreiche Projektarbeit ist es unabdingbar, daß
sich die verantwortlichen Berater über die organisatorischen Abläufe
des Unternehmens des Kunden informieren. Ziel dieser Phase ist es,
| Abs. 81 |
b. ) Prototyping |
| Im Anschluß an die Infophase erfolgt der Aufbau eines Betriebsmodells durch Mitarbeiter des Softwarehauses. | Abs. 82 |
| Der Aufbau des Betriebsmodells geschieht anhand der Informationen und Erkenntnisse der Unternehmensprozesse aus der Infophase. Auf Basis dieser Angaben richten die Mitarbeiter des Softwarehauses beim Kunden das Betriebsmodell ein. | Abs. 83 |
Arbeitsschritte zur Durchführung des Prototypings sind
hierbei:
| Abs. 84 |
| Ziel des Prototypings ist es, einen integrierten Betriebsablauf über alle Funktionen auf der Basis Ihrer Produktionsstruktur und des Informationsflusses mit dem Kernteam simulieren zu können. | Abs. 85 |
c. ) Schulung |
| Ziel ist es, die Kernteammitglieder mit dem neuen System vertraut zu machen, damit die Modulverantwortlichkeit gewährleistet werden kann und die erforderlichen Funktionen organisatorisch und systemtechnisch beherrscht werden. | Abs. 86 |
Ziel ist es, die Kernteammitglieder in die Lage zu versetzen:
| Abs. 87 |
d. ) Soll-Konzeptionsphase |
| In dieser Projektphase definiert das Kernteam mit den Beratern die Sollorganisation, deren Abläufe und Arbeitsinhalte. Dabei sind die Softwarefunktionen zu prüfen, die unbedingt für einen späteren Echteinsatz und die Zielrealisierung notwendig sind. | Abs. 88 |
| Alle Funktionen, die für den Echtbetrieb unerläßlich sind, aber nicht in dieser Form im Standardumfang der Software realisiert sind, werden in dieser Phase definiert und dokumentiert. Diese Zusatzanforderungen müssen dann entweder durch DV-Mitarbeiter des Kunden oder des Softwarehauses realisiert werden. | Abs. 89 |
| Die dafür erforderlichen Aufwendungen werden im Projekt gesondert angeboten und berechnet. | Abs. 90 |
| Ergebnis dieses Arbeitsschrittes ist: | Abs. 91 |
 |
e. ) Datenübernahme, Schnittstellen zu Altsystemen |
| Dieser Arbeitsschritt ist gegliedert in der Konzeption und der darauffolgenden Realisierung der Schnittstellen/Übernahmeprogramme und kann prinzipiell nach dem Prototyping gestartet und während der Soll-Konzeptionsphase weiter intensiviert werden. | Abs. 92 |
| Eine konkrete Zeit- und Aufwandsschätzung für die Realisierung der Schnittstellen und Übernahmeprogramme erfolgt nach der Integrationsphase. | Abs. 93 |
f. ) Testbetrieb |
| In dieser Projektphase werden die Programmfunktionen anhand des verabschiedeten Betriebsmodells getestet. Ebenso werden alle Übernahme- und Schnittstellenprogramme auf ihre Funktionstüchtigkeit und korrekte Arbeitsweise überprüft. | Abs. 94 |
| Nach dem Echtbetriebstest, der bei Bedarf mehrere Male wiederholt wird, erfolgt die Freigabe für den produktiven Echteinsatz. | Abs. 95 |
g. ) Dokumentation |
| Wichtiger Bestandteil einer erfolgreichen Projektstrategie ist die durchgängige Dokumentation. | Abs. 96 |
| Die Erstellung der gesamten Projektdokumentation, wie Schulungsunterlagen, Kernprozessbeschreibungen, Organisationanweisungen, etc. erfolgt im Rahmen der Projektarbeit zumeist durch den Kunden selbst. | Abs. 97 |
h. ) Echtbetriebsphase |
| Nach erfolgreichem Testbetrieb erfolgt der Echtbetrieb. | Abs. 98 |
| Die Umstellung erfolgt zu einem definierten Stichtag, wobei die in der Sollkonzeption festgelegten Unternehmensbereiche zu diesem Tag umgestellt werden. | Abs. 99 |
| Die getesteten Datentransfers werden so durchgeführt, daß zum Stichtag alle Bewegungsdaten aktuell übernommen werden | Abs. 100 |
IV. Vertrag: Regelungserfordernisse der Softwareeinführung |
| Nach alledem räumt das Softwarehaus dem Auftraggeber nach erfolgter Projektarbeit an Modifikationen und Erweiterungen dasselbe Nutzungsrecht ein wie an den überlassenen Standardprogrammen, zu denen sie gehören. Damit ist Überlassung von Software gewissermaßen häufig die Überlassung passender, aber letztlich "halbfertiger Software". Die Funktionalitäten der Standardsoftware werden aber immer ausgefeilter. Der Kunde selbst hat hierbei ein Interesse, daß Funktionen in den Standard kommen, damit er sie nicht aufwendig bei einem neuen Release nachführen muß. | Abs. 101 |
| Wird die Standardsoftware im Quellcode geliefert, so erfolgt auch die Lieferung von Modifikationen, Erweiterungen und anderer Zusatzprogramme im Quellcode, regelmäßig aber ohne systemtechnische Dokumentation, es sei denn eine solche wird ausdrücklich beauftragt. Wesentlich aus Sicht der Softwarehäuser ist hierbei, daß der Auftraggeber nach Lieferung für den Quellcode, insbesondere für dessen Sicherung, verantwortlich ist. | Abs. 102 |
| Eine Benutzerdokumentation (auf Datenträger gespeichert) wird in diesen Fällen aber häufig nur geliefert, wenn das ausdrücklich so vereinbart worden ist. Im Fall der Lieferung einer Benutzerdokumentation gilt: Ergeben sich aus Modifikationen/Erweiterungen Auswirkungen auf die Benutzerdokumentation der Standardprogramme, werden diese nicht darin integriert, sondern gesondert dargestellt. | Abs. 103 |
| Daraus ergeben sich folgende vertragliche Erfordernisse, deren typische Regelungsinhalte nachfolgend dargestellt werden: | Abs. 104 |
1. Leistungserbringung und Abnahme |
| Soweit es erforderlich ist, die Anforderungen des Auftraggebers genauer zu analysieren, erstellt der Lizenzgeber ein Detailkonzept gemäß dessen Anforderungen und mit seiner Unterstützung. Dies hat der Lizenzgeber dem Auftraggeber zur Genehmigung vorzulegen. Das genehmigte Detailkonzept beinhaltet dann die verbindliche Vorgabe für die weitere Arbeit. Bei Bedarf wird der Lizenzgeber dies im Laufe der Programmumsetzung in Abstimmung mit dem Auftraggeber verfeinern. | Abs. 105 |
| Der Auftraggeber wird die Leistungen unter seinen Einsatzbedingungen überprüfen und bei deren Übereinstimmung mit den definierten Anforderungen schriftlich innerhalb einer Prüffrist die Abnahme erklären. | Abs. 106 |
| Die Leistungen gelten als abgenommen, sobald nach Ablauf der Prüffrist deren Nutzbarkeit auf die Dauer von einer zu definierenden Zeit nicht wegen gemeldeter Fehler, eingeteilt nach Klassen im Hinblick auf ihre Auswirkungen, eingeschränkt ist. | Abs. 107 |
2. Änderungen der Anforderungen |
| Will der Auftraggeber seine Anforderungen ändern, wird der Lizenzgeber dem zustimmen, soweit es für den Lizenzgeber durchführbar ist. Soweit sich ein Änderungswunsch auf den Vertrag auswirkt, kann der Lizenzgeber eine entsprechende Anpassung des Vertrages, im besonderen die Erhöhung der Vergütung bzw. die Verschiebung der Termine, verlangen. | Abs. 108 |
| Häufig wird vereinbart, daß Änderungen der Anforderungen zur Rechtssicherheit der Schriftform bedürfen. | Abs. 109 |
3. Gewährleistung |
| Der Lizenzgeber gewährleistet, daß die Leistungen den Anforderungen in der Form, die diese nach der Ausarbeitung eines Detailkonzepts gefunden haben, entsprechen und nicht mit Fehlern behaftet sind, die ihre Tauglichkeit demgegenüber aufheben oder mindern. Die Gewährleistungsfrist beginnt mit der Abnahme. | Abs. 110 |
| Kommt der Lizenzgeber mit der Beseitigung von Fehlern in Verzug, kann der Auftraggeber eine angemessene Frist für die Beseitigung von Fehlern mit der Androhung setzen, nach nutzlosem Fristablauf die Beseitigung der Fehler abzulehnen. Verstreicht die Frist, ohne daß die Fehler beseitigt werden und schlägt die Fehlerbeseitigung endgültig fehl, kann der Auftraggeber regelmäßig unter den gesetzlichen Voraussetzungen Herabsetzung der Vergütung oder Rückgängigmachung des Vertrags oder Schadensersatz verlangen. | Abs. 111 |
4. Pflege der Programme und Hotline |
| Bei der Pflege von Standardsoftware kann zwischen Basispflege, Weiterentwicklung und Hotline differenziert werden. | Abs. 112 |
| Die Basispflege der Standardprogramme umfaßt die Fehlerbeseitigung, die Fortentwicklung der Standardprogramme durch den Lizenzgeber und die Übersendung der vom Lizenzgeber weiterentwickelten Releases sowie neuer Korrekturstände innerhalb der Releases sowie die Fehlerbeseitigung nach Ablauf der Gewährleistungsfrist. | Abs. 113 |
| Alle weiteren Leistungen werden häufig gesondert beauftragt und vergütet, insbesondere die Beseitigung von Störungen im Zusammenwirken mit anderen Programmen, die nicht vom Lizenzgeber geliefert worden sind. | Abs. 114 |
| Die Pflicht zur Fehlerbeseitigung bezieht sich auf den jeweils neuesten Korrekturstand der jeweils beiden zuletzt freigegebenen Releases der Standardprogramme. Wenn der Lizenzgeber auf Verlangen des Auftraggebers Fehler in älteren Korrekturständen dieser Releases beseitigt, kann er regelmäßig die Vergütung ihres Mehraufwands verlangen. | Abs. 115 |
| Die Hotline umfaßt die telefonische Beratung zu Fragen zum Einsatz der Programme. Sie wird während der normalen Geschäftszeiten vom Lizenzgeber erbracht. Der Lizenzgeber kann Antworten auch schriftlich geben. Der Auftraggeber benennt Ansprechpartner, die die Beratung in Anspruch nehmen dürfen. Diese müssen in den Programmen geschult worden sein. | Abs. 116 |
| Die Betreuung bezieht sich nicht auf die Bedienung der DV-Anlagen, auf denen die Programme eingesetzt werden und nicht auf die Beseitigung von Fehlern in den Datenbeständen des Auftraggebers. Wenn der Lizenzgeber solche Leistungen dennoch erbringt, werden diese nach Aufwand vergütet. | Abs. 117 |
| Die Beratung kann auch für die Formulierung von Fehlermeldungen in Anspruch genommen werden. Das entbindet den Auftraggeber nicht von einer schriftlichen Fehlermeldung. | Abs. 118 |
5. Weiterentwicklung der Standardsoftware |
| Der Lizenzgeber verpflichtet sich, ihre Weiterentwicklungen, Releases sowie neue Korrekturstände innerhalb der Releases der Standardsoftware einschließlich der zu diesen gehörenden Dokumentation auf Datenträger gespeichert nach Marktfreigabe zu übersenden. Dies gilt nicht für Entwicklungen, die der Lizenzgeber als neue Programme gesondert anbietet. | Abs. 119 |
| Der Auftraggeber wird dafür Sorge tragen, daß seine DV-Anlage einschließlich Systemsoftware jeweils den technischen Stand hat, den die Programme im Rahmen der Weiterentwicklung nach den vorstehenden Regelungen erfordern. Eine neues Release kann erfordern, daß der Auftraggeber eine weiterentwickelte Fassung der Systemsoftware einsetzen muß. Der Lizenzgeber wird den Auftraggeber rechtzeitig davon unterrichten, ab wann welche Voraussetzungen für die Pflegeleistungen bereitzustellen sind. | Abs. 120 |
| Der Auftraggeber wird den Lizenzgeber darüber vorab informieren, wenn er seinerseits ein neues Release der benötigten Systemsoftware installieren will. | Abs. 121 |
| Die jeweils vereinbarten Vergütungen für die Basispflege und/oder Hotline werden als Prozentsatz der jeweils bei ihrer Fälligkeit gültigen Überlassungsvergütung der Standardprogramme (jeweilige Preisliste für diese) entsprechend dem vereinbarten Nutzungsumfang berechnet. Sie werden angepaßt, sobald sich dieser vergrößert. | Abs. 122 |
| Bei Mehrfacheinsatz werden die ermäßigten Überlassungsvergütungen nur dann zugrundegelegt, wenn die Abwicklung der Pflege auf eine einzige Installation beschränkt wird (Leitinstallation). | Abs. 123 |
| Solange eine Pflegevereinbarung für Standardprogramme besteht, wird der Lizenzgeber auch die von ihr gelieferten Modifikationen/Erweiterungen und Zusatzprogramme gegen Vergütung nach Aufwand pflegen. | Abs. 124 |
| Wird alternativ Pflege gegen pauschale Vergütung vereinbart, werden die Pflegeleistungen wie für Standardprogramme erbracht. Sie deckt auch die Übertragung von Modifikationen und Erweiterungen in weiterentwickelte Releases der Standardprogramme, und bei ausdrücklicher Vereinbarung auch die Anpassung von Zusatzprogrammen an weiterentwickelte Releases ab. Die Pflege kann seitens des Auftraggebers unabhängig von der Pflege für die Standardprogramme gekündigt werden. | Abs. 125 |
| Die Überlassungsvergütung wird entweder fällig nach Vertragsschluß, nach Installation, wenn der Lizenzgeber installiert oder im Rahmen einer Staffelung bei Abruf von Usern. Der Lizenzgeber ist berechtigt, die Nutzbarkeit der Programme über eine Zeitsperre von der vertragsgemäßen Zahlung der Überlassungsvergütung abhängig zu machen. | Abs. 126 |
6. Störungen bei der Leistungserbringung und Fernbetreuung |
| Soweit eine Ursache, die der Lizenzgeber nicht zu vertreten hat, einschließlich Streik oder Aussperrung, die Termineinhaltung beeinträchtigt, kann der Lizenzgeber eine angemessene Verschiebung der Termine verlangen. Erhöht sich der Aufwand aufgrund einer Ursache im Verantwortungsbereich des Auftraggebers, kann der Lizenzgeber auch die Vergütung ihres Mehraufwands verlangen. | Abs. 127 |
| Der Auftraggeber wird dem Lizenzgeber Fernbetreuung (Ferndiagnose und -korrekturen, Überspielen von neuen Releases) nach den vom Lizenzgeber vorgegebenen technischen Varianten ermöglichen. Er wird dafür in Abstimmung mit dem Lizenzgeber einen Anschluß nach den vom Lizenzgeber vorgegebenen technischen Varianten an ein Telekommunikationsnetz auf eigene Kosten zur Verfügung stellen, so daß die Systeme beider Seiten miteinander gekoppelt werden können. Der Auftraggeber trägt die anfallenden Leitungskosten. | Abs. 128 |
| Das Anmelden auf dem System des Auftraggebers seitens des Lizenzgebers erfolgt durch ein vom Auftraggeber kontrolliertes Benutzerprofil/Kennwort. Aus Gründen des Datenschutzes gibt der Auftraggeber die Leitungsverbindung im Einzelfall frei. Der Lizenzgeber wird den Auftraggeber über die durchgeführten Maßnahmen informieren. | Abs. 129 |
| Treten bei vertragsmäßiger Nutzung Fehler auf, hat der Auftraggeber diese in nachvollziehbarer Form unter Angabe der für die Fehlererkennung zweckdienlichen Informationen zu melden, und zwar unter Verwendung des bereitgestellten Formulars. Voraussetzung für den Anspruch auf Fehlerbeseitigung ist, daß der Fehler reproduzierbar ist oder durch maschinell erzeugte Ausgaben aufgezeigt werden kann. | Abs. 130 |
| Der Auftraggeber hat den Lizenzgeber im Rahmen des Zumutbaren bei der Beseitigung von Fehlern zu unterstützen, insbesondere auf Wunsch des Lizenzgebers das Programm, wie es bei Auftreten des Fehlers benutzt wurde, zu übersenden und Maschinenzeit zur Verfügung zu stellen sowie Korrekturmaßnahmen, die der Lizenzgeber bereitstellt, einzuspielen. | Abs. 131 |
| Der Lizenzgeber hat Fehler in angemessener Frist zu beseitigen. Dafür gelten folgende Fehlerklassen (Severity-Klassen): | Abs. 132 |
| Der Lizenzgeber wird bei einem Fehler der Klasse 1 sofort und bei einem Fehler der Klasse 2 spätestens an dem der Fehlermeldung folgenden Arbeitstag mit der Fehlerbehebung beginnen und solange an der Fehlerbeseitigung arbeiten, bis der Fehler entweder beseitigt ist oder durch eine Umgehungslösung so entschärft ist, daß er in seinen Auswirkungen nur noch einem Fehler der Klasse 3 entspricht. Fehler der Klasse 3 und 4 werden im nächsten Korrekturstand beseitigt bzw. im übernächsten, wenn der nächste zum Zeitpunkt der Fehlermeldung bereits in der abschließenden Qualitätssicherung ist. | Abs. 133 |
| Der Auftraggeber kann eine angemessene Frist für die Beseitigung der gemeldeten Fehler setzen. Verstreicht sie, ohne daß der Fehler beseitigt wird, oder schlägt die Fehlerbeseitigung endgültig fehl, kann der Auftraggeber unter den gesetzlichen Voraussetzungen Herabsetzung der Vergütung oder Rückgängigmachung des Vertrags oder Schadensersatz verlangen. | Abs. 134 |
| Alle Ansprüche gegen den Lizenzgeber erlöschen für solche Programme, die der Auftraggeber ändert oder in die er sonstwie eingreift, es sei denn, daß der Auftraggeber im Zusammenhang mit der Fehlermeldung nachweist, daß der Eingriff für den Fehler nicht ursächlich ist. | Abs. 135 |
| Der Lizenzgeber kann die Vergütung des eigenen Aufwands verlangen, soweit der Lizenzgeber auf Grund einer Fehlermeldung tätig geworden ist, ohne daß der Auftraggeber einen Fehler nachgewiesen hat. | Abs. 136 |
| Der Lizenzgeber steht dafür ein, daß die Programme - auch in künftigen Releases - frei von Rechten Dritter sind, die deren vertragsgemäße Nutzung einschränken. Der Lizenzgeber stellt den Auftraggeber von Schadensersatzansprüchen Dritter wegen Schutzrechtsverletzungen frei. | Abs. 137 |
| Macht ein Dritter gegenüber dem Auftraggeber geltend, daß die Programme seine Rechte verletzen würden, benachrichtigt der Auftraggeber unverzüglich schriftlich den Lizenzgeber. Er überläßt es dem Lizenzgeber und für Lizenzgeber deren Vorlieferanten soweit wie zulässig, die geltend gemachten Ansprüche auf deren Kosten abzuwehren. | Abs. 138 |
| Schadensersatzansprüche gegen den Lizenzgeber (einschl. deren Erfüllungsgehilfen) über die Verletzung von Schutzrechten hinaus, bestehen uneingeschränkt, wenn Vorsatz oder grobe Fahrlässigkeit des Lizenzgebers vorliegt oder zugesicherte Eigenschaften fehlen. | Abs. 139 |
| Bei leichter Fahrlässigkeit können Schadensersatzansprüche, z.B. auf 50 % der vereinbarten Überlassungsvergütung der Standardsoftware begrenzt werden; die Haftung für entgangenen Gewinn ist ausgeschlossen. Der Auftraggeber kann eine weitergehende Haftung gegen Zahlung eines Risikozuschlags verlangen. Die Einschränkungen gelten nicht, soweit die Schäden durch die Betriebshaftpflichtversicherung vom Lizenzgeber abgedeckt sind. Ansprüche aus dem Produkthaftungsgesetz bleiben unberührt. | Abs. 140 |
| Schadensersatzansprüche verjähren zwei Jahre nach Beendigung der Leistung, in deren Ausführung der Schaden entsteht, soweit nicht eine kürzere gesetzliche Verjährungsfrist besteht. | Abs. 141 |
7. Vertraulichkeit |
| Der Lizenzgeber verpflichtet sich, alle im Rahmen des Vertragsverhältnisses erlangten Kenntnisse von Betriebsgeheimnissen und von schriftlich als vertraulich bezeichneten Informationen nur zur Durchführung des Vertrags zu verwenden und zeitlich unbegrenzt vertraulich zu behandeln. Der Lizenzgeber verpflichtet seine Mitarbeiter zur Wahrung der Vertraulichkeit. | Abs. 142 |
| Die Verpflichtung zur vertraulichen Behandlung gilt nicht für Ideen, Konzeptionen, Know-how und Techniken, die sich auf Programmerstellung beziehen sowie für Daten, die dem Lizenzgeber bereits bekannt sind oder außerhalb dieses Vertrages bekannt waren oder bekannt werden. | Abs. 143 |
| Wenn Daten zum Zwecke der Fehlersuche oder ihrer Restaurierung an den Lizenzgeber übertragen werden, wird der Lizenzgeber alle technischen und organisatorischen Maßnahmen im eigenen Bereich einhalten, die der Auftraggeber seinerseits gemäß § 9 Bundesdatenschutzgesetz zu treffen hat. Einzelheiten werden auf Wunsch des Auftraggebers gesondert vereinbart. | Abs. 144 |
V. Konsequenzen des BGH-Urteils für die Praxis der Softwareinfühung |
| Peter Chrocziel spricht in seiner Anmerkung zum Urteil des BGH von einem "weiteren Stück rechtlicher Normalität". Dem kann man vom rechtsdogmatischen Standpunkt des "Primats der Einordnung eines Rechtsproblems" zustimmen. Allerdings muß man sich dann auch damit zufrieden gehen, daß spezifische Sachverhalte eines Themas ausgeblendet werden und das Recht seine Problemlösungskapazität, die es eigentlich hätte, in weiten Teilen aufgibt. Es wird in Zukunft also noch mehr darauf ankommen, die Softwareüberlassung vertraglich zu regeln. | Abs. 145 |
| Um dies zu veranschaulichen, wurde in vorliegendem Beitrag die Frage behandelt: wie funktioniert eigentlich Softwareüberlassung? Anhand dieser Erfordernisse ergibt sich ein differenzierteres Bild. Die vom BGH geforderte unverzügliche Rügepflicht des Kunden an der Standardsoftware wird ihm regelmäßig nicht möglich sein. | Abs. 146 |
| Die Kritik des BGH an der im Urteil zitierten Rechtsprechung von Oberlandesgerichten geht insofern fehl, denn diese versuchen in zutreffender Weise, sich mit dem Sachthema der Softwareüberlassung auseinanderzusetzen. | Abs. 147 |
| Der Hinweis des BGH, daß diese Ansichten "zu einer Verwischung der Unterschiede zwischen Werkvertrag und Kaufvertrag" führen, mag richtig sein. Eine definitive Einordnung in ein System ist aber dann falsch, wenn das System falsch ist oder für den zu behandelnden Fall nicht zutrifft. So könnte das Urteil des BGH zu falschen Weichenstellungen führen. | Abs. 148 |
| Juristisch handeln, bedeutet Ursache und Auswirkungen eines Sachverhalts zu begreifen, d.h. man müht sich, die Herleitung einer Entscheidung aus dem Gesetz als Befund für die Beantwortung weitergehender Fragen zu begreifen. | Abs. 149 |
| Betriebswirtschaftlich geht es heute Kunden um die produktive Nutzung von Software im Echtbetrieb. Viele Software- und Beratungshäuser haben angesichts der hohen und spezifischen Anforderungen der Kunden im Grunde für diese "halbfertige Standardsoftware", welche eingeführt wird. Deshalb erfolgt vor dem Echtbetrieb ein Rundlauftest. Die klare Unterscheidung von Kauf- und Werkvertragsrecht wird in der Praxis durch die betriebswirtschaftliche Gewährleistung eines Echtbetriebs "ersetzt". | Abs. 150 |
| Dieser Weg muß bei Häusern, die ihre Software bei Kunden durch ihre Berater selbst einführen, aufgrund des Urteils des BGH neu überdacht bzw. vertraglich entsprechend abgesichert werden. Große Häuser, die lediglich Lizenzverträge abschließen und andere Systemhäuser diese Software einführen, werden sich durch den BGH eher bestätigt sehen. | Abs. 151 |
VI. Fazit: Was bedeutet Überlassung von Standardsoftware? |
| Überlassung von Standardsoftware bedeutet die Einräumung eines Nutzungsrechts an der Software für den Kunden! Meistens ist diese zur technischen Realisierung des Nutzungsrechts mit einem Einführungsprojekt gekoppelt. | Abs. 152 |
| Anders der BGH. Er geht von einem Kauf der Standardsoftware aus. Er leitet aus dem Begriff "Kauf" die Folge ab, daß auch Standardsoftware - und dies im wesentlichen abgleitet aus der Art der Vereinbarung von Zahlungsmodalitäten zwischen Softwarehaus und Kunden - "erworben" werde. Damit wird aus dem Mechanismus der Bezahlung aus einem "Überlassungsmechanismus" (Einräumung eines Nutzungsrechts) ein "Veräußerungsmechanismus" (Erwerb einer Sache). | Abs. 153 |
| Folge des Urteils wird sein, daß Softwarehäuser ihre Lieferanten-Kunden-Beziehungen bei Überlassung von Standardsoftware nach wie vor - wie in diesem Beitrag beschrieben - auch in der Zukunft "trotz oder auch gerade wegen dieses BGH-Urteils" zutreffend vertraglich regeln werden. | Abs. 154 |
| Durch das BGH-Urteil werden wir im Zeitalter der Globalisierung
im 21. Jahrhunderts in die zweite Hälfte des 19. Jahrhunderts, d.h. den
Beginn der Begriffsjurisprudenz mit Georg Friedrich Puchta zurückgeworfen.
Es ist insofern ein untauglicher Versuch. Die Praxis wird das Urteil zur
Kenntnis nehmen, es für viele Themenstellungen der Softwareüberlassung
aber als unzutreffend einstufen.
| JurPC Web-Dok. 242/2000, Abs. 155 |
Fußnoten:(1) Näher zu dieser Methode der Sachverhaltserfassung und Erreichung einer zutreffenden rechtlichen Strukturierung vgl. Fritjof Haft, Einführung in das juristische Lernen, 6. A. (1997), S. 181 ff. (Normalfalldenken) und S. 219 ff. (Strukturdenken).(2) S. zum Begriff Hans-Werner Moritz/Barbara Tybusseck, Computersoftware, 2. A. (1992), Rdnr. 61. (3) So Thomas Hoeren / Dirk Schumacher, CR 2000, 137 ff. (4) So z.B. Jochen Marly, Softwareüberlassungsverträge, 2. A. (1997), Rdnr. 65. (5) S. zum generellen Aufgabenstellung des Riskomanagements Bernd Saitz, in: Das Kontroll- und Transparenzgesetz, Hrsg. Bernd Saitz/Frank Braun, 1999, S. 69 ff. und speziell zum Riskomanagement als wettbewerbliche Notwendigkeit Bernd Pritzer, in: das Kontroll- und Transparenzgesetz, Hrsg. Bernd Saitz/Frank Braun, 1999, S. 146 ff. (6) Hierzu gehört, daß die Unternehmen gefährdende Entwicklungen und risikobehaftete Geschäfte vermieden werden; vgl. zum diesbezüglich globalen Risiko vgl. Hans Gisbert Ulmke/Stefan Schmale, in: Das Kontroll- und Transparenzgesetz, Hrsg. Bernd Saitz/Frank Braun, 1999, S. 210 ff. (7)Kritisch dazu Jean Nicolas Druey, in: Festschrift für Wolfgang Zöllner zum 70.Geburtstag, Band I, Herausgegeben von Manfred Lieb / Ulrich Noack / Harm Peter Westermann, 1998, S. 129 ff. (8)Instruktiv zu diesbezüglichen Auswirkungen der Globalisierung Bernd Lutterbeck, CR 2000, 52 ff. (insbesondere auch zum Bedeutungsverlust des deutschen Rechts S. 56 ff.). (9)Dazu Lothar Philipps, in: Die dunkle Seite des Chips, herausgegeben von Marie-Theres Tinnefeld / Lothar Philipps / Kurt Weis, 1993, S. 11 ff. (13 f.). (10) S. dazu Michael Wächter, NJW-CoR 1999, 420 ff. (11) S. zur Methode der Kautelarjurisprudenz Gerrit Langenfeld, Vertragsgestaltung, 2. A. (1997), Rdnrn. 1 ff., 25 ff., 96 ff., 103 ff. und speziell zu Gesichtspunkten der Vertragsgerechtigkeit Rdnrn. 522 ff. (12) So auch Christian Osterrieth, Patentrecht, 2000, Rdnrn. 56, 81. (13) Vgl. BGH, Beschluß vom 13.12.1999 - X ZB 11/98 (= JurPC Web-Dok. 72/2000), Leitsatz in NJW-CoR, Heft 3/2000, 167. (14) So auch Alexander Esslinger/Jürgen Betten, CR 2000, 18 ff. (21). (15)S. zu diesem Themenbereich OLG Frankfurt, CR 2000, 146 ff. mit Anmerkung von Peter Chrocziel auf S. 152 f. (16)Vergleich von Jochen Marly, Softwareüberlassungsverträge, 2.A. (1997), Rdnr. 936. (17) So aber Jochen Marly, Softwareüberlassungsverträge, 2.A. (1997), Rdnr. 941, der deswegen einen Verstoß gegen die "Kardinalpflicht der Eigentumsverschaffung" nach § 9 Abs.2 Nr. 1 und 2 AGBG annimmt. |
| * Dr. Michael Wächter ist Leiter Vertragswesen und -durchführung und Justitiar der BRAIN International AG Software & Consulting. Seit 1988 befaßt sich der Autor im Schwerpunkt mit Fragen des EDV-Rechts, insbesondere des Datenschutzrechts und des Arbeitsrechts. Der Autor hat im Jahr 1998 an der Universität Tübingen bei Prof. Dr. Fritjof Haft mit "summa cum laude" zum Datenschutzrecht promoviert. |
| [online seit: 11.12.2000] |
| Zitiervorschlag: Autor, Titel, JurPC Web-Dok., Abs. |
| Zitiervorschlag: Wächter, Michael, Was bedeutet Überlassung von Standardsoftware: Ablieferung von Software, Einräumung eines Nutzungsrechts oder Softwareeinführung beim Kunden? - JurPC-Web-Dok. 0242/2000 |
