Perché dovrei rilasciare il mio codice sotto licenza BSD e perché no sotto LGPL? [chiuso]

Ci sono due grandi differenze tra la licenza LGPL e BSD.

Innanzitutto, se si distribuisce una libreria con licenza LGPL, è necessario fornire la fonte. (Questo è leggermente diverso da quello che hai detto.Posso prendere qualsiasi libreria LGPL, apportare modifiche e usarlo internamente, purché non lo distribuisca, non ho bisogno di apportare modifiche che ho reso pubbliche. ho solo bisogno di offrire la mia versione del codice a coloro che distribuisco a, non sono obbligato a contattare lo sviluppatore originale e offrire le modifiche per l'upstreaming.)

In secondo luogo, se distribuisco qualcosa che utilizza una libreria con licenza LGPL, devo consentire agli utenti di sostituire la libreria con qualcosa di compatibile (ad es. la loro raccolta di tale libreria dove sono stati riparati un bug).

Questo secondo punto può essere problematico.

Rende difficile il collegamento statico. Se si desidera che la propria applicazione sia un eseguibile standalone, è necessario fornire le parti che lo compongono, oltre alle istruzioni su come ricombinarlo, in modo che gli utenti possano creare il proprio pacchetto. O almeno offrire una distribuzione alternativa che non sia un eseguibile standalone, ma invece ha la libreria in una forma esterna, sostituibile. Questo peggiora se il tuo processo di compilazione è più coinvolto. Ad esempio, se utilizzo l'ottimizzazione dell'intero programma per ottenere maggiori prestazioni avendo la libreria e il mio codice ottimizzati insieme, allora devo distribuire le mie parti in un modulo accessibile all'ottimizzatore (e quindi in genere molto più facile da invertire -engineer), oppure posso offrire un'esperienza degradata solo per la versione sostituibile. (Anche questo soddisfa i requisiti della LGPL? IANAL, IDK.)

Non tutti i formati di distribuzione sono suscettibili di sostituzione della libreria. Le librerie C # possono avere un "nome sicuro", dove sono firmate crittograficamente. Un'applicazione che fa riferimento a una libreria con un nome sicuro caricherà la libreria solo se l'emittente del certificato di firma è quella che si aspetta. Ciò garantisce che nessuno possa ingannare l'applicazione nel caricamento di codice non affidabile. Ma se è necessario che la libreria sia sostituibile con la sua licenza, non posso farlo. Se firmo usando la mia chiave, gli utenti non possono sostituirla. Se firmo usando una chiave disponibile pubblicamente, qual è il punto? Credo che lo sviluppo di iOS abbia un problema simile.

Non tutti i canali di distribuzione sono suscettibili di sostituzione della libreria. Se costruisco un dispositivo (ad esempio una lavatrice "intelligente") e utilizzo una libreria LGPL nel suo software, ho bisogno di dare all'utente la possibilità di sostituire questa libreria. Cosa comporta questo? Devo dargli la possibilità di prendere un'immagine del firmware, sostituire la libreria all'interno e quindi aggiornare il firmware sul dispositivo con questa nuova immagine. Voglio davvero che i casi di supporto tecnico derivino da questo? Che dire della responsabilità se la lavatrice si comporta in modo grave? Su quale sistema funziona anche la macchina e sono obbligato legalmente a fornire agli utenti gli strumenti necessari per compilare la libreria per questo sistema? Sono autorizzato a farlo, o la licenza che ho ricevuto dallo sviluppatore lo proibisce in primo luogo?

Non tutti i formati di libreria sono suscettibili di sostituzione della libreria. In C ++, è molto comune che le librerie consistano in parti grandi o addirittura completamente in codice template. Questo codice è istanziato con i tuoi tipi concreti in fase di compilazione e integrato nei file oggetto risultanti. Non esiste una libreria correttamente separata, e non c'è modo di usare una libreria sostituita eccetto per ricompilare l'intero programma. Ciò significa che in realtà devi fornire qualsiasi codice sorgente che usi la libreria ai tuoi utenti. A questo punto, c'è poca differenza tra la LGPL e la GPL. (In altre parole, una libreria C ++ per la maggior parte degli header con licenza LGPL è completamente inutile.)

E infine, la LGPL contiene una piccola clausola che limita i termini della licenza che puoi dare alla tua applicazione, e cioè che non deve proibire il reverse engineering e il debug della tua applicazione nella misura necessaria per consentire all'utente di ottenere la sua sostituzione lavoro. Un interessante caso limite qui sarebbe il software che utilizza la protezione da copia includendo un correttore di debugger (una parte del software che tenta di rilevare se è in esecuzione in un debugger e quindi uccide l'applicazione, specificamente inteso a ostacolare gli sforzi per bypassare la protezione dalla copia) . Se la licenza non vieta il debug, ma il programma contiene contromisure tecniche, questo viola la LGPL?

