Tiger103 ˚₊‧🐯.𖥔 ݁

IT-Recht

May 29, 202538 min read

Recht

Zusammenfassung der Informationen über das deutsche Rechtssystem

Die Quellen bieten einen umfassenden Überblick über das deutsche Rechtssystem, wobei der Schwerpunkt auf der Unterscheidung zwischen Zivilrecht, öffentlichem Recht und Strafrecht liegt. Es werden auch internationale Aspekte des Rechts und die wachsende Bedeutung des IT-Rechts behandelt.

Grundlegende Struktur des deutschen Rechtssystems

Das deutsche Rechtssystem ist in drei Hauptgebiete unterteilt: Zivilrecht, öffentliches Recht und Strafrecht. Jedes Rechtsgebiet hat eigene Gesetze und Verordnungen sowie spezifische Gerichte, die für die jeweilige Rechtsprechung zuständig sind.

Zivilrecht

  • Regelt die Rechtsbeziehungen zwischen Bürgern.
  • Kennzeichnend ist die Gleichberechtigung der beteiligten Parteien.
  • Beispiele für Untergebiete des Zivilrechts:
    • Vertragsrecht
    • Arbeitsrecht
    • Mietrecht
  • Zuständige Gerichte: Amtsgerichte, Landgerichte, Oberlandesgerichte, Bundesgerichtshof in Zivilsachen.

Öffentliches Recht

  • Behandelt die Rechtsbeziehungen zwischen Staat und Bürger.
  • Ein Merkmal ist das Ungleichgewicht der beteiligten Parteien, wobei der Staat hoheitliche Befugnisse ausübt.
  • Beispiele für Untergebiete:
    • Baurecht
    • Polizei- und Ordnungsrecht
    • Sozialrecht
  • Zuständige Gerichte: Verwaltungsgerichte, Sozialgerichte, Finanzgerichte.

Ausnahme

Wenn eine Behörde nicht hoheitlich handelt, fallen die Rechtsbeziehungen unter das Zivilrecht.

Strafrecht

  • Regelt die Ahndung von Straftaten.
  • Ein Bürger, der gegen eine strafbewehrte Norm verstößt, wird von der Staatsanwaltschaft angeklagt.
  • Juristische Personen können keine Straftaten begehen, aber zivilrechtlich haftbar gemacht werden.
  • Zuständige Gerichte: Strafgerichte.
  • Ein Schuldspruch im Strafverfahren kann Voraussetzung für eine zivilrechtliche Schadensersatzklage sein, aber ein zivilrechtliches Verfahren kann nicht zu einer abweichenden Entscheidung kommen, wenn kein Schuldspruch vorliegt.

Internationales Recht und IT-Recht

  • Zunehmende Bedeutung von länderübergreifenden Sachverhalten im Rechtsverkehr.
  • Das EGBGB (Einführungsgesetz zum Bürgerlichen Gesetzbuch) regelt, welches nationale Recht in internationalen Fällen anzuwenden ist.
  • Bei Verträgen können die Parteien das anzuwendende Recht wählen, aber zwingende Vorschriften dürfen nicht umgangen werden.
  • IT-Recht ist ein Querschnittsthema, das viele verschiedene Rechtsgebiete betrifft.
  • Der Einfluss des europäischen und internationalen Rechts auf das IT-Recht ist stark.

Rechtssubjekte und Rechtsobjekte

  • Rechtssubjekte sind Träger von Rechten und Pflichten (z. B. natürliche Personen, juristische Personen).
  • Rechtsobjekte sind Gegenstände, auf die sich das Recht bezieht (z. B. Sachen, Rechte).

Rechtsfähigkeit und Geschäftsfähigkeit

  • Rechtsfähigkeit ist die Fähigkeit, Träger von Rechten und Pflichten zu sein.
  • Geschäftsfähigkeit ist die Fähigkeit, Rechtsgeschäfte wirksam vorzunehmen.
  • Es gibt verschiedene Stadien der Geschäftsfähigkeit, die sich nach dem Alter und dem geistigen Zustand einer Person richten.

Deliktsfähigkeit

  • Deliktsfähigkeit ist die Fähigkeit, durch die Begehung einer unerlaubten Handlung zum Schadensersatz verpflichtet zu sein.
  • Wie bei der Geschäftsfähigkeit gibt es auch hier verschiedene Stadien, die sich nach Alter und Einsichtsfähigkeit richten.

Hinweis

Die Kenntnis der grundlegenden Prinzipien des deutschen Rechtssystems ist für alle von Bedeutung, die im geschäftlichen oder privaten Bereich tätig sind, insbesondere in der digitalen Welt, wo das IT-Recht zunehmend an Bedeutung gewinnt.

BESONDERHEITEN IT-VERTRÄGE

  • Rechtliche Einordnung von IT-Verträgen
  • Allgemeine Gesichtspunkte
  • Verwendung von AGB bei IT-Verträgen
  • spezielle Lebenssachverhalte in IT-Projekten

EINORDNUNG VON IT-VERTRÄGEN

Zuordnung nach Leistungsgegenstand

  • Software- / Hardwarekauf oder -miete
  • Consulting-Leistungen im Hard- / Softwarebereich
  • Wartung und Pflege eines IT-Projekts / Hardware
  • Sonstige Beratungsleistung / Support, Hotline, Service
  • Projektverträge / Outsourcing
  • Forschungs- und Entwicklungsverträge (FuE)

⇒ Oft keine klassische Kategorisierung nach BGB-Vertragstypen möglich

Zuordnung nach Leistungsart

  • Dauerhafte Leistungen
  • Einmalige Leistungserbringung
  • Beteiligte des IT-Vertrages
    • Anbieter (=Leistungserbringer)
    • Kunde (=Leistungsempfänger)

Warum ist der Vertragstyp überhaupt wichtig?

Grundsätzlich gilt ja (wie gelernt): Vertragsfreiheit = Privatautonomie

  • Nicht immer gelingt die konkrete Beschreibung der Rechte/Pflichten
  • Fragestellung: welche Leistungen / Bündel sind wie rechtlich zu behandeln?
  • der “gemeine” Jurist stellt immer die Frage nach der Anspruchsgrundlage: *WER- will *WAS- von *WEM- WORAUS?
  • Beispiele:
    • A will Lieferung bestellter Hardware von B aus Kaufvertrag (§ 433 BGB)
    • A will eine Softwareanpassung von B aus Werkvertrag (§ 631 BGB)

KAUF VON HARDWARE: § 433 BGB - I

Hintergrund

  • Erwerb von Hardware auf Dauer gegen Einmalentgelt
  • In Realität sehr unterschiedlich komplex: von Monitor bis zu Serverfarm
  • Meist auch Softwarebestandteile inkludiert (Treiber-CD o.ä.)

Wichtige Bereiche

  • Aufklärung und Beratung im Vorfeld
  • Vertragl. Hauptleistungs-, Neben- und Zusatzpflichten
  • Einräumung von Nutzungsrechten
  • Umgang mit Mängeln

Grundpflichten Unmittelbar aus § 433 BGB

  • Verkäufer: Sache übergeben – Eigentum verschaffen
  • Käufer: Sache abnehmen – Kaufpreis bezahlen

Gefahrübergang

  • Mit Übergabe = Gefahrübergang nach § 446 BGB
  • Ordnungsgemäße Übergabe erst mit Übergabe aller Komponenten:
    • Keine ordnungsgemäße Ablieferung, wenn Handbuch fehlt
    • Wenn Einweisung vereinbart
    • Ablieferung erst nach vereinbartem Probelauf erfolgt
  • Besonderheit Standardsoftware: vom BGH Erprobung abgelehnt: Übergabe direkt mit Eintritt in Machtbereich Käufer Übergabe

Eigentumsvorbehalt

  • Normalfall zur Risikominimierung bei ausbleibender Zahlung
  • Wirkung: Eigentumsübertrag unter aufschiebender Bedingung vollständiger Bezahlung des Kaufpreises: §§ 158 BGB iVm § 449 BGB
  • Im Unternehmensbereich Steigerung: sogen. erweiterter EV (Haupt-Lieferant an Sub-Lieferant und dieser an End-Kunde)

Änderungsvorbehalt

  • Gerade bei großen Beschaffungen relevant (1.000 neue Rechner)
  • Anbieter kann sich Recht auf Änderung einzelner Komponenten ausbedingen (z.B. andere Festplatten, Grafikkarten o.ä.)
  • Entscheidend idR.: bleiben Leistungsdaten identisch? Dann zulässig
  • Pflichten des Käufers
    • Kaufpreiszahlung und Abnahme: Schaffung Vorauss. für Aufbau / Installation,
    • Sicherung des Datenbestandes, wenn HW-Austausch erfolgen soll
  • Im Handelsbereich: sofortige Untersuchungspflicht, § 377 HGB,

KAUF VON HARDWARE: § 433 BGB - II

Weitere Nebenleistungspflichten

  • Installation: aus Umständen zu entnehmen, heute zunehmend Hauptpflicht, unsachgemäße Installation ist Sachmangel iSd § 434 II BGB
  • Einweisung und Schulung: zumindest grundsätzliche Einweisung erforderlich, so daß Käufer System künftig eigenständig unter bloßer Zuhilfenahme des Handbuches bedienen kann, ansonsten Schulung idR nur im Rahmen gesonderter Vereinbarung
  • Nutzungsrechte: bei HW mit Betriebssystem idr erforderlich, bei Kauf HW/SW-Bundle idR in Form Nutzungsbedingungen

