Skip to main content
main-content
Top

About this book

Das Buch behandelt aus der Perspektive von Software-Häusern und Entwicklern alle für die Praxis relevanten Rechtsfragen. Auf moderne Entwicklungsmethoden und ihren Einfluß auf den möglichen Rechtsschutz von Software wird ebenso eingegangen wie auf die Rechte und Pflichten angestellter und freier Mitarbeiter. Erstmals wurde die Form eines interdisziplinären Dialogs gewählt, der es gestattet, "Softwerker" (wie Dr. P. Schnupp) und Juristen (wie Dr. F.A. Koch) schneller zum gemeinsamen Problemkern finden zu lassen. Viele ausführliche Checklisten und Rechtsprechungsnachweise geben den Lesern die Sicherheit, alle wesentlichen Probleme in den Griff zu bekommen. Das Buch führt außerdem wichtige juristische Diskussionen an einigen Punkten weiter und gehört deshalb zum Rüstzeug aller Rechtsabteilungen und Syndici von Software-Anbietern.

Table of Contents

Frontmatter

1. Informatik und Recht — zwei Sichten

Zusammenfassung
Seit altersher waren die „Sachen“, mit denen sieh das Recht beschäftigte, immer materiell. Software ist hingegen immateriell, und dies bereitet Juristen beträchtliche Probleme. Häufig wird sie deshalb lediglich als „Eigenschaft des Datenträgers“ betrachtet, auf dem sie gespeichert ist — eine Sichtweise, die in einer Zeit der verteilten Datenhaltung und Datennetze natürlich noch mehr Schwierigkeiten macht, als es früher bereits der Fall war. Deshalb leitet sich auch die rechtliche Bewertung der Software selbst sowie der Beziehungen zwischen Menschen, die mit ihr umgehen, fast ausschließlich aus zwei Rechtsgebieten ab, die beide nicht recht passen: dem Urheberrecht bezüglich dem Verhältnis zwischen Auftraggeber und -nehmer bei der Herstellung sowie dem Wettbewerbsrecht für Fragen des Vertriebs von Software-Produkten. „Urheber“ kann nur eine natürliche, nicht jedoch eine juristische Person sein, so daß Rechte von Unternehmen an Software hieraus nicht ableitbar sind. Zudem sind die Anforderungen für die Schutzfähigkeit aus dem Urheberrecht in Deutschland strenger als in allen anderen Ländern. Ob und wieweit fremde Schutzrechte in Deutschland und deutsche im Ausland durchsetzbar sind, ist sehr unterschiedlich — im Verhältnis zu den USA ist es sogar abhängig vom jeweiligen Bundesstaat! Warenzeichen und Dienstleistungsmarken schützen grundsätzlich nicht die Produkte selbst, sondern ausschließlich die Hersteller- oder Verkäuferidentifikation. Ansprüche bezüglich des „Inhalts“ eines Softwareprodukts können am ehesten noch durch einen Know-how-Schutz oder aus „unlauterem Wettbewerb“ begründet werden, sind aber oft schwer nachzuweisen und durchzusetzen. Schließlich sind zumindest kleine Software-Häuser meist sehr unkonventionelle Arbeitsstätten, was auch die rechtliche Beurteilung der Beziehungen zwischen Arbeitgebern und Mitarbeitern erschwert (und häufig anders ausfallen läßt, als es sich die Beteiligten vorstellten).
Frank Alexander Koch, Peter Schnupp

2. Das Software-Produkt

Zusammenfassung
Neben seinen softwaretechnischen Attributen hat ein Programm auch zahlreiche Eigenschaften, die relevant werden, wenn es als Rechtsobjekt fungiert. Sie sind nicht immer mit den technischen korreliert und deshalb oft auch für den Informatiker kontraintuitiv. So ist etwa die für den Urheberrechtsschutz wichtige „schöpferische Gestaltungshöhe“ kaum aus programmiertechnischen Begriffen wie „Umfang“, „Komplexität“ oder „Qualität“ abzuleiten. Fast gilt sogar das Gegenteil: da die festen Regeln der Software-Technologie die Gestaltungsfreiräume des Programmentwicklers einengen, ist ihre Befolgung eher ein Gegenargument gegen das Entstehen von Urheberrechten. Auch die Anforderungen, die ein Gericht üblicherweise an die Dokumentation eines Programms, die Abnahmevoraussetzungen und die Haftung für Fehler stellt, sind meist höher als das, was im normalen Software-Alltag angenommen wird. Deshalb sollte ein Software-Hersteller oder -Verkäufer auf eine sorgfältige Ausformulierung dieser Punkte in den Angeboten und Verträgen achten: er kann nicht damit rechnen, daß er „nur das liefern muß, was im Vertrag drinsteht“. Umgekehrt sollte sich aber auch der Auftraggeber oder Käufer genau überlegen, was er als Vorgaben verlangt. So ist die von öffentlichen Auftraggebern und Großfirmen oft geforderte Anwendung bestimmter Technologien, Programmiersprachen oder Entwicklungsmethoden nicht ungefährlich: sie kann dem Auftragnehmer eine bequeme und tragfähige „Ausrede“ liefern, warum ein Entwicklungsvorhaben erfolglos blieb oder hohe Mehrkosten und Terminverzögerungen erforderte.
Frank Alexander Koch, Peter Schnupp

