Open cagix opened 3 months ago
@tgrothe Es gibt bestimmt Gradle-Plugins, die die gezogenen Dependencies und auch deren Lizenzen auflisten können.
Kannst bitte bei Gelegenheit mal schauen, ob Du da was findest?
@cagix
https://github.com/jk1/Gradle-License-Report kann dies:
Einfach nur id 'com.github.jk1.dependency-license-report' version '2.6'
in der top build.gradle
hinzufügen, dann kann mit ./gradlew clean generateLicenseReport
ein Report erstellt werden, der in etwa wie folgt aussieht:
Wenn ich soll, kann ich einen Pull-Request im dungeon erstellen.
Zusatz: Das Ganze hätte folgende Struktur
Wir könnten dann schauen, ob es Lizenzen gibt, die mit unserer Lizenz nicht vereinbar sind ... was ich aber nicht denke, weil die MIT Lizenz ja etwa nur eine schwächere Form darstellt. Ich bin mir aber nicht ganz sicher.
@cagix
https://github.com/jk1/Gradle-License-Report kann dies:
ist das das einzige plugin? ist es noch aktiv? gibt es irgendwo einen überblick über alternativen, ggf. mit pro/kontra?
Wenn ich soll, kann ich einen Pull-Request im dungeon erstellen.
das wäre gut.
bitte im ersten kommentar für den pr erstmal den text von hier (erster kommentar) übernehmen, das kürzen wir dann noch. zusätzlich eine kurze erklärung, warum gerade dieses plugin.
Zusatz: Das Ganze hätte folgende Struktur
das sieht gut aus!
die frage ist nur: das muss dann auch jedesmal neben das jar gelegt werden oder sogar noch mit in das jar integriert werden?
apache sagt beispielsweise, dass man den lizenztext und die notice "mit ausliefern" muss. vermutlich müssen wir beides machen: im repo den teil aus dem reports-ordner rüberkopieren und im jar den inhalt mit reinbauen lassen.
das kopieren müssen wir manuell machen. das einbauen könnte der jar-task mitmachen. kannst du das bitte entsprechend mit ergänzen?
Wir könnten dann schauen, ob es Lizenzen gibt, die mit unserer Lizenz nicht vereinbar sind ... was ich aber nicht denke, weil die MIT Lizenz ja etwa nur eine schwächere Form darstellt. Ich bin mir aber nicht ganz sicher.
ja, das ist der nächste schritt. mit ist sehr "schwach" bzw. "permissive", aber trotzdem kann ein im ausgelieferten produkt (unserem starter.jar) eingebauter baustein mit einer entsprechenden lizenz erzwingen, dass man alles (auch den starter.jar) unter diese lizenz stellt. wenn ich mich richtig erinnere, wäre das beispielsweise bei verwendeten bibliotheken mit gpl so ...
Hi @tgrothe, ich klinke mich mal ein, da ich gerade das gleiche Problem für den DSL IDE support mit LSP in meinem Forschungsprojekt habe.
ist das das einzige plugin? ist es noch aktiv? gibt es irgendwo einen überblick über alternativen, ggf. mit pro/kontra?
Ich habe noch ein weiteres gradle license plugin ausprobiert, welches neben html auch markdown reports generieren kann. Es ist jedoch schlechter gepflegt (1 Jahr keine Anpassung zu letzter Woche bei dem was @tgrothe gefunden hat) und listet die indirekten Abhängigkeiten nicht auf.
Gerade gesehen https://github.com/jk1/Gradle-License-Report kann auch ein Markdown Dokument erstellen:
licenseReport {
renderers = arrayOf(InventoryMarkdownReportRenderer())
}
@Ironeer Danke für den Input!
@tgrothe Dann sollten wir es mit dem Ding versuchen.
Im Dungeon haben wir unseren Code unter MIT gestellt und streng darauf geachtet, keine externen Artefakte irgendwelcher Art ins Repo einzubinden (bzw. im Falle der Texturen hier eine separate Lizenz zu notieren).
Wenn wir das Projekt bauen, werden aber sämtliche Dependencies aufgelöst und in die Starter.jar integriert. D.h. wir müssen (wenn wir das Starter.jar öffentlich bereitstellen) hier eine Auflistung der Dependencies und ihrer Lizenzen vornehmen. Und noch mehr: Wir müssen auf Kompatibilität mit unserer MIT-Lizenz prüfen - wenn eine verwendete Dependency unter GPL o.ä. steht, sind wir verpflichtet, das gesamte damit erstellte Produkt auch wieder unter GPL zu stellen!
Das betrifft vor allem das Dungeon-StarterKit!
Bis das geklärt ist, nehme ich das StarterKit-Repo offline.
(betrifft auch https://github.com/Dungeon-CampusMinden/Dungeon/discussions/1394)