Beispiele für Rechtsmängel im IT-Umfeld aus der Rechtsprechung:

  • Ständige maschinenseitige, nicht steuerbare Fehlermeldungen
  • Komponenten, die von vertraglicher Vereinbarung abweichen
  • Regelmäßige Programmabstürze, Stillstand der Hardware
  • Ausfall von Schnittstellenkarten
  • Nichterreichen vereinbarter Reaktions- oder Rechenzeiten

Gegenbeispiele

  • Kein Mangel wenn Komponenten von verschiedenen Herstellern
  • Kein Mangel bei Geräuschentwicklung innerh. Hersteller-Angabe

Herstellerangaben

  • § 434 BGB: Eigenschaft, die Käufer nach öff. Äußerung des Herstellers in der Werbung oder Beschreibung erwarten kann
  • Garantien: Gesetzliche Garantieregelung: § 443 BGB
    • Verkäufer will in vertragsmäßig bindender Weise die Gewähr für eine Beschaffenheit der Kaufsache übernehmen und für alle Folgen eines Fehlens einstehen
    • Üblicherweise gesonderte „Garantiekarten“ o.ä. beigefügt
    • Ggf. gesonderter Garantievertrag mit Hersteller
  • Wichtig: Wort „Garantie“ nicht zwingend: aus Kontext und Formulierungen und z.B. Betonung bestimmter Eigenschaften kann sich auch eine Garantieerklärung ergeben

KAUF VON HARDWARE: § 433 BGB - III

Rechtsfolgen bei Mangel

  • § 437 Nr. 1 iVm § 439: Nacherfüllung = Lieferung mangelfreier Sache / Mängelbeseitigung
  • § 439 II: Kosten der Nacherfüllung (Weg, Arbeit, Material, Gutachter, RA) trägt Verkäufer
  • § 439 III: Käufer hat Wahlrecht, kann aber eingeschränkt sein, wenn nur mit unverhältnism. Kosten für Verkäufer mögl.
  • § 275: kein Nacherfüllungsanspruch, wenn Hardware nicht mehr lieferbar, weil z.B. diese nicht mehr hergestellt wird
  • Pflicht des Käufers, vorab zu prüfen, ob Störung in seinem Verantwortungsbereich liegt
  • Nach Ablauf der Frist zur Nacherfüllung
    • §§ 440, 323, 326 V BGB: Rücktritt
    • § 441 BGB: Minderung Kaufpreis
    • §§ 440, 280, 281, 283 und 311a BGB: Schadenersatz Rücktritt

Aufklärungs- und Beratungspflichten

  • z.B. bzgl Leistungsfähigkeit
  • Geschwindigkeit
  • Kapazitäten
  • Eignung für Einsatzzweck des Kunden
  • Systemvoraussetzungen der einzusetzenden SW
  • korrekte Zusammenarbeit mit anderer SW
  • Umfassende Beratung bei HW für Datenbank, wenn Käufer Laie
  • Umfassende Beratung, wenn Anbieter-Einfluß auf geplante SW
  • Beratung, wenn Fachkenntnis zur Inbetriebnahme erforderlich
  • Beratung, wenn HW „Auslaufmodell“ und für Einsatz wichtig

⇒ Keine umfassende Beratung in Elektrofachmärkten zu erwarten! ;-) ⇒ Bei Verstoß: ggf. Schadensersatz aus §§ 280 I, 311 II BGB

KAUF VON SOFTWARE: § 433 BGB - I

Einordnung

  • Gem. BGH Erwerb von Standardsoftware grds. Kauf
  • Standardsoftware = Software, die für Vielzahl von Nutzern vorgefertigt wurde und auf bestimmte Anwendungen oder Funktionalitäten beschränkt ist
  • Klassische Problemfälle
    • Anpassung Standardsoftware auf spezielle betriebliche Bedürfnisse des Kunden (ggf. Werk)
    • Erstellung von im Standard nicht vorhand. Funktion (ggf Werk)
    • Einarbeitung und Schulung des Personals (im Normalfall Werk)
    • Regelungen zu Updates / Upgrades und deren Kostenpflicht
    • Regelungen zu kostenpflichtigem Support- und Wartungsvertrag

Leistungsgegenstände

  • Verkäufer: Sache übergeben – Eigentum verschaffen
  • Käufer: Sache abnehmen – Kaufpreis bezahlen
  • Ggf. zusätzliche Leistungsbeschreibung sinnvoll: Eignung der SW, um bestimmte Anforderungen zu erfüllen
  • „Übergabe“ bei Software:
    • Heute oft keine Datenträger-Übergabe mehr
    • Übertragung über Datennetze/Aufspielen auf HW des Kunden
    • Übergabe Dokumentation: Handbuch Pflicht, weit. Dokumentation ggf. vertraglichzu regeln
    • Aktuell zumeist noch ausgedruckte Version Handbuch erwartet, Tendenz abnehmend, insbes. bei sehr umfangr. Standard-SW

Mitwirkungspflichten Käufer/Kunde

  • Im Kaufrecht im Ggs zum Werk (§ 642 BGB) keine Regelung
  • jedoch gem §§ 241/242 BGB “zu Mitwirkung verpflichtet”
  • Bei Verkauf von Standardsoftware „über den Ladentisch“ selten
  • Bei hochpreisiger oder komplexer Standardsoftware durchausübliche Pflichten:
    • Durchführung der Datensicherung
    • Erstellung von Störungsmeldungen in vorgegebener Form
    • Vorhergehende Erforschung der Störung auf eigener Seite
    • Einräumung eines Fernzugriffs zur Mängelbeseitigung
    • Benennung eines qualifizierten Ansprechpartners
    • Schaffen der Installationsvoraussetzungen
    • Zurverfügungstellung von Schulungsräumen und –ausrüstung
    • Aufspielen Patches/Updates/Upgrades strittig: § 437 iVm 439

Nutzungsrechte

  • Wie Kaufrecht, gleichzeitig idR. urheberrechtlicher Schutz
  • Üblicherweise Nutzungsregelungen beiliegend
  • Grds. ist zeitl. uneingeschränktes Nutzungsrecht zu gewähren
  • Grds. keine Beschränkung der Mindestrechte nach § 69d ff UrhG
  • Weitere Einschränkungen ggf. gem. §§ 305 ff BGB oder KartellR
  • Verschiedenste Lizenzformen etabliert und zulässig (concurrent user, named user, Enterprise-Volumenlizenz uvm)
  • Weiterverkaufs-Beschränkung heute nach hM unwirksam

KAUF VON SOFTWARE: § 433 BGB - II

Mangel bei SW

  • Technisch und juristisch anerkannt: Software nie mangelfrei
  • Mathematisch beweisbar: allenfalls Einzelfunktionen nach best. Kriterien fehlerfrei erstellbar, kompl. SW niemals
  • Rechtsprechung zum „Mangel“ bei Software
    • Fehlen von Funktionen
    • Lieferung Demo- statt Vollversion
    • Leistungs- und Komforteinschränkungen
    • Konzeptionsmängel
    • Programmsperren (Dongles, Registrierung, Passwortschutz o.ä.)

Behandlung von Mängeln bei Software

  • unzulässig, wenn diese vertragsgemäße Nutzung einschränkt:
    • hoher Speicherbedarf
    • Performance-Einbruch bei Massendaten-Bearbeitung
    • fehlende Kompatibilität zu anderer Software
    • Erzeugung fehlerhafter Ergebnisse
    • zu lange Wartezeiten zur Ergebnisausgabe
    • Druckgeschwindigkeit zu gering
    • Festplattenzugriff ungewöhnlich langsam
  • Bedienbarkeit als Mangel?
    • Bei Standardsoftware im Massengeschäft oft Frage der „leichten Bedienbarkeit“
    • jedoch nicht unbedingt bei komplexer Branchen-spezifischer Standard-Software
  • Übereinstimmung mit gesetzlichen Vorgaben
  • Alter Programm kein Mangel, wenn korrekt funktionsfähig

Probleme bei „Mangel“ einer Software:

  • Grds. Nachbesserungsrecht: §§ 437 Nr. 1, 439 BGB
  • Problem bei nichtbehebbaren Mängeln mittels Patch o.ä.:
    • Nachbesserung i.O., wenn Umgehung angemessen und Ablauf nicht beeinträchtigt
    • umständlicher Workaround idR nicht
  • Üblicherweise Einteilung in: Betriebsverhindernde Mängel / Betriebsbehindernde Mängel / Sonstige / leichte Mängel
  • Rechtsfolgen eines Mangels: § 437 BGB
    • § 439 BGB: Recht zur Nacherfüllung
    • §§ 440, 323, 326 V BGB: Rücktritt nach Frist Nacherfüllung
    • § 441 BGB: Minderung Kaufpreis nach Frist Nacherfüllung
    • §§ 440, 280, 281, 283 und 311a BGB: Schadenersatz neben Rücktritt

KAUF VON SOFTWARE: § 433 BGB - III

