Ist ein konkreter Fertigstellungstermin vereinbart, so gerät der Anbieter ohne Weiteres in Verzug. Dabei ist grundsätzlich nicht das Erreichen eines bestimmten Milestones maßgeblich. Die Überschreitung von Terminen in Projektplänen begründet noch keinen Verzug des Anbieters. Anderes gilt, wenn Fertigstellungstermine für die gesamte Software oder eigenständige Module überschritten werden.

Die nächste Voraussetzung für den Eintritt des Verzugs ist das Verschulden des Anbieters. Das Gesetz spricht in diesem Zusammenhang von dem “Vertreten müssen”. In der Praxis gibt es kaum Einwände, die der Lieferant oder Anbieter geltend machen kann, weshalb ihn an der verspäteten Leistung kein Verschulden trifft. Natürlich kann es sein, dass bestimmte Softwaremodule oder Teile von Drittlieferanten nicht geliefert werden können oder diese sich im Nachhinein als so mangelhaft herausstellen, dass man dies auf der Seite des Lieferanten nicht erkennen konnte und deswegen die Produkte gar nicht erst an den Kunden ausliefert. Diese Fälle bilden allerdings die Ausnahme. Ein Ausscheiden von Mitarbeitern entlastet den Anbieter nur dann, wenn bei den entsprechenden Mitarbeitern nicht absehbar war, dass diese dauerhaft nicht in der Lage sein würden, die ihnen überlassenen Aufgaben wahrzunehmen, so z.B. bei Schwangerschaft, Tod, dauerhaften Siechtum etc..Entlässt der Anbieter sein Personal, liegt Verschulden vor. Im Normalfall muss der Anbieter in den Fällen, in denen er eine Kündigung ausspricht dafür sorgen, dass ausreichendes Ersatzpersonal in der Lage ist, die vertraglich vereinbarten Leistungen rechtzeitig zu erbringen. Wie an anderer Stelle dargelegt, gerät der Anbieter auch dann nicht in Verzug, wenn eine Mitwirkungshandlung des Kunden nicht erfolgt ist und bestimmte vertragliche Vereinbarungen bestehen, die absichern, dass der Kunde zunächst leisten muss, bevor der Anbieter in Verzug gerät. Dass sich Changes auf den Projektplan auswirken können, bedarf keiner weiteren Ausführung. Ich kann in diesem Zusammenhang nur dringend davor warnen, im Rahmen des Changesmanagements eine Anpassung des Projektplans zu unterlassen.

Änderungen des Projektplans müssen nicht unbedingt explizit vereinbart werden  – es ergeben sich Beweisfragen, aber es kann auch sein, dass sich der Kunde und der Anbieter stillschweigend auf eine Verlängerung der einmal gesetzten Fristen einigen. In diesem Fall kann der Anbieter nur dadurch in Verzug geraten, dass der Kunden ihn mahnt. Das Gleiche gilt dann, wenn kein Fertigstellungstermin vereinbart wurde.

Im Grundsatz ist aufgrund dessen, dass in der Praxis sehr häufig eine konkludente Verschiebung der einzelnen Termine stattfindet immer der Weg vorzuziehen, dem Anbieter vorab eine Mahnung zu übersenden. Diese Mahnung sollte klipp und klar darauf hindeuten, dass der Kunden im Falle des fruchtlosen Ablaufes einer gesetzten Frist nicht mehr bereit ist, die Leistung in Empfang zu nehmen und als Erfüllung zu akzeptieren. Dies hat der BGH in einer jüngeren Entscheidung zum § 281 BGB wieder deutlich klar gemacht.

Im Falle des Verzugs kann der Kunde von dem Anbieter den Verzugsschaden geltend machen, §§ 280, 286 BGB. Der Verzugsschaden kann unter Umständen auch im entgangenen Gewinn liegen, wenn z.B. die Software bei rechtszeitiger Inproduktivsetzung dem Kunden Geld erspart hätte. Entsprechende Schadensersatzforderungen sind im Regelfall in der Praxis allerdings nur schwer zu fühlen. In Ansatz gebracht werden können aber z.B. die Kosten für nutzlos aufgewendete Leasinggebühren für die Hardware, Personal- oder andere Kosten, die nachweislich darauf zurückgehen, dass der Kunde infolge der verspäteten Lieferung einen kommerziellen Schaden erlitten hat.

