Titolo originale: Considering Open Source Licenses

Pubblicato in: Business

Scritto da

E così avete un progetto che volete creare con degli strumenti open source. Beh, mi tolgo il cappello davanti a voi developer. Ma sapete a che domande dovete rispondere prima di iniziare?

In quale fase di sviluppo si trova il vostro progetto in questo momento? Avete finito la fase di pianificazione? State lavorando con un team? Il progetto sarà suddiviso in diversi moduli? E così via.

Il principio DRY (Don't Repeat Yourself) è diventato una regola non scritta per gli sviluppatori. Invece di partire da zero su ogni nuovo progetto, trovate modi per costruire basandovi sul lavoro precedente. Questo vi consente di risparmiare tempo e altre risorse. In altre parole, non re-inventate la ruota: sfruttate il grande lavoro che gli altri hanno perfezionato e vi hanno messo a disposizione "gratuitamente" come base da cui partire.

Tale principio DRY può essere applicato anche ai lavori open source. Quando si avvia un nuovo progetto, la maggior parte degli sviluppatori innanzitutto cerca attentamente i framework, le librerie e i pacchetti su cui possono costruire o che possono modificare per soddisfare le loro esigenze.

Soprattutto, potete scegliere tra le migliaia e migliaia di progetti open source (OS, framework, IDE, librerie, sistemi di gestione di database e così via) disponibili.

Ma aspettate un minuto!

Immaginate che il vostro progetto diventi un enorme successo, solo per essere poi abbattuto da questioni di licenze richieste dai lavori su cui vi siete basati per realizzarlo. Capite veramente che cosa significa usare il lavoro open source nel vostro progetto?

Man mano che aumenta l'adozione di open source, aumenta anche il rischio di non conformità con i termini di licenza che, a sua volta, porta ad un aumento del numero delle controversie che coinvolgono le opere open source.

Uno degli esempi più recenti coinvolge Hancom e Artifex, lo sviluppatore di Ghostscript . Il caso è in corso, ma da quanto segue, la direzione sembra essere chiara:

Per utilizzare Ghostscript gratuitamente, Hancom dovrebbe aderire alla sua licenza open-source, la GNU General Public License (GPL). Il GNU GPL richiede che quando si utilizza software con licenza GPL per realizzare un altro software, il software risultante deve anche essere open source con la stessa licenza se viene rilasciato al pubblico. Ciò significa che Hancom dovrebbe rilasciare la sua intera suite di applicazioni come open source.

Oppure, Hancom deve pagare un diritto di concessione ad Artifex.

Adesso cominciate a farvi un'idea della situazione, vero?

Nota: nulla di ciò che dico in questo articolo è consulenza legale. Se non vi sono chiare le spiegazioni o i termini che trovate in una licenza, è una buona idea ottenere una consulenza legale qualificata. Queste sono solo alcune cose in cui mi sono imbattuto e voglio metterle in evidenza per i miei colleghi sviluppatori.

Valutare le opzioni open source

Prima di decidere per un progetto open source da utilizzare o da includere nel vostro progetto, tornate alla vostra grande idea (cioè, il progetto che state sviluppando) e rispondete alle seguenti domande.

  1. Qual è la visione del progetto? In particolare, state sviluppando un altro progetto open source o venderete il vostro progetto per trarne profitto?
  2. Come metterete a disposizione degli altri il vostro progetto? Saranno in grado di leggere il codice sorgente o lo renderete off limit?
  3. Quali diritti di ridistribuzione permetterete? Gli altri saranno autorizzati a re-impacchettare il vostro lavoro e a venderlo a scopo di lucro, oppure saranno in grado di ridistribuirlo gratuitamente?
  4. Come dovreste gestire l'embedding? Gli altri potranno incorporare il vostro lavoro nel loro, per poi venderlo o distribuirlo per profitto o incorporare il vostro lavoro, ma impedire l'accesso al sorgente in modo che non sia disponibile ad altri?
  5. Come gestirete l'attribuzione? Cosa farete per dare credito ai creatori originali dei tool inclusi?

Una volta che avrete risposto alle domande precedenti, cosa succede? È giunto il momento di rispondere ad un'altra domanda.

Cosa significa open source?

Cosa vi viene in mente quando vi imbattete in un lavoro classificato come open source? Libero da utilizzare come lo ritenete appropriato? Scoprite cosa significa realmente in questo caso dalla Open Source Initiative.

Dopo averlo letto, volete ancora includere del lavoro open source nel vostro progetto? Farà deragliare il vostro scopo e il vostro obiettivo?

Perché i progetti open source hanno una licenza?

Una ragione per cui i progetti sono concessi in licenza con una licenza open source è per convenienza.

Le licenze open source dicono agli sviluppatori come utilizzare il vostro lavoro e quali limitazioni e restrizioni devono rispettare. Non vorreste un flusso costante di messaggi di posta elettronica da parte di tutti quelli che sono interessati a utilizzare il vostro lavoro: potrebbero essere migliaia di persone.

Allo stesso tempo, le licenze open source rendono facile per altri contribuire a un progetto, al contrario di un sistema chiuso. Immaginate i talenti che potranno contribuire a un progetto open source rispetto a un progetto interno. Sarete in grado di attirare risorse di gran lunga maggiori per raggiungere l'obiettivo del vostro progetto: sì, sarete d'accordo sul fatto che si può ottenere molto di più in questo modo.

La licenza serve come protezione per il creatore di un lavoro o di un insieme di lavori: nessun altro potrà affermare che il vostro lavoro sia loro. Assicuratevi di ottenere i credit che meritate come autori di un progetto.

Leggete ogni licenza, ogni volta#section4

Non tutte le licenze open source sono uguali. Date un'occhiata alla tabella nella Fig. 1 per vedere che tipi di differenze potreste incontrare.

Tabella di confronto delle licenze open source

Fig. 1: Confronto delle licenze open source
Image Source: https://choosealicense.com/appendix/

Introduzione alle licenze più popolari

Di seguito sono riportate alcune delle licenze open source più diffuse, con i dettagli su quali poteri o limitazioni vengono imposti per quanto riguarda l'utilizzo e la ridistribuzione.

MIT License

Un progetto con questa licenza open source consente di utilizzare, copiare, modificare, unire, pubblicare, distribuire, sub-licenziare e/o vendere copie del Software e permettere di fare lo stesso alle persone a cui è fornito il software". Ciò significa che potete utilizzare questo lavoro per il vostro progetto come lo ritenete appropriato (anche vendere opere derivate) con le uniche condizioni che voi 1) lasciate intatta la licenza MIT e 2) includiate un avviso di copyright.

Ciò significa che è necessario includere una nota simile a questa nel file di licenza del vostro lavoro:

"[Nome del vostro progetto] include codice da [creatore originale del lavoro incluso] ed è concesso in licenza sotto la licenza MIT" seguito dal testo completo della licenza MIT.

Un'altra cosa da notare prima di utilizzare un lavoro con questa licenza è che "Il software MIT concesso in licenza può essere integrato nel software GPL, ma non il viceversa". Pensate a una situazione in cui dovrete includere dei lavori con le licenze MIT e GPL nel vostro progetto. Alla fine, questa combinazione porterà la licenza GPL, escludendo la licenza MIT. (Potete leggere della licenza GPL qui sotto.)

Apache License

Questa licenza è in qualche modo simile alla licenza MIT. Potete utilizzare i lavori con questa licenza nel vostro progetto a condizione che prendiate nota del fatto che "richiede la conservazione dellacopyright notice e del disclaimer".

I termini della Apache Licence sono molto rigorosi circa le modifiche. È necessario dichiarare esplicitamente che l'opera originale è stata modificata e includere quanto segue nel vostro avviso di licenza:

La Free Software Foundation considera che tutte le versioni della licenza Apache siano incompatibili con le versioni precedenti GPL 1 e 2 e, inoltre, considera le versioni di licenza Apache prima della v2.0 incompatibili con GPLv3. A causa delle richieste di licenza brevettuale della versione 2.0, la Free Software Foundation la raccomanda rispetto ad altre licenze non copyleft, specificamente raccomandandole sia per i piccoli programmi che per gli sviluppatori che desiderino utilizzare una licenza permissiva per altri motivi.

GNU General Public License (GPL) 3

Questa licenza non è particolarmente permissiva se confrontata con, ad esempio, la licenza MIT. Tuttavia, promuove notevolmente lo sforzo comunitario ed è una delle licenze open source più popolari là fuori.

Quando utilizzate un lavoro con GPL che rilascerete al pubblico (o ridistribuirete), questa licenza richiede che rendiate disponibili le modifiche (inclusa la documentazione per l'installazione e la creazione) sotto la licenza GPL.

BSD 3-Clause License

Anche questa è molto simile alla licenza MIT: vi permette l'utilizzo per progetti commerciali, la ridistribuzione e la modifica, ma devono essere incluse la nota sul copyright e la licenza BSD stessa.

La scelta tra MIT e BSD dipende ora da ciò che è adatto al vostro progetto. Le licenze MIT e BSD differiscono in termini di compatibilità con altre licenze open source, mentre il lavoro licenziato MIT vi permetterà di includere altri lavori con termini di licenza diversi, il lavoro con licenza BSD non lo permetterà. Di più su questa compatibilità di licenza sotto.

Ci sono diverse altre licenze open source che non sono incluse qui. Richiedono un'attenta lettura e comprensione prima di lanciarsi nell'utilizzo di opere con questo tipo di licenze.

Ignorare i termini di una licenza open source

Valutare quali licenze open source sono adatte si riduce ad evitare future cause legali. I problemi previsti sono problemi mezzo-risolti. Ma cosa succede se ignorate i termini di una licenza?

Sarete perseguiti quando lo si scoprirà? La Free Software Foundation è un'organizzazione che offre come volontarie le proprie risorse per garantire la conformità delle licenze open source: una specie di polizia delle licenze open source. Di seguito è riportata una frase tratto dalla loro pagina di conformità:

Una volta che abbiamo accertato che si è verificata una violazione, spieghiamo al violatore cosa dovrà fare per essere conforme. Egli farà alcuni cambiamenti appropriati - al software, al prodotto, al sito web o a qualunque cosa ne sia toccata - e ce lo comunicherà. Verificheremo questi cambiamenti, lo informeremo di eventuali nuovi problemi o di altri in sospeso e gli chiederemo di apportare ulteriori modifiche. Questo avanti e indietro continuerà finché sarà necessario.

Compatibilità delle licenze

E per quel che riguarda l'utilizzo di lavori con licenze open source diverse? Ci saranno delle implicazioni? In altre parole, se state pensando di "mescolare" il lavoro di vari termini di licenza in un progetto, è qui che dovete iniziare a pensare alla compatibilità.

Se delle componenti di codice che sono state concesse sotto condizioni di licenza diverse vengono compilate per formare un nuovo lavoro, si pone una domanda: l'uso comune del codice è consentito in base alla licenza? Se per esempio il codice A sotto licenza X è collegato al codice B sotto licenza Y per formare un nuovo programma, le licenze X e Y devono permetterlo. Se questo è il caso, esiste la compatibilità della licenza.

ifrOSS (The Institute for Legal Questions on Free and Open Source Software)

Magari avete trovato un lavoro open source che si adatta perfettamente al vostro progetto... Ma. La. Licenza. Non. È. Compatibile! Cosa puoi fare per questo?

Innanzitutto, considerate la licenza del lavoro open source che intendete utilizzare nel vostro progetto.

Ovviamente, i problemi di licenza saranno più facili da gestire quando userete lavori open source con la stessa licenza e un modo per evitare l'incompatibilità della licenza consiste nel leggere oltre l'elenco delle feature, dopo aver letto la sezione delle funzionalità, assicuratevi di leggere rapidamente la sezione requisiti.

Quando indagate gli strumenti open source da utilizzare nel vostro progetto, fate della "compatibilità" la vostra compagna. Tenetela vicina.

In termini di compatibilità, la licenza MIT è abbastanza generosa: a partire dal momento in cui questo articolo è stato scritto, questa licenza impedisce solo di citare l'autore del lavoro. Quindi, in generale, un lavoro sotto licenza MIT è ottimo per la maggior parte degli obiettivi. (Ricordatevi che questo non è un consiglio legale).

Violazione della licenza

Se un caso di licenza influisce su di voi o sul vostro progetto, notate che alcuni casi legali relativi all'infrazione della licenza vengono risolti in tribunale. Potreste essere in grado di negoziare e raggiungere un accordo personale con l'autore - un accordo che consentirà di utilizzare il lavoro senza violazione. In poche parole, contattate l'autore del lavoro open source per discutere della situazione e dei possibili compromessi o delle alternative che potrebbe prendere in considerazione. Il negoziato fatto prima di intraprendere il vostro progetto potrebbe contribuire a chiarire la licenza, assicurare che voi e l'autore siate d'accordo ed evitare interamente una questione giuridica.

Per concludere

L'esame delle licenze open source dovrebbe essere parte della fase di pianificazione precoce del progetto, non venire dopo lo sviluppo.

Per ridurre significativamente il rischio di violazioni, assicuratevi di prendere sul serio le violazioni delle licenze open source e che siano previste politiche open source appropriate per guidare il vostro team di sviluppo. Non dimenticate che il progetto avrà anche bisogno di una licenza dopo aver completato lo sviluppo (e la produzione). Che licenza userete? Le licenze incluse nel lavoro open source utilizzato nel progetto determineranno la vostra licenza.

Soprattutto, in qualità di sviluppatore individuale o entità aziendale che sviluppa, distribuisce o utilizza open source, dovreste trovare il tempo per leggere e comprendere i termini e le condizioni delle licenze open source che utilizzate.