Quando pubblico il codice sorgente sotto una licenza open source rendo pubblica una sola parte del know-how del progetto: il testo del programma. Restano fuori i dati operativi, le procedure di build e di deploy, la conoscenza del dominio applicativo e l’esperienza accumulata nel tenerlo in piedi in produzione. Questi elementi possono restare coperti dalla tutela del know-how, perché la loro protezione poggia sulla segretezza di fatto e non sul regime di copyright del sorgente.

Tengo separate due cose che si confondono spesso: la licenza sotto cui distribuisco il codice e il segreto che eventualmente conservo su tutto ciò che la licenza non copre. Sono due piani giuridici distinti. Chi sa dove passa il confine rilascia con cognizione; chi non lo sa, per disattenzione, finisce per regalare informazioni che restavano legittimamente tutelabili.

Cosa intende il diritto per know-how

La definizione operativa più precisa è quella comunitaria. Il Regolamento CE 772/2004 sugli accordi di trasferimento di tecnologia (art. 1) descrive il know-how come un patrimonio di informazioni pratiche non brevettate, frutto di esperienza e di prove, che sia segreto, sostanziale e individuato:

  • segreto, nel senso che il complesso delle informazioni non è generalmente noto né facilmente accessibile;
  • sostanziale, perché significativo e utile alla produzione dei beni oggetto del contratto;
  • individuato, perché descritto in modo abbastanza completo da poterne verificare segretezza e sostanzialità.

Sul piano internazionale l’Accordo TRIPS (Trade-Related Aspects of Intellectual Property Rights, allegato all’accordo istitutivo dell’OMC, 1994), all’art. 39, obbliga gli Stati membri a proteggere le undisclosed information contro l’uso da parte di terzi in modo contrario alle corrette pratiche commerciali, a tre condizioni cumulative: l’informazione è segreta, ha valore economico proprio perché segreta, ed è stata oggetto di misure ragionevoli per mantenerla tale.

In Italia la tutela si appoggia agli artt. 98 e 99 del Codice della Proprietà Industriale (D.Lgs. 30/2005), che riconoscono le informazioni segrete come oggetto di un diritto di proprietà industriale, e agli artt. 622 e 623 del codice penale, che puniscono la rivelazione del segreto professionale e di quello scientifico o industriale. Il filo che tiene insieme tutte queste fonti è la condizione di segretezza: caduta quella, cade la tutela.

Cosa pubblica davvero una licenza open source

L’Open Source Definition mantenuta dalla Open Source Initiative richiede, tra le altre cose, la disponibilità del codice sorgente e la libertà di creare opere derivate. La licenza agisce sul diritto d’autore del codice: concede permessi di uso, copia, modifica e ridistribuzione che il copyright altrimenti riserverebbe all’autore. Non agisce, e non può agire, su informazioni che nel codice non compaiono.

Una licenza copyleft forte come la GNU General Public License v3 (29 giugno 2007) porta questo principio fino a vietare al distributore di imporre further restrictions ai diritti concessi: chi distribuisce un’opera coperta da GPL non può sovrapporvi un accordo di riservatezza che ne limiti la ridistribuzione. Ma il vincolo riguarda il sorgente distribuito e le sue opere derivate, non l’intero patrimonio conoscitivo di chi lo ha scritto.

Da qui la distinzione operativa più importante:

  • quando distribuisco un binario GPL devo rendere disponibile il corresponding source, cioè il codice che serve a costruire quel binario. Questo diventa pubblico;
  • tutto ciò che non serve a riprodurre il binario distribuito può restare fuori: i dataset proprietari su cui gira il software, le configurazioni di tuning per un carico specifico, i runbook operativi, i risultati delle prove che hanno portato a una certa scelta architetturale.

Il caso emblematico è la cosiddetta tivoization, contro cui la GPLv3 ha introdotto difese esplicite: un dispositivo distribuisce il sorgente conforme alla licenza ma blocca l’esecuzione delle versioni modificate, accettando solo firmware firmato dal produttore. Il sorgente è pubblico; la chiave di firma — il know-how operativo che lascia il controllo del dispositivo al solo produttore — non lo è. La GPLv3 reagisce richiedendo le installation information, ma il principio resta lo stesso: pubblicare il codice non vuol dire pubblicare tutto ciò che serve a farlo funzionare.