Spezialfall: Schutzhüllenverträge

  • Kunde soll durch Öffnen einer Verpackung Einverständnis mit den von aussen nicht einsehbaren oder lesbaren AGB erklären
  • auch „Enter-Vereinbarung“ genannt = Installation erst nach „Enter“-Taste
  • Verwendung hauptsächl. bei Standardsoftware im Massengeschäft (Herkunft: US-Markt)
  • Zulässigkeit strittig:
    • Aufreissen einer Schutzhülle Keine Handlung mit Erklärungsbewußtsein
    • Mindestens fehlt Rechtsbindungswille, wenn Öffnen notw., um Einverständnismit der Regelung überhaupt prüfen zu können
    • Ausserdem vmtl gem. § 305 II Nr.2 BGB unwirksam, da keine zumutbare Möglichkeit Kenntnisnahme AGB vor Vertagsschluss

Aufklärungs- und Beratungspflichten

  • Bei Standard-SW: „für Vielzahl von Kunden“ (= Massengeschäft) besteht grds. keine spez. Aufklärungs- und Beratungspflicht
  • Beispiele
    • Systemberatungshaus hat vorab über spezielle Kompatibilitätsvoraussetzungen zu beraten
    • Aufklärung Sperre/Zwangsregistrierung nach 25-maligem Aufruf
    • Keine Aufklärungspflicht, daß SW überdimensioniert, wenn diese einziges Produkt und sonst Verweis auf Konkurrenz notwendig wäre
    • Keine Pflicht bzgl jeder verfügbaren Einzelfunktion, wenn wie bei Vorversion gezielt Version mit beschränktem Umfang gewählt
    • Keine Beratungspflichtverletzung für Empfehlung zu de facto nicht erforderlichem Ausbau Arbeitsspeicher
    • Beratung über geeignete SW und ggf. Untersuchtungspflicht der betriebl. Abläufe, wenn Käufer erkennbar vollkommener Laie

SPEZIALFALL: HARD- UND SOFTWARE ALS EINHEIT

Formen

  • Bezeichnung als „Komplettpaket“ / „Bundle“ / „Gesamtlösung“
  • Software gekoppelt an bestimmte Hardware (Dongle o.ä.)
  • Hardware wird teilweise speziell für Software angeschafft

Relevanz

  • wenn z.B. Teil-Leistung nicht ordentlich erbracht sind:
    • HW / SW komplett oder teilweise inkompatibel
    • einzelne Hardwarekomponenten stören das Gesamtsystem

Rückabwicklung

  • Für den Erwerber ist ein Teil praktisch nicht einzeln nutzbar
  • Daher Rückabwicklung des Gesamtvertrags für ihn sachgerecht: § 323 V S.1 BGB:
  • Erwerber kann vom Vertrag zurücktreten, wenn an Teilleistung kein Interesse besteht
  • Für Lieferant üblicherweise Interesse an getrennter Behandlung

SOFTWARE-ERSTELLUNG - I

Rechtliche Form(en): üblicherweise typengemischter Vertrag

  • Installation ⇒ Werkvertrag
  • Parametrisierung ⇒ Dienstvertrag / Werkvertrag
  • Schulung ⇒ Dienstvertrag
  • Erstellung einer Dokumentation ⇒ Werkvertrag

Wiederholung: wie unterscheiden sich Dienst- und Werkvertrag?

  • Dienstvertrag: Leistung wird geschuldet:
  • Werkvertrag: Erfolg wird geschuldet:

Vorvertragliche Pflichten

  • Wie üblich Aufklärungs- und Beratungspflichten
  • Da individuell auf Kunden zugeschnittene Lösung, ist Aufklärung und Beratungsumfang üblicherweise hoch anzusetzen
  • Sinnvoll ist, in eigene, klar abgegrenzte Beratungsprojekte zu “schneiden”: schrittweises Herausarbeiten der Lösung
  • Klares Lasten- und Pflichtenheft / Leistungsbereiche
    • Neu-Programmierung kundenindividueller Software
    • Um- oder Zusatz-Programmierung von/zu Standardsoftware
    • Verbindung unterschiedlicher Systeme oder Komponenten

Wichtig

  • Kunde will regelm. bei Standardsoftware Verbindung aller Bestandteile: angepasste Software als Zielsetzung
  • Hersteller will üblicherweise klare Trennung, da Standardsoftware auch ohne Erweiterungen einsetzbar

⇒ klares Lastenheft dringend empfohlen

SOFTWARE-ERSTELLUNG - II

Haupt- und Nebenleistungspflicht

  • Entwicklung der Software
  • Erstellen von Handbüchern, Dokumentationen
  • Überlassung der Software (meist incl. Quellcode!)
  • Vollständige Einräumung der Nutzungs- und Verwertungsrechte
  • Wie oben oft tiefgehende Mitwirkungspflicht bei Erstellung Pflichtenhefts (=techn. Lastenheft!)

Typische Nebenpflichten

  • Umgang mit Change-Requests sollte sauber geregelt werden
  • Übergabe Quellcode sollte vertraglich geregelt werden: insb. bei beabsichtigter
  • Vermarktung oder eigener Pflege / Weiterentwicklung durch Kunde
  • Soweit für Weiterentwicklung relevant, kann zusätzl. Dokumentation auch des Quellcodes erforderlich sein

Mitwirkungspflichten des Kunden

  • Bereitstellung Personal zur Erarbeitung der Lösung
  • Bereitstellen Testfälle und –daten, -personal
  • Bereitstellung Lizenzen (Dritt-Systeme), Entwicklungs- und Testsysteme
  • Bereitstellen Unterlagen, Pläne, Ansprechpartner
  • Datensicherung
  • Aufbereitung/ Übergabe Alt- und Echtdaten

Leistungsüberprüfung - Bei SW-Erstellung besonders relevant

  • Pflicht zur Testphase und Bereitstellung zur Abnahme nur in qualitätsgesichertem Stand
  • Zurverfügungstellung auf speziellem Testsystem
  • Bestückung mit definierten Testdaten, Durchführen definierter Testfälle incl. Protokollierung / Kategorisierung gefundener Fehler
  • Definition Anzahl tolerierbarer Fehler: „leichte Fehler“ im 4-stell. Bereich nicht unüblich!
  • Nach Abnahme: Übertragung auf Produktivsystem, Beginn Produktivbetrieb
  • Ggf. Migration Altdaten
  • Bei fehlender Abnahme: Mängelbeseitigung und üblicherweise komplett neuer Testdurchlauf.

⇒ Typischerweise: Kunde will Abnahme grds. mögl. spät, Lieferant grds. mögl. früh!

WARTUNG UND PFLEGE - I

Rechtliche Form(en)

  • Gegenseitige Verträge gem. §§ 320 ff BGB
  • Bündelung verschiedener Leistungspflichten
  • Dauerschuldverhältnisse für bestimmte oder unbestimmte Zeit

Hardware-Wartung:

  • Erhalt der Betriebsbereitschaft
  • Instandsetzung
  • Fehlerbehebung
  • Üblicherweise auf Erfolg ausgerichtet = werkvertrag

Software-Wartung:

  • Im Wesentlichen 3 unterschiedliche Leistungsbereiche:
    • Sicherstellen Funktionsfähigkeit der Software
    • Beseitigung Fehler
    • Lieferung neuer Versionen, Aktualisierung, Verbesserung

WARTUNG UND PFLEGE - II

Nebenleistung

  • Hotline-Service, Informationsleistungen = meist DienstV
  • Sicherstellung Funktion = WerkV
  • Lieferung neuer Programmversionen = wenn zur Erfüllung gesetzl. oder technischer Voraussetzungen, dann eher WerkV
  • sonstige Verbesserungen typischerweise Dienstvertrag
  • Keine Pflicht zur Entwicklung bestimmter gewünschter Funktionen, Hersteller einer StandardSW ist frei in Entscheidung, in welche „Richtung“ er Software entwickeln will!
  • Upgrades und Updates teilw. differenziert:
    • Upgrade= Funktionsverbesserung,
    • Update=Fehlerbehebung
  • Kein Zwang zur Abnahme aller Updates / Upgrades per AGB!

Pflichten des Kunden:

  • Zahlung der vereinbarten Wartungs- und Pflegegebühr
  • Vergütungsvarianten: Pauschalen, Fixpreise, Stundenkontingente
  • Gesondert zu vergüten sind z.B. Ersatzteile für Hardware o.ä.
  • Preisanpassungsklauseln grds. möglich, aber AGB-Kontrolle: sofern Gewichtung bereits bei der Gesamtkalkulation offen gelegt
  • Duldung von Wartungs- und Pflegemaßnahmen
  • Durchführung von Datensicherungen
  • Störungsmeldungen in bestimmter Form und mit best. Tool

Pflichtverletzungen

  • Verzögerte Durchführung einer Leistung
  • Nichtleistung
  • Mangelhafte Leistung (nicht entspr. vertraglicher Vereinbarung)

Folgen

  • Bei Schlechtleistung ggf. Rücktritt
  • oder außerordentliche Kündigung

SOFTWARE – MIETE / LEASING / ASP - I

Unterschied zum Kauf: zeitlich begrenzte Nutzung

Vorteile

  • Keine vollständige Finanzierung von Hard- und Software
  • Kein Nutzungszwang für ggf. hochpreisige SW auf lange Zeit
  • Schnellere Möglichkeit der Kündigung
  • Nutzung aktuellerer Hard- / Software
  • Positive steuerliche Auswirkung und Abschreibungsmöglichkeit
  • Schnellere Skalierbarkeit durch Zumietung von Kapazitäten

Aber

  • Vorteile oft theoretischer Natur: Auch geleaste SW wird bei komplexen Systemen nicht „nebenbei“ oder regelmässig durch neue SW ersetzt (Migrationsaufwände u.ä.)

