Vendere e acquistare software Open, quando conviene? | Digital4Trade
Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Legal IT

Vendere e acquistare software Open, quando conviene?

di Redazione

23 Gen 2017

Guglielmo Troiano, Senior legal consultant di P4I, spiega quali siano le caratteristiche del modello “open” e quali siano le questioni da approfondire per poter sfruttare questo modello e risparmiare sullo sviluppo

Il modello “open” nello sviluppo e distribuzione di software è senza dubbio il più diffuso oggi. Gartner ha stimato che entro il 2016 questo modello sarà incluso nei software mission-critical nel 99% delle imprese nel Mondo.
Il modello “open” è utilizzato per creare applicazioni, prodotti e servizi di ogni genere e offre centinaia di migliaia di componenti di codice che possono accelerare lo sviluppo e tagliare i budget di migliaia o addirittura milioni di USD.
Le aziende IT con il più alto tasso di crescita sono nate e si sono sviluppate sul modello “open”, da Facebook a Twitter ad Amazon e Google. Persino Apple, la società più preziosa del mondo IT, ha sviluppato i suoi sistemi operativi partendo da modelli “open” (Mac OS X nasce da uno sviluppo del sistema operativo Darwin, proveniente dalla famiglia di sistemi operativi “open” BSD).
l vantaggi economici del modello “open” sono evidenti. Se si considera che il costo per riga di codice (Line Of Code – LOC) oscilla oggi tra i 10 ed i 20 USD e che mediamente ci sono 50.000 LOC in ogni componente software, utilizzando codice sviluppato e distribuito con il modello “open” si potrebbe giungere ad un risparmio sino ad un milione di USD per progetto.

Guglielmo Troiano, Senior Legal Consultant di P4I – Partners4Innovation

Ma che cosa si intende per modello “open”? Quali sono le questioni da approfondire per poter sfruttare questo modello e risparmiare sullo sviluppo? Si può modificare il software “open” e se si a quali condizioni?
Al consumatore finale che utilizza il software “as is” poco o nulla importa di queste tematiche. Per l’utente finale è importante che il software riesca a soddisfare la generica esigenza per il quale è stato acquisito (per es. Word o LibreOffice per word processing). Ma che accade se l’utente finale non è soddisfatto dalle funzioni che offre il software ed è un soggetto capace di poterlo modificare? Non è rilevante che questo soggetto sia un singolo individuo o un’azienda (per la PA occorre fare un discorso a parte), potrebbe essere in tutti i casi interessato a modificare il software per adattarlo alle proprie esigenze.
Generalmente il software può essere utilizzato solo così com’è, non si può modificare. Si possiede il file eseguibile per installarlo (EXE, DMG ecc.) e si hanno stringenti limiti di utilizzo, oltre al fatto che il “codice sorgente” non è disponibile.