Da die entsprechenden Verzugsschäden in der Praxis nur schwer darzulegen sind, behilft man sich bei dem Verfassen von Verträgen häufig dadurch, dass man Vertragsstrafen zu Lasten des Anbieters vereinbart. Aus dem Bereich der Bauverträge  – entsprechende Regelungen hat der BGH im Bereich des IT-Rechts noch nicht überprüft -  weiß man, dass eine Vertragsstrafe in Allgemeinen Geschäftsbedingungen pro Tag nicht mehr als 0,5 % der Auftragssumme überschreiten darf und grundsätzlich nur 5 % der Auftragssumme insgesamt als Schaden abdecken darf. Ob man im IT-Recht 10 % des Auftragswertes als pauschalierten Schadensersatz geltend machen kann, muss abgewartet werden.

Wichtig ist allerdings, dass der Kunde, der trotz verspäteter Lieferung noch die Leistungen annehmen will, sich die Geltendmachung der Vertragsstrafe bei der Annahme der Leistung vorbehalten muss (§ 341 Abs. 3 BGB).

Schutzfähigkeit der eigenen Software

Nach dem Willen des deutschen Gesetzgebers wird nicht alles,, was Software ist, geschützt, sondern nur Software, die die erforderliche geistige Schöpfungshöhe erreicht. Hierzu habe ich an anderer Stelle die Regelung des  § 69a UrhG vorgestellt, die die Voraussetzungen für die Schutzfähigkeit von Software bestimmt. Schlichter HTML Code ist zum Beispiel nicht vom Urheberrecht geschützt.  Der BGH hat zwar Erleichterungen vorgesehen, wenn es sich um komplexe Software handelt. Hier spricht, so der BGH (Urt.v. 3.3.2005), eine tatsächliche Vermutung für die Schutzfähigkeit des Programms. Diese Erleichterung hilft aber nur dann, wenn das Programm vollständig übernommen wurde. Eine weitere Darlegung ist bei 1:1 Übernahmen des gesamten Source nicht erforderlich.

Der Umstand, daß bestimmte Dinge gleich aussehen, der Ablauf oder die Funktion gleich sind, besagt nicht, daß das Programm kopiert wurde. Geschützt ist das Computerprogramm, nicht das, was es hervorbringt. Das kann im Einzelfall über den § 2 Abs.1 UrhG anders zu beurteilen sein, allerdings sind dessen Schutzvoraussetzungen so hoch, daß kaum jemals damit zu rechnen ist, einen Prozeß auf diese Art und Weise zu gewinnen.

Bei Teilübernahmen häufig Zwang zur Offenlegung des eigenen Codes

Übernahmen von einzelnen Teilen eines Computerprogramms sind aber in der Pracis häufiger und juristisch viel, viel unangenehmer zu führen. Hier muß man genau darlegen, welche Teile das Programm genau übernimmt. Im zweiten Schritt ist klarzumachen, daß genau diese Teile die Voraussetzungen des § 69a UrhG erfüllen, also vom Urheberrecht als Programm geschützt sind und daß es sich bei dem Programm der Verletzten um eine glatte Übernahme oder eine unfreie Bearbeitung handelt. Zur Erläuterung: Eine unfreie Bearbeitung (§ 23 UrhG) liegt dann vor, wenn das neue Programm zwar Teile des Alten übernimmt, aber das alte Programm in seiner Ideenstruktur so hinter das neue Werk trete, daß das alte Programm verblasse. Dahinter verbirgt sich der politische Wille, daß jede Idee auf einer anderen aufsetzt und man eben nicht das Ersinnen neuer Ideen sondern das Klauen von Ideen verhindern will. Also: Selbst dann, wenn klar ist, daß bestimmte Teile des Source übernommen wurden, kann das neue Programm als neuer, geistiger Schöpfungsschritt von einer solchen Eigenständigkeit gekennzeichnet sein, daß eine Urheberrechtsverletzung ausscheidet. Die Entscheidung hierüber obliegt dem Gericht, das einen Sachverständigen einschalten wird.

Um nun zu beweisen, daß das Programm des Verletzers die Urheberrechte am eigenen Programm verletzt, wir man prinzipiell bereit sein müssen, den eigenen Sourcecode dem Gericht und damit dem Gegner (!) in kommentierter Form zukommen zu lassen und die oben gemachten Darlegungen beizubringen. Sonst geht der Prozess verloren. Wer hat einen ausreichend kommentierten Source und ist bereit, die Gefahr einzugehen, daß der Gegner Kenntnisse über das Know How am Source erhält???

