Sta mettendo la licenza nel tracker dei problemi ok o è ancora meglio che metterla in un singolo file?

C'è una differenza fondamentale tra un tracker dei problemi e lo stesso repository:
Il tracker dei problemi non è distribuito con il repository

Quando si scarica la libreria o si fa un git clone https://github.com/jsmith/acme , la licenza che la libreria e il codice sono distribuiti sotto deve essere lì . Considera la situazione in cui qualcuno ha avuto il codice su Google Code o Source Forge con la licenza nel tracker dei problemi laggiù e poi ha migrato il progetto su github ... e non c'è più traccia di un file di licenza.

In particolare con GitHub e la sua cultura del biforcarsi, si dovrebbe anche guardare a ciò che si vede quando si scarica o si clona da una forcella . Non c'è nemmeno un accenno a un problema che contenga la licenza nel codice biforcato. Del resto, la fork avrebbe potuto abilitare i suoi propri problemi lì e rivendicare una licenza WTFPL su di essa (chiunque scaricasse dal fork e andasse a https://github.com/sjane/acme/issues/97 accennato da qualcuno come contenente la licenza in esso potrebbe vedere qualcosa di completamente diverso dal MIT).

La licenza deve essere distribuita con la libreria e i file sorgente. Altrimenti non c'è alcuna licenza su di loro e rende il reparto legale piuttosto nervoso.

Inoltre, i tracker dei problemi non sono legati a una revisione. Considerare se jsmith in seguito decide di passare da MIT a GPL (come unico autore, perfettamente accettabile). E ora ... qual è la licenza? C'è un problema qui che dice il suo MIT e un altro lì che dice la sua GPL. Se clino dalla revisione 1, che licenza è sotto? E se clonassi dalla revisione 2?

L'unico modo per risolvere questo problema è se la licenza fa parte della distribuzione stessa. La sua pubblicazione in un tracker dei problemi non identifica in realtà la licenza a cui è sottoposta una determinata revisione. Né la pubblicazione in un tracker dei problemi mi consente di ridistribuire il codice sotto la licenza I (potrebbe averlo) ricevuto quando il tracker dei problemi è scomparso.

Probabilmente dipende da come intendi distribuire il tuo software, ma mi aspetto che non sarà molto utile, per non dire altro.

Normalmente, il software libero è distribuito come archivi del codice sorgente. (Altri progetti - o tu stesso - potrebbero prendere in considerazione questi archivi e creare file di distribuzione "installabili" per i rispettivi gestori di pacchetti.) Se distribuisci il tuo software in questo modo, disponi delle informazioni sulla licenza da qualsiasi altra parte ma posizionati in modo prominente nella sorgente l'archivio stesso è estremamente inutile. Essenzialmente, rende l'archivio di origine inutile per chiunque sia serio sul copyright perché non ha modo di dimostrare che i file nell'archivio sono gli stessi del repository oltre a controllare direttamente il repository e fare una diff.

Alcuni progetti non creano archivi di origine, ma piuttosto chiedono alle persone di controllare direttamente il loro repository. Per un progetto di questo tipo, potrebbe fare meno male posizionare il file di licenza da qualche altra parte, ma non riesco ancora a vedere alcun vantaggio di fare ciò.

Da un punto di vista legale, non è probabile che ti sparerai ai piedi con questo approccio - cioè, a meno che non contenga fastidiosi potenziali utenti che sparano ai piedi. Se non mi viene data una licenza per fare X con il tuo software, allora devo presumere che non è libero e non devo fare X con esso. (Dove X è fondamentalmente qualcosa di interessante che le persone vogliono fare con il software.) Naturalmente, se non rendi chiaro quale sia la licenza del tuo progetto, potrebbe ricadere su di te se i potenziali violatori possono sostenere che presumevano giustamente che la licenza fosse Y quando si pensa che fosse Z in realtà. Ma a meno che tu non crei l'impressione che la licenza possa essere Y , nessuno deve supporre questo perché i lavori senza licenza sono impostati su "tutti i diritti riservati".