29.04.2015 – Wer rechtliche Risiken aus dem Einsatz von Open Source Software einschätzen will, muss verstehen, wie sich die Positionen der Marktteilnehmer in den letzten 20 Jahren mehrfach gewandelt haben. Die Einstellungen der vergangenen Ära sind genauso überholt wie die Prognosen für die Zukunft. Mit dem bloßen Blick auf alte Gerichtsurteile übersieht man, dass der Compliance Druck nicht von den Rechteinhabern, sondern von den OEMs kommt.
Die Ära der Ahnungslosigkeit und Gleichgültig (1992 – 2004)
Als mit der GPL 2.0 erstmals das Prinzip des Copyleft Effektes aufkam und Linux unter dieser Lizenz vertrieben wurde, war beides noch ein Tummelfeld für Freaks. Im Büro benutzte man Windows 3.1 und das Unternehmensrechenzentrum betrieb Großrechner auf Unix Basis von IBM. Linuxanwender waren meistens auch gleichzeitig Softwareentwickler und typischerweise Langzeitstudenten der Informatik. Über License Compliance musste man sich keine Gedanken machen. Open Source Software war in erster Linie kostenlos und unverbindlich.
Ära der Prinzipien (2004 – 2011)
Open Source Software und ihre Entwickler wurden erwachsen und kommerziell. Billige klein Geräte wie Router, Netzwerkspeicher und Navigationsgeräte setzten massiv Open Source Software ein. Viele beachteten nicht einmal die grundlegenden Lizenzverpflichtungen wie etwa die Bereitstellung des Lizenztextes und des Original Source Codes. Erste Organisationen und Entwickler nahmen die Rechtsverfolgung auf. Ihnen ging es nicht darum Geld zu verdienen, sondern den sozialen Gedanken der Open Source Bewegung durchzusetzen.
Harald Welte reklamierte in dieser Zeit über 100 erfolgreich abgeschlossene Fälle. Die ersten GPL Gerichtsentscheidungen ergingen zugunsten der Rechteinhaber und stellten klar, dass GPL wirksam und durchsetzbar ist.
Die wenigen gerichtlichen Entscheidungen wurden als Mahnmal hochgehalten, um Compliance orientierten Managern den Weg zu weisen. Tatsächlich war das Verfolgungsrisiko, vor allem aber das Schadenspotenzial bei der Verletzung von Open Source Bedingungen niedrig. Patentverletzungen schienen wesentlich gefährlicher und ein Open Source Compliance Prozess im Unternehmen war ein belächeltes Steckenpferd. Nur wenige Unternehmen waren damals in der Lage, umfassend darüber Auskunft zu erteilen, welche Open Source in ihren Produkten zum Einsatz kam. Die Einhaltung von Open Source Bedingungen wurde erst dort relevant, wo prinzipiengeleitete Juristen das Sagen hatten: z. B. bei einer Due Diligence Prüfung im Rahmen eines Unternehmenskaufes.
Automobilhersteller verließen sich auf die naive Parole, dass Open Source in Einkaufsbedingungen als verboten klassifiziert wurde und somit auch nicht im Einsatz sein kann. Tatsächlich weiß natürlich jeder, dass auch damals schon fast jedes Navigationsgerät auf Linux oder QNX basierte.
Zum Ende dieser Ära hatten sich die Softwarezulieferer in die Fraktion der Langschläfer und Frühaufsteher aufgeteilt. Während die Langschläfer darauf vertrauten, dass Open Source Compliance ein theoretisches Risiko bleiben wird, haben die Frühaufsteher vorsorglich begonnen, ihre Source Codes zu untersuchen und ihre Zulieferer zu disziplinieren. Sie waren gerüstet, für das was mit dem nächsten Zeitalter begann.
Zeitalter der Kundenforderung (2011 – heute)
Während noch viele Softwarehersteller darauf warteten, dass sie beim Hacking for Compliance Workshop übersehen werden würden, kamen die gefürchteten Fragen plötzlich von unverhoffter Seite: vom Kunden.
Großunternehmen hatten zwischenzeitlich ihre Hausaufgaben in Sachen Open Source Compliance zumindest angefangen. Dabei waren sie früh zu der Erkenntnis gelangt, dass ein Software Assessment bei den Zulieferern anfangen müsse und das Aufstellen von Forderungen gar keine eigenen Kosten verursacht, weil es ohnehin von den weiten Vertragsklauseln umfasst war. Im Vertrag fand sich irgendwo die Klausel, dass Software frei von Rechten Dritter sein müsse, was für Open Source Software nun mal nicht zutrifft.
Kunden konnten mit Leichtigkeit nachweisen, dass die Lizenzbedingungen nicht vollständig eingehalten waren und forderten rechtsmangelfreie Software. Wer jetzt zum ersten Mal einen Software Scan bei Black Duck oder Palamida in Auftrag gab, war vermutlich erschüttert von der langen Trefferliste. Die Open Source Software Scanner beschränken sich immerhin noch darauf, bei Paketen nur die oberste Ebene anzugeben. Die Ergebnisse ließen sich jedoch meistens nicht kurzfristig beheben und erforderten substanzielle Zugeständnisse, um den Kunden noch zufriedenzustellen.
Software Compliance begann beim Einkauf. Die Hersteller formulierten ihre Forderungen in Lastenheften und Einkaufsbedingungen. Der bloße Hinweis darauf, Software müsse frei von Rechten Dritter sein, reichte den OEMs nicht mehr aus, schließlich hilft diese Garantie nicht, wenn ein Softwaretroll mit einer einstweiligen Verfügung die Auslieferung einer ganzen Baureihe blockieren könnte.
Die First Tiers reagierten schnell und gaben die Anforderungen eins zu eins an ihre Zulieferer weiter.
Auf der gerichtlichen Front war die neue Qualität des Compliance Drucks nicht spürbar. Meinungsverschiedenheiten zwischen OEMs und Zulieferern werden demnächst in öffentlichen Prozessen ausgetragen.
Die Rechteinhaber waren aber nicht untätig geblieben. Mit den meisten Grundsatzentscheidungen schossen sie jedoch über das Ziel hinaus, wie etwa beim Landgericht Berlin, wo jede Routerfirmware zum urheberrechtlichen Sammelwerk erklärt wird, welches keine proprietären Lizenzen mehr zulässt. In Hamburg muss sich VMware für die Modifikation des Linuxkernels verantworten.
Die Einforderung von Open Source Compliance ist plötzlich nicht mehr ein Weglaufen vor einem unwahrscheinlichen Blitzschlag geworden, sondern die notwendige Vorsichtsmaßnahme gegen Regen. Heute im Jahr 2015 mag der Compliance Druck noch nicht zu jedem einzelnen Entwickler durchgeschlagen haben; das liegt vor allem daran, dass die neuen Compliance Regeln erst in der nächsten Ausschreibung Vertragsinhalte werden und tatsächlich auch die Umstellung von Einkaufsprozessen in manchen Konzernen mehrere Jahre. Feststeht aber: es reicht nicht mehr aus, den geklauten Source Code vor ein paar Hackern zu verstecken, die das Gerät auseinandernehmen können. Ihr Kunde verlangt von ihnen, dass sie ihre Codebase freihalten von Rechtsmängeln. Dabei bedroht er sie nicht mit der Unterlassungsklage und dem Vernichtungsanspruch wie die Kernelentwickler, sondern mit der einfachen Mängeleinrede bei der Nichtbezahlung ihres Kaufpreises.