Der BGH hat in einem Patentverletzungsprozeß jüngst (Beschluß vom 16.11.2009) wieder dargelegt, daß die vom Sachverständigen ermittelten Erkenntnisse nur dann gegenüber den Parteien geheimgehalten werden dürfen, wenn anderenfalls zu befürchten ist, daß die offenlegende Partei einen wesentlichen Wettbewerbsnachteil riskiere. Nur in diesem Fall käme es in Betracht, das Gutachten nur einem begrenzten Kreis offenzulegen (Richtern, Anwälten), der möglicherweise eine gesonderte Geheimhaltungsvereinbarung abgeben müsse. Die Entscheidung über den Umfang der Offenlegung des kommentierten Sourcecodes ist damit Sache der Ermessensausübung des Gerichts.

Das Problem der Aktivlegitimation

Weiteres kommt hinzu: Juristisch bedeutsam ist der Terminus der Aktivlegitimation: Wer nicht in einem Urheberprozeß lückenlos darlegen kann, selbst Inhaber der ausschließlichen Nutzungsrechte (oder Urheber) des Computerprogrammes zu sein, besitzt keine Aktivlegitimation, und damit nicht das Recht, Unterlassungsansprüche an den Teilen des Programms geltend machen zu können. Das aber wird man in den allerwenigsten Fällen im Hinblick auf das gesammte Programm darlegen können. Die meisten Programme werden objektorientiert mit Tools geschrieben, die Programmbibliotheken enthalten. An diesen Programmbibliotheken besitzt nur der Inhaber der Rechte des Tools die absoluten Nutzungsrechte, also beispielsweise Microsoft oder via Sun Oracle. Das Kopieren oder Bearbeiten solcher Programmbibliotheken kann also nur von MC oder Oracle angegriffen werden (oder es wird genehmigt, den Prozess zu führen, was ich auch noch nicht erlebt habe).

Dieser Fall kommt relativ häufig vor. Mehrere Personen schließen sich zusammen, um Software zu programmieren und zu vermarkten. Daebi entsteht nach dem Gesetz automatisch eine Gesellschaft bürgerlichen Rechts. Eine Gesellschaft bürgerlichen Rechts wird schon dann gründet, wenn sich mehrere Personen zur Erreichung eines bestimmten  Zwecks für eine bestimmte Dauer zusammentun. Einen schriftlichen Gesellschaftsvertrag braucht man nicht.

Nur vergessen die meisten Personen in diesen Fällen, dass die entscheidenden Regelungen in Gesellschaftsverträgen für den Fall der Auseinandersetzung und Kündigung der Gesellschaft betroffen werden. Dies liegt in der Natur der Sache. Solang man sich versteht, braucht man keine Verträge und keine Rechtsanwälte. Regelungen bedarf es aber immer für den Fall, dass einer die Gruppe verlassen will, ausgeschlossen werden soll oder dass die Gesellschaft beendet werden soll. So wenig Eheverträge für den Fall des Funktionierens einer Ehe geschrieben werden – und deshalb meist nicht oder zu spät abgeschlossen werden – so wenig werden Gesellschaftsverträge für den Fall geschrieben, dass sich alle verstehen.

Im vorliegenden Fall hat man diesen Punkt übersehen,  zu Lasten des Geschäftsführers, der zugleich Programmierer war. Diesem stehen nach dem BGB nämlich keine Ansprüche auf Aufwendungs- oder gar Schadensersatz zu, weil er Tage- oder Monatelang ohne bezahlt zu werden für die Qualität einer Software gearbeitet hat, die nun von den anderen weiter vermarktet wird. Er steht nicht rechtlos da. Als Miturheber der Software, die noch vermarktet werden soll, hat er sicherlich Ansprüche gegen die Gesellschaft, die darauf gerichtet sind, eine angemessene Vergütung zu erhalten. Dafür ist aber nicht der Umfang seiner Tätigkeit gleich einem Angestellten maßgeblich, sondern der Wert der Software selbst. Sofern sich dieser am Markt überhaupt nicht etablieren lässt oder nur ein niedriger Preis für deren Vermarktung zu erzielen ist, ist auch der merkantile Wert der Ansprüche des Geschäftsführers als gering zu veranschlagen, unabhängig davon, wie viel Arbeit er in das Projekt hineingesteckt hat. Der Geschäftsführer kann in diesem Fall nur einen Wertersatz in Form von Lizenzgebühren geltend machen. Dieser Wertersatz ist garantiert niedriger als das, was der Geschäftsführer sich vorgestellt hat. Insofern kann nur dringend geraten werden, einen Gesellschaftsvertrag für eine Programmierergemeinschaft abzuschließen, der durch einen Rechtsanwalt begleitet wird. Die Kosten für solch einen Vertrag liegen bei weniger als 500,00 €.