Pflichten des Vermieters, § 533 I BGB

  • Gebrauchsüberlassung in einem zum vertragsgemäßen Gebrauch geeigneten Zustand
  • Erhalt in diesem Zustand

Pflichten des Mieters, § 533 II BGB

  • Entrichtung Mietzins Gebrauch nur zum vertragsmäßigen Zweck
  • Duldung von Erhaltungsmaßnahmen (idr kein zusätzlicher Wartungsvertrag erforderlich)
  • Teilw.: Zugang zu Wartungszwecken gewähren
  • Kein Recht zur Überlassung an Dritte ohne Zustimmung und keine Weitervermietung: § 540 BGB

SOFTWARE – MIETE / LEASING / ASP - II

Mietzins

  • Pauschale, periodische Entgeltzahlungen (z.B. monatl.)
  • Nutzungsabhängige Entgelte (z.B. Datenvolumen, Useranzahl)
  • Preisanpassungen nur iRd § 307ff BGB

Veränderungen durch Vermieter

  • Änderung schon in regelmäßigen Fehler-Updates zu sehen ⇒ unproblematisch
  • Anpassung an rechtliche Änderungen ⇒ unproblematisch
  • Berechtigung zur Veränderung ohne gesonderte Vereinbarung ⇒ eher nein

Veränderungen durch Mieter

  • Beachtung von Vorschriften des Urheberrechts
  • Bei Veränderungen fraglich, ob „vertragswidriger Gebrauch“:
  • z.B. Änderung des Aufstellortes gemieteter Hardware ⇒ Zustimmungspflicht des Vermieters
  • keine Dekompilierung und Veränderung
  • Mindestrechte aus UrhG: §§ 69d II und III, 69e, 69gII (kommt noch später :)
  • Einräumung von Rechten
    • Erforderliche Nutzungsrechte bei SW zwingender Bestandteil
    • Klarstellung der Einräumung eines zeitlich begrenzten Rechts
    • Inhaltlich, zeitlich, räumlich beschränkbar

SOFTWARE – MIETE / LEASING / ASP - III

Mängel:

  • Grds. gleich zu bewerten wie bei Kauf Hard-/Software
  • z.B.: Einhaltung gesetzlicher und technischer Normen
  • Beispiele aus Rechtsprechung
    • Mangel gesamter Anlage, wenn Untauglichkeit 1 Komponente Einsatzfähigkeit der gesamten Anlage betrifft
    • IT-Anlage mangelhaft, wenn Datensicherung nicht funktional
    • Dongle oder andere Kopierschutz kein Mangel, wenn der vertragsgemäße Gebrauch nicht eingeschränkt ist
    • Exkurs Audio-CD: Kopierschutz Mangel, wenn zu Nicht-abspielbarkeit einer CD in einer Vielzahl von Playern führt
    • Rechtsmangel, wenn Gebrauch der Software dauerhaft oder teilweise durch Rechte Dritter entzogen: § 536 III BGB

Mangelfolgen: Minderung Mietzins

  • „angemessen herabgesetzte“ Miete: § 536 I BGB
  • Nur unerhebliche Minderung der tauglichkeit bleibt außer Betracht: § 536 I BGB
  • Für Dauer der Nichtgebrauchsfähigkeit vollständig von Pflicht zur Mietzins-Zahlung befreit: § 536 I BGB
  • Schadenersatz und Aufwendungsersatz: § 536a BGB
    • Schaden vor Übergabe: verschuldensunabh. Haftung Vermieter
    • Schaden nach Übergabe: Verschulden Vermieter erforderlich
  • Wichtig
    • Mieter zur Anzeige des Mangels verpflichtet: § 536c I BGB, sonst Schadenersatzpflicht: § 536c II BGB
    • Bei Nichtanzeige und daraus erfolgter Nichtbehebung gleichzeitig keine Rechte nach § 536, 536a oder 543 II S.1
    • Beseitigungsrecht und Aufwendungsersatz nach § 536a II BGB

Rückabwicklung:

  • Mietsache herausgeben: § 546 I BGB
  • Ggf. rückstandsfreie Löschung von Softwarekopien im Beisein oder durch Nachweis ggü. dem Vermieter
  • Aber: Datenbestand muß weiter nutzbar bleiben, d.h. ggf. Recht auf eine Softwareversion zum Nutzen der Daten im „Nur-lesen-Modus“!

SPEZIELLE THEMEN BEI ASP

Zielstellung beim ASP

  • Bereitstellung SW auf Server zur Nutzung über Datennetze
  • Sonderrechte (und Lizenz) des Anbieters, Software im ASP-Modell zur Verf. zu stellen
  • Oft zusätzl. Angebot von System-Management, Datensicherung, Hotline, Kundensupport

Vorteile:

  • Grds. wie bei Miete / Leasing
  • Zusätzlich: meist auch noch Systempflege ausgelagert

Nachteile:

  • Geschäftskritische Daten werden extern verarbeitet
  • Abhängigkeit von einem Anbieter
  • Schwierigkeit bei Datenzugriff (insb. im Streitfall)

Besonderheiten von ASP

  • Rechtsnatur: Mietrecht
  • Bei Zusatzleistungen durch Anbieter (Pflege u.a.) typischerweise gemischter Vertrag
  • Da zumeist geschäftskritische Daten: oft Verpflichtung zu weitreichenden Pflichten hinsichtl. Wartung, Verfügbarkeit
  • Anbieter schuldet Erhalt der Software in vertragsgem. Zustand
  • Oft Probleme in Realität, da Updates bei gemeinsam genutzten Systemen für alle Kunden wirken
  • Nutzungsgebühr idR zeit- oder mengenabhängige Modelle
  • ASP ist urheberrechtlich eine eigene Nutzungsart (so genannte “öffentl. Wiedergabe”)

BERATUNGSLEISTUNGEN

Rechtliche Zuordnung

  • Zeitpunkt der Beratung relevant: vorvertraglich: in der Regel unentgeltlich (Akquise)
  • Abgr.: Beratervertrag ⇐/⇒ vorvertragl. Beratungs-/Aufklärungspflicht
  • Wiederum (theoretisch) Dienst oder Werkvertrag möglich

Problem

  • „Erfolg“ bei Beratung schwer nachweisbar
  • üblicherweise daher: Wertung als „Unterstützungsleitungen innerhalb bestimmten Zeitrahmens“
  • Zeitpunkt relevant: bei Aufnahme Vertragsverhandlungen entsteht Schuldverhältnis mit Folgen des § 241 II BGB

Folgen

  • Rücksicht auf Rechte, Rechtsgüter, Interessen des Anderen
  • Verletzung der Pflichten kann Schadensersatzpflicht begründen

Besonderheit im IT-Bereich

  • Anbieter hat üblicherweise erhebliches Mehr an Fachkenntnis:
  • Grds. gilt: jede Partei muß sich selbst informieren
  • Aufklärungs-/Beratungspflicht nur unter best. Voraussetzung
  • Aufklärungspflicht bzgl. Umstände, die nur Anbieter bekannt
  • Aufklärungspflicht nur bzgl. dieser Umstände, soweit Wichtigkeit für andere klar u. eindeutig erkennbar

Einzelheiten ausgestaltung durch viele Entscheidungen

  • Unterstützung bei Erarbeitung der Anforderungen an System
  • Verpflichtung zur Ermittlung der betrieblichen Bedürfnisse
  • Beratung über Geeignetheit der Software für bestimmten Zweck
  • Verpflichtung zum Vorschlag einer praktikablen Lösung
  • Verpflichtung zum Vorschlag von Organisations-Änderungen
  • Verpflichtung zur Beratung bei verschiedenen Versionen

Haftungsumfang

  • für falsche Auskünfte
  • für Nicht-Aufklärung von offensichtlichen Irrtümern
  • Auf Ersatz des Vertrauensschadens
  • Kein Anspruch auf Vertragsanpassung
  • kein Anspruch auf kostenfreie Beratung

GENERELLE MITWIRKUNGSPFLICHT DES KUNDEN

Grundsätzlich

  • Pflicht des Auftraggebers, die in seiner Sphäre liegenden Handlungen zur Erreichung des Vertragszweck zu leisten
  • Rechtsgrundlage: im Werkvertrag über § 642 BGB ist Vorliegen von Mitwirkungspflichten anerkannt
  • Jedoch im Gesetz keine Festlegung über Umfang und Art, daher Prüfung jedes Einzelfalls notwendig

Beispiele

  • Mitteilung der Aufgabenstellung
  • Mitarbeit an Projektplan-Erstellung
  • Erstellung detailliertes Pflichtenheft
  • Erstellung Unterlagen, soweit relevant für Erfüllung
  • Hinweis- und Überprüfungspflichten
  • Einhaltung von Besprechungsterminen / Kooperation
  • Stellen geeigneter Systemumgebung
  • Zur-Verfügung-Stellung von Personal / Bestandteilen für Tests, Handbuch o.ä.
  • Lieferung von Vor- und Testprogrammen
  • Eigenständiges Einspielen von Updates, Patches usw.
  • Verwendung bestimmter Formulare für Fehlermeldungen
  • Stellen von Testfällen
  • Durchführen der Abnahme

VORVERTRAGLICHE RISIKEN

Hintergrund

  • Viele IT-Projekte beginnen bereits vor schriftl. Vertrag
  • Probleme mögl., wenn:
    • Leistungsbeschreibung nicht vollständig
    • Vorbehalte bei einem Beteiligten
    • Kein Terminplan festgelegt

