Quasi ogni azienda che sviluppa software usa componenti open source, spesso in quantità che nessuno ha mai contato. Molte, inoltre, hanno sviluppatori che correggono bug in progetti esterni o vorrebbero pubblicare strumenti interni. Senza regole, ognuna di queste attività viene gestita caso per caso, con risultati incoerenti: un team pubblica liberamente, un altro chiede il permesso all'ufficio legale per una correzione di due righe. Una policy interna e, nelle organizzazioni più grandi, un Open Source Program Office servono a rendere queste attività prevedibili.
Le tre attività da regolare
Una policy efficace distingue tre situazioni, perché i rischi sono diversi.
Usare componenti open source
È l'attività più frequente e quella con il rischio più concreto. Le domande da coprire:
- quali licenze sono ammesse senza approvazione, quali richiedono una verifica e quali sono escluse per certi tipi di prodotto;
- come si registra l'uso di un componente, per esempio con un inventario o una SBOM generata automaticamente;
- come si gestiscono gli aggiornamenti di sicurezza delle dipendenze.
Un approccio pratico è una tabella a semaforo:
| Categoria | Esempi | Regola |
|---|---|---|
| Verde | MIT, BSD, Apache 2.0 | Ammesse, con rispetto degli obblighi di attribuzione |
| Gialla | LGPL, MPL, EPL | Ammesse con verifica del modo di integrazione |
| Rossa | GPL e AGPL in prodotti distribuiti chiusi, licenze source-available | Richiedono approvazione esplicita |
Contribuire a progetti esterni
Qui il rischio principale è cedere involontariamente diritti dell'azienda o divulgare informazioni riservate. La policy dovrebbe indicare:
- se i dipendenti possono contribuire in orario di lavoro e con quale account;
- chi può firmare CLA aziendali per conto dell'azienda;
- quali contributi richiedono revisione preventiva, per esempio quelli che toccano tecnologie brevettate o segreti industriali;
- che le correzioni piccole non richiedono approvazione, per non scoraggiare chi contribuisce.
Pubblicare progetti propri
Rendere pubblico uno strumento interno è una scelta che coinvolge più funzioni. Prima della pubblicazione servono controlli precisi:
- pulizia del codice: nessuna password, chiave, indirizzo interno o nome di cliente, anche nella storia del repository;
- verifica delle dipendenze e della compatibilità delle loro licenze con quella scelta;
- scelta della licenza coerente con gli obiettivi;
- file di base: README, licenza,
CONTRIBUTING.md,SECURITY.md, codice di condotta; - responsabilità: chi manterrà il progetto e con quanto tempo.
Il quinto punto è il più trascurato. Pubblicare un progetto e abbandonarlo dopo sei mesi danneggia la reputazione dell'azienda più che non pubblicarlo affatto.
Che cos'è un OSPO
Un Open Source Program Office è una funzione, a volte una persona sola, a volte un piccolo gruppo, che coordina tutto ciò che riguarda l'open source in azienda. I compiti tipici sono:
- scrivere e aggiornare la policy;
- fare da punto di contatto tra sviluppatori, ufficio legale e sicurezza;
- mantenere l'inventario dei componenti usati;
- approvare i casi dubbi in tempi rapidi;
- decidere quali progetti esterni sostenere con contributi o finanziamenti;
- formare i team su licenze e buone pratiche.
Un'azienda piccola non ha bisogno di un ufficio: basta indicare una persona di riferimento e un processo leggero. Ciò che conta è che le domande abbiano un destinatario e una risposta in tempi ragionevoli, e che le decisioni prese vengano annotate in un unico posto, così che i casi simili successivi si risolvano senza ripartire da zero.
Errori frequenti nelle policy
- Vietare tutto per prudenza: gli sviluppatori aggirano le regole e l'azienda perde visibilità su cosa usa.
- Approvazioni lente: se servono tre settimane per approvare una libreria, nessuno chiederà.
- Ignorare le dipendenze transitive: la libreria approvata può portarsene dietro decine di altre con licenze diverse.
- Trattare i contributi come un rischio e basta: contribuire alle dipendenze critiche riduce il costo di mantenere correzioni interne.
Nel mio lavoro, la policy che funziona meglio è quasi sempre breve, con esempi concreti e con un automatismo nella pipeline che fa il controllo al posto delle persone.
In sintesi
- Una policy aziendale deve regolare separatamente uso, contributi e pubblicazione.
- Una tabella a semaforo delle licenze semplifica le decisioni quotidiane.
- Prima di pubblicare servono pulizia del codice, verifica delle dipendenze e un responsabile.
- Un OSPO, o una persona di riferimento, coordina policy, inventario e approvazioni.
- Regole troppo rigide o lente vengono aggirate: meglio poche regole chiare e automatizzate.
