Confronto delle licenze open source

Breve : questa guida dettagliata offre un confronto delle licenze Open Source efficace. Con le licenze Open Source spiegate qui, dovrebbe aiutarti a scegliere la giusta licenza Open Source per il tuo progetto.

Quindi, stai lavorando a quel nuovo fantastico progetto per un po 'e ora sei pronto per fare il passaggio critico da closed source a open source .

Non sembra molto più lavoro che pulire i sorgenti e la cronologia dei commit prima di spingere il repository su GitHub o Bitbucket ... ... fino a quando non viene fuori la domanda della Licenza. Ci sono così tante scelte disponibili. Quale scegliere? E hai davvero bisogno di una licenza, dopo tutto?

La risposta breve a quest'ultima domanda è semplice: Sì, hai davvero bisogno di una licenza. Per quanto riguarda la licenza di cui hai bisogno, posso persino dare una risposta più breve: dipende .

Ma se sei serio riguardo al tuo progetto, probabilmente vorresti un po 'più di dettagli. Quindi leggi avanti - e ricorda: stai entrando in territorio di guerra santa ora!

Ho bisogno di una licenza? E che cos'è una licenza, dopo tutto?

Una Licenza è un permesso ufficiale concesso dal proprietario di qualche Opera (il "Licenziante") ad altre persone (il "Licenziatario") e stabilisce come il Licenziatario può utilizzare il Lavoro del Licenziante.

Questo assume la forma di un contratto, entrambe le parti devono essere d'accordo. Al giorno d'oggi, l'accettazione è piuttosto implicita: semplicemente usando un po 'di lavoro, si è ritenuto che sia d'accordo con la sua licenza d'uso.

Solo per fare chiarezza, quando rilasci il tuo lavoro, il Licenziante sei tu . E il licenziatario, chiunque usi il tuo codice. A grandi linee, questo include due categorie principali: sviluppatori e utenti finali .

E per aggiustare alcuni termini di vocabolario, modificando il tuo Lavoro, un licenziatario sta creando quella che viene chiamata un'opera derivata. Non tutte le licenze concordano però se l' uso del tuo Lavoro in un lavoro più ampio qualificherà quest'ultimo come Lavoro derivato o meno. Come vedrai di seguito, alcune licenze riguardano specificamente questi problemi.

Qual è lo scopo della licenza?

Fondamentalmente, la Licenza è un modo per il Licenziante e il Licenziatario di concordare i diritti e gli obblighi di entrambi . Tali diritti e doveri associati a una Licenza possono essere qualsiasi cosa - fino a quanto consentito dalla Legge . Ad esempio, un Licenziante potrebbe richiedere al Licenziatario di citare il suo nome quando usa il suo lavoro. Oppure puoi autorizzare a copiare il suo lavoro, ma non a modificarlo in alcun modo. O addirittura richiedere che il Lavoro derivato venga rilasciato con gli stessi termini dell'Opera originale.

D'altra parte, la Licenza è un modo per proteggere anche il Licenziatario. Dichiarando chiaramente come può usare la tua Opera, non è a rischio di vederti inaspettatamente chiedere royalties o un'altra forma di compenso per aver usato il tuo lavoro. Qualcosa che è fondamentale per l'adozione del tuo lavoro.

Quindi, la Licenza proteggerà il tuo lavoro. Proteggerà il Licenziante. Ma proteggerà anche te. Intendo te, personalmente . Ad esempio limitando la responsabilità del Licenziante per potenziali danni causati dal suo lavoro.

E se non usassi alcuna Licenza?

In assenza di una Licenza esplicitamente associata a un'opera, si applica il copyright "predefinito" per la giurisdizione dell'autore. In altre parole, non considerare mai la "mancanza di licenza" come una concessione implicita per noi per fare tutto ciò che vogliamo con il tuo lavoro. Questo è l'esatto opposto: senza alcuna licenza specifica, tu, l'autore, non hai rinunciato a NESSUNO dei tuoi diritti come concesso dalla legge.