3. Der Entwickler

Zusammenfassung
Software-Entwicklung ist heute fast immer Teamarbeit. Damit entstehen Probleme mit der Leistungszuschreibung, ihrer Kontrolle und den Vertragsverhältnissen zwischen Entwicklern und Arbeit- oder Auftraggebern: Oft ist noch nicht einmal klar, als was deren (rechtliche) Beziehung überhaupt gedacht war, geschweige denn, wie sie ein Richter bewerten wird. Dementsprechend unklar sind dann oft auch die gegenseitigen Rechte, Pflichten, Weisungsbefugnisse und Haftungen. Zwar kann für die meisten Programme mangels Gestaltungshöhe kein Urheberrechtsschutz verlangt werden. Greift er aber Platz, so begründet er eine Reihe von Rechten des Entwicklers an seinem Produkt, die zum Teil noch nicht einmal abdingbar sind und für einen Arbeitgeber unangenehme Überraschungen bedeuten können. Auch über die Pflichten nach einem Ausscheiden aus einem Unternehmen bestehen oft recht unklare Annahmen: So betreffen etwa Verschwiegenheitspflichten grundsätzlich nur anwendungsspezifisches Wissen, nicht jedoch das für einen Technologiebetrieb viel wichtigere, technische know how!
Frank Alexander Koch, Peter Schnupp

4. Der Auftraggeber

Zusammenfassung
Die Probleme, welche die „Immaterialität“ der „Sache Software“ bei der juristischen Bewertung von Streitigkeiten macht, wird besonders deutlich, wenn man die von einem Auftraggeber erworbenen Rechte an ihr diskutiert. Wem gehören zum Beispiel die Dokumentation und der Quellcode? Darf der Auftraggeber die von ihm erworbene Software überhaupt kopieren? Und — was kaum jemand weiß — bestimmte Programme, wie zum Beispiel Betriebssystemsoftware, gelten als „mit dem Rechner verbunden“, so daß in Sonderfällen ihr Lieferant Eigentumsrechte am Rechner des Auftraggebers erwerben kann, wenn dieser diese Software lädt! Welche Rechte an einem im Auftrag gefertigten Softwareprodukt erworben werden, ist ebenfalls weniger, als die meisten Auftraggeber meinen. So gibt es grundsätzlich keinen „Ideenschutz“: im Auftragsverhältnis realisierte Softwareideen darf der Auftragnehmer — aber, zu dessen Leidwesen, auch jeder andere — immer wieder in ähnlicher Form anderweitig nutzen. Die Immaterialität des entstehenden Produkts hat auch Auswirkungen auf die Projektdurchführung, die Leistungbeschreibung und die Abnahme. Hier muß man zwischen der (technischen) Leistungsstruktur und der (vertragrechtlichen) Leistungsdefinition unterscheiden, die meist schwer in auch nur annähernde Übereinstimmung zu bringen sind. Vor allem bei Schadensersatzansprüchen kann es hier auf (ihrerseits oft wieder streitige) Detailfragen ankommen, wie zum Beispiel die, ob ein vom Auftragnehmer erstelltes Pflichtenheft im Werk- oder Dienstvertrag angefertigt wurde. Und wenn gar moderne Prototyping-Techniken genutzt wird, kommt es zu juristischen Rekursivitäten: die Fortschreibung des Pflichtenhefts ist selbst Vertragsinhalt des Entwicklungsvertrags. Und vernachlässigt der Auftraggeber hierbei seine Mitwirkungspflicht, so kann dies Schadenersatzansprüche des Auftragnehmers begründen, da dieser dadurch bei seiner Leistungserbringung behindert wird. Schließlich können auch noch die Gewährleistungsfristen für Software-Produkte beiden Seiten unangenehme Überraschungen bereiten. Meist, aber nicht immer, betragen sie 6 Monate und sind damit für praktische Verhältnisse sehr kurz. Wenn der Auftraggeber nicht genau über diese Fristen und die für die Fristenhemmung nötigen Maßnahmen Bescheid weiß, hat der Auftragnehmer ausgezeichnete Chancen, sich seiner Gewährleistungspflicht einfach durch 6-monatiges „Totstellen“ zu entziehen!
Frank Alexander Koch, Peter Schnupp

