Manfred Kloiber: Martin Schweinoch, Rechtsanwalt aus München, Sie haben maßgeblich an diesem Leitfaden mitgearbeitet. Was genau steht denn drin?
Martin Schweinoch: Der Leitfaden hat eine Zielsetzung, ein Bewusstsein zu schaffen für die rechtlichen Fragen, die um Open-Source herum kreisen. Er führt ein in die Thematik mit der Botschaft, dass Open-Source-Software, bloß weil sie umsonst ist, nicht zu allem und jedem verwendet werden kann.
Kloiber: Was ist denn das Spezielle am Themenkreis Open-Source und Recht?
Schweinoch: Das Spezielle ist von der Ursprungssituation her, dass Open-Source-Software im Quellcode weitergegeben wird und von den Beziehern auch geändert werden darauf. Das ist ein Charakteristikum, was Open-Source grundsätzlich von kommerzieller Software unterscheidet. Die Entwickler, die Open-Source dann auch inhaltlich wirklich verändern und nicht weitergeben, so wie sie sie bekommen, sondern damit arbeiten, laufen Gefahr, damit gegen die Lizenzbedingungen, die für die Open-Source-Software jeweils gelten, und davon gibt es unterschiedliche, zu verstoßen. Das bedeutet, ein Softwarehaus, ein Entwickler, der seinen Kunden veränderte Open-Source-Software weitergibt und diese Lizenzbedingungen nicht einhält, kann den Kunden daran keine Rechte verschaffen. Er verkauft etwas, was er nicht leisten kann. Und das ist auf der vertragsrechtlichen Ebene, vorsichtig ausgedrückt, problematisch.
Kloiber: Ein Grund liegt vielleicht darin, dass Softwareentwickler natürlich ein Interesse daran haben, ihre Entwicklung zu schützen und deswegen ungern erzählen, wie sie es gemacht haben. Das müssen Sie aber jetzt?
Schweinoch: Bei bestimmten Arten von Open-Source-Lizenzen müssen sie das erzählen. Die Open-Source-Lizenzen, die den so genannten Copyleft-Effekt beinhalten, sehen das gerade vor. Copyleft-Effekt, das ist ein Wortspiel mit dem englischen Begriff Copyright, also dem deutschen Urheberrecht, und bedeutet: die veränderte Open-Source-Software, die weitergegeben werden soll, muss auch im Quelltext offen gelegt werden. Das ist etwas, was es so bei kommerzieller Software auch nicht gibt. Dieser Copyleft-Effekt vererbt sich quasi, also Open-Source-Software, die diesem Copyleft-Effekt unterliegt, das ist in den Lizenzbedingungen dann so geregelt, muss dann auch in veränderter Form wieder offen gelegt werden. Das gilt sogar dann, wenn kommerzielle Software mit Open-Source kombiniert wird, sodass es ein gemeinsames Programm wird, dann ist das gesamte Programm offen zu legen.
Kloiber: Es gibt aber auch noch andere Fallstricke. Sie haben ja ein Beispiel genannt aus dem Bereich Gewährleistung. Da gibt es dann Unterschiede, die auf einmal auftauchen, oder eine Gewährleistungslücke. Können Sie das erklären?
Schweinoch: Die Lizenzbedingungen für Open-Source-Software unterstehen fast immer ausländischem Recht, insbesondere angelsächsischem Recht. Das angelsächsische Recht kennt, anders als das deutsche Recht, nicht in dieser Form wie wir es gewohnt sind eine gesetzliche Gewährleistung, die relativ lange dauert und ganz klar definierte Rechte für den Benutzer beinhaltet. Das führt zu folgendem Effekt: der Entwickler bezieht die Open-Source-Software und hat gegenüber seinem Lieferanten keine dem deutschen Recht entsprechenden Gewährleistungsansprüche. Wenn er sie entgeltlich weiter vermarktet, muss er aber seinen Kunden die Gewährleistungsansprüche nach deutschem Recht gewähren. Diese Lücke, die da besteht, muss er im Grunde genommen auf das eigene Risiko nehmen und auch durch eigene Leistung ausfüllen können.
Kloiber: Was sollte man denn tun, wenn man jetzt konkret in der Entwicklung als Softwareentwickler freiberuflich oder in einer Firma steht, ein Open-Source-Projekt entwickelt oder ein Projekt, wo zumindest durch GPL, also diese Public License geschützte Teile verwandt werden. Was kann man da als erstes oder regelmäßig tun, um sich eben halt vor so einer Pleite zu schützen?
Schweinoch: Man kann im Grunde genommen drei Schritte unterscheiden. Der erste Schritt heißt schlicht, den Status analysieren, welche Lizenzbedingungen gelten für welche Bestandteile von Open-Source-Software? Die Lizenzbedingungen sind sehr unterschiedlich. Es gibt auch durchaus Lizenzbedingungen, die diesen Copyleft-Effekt, den Zwang zur Offenlegung auch geänderten Quellcodes, nicht vorsehen. Das heißt, man muss erst einmal eine Statusaufstellung machen, für welche Open-Source-Software gelten welche Lizenzbedingungen in welcher Fassung. Diese Fassungen werden ständig weiterentwickelt und haben eine Versionsführung, ähnlich wie es sie auch für Software gibt. Der zweite Schritt wäre dann, anhand dieser Lizenzinhalte zu überlegen, wie kann ich das einsetzen, was kann ich dann intern weiterverwenden oder was kann ich dann an meine Kunden in welcher Form weitergeben. Und im dritten Schritt wäre es auch dem Kunden gegenüber klar zu kommunizieren und auch in den Verträgen zu vereinbaren, welche Bestandteile der Software sind Open-Source und welche Lizenzbedingungen gelten für diese Bestandteile.
Martin Schweinoch: Der Leitfaden hat eine Zielsetzung, ein Bewusstsein zu schaffen für die rechtlichen Fragen, die um Open-Source herum kreisen. Er führt ein in die Thematik mit der Botschaft, dass Open-Source-Software, bloß weil sie umsonst ist, nicht zu allem und jedem verwendet werden kann.
Kloiber: Was ist denn das Spezielle am Themenkreis Open-Source und Recht?
Schweinoch: Das Spezielle ist von der Ursprungssituation her, dass Open-Source-Software im Quellcode weitergegeben wird und von den Beziehern auch geändert werden darauf. Das ist ein Charakteristikum, was Open-Source grundsätzlich von kommerzieller Software unterscheidet. Die Entwickler, die Open-Source dann auch inhaltlich wirklich verändern und nicht weitergeben, so wie sie sie bekommen, sondern damit arbeiten, laufen Gefahr, damit gegen die Lizenzbedingungen, die für die Open-Source-Software jeweils gelten, und davon gibt es unterschiedliche, zu verstoßen. Das bedeutet, ein Softwarehaus, ein Entwickler, der seinen Kunden veränderte Open-Source-Software weitergibt und diese Lizenzbedingungen nicht einhält, kann den Kunden daran keine Rechte verschaffen. Er verkauft etwas, was er nicht leisten kann. Und das ist auf der vertragsrechtlichen Ebene, vorsichtig ausgedrückt, problematisch.
Kloiber: Ein Grund liegt vielleicht darin, dass Softwareentwickler natürlich ein Interesse daran haben, ihre Entwicklung zu schützen und deswegen ungern erzählen, wie sie es gemacht haben. Das müssen Sie aber jetzt?
Schweinoch: Bei bestimmten Arten von Open-Source-Lizenzen müssen sie das erzählen. Die Open-Source-Lizenzen, die den so genannten Copyleft-Effekt beinhalten, sehen das gerade vor. Copyleft-Effekt, das ist ein Wortspiel mit dem englischen Begriff Copyright, also dem deutschen Urheberrecht, und bedeutet: die veränderte Open-Source-Software, die weitergegeben werden soll, muss auch im Quelltext offen gelegt werden. Das ist etwas, was es so bei kommerzieller Software auch nicht gibt. Dieser Copyleft-Effekt vererbt sich quasi, also Open-Source-Software, die diesem Copyleft-Effekt unterliegt, das ist in den Lizenzbedingungen dann so geregelt, muss dann auch in veränderter Form wieder offen gelegt werden. Das gilt sogar dann, wenn kommerzielle Software mit Open-Source kombiniert wird, sodass es ein gemeinsames Programm wird, dann ist das gesamte Programm offen zu legen.
Kloiber: Es gibt aber auch noch andere Fallstricke. Sie haben ja ein Beispiel genannt aus dem Bereich Gewährleistung. Da gibt es dann Unterschiede, die auf einmal auftauchen, oder eine Gewährleistungslücke. Können Sie das erklären?
Schweinoch: Die Lizenzbedingungen für Open-Source-Software unterstehen fast immer ausländischem Recht, insbesondere angelsächsischem Recht. Das angelsächsische Recht kennt, anders als das deutsche Recht, nicht in dieser Form wie wir es gewohnt sind eine gesetzliche Gewährleistung, die relativ lange dauert und ganz klar definierte Rechte für den Benutzer beinhaltet. Das führt zu folgendem Effekt: der Entwickler bezieht die Open-Source-Software und hat gegenüber seinem Lieferanten keine dem deutschen Recht entsprechenden Gewährleistungsansprüche. Wenn er sie entgeltlich weiter vermarktet, muss er aber seinen Kunden die Gewährleistungsansprüche nach deutschem Recht gewähren. Diese Lücke, die da besteht, muss er im Grunde genommen auf das eigene Risiko nehmen und auch durch eigene Leistung ausfüllen können.
Kloiber: Was sollte man denn tun, wenn man jetzt konkret in der Entwicklung als Softwareentwickler freiberuflich oder in einer Firma steht, ein Open-Source-Projekt entwickelt oder ein Projekt, wo zumindest durch GPL, also diese Public License geschützte Teile verwandt werden. Was kann man da als erstes oder regelmäßig tun, um sich eben halt vor so einer Pleite zu schützen?
Schweinoch: Man kann im Grunde genommen drei Schritte unterscheiden. Der erste Schritt heißt schlicht, den Status analysieren, welche Lizenzbedingungen gelten für welche Bestandteile von Open-Source-Software? Die Lizenzbedingungen sind sehr unterschiedlich. Es gibt auch durchaus Lizenzbedingungen, die diesen Copyleft-Effekt, den Zwang zur Offenlegung auch geänderten Quellcodes, nicht vorsehen. Das heißt, man muss erst einmal eine Statusaufstellung machen, für welche Open-Source-Software gelten welche Lizenzbedingungen in welcher Fassung. Diese Fassungen werden ständig weiterentwickelt und haben eine Versionsführung, ähnlich wie es sie auch für Software gibt. Der zweite Schritt wäre dann, anhand dieser Lizenzinhalte zu überlegen, wie kann ich das einsetzen, was kann ich dann intern weiterverwenden oder was kann ich dann an meine Kunden in welcher Form weitergeben. Und im dritten Schritt wäre es auch dem Kunden gegenüber klar zu kommunizieren und auch in den Verträgen zu vereinbaren, welche Bestandteile der Software sind Open-Source und welche Lizenzbedingungen gelten für diese Bestandteile.