Negli ultimi anni ho tenuto diversi interventi sul FOSS. Ho avuto diverse platee - studenti del corso di diritto delle nuove tecnologie dell’Università di Padova, colleghi avvocati, sviluppatori, etc. – e diversi contesti – per esempio gli incontri di Developers in Vicenza e Programmers in Padua, oppure formazione all’interno di aziende.
Nel tempo ho notato però alcune aree in cui dubbi e domande si vanno a concentrare. Non è una sorpresa che molte di queste riguardino le licenze FOSS copyleft. Si tratta delle licenze, chiamate anche ‘virali’ per il loro effetto di ‘contagio’ (un nome che in questo periodo di pandemia risulta particolarmente allarmante), ovvero per il requisito che prodotti derivati dal codice originario siano distribuiti sotto i termini della medesima licenza copyleft, con esclusione di qualsiasi altra licenza (non solo proprietarie ma anche altre licenze open). Per chi sentisse l’esigenza di un ripasso veloce sui temi delle licenze software e del copyleft prima di proseguire nella lettura, ne ho parlato rispettivamente qui e qui.
No, la contribuzione al progetto rimane una scelta libera e non un obbligo, anche nel caso di licenza FOSS copyleft.
Su questo punto non mi stanco mai di ripetere due chiarimenti.
Il primo, la clausola copyleft ha effetti solamente nel caso in cui il codice oggetto della licenza originaria venga distribuito nella sua versione modificata. In particolare, e per semplificazione, il codice sorgente (incluso quello delle modifiche) deve essere consegnato e/o messo a disposizione di chi riceve una copia dell’eseguibile licenziato con licenza FOSS copyleft. Se, invece, il codice modificato viene utilizzato per scopi meramente interni e non distribuito, non sorge alcun obbligo connesso alla natura copyleft della licenza originaria.
Il secondo, anche nel caso di distribuzione della versione modificata, lo sviluppatore non è tenuto a contattare i maintainer del progetto presentando le proprie modifiche affinché vengano incluse nella release successiva. Gli obblighi (essenzialmente quelli del paragrafo che precede) si applicano solo nei confronti dei soggetti a cui viene distribuita la versione modificata.
Intendiamoci, non voglio sconsigliarvi di contribuire ai progetti su cui vi basate per le vostre modifiche, che anzi risponde alla filosofia e approccio open. Tenete solo presente che non si tratta di un obbligo.
Il pensiero implicito dietro la domanda è che, siccome (i) la licenza FOSS copyleft richiede di distribuire eventuali versioni modificate del software sotto la stessa licenza, e (ii) successive release del software devono essere considerate modifiche al software originario, allora debba continuare ad applicarsi la stessa licenza FOSS copyleft originaria.
Questa ricostruzione però non considera che l’azienda è la titolare del diritto d’autore sul software. La titolarità del diritto non viene limitata dalla decisione di distribuire il software sotto licenza FOSS copyleft. L’azienda, quindi, in quanto titolare del diritto può decidere in qualsiasi momento di cambiare il modello di licenza, non solo su successive release ma anche rispetto al medesimo software. Non è raro che lo stesso prodotto venga licenziato con doppio binario, da una parte con licenza FOSS copyleft e dall’altra con licenza proprietaria, a volte con inclusione di features aggiuntive ma altre volte al solo fine di consentire ai terzi interessati alla licenza di includere il software in un progetto più ampio, senza temere gli effetti virali della licenza FOSS copyleft.
Per chiarezza, le copie già distribuite con licenza FOSS copyleft invece rimangono sottoposte alla licenza originaria. Il cambio dal modello open a quello proprietario si applica alle copie distribuite successivamente.
La domanda forse esula un po’ dallo specifico tema FOSS, ma trattandosi di sviluppo software e visto che è tra le domande che ricevo più frequentemente in assoluto, ho deciso di includerla comunque.
Il tema è preso in considerazione dalla legge sul diritto di autore (L. n. 633/1941) che prevede all’art. 12bis che “il datore di lavoro è titolare del diritto esclusivo di utilizzazione economica del programma per elaboratore o della banca dati creati dal lavoratore dipendente nell’esecuzione delle sue mansioni o su istruzioni impartite dallo stesso datore di lavoro”.
La regola si applica solo nel caso in cui siano presenti tutti i requisiti, ovvero (i) che lo sviluppatore sia un lavoratore dipendente; e (ii) che abbia sviluppato il software nell’esecuzione delle proprie mansioni, oppure comunque su istruzioni impartite dal datore di lavoro.
Rimane possibile trovare un accordo diverso con il datore di lavoro, che però dovrà essere negoziato e documentato in forma scritta, con una certa precisione rispetto alla titolarità dei diritti sul software e la relativa regolamentazione, per evitare controversie future. Se non è prevista una deroga esplicita, allora si applicano le previsioni della legge sul diritto d’autore e i diritti economici sul software spetteranno al datore di lavoro.
Segnalo per completezza che anche nei contratti di lavoro autonomo si pone il tema della titolarità dei diritti sul software sviluppato, e che solitamente viene previsto che questi spettino a chi ha conferito l’incarico. Nel caso in cui il contratto non preveda nulla, però, al contrario di quanto avviene per i contratti di lavoro dipendente, è più difficile sostenere che il committente goda di diritti esclusivi.
Avv. Cosetta Masi - EOSS founder & L2B Partners Junior Partner
Sappiamo cosa sono le licenze software (se non lo sapete, o ve lo siete dimenticato, ne ho parlato in questo post). Le licenze però non sono tutte uguali – neppure all’interno della categoria Open Source. La differenza più nota è tra licenze non-copyleft (o permissive) e licenze copyleft (o non permissive).
Facciamo un passo indietro: cosa sono le licenze Open Source? Solitamente si fa riferimento alla definizione fornita dall’Open Source Initiative (OSI), in particolare all’elenco delle caratteristiche obbligatorie per poter classificare una licenza come Open Source.
Ecco le principali:
1. Distribuzione. La licenza deve dare il diritto di ridistribuire il software, da solo o come parte di un lavoro più complesso;
2. Codice Sorgente. La licenza deve prevedere il diritto di ricevere il codice sorgente del software;
3. Diritto di modificare. La licenza deve prevedere il diritto di modificare il codice e di distribuirlo nella versione modificata;
4. Gratuità. La licenza non può prevedere il pagamento di un compenso.
I punti dell’elenco creato da OSI sono 10, ma diciamo che questi sono i più caratterizzanti.
La differenza tra licenze copyleft e non copyleft ruota attorno ai punti 1 e 2: ovvero la modifica (o la creazione di lavori complessi) e la redistribuzione del software.
Nel caso di licenze non- copyleft, il codice potrà essere modificato e/o utilizzato come parte di progetti più ampi, e il risultato potrà essere distribuito sotto una licenza liberamente scelta dall’autore delle modifiche e/o del progetto (anche una licenza proprietaria).
Nel caso di licenze copyleft, invece, eventuali modifiche o lavori complessi dovranno essere redistribuiti utilizzando la medesima licenza. A volte si parla di effetto ‘virale’ delle licenze copyleft, in quanto ‘contagiano’ gli ulteriori elementi di software con cui vengono combinate.
Esempi classici delle prime sono le licenze MIT, BSD (in tutte le versioni) e Apache. Per quanto riguarda le licenze copyleft, possiamo pensare alle licenze della famiglia GPL (Gnu Public License).
Ma qual è il perimetro dell’effetto virale delle licenze copyleft? Nel caso di modifiche al codice originario, non c’è margine per dubbi e sarà necessario applicare la licenza originaria. Nel caso di lavori complessi, invece, diventa più difficile individuare i confini e viene in rilievo il concetto di ‘programmi derivati’. Sorpresa sorpresa: non esiste una definizione univoca, ma possiamo comunque trovare qualche linea guida. Per esempio, se il lavoro complesso contenente anche codice licenziato sotto una licenza copyleft viene poi compilato in un unico eseguibile, si ritiene con relativa certezza che si tratti di un lavoro derivato che deve quindi essere distribuito con la medesima licenza copyleft. Se, invece, gli eseguibili sono diversi ci sono molti più elementi da tenere in considerazione, e molte meno certezze.
L’effetto espansivo/virale è mitigato nelle licenze cd. ‘weak copyleft’. La più famosa è la LGPL (Lesser Gnu Public License), pensata per le librerie. In questo caso, le modifiche fatte alla libreria devono essere distribuite con la medesima licenza, mentre invece il software esterno che chiama la libreria non verrà considerato un lavoro derivato e potrà continuare ad essere distribuito con una licenza diversa.
Occorre fare attenzione alla licenza di librerie e altre componenti software che vengono utilizzate in un progetto, e alla possibilità che una licenza copyleft ‘contagi’ un intero progetto, escludendo non solo la possibilità di distribuirlo con licenza proprietaria, ma di distribuirlo con qualsiasi licenza diversa dalla licenza originaria. Naturalmente, per le realtà che basano il proprio modello di business sull’ottenere un pagamento per concedere licenze, questo sarebbe un problema molto serio.
D’altra parte, i modelli di business possono essere diversi. Il software di per sé potrebbe continuare a essere concesso con licenza Open Source (la licenza copyleft di cui si diceva), senza ottenere alcun pagamento. La remunerazione potrebbe essere collegata a servizi di installazione e/o supporto sul software, così come dalla fornitura di garanzia o altro tipo di utilità.
Un chiarimento. È sbagliato pensare che con una licenza permissiva (non copyleft) la libertà sul software sia assoluta. Anche questo tipo di licenze prevedono obblighi. Per esempio, la versione semplificata della licenza BSD (quella ridotta a due clausole) richiede che siano riportate in tutte le copie del software (i) il testo della licenza – ed in particolare l’esclusione di garanzia; e (ii) la copyright notice. Quindi, tutte le licenze – per quanto open – prevedono alcuni obblighi per chi ne fa uso…senza entrare qui nel merito della folcloristica ‘do the fuck you want public license’ che, più che un concreto modello di licenza, sembra voler essere un atto di ribellione verso la rigidità e il dilagare delle licenze copyleft.
Avv. Cosetta Masi - Studio Masi https://www.avvocatomasi.com/
