YourFritz-Repository und Aktualisierungen in Freetz-NG

[PeterPawn]

Damit das nicht immer als "stille Post" laufen muß und entsprechende Verzögerungen zwischen meinen Versuchen der Fehlerbehebung und der Verfügbarkeit für die Benutzer von Freetz-NG nach sich zieht, hänge ich Dir hier mal einen Vorschlag meinerseits an, wie man das so regeln könnte (mit minimalen Änderungen für das yourfritz-host-Paket in den Freetz-Tools), daß ich meinerseits mit einem passend benannten Tag im GitHub-Repository steuern kann, WELCHEN Stand die Freetz-NG-Benutzer verwenden ... und das dann auch bei JEDEM Build (weil der Hash beim Zusammenstellen des Baumes für das make ermittelt wird).

---

Dafür muß man zwar auf die SHA256-Verifikation verzichten, aber die ist letztlich auch nur Augenwischerei - wenn GitHub da schon irgendwelche Änderungen vornehmen würde, dann hat man die bei dem Checkout, anhand dessen dieser Hash im Makefile hinterlegt wird, ja auch dabei. Es geht hier ja nicht um den Download des Pakets von irgendeinem fremden Download-Server. Die Authentizität des jeweils getaggten Commits ist mit meiner Signatur bestätigt - auch wenn das derzeit im git_tag_to_hash nicht aktiv geprüft wird. Wollte man das noch einbauen, müßte man auch freetz_download ändern, denn dann müßte man nicht nur das Log durchsuchen lassen, sondern auch noch den Commit laden (bzw. geladen haben) und mit dem passenden Key verifizieren.

---