Ma ricorda sempre che una Licenza regola i diritti e gli obblighi. Ti sei mai chiesto perché così tanti testi di licenza contengono una dichiarazione di non responsabilità scritta in TUTTE LE LETTERE MAIUSCOLE sulle garanzie fornite con un prodotto - o più spesso l'assenza di garanzia? Questo serve a proteggere il proprietario del lavoro da garanzie implicite o presupposti dell'utente. L'ultima cosa che vuoi è denunciare come conseguenza del tuo lavoro open source!

Posso usare una licenza personalizzata?

Si, puoi. Ma probabilmente non dovresti.

Essendo un contratto, una licenza non può (nella maggior parte delle giurisdizioni? Tutti loro?) Avere la precedenza sulle leggi territoriali. Da qui la difficoltà a far rispettare i diritti di licenza in un mondo globalizzato. Probabilmente sarebbe più facile (voglio dire, meno difficile) difendere una Licenza "standard" davanti a un giudice. In realtà, tali casi sono già stati difesi in diverse giurisdizioni e possono essere citati come precedenti. Ovviamente, qualcosa che non può essere fatto con una licenza personalizzata.

Inoltre, le licenze personalizzate (a volte soprannominate Vanity Licenses) possono creare incompatibilità con altre licenze, con conseguente scarsa compatibilità del tuo lavoro legalmente.

Posso usare più licenze?

Sì. La multi-licenza, in particolare la doppia licenza, non è così rara. Questo è particolarmente vero quando vuoi costruire un business attorno al tuo Lavoro gratuito. In tal caso, il progetto verrà probabilmente rilasciato sia con licenza FOSS che con licenza commerciale.

Un altro uso del multi-licensing è quello di aumentare la compatibilità, consentendo al tuo lavoro di essere combinato con opere pubblicate in termini diversi o per soddisfare le diverse esigenze o esigenze degli utenti. Questo è un motivo per cui alcuni progetti sono rilasciati sotto diverse licenze FOSS.

Ma attenzione: non tutte le licenze sono compatibili insieme! Ancora una volta, ti scoraggio dal reinventare la ruota rimanendo con licenze compatibili conosciute se vuoi andare in quel modo.

Posso cambiare la licenza "più tardi"?

Sì. Il detentore del copyright è responsabile dei termini della licenza. È piuttosto facile cambiare la Licenza finché sei l'unico contributore. Ma per fare un esempio estremo, se Linus Torvald volesse rilasciare il Kernel Linux con una licenza diversa, probabilmente avrebbe prima bisogno di approvare le migliaia di contributori a quel progetto. Qualcosa di impossibile in pratica.

Per un progetto di dimensioni più ragionevoli, può essere fatto. E infatti, è stato come vedrai in alcuni esempi qui sotto.

Quale licenza Open Source dovrei usare?

Ok, ora sei convinto che dovresti usare una Licenza Standard. Ma quale scegliere? La scelta finale spetta a te. E ci sono dei comparatori molto ben fatti disponibili sul web per aiutarti nella tua scelta. Solo per citare i miei preferiti:

  • //oss.ly/licdif
  • //choosealicense.com/ / //choosealicense.com/appendix/
  • //opensource.org/licenses
  • //tldrlegal.com/

Ma come sempre con gli affari legali, la risposta definitiva sarà quella di leggere - e capire - il testo autorevole della Licenza. Ciò potrebbe richiedere l'aiuto di un avvocato professionista. Qualcosa che non sono.

Ma quello che posso fare è fornirti un'introduzione alle licenze più comuni per guidare i tuoi primi passi.

GNU General Public License (GPL)

La GPL è una delle più popolari licenze Open Source. È disponibile in diverse versioni, ma per un nuovo progetto, dovresti considerare la più recente, che è la GPL 3 al momento in cui scrivo.

