Tachchen!
Begriffe wie "Freie Software", "Open Source", "FOSS", "FLOSS" usw. beziehen sich ja immer auf das Endergebnis, auf die ausgelieferte Software. Wenn man einen privaten Abzweig eines Programmes unterhält oder die Geschichte eines Programmfehlers erforschen will, so braucht man aber auch noch die Versionsgeschichte. Die meisten FLOSS-Projekte werden heute ja auf öffentlichen CVS-, Subversion-, Git-, Darcs- usw. -servern entwickelt, aber streng genommen wird das von obigen Begriffen nicht gefordert. Gibt es denn auch einen Namen für "freie Software (4 Freiheiten) + Veröffentlichung der Versionsgeschichte"?
Hallo,
bei Freier Software (im herkömmlichen Sinne) werden die vier Freiheiten durch die jeweilige Lizenz rechtlich garantiert. Ich habe beispielsweise ein Recht darauf, die Software verändern zu dürfen und ich habe einen Anspruch darauf, dass mir der Quellcode der an mich weitergegebenen Version zugänglich gemacht wird.
Schon dieser Anspruch verlangt vom Entwickler einen gewissen Aufwand, aber letztlich entscheidet er durch Art und Umfang der Veröffentlichung des Programms über die Größe dieses Aufwandes.
Würde man Deine fünfte Freiheit auf Zugang zur Versionsgeschichte ebenso rechtlich verbindlich zum Gegenstand der Lizenz machen, würde man dem Entwickler und/oder dem Verbreiter einen Aufwand zumuten, der in verschiedener Hinsicht weit über die bisherigen Verpflichtungen hinausgeht, die sich für den Entwickler und/oder den Verbreiter aus den bisherigen Freien Lizenzen ergeben.
Erhebliche Probleme ergeben sich auch dann, wenn in Versionsständen Verletzungen der Rechte Dritter enthalten sind, zu deren Abstellung der Entwickler und/oder der Verbreiter diesen gegenüber verpflichtet ist.
Nur ein paar schnelle Überlegungen zu Deinem Vorschlag.
Das Anliegen, das Studium der Softwareentwicklung durch entsprechende Transparenz zu fördern, halte ich auch für unterstützenswert.
Gruß Michael
Moin,
Am Freitag, 12. Januar 2018, 19:21:02 CET schrieb Dr. Michael Stehmann:
Hallo,
bei Freier Software (im herkömmlichen Sinne) werden die vier Freiheiten durch die jeweilige Lizenz rechtlich garantiert. Ich habe beispielsweise ein Recht darauf, die Software verändern zu dürfen und ich habe einen Anspruch darauf, dass mir der Quellcode der an mich weitergegebenen Version zugänglich gemacht wird.
Schon dieser Anspruch verlangt vom Entwickler einen gewissen Aufwand, aber letztlich entscheidet er durch Art und Umfang der Veröffentlichung des Programms über die Größe dieses Aufwandes.
Würde man Deine fünfte Freiheit auf Zugang zur Versionsgeschichte ebenso rechtlich verbindlich zum Gegenstand der Lizenz machen, würde man dem Entwickler und/oder dem Verbreiter einen Aufwand zumuten, der in verschiedener Hinsicht weit über die bisherigen Verpflichtungen hinausgeht, die sich für den Entwickler und/oder den Verbreiter aus den bisherigen Freien Lizenzen ergeben.
Erhebliche Probleme ergeben sich auch dann, wenn in Versionsständen Verletzungen der Rechte Dritter enthalten sind, zu deren Abstellung der Entwickler und/oder der Verbreiter diesen gegenüber verpflichtet ist.
In dem Zusammenhang möchte ich mal meine Interpretation der Sachlage öffentlicher Repositories mit eurer abgleichen.
Wenn der Quellcode zwischen den Releases öffentlich und mit Lizenzangaben zur Verfügung steht (was ja die Voraussetzung für Hennings Forderung wäre), dann gilt jeder Commit als Release im Sinne der Lizenz, oder?
Im Umkehrschluss muss jeder Commit lizenztechnisch einwandfrei sein, also z.B. genutzten Fremdcode ordentlich ausweisen, das sagt Michael gerade.
Und last-but-not-least macht man sich durch das Forken eines lizenztechnisch unsauberen Standes in z.B. Github, wo alle Repos öffentlich sind, und der damit einhergehend (automatischen zwangsweisen) Weitergabe für genau diese Lizenzverletzung haftbar, oder? Also ein klares Argument gegen Github und ähnliche Angebote...
Liege ich mit meiner Interpretation richtig? Ist das schonmal tiefer beleuchtet worden?
Nur ein paar schnelle Überlegungen zu Deinem Vorschlag.
Das Anliegen, das Studium der Softwareentwicklung durch entsprechende Transparenz zu fördern, halte ich auch für unterstützenswert.
+1
Viele Grüße Christian
Moin,
Am Sonntag 14 Januar 2018 14:32:59 schrieb Christian Kalkhoff:
Wenn der Quellcode zwischen den Releases öffentlich und mit Lizenzangaben zur Verfügung steht (was ja die Voraussetzung für Hennings Forderung wäre), dann gilt jeder Commit als Release im Sinne der Lizenz, oder?
das kommt auf die Lizenz und das Produkt an, würde ich sagen. In den GNU Lizenzen geht es viel um Binärversionen eines Produkts.
Im Umkehrschluss muss jeder Commit lizenztechnisch einwandfrei sein, also z.B. genutzten Fremdcode ordentlich ausweisen, das sagt Michael gerade.
Da jede Quelltextänderung öffentlich ist, sollte sie in jeder Hinsicht in Ordnung sein. Das muss aber im Sinne der Lizenz noch keine "Veröffentlichung" bedeuten. (Wenn mal ein Unfall passiert, dann kann mit den verteilten SCMs die Geschichte umgeschrieben werden. Beispiel: https://www.mercurial-scm.org/wiki/EditingHistory )
Und last-but-not-least macht man sich durch das Forken eines lizenztechnisch unsauberen Standes [..], wo alle Repos öffentlich sind, und der damit einhergehend (automatischen zwangsweisen) Weitergabe für genau diese Lizenzverletzung haftbar, oder?
Du könntet beim Kopieren des Quelltextbaumen angegeben, dass Du Dich auf die Aussage der original-Lizenz verlassen hast und Du vernünftige Maßnahmen ergriffen hast, die Plausibilität zu prüfen. Dann kannst Du unter Umständen das Problem weiterreichen, falls Du eines hast. Oft reicht es aber auch, dass Problem einfach abzustellen.
Liege ich mit meiner Interpretation richtig? Ist das schonmal tiefer beleuchtet worden?
Wenn ich schätzen sollte, würde ich sagen, dass sich das bestimmt schon mal jemand angesehen hat. Mir ist es jedoch nicht über den Weg gelaufen und ich denke, dass hier ein wenig Pragmatik angesagt ist. Arbeiten in der Öffentlichkeit sorgt oft schon dafür, dass jeder ein wenig mehr aufpasst, das ist schon gut. Das Herumspielen mit Quelltext sollten wir eigentlich fördern und die juristischen Hürden klein halten. Klar, wer dann ein großes kommerziell erfolgreiches Freie Software-Produkt auf Basis seiner Variante herausgibt, dem sind auch ein paar mehr Prüfungen zuzumuten.
Nur ein paar schnelle Überlegungen zu Deinem Vorschlag.
Das Anliegen, das Studium der Softwareentwicklung durch entsprechende Transparenz zu fördern, halte ich auch für unterstützenswert.
+1
Da stimmte ich nur eingeschränkt zu. Zuviel Druck in Richtung "offene Entwicklung" halte ich für schlecht.
Gruß, Bernhard
Moin Henning,
Am Donnerstag 11 Januar 2018 20:14:48 schrieb Henning Thielemann:
Gibt es denn auch einen Namen für "freie Software (4 Freiheiten) + Veröffentlichung der Versionsgeschichte"?
allgemein kenne ich das unter "offener Entwicklung" auf Englisch würde ich "development in the open", "open development" oder "development in public" sagen.
Wie offen oder geschlossen entwickelt wird, halte ich für eine Eigenschaft, welche sehr unterschiedlich sein kann und ich deshalb unabhängig von der Freiheit einer Software einordne (siehe meinen Artikel [1]).
Mir erscheint es sinnvoll, hier verschiedene Grade der Entwicklung als positiv anzusehen, da einige Entwicklungsgruppen mit sehr detaillierten Commits arbeiten und die werden für die Versionsgeschichte nicht gebraucht und sind eher hinderlich. Die Freiheit ein Programm zu studieren, wird dadurch aufgewertet, dass ich das im geschützen, nicht-öffentlichen Raum tun darf. Manchmal ist es sogar sinnvoll, dass ich meine eigenen kleinen Variationen die ich verwende, nicht veröffentlichen brauche, obwohl ich sie nutze, es macht die Software robuster.
Bei (meinem Unternehmen) Intevation möchten wir immer in der Öffentlichkeit entwickeln. Manchmal gibt es Kunden, welche sich damit nicht sofort Wohl fühlen. Was wir jedoch immer machen, ist unseren Code (nicht die Konfiguration) veröffentlichen und ich nenne das "Output-Freie Software", in Abgrenzung zu anderen Unternehmen, welche ihre Produkte mit Freie Software-Komponenten bauen, die dann aber entweder nur laufen lassen oder sie ausschließlich dem Auftraggeber zur Vergügung stellen (der dann oft nicht veröffentlicht).
Viele Grüße, Bernhard
[1] [Reiter 2004] Bernhard E. Reiter Wandel der IT: Mehr als 20 Jahre Freie Software; in HMD, Heft 238, August 2004, Seiten 83-91 https://intevation.de/~bernhard/publications/200408-hmd/200408-wandel_der_it...