Probleme

  • „Vorfeldvereinbarungen“, die gar nicht mehr in richtigen Vertrag münden, weil Projekt terminlich/qualitativ schleppend durchgeführt
  • Folge also: vielfältige Konstellationen denkbar, die bereits im Vorfeld zu einer Haftung führen können
  • Daher bereits vorvertragliche Vereinbarungen empfehlenswert

Ziel

  • Auffangen von im Vorfeld eines Vertrags bestehenden Risiken
  • Aber: kein Anspruch auf Abschluß eines Vertrags
  • Risiko nicht erfolgenden Vertrags trägt jede Partei selbst
  • Keine Vergütung für im Vorfeld getätigte Aufwände, aber Schadensersatz, soweit:
    • eine Partei die Vertragsverhandlungen grundlos abbricht und ein zurechenbares
    • Erwecken von Vertrauen auf sicheren Abschluss stattfand

Besondere Form: LoI / MoU

  • LOI = Letter of intent = “Absichtserklärung”
  • MOU Memorandum of Understanding = “Vertrags-Hintergründe”
  • Äußerung eines „ernsthaften Willens zur Einigung“
  • Grds.: Keine rechtlich verbindliche Erklärung
  • Aber Gefahr, daß bereits ungewollt rechtsverbindliche Aussagen getätigt werden
  • Daher „Unverbindlichkeitsklausel“ („non-binding-clause“) empfohlen und Besondere Vorsicht bei Regelungen, die über reinen Inhalt hinausgehen (z.B. Vereinbarung eines b.a.W. geltenden Tagessatz)

Steigerung zu LoI / MoU: Vorvertrag

  • Rechtlich verbindlicher Vertrag
  • Zweck: Verpflichtung zu Zeitpunkt, zu dem noch rechtliche/tatsächliche Hemmnisse bestehen
  • Verpflichtungsziel: zum Abschluss späteren Hauptvertrages
  • Nur wenn besondere Umstände Bindungswille erkennen lassen
  • Allgemein anerkannt, obwohl im BGB nicht explizit geregelt
  • Bei Verweigerung: Klage auf Abgabe der WE möglich!

PFLICHTENHEFT - I

Inhalte

  • Fixierung von Art, Umfang, Güte der geschuldeten Leistungen und Gegenleistungen
  • Problemlos über 1.000 Seiten in komplexem IT-Projekt!
  • Wesentliches Element des IT-Vertrages: Im Streitfall Maßstab für Beurteilung der Leistung
  • Anhaltspunkt für Abgrenzung der pauschal und der gesondert zu vergütenden Teile
  • Hoher Detailgrad d. Beschreibung wichtig
  • Ausnahmsweise geringere Anforderungen z.B. bei Erwerb von Standardsoftware
  • Bei Individualsoftware absolut essentiell!

Zentralster Streitpunkt

  • Wird zwar sehr oft mit hohem Aufwand erstellt, ist in Realität trotzdem der Hauptstreit beinahe jedes IT-Projekts!
  • Im Zweifel wie immer: Auslegung Parteiwille
  • Leistung mittlerer Art und Güte = nach aktuellem Stand der Technik (= hier sind dann z.B. DIN-Normen relevant!)
  • Basis für Abnahme eines Werkvertrages

Viele verwendete Begrifflichkeiten

  • Soll-Ist-Analyse: Prüfung der Stärken / Schwächen der vorhandenen IT-Landschaft für Bedarf
  • Lastenheft: Beschreibung der Anforderungen an die Lösung
  • Anforderungsprofil: meist analog Lastenheft
  • Grobkonzept: Lösungsvorschlag für die gestellten Anforderungen
  • Feinkonzept: Lösungsvorschlag für die gestellten Anforderungen
  • Leistungsbeschreibung: detaillierte Beschreibung zu erbringender Lieferung / Leistung

PFLICHTENHEFT - II

Grundverständnis Pflichtenheft (juristische Sichtweise)

  • Technische Sicht: Orientierung am typisches Verständnis vom „Lastenheft“ z.B. in V-Modell XT:
    • Leitfaden zur Ausführung von Systemprojekten und Standard im Bereich der Bundesverwaltung
    • Aufstellung aller technischen und inhaltlichen Anforderungen ans System
  • Prinzip
    • Das vom Auftraggeber zu erstellende Lastenheft definiert die im vom Auftragnehmer zu erstellenden Pflichtenheft dokumentierten, umzusetzenden Anforderungen
    • Findet Ausdruck z.B. auch in DIN 66001 oder VDI 2519

Mitwirkungspflichten

  • Erstellungspflicht für „technisches Lastenheft“ liegt typischerweise in Sphäre des Kunden
  • Aber: weit reichende Mitwirkungspflicht des Anbieters, notfalls auch einseitig durch Anbieter zu erstellen
  • Kunde auf Notwendigkeit eines Pflichtenhefts hinzuweisen: üblicherweise größeres Fachwissen beim Anbieter
  • Erstellung „technischen Pflichtenhefts“ wird grundsätzlich in Sphäre des Anbieters gesehen, da Kunde übl. keine Sachkenntnis vom zu erstellenden Programm hat

Oft genau dies Streitpunkt

Insbesondere bei Standardsoftware dann Rückgriff: eschuldet wird Software „mittleren Standards“ d.h. gem. aktuellem Stand der Technik

  • will Anbieter natürlich genau so, da für ihn vorteilhaft
  • Kunde will natürlich in der Regel immer mehr ;-)

DOKUMENTATION

Begriff

  • nicht eindeutig definiert
  • DIN 69901: enthält auch Daten über
    • Gang des Projektes
    • vereinbarte Resultate
    • Mittel und Wege zur Lösung
  • Dokumentation HW/SW‘ versteht meist reines Nutzerhandbuch

Grundsätze

  • Bei SW und HW: Pflicht zur Lieferung Bedienungsanleitung
  • Hauptleistungspflicht, nicht nur Nebenpflicht!
  • Inhaltlich: Vollständig, Übersichtlich, Zutreffend
  • Beschreibung der Programmbedienung
  • Anhaltspunkt: DIN EN 62079 (Anforderungen an Bedienungsanleitungen)
  • Im Rahmen von Wartungsverträgen muß mit einem Update auch Dokumentation aktualisiert werden, z.B. soweit sich Bildschirmmasken ändern

BEISPIELE

Beispielfall A

Hersteller A erstellt Software, die auf spezieller, ebenfalls von ihm gelieferter Hardware läuft. Als Dokumentation liefert er eine in englisch gehaltene Online-Hilfe mit - ausreichend?

Lösung Beispielfall A

Soweit Adressatenkreis deutsch, dann auch Pflicht einer deutschsprachigen Dokumentation

Beispielfall B

Kunde B möchte nicht nur auf die Online-Hilfe zurückgreifen, da diese nichts über Hardware enthält. Hat er Anspruch auf ein gesondertes Benutzerhandbuch?

Lösung Beispielfall B

Soweit Kunde B die Software selbständig betreiben möchte und dafür hardware-spezifische Themen relevant sind, kann er auch einen Anspruch auf eine gesonderte Hardware-Doku erheben

Beispielfall C

B ist der englischen Sprache nicht ausreichend mächtig. Hat er Anspruch auf ein in deutscher Sprache gedrucktes Handbuch?

Lösung Beispielfall C

Hinsichtlich Sprache siehe oben … eine zusätzliche, gedruckte Fassung wird aktuell noch von einigen Gerichten als notwendig erkannt – diese Anforderung wird zunehmend kritisiert (insbesondere bei umfangreicher Branchensoftware mit mehreren 1.000 Seiten Gesamt-Handbuch-Umfang praktisch nicht mehr handhabbar)

Beispielfall D

Wenn B ein Rechenzentrum hätte, in dem die Software betrieben wird, ändert dies die Sachlage?

Lösung Beispielfall D

Für SW, die ausschliesslich von Fachleuten in RZ benutzt wird, ist englischsprachige Doku und auch reine Online-Hilfe ausreichend, weil hier Online-Hilfesysteme, sowie Verwendung englischer Fachbegriffe und Sprache üblich ist

QUELLCODE

Allgemeines

  • In Literatur als „Herz der Software“ bezeichnet
  • Typischerweise widersprechende Interessen:
    • Hersteller hat Interesse, Quellcode geheim zu halten
    • Kunde will Quellcode zur Erweiterung/Fehlerbehebung erhalten

Herausgabepflicht

  • Bei Standard-SW: keine Pflicht zur Herausgabe des Quellcode
  • Bei Individual-SW: Pflicht zur Herausgabe, wenn keine gesonderte Wartung / Pflege durch Hersteller vereinbart

Besonderes Verfahren: Quellcode-Hinterlegung = „Escrow“

  • Minderung des Risikos z.B. von Insolvenz / Geschäftsaufgabe
  • Eigene Fehlerbehebung des Kunden im Fall gescheiterter Behebungsversuche des Herstellers
  • Sicherung SW-abhängige, unternehmenskrit. Prozesse
  • Schutz Urheber/Schutz vor Entfernen Urheber-Hinweis
  • Steigerung der Angebotsqualität
  • Erhöhung des Kundenvertrauens

Problem

  • selbst bei Zugriff auf Quellcode kann Störungsbeseitigung trotzdem Monate dauern
  • Bessere Lösung: Einstellung eines der Programmierer des ursprünglichen Herstellers

