L’argomento è molto ampio e ci sarebbe moltissimo da dire. Fare ordine non è facile ma abbiamo scelto di dedicare questo primo post legale ad un tema generale per non entrare subito in dettagli e temi di nicchia, senza avere prima offerto gli strumenti generali per capire gli aspetti legali del FOSS – in particolare le licenze open source.
Dal punto di vista legale la licenza è un testo, indipendentemente dal formato, in cui lo sviluppatore del software elenca i diritti degli utilizzatori del software, insieme anche agli obblighi che questi devono rispettare.
La licenza è quel testo che a volte compare al primo utilizzo di un software e che accettiamo tendenzialmente senza leggere.
La licenza è il contratto che due società firmano, perché una possa utilizzare un prodotto software creato dall’altra.
La licenza è quel testo che viene conservato insieme al codice sorgente in repository come GitHub, a volte sotto titoli parzialmente ingannevoli come ‘README’ o ‘LEGAL’.
In tutti i casi, si tratta di un testo che descrive – a volte in dettaglio o a volte in maniera molto generale – che cosa un utente può fare con un software. Può sembrare astratto ma in realtà si tratta di riflettere su un bene immateriale come il software concetti che sperimentiamo tutti i giorni.
| Locazione (contratto di affitto) | Licenza Software |
| Diritto di proprietà su un immobile | Diritto di proprietà intellettuale su un software (diritto di autore) |
| Viene messo a disposizione di un soggetto, che lo utilizza | Viene messo a disposizione di un soggetto, che lo utilizza |
| Il proprietario prevede dei limiti (es. niente animali, niente lavori di un certo tipo, etc.). | Il proprietario prevede dei limiti (es. divieto di fare copie, possibilità di utilizzare il software solamente in laboratorio, etc.). |
| Il bene (l’immobile) è materiale e può essere messo a disposizione solo di un soggetto. | Il bene (software) è immateriale e può essere messo a disposizione di un numero infinito di soggetti. |
L’autore di un libro di narrativa e lo sviluppatore di un software sono equiparati: il lavoro di entrambi è protetto dal diritto di autore.
Nel caso del software, quindi, viene protetta non la funzionalità, ma l’esatta sequenza di caratteri nel codice sorgente. Se qualcuno li copiasse commetterebbe una violazione del diritto d’autore allo stesso modo di qualcuno che riutilizza, spacciandole per creazione propria, le pagine di un libro scritto da un’altra persona.
Il diritto di proprietà intellettuale che proteggerebbe la funzionalità di un software è il brevetto, ma il tema della brevettabilità del software è oggetto di dibattiti da decenni e di contrapposizioni molto forti. In generale, possiamo considerare brevetti sul software possibili ma molto molto difficili da ottenere, almeno nel sistema europeo (un discorso a parte meriterebbe l’ambito USA).
Due sono soggettivi e uno oggettivo:
1. L’oggetto della licenza, che non è il software in quanto tale ma il diritto d’autore sullo stesso.
2. Chi la concede (licenziante – parola non troppo bella). Si tratta del soggetto che ha sviluppato il software. Può essere una persona, che ha lavorato in proprio, oppure un’azienda, i cui dipendenti hanno sviluppato il software per conto dell’azienda.
Si può anche trattare di un soggetto che ha comprato i diritti sul software in un momento successivo, o che ha a sua volta ricevuto una licenza, che gli dà il diritto di concedere ulteriori licenze a terzi (sublicenze).
È sempre bene verificare che il licenziante abbia effettivamente il potere di concedere una licenza. In caso contrario, il diritto derivato del soggetto che riceve la licenza non può esistere (o non esiste nell’estensione voluta), con tutti i problemi che ne seguono.
3. Chi la riceve (licenziatario – termine ancora poco poetico, ma stiamo migliorando). Si tratta del soggetto che riceve la licenza. Può utilizzare il software solamente come previsto nella licenza stessa.
La licenza è il modello più vecchio con cui si ottiene la possibilità di utilizzare un software. Il modello si sta sempre più spostando verso il software as a service (SAAS), in cui non si ottiene una copia del software installata sul nostro pc da utilizzare come previsto dalla licenza, ma si utilizza/beneficia da remoto di un software che rimane installato su un’infrastruttura di terzi. In questo caso non si parla di licenza ma di un contratto di servizi. Anche nel mondo FOSS questa ipotesi sta prendendo piede, basti pensare alle Affero Gnu Licenses. Ne sono un esempio i TOOLS di Enterprise OSS.
Ho lavorato con sufficienti sviluppatori per sapere che nella maggior parte dei casi, parlando con i tecnici di licenza, il pensiero corre subito a quella parte di codice che abilita/disabilita un software rispetto a quelle funzionalità che un utente non può (o meglio, non ha pagato per) utilizzare. Abbiamo visto che dal punto di vista legale, e direi anche generale, è una cosa diversa.
Inoltre, non è detto che modalità di utilizzo non concesse dalla licenza (testo) possano essere bloccate dalla licenza (software) – in alcuni casi non esiste uno strumento tecnico per farlo. Pensiamo al caso di un software per la gestione di e-books, che viene utilizzato per leggere libri ottenuti illegalmente.
In generale comunque la licenza (software) è uno strumento per far valere i limiti imposti dalla licenza (testo).
Cosetta Masi
Io e mio figlio quando dobbiamo aggiustare qualcosa guardiamo su YouTube how fix per capire come fare e poi guardiamo nella cassetta degli attrezzi se abbiamo quello che serve.
Capita spesso di non avere gli strumenti giusti, i motivi principali sono:
• la mancanza
• la specificità quindi la scarsa reperibilità
• il fatto che sono "closed" quindi non disponibili se non agli addetti ai lavori della società produttrice
Superato un primo momento di frustrazione l'unica soluzione è ingegnarsi e "cercare di fare quello che si deve con ciò che si ha", con enorme fatica e dispendio di tempo ed energia, raggiungendo l'obiettivo come si può.
Naturalmente tutto questo guardando il video e cercando di intercettare il punto giusto dove operare.
Quindi ricapitolando servono attrezzi giusti, documentazione giusta e capire quando intervenire e come saper utilizzare gli attrezzi.
Noi di Corsinvest amiamo le cose semplici e lineari, per questo: ”come lo vogliano per noi, ci impegniamo a crearlo per gli altri”. Quindi i nostri software devono essere semplici da capire, facili da installare ed usare, ben documentati e con supporto.
Nel Dicembre del 2016 abbiamo rilasciato Open Source il primo progetto legato a Proxmox VE https://github.com/Corsinvest/cv4pve-autosnap
Questo software permette di creare snapshot di una “Macchina Virtuale” automaticamente specificando una retention, una protezione continua dei dati. Nel frattempo un secondo progetto era partito https://github.com/Corsinvest/cv4pve-barc . Altri progetti seguirono.
Con nostra sorpresa i software hanno riscosso parecchio successo, nelle università (europee (Ginevra) ed americane), nelle strutture statali, svariati datacenter, e molti IT manager.
Con le richieste e segnalazioni della comunità, abbiamo migliorato il prodotto e capito che le idee erano ottime ma la strada percorsa per l'implementazione non era ottimale per questo forte legame interno con Proxmox VE.
Volevamo abbracciare altre filosofie:
• Zero configurazione in Proxmox VE
• Utilizzo di API
• Utilizzabile esternamente a Proxmox VE
• Eseguibile su qualsiasi Sistema Operativo, Windows, Linux, MacOS
• Installazione zero
• Download and run
• Script hook esterni configurabili
• Per più linguaggi (non esitiamo solo noi)
Bisognava partire da zero, ritornare sui propri passi, partire dalla base quindi dalle API. Non contenti di quello che veniva offerto, non compatibile con l’idea Corsinvest abbiamo deciso di creare noi i client API.
• cv4pve-api, client API per vari linguaggi .Net (C#), Java, Php (facili, documentati, aggiornati)
Non è una persona fisica che li crea (come fanno tutti), ma un robot creato da noi, che leggendo la documentazione genera i client. Stiamo aggiornando il nostro robot per la generazione in altri linguaggi Go, Python, Ruby, Rust, Javascript
• cv4pve-autosnap ora riscritto da zero in .Net è stato il primo
E molti altri.
Durante lo sviluppo e dopo la pubblicazione degli strumenti Proxmox su Github non riuscivamo a capire perché i nostri software non venissero copiati o clonati da altri. Ci siamo confrontati ed è emerso che quello che noi davamo per scontato per tanti non lo è (questo è un difetto italiano).
Diamo per scontato che tutto ciò che facciamo sia facile ma non è così. Le conoscenze le competenze acquisite hanno un peso e salire ogni singolo gradino per arrivare alla fine della scala costa.
Noi ci siamo arrivati, non con pochi sacrifici, per questo altri piuttosto che spendere tempo nel capire, preferiscono avere un prodotto già pronto.
Continuiamo a manutenere e supportare i nostri progetti su https://github.com/Corsinvest, dove chiunque può scaricare e installare rispettando le licenze Open Source che abbiamo deciso di utilizzare.
Per un supporto Enterprise in mainstream e per tutte quelle strutture che lo richiedono, abbiamo creato una suite per Proxmox VE https://www.corsinvest.it/cv4pve-tools
"Non esiste buono o cattivo tempo, ma solo buono o cattivo equipaggiamento.”
Robert Baden-Powell
Daniele Corsini - Programmatore e titolare di Corsinvest e fondatore di Enterprise OSS