Für den Bereich der Programmierung von Software sollte – und insoweit besteht Einigkeit zwischen Gerichten und Anwälten – grundsätzlich Werkvertragsrecht anwendbar sein. Wo der Prozeß der Planung und Herstellung eine Rolle für den Interessenausgleich zwischen den Parteien spielt, muß es Regelungen geben, die diesen Interessenausgleich realisieren. Das Das Kaufrecht schafft das nicht. Schlimmer noch: Standardverträge, deren Vertragsgrundlagen auf dem Werkvertragsrecht basieren, die also z.B. eine Abnahme, Mitwirkungspflichten des Auftraggebers etc. regeln, weichen immer von den grundsätzlichen Vorgaben des Kaufvertragsrechts ab und können auf dem Weg über § 307 Abs.2 S.1 BGB dazu führen, daß die Klauseln unwirksam sind. Der BGH ist in seiner Entscheidung vom 23.7.2009 genau diesen Weg gegangen.

Zu beachten ist auch, daß die Gerichte – zum Teil selbst der BGH (die Entscheidung des BGH vom 04.03.2010 deutet es an) diesen Weg häufig nicht gehen wollen. Das OLG München hat in einer Entscheidung vom 23.12.2009 (die Dank dem Kollegen Witte doch wenigstens in Teilen publiziert wurde) den eigentlich einschlägigen § 651 BGB nicht für anwendbar erklärt. Maßgeblicher Topos ist die Fragestellung, ob der Schwerpunkt der Leistung des Vertrags auf den Planungs- und Erstellungsleistungen oder auf der Lieferung der neuen Software liegt.

Dabei gilt als Faustregel, die sich aktuell aus der Rechtsprechung kristalisiert: Je mehr der Schwerpunkt der Leistung des Auftragnehmers in der Verwirklichung einer vom Auftraggeber vorgegebenen Planung liegt, desto eher ist Kaufrecht anwendbar.

Agiles Programmieren zeichnet sich aber dadurch aus, daß eben nicht alle Funktionen und Eigenschaften von Beginn an festgelegt werden, sondern dadurch, daß der Kunde nach der Evaluierung eines oder mehrerer Varianten der Software gemeinsam mit dem Auftragnehmer weitere Verbesserungen vornimmt. Dieser Weg der gemeinsamen Verbesserung ist juristisch im Bereich des Dienstvertragsrecht angesiedelt. Das Problem für den Kunden im Bereich des Dienstvertragsrechts besteht darin, daß der Kunde für einen bestimmten Preis kein vorher bestimmtes Produkt erhält.Er kauft vielleicht nicht die “Katze im Sack”, aber er weiß nicht genau, was er bekommt. Aus der Sicht des Kunden geht es darum, bestimmte Funktionen und Eigenschaften mit der Software zu erhalten. Dann ist Werkvertragsrecht anwendbar.

Die Lösung dieses gordischen Knotens kann meines Erachtens nur so aussehen, daß man in Standardverträgen davon ausgeht, Werkvertragsrecht und Dienstvertragsrecht nebeneinander anzuwenden. Bestimmte Mindestanforderungen der Software im Hinblick auf Funktion und Eigenschaft, die innerhalb einer vorab definierten Systemumgebung zu erzielen sind, müssen vorab festgelegt werden. Werden diese Eigenschaften nicht erreicht, sind Maßnahmen  für die Risikoverteilung, Fehlerbehebung und auch Rückabwicklung vorzusehen. Geht es um Customizing, wird Kaufrecht neben dem Dienstvertragsrecht anwendbar sein.

Weitere Funktionen und Eigenschaften sind mit dem Kunden in einem Prozeß neu zu erfinden oder zu verbessern, bis das Zeit- oder Kostenbudget aufgebraucht ist. Auch für diesen Teil wird für den Fall, daß der Kunde nicht zufrieden ist, ein Maßnahmekatalog vorzusehen sein, der einen angemessenen Interessenausgleich regelt. Nur wird dieser Katalog keine Rückabwicklungsmöglichkeiten für den Fall des Nichterreichens vorsehen können. Genau dies entspricht dem Dienstvertragsrecht.

Dabei ist es egal, wie die Leistungsbeschreibung genannt wird. Protokoll, Lastenheft, Pflichtenheft etc. Für den Juristen ist nur entscheidend nachzuweisen, daß sich die Parteien auf einen bestimmten Sollzustand geeinigt haben, anhand dessen festzustellen ist, ob der Vertrag erfüllt und die Vergütung geschuldet ist.