Ausgestaltung Code-Hinterlegung

  • Hinterlegungsvertrag
  • Geschäftsbesorgungsvertrag, § 675 BGB
  • Typischer Fall = dreiseitiger Vertrag: Software-Hersteller ⇐> Kunde des Software-Herstellers ⇐> Software-hinterlegende Stelle
  • häufiger werdender Fall = zweiseitiger Vertrag: Standard-Vertrag SW-Hersteller mit Escrow-Stelle für alle künftigen Fälle
  • Sehr seltener Fall = Hinterlegung beim Auftraggeber
  • Potentielle Hinterlegungsstellen
    • Notare
    • Rechtsanwälte
    • Kommerzielle Hinterlegungsstellen

Ausgestaltunng der Code-Hinterlegung

  • Empfehlung: profess. Hinterlegungsstelle
  • Sachgemäße physikalische Lagerung, z.B. brandgeschützte, klimatisierte Räumlichkeiten
  • Verifikation des Materials von einfacher Checksummen-Prüfung bis hin zu Vollverifikation
  • Ggf. auch Einarbeitung von Aktualisierungen Dokumentation und Kontaktdaten Programmierer (soweit datenschutzrechtlich zulässig)
  • Klare Fassung der Herausgabegründe: Verhinderung vorschnellen Zugriffs des Kunden im Streitfall und trotzdem Ermöglichung sicheren Zugriffs des Kunden im Ernstfall

GEHEIMHALTUNGSVEREINBARUNGEN - NDA

Hintergrund

  • Zunehmend bereits in vorvertraglichen Vereinbarungen zum Schutz von KnowHow, Betriebs-, Geschäftsgeheimnissen, unternehmenskritischer Daten, usw
  • Bereits in Workshops, Machbarkeitsstudien o.ä. erhält Gegenseite Informationen, Kundendaten, usw.
  • Gesetzl. Vorschriften zum Geheimnisschutz (§§ 17ff UWG/StGB) oft nicht ausreichend

Verwendungsform

  • Geheimhaltungs-, Nichtverwendungs- und Datenschutzabreden gelten üblicherweise über Projektende hinaus
  • Oft Bezugnahme auf im Vorfeld abgeschlossene Vereinbarung
  • Typischerweise beidseitiges Interesse: Anbieter gibt Informationen über seine Software preis, Kunde gibt Informationen über seine Strategie / Abläufe preis

Ausgestaltung

  • Üblicherweise wird Verstoß mit Vertragsstrafe bedroht
  • Konkreter Schaden selten bemeßbar, aber bei Vertrags-vereinbarung entbehrlich: Verstoß allein ist ausreichend

Beispiele Umfang

  • Beschreibung der geheim zu haltenden Informationen
    • formell: „…alle als „geheim“ gekennzeichnete Dokumente…
    • mit Passwortschutz versehene Datenträger…“
    • inhaltlich: „…sämtliche zwischen den Beteiligten über das System XYZ ausgetauschten Informationen mit Ausnahme von…“
  • Ggf. Beschreibung der nicht geheim zu haltenden Informationen

Dauer der Geheimhaltungspflicht

  • Grundsätzlich bis zur Beendigung der Vereinbarung, üblicherweise auch über Vertragsende hinaus
  • Auch oft: Pflicht zur sicheren Aufbewahrung und Schutz vor dem Zugriff Dritter auf die Daten
  • Pflicht zur Rückgabe bzw. Löschung / Vernichtung incl. Nachweis
  • Klare Formulierung der durch einen Verstoß ausgelösten Sanktionen

SERVICE LEVEL AGREEMENTS - SLA - I

Bestandteil vieler Verträge

  • Wartungs- und Pflegeverträge
  • Verträge zum IT-Outsourcing
  • ASP-Verträge (Application Service Providing)
  • Entspricht de facto deut. Begriff „Leistungsbeschreibung“

Funktion

  • Beschreibung von Zeitpunkt, Menge, Ausmaß und Qualität geschuldeter Leistung,
  • ggf. Folgen der Nichteinhaltung

Form

  • Üblicherweise als Vertragsanhang
  • Definition zur qualität, Ermöglichen Überwachung/Überprüfung
  • Massstab für Bewertung der Qualitätserreichung
  • Transparenz der Preiskalkulation
  • Sanktionen für Nichteinhaltung der Qualitätsstandards
  • Marketinginstrument, da SLA versch. Anbieter vergleichbar

Regelung von Rahmenparameter

  • Festlegung der maximalen Anzahl gleichzeitiger Nutzer
  • Definition eines Maximalzeitraumes des Ausfalls
  • Verfügbarkeitsklauseln per AGB sehr kritisch zu betrachten (immer vom Einzelfall = System abhängig)
  • Geplante Wartungsfenster (so genannte „scheduled downtime“), z.B. Sontags zw. 02:00 und 04:00 Uhr
  • Ungeplante Wartungsfenster z.B. Ausfallfenster von max. 2 Stunden in Zeit zw. 22:00 und 06:00 Uhr
  • Vorankündigung ungeplanter Wartungsfenster z.B. nicht unter 36 Stunden

Regelung Key-Service-Level

  • Für Auftraggeber von überragender Bedeutung
  • Verfügbarkeiten der IT-Systeme, nicht nur unternehmenskritische
  • Bezugspunkt der Verfügbarkeiten in technischer Hinsicht = Definition der relevanten Systeme
  • Möglichkeit der Aufteilung: im Ganzen und differenzierte Verfügbarkeit von Einzelsystemen
  • Üblich: Angabe Prozentsatz mit Bezug zu Zeitraum
    • Bezugszeitraum sollte nicht zu lang bemessen sein, da sonst unrealistische Werte
    • Verfügbark. 99,0% pro Jahr/Monat/Tag kommen zwar alle in Summe auf Gesamt-Ausfallzeit von ca. 3,7 Tage/Jahr
    • Einheit Jahr/Monat/Tag hat jedoch unterschiedliche Auswirkung: 3,7 Tage am Stück können einen Kunden in seinem Betrieb schwer treffen
    • Relevant daher immer: Umstände Einzelfall / Einsatzzweck System
  • Regelung Antwortzeitverhalten: maximaler Zeitraum, in dem ein IT-System auf eine Informationseingabe ein Ergebnis liefert
  • Bewertungssystem notfalls wieder „Stand der Technik“
  • RegeLung Reaktions- / behebungszeiten
  • Üblicherweise Aufteilung der Störungen in mehreren Stufen
    • Zeitraum der ersten Reaktion durch Aufnahme in Ticketsystem
    • Maximale Zeit bis zur Fehlerbehebung: Mean Time to Repair (MTTR): Durchschnittswert zur Behebung der Störung nach entsprechender Meldung
    • Mean Time between Failures (MTBF): Durchschnittswert des zulässigen, zwischen Störungen liegenden Zeitraumes
    • Auch hier immer Bezugszeitraum anzugeben

Servicezeiten des Anbieters

  • Rund um die Uhr = 24/7
  • Nur zu üblichen Geschäftszeiten
  • Innerhalb weniger Stunden pro Tag
  • Nur per Hotline oder Help Desk
  • Per Remote-Wartungszugriff oder vor Ort beim Kunde
  • In der Regel gestufte Wartungspakete: Bronze – Silber – Gold (Bezeichnungen teils wechselnd und sehr kreativ ;-)
  • Wartungspakete idR. auch unterschiedlich vergütet

SERVICE LEVEL AGREEMENTS - SLA - II

Begleitende Festlegungen

  • Manipulationssicheres Monitoring und Reporting
  • Laufende Überwachung der Einhaltung
  • Umfassendes Service-Level-Management:
    • Festlegungen zu regelmäßig zu liefernden Reports
    • Vorgaben zu Messmethoden, Messintervallen, Messzeiträume
    • Vorgaben zu den zu verwendenden (Software-) Tools
    • Abdeckung der gesamten Leistungsbandbreite der Service Levels
    • Unterschiedliche Messzeitpunkte (Schwerlast, Normallast usw.)
    • Generierung aussagekräftiger Kennzahlen
    • Festlegung von gesonderten Vergütungen für Messungen

Mitwirkungspflichten des Kunden

  • Meist unabdingbare Voraussetzung für Einhaltung Servicelevel
  • Einrichtung eines Remote-Zugriffs
  • Zugang zu Räumlichkeiten
  • Bereitstellung technischer Vorrichtungen
  • Benennung eines qualifizierten Ansprechpartners
  • Unverzügliche Information über aufgetretene Störungen
  • Regelungen, wer eine Störungsmeldung einleiten darf
  • Regelungen der Mindestvoraussetzungen einer Störungsmeldung
  • Regelungen der Form einer Störungsmeldung

Sanktionen und Rechtsfolgen

  • Vertragsstrafenregelungen
  • Pauschalierter Schadensersatz und Pauschalierte Minderung
  • Mehrstufige Sanktionssysteme / Kombination Sanktionen
  • Verschuldensunabhängige Minderungspauschale
  • Bonusregelungen für überobligatorische Leistungen
  • Regelungen zu außerordentlichen Kündigungsrechten
  • Anhalten zur Qualitätssicherung: Analyse von Nichteinhaltungsgründen und künftigen Sicherstellung

Abschluß-Beispiel

