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
Prima di preparare queste poche righe ho fatto l’errore di leggere il blogpost che subito mi precede, scritto da uno dei miei co-founders in Enterprise OSS.
Non si può ‘competere’ in quanto a storytelling, quindi decido di giocarmela sul fronte della brevità. Uso di proposito le virgolette quando parlo di competizione, perché in questo caso la vedo come una rivalità sana e giocosa, che all’interno dell’associazione ci porta a confrontarci con l’obiettivo finale di creare valore per il nostro progetto comune.
Con questa premessa, che già da sola rischia di minare il mio obiettivo di essere sintetica, condivido di seguito qualche riflessione sull’importanza di documentare librerie e altre componenti FOSS utilizzati in un progetto software.
“The Company Technology and the Deliverables do not, and will not, contain any:
(a) viruses, other disabling or damaging codes, or
(b) third party or open source software that is not identified in writing by Company prior to and during the development process;
provided, however, that prior to the use of any third party or open source software, and as a condition thereto, Company will provide to Buyer the completed written list identifying such third party or open source software, as well as the name of the licensor and a copy of or reference to the license terms;
and Company will warrant to Buyer that it shall comply with the terms and conditions of such software”.
Per i non anglofoni, questa è una clausola estrapolata da un contratto di licenza software, che prevede a carico dello sviluppatore
(i) l’obbligo di fornire un elenco scritto di tutte le dipendenze FOSS;
(ii) indicando il licenziatario e i termini della licenza;
(iii) garantendo che tali dipendenze non limitino i diritti di uso previsti dalla licenza.
In questo caso, il ‘Buyer’ era una società con competenze specifiche nel settore, ma clausole di questo tipo stanno sempre più prendendo piede in contratti di licenza o di outsourcing software, anche per incarichi contenuti e/o che non coinvolgono operatori esperti. La tendenza è in questo senso e occorre essere pronti.
In progetti strutturati, ancora di più se sviluppati in team, non è semplice tenere sotto controllo tutte le dipendenze e creare la relativa documentazione. Occorre, quindi, adottare un metodo che permetta di farlo nella maniera più corretta e meno dispendiosa possibile.
Aver individuato le dipendenze FOSS, però, è solo un primo passo. Occorre anche valutarle e assicurarsi che non presentino vincoli o limiti rispetto alla distribuzione del software secondo il modello che lo sviluppatore ha individuato (da ricordare in particolare il tema delle licenze copyleft, di cui abbiamo già parlato qui).
La soluzione è tendenzialmente una sola: PROCEDURE, che siano procedure mentali per uno sviluppatore che lavora da solo – e così sostanzialmente una check-list di aspetti da verificare per ridurre potenziali rischi, o procedure vere e proprie per realtà di più grandi dimensioni – e così documentate in prassi e linee guida interne. Su quest’ultimo fronte, la Linux Foundation mette a disposizione dei template generici di documenti per la compliance FOSS, che potete trovare qui.
Naturalmente, si tratta di bozze generali da adattare al caso concreto…per un’azienda con 3 sviluppatori non ha molto senso adottare un modello come quello proposto da Linux Foundation che prevede un ‘FOSS Steering Commitee’ e un ‘FOSS Compliance Officer’.
Infine, un altro motivo per adottare un approccio attento nell’utilizzo di dipendenze FOSS: sono gli stessi sviluppatori FOSS che chiedono a chi utilizza e/o distribuisce il loro lavoro di adottare alcuni accorgimenti. Queste per esempio le richieste nel caso della semplicissima licenza Free BSD (o BSD 2 clauses): includere in tutte le distribuzioni, che siano codice sorgente o binario:
(i) la copyright notice;
(ii) le condizioni di utilizzo;
(iii) l’esclusione di garanzia.
Le procedure di compliance FOSS sono quindi a servizio di una corretta gestione sia nei confronti dei clienti, che degli sviluppatori originari delle dipendenze.
Avv. Cosetta Masi