L’architettura della protezione residua

Per chi tiene un progetto open source, la tutela del know-how residuo si regge sempre sullo stesso requisito — misure ragionevoli per mantenere segrete le informazioni che restano fuori dal rilascio — e agisce su tre fronti.

Verso dipendenti e collaboratori. L’art. 2105 c.c. impone al prestatore di lavoro un obbligo di fedeltà che gli vieta di divulgare e di usare a fini concorrenziali le informazioni sull’organizzazione e sui metodi di produzione dell’impresa. La Cassazione (sent. n. 25008/2001, in materia di rivelazione di segreti industriali ex art. 623 c.p.) ha riconosciuto la portata ultrattiva delle clausole di riservatezza, che vincolano anche dopo la fine del rapporto. Che il codice sia pubblico non scioglie il dipendente dall’obbligo sulle parti che pubbliche non sono.

Verso i terzi licenziatari. Quando il know-how esce dall’azienda — in un accordo di supporto, di integrazione o di doppia licenza — lo strumento è il contratto di licenza, che il diritto comunitario distingue in accordi di solo know-how e accordi misti know-how/brevetti. L’obbligo di riservatezza sulle informazioni ricevute fa parte del contratto anche senza una clausola espressa: senza segretezza il know-how non esiste, e questo il contratto lo dà per scontato.

Sul perimetro tecnico del rilascio. Scegliere quali file versionare e quali tenere fuori dal repository pubblico è la prima misura di salvaguardia. Una chiave privata, un endpoint interno o un parametro calibrato che finiscono per errore nella history di un repository pubblico smettono di essere segreti: la divulgazione, anche colposa, fa venir meno la condizione di segretezza richiesta da TRIPS art. 39, lett. (c), e dal Reg. CE 772/2004.

Implicazioni operative

Chi rilascia software open source dovrebbe trattare il confine tra sorgente pubblicato e know-how riservato come una decisione di progetto, presa prima del primo commit pubblico e non dopo. In pratica:

  • mappare quali informazioni servono a riprodurre il binario distribuito (queste seguono la licenza) e quali no (queste possono restare segrete);
  • non versionare credenziali, dati di prova proprietari, configurazioni di produzione: una volta nella history pubblica, sono divulgate;
  • mantenere le clausole di riservatezza nei rapporti di lavoro e nei contratti con i terzi anche per i progetti aperti, perché coprono ciò che la licenza non tocca;
  • documentare le misure adottate, perché la tutela ex art. 98 c.p.i. e TRIPS art. 39 presuppone di poter dimostrare le reasonable steps prese per mantenere il segreto.

Limiti

La segretezza non è un diritto esclusivo. A differenza del brevetto, che protegge anche contro chi sia arrivato alla stessa soluzione per conto suo, il know-how è protetto solo contro l’acquisizione o l’uso scorretto: il reverse engineering lecito di un binario rilasciato, o lo sviluppo indipendente della stessa conoscenza, restano legittimi. Quando un’informazione diventa generalmente nota o facilmente accessibile — per una pubblicazione altrui o per una fuga involontaria — la tutela cessa e non si ripristina.

Un’ultima avvertenza: le fonti richiamate qui fissano principi, non automatismi. Stabilire se una specifica informazione sia know-how protetto, e se una specifica clausola sia efficace, resta una valutazione caso per caso, che esce dai confini di questa nota tecnica e richiede il parere di chi cura la materia legale.

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32004R0772 https://www.wto.org/english/docs_e/legal_e/27-trips_04d_e.htm https://www.gnu.org/licenses/gpl-3.0.html https://opensource.org/osd https://www.noze.it/insights/know-how-proprieta-intellettuale/

Immagine di copertina: Il caveau metallico che custodisce la formula segreta della Coca-Cola, esposto al World of Coca-Cola di Atlanta — foto di Mx. Granger, CC0 — https://commons.wikimedia.org/wiki/File:Vault_of_the_Secret_Formula_at_the_World_of_Coca-Cola.jpg