Come potete vedere, la LGPL offre alcune trappole per gli sviluppatori commerciali, motivo per cui le aziende potrebbero spesso essere molto caute nell'usare il codice LGPL nei loro prodotti. Il codice dell'intestazione, il nome solido C # e i problemi di protezione della copia sono stati i motivi per cui abbiamo deciso di non utilizzare alcuna libreria LGPL al mio precedente lavoro.

La prima cosa da tenere a mente è che, per la stragrande maggioranza delle librerie open-source, c'è sempre un solo contributore al codice: il creatore di quella libreria.

Se è una delle tante soluzioni simili e una terza parte trova una limitazione, prenderà seriamente in considerazione il passaggio a un'altra libreria che non ha questa limitazione.

Se è popolare e offre funzionalità uniche, le persone potrebbero richiedere all'autore di aggiungere funzionalità mancanti.

Se è popolare e sei fortunato, altri potrebbero investire nello sforzo di apportare modifiche anche.

Dall'esperienza, sia come qualcuno che ha apportato queste modifiche e sia stata abbastanza fortunata da fare in modo che gli altri abbiano a cuore il mio lavoro da voler contribuire, se fanno quel cambiamento, saranno ansiosi di averlo incorporato nel codice originale . Il motivo è semplice: mantenere un fork separato è un compito arduo poiché ogni modifica dell'originale deve essere costantemente unita, ogni volta che si espone al rischio di un conflitto che deve essere risolto.

Il motivo principale per cui qualcuno dovrebbe seguire la strada alternativa per mantenere una forcella separata, privata, è per ragioni commerciali. Quindi, la licenza entra in gioco. Posso legalmente mantenere questa forcella privata? Se sì, allora fantastico. Se no, allora posso avvolgere il mio vantaggio commerciale attorno alla libreria senza cambiarlo? Sì? Quindi fantastico. Se no, è tempo di correre il rischio e ignorare la licenza o trovarne un'altra / scriverla da sola. Ancora una volta, "è un duro lavoro" entra in gioco con l'ultima alternativa: pubblicare la propria versione, evidenziando le modifiche, in quella libreria.

Quindi, supponendo che quanto sopra valga per la maggior parte delle persone (e non ci sono davvero prove empiriche per confermarlo o negarlo), allora usare la licenza LPGL non aumenterà le possibilità che qualcuno lo aiuti a mantenerlo. Inoltre, le organizzazioni commerciali sono spesso nervose di LGPL. È troppo vicino ad altre licenze GPL e potrebbe non voler assumere un avvocato per verificare che sia conforme alla licenza. Quindi è più economico e semplice vietare l'uso delle librerie LGPL, riducendo la tua potenziale base di utenti.

Il motivo principale per cui le persone usano le licenze * GPL, è perché vogliono controllare ciò che fanno gli altri con il loro codice, piuttosto che incoraggiare i contributi. Quindi, se i contributi incoraggianti sono la tua principale preoccupazione, segui la licenza BSD e metti in pratica lo sforzo di comunicare il fatto che accetti i contributi degli altri.