Entscheidung des BGH zur Wirksamkeit von Verfügbarkeitsauschlüssen per AGB: eine Bank verwendete ein Formular, in dem es u.a. heißt: „…aus technischen oder sonstigen Gründen sind zeitweilige Beschränkungen und Unterbrechungen des Zugangs möglich. Zeitweilige Beschränkungen und Unterbrechungen beruhen auf höherer Gewalt, Änderungen oder Verbesserungen an den technischen Anlagen oder auf sonstigen Maßnahmen, z.B. Wartungs- und Instandsetzungsarbeiten, oder auf sonstigen Vorkommnissen, z.B. Überlastung der Telekommunikations-Netze…“

Lösung

Nicht zulässig: Bank will sich sanktionslos stellen, selbst wenn Mangel auf Eigenverschulden beruht - Dies stellt einen unzulässigen, versteckten Haftungsausschluss dar (= AGB-Verstoß)

GENERAL- / SUBUNTERNEHMER

Konstellationen

  • Typisch in komplexen IT-Projekten
  • z.B. aufgrund fehlender Fachkunde in Teilbereichen
  • z.B. aufgrund Auslastung des eigenen Personals

Kein eigener Vertragstyp

  • typische Mehrpersonenkonstellation:
    • Hauptauftraggeber verpflichtet Generalunternehmer
    • Generalunternehmer beauftragt Subunternehmer
  • Subunternehmer hat keine vertragliche Beziehung zu Hauptauftraggeber und umgekehrt
  • Subunternehmer ist Erfüllungsgehilfe des Generalunternehmers: § 278 BGB

Vorteile

  • Hauptauftraggeber hat nach wie vor nur einen Anspruchsgegner
  • Oft Verlängerung von Mängelhaftungsfristen
  • Oft Zahlung an Subunternehmer durch Generalunternehmer erst nach Zahlung durch Hauptauftraggeber an Generalunternehmer

Risiken

  • Generalunternehmer trägt Risiko des Gesamt-Projekterfolgs
  • Generalunternehmer von ordentl. / fristgerechter Zuarbeit des Subunternehmers abhängig
  • Erbringt Subunternehmer Leistung nicht/schlecht/verzögert, ist Gesamtprojekt gefährdet
  • und natürlich: Illegale Arbeitnehmerüberlassung / Scheinselbständigkeit = kein “Einbinden” in den eigenen Betrieb

Besonderheiten

  • Zwei Verhandlungsrichtungen des Generalunternehmers:
    • Generalunternehmer trägt Risiko von Leistungszusagen an Hauptauftraggeber
    • gleichzeitig Sicherstellung der Leistungsfähigkeit der Subunternehmer
  • Sonderregelungen
    • Verpflichtung des Generalunternehmers zur sorgf. Auswahl Subunternehmer, ggf Sub aus vorbenannten Firmen auszuwählen auf besondere Fachkenntnis zu achten
    • Generalunternehmer hat für Subunternehmer wie für eigenes Personal einzustehen
    • Einbindung von Subunternehmern ggf. von Zustimmung Hauptauftraggebers abhängig
    • Klärung, ob ggf. weitere Vergabe von Unteraufträgen durch Subunternehmer zulässig

OUTSOURCING

Ziele

  • Einsparung Kosten/Ressourcen
  • Organisationsveränderungen: Freistellen Ressourcen für andere Bereiche - Entlassen von Mitarbeitern
  • Auslagern von IT-Themen auf spezialisiertere Partner

Risiken

  • Abhängigkeit ordnungsgemäßer Leistung durch externe Dritte
  • Schutz geheimhaltungsbedürftiger Informationen
  • Abfluss internen KnowHows an Outsourcing-Dienstleister
  • Auswirkung: Datenschutz, Arbeitsrecht, Kartellrecht, GdPDU, GoBS, AO, AktG, GmbHg, HGB
  • Unterscheidung ausgelagerter Bereiche
    • „Full Outsourcing“ der gesamten IT
    • „Partial Outsourcing“ oder „Outtasking“ einzelner Proesse
    • „Business Process Outsourcing“ einzelner betrieblicher Abläufe

Rechtliche Wertung: typischerweise gemischter Vertrag

  • Rahmenvereinbarungen zu Transition und Betrieb
  • Überleitung von Betriebsmitteln und Nutzungsrechten
  • Regelung der einzelnen zu erbringenden Leistungen (SLA‘s)
  • Regelmäßige Kontrollen der Leistungsstandards
  • Sicherheits- und Notfallkonzept
  • Umgang mit Störfällen, Viren, Hacker-Angriffe
  • Eskalationsabläufe, Überprüfungen
  • Änderungsmanagement: Anpassung an behördliche, gesetzliche, technische Gegebenheiten, Customizing usw
  • Vereinbarung für Fall Anbieterwechsel/ In-/Backsourcing

Arbeitsrechtliche Relevanz

  • § 613 BGB: soweit Teile des Betriebes übergehen (entscheidend, ob wirtschaftliche Einheit bestehen bleibt)
    • Geht Betriebsteil über, tritt neuer Inhaber in Rechte und Pflichten ein und bisheriger Inhaber haftet neben dem neuen Inhaber
    • Informationspflicht ggü. den betroffenen Arbeitnehmern über: Zeitpunkt / Grund / rechtl., wirtschaftl. und soziale Folgen

Datenschutzrechtliche Relevanz, z.B. Auslagerung EU-Ausland / Drittländer

  • hierzu im Detail später bei „Datenschutzrecht“

Weitere wichtige Themen

  • Zutrittskontrollen: kein Zutritt für Unbefugte
  • Zugangskontrollen: keine Nutzung durch Unbefugte
  • Zugriffskontrollen: nur Zugriff auf berechtigte Daten
  • Weitergabekontrollen: kein unbefugter Zugriff während Transport
  • Eingabekontrollen: Kontrolle, wer wann welche Daten ändert
  • Auftragskontrollen: Verarbeitung nur innerhalb des Auftrags
  • Verfügbarkeitskontrollen: Sicherung gegen Zerstörung oder Verlust
  • Getrennte Verarbeitung: falls Daten zu untersch. Zweck erhoben
  • Datenverarbeitung nur im Rahmen der Weisung des Kunden (Auftragsdatenverarbeitungs-Vertrag = ADV notwendig)

CLOUD-VERTRAG

Typengemischter Vertrag

  • Storage-Bereitstellung in der Regel Miete (§ 535 BGB)
  • Implementierung in der Regel Werk (§ 631 BGB)
  • Rechnerleistung/Support in der Regel Dienst (§ 611 BGB)

Weitere rechtlich relevante Bereiche

  • Lizenzrechtliche Besonderheiten aufgrund weltweiter Zugriffsmöglichkeiten beachten
  • SLA’s mit Hauptaugenmerk auf sicherheitsrelevante Themen
  • Deutsches Datenschutzrecht gilt für alle personenbezogenen Daten (§ 3 BDSG)
  • Ausgenommen von BDSG sind nur anonymisierte Daten
  • Pseudonymisierte Daten =/= anonymisierte Daten! D.h.: fallen ebenfalls unter Schutz BDSG

Problembereiche beim Cloud-Computing

  • Vertraulichkeit
    • Gewährleistung Vertraulichkeit Daten, Zugriffsmögl. Dritter
    • verschlüsselte Verbindung, Inhalte ggf. unverschlüsselt
    • verschlüsselte Datenablage ⇒ Key ggf. bei Cloud-Anbieter
    • Integrität der Daten ⇒ Manipulationsmöglichkeiten Dritter
  • Rechtsschutz
    • Auskunftsmöglichkeiten ggf. in Drittland nicht durchsetzbar
    • Kenntnisnahme von ggf. bereits erfolgtem Zugriff erschwert/unmögl.
    • Rechtsschutzmögl. ggf. in Drittland niedriger oder nicht gegeben
  • Unkontrollierte und unbekannte Weitergabemöglichkeit an Drittstaaten / Geheimdienste
  • Zugriffsmöglichkeiten aufgrund vollkommen unbestimmter (Rechts)Begriffe
  • Zugangsbeschränkungen auch für private Daten z.B. aufgrund anderer Moralvorstellungen
  • Unvermittelte Änderungen in Moral-/Wertvorstellungen verändern Lage/Auslegung/Zugriff

Beispiele für bestehende Zugriffskompetenzen staatlicher Stellen

  • Herausgabepflicht für Kryptoschlüssel: Großbritannien
  • Vollständiges Mitlesen ermöglicht: Schweden

§ 11 BDSG

  • Vertrag zur Auftragsdatenverarbeitung zwingend notwendig
  • Ort der Datenspeicherung / Datenverarbeitung
  • Einzelheiten zu eingebundenen Subunternehmern / eingesetzter Technik
  • Prüfungsmöglichkeit
  • Besonderheit bei Cloud-Anbietern ausserhalb EU
    • zusätzliche Anforderungen an Angemessenes (=vergleichbares) Datenschutzniveau
    • Keine Speicherung “besonderer” personenbez. Daten (§3 Nr. 9 BDSG): Herkunft, Rasse, Religion, Einkünfte, Politische Meinungen, Gesundheit, Sexualleben

WEITERE VERTRIEBSMODELLE

OEM-Vertrag

  • Original Equipment Manufacturer ⇒ Hersteller der Originalware
  • Vertrieb und Vermarktung von Hard- und Software gemeinsam
  • Ohne Nennung des Herstellers unter eigener Marke

