Perché devo mantenere la mia licenza software open source nella radice?


10

Quasi tutte le licenze software open source richiedono (o almeno gli avvocati generalmente suggeriscono di richiedere) agli utenti di includere la licenza completa nella radice del progetto che stanno proteggendo.

Un avvocato con cui ho parlato suggerisce che questo è un retaggio dell'era del CD, quando era necessario includere una licenza completa in una custodia.

Ma oggi viviamo nell'era delle nuvole. Perché, ad esempio, non posso semplicemente ospitare la licenza completa sul mio sito Web e includere il titolo + URL di quella licenza nell'intestazione dei miei file di origine?

Bonus: se si concorda generalmente che le licenze stabilite devono essere mantenute intatte nella radice, perché l'OSI di FSF non ha approvato una licenza a cui si può fare riferimento tramite URL e cosa impedisce a qualcuno di crearla?


4
Un problema che viene in mente è che gli URL possono cambiare o essere interrotti.
Aaron Kurtzhals,

6
'Internet non è onnipresente' sarebbe la ragione più ovvia (anche se qualcuno ha Internet quando scaricano il tuo software, potrebbe non essere disponibile quando vogliono estenderlo / modificarlo).
TZHX

9
Stai chiedendo perché TUTTA LA LICENZA DEVE ESSERE INCLUSA nella radice, o perché l'intera licenza deve essere inclusa NEL ROOT?
DougM,

Solo sottolineando che qui stiamo parlando di una falsa dicotomia; Ti chiedi perché la licenza deve essere nella directory principale e perché non può essere online in un URL? C'è una terza opzione che nessuno è menzionato; la licenza è in bundle con il software ma in una directory "docs" o qualcosa del genere e il commento nell'intestazione dei file di codice lo riflette. Sono d'accordo con i buoni motivi dati perché la Licenza dovrebbe essere inclusa nel software, ma ciò non si ferma in una directory di documenti.
James,

4
Il motivo è quasi sempre alla radice è quindi è facile da trovare. Quando scarico il tuo progetto, sfoglio il root e una delle prime cose che vedo è la licenza. Semplice come quello
JohnL

Risposte:


24

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:

  1. Questo non generalizza agli identificatori di licenza che sono meno chiari (viene in mente la frase "licenza BSD").

  2. 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?

  3. 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.


3
Considera anche la possibilità di collegarti a un sito remoto per site.com/foo/license.txt che hai ottenuto con una licenza BSD, ma da allora è stato concesso in licenza con GPL v3 e questo è site.com/foo/license. txt ora contiene. Ma la versione che hai scaricato ha diritti diversi.

Ho contrassegnato questa risposta corretta in quanto sembra esporre la saggezza convenzionale e legale in merito alle licenze OSS. Detto questo , questo pensiero mi sembra un po 'paranoico per questo mondo di backup, controllato in base alla versione in cui viviamo. Non sono sicuro che il rischio di manomissione del contenuto degli URL canonici sia maggiore del rischio che qualcuno elimini accidentalmente una parte di una licenza contenuta nella radice. E anche se il rischio è maggiore, sono scettico sul fatto che sia così grande da costringere gli sviluppatori a includere licenze complete nel loro software, al contrario, per esempio, citando licenze ospitate esternamente nei commenti di codice.
samthebrand,

Cordiali saluti, forse un segno di cose a venire per le licenze OSS: Creative Commons 4.0 consente ai licenziatari di collegarsi a una pagina separata che include informazioni di attribuzione.
samthebrand,

6

Ma oggi viviamo nell'era delle nuvole. Perché, ad esempio, non posso semplicemente ospitare la licenza completa sul mio sito Web e includere il titolo + URL di quella licenza nell'intestazione dei miei file di origine?

Esistono licenze che lo consentono. Apache 2.0, ad esempio. Apache 2.0 richiede solo che ogni file di origine contenga una piccola intestazione che punta all'URL canonico della licenza di Apache 2.0. Non è necessario riprodurre la licenza completa nella struttura dei sorgenti.

Dalla stessa licenza di Apache 2.0:

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

Penso che l'appendice sia incompleta o almeno funzioni nel presupposto che tu stia già includendo una copia della licenza. Dal testo 2.0 stesso , durante la distribuzione dell'opera con licenza Apache:4.(a) You must give any other recipients of the Work or Derivative Works a copy of this License;
apsillers

3

Non è necessario che sia nella radice del progetto. È semplicemente il luogo più comune e quindi il primo posto in cui le persone cercheranno la licenza. Del resto, anche se non fosse comune, è comunque probabile che il primo posto in cui la gente guarderà. Poiché esiste la licenza per informare, nascondere le informazioni non ha molto senso.

Se lo nascondi dietro un URL, non esiste alcuna garanzia assoluta che tale URL sarà sempre disponibile. Se si tratta di un file nella radice del progetto, per definizione sarà sempre disponibile.

In breve, questo è il posto più efficace e più facile da usare per dirlo.


La radice del progetto è il primo posto in cui cercare: è la parte superiore dell'albero, radice della gerarchia di cartelle. Tutta la documentazione di livello superiore dovrebbe andare lì: readme, licenza, ecc. Questi file possono indirizzare il lettore a scavare più a fondo in altre parti del progetto, ma la radice è il primo posto in cui cerco qualcosa.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.