Supportando un copyleft forte, la GPL è probabilmente la licenza del software libero più protettiva. Qualcosa che può essere lodato o criticato per dipendere dal tuo punto di vista. Anche il concetto base dietro la GPL di qualsiasi lavoro derivato deve essere rilasciato sotto la GPL.

  • Forte permesso d'autore
  • Il lavoro è adatto per uso commerciale.
  • I licenziatari possono modificare il lavoro.
  • I licenziatari devono rilasciare la fonte insieme a Derivative Work.
  • Il lavoro derivato deve essere rilasciato agli stessi termini.

Progetti popolari

La GPL è la licenza naturale per i progetti della Free Software Foundation. Compresi gli strumenti GNU al centro di qualsiasi sistema Linux. I progetti di grandi dimensioni, a fortiori commerciali, tendono ad utilizzare la GPL insieme a una o più licenze.

  • Inkscape (disegno vettoriale): GPLv2
  • Drupal (Web Content Management System): GPLv2
  • MariaDB (database): GPL v2
  • MySQL (database): licenza GPL e commerciale
  • Qt (framework di applicazioni multipiattaforma): LGPL, GPL e Commercial - a seconda dei moduli e del livello di contratto di servizio

GNU Lesser General Public License (LGPL)

La GPL è molto restrittiva nel senso che costringe qualsiasi opera derivata a essere rilasciata open source con gli stessi termini. Ciò è particolarmente importante per le librerie, che sono elementi costitutivi per software più grandi: rilasciando una libreria sotto GPL, forzerai qualsiasi applicazione che usi quella libreria a essere rilasciata come GPL. Qualcosa che gli indirizzi LGPL.

Per le biblioteche, la FSF distingue tre casi:

  • La tua biblioteca implementa uno standard che compete con uno standard non libero. In tal caso, l'adozione ampia della tua libreria aiuterà la causa del Software Libero. La FSF suggerisce la licenza Apache abbastanza permissiva per quel caso (descritta più avanti in questo articolo).
  • La tua libreria implementa uno standard già implementato da altre librerie. In tal caso, non vi è alcun vantaggio per il Software Libero che possa abbandonare del tutto il copyleft. Quindi la FSF raccomanda la LGPL.
  • Infine, se la tua biblioteca non è in concorrenza con altre librerie o altri standard, la FSF raccomanda la GPL.

Gli argomenti della FSF sono per lo più etici e filosofici. In pratica, gli sviluppatori potrebbero avere altre preoccupazioni. Soprattutto se progettano di sviluppare un'attività basata sul lavoro con licenza. Ancora una volta, la doppia licenza può essere un'opzione da considerare.

  • Copyleft debole (associato a una libreria collegata dinamicamente)
  • Il lavoro è adatto per uso commerciale.
  • I licenziatari possono modificare il lavoro.
  • I licenziatari devono rilasciare la fonte insieme a Derivative Work.
  • se si modifica il lavoro, è necessario rilasciare l'opera modificata secondo gli stessi termini.
  • se usi il Lavoro, non hai bisogno di rilasciare il Lavoro derivato sotto gli stessi termini.

Progetti popolari

  • OpenOffice.org 3 (suite per ufficio): LGPLv3 - ma Apache OpenOffice 4 è passato ad Apache License 2.0.
  • GTK +, GIMP Toolkit (GUI toolkit): LGPLv2.1
  • CUPS (sistema di stampa multipiattaforma): GPL o LGPLv2 con un'eccezione per i sistemi operativi Apple, a seconda dei componenti.
  • WineHQ (livello di compatibilità Windows): LGPLv2.1
  • GNU Aspell (correttore ortografico): LGPLv2.1

Licenza pubblica Eclipse (EPL 1.0)

Con un permesso d'autore più debole rispetto alla LGPL, la licenza Eclipse è più Business-friendly in quanto consente la sub-licenza e la creazione di software fatto di EPL e non EPL (anche proprietario), purché il codice non EPL sia un "separato" modulo [s] di software " .