VAR-Vertrag

  • Value Added Resale ⇒ Sonderform des Softwarevertriebs
  • Hersteller überläßt Software zum Weitervertrieb incl. Genehmigung zum Hinzufügen eigener Komponenten des Händlers
  • Kreation neuer Produkte steht im Vordergrund

FUE-VERTRAG

Forschungs- und Entwicklungsverträge (FuE)

  • Entwicklung neuer Software
  • Entwicklung leistungsfähigerer Hardware

Vorteile

  • Positive Kosteneffekte, da Doppelausgaben vermieden werden
  • Unterstützung durch meist öffentliche Mittel
  • KnowHow-Austausch, Erfahrungs- und Ideen-Austausch
  • Optimale Auslastung gemeinsamer Betriebsmittel / Ressourcen

Nachteile

  • Ungewollter Abfluß von KnowHow oder geheimen Informationen
  • Wechsel von Mitarbeitern zum FuE-Partner
  • Verlangsamung Entscheidungsprozesse durch mehrere Partner

Arten des FuE-Vertrags

  • Meist zwischen Hochschulen / Forschungseinrichtungen und Firmen
  • Öffentliche Förderung national oder auf EU-Ebene
  • Auftrags-FuE (Vertikal): Tätigkeit mit best. Zielsetzung, Auftragg. erhält
  • Rechte an Arbeitsergebnis
  • FuE-Kooperation (Horizontal): best. Entwicklungsziel, gemeins.
  • Nutzung/Verwertung aller Ergebnisse

Rechtsformen

  • Konkrete Aufgabenstellung nach BGB-Vertragstyp zu bewerten
  • Bei FuE-Kooperationen meist zusätzliche gesellschaftsr. Verbindung wie Joint-Venture, BGB-Gesellschaft, o.ä.
  • Hauptaugenmerk auf konkreter und detaillierter Ausgestaltung der Verwertungs- und Nutzungsrechte an Arbeitsergebnissen

AGB IN IT-VERTRÄGEN

Regelfall bei Kauf, Wartung, Pflege

  • Vereinfachung/Standardisierung von Geschäftsabläufen, Wenn HW-/SW-verkauf/Wartung/Pflege Massengeschäft darstellt
  • Verwendung in (reinen) IT-Projekt-Verträgen selten

Ausnahmen:

  • Verwendung Standards bei regelm. Projekten gleichen Inhalts
  • Verwendung von Rahmenverträgen
  • Wiederkehrende Geschäftsbeziehungen mit gleichen Partnern

Bedingungen

  • Klare und deutliche Formulierung: § 307 I 2 BGB = wirtschaftliche Nachteile für den Einzelfall klar erkennbar
  • Massstab: durchschnittlich verständiger Kunde
  • Keine überraschenden Klauseln gem. § 305c BGB

Haftungsausschlüsse

  • Aus Anbietersicht wünschenswert, die Risiken eines komplexen IT-Projekts dem Kunden aufzuerlegen
  • Aus Kundensicht wünschenswert, um Anbieter voll in Anspruch und ggf. Haftung nehmen zu können und eigene Haftung (z.B. für Mitwirkungspflichten) ebenfalls einzuschränken
  • Rechtsfolgen:
    • wie bereits dargestellt: geltungserhaltende Reduktion: Vertrag bleibt im Übrigen wirksam
    • An Stelle unwirksametreten gesetzliche Regelungen: § 306 II BGB

EVB-IT ALS AGB

Definition EVB-IT

  • Allgemeine Einkaufsbedingungen der öffentlichen Hand = Verwaltung = Bund / Länder
  • Schaffung der „Besonderen Vertragsbedingungen für die Beschaffung von DV-Leistungen“ (BVB) in den 1970ern
  • Ablösung im Laufe der Zeit durch die „Ergänzenden Vertragsbedingungen für die Beschaffung von IT-Leistungen (EVB-IT)“
  • EVB-IT entwickelt unter Federführung des Bundesministeriums des Inneren
  • BVB weiterhin geltend, soweit noch keine Regelungen in EVB-IT getroffen / umgesetzt

Aktuell jeweils eigene EVB-IT existent für

  • EVB-IT-Kauf
  • EVB-IT-System
  • EVB-IT-Dienstleistung
  • EVB-IT-Überlassung (Typ A und B)
  • EVB-IT-Instandhaltung
  • EVB-IT-Pflege

TYPISCHER AUFBAU / INHALTE EINES IT-VERTRAGES

  • Präambel
  • Vertragsgegenstand
  • Leistungs- / Mitwirkungspflichten
  • Projektorganisation / Projektmanagement
  • Termine / Meilensteine
  • Änderungsanforderungen (so genanntes Change-Management)
  • Einschaltung Subunternehmer / Dritter / Regelungen zu AÜ
  • Übergabe / Vertragsgemässheit
  • Rechteeinräumung / Rechtsmängel
  • Vergütung / Zahlungsmodalitäten
  • Regelungen zu Mängel / Störungen / Haftung
  • Geheimhaltung / Datenschutz
  • Vertragsdauer / (ausserordentliche) Vertragsbeendigung / Höhere Gewalt
  • Sicherungsleistungen
  • Schlussbestimmungen

Quizfragen IT

Basierend auf den bereitgestellten Quellen zum deutschen IT-Recht, insbesondere zu verschiedenen Arten von IT-Verträgen, wurden die folgenden Quizfragen mit praxisnahen Beispielen erstellt:

Beispiel 1: Ein Unternehmen kauft 100 neue Computer. Nach der Lieferung stellt sich heraus, dass die Grafikkarten nicht den vertraglich vereinbarten Spezifikationen entsprechen. Frage: Welche Rechte hat das Unternehmen in diesem Fall? Nennen Sie mindestens zwei Möglichkeiten.

Beispiel 2: Ein Unternehmen bestellt einen Server inklusive Installation. Der Techniker des Verkäufers installiert den Server jedoch fehlerhaft, so dass dieser nicht betriebsbereit ist. Frage: Liegt in diesem Fall ein Sachmangel vor? Begründen Sie Ihre Antwort.

Beispiel 3: Ein Unternehmen erwirbt eine Standardsoftware zur Buchhaltung. Nach der Installation stellt sich heraus, dass die Software nicht mit dem Betriebssystem des Unternehmens kompatibel ist. Der Verkäufer hatte das Unternehmen im Vorfeld nicht über diese Inkompatibilität aufgeklärt. Frage: Hat das Unternehmen in diesem Fall Ansprüche gegen den Verkäufer? Begründen Sie Ihre Antwort.

Beispiel 4: Ein Unternehmen erwirbt eine Software, die durch einen Dongle geschützt ist. Der Dongle funktioniert jedoch nicht, so dass die Software nicht genutzt werden kann. Frage: Liegt in diesem Fall ein Mangel der Software vor? Begründen Sie Ihre Antwort.

Beispiel 5: Ein Unternehmen beauftragt einen Softwareentwickler mit der Erstellung einer individuellen Softwarelösung. Nach der Abnahme stellt sich heraus, dass die Software mehrere Fehler enthält, die eine reibungslose Nutzung unmöglich machen. Frage: Welche Möglichkeiten hat das Unternehmen, die Mängel der Software beheben zu lassen?

Beispiel 6: Im Laufe der Entwicklung einer Individualsoftware ändern sich die Anforderungen des Unternehmens. Der Softwareentwickler weigert sich, die Software entsprechend anzupassen, da dies nicht im ursprünglichen Pflichtenheft vorgesehen war. Frage: Ist der Softwareentwickler verpflichtet, die Software anzupassen? Begründen Sie Ihre Antwort.

Beispiel 7: Ein Unternehmen hat einen Wartungsvertrag für eine Standardsoftware abgeschlossen. Im Rahmen eines Updates liefert der Hersteller eine neue Version der Software, die jedoch zu erheblichen Performance-Einbrüchen im Unternehmen führt. Frage: Ist das Unternehmen verpflichtet, das Update zu installieren?

Beispiel 8: Ein Unternehmen hat einen Wartungsvertrag für eine Hardwarekomponente abgeschlossen. Die Komponente fällt während der vereinbarten Wartungszeit aus. Der Hersteller benötigt jedoch mehrere Tage, um den Fehler zu beheben. Frage: Welche Ansprüche hat das Unternehmen in diesem Fall?

Beispiel 9: Ein Unternehmen möchte seine gesamte IT an einen externen Dienstleister auslagern (Outsourcing). Welche rechtlichen Aspekte sind dabei zu beachten? Nennen Sie mindestens drei.

Beispiel 10: Ein Unternehmen möchte Software aus der Cloud nutzen. Welche datenschutzrechtlichen Besonderheiten sind dabei zu beachten?

Beispiel 11: Ein Softwareentwickler hat den Quellcode einer Software gestohlen und unter seinem eigenen Namen veröffentlicht. Frage: Welche Straftat hat der Softwareentwickler begangen?

Beispiel 12: Ein Mitarbeiter eines Unternehmens verbreitet im Intranet des Unternehmens beleidigende Äußerungen über einen Kollegen. Frage: Welche rechtlichen Konsequenzen drohen dem Mitarbeiter?

Hinweis: Die Antworten auf die Quizfragen basieren auf den bereitgestellten Quellen und stellen eine rechtliche Bewertung dar. Im Einzelfall können jedoch abweichende Ergebnisse möglich sein. Es wird daher empfohlen, sich in konkreten Fällen anwaltlich beraten zu lassen.

Graph View

Backlinks