Die Leistungsbeschreibung selbst kann unmittelbar im Vertrag erfolgen. Meist geschieht dies in der Praxis, in dem ein Angebot verwendet wird, das sich mit den technischen Spezifikationen und den Preisen auseinandersetzt, während das Angebot selbst auf Allgemeine Geschäftsbedingungen verweist. Soll-Zustände werden auch im Lasten- bzw. Pflichtenheft fixiert. Es ist möglich, dass das Lastenheft wie auch das Pflichtenheft erst nach dem Abschluss des Vertrags konkretisiert werden.

Der Begriff Pflichtenheft wird von Juristen und Technikern unterschiedlich besetzt. Die Rechtsprechung verwendet den Begriff Pflichtenheft häufig für die Beschreibung von Leistungen, die die Techniker als Lastenheft beschreiben. Nach dem Jargon der Juristen bezeichnet das Pflichtenheft die fachlichen Vorgaben  – also das was der Techniker das Konzept nennt. Diese Begriffsverwirrung ist auch nicht weiter relevant, da es jedem freisteht, in einem Vertrag zu definieren, was ein Lastenheft ist, welche Funktionen und Inhalte es aufzuweisen hat. Das Gleiche gilt auch für das Pflichtenheft. Fehlen solche Definitionen in den Vertragsunterlagen müssen Techniker und Jurist aufpassen, nicht aneinander vorbei zu sprechen.

Die Erstellung des Lastenhefts ist grundsätzlich Aufgabe des Kunden. In den meisten Fällen wird aber vertraglich vereinbart, dass der Anbieter die Lasten- und Pflichtenhefte erstellt. Die Übersetzung der betriebswirtschaftlichen Ziele in technische Funktionen und Eigenschaften ist eine Aufgabe, die die Kunden meistens nicht beherrschen. Übernimmt der Kunde die Erstellung des Lastenhefts, muss der Anbieter bei der Übergabe des Lastenhefts prüfen, ob die Vorgaben des Kunden überhaupt technisch realisierbar sind. Der Kunde muss die betriebswirtschaftlichen Ziele und Strukturen darlegen, der Anbieter die Übersetzung auf die technische Ebene. Der Anbieter selbst ist verpflichtet, dem Kunden bei Vorliegen evidenter Mängel darauf hinzuweisen, dass die von dem Kunden gelieferten Vorgaben nicht konsistent sind. Dabei beschreibt das Lastenheft im Grundsatz nur die Aufgabe, die betriebswirtschaftlichen Ziele des Kunden in eine technische Lösung umzusetzen. Erstellt der Kunde das Lastenheft, so handelt er in eigener Verantwortung und auf eigenes Risiko. Der Kunde trägt das Risiko für die Unvollständigkeit der von ihm vorgenommenen betriebswirtschaftlichen Abbildung; der Anbieter aber trägt das Risiko, dass die im Lastenheft getroffenen betriebswirtschaftlichen Spezifikationen im Pflichtenheft nicht sauber abgebildet sind. Da der Anbieter die Erstellung des Pflichtenhefts meistens nicht ohne Mitwirkung des Kunden vornehmen kann  – dafür wird es im Laufe eines Projektes zu viele Rückfragen geben, viele Informationen werden erst nachträglich angefordert werden können -  empfehle ich immer dringend die Verpflichtung des Kunden an der Mitarbeit zur Erstellung des Pflichtenhefts als Hauptleistungspflicht auszugestalten.

Diese Rechtsprechung ist deswegen besonders zu beachten, weil der siebte Senat am 23.07.2009 und der zehnte Senat des BGH am 09.02.2010 übereinstimmend erkannt haben, dass gemäß § 651 Satz 1 BGB Kaufrecht auf die Verträge anzuwenden sei, die die Lieferung herzustellender oder zu erzeugender beweglicher Sachen zum Gegenstand hätten. Das würde also auch für Software gelten. Ich habe mich an anderer Stelle mit der Entscheidung vom 23.07.2009 ausführlich auseinander gesetzt.

Die meisten Verträge über die Erstellung von Software bzw. deren Anpassung im Wege von Customizing bzw. Parametrisierung sind Standardverträge, die nicht für jeden Vertrag neu angefertigt werden. Es sind AGB.

