( HINWEIS : Diese Frage beinhaltet das Wort "Lizenz". Aber lassen Sie es uns klarstellen: Diese Frage lautet nicht und fragt nach Lizenzierungsratschlägen die Dateibenennungsanforderungen von "Software-Tools, die häufig von Programmierern verwendet werden": Github und CRAN. Diese Frage könnte genauso gut bei README-Dateien stehen. Die bloße Verwendung des Wortes "Lizenz" scheint die Leute glücklich zu machen mit ihren engen Stimmen.)
Ich habe ein R-Paket, dessen Code ich gerne auf Github behalten möchte.
Gemäß den Anforderungen von R (siehe hier für einen Hinweis zu Template-Lizenzen), habe ich in meiner DESCRIPTION -Datei die Zeile:
Und meine LICENCE -Datei enthält nach Bedarf die MIT-Vorlage:
Github hat die Lizenzierung nur anhand der Datei LICENSE ermittelt, die es mir erlaubte, den MIT-Text in LICENSE zu belassen, damit Github ihn und das CRAN-Template in LICENCE erkannte, so dass CRAN es erkennen würde es. Bei diesem Ansatz wurde .Rbuildignore verwendet, um den Github LICENSE vor CRAN zu verbergen.
Aber jetzt ist eine Dunkelheit auf das Land gefallen: Github schaut auf beide LICENSE und LICENCE . Wenn man sie anders findet, gibt sie den Versuch auf, die Lizenz des Projekts zu bestimmen.
Daher ist es nicht möglich, die MIT-Lizenz oder andere lizenzierte Lizenzen so zu verwenden, dass sie sowohl CRAN als auch Github erfüllen.
Das Umbenennen meiner CRAN-Lizenzvorlagendatei von LICENCE nach LICENCE.template würde das Problem beheben, aber dann beschwert sich CRAN über eine nicht standardmäßige Datei.
Ich könnte eine CRAN-Lizenzvorlagendatei aus dem git-Repo auslassen, aber dann opfere ich die Versionskontrolle nicht aus Zweckmäßigkeitsgründen.
Gibt es eine Problemumgehung?
Mein aktueller Ansatz basiert auf Thomas 'Kommentar wie folgt:
Die Datei LICENCE enthält die MIT-Template-Lizenz gemäß den CRAN-Anforderungen. Es ist jetzt in .gitignore aufgeführt, damit es nicht mit Github verwechselt wird.
Die Datei LICENSE enthält die tatsächliche MIT-Lizenz gemäß Githubs Anforderungen. Es ist nicht in .Rbuildignore aufgeführt, damit es nicht mit CRAN verwechselt wird.
Natürlich ist dies keine ideale Lösung, da jetzt weder CRAN noch Github die gesamte Codebasis genau archivieren. Insbesondere wenn der Code von Github erworben wird, ist es nicht in einem Zustand, in dem es erlaubt wäre, ihn zu CRAN hochzuladen. Wenn der Code von CRAN erworben wurde, wäre es lediglich nicht kooperativ, ihn auf Github zu veröffentlichen (da Github die Lizenz nicht ableiten würde).