Inoltre, l'EPL aggiunge una protezione extra per i contributori del codice EPL in caso di azioni legali / danni causati da un'offerta commerciale compresa tale Opera.

  • Debile copyleft (associato al "modulo" software)
  • Il lavoro è adatto per uso commerciale.
  • I licenziatari possono modificare il lavoro.
  • Se si modifica il lavoro, è necessario rilasciare l'opera modificata secondo gli stessi termini.
  • Se si utilizza il lavoro, non è necessario_rendere il lavoro derivato sotto gli stessi termini.
  • I distributori commerciali del software devono difendere o risarcire i contributori originali di EPL da cause legali / danni causati dall'offerta commerciale.

Progetti popolari

Ovviamente, l'EPL è la licenza naturale per i progetti della Fondazione Eclipse. Compreso il famoso IDE di Eclipse. Ma ha guadagnato una certa popolarità oltre a questo, specialmente nel mondo di Java:

  • Clojure (linguaggio di programmazione)
  • Graphviz (pacchetto di visualizzazione grafico)
  • Jetty (Application server): doppia licenza EPL1.0 / Apache License 2.0 dal Jetty 7
  • JUnit (Java testing unit framework)

Mozilla Public License (MPL)

La licenza pubblica Mozilla è una licenza utilizzata per il software sviluppato dalla fondazione Mozilla. Ma non è certamente limitato a quell'area. L'MPL mira ad essere un compromesso tra licenze rigorose (come la licenza GPL) e licenze permissive (come la licenza MIT).

Nel MPL la "unità di licenza" è il file sorgente. I licenzianti non sono autorizzati a limitare i diritti degli utenti e l'accesso su qualsiasi file coperto da MPL. Ma lo stesso progetto può contenere anche file con licenza non MPL proprietari. Il progetto risultante può essere rilasciato con qualsiasi licenza, a condizione che venga concesso l'accesso ai file con licenza MPL.

  • Debile copyleft (associato a singoli file)
  • Il lavoro è adatto per uso commerciale.
  • I licenziatari possono modificare il lavoro.
  • I licenziatari devono fornire una corretta attribuzione per il lavoro.
  • I licenziatari possono ridistribuire il lavoro derivato in base a termini diversi
  • I licenziatari non possono rilasciare la licenza per la licenza MPL
  • I licenziatari devono distribuire il codice sorgente con licenza MPL insieme alla loro opera derivata.

Progetti popolari

  • Mozilla Firefox (browser Web), Mozilla Thunderbird (client di posta elettronica): MPL
  • LibreOffice (suite per ufficio): MPL2.0
  • Motore di database H2 (database): MPL2.0 ed Eclipse License 1.0
  • Cairo (motore grafico 2D): MPL 1.1 o LGPLv2.1

Apache License 2.0 (ASL 2.0)

Con l'ASL, stiamo entrando nel regno delle licenze libere permissive . Ma anche la FSF suggerisce la licenza Apache in alcuni casi. La Licenza Apache è permissiva in quanto non richiede la distribuzione di Derivative Work agli stessi termini. In altre parole, questa è una licenza non copyleft.

L'ASL è l'unica licenza utilizzata per i progetti di Apache Software Foundation. Essendo considerato come business-friendly, ha acquisito un'adozione diffusa al di fuori di tale organizzazione. Non è raro vedere i progetti di livello enterprise rilasciati nell'ambito dell'ASL.

  • Senza permesso d'autore
  • Il lavoro è adatto per uso commerciale.
  • I licenziatari possono modificare il lavoro.
  • I licenziatari devono fornire una corretta attribuzione per il lavoro.
  • I licenziatari possono ridistribuire il lavoro derivato in base a termini diversi.
  • I licenziatari non devono distribuire il codice sorgente insieme alla loro opera derivata.

Progetti popolari

  • Android (sistema operativo): ASL 2.0 con alcune eccezioni (in particolare per quanto riguarda il kernel di Linux)
  • Apache httpd (server Web): ASL 2.0
  • Apache Spark (Cluster computing framework): ASL 2.0
  • Spring Framework (Framework per applicazioni enterprise basate su Java): ASL 2.0