Nel modello “open”, viceversa, sussistono entrambe le due condizioni (codice disponibile e possibilità di modificarlo) ma uno degli aspetti più importanti è il concetto di copyleft. Solitamente si definiscono due livelli di copyleft nel software “open”: forte e debole. Se il copyleft è forte, tutte le successive opere derivate del software devono conservare la stessa licenza del software originario, quindi le stesse condizioni (concetto della c.d. “ereditarietà”). Se invece il copyleft è debole questo vincolo non sussiste.
L’archetipo di licenza con copyleft forte è la licenza GNU/GPL (ideata da Richard M. Stallman, un informatico, e perferzionata da Eben Moglen, un professore di legge e avvocato). Questa licenza è caratterizzata dall’obbligo di rilasciare (ripubblicare) il codice eventualmente modificato con la stessa licenza. In altre parole, tutto il codice sviluppato dev’essere a sua volta coperto con la stessa licenza. La GPL è chiara su questo punto “I programmi coperti da GPL non possono essere incorporati all’interno di programmi non liberi”.
Un esempio di licenza con copyleft debole è Apache utilizzata, per esempio, per il sistema operativo per smartphone più diffuso al Mondo, Android di Google. Apache si può considerare una licenza “open” ma le sue condizioni concedono a chiunque la libertà nell’utilizzo del codice al punto che consente anche la libertà di utilizzare lo stesso codice per sviluppare software che possa a sua volta essere rilasciato con licenza “proprietaria”, lasciando impregiudicate solo le parti sottoposte espressamente ad una licenza di diverso tipo.
Sebbene l’utilizzo di una licenza con copyleft debole (anche detta “permissiva”) come l’Apache è il modo migliore per sostenere una piattaforma di sviluppo software complessa come Android, molti, Free Software Foundation compresa, sostengono che l’uso delle licenze con copyleft debole sacrifichino l’occasione per incoraggiare una maggiore trasparenza nel vasto mercato del software. Infatti, se Android fosse stato distribuito con licenza GPL, tutti avrebbero dovuto condividere i propri miglioramenti sulla piattaforma di sviluppo, il che avrebbe potuto teoricamente portare alla condivisione diffusa di codice e ad un’accelerazione più rapida dello sviluppo del sistema operativo.
Quindi la licenza determina il modello di business sul software?
Si. Tornando ancora su Android, la licenza Apache, con ogni probabilità, è stata scelta da Google sulla base di logiche commerciali e non per sensibilità verso i diritti degli utenti o, tanto meno, della comunità degli sviluppatori indipendenti. Il modello che Google ha scelto per Android è senz’altro “open” ma poco orientato al mantenimento perpetuo di tale apertura. Chiunque potrebbe infatti appropriarsi di tutte le componenti di Android rilasciate con licenza Apache (la maggior parte) e “chiuderle” in una licenza proprietaria. Samsung, per esempio, sviluppa un suo sistema Android ottimizzato per i suoi dispositivi e lo rilascia con una sua licenza (proprietaria).
Bisogna tenere presente che il software non è un’entità statica e monolitica, bensì un insieme fittissimo di altri software, se per software intendiamo una serie di istruzioni impartite al computer. Per cui, è possibile che nel modello “a cascata” di ridistribuzione, grazie alla disponibilità del codice sorgente completo e alla possibilità di modifica garantite dalla licenza, qualche sviluppatore voglia scorporare il pacchetto software e rielaborarne solo una parte, oppure decida di fare interagire un software di derivazione “open” con un software proprietario.
Quanto detto sinora è utile per comprendere cosa accade quando si decide di voler acquisire software “open” ed eventualmente modificarlo. La prima domanda da porsi è: che cosa ci devo fare con questo software?
Se il suo utilizzo non prevede una distribuzione al pubblico non ci si deve preoccupare di molto perché la licenza “open”, a prescindere dal livello di copyleft forte o debole, consente di modificare il software come si ritiene necessario. Per esempio si acquisisce un software “open” ERP che si utilizzerà solo internamente nella propria struttura aziendale.
Ma se è prevista una distribuzione al pubblico, perché il software “open” è “embedded” in un prodotto o servizio venduto sul mercato? Allora certamente occorre verificare ex ante il livello di copyleft della licenza “open” (se forte o debole) quindi occorre verificare i contenuti di tutte le licenze “inbound” (in ingresso) per capire che cosa accadrà quando, a modifiche effettuate, si deciderà di distribuire il software con le relative licenze “outbound” (in uscita).
La questione è nella pratica anche più complicata perché quasi mai il software è sviluppato direttamente da un’azienda ma viene commissionato in outsourcing e può accadere che il fornitore/sviluppatore inserisca delle parti di codice le cui condizioni sono incompatibili con la licenza outbound decisa dal committente.
Le condizioni di licenza “inbound” possono richiedere che il software sia sotto una determinata licenza o categoria di licenze (outbound), oppure possono addirittura escludere la licenziabilità del software sotto una o più licenze incompatibili.
L’azienda committente, soprattutto in relazione alle dimensioni di un progetto di sviluppo di un software destinato ad un proprio prodotto o servizio venduto/distribuito sul mercato, non può sottovalutare queste implicazioni perché potrebbe incorrere nel rischio di violare le condizioni della (o delle) licenza/e inbound che, in altre parole, vuol dire violare i diritti d’autore ed incorrere in illeciti perseguibili anche con sanzioni penali

  • Di Guglielmo Troiano, Senior Legal Consultant di P4I – Partners4Innovation

  • arrow_upward
  • arrow_downward
  • share
    31 Share