Ich habe dabei auch bewußt darauf verzichtet, das mittels der automatisch erzeugten Links für Pakete (https://github.com/PeterPawn/YourFritz/tags) zu realisieren, weil man dann IMMER den Download ausführen müßte, da es an diesen Links/Dateien nicht mehr ersichtlich ist, ob sich das Tag verschoben hat (im Vergleich zum letzten Run) oder nicht.

---

Ich habe es auch (absichtlich) in einzelne Commits gesplittet, damit Du Dir für jeden einzelnen davon eine Meinung bilden kannst - der Patch, der den 101-irgendwas-Patch ändert und die Änderungen am Inhalt von make/tools/yourfritz-host stehen aber in einem Zusammenhang.

---

Wenn Du dann hinterher auch noch diese zwei Zeilen für die Skripte in bootmanager entfernen willst:

freetz-ng/tools/make/yourfritz-host/yourfritz-host.mk

Line 11 in 272705a

YOURFRITZ_HOST_BASH_AS_SHEBANG += bootmanager/add_change_oem.sh

, tu Dir keinen Zwang an. Diese verwenden mittlerweile NUR NOCH einfache POSIX-Syntax und müßten daher auch mit der dash problemlos funktionieren:

vidar:/home/GitHub/YourFritz/bootmanager $ shellcheck -s dash -a add*
vidar:/home/GitHub/YourFritz/bootmanager $

... zumindest sieht das auch ein shellcheck so.

---

0001-tools-add-a-small-shell-script-to-get-the-hash-value.patch.txt
0002-yourfritz-host-use-remote-version-tagged-with-freetz.patch.txt
0003-yf_bootmanager-unify-handling-of-fixed-branding-betw.patch.txt

[fda77]

Checksum bei repos wird ignoriert - solang aus dem cvs ausgecheckt wird. Die Checksumme wird aber verwendet wenn ein Backup von den Mirrors heruntergeladen wird. Mirrors sind schneller, man kann im menuconfig auswählen was bevorzugr werden soll. kconfig hat zb einen extreme langsames source-repo, der Dl dauert über 1 Minute. Ich ändere nur auf 2 der insgesamt 6 oder 7 mirror Dateien. Wenn man kein Backup auf Mirrors hat, bzw den download von Freetz aus sperren will ein "X" eingeben. https://github.com/Freetz-NG/freetz-ng/blob/master/tools/freetz_download#L381

Tag freetz-ng-version: Find ich nicht so gut. Angenommen jemand aktualisiert seinen freetz clone nur 1x im Jahr. Dieser würde aber immer das neueste YourFritz erhalten. Wenn dieser die Datei "040-bootmanager_freetz_fixed_branding_approach.patch" noch hätte würde es nicht mehr funktionieren.
Oder in einer neueren Revision von Yourtfritz ändert sich ein Parameter oder dieser muss immer angegeben werden. Die vorhandenen Scripte in Freetz haben diesen aber noch nicht und würden fehlschlagen.
Eine statische Versionsnummer ist da besser. Manche Packages in freetz haben eine auswahl "gesteteter has" oder "neuester", da liegt es dann am Benutzer zu schauen ob alles noch zusammenpasst, zb https://github.com/Freetz-NG/freetz-ng/blob/master/make/pyload/pyload.mk#L2
eine "git-get-latest-revision" funktion gibt es übrigens schonm hab jetzt auf die schnelle nicht gefunden wie die im code steckt

juis_check nicht vergessen: Es nutzt immer die gleiche Version wie yourfritz und erspart sich den download und entpacken, da yf-host immer vorher verfügbar ist. Bei verschiedenen Versionen gibt es den Pfad nicht der die Version enthält: https://github.com/Freetz-NG/freetz-ng/blob/master/make/juis_check/juis_check.mk EDIT falsch, es aktualisiert sich nur nicht bei tag-änderungen

[fda77]

Übrigens hat ein aus git/svn etc heruntergeladenes Package jedes mal einen anderen Hash, da Timestamps in der tar sind. er13 wollte das mal irgend wann einbauen, hatte aber keinen Weg gefunden immer auf die gleiche Checksum zu kommen

[PeterPawn]

Checksum bei repos wird ignoriert

Dann macht die Angabe in der mk-Datei ja erst recht keinen Sinn und auch die wird von Dir ja immer wieder aktualisiert.

Die Checksumme wird aber verwendet wenn ein Backup von den Mirrors heruntergeladen wird.

DAS macht ja nun in meinen Augen gar keinen Sinn mehr (und ich habe auch ältere YourFritz-Versionen da nie gefunden). Ich hoffe mal, daß Du das nicht wirklich so machst ... ich erinnere dabei dann auch noch einmal daran, daß längst nicht alles in meinen Repositories auch unter einer Lizenz steht, die anderen die Verbreitung erlaubt. Der überwiegende Teil ist zwar GPL (v2 bzw. v3), aber in Unterverzeichnissen kann es in all diesen Repositories auch abweichende Lizenzbestimmungen geben, die dann natürlich auch vorrangig gelten.

Angenommen jemand aktualisiert seinen freetz clone nur 1x im Jahr. Dieser würde aber immer das neueste YourFritz erhalten. Wenn dieser die Datei "040-bootmanager_freetz_fixed_branding_approach.patch" noch hätte würde es nicht mehr funktionieren.

Verstehe ich nicht ... entweder er nimmt von Freetz-NG eine ältere Version, dann passen die Patches auch noch (die sind ja Bestandteil von Freetz-NG und nicht im YourFritz-Repo, daher auch nicht von dessen Stand abhängig - außerdem hat er ja dann immer noch die alte yourfritz-host.mk mit dem alten Hash) oder er aktualisiert auf eine neuere Freetz-NG-Version, dann hat er auch neuere Patches. Was siehst Du da genau für Probleme?

Oder in einer neueren Revision von Yourtfritz ändert sich ein Parameter oder dieser muss immer angegeben werden. Die vorhandenen Scripte in Freetz haben diesen aber noch nicht und würden fehlschlagen.

Kannst Du das noch mal irgendwie erklären - am besten mit einem nachvollziehbaren Beispiel? Auch hier verstehe ich gar nicht, was Du genau meinst. Ich bin ja sogar hingegangen und habe beim bootmanager die ganzen bisherigen Werte weiterhin ausgegeben (einen Fehler dabei habe ich gerade erst noch korrigiert), damit auch dann, wenn jemand etwas eigenes auf der Basis einer älteren Version gebaut haben sollte, dieses nach wie vor funktionieren kann. Und ich wage mal zu behaupten, daß ich selbst solche "breaking changes" deutlich seltener ausführe, als andere ... und ich will da niemanden direkt anschauen.

eine "git-get-latest-revision" funktion gibt es übrigens schon

Das ist aber etwas anderes (außerdem glaube ich, daß Du das irgendwie mit freetz_revision und der Suche nach der letzten Freetz(-NG)-Version verwechselst), denn mein Tag muß gar nicht zwingend auf der "latest version" sitzen, solange Änderungen nicht den Boot-Manager und/oder juis betreffen (für avm_kernel_config wird ja ohnehin der (geänderte) Quelltext direkt in den Freetz-Repos verwaltet - das ist auch GPL-Lizenz meinerseits gewesen) - das würde man ja genauso "selten" aktualisieren, wie Du einen "version bump" für das Repo ausführst ... und mal ganz ehrlich, Du kannst mir nicht wirklich einreden, daß Du immer erst alle Änderungen zwischen den Versionen von YourFritz ansiehst/überprüfst, bevor Du da einen neuen Hash einsetzt. Da wärst Du sogar wieder "fein raus", wenn Du dafür gar nicht mehr verantwortlich bist.

Du warst auch mal der Ansicht, ich sollte doch einfach selbst Schreibrechte im Freetz-NG-Repo haben wollen ... was ich aber nicht will und zwar "aus Gründen". Das hier wäre letztlich nichts anderes, nur beschränkt auf genau die Teile/Software, für die ich mich tatsächlich auch zuständig sähe.

---

Ich habe das jedenfalls in meinem eigenen (lokalen) Klon des Freetz-NG-Repos GENAU SO auch umgesetzt (und auch noch mit abweichender URL, denn lokal greife ich mit SSH zu) - ich habe einfach KEINEN BOCK, nach Änderungen im YourFritz-Repo, deren Auswirkungen auf das Freetz-NG-Zeug ich dann prüfen will, jedesmal auch erst noch den Hash (und anderen Unsinn) in den Makefiles anpassen zu müssen.

Solange das nicht bei Dir am Upstream auch so implementiert ist, müßte ich dann jedesmal, wenn Du den Upstream geändert hast, auch meine eigenen Änderungen wieder auf den dann aktuellen Stand "rebasen" - ehrlich gesagt nichts, was ich ständig machen möchte und damit dann auch wieder ein Punkt, der mich davon abhält, für irgendwelche Probleme (ob nun im Zusammenhang mit meinen eigenen "Schöpfungen" oder bei anderen Paketen) selbst mit einem Freetz-NG-Checkout auf eine Suche zu gehen.

Aber mach', wie Du denkst ... und das war auch nicht die einzige Änderung mit diesen drei Patches und in diesem Beitrag habe ich dann ja auch noch zwei(!) Fragen gestellt, die Du mir vielleicht beantworten kannst.

[fda77]

ich habe auch ältere YourFritz-Versionen da nie gefunden

Wo hast du gesucht? Hier zb bestimmt nicht: https://github.com/Freetz-NG/dl-mirror
Auch auf den 3 freetz/ mirrors liegen mindestens 5 verschieden Versionen, zb 50b40c96f3 & d976e2791a
Das aktualisieren von Checksummen hab ich eh automatisiert

Verstehe ich nicht ... entweder er nimmt von Freetz-NG eine ältere Version, dann passen die Patches auch noch (die sind ja Bestandteil von Freetz-NG und nicht im YourFritz-Repo, daher auch nicht von dessen Stand abhängig - außerdem hat er ja dann immer noch die alte yourfritz-host.mk mit dem alten Hash) oder er aktualisiert auf eine neuere Freetz-NG-Version, dann hat er auch neuere Patches. Was siehst Du da genau für Probleme?

Ja so ist das aktuell und passt immer. Daher finde ich es ja problematisch dass zukünftig immer die aktuellste YF Version verwendet werden soll, da dann Patches, Parameter usw dann nicht passen könnten. Oder eine neuere Version brauch eine zusätzliche env-Variable etc.
Daher denke ich dass das zukünftig einfach nur mehr Probleme berieten wird. Du könntes bei dir als Version auch einfach den Tag angeben. Einzigster Nachteil wäre dann dass es nciht automatisch neu ausgepackt wird bei änderungen des Tags

Das ist aber etwas anderes (außerdem glaube ich, daß Du das irgendwie mit freetz_revision und der Suche nach der letzten Freetz(-NG)-Version verwechselst

Ne, ich hatte das doch verlinkt. Man kann auswählen dass bei manchen Packages aus dessen git die aktuelleste Revision genommen wird. Diese Funktion könnte man (wenn man es nutzen möchte) auf einen Tag beschränken. So sind 2 ähnliche Dinge an verschiedenen Stellen
https://github.com/Freetz-NG/freetz-ng/blob/master/include/make/020-helper-functions.mk#L222

Du warst auch mal der Ansicht, ich sollte doch einfach selbst Schreibrechte im Freetz-NG-Repo haben wollen

Ist bekannt, das wäre nämlich der einfachste und schnellste Weg was zu aktualisieren. Aber ich frag ja gar nicht mehr. Auch nicht als du gestern einen Diskussions-Titel geändert haben wolltest ;-)

ich erinnere dabei dann auch noch einmal daran, daß längst nicht alles in meinen Repositories auch unter einer Lizenz steht, die anderen die Verbreitung erlaubt. Der überwiegende Teil ist zwar GPL (v2 bzw. v3), aber in Unterverzeichnissen kann es in all diesen Repositories auch abweichende Lizenzbestimmungen geben, die dann natürlich auch vorrangig gelten.

Öh, wie? Wenn ich auf https://github.com/PeterPawn/YourFritz geh steht oben rechts "GPL-2.0 License". Da geh ich doch nicht durch alle Dateien und schaue ob da was anderes drin steht. Falls eine andere Lizenz zutrifft hat diese auf jeden Fall GPL2 oder noch weitere Rechte. Alles andere wäre "überraschend". Wenn nicht, solltest du das ändern

Den 0003* kann unabhängig commited werden?

[fda77]

Wie wäre es ein .config sybol einzubauen mit dem immer die neueste Version verwendet wird? dann brauchst du nichts zu ändern. Wie hier: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/kconfig-host/kconfig-host.mk#L19

[PeterPawn]

Ne, ich hatte das doch verlinkt

Bist Du da sicher? Was ich oben zu diesem Punkt (und ich hatte meinerseits vor diesem Satz ja UNMISSVERSTÄNDLICH auf genau dieses git-get-latest-revision Bezug genommen) lesen kann, ist das hier:

eine "git-get-latest-revision" funktion gibt es übrigens schonm hab jetzt auf die schnelle nicht gefunden wie die im code steckt

und ich finde da irgendwie Deine "Verlinkung" nicht.

Den 0003* kann unabhängig commited werden?

Weiß ich nicht, müßte ich erst wieder nachsehen, was der genau macht - das stünde ja dann im Namen des Files, der sich hinter Deinem "*" versteckt.

Öh, wie? Wenn ich auf https://github.com/PeterPawn/YourFritz geh steht oben rechts "GPL-2.0 License". Da geh ich doch nicht durch alle Dateien und schaue ob da was anderes drin steht. Falls eine andere Lizenz zutrifft hat diese auf jeden Fall GPL2 oder noch weitere Rechte. Alles andere wäre "überraschend". Wenn nicht, solltest du das ändern

Hier liegst Du dann tatsächlich daneben - das Bereithalten einer LICENSE-Datei auf der obersten Gliederungsebene (worauf dann auch die Kennzeichnung auf der GitHub-Seite beruht - kannst Du gerne ausprobieren, indem Du diese Datei in einem Repo änderst) heißt noch längst nicht, daß es darunter keine anderen Lizenzen mehr geben kann oder daß die alle nur noch zusätzliche Rechte zur GPL einräumen dürfen.

Genau für das automatisierte Auswerten, welche Teile fremder Software ich unter welchen Lizenzen nutzen darf, gibt es die SPDX-Tags - siehe https://spdx.dev/

Und in meinen Repositories wirst Du - wenn da unterschiedliche Lizenzen gelten - auch genau diese Kennzeichnungen finden (wobei einige dieser Zeilen auch aus fremden Quelltexten stammen, die bei mir als "submodule" eingebunden sind):

vidar:/home/GitHub/YourFritz $ grep -r --color=none "SPDX-License-Identifier:" 2>/dev/null | wc -l
347
vidar:/home/GitHub/YourFritz $ grep -r --color=none "SPDX-License-Identifier: \(GPL-2.0-or-later\)\$" 2>/dev/null | wc -l
214
vidar:/home/GitHub/YourFritz $ grep -r --color=none "SPDX-License-Identifier:" 2>/dev/null | sed -n -e "s|^.*fier: \(.*\)|\1|p" | sort | uniq -c
     16 (GPL-2.0-or-later OR BSD-2-Clause)
      5 (GPL-2.0-or-later OR BSD-2-Clause) */
      1 BSD-2-Clause
    214 GPL-2.0-or-later
     16 GPL-2.0-or-later */
      2 GPL-2.0-or-later WITH exceptions
      1 GPL-2.0-or-later WITH restriction to combine it with a license file and point out its source project, if it gets distributed further
      1 GPL-2.0-or-later WITH restriction to combine it with a license file and point out its source project, if it gets distributed further\n"                 71 LGPL-2.1-or-later
      1 LGPL-2.1-or-later */
      1 LicenseRef-limited-license-see-text-below
vidar:/home/GitHub/YourFritz $

Da sind also NUR 230 Dateien unter einer "reinen" Lizenz GPL-2.0-or-later enthalten (wie gesagt, da kommen auch Dateien aus anderen Repos dazu, in dtc kann man das z.B. gut sehen) und mind. 5 Fundstellen, wo die Rechte aus der GPL-Lizenz durch Zusätze von mir eingeschränkt wurden.

Und daß solche Einschränkungen legitim sind, steht hoffentlich auch nicht in Abrede und das SPDX-Format sieht solche "limitations" ebenfalls explizit vor, siehe die "WITH"-Klausel hier: https://spdx.github.io/spdx-spec/SPDX-license-expressions/

Das meinte ich also durchaus ernst - und die Anzeige in GitHub ist auch nichts weiter als ein Hinweis bzw. erster Anhaltspunkt, wie man bei GitHub auch nachlesen kann: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#disclaimer

Da sehe ich also meinerseits keinen Grund, IRGENDETWAS zu ändern ... ich halte mich (nach meiner Kenntnis jedenfalls) an die "gebräuchlichen Standards". Das Klonen eines Repositorys und dessen Zusammenpacken, damit das dann andere in dieser gepackten Form verwenden können, ist auch eine eher "ungewöhnliche Nutzung", für die man nur wenige gute Gründe finden dürfte.

Alle Argumente, daß man nur so gegen (unbekannte) Änderungen an diesem Repository gefeit ist, sind zwar richtig ... aber dafür muß man eben dessen Inhalt nicht selbst verbreiten, solange es jederzeit auch weiterhin möglich ist, einen älteren Stand "frisch" aus der originalen Quelle zu erstellen. Da stellt sich mir auch nicht ausschließlich die Frage nach den Lizenzbestimmungen, sondern komplett nach dem Sinn des Ganzen. Eine (realistische) "Gefahr", daß so eine Quelle "ganz plötzlich" verschwindet, sehe ich auch nicht bei Repositories bei einem der bekannten Git-Hoster ... solches "Hamstern" fremder Software finde ich sogar sehr befremdlich, solange es keine wirklich plausiblen Gründe gibt für eine Annahme, daß diese Quellen irgendwie versiegen könnten. Das hat ja mit "Forken" nichts mehr zu tun - das gehört dann wieder zu den gebräuchlichen Verwendungen.

Was dabei dann für Unsinn herauskommen kann, sieht man an meinen Shell-Skripten für den EVA-Zugriff. Deren Kopie auf einem (uns beiden bekannten) Download-Server verstößt auch gegen meine Urheberrechte, weil dort in den Dateien eben noch KEINE Kennzeichnungen der Lizenz enthalten waren.

Somit war da also nur dann eine GPL-Lizenz anzunehmen, wenn eine entsprechende Datei beilag und die Lizenzbestimmungen der GPL sehen eben auch vor, daß diese Bestimmungen selbst dann auch immer dazu gepackt werden müssen. Da man dort auch darauf verzichtet hat, ist das im Ergebnis ein Lizenzverstoß - bei den PS-Versionen steht zumindest schon mal mein Header in den Dateien, wo dann auch die Lizenz enthalten ist.

[fda77]

Wenn nicht alles GPL2 ist solltest du es auch nicht dran schreiben. Wo ist das Problem? Schreib halt "ganz viele verschiedene" oder was auch immer hin. Wenn du allein der Author bist kannst du das ja einfach ändern

[fda77]

Ne, es gibt noch Authoren andere. Die müssten zustimmen

[PeterPawn]

So sind 2 ähnliche Dinge an verschiedenen Stellen

Wenn Du da ein weiteres make-Makro erstellen willst, mit dem man den Hash für ein bestimmtes Tag ermitteln kann, dann gerne auch auf diesem Weg. Aber das derzeit vorhandene hat einen anderen Inhalt bzw,. liefert ein anderes Ergebnis ... das ist also keinesfalls dasselbe.

das wäre nämlich der einfachste und schnellste Weg was zu aktualisieren

Und ich habe Dir auch deutlich gemacht, warum das so ohne weiteres nicht geht. Ich benutze für diese Dinge (OpenSource, Freetz oder Freetz-NG) EINEN GitHub-Account, EINEN GPG-Key und EINE Identität. Wenn ich etwas direkt in ein GitHub-Repository für Freetz-NG pushen will, kommt sich das mit meinem eigenen Freetz-Fork ins Gehege und ich habe überhaupt gar keine Lust, unter verschiedenen Identitäten (das mache ich schon zur Unterscheidung OpenSource vs. beruflich) an dieser Stelle zu agieren bzw. zusätzliche Kopfstände machen zu müssen.

Wenn Du Deinerseits das Repo hier so weit aufräumen solltest, daß da bei

This branch is 4059 commits ahead, 470 commits behind Freetz:master.

nicht länger eine Zahl für "behind" steht, dann denke ich darüber ggf. noch mal neu nach. Mein Fork ist jedenfalls nicht "behind" - die 3 Commits aus dem Mai 2021 sind geschenkt, die machen keinen funktionalen Unterschied und wären im Handumdrehen "gemischt", wenn ich das für notwendig erachten sollte - da ergäben sich nämlich auch keine Konflikte, die man erst auflösen müßte und selbst wenn, wären das nur "peanuts".

[fda77]

Und ich habe Dir auch deutlich gemacht, warum das so ohne weiteres nicht geht.

Man kann auch über das Github-Webinterface Änderungen vornehmen

nicht länger eine Zahl für "behind" steht,

Ich sehe keinen Grund weshlab ich mich um commits kümmern sollte, die neu gemacht wurden statt die in NG schon vorhandenen zu übernehmen. Der andere Teil (labor etc) ist überflüssig.

und ich finde da irgendwie Deine "Verlinkung" nicht.

Ich schon, steht oben.

das derzeit vorhandene hat einen anderen Inhalt bzw,. liefert ein anderes Ergebnis ... das ist also keinesfalls dasselbe.

Es könnte auch für Tags funktionieren, genaues weiss niemand

Wenn Du da ein weiteres make-Makro erstellen willst, mit dem man den Hash für ein bestimmtes Tag ermitteln kann, dann gerne auch auf diesem Weg

Ne, will ich nicht. Das an 2 verschiedenen Stellen auf 2 verschieden Wegen zu lösen finde ich nicht gut

[PeterPawn]

Ich schon, steht oben.

Ja, aber wieder mal bist Du offenbar mit Deiner Zeitmaschine umher gereist ... Dein Link steht deutlich NACH meinem Zitat und wenn Du nicht das Zeitgefühl verloren hast, ist das hier drüber Zitierte offensichtlicher Unsinn - wenn Du dann einen Link DANACH angibst, macht ein

ich HATTE das doch verlinkt

einfach keinen Sinn in der deutschen Sprache.

Es könnte auch für Tags funktionieren, genaues weiss niemand

Lesen hilft manchmal auch ... ich zitiere mal aus der Hilfe für ls-remote:

Limit to only refs/heads and refs/tags, respectively.

(https://git-scm.com/docs/git-ls-remote.html)

und da dort bei Dir ja explizit ein --heads steht, sind Deine sibyllinische Anmerkungen dazu eher Wunschdenken - man KANN das zumindest wissen.

Ne, will ich nicht. Das an 2 verschiedenen Stellen auf 2 verschieden Wegen zu lösen finde ich nicht gut

Mach' was Du willst - ich habe meine Argumente vorgebracht und angesichts von Reaktionen wie dieser:

Ich schon, steht oben.

sehe ich nur noch "Bockigkeit" und das muß ich nicht haben. Eine VERNÜNFTIGE Antwort (die denke ich mir verdient zu haben), hätte zumindest noch ausgeführt, wo genau das "oben" stehen soll und den entsprechenden Passus zitiert.

Wenn nicht alles GPL2 ist solltest du es auch nicht dran schreiben. Wo ist das Problem?

Ganz einfach ... ich "schreibe" da gar nichts dran, diese Anzeige wird ganz alleine von GitHub generiert, weil für die oberste Gliederungsebene dieses Repos die GPLv2-Lizenz ("or later") gilt und das nicht etwa, weil ich mir von GitHub eine Lizenz "generieren" ließ, sondern schlicht aufgrund der puren Existenz der Datei LICENSE mit dem Text der GPLv2.

Das enthebt mich der Notwendigkeit, in jedem Unterverzeichnis des Repos, wo diese Lizenz ebenfalls gilt, noch einmal eine gesonderte Kopie der Lizenzbestimmungen vorhalten zu müssen.

In den Verzeichnissen hingegen, wo andere Lizenzbedingungen gelten, sind diese dann auch entsprechend hinterlegt und sogar in einer Form, die man maschinell auswerten kann - man muß das also nicht mal in JEDEM Verzeichnis gesondert lesen ... zumindest nicht, solange es da auch nichts anderes zu lesen gibt.

Und das REICHT auch vollkommen ... es ist nicht mein Problem, die Lizenzen jedem Einzelnen vorzusingen - es ist die verdammte Pflicht und Schuldigkeit eines LIZENZNEHMERS, sich darum zu kümmern, welche Lizenzbestimmungen gelten und diese dann auch einzuhalten. Punkt.

Ich mache das selbst ja auch so ... wie oft habe ich mich schon irgendwo "unbeliebt" gemacht, wenn ich darauf verwiesen habe, daß für die AVM-Bestandteile einer Firmware auch entsprechende Urheberrechte gelten - solange diese nicht durch das Zusammenführen mit anderen Komponenten, deren Lizenzbestimmungen eine Beschränkung DES VERTRIEBS nicht erlauben, außer Kraft gesetzt bzw. "überstimmt" werden (was z.B. für komplette Firmware-Images gilt, aber nicht mehr für einzelne AVM-Binärdateien).

Das kannst Du von mir mehrfach an allen möglichen Stellen lesen ... und das Berücksichtigen der Urheberrechte von anderen gehört für mich zu den Selbstverständlichkeiten in diesem Metier.

[fda77]

Ganz einfach ... ich "schreibe" da gar nichts dran, diese Anzeige wird ganz alleine von GitHub generiert, weil für die oberste Gliederungsebene dieses Repos die GPLv2-Lizenz ("or later") gilt und das nicht etwa, weil ich mir von GitHub eine Lizenz "generieren" ließ, sondern schlicht aufgrund der puren Existenz der Datei LICENSE mit dem Text der GPLv2.

Genau durch die pure Existenz und dass diese existierende Datei die GPL2 enthält gibst du an dass das Repo unter GPL2 steht.
Außerdem hast du in PeterPawn/YourFritz@7235f94 geschrieben "clarify license by adding the GPLv2 text", das war also absicht
Wie kannst du das ändern? -> den Inhalt der Datei ändern und damit die Lizenz, vorher die Mitauthoren fragen.

Ein zufälliges Beispiel: https://github.com/topjohnwu/libsu ist "Apach 2.0"

Ich versteh dein Problem nicht

[PeterPawn]

Ich versteh dein Problem nicht

Warum sollte ich die LICENSE-Datei auf der OBERSTEN Ebene denn entfernen? Für den größten Teil der enthaltenen Software gilt exakt diese Lizenz - die Angabe ist also RICHTIG.

Und an den Stellen, wo das nicht gilt, liegt dann eine andere Lizenz - manchmal sind die Ausnahmen auch nur in den Header-Zeilen der betreffenden Datei(en) erläutert.

Verstehst Du das Prinzip der "Vererbung" von Eigenschaften? Die Lizenzbestimmungen für meine Repos (ich habe ja nur eines herausgegriffen) werden auf alle darin enthaltenen Dateien vererbt, AUSSER an den Stellen, wo das explizit anders festgehalten wurde.

Wo also genau ist DEIN Problem?

Ich bin auch keinesfalls der Einzige, der das so handhabt - gerade dann, wenn ein Projekt aus mehreren Teilen besteht und einige dieser Teile auch andere Lizenzen benutzen (die trotzdem "kompatibel" sind und das heißt nur, daß sich die Bestimmungen sinnvoll ergänzen können und nicht, daß dann jeweils die Bestimmungen mit den "größten Freiheiten" für den Lizenznehmer kombiniert werden müssen), dann ist das "gelebte Praxis", daß solche Teile auch unter anderen Lizenzbestimmungen bereitgestellt werden.

Ich verweise Dich NOCH EINMAL auf die oben schon verlinkte Seite von GitHub zu diesem Thema ... die Anzeige, die GitHub aus dem Vorliegen der Datei auf der obersten Gliederungsebene generiert, ist NICHT VERBINDLICH - es handelt sich nur um einen Einstiegspunkt, an dem dann eben weitere eigene Recherchen ansetzen sollten.

Angesichts der deutlichen Überzahl der Dateien, die unter "GPL-2.0-or-later" von mir (oder von den ursprünglichen Autoren, wenn ich daran nur eigene Änderungen vorgenommen habe) lizensiert werden, ist die Kennzeichnung auf der obersten Ebene absolut gerechtfertigt, zumal sie eben NICHT bedeutet, daß es darunter keine Ausnahmen geben kann.

Es mag ja sein, daß Dir das nicht paßt oder es Dir nicht einleuchtet ... aber andere machen es ebenso - und als Beispiel sei dann mal der Linux-Kernel genannt, der ja sogar eine strikte Beschränkung auf GPLv2 hat:

The common way of expressing the license of a source file is to add the matching boilerplate text into the top comment of the file. Due to formatting, typos etc. these "boilerplates" are hard to validate for tools which are used in the context of license compliance.

An alternative to boilerplate text is the use of Software Package Data Exchange (SPDX) license identifiers in each source file. SPDX license identifiers are machine parsable and precise shorthands for the license under which the content of the file is contributed. SPDX license identifiers are managed by the SPDX Workgroup at the Linux Foundation and have been agreed on by partners throughout the industry, tool vendors, and legal teams. For further information see https://spdx.org/

aus: https://github.com/torvalds/linux/blob/master/Documentation/process/license-rules.rst

[fda77]

Du kannst darüber denken wie es dir passt

[PeterPawn]

Du kannst darüber denken wie es dir passt

Nicht nur das - ich kann das auch entscheiden, welche Teile ich unter welchen Bedingungen für andere lizenziere.

[fda77]

Klar kannst du da, aber solltest dran schreiben was es ist. Hast du ausser mit https://github.com/Freetz-NG/freetz-ng/blob/master/graphics/tagging/pimped.png noch irgend welche Bedenken?

[fda77]

Bist du nun zufrieden? 2d21b6a

[PeterPawn]

Ja (geht doch):

Darauf kann man aufbauen - was aber immer noch nicht heißt, daß ich mich aktiv an einem Projekt beteiligen kann (in "verantwortlicher Rolle"), das keine klare Abgrenzung gg. UrhG-Verletzungen hat (und das meint nicht unsere kleine Diskussion hier drüber, sondern gesetzte Links). Selbst wenn das hier "Hobby" sein mag, kann ich es mir beruflich nicht leisten.

Und mich findet man auch "in persona", wenn man will - spätestens anhand von Domaininhaber-Daten und auch bei AVM kennt man meine "ladungsfähige Adresse". Das ist bei anderen Leuten halt anders ... und damit gehen die auch ein geringeres Risiko ein.

Aber das macht es jetzt einfacher, auch wirklich mal einen PR abzusetzen ... mal sehen, was ich mit dem Kernel-(Ent-)Packer für die GRX-Boxen mache. Den muß ich zwar noch "aufhübschen", aber nachdem ich gesehen habe, daß das immer noch niemand anderes in Angriff genommen hat, wird es vielleicht mal Zeit - sonst sind die Modelle schon wieder vom Markt verschwunden, wenn das irgendwann mal nutzbar wird.

[fda77]

Es haben sich mittlerweile wohl alle daran gewöhnt oder sind zu Openwrt gewechselt. Ich hab zb keine 7590 mehr mit der ich testen könnte.
Es betrifft übrigens alle Kernel ab Version 4, das sollten nicht nur GRX sein
Wenn man will findet man die Daten zu jedem, zur Not über die IP