Dichiarazione di più licenze in un progetto GitHub

Per anni, sono stato un grande fan di mettere licenze su cose condivise online per rendere più facile agli altri determinare se e come possono riutilizzare tali cose. Prima che GitHub iniziasse a "spingere" delicatamente i propri utenti affinché includessero i file LICENSE nei loro repository, non sapevo davvero come farlo al meglio con il codice, in particolare il codice condiviso pubblicamente su GitHub! - ma da allora ho provato a fare buon uso dei file LICENSE.

Ora mi trovo nella situazione in cui ho lavorato su un piccolo progetto con altre persone, che richiede la menzione di diverse licenze (a causa di codici e librerie di terze parti e file non di codice). Mentre i miei partner affrontano la questione in modo piuttosto "sciatto" - mi è stato suggerito di "mettere il codice online così com'è, nessuno se ne occuperà", preferirei farlo correttamente. Il problema è: non so come si debba fare menzione di diverse (diverse) licenze su GitHub.

Ho visto diverse soluzioni su GitHub, motivo per cui è difficile per me giudicare se questa risposta a una domanda leggermente diversa è autorevole. Quello che mi piacerebbe sapere è quale dei seguenti - se ce ne sono - è il modo più comune o se ci sono altri modi aggiuntivi per farlo.

Crea un singolo file LICENSE e inserisci le descrizioni di tutte le diverse licenze. ( Domande : dovrebbero essere inserite in un ordine particolare? Avrei iniziato il file con la menzione dei nomi di tutte le licenze contenute, per una migliore visione d'insieme)?
Creare un file di licenza per ogni licenza utilizzata e loro un nome LICENSE.md, LICENSE.LibNameA.md, LICENSE.AssetsB.mdecc come suggerito nella risposta collegato. ( Domanda : la denominazione si baserebbe sui nomi dei progetti? Non sui nomi delle licenze? Se avessi usato più di una licenza per materiale autoportante, le avrei menzionate tutte in "principale" LICENSE.md? In caso contrario, cosa farei invece?)
Crea due file di LICENZA : uno che elenca la licenza o le licenze per i contenuti "principali", ovvero tutto il codice / gli asset da lui stesso creati; uno per tutti i materiali di terze parti. ( Domande come sopra : esiste uno schema di denominazione particolare da utilizzare e un ordine in cui elencare i materiali di terze parti?)

Infine, se ho compreso correttamente le varie spiegazioni e progetti di GitHub riguardanti l'API delle licenze, nel determinare la licenza di un repository verranno presi in considerazione solo i file LICENSE "principali" (anche se non sono stato in grado di capire quale licenza sarebbe stata scelta se ne fossero citati diversi).

licensing github

— Kay
fonte

Quindi avere quindi un file README e uno o più file di LICENZA. Questa non è scienza missilistica.

— Robert Harvey,

Per quanto riguarda la pagina collegata: non ha nulla a che fare con la distribuzione dei file di licenza, ha a che fare con l'API delle licenze di GitHub che determina / riporta sulla licenza di un repository. Come mi è stato chiesto sulla licenza / l'utilizzo di file di licenza su GitHub specificamente, non open source o git, in generale, il modo in cui un progetto open source è 'ritratto' per essere concesso in licenza in là è troppo rilevante. "Questa non è scienza missilistica" non è particolarmente utile, a proposito, esp. non nel contesto della mia domanda focalizzata su GitHub.

— Kay,

Potrei suggerire che il tuo README ha una sezione sulle licenze, semplicemente affermando che ci sono più licenze e informando per ogni licenza, il nome del file LICENSE in cui si trova?

— Erik Eidt,

@immibis Ne sono consapevole e non è affatto quello che la mia domanda riguardava. In particolare, stavo chiedendo una risposta su "qualunque modo abbia più senso per gli umani" (su: GitHub).

— Kay,

@immibis: "Nessun compilatore lo leggerà" - il problema è che in senso stretto, questo non è vero per Github. Github utilizza uno strumento automatico per determinare la "licenza" applicata ai contenuti del repository. Il nome della licenza così determinata verrà quindi visualizzato nella barra del titolo del repository, insieme ad alcune informazioni molto più generali che forniscono ai visitatori un'impressione di base del progetto (ad es. Numero di collaboratori e rilasci).

— OR Mapper

Risposte:

Puoi usare qualsiasi meccanismo per includere quelle licenze che ti piacciono, a condizione che diventi chiaro per un visitatore del tuo progetto quale licenza è applicabile a quale parte del progetto.

La mia preferenza sarebbe:

Metti ogni libreria di terze parti che usi in una sua directory. Questa directory dovrebbe contenere tutti i file che fanno parte della distribuzione della libreria, inclusi i file di licenza e readme.
Nel tuo file di licenza, fai riferimento solo alla licenza del tuo codice
Nel file Leggimi del progetto, menziona le librerie di terze parti che utilizzi e in quale licenza è distribuita ciascuna libreria. Per i dettagli completi sulla licenza, consultare il file della licenza nella directory della libreria.

— Bart van Ingen Schenau
fonte

Come gestiresti il tuo file LICENSE in caso di doppia licenza dei propri contenuti in questo scenario? Vale a dire se hai usato licenze diverse per parti diverse del progetto (codice rispetto ai file multimediali) o se volevi distribuire il tuo codice con due (o più) licenze software diverse? Inserire informazioni aggiuntive nel README ha molto senso ed è quello che farei anche io, ma sono particolarmente interessato a come gestire i file LICENSE su GitHub (che, ai miei occhi, sono incoraggiati a dare ai visitatori / spettatori di il progetto una rapida panoramica).

— Kay,

Se (parti) del mio codice hanno una doppia licenza, aggiungerei due (o più) file di licenza al progetto, uno per ogni licenza, e chiarire nel file readme quale licenza si applica in tal caso.

— Bart van Ingen Schenau,

Bart, grazie per aver condiviso come lo faresti, è molto più utile di alcuni dei commenti che ho ricevuto. :) Nel frattempo ho effettivamente contattato GitHub a riguardo e lascerò questa domanda aperta per ora nel caso in cui qualcosa ne venga fuori.