Standardverträge sind nach § 307 Abs. 2 Satz 1 BGB so auszugestalten, dass sie nicht wesentlich von den Entscheidungen des gesetzlichen Leitbildes des jeweiligen Vertragstyps abweichen dürfen. In nicht juristischen Worten ausgedrückt bedeutet, daß Standardverträge über Kaufvertrag nicht als Werkverträge ausgestaltet sein dürfen. Egal, welche Überschrift der Vertrag aufweist: Sofern die juristische Qualifikation eines Vertrags die eines Kaufvertrags ist, dürfen die Standverträge eben nicht von dem gesetzlichen Leitbild des Kaufvertrags im BGB wesentlichen abweichen. Eine solche wesentliche Abweichung besteht z.B. dann, wenn der Vertrag von Abnahme, Mitwirkungspflichten oder vorzeitigen Kündigungsrechten des Auftraggebers spricht, weil es diese Dinge im Kaufrecht einfach nicht gibt.

Sofern der BGH also Verträge über die Lieferung und Herstellung von Standardsoftware als Kaufvertrag qualifiziert, dürfen die Standardverträge nicht dem Werkvertragsrecht entsprechen. Anderenfalls sind sie unwirksam.

Der BGH hat für den Bereich des Maschinen- und Anlagebaus in zwei Entscheidungen vom 23.07.2009 und 09.02.2010 klar und deutlich formulieren, dass hier für die Lieferung beweglicher Sachen Kaufrecht anwendbar ist, auch wenn der Lieferung Planungs- und Anpassungsleistungen vorausgehen. Da Software vom BGH als bewegliche Sache qualifiziert wird, müssten diese Entscheidungen auch für den Bereich des Softwarevertriebs gelten.

Dem tritt der dritte Senat des BGH nun entgegen.Verträge, die “auf die Erstellung oder Bearbeitung einer speziellen, auf die Bedürfnisse des Auftraggebers abgestimmten Software gerichtet” seien, unterfielen dem Werkvertragsrecht oder Werkliefervertrag.

Wie also ist weiter zu verfahren?

Die Entscheidung des BGH vom 04.03.2010 erzeugt keine abschließende Rechtssicherheit. Wann ist ein Vertrag genau auf die Erstellung oder Bearbeitung einer speziellen, auf die Bedürfnisse des Auftraggebers abgestimmten Software gerichtet? Es fehlt an Kriterien, die eine Zuordnung dieser Rechtsprechung auf die Bereiche des Customizing und der Parametrisierung zuließe. Klar dürfte sein, dass Verträge die auf die Erstellung von Individualsoftware gerichtet sind, einzig und allein dem Werkvertragsrecht zu unterstellen sind. Verträge, die dem Customizing oder der Parametrisierung zuzuordnen sind, werden wie § 651 Satz 3 BGB dem Kaufrecht zu unterstellen sein, wobei hier ergänzend werkvertraglich rechtliche Bestimmungen zu Anwendung gelangen. Sofern in dem Vertrag und in den leitenden Unterlagen sichergestellt wird, dass die Planungsleistung, die auf die Anpassung der Standartsoftware gerichtet sind, im Umfang von mindestens 50 % der vom Auftragnehmer zu erbringenden Leistungen umfassen, kann man den Vertrag insgesamt dem Werkvertragsrecht unterstellen. Warum dies wirtschaftlich sinnvoll und vernünftig ist, habe ich an anderer Stelle dargelegt. Mit dem Erlass der Entscheidung des BGH vom 04.03.2010 steht diese Ansicht auf einem vernünftigen Fundament.

In der GPL v3 wird zwischen dem covered work und dem Aggregate unterschieden. Eine covered work ist ein Werk, dass voll unter die Lizenz fällt. Die GPL v3 ist nicht nur auf das ursprüngliche Programm, sondern auch auf die Bearbeitung anzuwenden. Der proprietäre Code ist offen zu legen. Das Aggregate besteht aus einer Verbindung von Programmen, die nach der GPL keine Infektion der proprietären Codes nach sich zieht. Die entscheidende Frage besteht also immer darin festzustellen, ob es sich bei dem hergestellten Produkt um ein covered work oder um ein Aggregate handelt. Unerheblich ist die Fragestellung, ob das Werk kompiliert oder nicht kompiliert ist.

Erwähnt seien noch die sogenannten Permissive Lizenzen, die keine Copyleft-Klauseln beinhalten. Hier seien die BSD und die MIT genannt. Diese Regelungswerke verlangen keine Offenlegung des proprietären Codes. Die nachfolgenden Ausführungen beziehen sich ausschließlich auf Fragestellungen, die dann auftreten, wenn die GPL zu Anwendung kommt. Hier sind folgende Fallgruppen zu unterscheiden:

1.

Einsatz von nicht proprietäre Softwareentwicklungsumgebung