5. Der Benutzer

Zusammenfassung
Benutzung von Software erfolgt meist auf der Basis von „Lizenzen“ — einer juristisch unkorrekten und deshalb zu vielen Mißverständnissen führenden Übersetzung des amerikanischen licence. Korrekt handelt es sich hierbei um Nutzungsverträge. Schon die Abgrenzung und erst recht die Überwachung der unter einem Nutzungsvertrag zulässigen Benutzerhandlungen ist schwierig. Selbst „lizenzfreie“ public domain-Software ist dabei nicht problemlos: Ihre oft hohe Originalität begründet leicht Urheberrechte des Entwicklers, die von Lizenzzahlungen oder auch dem Verzicht hierauf unabhängig sind. Urheberrechte sind oft auch das einzige Mittel, gegen Raubkopien vorzugehen, die sich Mitarbeiter des legitimen Lizenznehmers ohne dessen Einwilligung für den eigenen Gebrauch ziehen. Streitgegenstand zwischen Benutzer und Verkäufer oder Hersteller von Software ist oft die Fehlerbehebung, sei es aus Gewährleistungsverpflichtungen oder Wartungsverträgen. Vor allem bei Standardpaketen oder kleineren Individualentwicklungen sollte man hier nicht zu hohe Ansprüche stellen. Solange sich die Fehlerzahl im Rahmen des (leider) üblichen hält, ist es meist sinnvoller, sich mit ihnen und dem Lieferanten „zu arrangieren“, als unter allen Umständen sein „gutes Recht“ durchsetzen zu wollen. Deshalb sollte der Benutzer bei ihm angebotenen Wartungsverträgen prüfen, welche der darin enthaltenen Rechte (Fehlerbehebung, Betreuung über eine hot line, Versorgung mit neuen Versionen,…) für ihn die anfallenden Kosten tatsächlich rechtfertigen. Und schließlich sollte ein Anwender auch wissen, daß ihm unter extremen Bedingungen auch eine extreme juristische Waffe zur Verfügung steht: Zu weit gehende Nutzungseinschränkungen können für den Anbieter auch strafrechtliche Folgen haben.
Frank Alexander Koch, Peter Schnupp

6. Der Verkäufer

Zusammenfassung
Die Beziehung zwischen Käufer und Verkäufer von Softwareprodukten sind, je nach Größe und Preis der Produkte sowie deren beabsichtigtem Einsatz, sehr unterschiedlich, was damit zwangsläufig auch für die zu erwartenden Eigenschaften und Nebenleistungen wie Installation, Einführung und Gewährleistung gilt. Grundsätzlich ist der (vertragliche oder „übliche“) Gebrauch der erworbenen Ware der Maßstab für das, was der Käufer erwarten kann: so lange er diesen Gebrauch nicht berührt, ist ein „Fehler“ kein Mangel, auf den sich Gewährleistungs- oder Haftungsansprüche gründen können. Es empfiehlt sich deshalb, den beabsichtigten Gebrauch in Aufträgen oder Verträgen klar und vollständig festzulegen. Eigenschaften, auf die der Käufer Wert legt, sollte er ebenfalls ausdrücklich nennen (lassen); die Haftung für zugesicherte Eigenschaften ist nämlich verschärft und gilt unabhängig von einem eventuellen Verschulden des Lierferanten. Dies kann für Hersteller und Händler eine unangenehme Nebenwirkung von Prüfsiegeln darstellen: sie machen alle Eigenschaften, für welche das Siegel laut der Vergabe-Institution steht, zum Vertragsbestandteil. Auf einen entsprechenden Standpunkt kann sich auch ein Käufer stellen, der ein Produkt auf der Basis eines Software-Pröbchens erwarb und im endgültigen Programm bestimmte Eigenschaften (zum Beispiel die schnelle Antwortzeit oder den geringen Speicherbedarf!) nicht wiederfindet.
Frank Alexander Koch, Peter Schnupp

Backmatter

Additional information