Dalle FAQ di GPL (ma il consiglio è applicabile a tutte le licenze):
Perché la GPL richiede l'inclusione di una copia della GPL in ogni copia del programma?
Includere una copia della licenza con il lavoro è vitale in modo che chiunque ottenga una copia del programma possa sapere quali sono i suoi diritti.
Potrebbe essere allettante includere un URL che si riferisce alla licenza, anziché alla licenza stessa. Ma non puoi essere sicuro che l'URL sarà ancora valido, tra cinque o dieci anni da oggi. Tra vent'anni, gli URL così come li conosciamo oggi potrebbero non esistere più.
L'unico modo per assicurarsi che le persone che hanno copie del programma continuino a essere in grado di vedere la licenza, nonostante tutte le modifiche che accadranno nella rete, è di includere una copia della licenza nel programma.
(enfatizzare il mio)
Nel momento in cui il sito che ospita la licenza diminuisce o modifica i relativi percorsi URL, le persone che dispongono di copie del software non possono più verificare quali diritti possono esercitare in sicurezza. Supponiamo che tu possa in qualche modo garantire che quell'URL esatto sia sempre online: la possibilità per gli utenti di verificare che il loro uso del tuo software sia legale dipende ancora dalla possibilità di connettersi a quel particolare URL. Sebbene questo requisito possa non essere oneroso nella tua particolare città / nazione / pianeta, potrebbe essere oneroso altrove. Non è necessario imporre questo requisito, soprattutto quando la soluzione alternativa (incluso il testo completo della licenza) è banale.
Potresti rispondere a questa lamentela dicendo: "E allora? Se l'URL scende o non è accessibile, un descrittore inequivocabile come" GNU GPL v3 "dovrebbe essere sufficiente. Le copie full-text della GPL sono abbondanti; gli utenti possono cercare la licenza stessa ". Vengono subito in mente alcuni problemi:
Questo non generalizza agli identificatori di licenza che sono meno chiari (viene in mente la frase "licenza BSD").
Ciò non si generalizza bene con le licenze meno comuni o personalizzate (viene in mente "GPL con eccezioni di collegamento": quali eccezioni di collegamento?). Quanto deve essere comune una licenza prima che sia ragionevole aspettarsi che un utente la trovi in modo affidabile per nome?
Ciò richiede comunque che gli utenti dispongano di una connessione Internet, il che potrebbe non essere il caso, anche se avevano una connessione nel momento in cui hanno ottenuto il software. (E potrebbero non aver avuto accesso a Internet quando hanno ottenuto il software: "l'età del CD" non è ancora terminata in molte parti del mondo. Come caso aggiuntivo, si considerano le popolazioni nazionali che hanno un accesso a Internet diffuso ma ne censurano gran parte .) Una conseguenza del software liberamente ridistribuibile è che un destinatario potrebbe non ricevere una copia del software direttamente da te o attraverso un canale di distribuzione inizialmente previsto.
Un ultimo argomento contro i collegamenti di licenza è indicato nel commento di MichaelT di seguito: potrebbe consentire di modificare in modo dinamico, retroattivo la licenza. Questo potrebbe essere fatto intenzionalmente, ma potrebbe anche essere fatto per caso, se si modifica la licenza tra le versioni del software, ma si utilizza lo stesso collegamento di licenza per entrambe le versioni, rendendo così obsoleta la vecchia licenza. Un tale passaggio aggiungerebbe difficoltà per le persone che devono dimostrare di aver ottenuto la loro copia precedente con una licenza diversa rispetto alla versione corrente.
Quindi perché devo mantenere la licenza nella radice del progetto?
Io non sono un avvocato, ma non ho mai visto alcun argomento convincente che non c'è bisogno di mantenere le licenze nella radice del progetto. Perfino la GPL, che specifica che la licenza deve accompagnare ogni copia dell'opera, tace su come deve accompagnare l'opera. (Ciò può essere dovuto al fatto che la GPL potrebbe essere applicata in contesti non software, in cui il concetto di "directory radice" non è significativo.)
Mantenere la licenza nella directory principale è probabilmente una buona idea , perché massimizza la probabilità che l'utente vede, e quindi riduce al minimo sia la frustrazione degli utenti e la probabilità di denunce contro di voi per aver cercato di nascondere la licenza in una directory oscura. Se si dispone di molte licenze, potrebbe essere più sensato inserirle tutte nella propria cartella e includere un progetto README ovvio che contenga percorsi di file per trovare la licenza per ciascun componente.
Inserire la licenza nella directory root è una pratica utile anche perché può chiarire le licenze dei moduli con licenza diversa rispetto al lavoro nel suo insieme. Supponiamo che il mio progetto FooProj utilizzi il modulo autonomo BarMod. FooProj potrebbe essere concesso in licenza GPL, mentre il modulo autonomo potrebbe essere concesso in licenza MIT. Quando apro FooProj per la prima volta, vedo una copia della GPL nella radice e capisco che il lavoro nel suo insieme è concesso in licenza GPL. Quando scendo nella cartella per BarMod, vedo lì un nuovo file di licenza e capisco che il contenuto di questa cartella è concesso in licenza MIT. Certo, questo è solo un aiuto utile; dovresti sempre indicare esplicitamente la licenza dei tuoi moduli in un file README, AVVISO o simile.
In breve, l'utilizzo del file root è una questione di praticità e chiarezza. Non ho visto alcun testo di licenza open source legalmente vincolante che lo richieda, né conosco alcun motivo per cui sarebbe legalmente richiesto. La licenza dovrebbe essere ragionevolmente facile da scoprire per il destinatario; includere la licenza nella radice del progetto è sufficiente, ma non necessario, per soddisfare questo criterio.