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
