Attenzione programmatori: ci sono molti problemi di licenza per le app Ether

Matt Savare e John Wintermute lavorano presso Lowenstein Sandler LLP, dove si occupano di proprietà intellettuale, pubblicità digitale, Tecnologie, blockchain e diritto Privacy . Shailley Singh è il direttore senior per i prodotti e R&S presso IAB Tech Lab.

Nonostante l'incredibile attenzione che la Tecnologie blockchain ha suscitato nell'ultimo anno, si è parlato molto poco dei problemi di licenza open source e dei rischi correlati a cui vanno incontro gli sviluppatori quando utilizzano Ethereum come base per le proprie applicazioni.

Molti sviluppatori potrebbero non comprendere (o ignorare volontariamente) i rischi specifici che si corrono utilizzando software open source. (Questi rischi non sono presenti in Bitcoin, perché la blockchain Bitcoin , a differenza della blockchain Ethereum , non è una piattaforma su cui gli sviluppatori possono creare facilmente applicazioni decentralizzate utilizzando codice open source.)

La Ethereum Foundation attualmente utilizza una varietà di licenze open source per i diversi componenti di Ethereum. Per complicare ulteriormente le cose, l'ente ha indicato di non aver ancora selezionato una licenza open source definitiva su cui il CORE di Ethereum sarà reso disponibile in futuro.

Per questo motivo, gli sviluppatori di applicazioni basate su Ethereum dovrebbero identificare, comprendere e affrontare questi rischi e limitazioni.

L'utilizzo di Ethereum comporta una serie di questioni legali e commerciali, ma forse nessuna è più urgente per uno sviluppatore di app basate su Ethereum di quella che di solito è una domanda semplice: quali sono i miei diritti di utilizzare Ethereum?

La risposta, a quanto pare, non è così semplice.

Quando "gratis"T è gratis

La Ethereum Foundation promette che Ethereum "è sia un software open source che un software libero secondo la definizione della Free Software Foundation (il cosiddetto FLOSS)." In altre parole, i titolari di licenza riceveranno generalmente ampi diritti per eseguire, copiare, distribuire e migliorare il software.

Tuttavia, al di là di questa premessa di base, la situazione diventa incerta.

Come sa qualsiasi sviluppatore di software open source esperto, software "libero" non significa "senza restrizioni", né significa necessariamente "senza costi", anche se spesso lo è. Tali restrizioni, che possono sconvolgere il CORE del modello di business di uno sviluppatore downstream, sono particolarmente complicate quando si tratta di Ethereum.

Il software open source, che si basa sul concetto che ogni licenziatario di un software dovrebbe ricevere il codice sorgente di un programma e la possibilità di modificarlo per i propri scopi, rientra generalmente in ONE delle due grandi categorie: "permissivo" e "restrittivo".

Le licenze di tipo permissivo, che includono MIT, BSD e Apache, contengono restrizioni minime e concedono ampi diritti ai licenziatari di utilizzare e modificare il software coperto e di ridistribuire le modifiche alle condizioni preferite dal licenziatario.

Per gli sviluppatori commerciali, le licenze permissive sono generalmente considerate più sicure di quelle restrittive, perché non corrono il rischio di "contaminare" sviluppi o modifiche con i termini open source del software con licenza.

La licenza MIT, ad esempio, richiede solo un avviso di copyright, un disclaimer e che il disclaimer e l'avviso vengano trasmessi a tutti i licenziatari a valle. Uno sviluppatore è libero di prendere software concesso in licenza ai sensi della licenza MIT e di ri-licenziare qualsiasi modifica o lavoro derivato come parte di un'offerta commerciale standard.

Licenze infettive

Le licenze di tipo restrittivo, o licenze "copyleft", includono la Mozilla Public License, la General Public License (GPL), la Lesser GPL e la Affero GPL.

A differenza delle licenze permissive, queste licenze limitano la possibilità del licenziatario di distribuire modifiche e lavori derivati a condizioni commerciali o non open source.

Le licenze copyleft sono anche chiamate "licenze virali", perché potrebbero potenzialmente "infettare" un prodotto software con i termini open source del programma copyleft sottostante, impedendo al licenziatario di distribuire una versione modificata o derivata a pagamento o in formato non sorgente.

A seconda della licenza copyleft, potrebbero esserci modi per utilizzare il software open source senza infettare il prodotto nel suo complesso; il modo in cui verrà attivato il termine della licenza virale è spesso una questione complicata e legata ai fatti.