Softwareentwicklungsumgebungen werden eigentlich überall eingesetzt.     Der Einsatz von Softwareentwicklungsumgebung stellt unter dem Gesichtspunkt des Copyleft-Effektes kein Problem dar. Es wird kein Code aus dem nicht proprietären Open Source in das erstellte Programm übernommen, es findet keine Modifikation statt.

2.

Schon schwieriger ist die Verwendung von eigenständigen nicht proprietären OS-Komponenten, die als Subsysteme verwendet werden. Die Verwendung solcher Subsysteme ist der typische Fall, den die GPL v3 unter der Ziffer 5 als Aggregate der nicht proprietäre Open Source Teil wird als eigenständiges Subprogramm verwendet, der erforderlich ist, um die proprietäre Anwendung durchzuführen. Der proprietäre Teil der Software, den das Software-Haus erstellt bleibt ein eigenständiges Werk, ebenso wie der nicht proprietäre Teil der OS. Es handelt sich insofern um ein Aggregate.

Weiter zu Teil 2

]]> http://www.anwaltskanzlei-online.de/2010/05/27/softwarelizenzrecht-embedded-systems-und-copyleft-teil-1/feed/ 1 http://www.anwaltskanzlei-online.de/2010/05/27/softwarelizenzrecht-embedded-systems-und-copyleft-teil-2/ http://www.anwaltskanzlei-online.de/2010/05/27/softwarelizenzrecht-embedded-systems-und-copyleft-teil-2/#comments Thu, 27 May 2010 10:02:22 +0000 Stefan G. Kramer http://www.anwaltskanzlei-online.de/?p=2193 Fortsetzung von Teil 1

3.

Schwierig sind die Situationen zu beurteilen, in denen eine dynamische Verlinkung zwischen dem proprietären Programm und dem nicht proprietären OS-Code vorgenommen werden. Zumeist geschieht eine solche dynamische Verlinkung dadurch, dass der Code des OS-Programmes in den Hauptspeicher des Computers geladen wird, wenn die Funktionalität benötigt wird. Häufig geschieht dies über Webapplikationen. Juristisch gesehen ist eine solche Verwendung von Open Source und proprietärer Software nicht einfach zu beurteilen, weil das Gesetz nicht zwischen einer Kombination im Arbeitsspeicher und einer Kombination in einem Festspeicher unterscheidet. Sofern die nicht proprietäre OS-Software sauber von dem proprietären Teil der Software unterschieden werden kann, etwa indem die proprietäre Anwendung die OS-Anwendung nur über eine klare Schnittstelle ansteuert, handelt es sich um einen Aggregate und der Copyleft-Effekt tritt nicht ein. Das Problem besteht aber darin, dass eine solche saubere Definition von Schnittstellen häufig überhaupt nicht möglich ist. Eine dynamische Verlinkung zwischen nicht proprietären OS-Code und proprietärer Software birgt immer das Risiko, dass der Copyleft-Effekt eintritt und der gesamte proprietäre Code offenzulegen ist oder eben im Falle des nicht Offenlegens des proprietären Teil des Codes eine Urheberrechtsverletzung vorliegt. Dies sind genau die Fälle, in denen technische Sachverständige und Rechtsanwalt zusammen arbeiten müssen, um eine Klärung zu erzielen. In diesem Zusammenhang sei noch bemerkt, dass die Verwendung von Software, die der GPL unterliegt  – also der General Public License -  bestimmte Probleme entschärfen kann. Einzelheiten können hier aber nicht dargelegt werden.

4.

Die vierte Gruppe besteht in der statischen Verlinkung von der der nicht proprietären Open Source mit proprietären Source. Hier gilt der Grundsatz, dass eine statische Verlinkung immer zu einer modification führt. Eine modification wird ein Werk hergestellt, dass ausreichend dauerhafter Natur ist, wesentliche und kreative Teile eines GPL-Programmes enthält, selbst hinreichen kreativ ist und inhaltliche Änderung des GPL-Programms nach sich zieht. Das deutsche Urheberrecht spricht hier von einem Werk der abhängigen Schöpfung oder einer abhängigen Bearbeitung. Eine solche modification zieht zwingend den Copyleft-Effekt nach sich.

5.

Die fünfte und letzte Fallgruppe ist rechtlich sehr einfach zu beurteilen: Dabei handelt es sich um die Verwendung von einzelnen Teilen, die dem Open Source entnommen werden, um neuen Text herzustellen. Da in diesen Fällen keine klare Abgrenzung zwischen dem alten und der neuen Source mehr möglich ist, handelt es sich zwingend um eine modification mit dem Effekt, dass der copyleft-Effekt eintritt.

