Gesellschaft::Politik/Recht
Copyright und Open Source
Das Software Freedom Law Center hat einen Leitfaden herausgegeben, um Open-Source-Projekten bei der Handhabung der Copyright-Informationen zu helfen.
OCAL
Zusammen mit dem Quellcode veröffentlichen freie Software-Projekte üblicherweise die Lizenz(en), der die Software unterliegt, und die Copyright-Informationen der daran beteiligten Autoren. In größeren Projekten kann die Pflege dieser Informationen mit jeder neuen Version der Software viel Zeit beanspruchen.
Wozu ist Copyright gut? Im Copyright wird festgehalten, wer welche Teile des Codes geschrieben hat und unter welcher Lizenz diese stehen. Fehlendes Copyright bedeutet nicht, dass dem Entwickler der Code nicht mehr gehört. Es bedeutet aber, dass er alle daran Interessierten im Unklaren über Rechte und Lizenzen lässt.
Die Anleitung des Software Freedom Law Center will freien Projekten helfen, die Probleme zu minimieren und die Nützlichkeit der Copyright-Informationen zu erhöhen. Copyright ist nicht nur juristisch relevant, auch Downstream-Entwickler und Endnutzer orientieren sich sowohl an Lizenzen als im Detail am Copyright in der Frage, was man mit dem Code tun darf und was nicht.
Was macht Software frei im Sinne von Freiheit? Wenn ein Entwickler einer Software diese als freie Software deklarieren will, muss er in seinem Copyright eine freie Lizenz verwenden und eine Kopie dieser Lizenz beifügen oder verlinken. Gleiches gilt für alle anderen beteiligten Personen und ihre Beiträge. Ist dies nicht der Fall, muss ein Dritter, der den Code kopieren, verändern oder veröffentlichen will, davon ausgehen, dass er das nicht darf.
Gründliche und akkurate Pflege der Copyright-Einträge liegt im Eigeninteresse eines jeden Projekts und wird im Leitfaden als erstes angemahnt. Nur so können Dritte eigene Entwicklungen abzweigen und die Software einer weiteren Verbreitung zuführen. Oft ist es in größeren Projekten so, dass verschiedene Teile des Codes verschiedenen Lizenzen unterliegen. Bestandteile können auf proprietärem Code aufbauen. Hier ist eine genaue Kennzeichnung essentiell. Notizen, wer welchen Codeschnipsel wann eingeführt hat, können ebenfalls zu einem späteren Zeitpunkt sehr hilfreich sein.
Ein weiteres Problem in großen Projekten ist, dass nur eine bestimmte Anzahl an Entwicklern das Recht hat, Pakete und Patches in den Codebestand einzubringen. Sie erhalten oft von dazu nicht berechtigten Autoren Beiträge, die sie dann einpflegen. Hier geht sehr leicht Copyright-Information verloren. Das Papier rät daher, ab einer bestimmten Größe nicht nur den Code, sondern auch die Copyright-Einträge in einem Version Control System (VCS) wie beispielsweise SVN, GIT oder Mercurial zu verwalten.
Debian geht einen anderen Weg. Wer dort Copyright-Einträge nachliest, wird feststellen, dass es kein einheitliches Format für diese Einträge gibt bzw. gab. Das Problem hierbei ist, das derart frei gestaltete Copyright-Informationen nicht maschinenlesbar sind. Debian hat deshalb vor einiger Zeit ein Projekt namens DEP5 gestartet, um sein Copyright in allen Paketen maschinenlesbar umzustellen, aber gleichzeitig leicht lesbar für Menschen zu belassen. Die Umstellung wird einige Zeit dauern. Damit wird es ein Leichtes, verschiedenste Informationen aus einem Paket oder dem gesamten Projekt zu ziehen und z.B. statistisch auszuwerten.
Das Papier stellt im weiteren Verlauf zwei Systeme vor, wie üblicherweise Copyright-Informationen in freien Projekten gehandhabt werden. Das dateibasierte System wird dem zentralisierten System gegenübergestellt. In ersterem hat jede Datei am Anfang den Copyright-Eintrag. Beim zentralisierten System gibt es eine Datei pro Paket (z.B.debian/copyright), die das gesamte Copyright des Pakets enthält.
Beim dateibasierten Ansatz ist es wahrscheinlicher, dass der Autor sein Copyright selbst pflegt und aktualisiert. Bei einer Änderung des Codes muss er oft nur die Jahreszahl heraufsetzen oder schlimmstenfalls eine Zeile ändern oder hinzufügen. Er sieht den Eintrag am Kopf der Datei und wird ihn eher selten vergessen. Das Prinzip eignet sich am ehesten für kleinere Projekte mit einer überschaubaren Anzahl an Paketen.
Der zentralisierte Ansatz, der am besten mit einem VCS verknüpft wird, hat lediglich einen Nachteil, wenn Dinge am VCS vorbei geschehen. So wird eine manuell verschobene Datei aus dem System fallen und die Copyright-Information verloren gehen. Ansonsten hilft bei großen Projekten dieser Ansatz bei der Übersicht. So können auch die jeweiligen Lizenzen in Kopie in der zentralen Copyright-Datei vorgehalten werden.
Wie auch immer das Copyright gehandhabt wird, der Artikel macht zum Schluss noch einmal klar, dass im Copyright
die gesamten Besitzverhältnisse und die Lizenzstruktur innerhalb eines Projekts verankert sind. Ein gut gepflegtes Copyright zahlt sich spätestens dann aus, wenn es Unstimmigkeiten gibt oder wenn beispielsweise die Lizenz des Projekts geändert werden soll.
){kind=small}