Pertanto, l'uso di software open source, pur essendo estremamente prezioso, comporta livelli di rischio che devono essere analizzati prima di concedere in licenza qualsiasi prodotto open source.

Al livello di rischio più elevato, uno sviluppatore potrebbe mettere a repentaglio l'intero valore proprietario di un progetto.

Punti di vista contrastanti

Per gli sviluppatori che cercano di comprendere le implicazioni della concessione di licenza Ethereum per l'uso nelle loro attività, la Ethereum Foundation complica questa questione già delicata in due modi: in primo luogo, sfruttando una varietà di licenze open source per i vari componenti di Ethereum; e in secondo luogo, rimanendo indecisa sul futuro schema di licenza di Ethereum, in particolare per Ethereum CORE.

Secondo la sezione sulle licenze di EthereumPagina GitHub, le applicazioni saranno distribuite sotto GPL e il middleware sarà reso disponibile sotto una versione della Affero GPL. Entrambe le licenze sono di natura restrittiva e pertanto limitano la capacità di un licenziatario di concedere nuovamente in licenza modifiche o sviluppi a condizioni commerciali.

Differiscono, tuttavia, nella definizione di "distribuzione" che innesca le restrizioni virali in ogni licenza. Il problema di Affero è che l'interazione remota tramite il web è sufficiente a innescare un requisito che un licenziatario Affero renda generalmente disponibile il codice sorgente dei propri sviluppi e modifiche.

In altre parole, un licenziatario di un prodotto software coperto da Affero potrebbe voler apportare modifiche o miglioramenti al software sottostante e rendere disponibile tale prodotto migliorato come software-as-a-service, ma in tal caso, il codice sorgente dell'intero lavoro derivato deve essere reso disponibile agli utenti che interagiscono con esso. Ovviamente, questo requisito è spesso proibitivo per uno sviluppatore che desidera mantenere il valore proprietario del prodotto.

La Ethereum Foundation spiega che Ethereum "è distribuito con diverse licenze" in parte "per riflettere il diverso modo di pensare delle menti dietro i diversi software".

Questi punti di vista contrastanti sono evidenti anche dal fatto che la Ethereum Foundation ha dichiarato di non aver ancora selezionato una licenza definitiva per il CORE di Ethereum, che include il motore di consenso, il codice di rete e le librerie di supporto.

Domande irrisolte

Sebbene la Ethereum Foundation affermi che "il CORE di Ethereum verrà rilasciato con la più liberale delle licenze", cita la licenza MIT, la licenza pubblica Mozilla e la LGPL come le tre principali candidate, le ultime due delle quali sono in realtà di natura copyleft (anche se generalmente considerate licenze "copyleft deboli").

L'obiettivo, secondo la fondazione, è rendere il CORE "disponibile per l'uso in qualsiasi ambiente commerciale, chiuso o open source".

Per complicare ulteriormente le cose, cpp-ethereum, che contiene tutte le librerie CORE di ethereum, sembra essere attualmente rilasciato con licenza GPL.

Non solo ciò è in conflitto con l'indicazione della fondazione che le licenze CORE finali sono indeterminate, ma non è nemmeno tra le opzioni elencate dalla fondazione per la considerazione. La GPL non è né una licenza permissiva né ONE"debole copyleft". Piuttosto, contiene significative restrizioni sulla modifica e la ridistribuzione a valle.

L'attuale utilizzo di una licenza copyleft forte e l'apparente incertezza riguardo allo schema di licenza finale rappresentano rischi potenzialmente significativi per gli sviluppatori.

Finché non verrà determinata la licenza definitiva, gli sviluppatori di applicazioni basate su Ethereum saranno soggetti a eventuali cambiamenti o divisioni nella filosofia alla base della licenza di Ethereum , una filosofia che la Fondazione Ethereum ammette liberamente contenga già delle fratture tra le varie parti interessate.

Procedere con cautela

Tutto questo non significa che gli sviluppatori non dovrebbero utilizzare Ethereum o che l' Ethereum Foundation stia sbagliando qualcosa nel suo approccio.

Gli sviluppatori commerciali devono invece comprendere le complicazioni delle licenze open source e le peculiarità del contesto di Ethereum.

Gli svantaggi di sottovalutare o valutare male i rischi sono decisamente troppo grandi.

Monumento del programmatoreimmagine tramite Shutterstock