— Kay,

Quando ricevi una risposta da Github, pubblica tali informazioni come risposta automatica a questa domanda.

— Bart van Ingen Schenau,

Lo farò sicuramente se per loro va bene dato che potrebbe essere interessante sapere anche per gli altri!

— Kay,

In una presentazione dei creatori di SPDX ( diapositiva 12 ), è molto chiaro:

Contenuto di LICENSE:

Apache-2.0 OR GPL-2.0-or-later

È quindi possibile aggiungere altri due file di LICENZA: LICENSE.Apache-2.0e LICENSE.GPL-2.0-or-later.

In tutti i casi, README.mddovrebbe contenere un identificatore di licenza SPDX :

SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later

Puoi farlo così:

## License

This work is dual-licensed under Apache 2.0 and GPL 2.0 (or any later version).
You can choose between one of them if you use this work.

`SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later`

Nota che Apache-2.0 OR GPL-2.0-or-latere Apache-2.0 AND GPL-2.0-or-laterfa una grande differenza. Il primo significa che l'utente può scegliere tra entrambi (che è il caso normale!) E il secondo indica che l'utente deve rispettare entrambe le licenze. Vedi anche le licenze multiple su Wikipedia.

Si noti che sto usando il nuovo (dal 2017-12-28 ) SPDX License List 3.0 qui. Le versioni del 2017 avevano l' GPL-2.0identificatore di GPL 2.0, ma non era chiaro se ciò significasse "solo GPL 2.0" o "GPL 2.0 o versione successiva".

— koppor
fonte

Alla fine ho contattato direttamente l'assistenza GitHub per quanto riguarda la mia domanda e mi hanno detto che era giusto citarli se avessi chiarito che le loro risposte erano intese solo come suggerimenti, non raccomandazioni.

Il nostro team non ha particolari consigli da offrire in questo momento, ma ci assicureremo di chiedere in giro e aggiornarti se abbiamo qualcos'altro da condividere!

La loro risposta originale aveva quanto segue da offrire:

Un suggerimento è di avere un file LICENSE per la maggior parte del codice e aggiungere il testo delle licenze per il resto dei materiali di terze parti nel file README.

Un altro modo è che ogni percorso abbia il proprio file LICENSE quando ha senso. Quindi se, ad esempio, il tuo repository ha il seguente percorso: libs / awesome-lib-v2 / potresti avere libs / awesome-lib-v2 / LICENSE.

In quest'ultimo caso, potresti menzionarlo nel file README e / o nel file LICENSE nella tua radice.

Puoi anche considerare di utilizzare solo un file LICENSE nella radice del tuo repository e aggiungere sottosezioni per qualsiasi materiale, codice, ecc. Di terze parti.

— Kay
fonte