Vorrei rilasciare una libreria software scritta in un linguaggio di programmazione orientato agli oggetti (Java) basato su classe su un servizio di hosting di codice sorgente basato sul Web , che consente di unire le forcelle del progetto nel progetto principale (GitHub tramite pull richieste). Ho fatto ricerche sul web e ho riflettuto molto su come ottenere la licenza del software. Sono corretto nei seguenti presupposti (da una prospettiva IANAL )?

• Sia LGPL che MPL promuovono la condivisione di modifiche al software con licenza LGPL / MPL utilizzato all'interno di altri progetti software. Invece di richiedere agli utenti della libreria modificata di ospitare un fork separato della libreria, posso promuovere il contributo alla libreria originale (ad esempio tramite richieste pull).

• La differenza principale è come il codice con licenza MPL / LGPL deve essere collegato al progetto. I file di codice sorgente MPL possono essere copiati direttamente in un (eventualmente) progetto software proprietario ( collegamento statico ), mentre il codice concesso in licenza LGPL deve essere collegato in modo dinamico (liberamente collegato al progetto software possibilmente proprietario, in modo che gli utenti finali possano cambiare il software concesso in licenza libreria per un'altra versione della libreria software con licenza).

• Il collegamento dinamico e quindi LGPL impone ulteriori ostacoli per il confezionamento del prodotto software proprietario, senza promuovere più contributi alla libreria di software open source rispetto al collegamento statico (e quindi MPL). C'è una LGPL modificata che consente il collegamento statico.

• Non ci sono altre differenze rilevanti (dal punto di vista IANAL ).

• Le versioni precedenti della licenza non soddisfano le mie esigenze come quelle più recenti.

Come puoi vedere, il mio requisito principale è che le modifiche della libreria software che potrebbero rivelarsi utili al grande pubblico rimangano open-source, senza imporre restrizioni sull'uso della libreria software in un prodotto proprietario.
Non esiste una licenza che richieda che anche le estensioni della libreria software rilevanti per l'opera originale siano rilasciate come open-source, poiché l' ambito del termine rilevante può essere arbitrariamente piccolo / enorme, finendo così come GPL che non può essere utilizzato in un prodotto proprietario (senza rilasciare l'intera fonte).

Sono tentato di usare il LPGL modificato , ma d'altra parte scoraggiato dall'impopolarità. Sulla base dei punti precedenti preferisco MPL.
Domanda: le mie affermazioni precedenti sono corrette? Quale licenza devo scegliere considerando i miei requisiti?

Soluzione: con l'aiuto della discussione nella risposta accettata, scelgo di attenermi alla MPL a causa della popolarità , della libertà di collegamento e perché è una licenza ufficiale, non modificata .

Credo che tu abbia affermato con precisione le differenze tra la Licenza pubblica Mozilla e la Licenza pubblica generale minore GNU , e entrambe potrebbero soddisfare bene le tue esigenze, ma stai saltando la differenza più importante tra le due licenze:

Chi può fare nuove versioni?

Sia la MPL (sezione 10) che la LGPL (sezione 14) includono nella loro licenza il diritto di sostituire la versione corrente con una versione più recente, e non ci sono limiti reali su cosa può andare in quelle licenze. Mentre è altamente improbabile che la Mozilla Foundation o la Free Software Foundation facciano qualcosa di così folle come, diciamo, istituire una clausola che dice "tutti i contributi a questo software diventano di nostra proprietà", non è al di fuori del regno delle possibilità che uno dei le organizzazioni rilasceranno una nuova versione della licenza che non ti piace.

Il che fa emergere un altro punto sull'uso di una "LGPL modificata".

Una licenza modificata non è la stessa licenza!

Sebbene tu abbia una capacità abbastanza sorprendente di specificare i tuoi termini di licenza e, in sostanza, potresti dire "puoi distribuirlo secondo la GPL, ma devi mettere il mio nome nei tuoi crediti e pagarmi l'1% delle entrate generate" , ogni volta che lo fai, stai creando una nuova licenza basata sul lavoro di qualcun altro. Questo significa che NON stai usando MPL o LGPL, stai usando una nuova "licenza mucaho".

Ciò significa che probabilmente non otterrai alcun aiuto dall'autore della tua licenza originale se devi difendere la tua interpretazione della licenza all'interno di un'aula di tribunale, ed è del tutto possibile che possano presentare la causa per dire che la LORO versione dovrebbe essere applicata e non tuo.

Naturalmente, entrambi questi sono punti minori. Anche la "popolarità della licenza" non ha importanza a meno che non ti aspetti che il tuo codice sia incorporato direttamente in progetti più grandi.

Personalmente, penso che l'MPL sia una scelta migliore se ti piace la compatibilità proprietaria, o se la scelta è tra l'effettivo MPL e una diversa licenza che devi modificare manualmente in base alla LGPL. A meno che tu non abbia un motivo per non usare la MPL, scegli qualcosa supportato da una fondazione anziché da una che potrebbe lasciarti in un'aula di tribunale senza alcun aiuto.

La risposta di DougM e AER è giusta. MPLv2 e LGPLv3 con eccezione statica sono gli stessi per quanto riguarda gli eventi che potrebbero innescare il copyleft. Tuttavia, penso che ci manchi un'altra differenza molto importante tra LGPL e MPL. Quando viene attivato il copyleft, il copyleft si applica a:

• per MPL: negli stessi identici file della tua libreria originale
• per LGPL: al "lavoro basato sulla biblioteca" in contrapposizione al "lavoro che utilizza la biblioteca". Quindi la LGPL può potenzialmente estendere il suo copyleft a nuovi file.

Caso limite: l'utilizzo di MPL consente agli utenti di non condividere i propri miglioramenti

MPL è una licenza di copyleft a livello di file. Significa che se qualcuno lo incorpora in un progetto più grande (staticamente o dinamicamente) e apporta una modifica al tuo file, deve solo rilasciare la modifica apportata a questo particolare file.

Se sei preoccupato di mantenere aperta l'integrità della tua base di codice, ci sono casi limite in cui questo effetto copyleft di MPL potrebbe non essere sufficiente.

Ad esempio, qualcuno potrebbe prendere uno dei file principali del progetto, aggiungere "import my_private_new_file" e modificare il metodo principale, ad esempio aggiungendo "my_private_new_file.newAwesomeFeature.run ()" .

In questo modo ha potuto aggiungere nuove funzionalità al tuo progetto rilasciando solo il file principale modificato e mantenendo la logica effettiva della nuova funzionalità sorgente chiusa in "my_private_new_file" .

Avere il file principale nella comunità ti dà solo l'informazione che "hey hai aggiunto una nuova funzionalità" ma non ti consente di incorporare questa nuova funzionalità all'aperto ... Può essere fastidioso se la nuova funzionalità è strettamente in relazione al problema che la tua libreria sta cercando di risolvere.

Ovviamente, questo è un caso limite ed è abbastanza improbabile che qualcuno vorrebbe farlo, ma è un rischio che devi essere consapevole quando usi MPLv2.

La LGPL è scritta per vietare tali comportamenti. Vedere:

• https://www.javalobby.org//java/forums/t15903.html#91819035
• La LGPL mi consente di farlo?

Cito la licenza originale LGPL:

Presta molta attenzione alla differenza tra un "lavoro basato sulla biblioteca" e un "lavoro che utilizza la biblioteca". Il primo contiene codice derivato dalla libreria, mentre il secondo deve essere combinato con la libreria per poter essere eseguito.

Il copyleft si applica solo al "lavoro basato sulla libreria". Ora che cos'è in pratica un "lavoro basato sulla biblioteca"? Lascia spazio all'interpretazione. Il che non è solo una cosa carina in quanto significa rispettare la tua licenza diventa più complicato e quindi spaventoso. Potrebbe portare alcune persone semplicemente a non usare la tua libreria.

In questo senso, LGPL è più restrittivo di MPL, ma anche più protettivo dell'integrità del progetto.

MPL rende più semplice per gli utenti del mondo proprietario riparare la libreria e usarla, pur condividendo la correzione

Un vantaggio per MPL è che se un utente trova un bug nella tua libreria, può risolverlo direttamente nel file, senza dover distribuire tutto il suo codice ma solo fornire la correzione. In pratica, quando distribuisce il suo lavoro a un cliente, può semplicemente fornire un link a un fork del tuo progetto contenente la correzione, ed è bravo.

Usando LGPL, le cose sono più complicate. Se qualcuno crea il tuo progetto, corregge un bug e lo incorpora staticamente nel suo software proprietario, deve distribuire ai suoi utenti il ​​"lavoro basato sulla libreria" sotto LGPL. Il che è un'idea piuttosto oscura, specialmente quando la libreria è staticamente incorporata ... A questo proposito, penso che sia stata la ragione originale per cui non esiste un'eccezione "statica" nella LGPL originale. Rende banale l'identificazione del "lavoro basato sulla libreria": è la libreria dinamica che chiamate nel vostro software proprietario.

Di conseguenza, MPL rende interessante per i rivenditori proprietari l'uso e l'invio di correzioni alla libreria in modo interessante rispetto a LGPL.

Allo stesso tempo, la maggior parte delle volte i fornitori proprietari non hanno le risorse né il tempo per immergersi nella tua complessa libreria e molto probabilmente non li riparerebbero da soli. Preferirebbero aprire un problema sul repository GitHub o inviare un'e-mail nella mailing list e attendere la correzione.

A questo proposito, LGPL applica maggiormente questo tipo di comportamento. Ma è davvero necessario applicare la legge?

Conclusione

Scegliere tra LGPL e MPL è una domanda difficile e, come al solito con la licenza software, dipende dal tuo obiettivo. Entrambe le licenze sono molto simili ma allo stesso tempo estremamente diverse. Sono stati progettati per obiettivi e filosofia molto diversi.

LGPL è stato creato dalla Free Software Foundation per consentire l'uso diffuso delle librerie di software libero nel mondo proprietario, ma tenendo sempre presente l'idea di promuovere il software libero e combattere i software proprietari. Fa tutto parte di una strategia nei confronti della loro ideologia. Vedi: https://www.gnu.org/licenses/why-not-lgpl.html

MPL è una licenza pratica progettata da Mozilla per imporre un qualche tipo di condivisione alla libreria originale, mentre incoraggia ancora le persone a creare software proprietari e componenti aggiuntivi (incluso Mozilla stesso), che è una pratica che la FSF autorizza tramite LGPL ma considera ancora dannoso.

In sostanza, MPLv2 è considerato da molti come una licenza permissiva, mentre LGPLv3 incluso con eccezione statica viene raramente chiamato in questo modo.

MODIFICARE

Ho dimenticato di menzionare qualcosa di importante. LGPLv3 (con o senza eccezione statica) proibisce la tivoizzazione . Potresti pensare che sia un "dettaglio", ma in realtà non lo è, a seconda del tuo obiettivo. Ti interessa la libertà degli utenti? Quindi non è un dettaglio. Ti interessa che la tua libreria possa essere utilizzata sul dispositivo Apple? VLC si preoccupa di più dell'utilizzo , quindi hanno deciso di utilizzare LGPLv2 che non contiene tale restrizione. Allo stesso modo, questo è uno dei motivi per cui Linux continua a usare GPLv2 . MPLv2 inoltre non ha alcuna restrizione di tiviozation, ovviamente in quanto è una licenza creata con in mente la filosofia più "pratica" di Open Source, non l'ideologia di FSF.

Potrebbero esserci altre cose "minori" come questa che mi mancavano.