Il grande problema legale di cui gli sviluppatori di blockchain raramente discutono

Mark Radcliffe e Victoria Lee sono soci dello studio legale DLA Piper.

Il software concesso in licenza con licenze open source (OSS) è fondamentale per il successo dei progetti blockchain. Tali licenze consentono uno sviluppo collaborativo e decentralizzato, incoraggiano una rapida adozione da parte degli utenti e consentono alla comunità di "forcare" il progetto per risolvere controversie strategiche.

Infatti, le licenze OSS sono utilizzate da entrambe le due principali blockchain pubbliche, Ethereum e Bitcoin, nonché da molti altri importanti progetti blockchain, tra cui i programmi HyperLedger e Corda di R3.

Tuttavia, le licenze OSS sono generalmente piuttosto diverse dalle licenze tradizionali per software proprietario. L'importanza di selezionare la giusta licenza OSS e di rispettare i termini di tale licenza viene raramente discussa dalla comunità blockchain.

Se i progetti blockchain cercano l'adozione da parte delle aziende, la licenza OSS per il progetto avrà un impatto materiale sul tasso di adozione. Anche per progetti consolidati comeEthereum, i potenziali utenti aziendali valutano attentamente le licenze OSS che potrebbero utilizzare.

Ad esempio, Jerry Cuomo di IBM ha recentemente osservato l'innovazione blockchain di Frederick Munawapodcast che la complessità delle licenze OSS per Ethereum è stata ONE delle ragioni per cui IBM ha deciso di passare da Ethereum al proprio progetto blockchain, che alla fine è diventato parte del progetto HyperLedger.

I potenziali utenti aziendali di un progetto blockchain decideranno quale progetto blockchain adottare applicando gli stessi criteri che utilizzano per l'adozione di altri progetti con licenza OSS: (1) la complessità della licenza o delle licenze del progetto OSS; (2) la potenziale difficoltà di rispettare gli obblighi di tale licenza OSS; e (3) le potenziali sfide dell'integrazione di un progetto blockchain con altri progetti software.

Le licenze OSS variano notevolmente nei loro termini. L'Open Source Initiative (OSI) ha approvato 83 licenze come "open source".

Tuttavia, la complessità completa delle licenze OSS è suggerita dal progetto SPDX, gestito dalla Linux Foundation, che ha identificato 345 licenze "principali"; Black Duck Software elenca 2.500 versioni di licenze di tipo OSS nella sua Knowledge Base, che copre oltre 530 miliardi di linee di codice OSS da oltre 9.000 fucine e repository di progetti open source. Black Duck nota che il 94 percento dei progetti OSS è concesso in licenza con le prime 10 licenze OSS.

I due principali tipi di licenze OSS sono "copyleft" e "permissive". Ethereum è principalmente concesso in licenza con due licenze copyleft: la Lesser General Public License versione 3 (LGPLv3) e la General Public License versione 3 (GPLv3). D'altro canto, Bitcoin CORE è concesso in licenza con la licenza MIT, la licenza permissiva più popolare.

Licenze copyleft

Le licenze copyleft impongono i termini più restrittivi all'uso dell'OSS. L'esempio più noto di licenza copyleft è la General Public License versione 2 (GPLv2), utilizzata per il programma del sistema operativo Linux.

Secondo Black Duck Knowledge Base, la GPLv2 è la seconda licenza più popolare, adottata dal 14 percento dei progetti OSS. La GPLv3 utilizzata da Ethereum è la versione aggiornata della GPLv2, pubblicata nel 2007. La caratteristica più fondamentale di una licenza copyleft è la sua clausola "reciproca": il requisito legale che sia l'OSS originale sia tutti i "lavori derivati" dell'OSS originale siano distribuiti esclusivamente secondo i termini della licenza copyleft. "Lavoro derivato" è un termine tecnico ai sensi della legge statunitense sul copyright, che descrive un lavoro basato su ONE o più lavori preesistenti che rappresentano un'opera originale di autore.

La legge sul copyright è stata originariamente concepita per proteggere libri, canzoni e film, ma protegge anche il software. ONE esempio è la serie Game of Thrones, che è un'opera derivata basata sulla serie di romanzi con lo stesso nome. Sebbene l'opera derivata significhi generalmente una modifica del software, un'opera derivata può essere creata in altri modi: ad esempio, due programmi compilati insieme sono spesso considerati un'opera derivata.

Tuttavia, l'applicazione della legge sul copyright al software continua a essere incerta. Di conseguenza, l'integrazione di progetti con licenza copyleft con progetti con licenza sotto altre licenze OSS o licenze proprietarie comporta un'analisi legale complessa.

La conformità con la licenza copyleft è significativamente più impegnativa della conformità con le licenze permissive: le licenze copyleft hanno obblighi più complessi e la mancanza di chiarezza della legge sul copyright applicata al software crea altri problemi. La comunità OSS che supporta le licenze copyleft è molto preoccupata per l'uso improprio di OSS da parte dei venditori proprietari.

Questa comunità è piuttosto aggressiva nel cercare di ottenere dagli utenti la conformità a tali licenze. Praticamente tutte le controversie legali riguardanti le licenze OSS sono state intentate per l'applicazione delle licenze copyleft.

Licenze permissive

Le licenze "permissive" impongono pochissimi termini all'uso dell'OSS, in genere richiedono solo all'utente di includere avvisi e una copia della licenza. A differenza delle licenze copyleft, non includono obblighi "reciproci".

La comunità OSS che supporta le licenze permissive ritiene generalmente che tali licenze favoriscano un'adozione più rapida di un progetto OSS e che i termini "reciproci" delle licenze copyleft non siano necessari per lo sviluppo di successo di un progetto blockchain.

L'esempio più noto di licenza permissiva è la licenza MIT utilizzata da Bitcoin. Secondo Black Duck Knowledge Base, il 38 percento dei progetti OSS ha adottato la licenza MIT, rendendola la licenza OSS più popolare.

La maggior parte dei progetti blockchain non si è storicamente concentrata sull'importanza della scelta di una licenza OSS. Tuttavia, considerare attentamente la scelta della licenza e prendersi il tempo per comprendere le differenze nei requisiti di conformità e nell'approccio all'applicazione dovrebbe consentire ai progetti di raccogliere benefici a lungo termine.

La scelta della licenza non inciderà solo sulla volontà delle aziende di adottare il progetto, ma determinerà anche la filosofia di conformità e la cultura comunitaria del progetto.

Sintassi del codiceimmagine tramite Shutterstock