Licenza MIT

Questa è una licenza molto popolare. Anche probabilmente il più popolare. Ponendo pochissime limitazioni al riutilizzo, la licenza MIT può essere facilmente associata ad altre licenze, dalla GPL alle licenze proprietarie.

  • Senza permesso d'autore
  • Il lavoro è adatto per uso commerciale.
  • I licenziatari possono modificare il lavoro.
  • I licenziatari devono fornire una corretta attribuzione per il lavoro.
  • I licenziatari possono ridistribuire il lavoro derivato in base a termini diversi
  • I licenziatari non devono distribuire il codice sorgente insieme alla loro opera derivata.

Progetti popolari

  • node.js (ambiente runtime JavaScript): licenza MIT
  • jQuery (libreria JavaScript lato client): Licenza MIT (fino al 2012, doppia licenza MIT / GPL)
  • Atom (editor di testo): licenza MIT
  • AngularJS (framework dell'applicazione JavaScript): licenza MIT
  • SQLAlchemy (toolkit SQL e Object Relational Mapper per Python): licenza MIT

Licenze BSD

La licenza BSD è disponibile in tre versioni. La licenza originale di 4 clausole, la licenza di 3 clausole "revisionata" e la licenza "semplificata" di 2 clausole. Tutti nello spirito sono molto vicini alla licenza del MIT. E in effetti, esistono pochissime differenze pratiche tra la licenza BSD a 2 clausole e la licenza MIT.

Le licenze BSD a 3 e 4 clausole aggiungono ulteriori requisiti riguardanti il ​​riutilizzo dei nomi e la pubblicità. Questo è qualcosa da considerare se vuoi proteggere il tuo prodotto o il tuo marchio.

  • Senza permesso d'autore
  • Il lavoro è adatto per uso commerciale.
  • I licenziatari possono modificare il lavoro.
  • I licenziatari devono fornire una corretta attribuzione per il lavoro.
  • I licenziatari possono ridistribuire il lavoro derivato in base a termini diversi.
  • I licenziatari non devono distribuire il codice sorgente insieme alla loro opera derivata.
  • I licenziatari non possono utilizzare il nome o il marchio dell'autore originale per sostenere il lavoro derivato (3 e 4 clausole BSD)
  • I licenziatari devono riconoscere l'autore originale in tutti i materiali pubblicitari che menzionano le caratteristiche o l'uso del lavoro (4-clausole BSD)

Progetti popolari

  • Django (web ramework): 3-clausole BSD
  • Redis (archivio dati): 3-clausole BSD
  • Ruby (linguaggio di programmazione): BSD a 2 clausole e licenza personalizzata
  • Nginx (server Web): BSD a 2 clausole
  • NetBSD (sistema operativo): BSD a 2 clausole - 4 clausole BSD fino al 2008

L'ultima parola sulle licenze Open Source

Se vieni così lontano, congratulazioni! Adesso lo capisci, il licensing è davvero un argomento enorme e complesso. Ma vale la pena prendersi il tempo per scegliere la licenza giusta per il proprio progetto e per fare quella scelta in anticipo. Potresti risparmiare un sacco di problemi in seguito, quindi puoi utilizzare il tuo tempo e le tue energie lavorando sul tuo progetto piuttosto che affrontare problemi di copyright o di compatibilità legale.

Anche se ho fatto del mio meglio per rendere accessibile l'argomento, non è sempre facile riassumere le sottigliezze delle varie licenze. E al di là delle poche licenze importanti presentate qui, ce ne sono altre decine più o meno comunemente usate.

Quindi, non esitate a utilizzare la sezione commenti qui sotto per dirci qual è la vostra licenza preferita e perché. O per citare alcune caratteristiche importanti che potrei aver dimenticato!

Raccomandato

Il nuovo lettore musicale Elisa di KDE: così vicino, eppure così lontano
2019
MPV Player: un riproduttore video minimalista per Linux
2019
Le migliori distribuzioni Linux basate su Fedora
2019