Der § 69 f Abs. 1 ist die Spezialregelung zum § 98 Abs. 1, nach dessen Inhalt dem Rechtsinhaber ebenfalls ein Anspruch auf Vernichtung der Exemplare der Software zusteht. Anders als der § 98 Abs. 1 richtet sich der Anspruch aber nicht nur gegen den Verletzer der Urheberrechte, sondern gegen jeden Eigentümer oder Besitzer des illegalen Vervielfältigungsstücks. Sofern Software also illegal hergestellt wird, ist jeder einzelne Kunde des Softwareherstellers verpflichtet, die illegale Software zu vernichten. Die Kopien der Software sind dann rechtswidrig hergestellt, wenn ein Verstoß gegen § 69 c vorliegt. Was dann der Fall ist, wenn keine Legitimation nach dem § 69 d oder § 69 e in Betracht kommt. Wie bereits an anderer Stelle dargelegt, muss die Software ohne Zustimmung des Berechtigten hergestellt worden sein und die Zustimmung nicht nach dem § 69 d oder § 69 e entbehrlich ist.

Der Anspruch setzt keine Verschulden voraus was schlicht bedeutet, dass der Kunde die rechtswidrig hergestellten Leitstücke der Software zu vernichten hat, unabhängig davon, ob er wusste, dass die Software unter Verletzung von Urheberrechten hergestellt wurde oder nicht.

Der § 69 f Abs. 2 geht im § 95 a vor. Die §§ 95 a ff. sind über § 69 a Abs. 5 auf Computerprogramme nicht anzuwenden. Über die Verweisung nach § 69 f Abs. 1 Satz 2 über die §§ 98 Abs. 3 und 4 kann der Inhaber der Nutzungsrechte anstelle der Vernichtung auch die Überlassung der Vervielfältigungsstücke gegen Zahlung einer angemessenen Vergütung verlangen. Ebenso ist über § 98 Abs. 4 das Verhältnismäßigkeitsgebot anzuwenden. Dieser Umstand spielt immer dann eine Rolle, wenn die Software auf Datenträgern, insbesondere auf Hardware gespeichert ist. Natürlich soll verhindert werden, dass Festplatten herausgegeben werden; in der Literatur wird deshalb vorgeschlagen, dass auch eine Low-Level-Formatierung ausreichend ist. Die Vernichtung von Roms oder CD-Roms, DVDs oder Disketten und entsprechenden Dingen kann erlangt werden.

Der Anspruch verjährt gemäß § 102 in Verbindung mit § 69 a Abs. 4 innerhalb von drei Jahren ab dem Zeitpunkt der Kenntniserlangung der Rechtsverletzung bzw. der grobfahrlässigen Unkenntnis über die Rechtsverletzung, spätestens aber zehn Jahre nach der Verletzung (§§ 195, 199 Abs. 1, 4 BGB).

Die Haftung des Geschäftsführers folgt aus § 823 i. V. m. § 15a InsO wegen fahrlässiger Verletzung seiner Insolvenzantragspflicht. Danach haftet der Geschäftsführer des Unternehmens gegenüber allen Gläubigern, mit denen das Unternehmen nach Eintritt der Insolvenzreife einen Vertrag geschlossen hat, den die Gläubiger bei pflichtgemäßen Verhalten des Geschäftsführers nicht geschlossen hätten. Voraussetzung hierfür ist, dass eine Überschuldung der GmbH vorliegt. Im vorliegenden Fall bestand die Besonderheit darin, dass der Geschäftsführer die den Wert der Software mit dem vermuteten Gewinn aus dem Abverkauf der Software sowie den zu schließenden Softwarepflegeverträgen für die nächsten Jahre abgeleitet hatte, während die Software selbst nicht im Markt eingeführt und in weiten Teilen noch nicht fertig gestellt war. In der Folge geschah, was geschehen musste: Die Software wies eine Reihe von Mängeln auf und etablierte sich nicht im Markt. Die Lieferanten des Unternehmens konnten nicht bezahlt werden. Ihren Anspruch stellen sie nun nicht gegen die Gesellschaft, sondern gegen den Geschäftsführer, der es unterlassen hat, rechtzeitig Insolvenz anzumelden. Mit Erfolg, denn die Bewertung der Software war schlicht falsch. An dieser Stelle liegt eine der Schnittstellen zwischen Steuerberatung und rechtsanwaltlicher Beratung. In jedem Fall muss darauf geachtet werden, dass eine Software, die noch nicht ausreichend fertig gestellt und am Markt etabliert ist, nicht mit Phantasie-Werten in die Bilanz eingestellt wird.