Il 27 luglio 2026 la Commissione europea ha pubblicato la Comunicazione C(2026) 5252 e il suo allegato, una guida all’applicazione del Regolamento (UE) 2024/2847 sulla resilienza informatica. Il documento conta 83 pagine e 67 esempi numerati, e dedica il capitolo 3 — paragrafi da 40 a 89 — al software libero. Il quadro generale per i fabbricanti, con ambito, modifica sostanziale, periodo di supporto e finestre di segnalazione, lo trattiamo su noze in un pezzo del giorno dopo la pubblicazione. Qui guardo solo quel capitolo, perché riguarda chi mantiene software libero senza venderlo e contiene la parte che cambia di più rispetto a come la comunità è abituata a ragionare.

Due condizioni cumulative

L’articolo 3(48) del regolamento definisce il software libero come «software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable». Il paragrafo 44 della guida legge quella frase come due condizioni cumulative: la licenza deve concedere l’intero insieme dei diritti elencati, e il codice sorgente deve essere condiviso apertamente.

La seconda condizione è quella che sposta qualcosa. Il paragrafo 46 chiarisce che «openly shared» significa pubblicamente disponibile, a monte o a valle, e non fornito su base ristretta o condizionata; e ne trae la conseguenza esplicita: software distribuito sotto licenza libera ma il cui sorgente è condiviso solo con clienti paganti o con un gruppo limitato di utenti non è FOSS ai sensi dell’articolo 3(48).

Non è la prima definizione di software libero scritta in un regolamento europeo. Il Regolamento (UE) 2024/903 sull’Europa interoperabile, all’articolo 2(12), definisce già la «licenza open source» come quella che permette riuso, ridistribuzione e modifica per ogni uso sulla base di una dichiarazione unilaterale del titolare, «and where the source code of the software is made available to users indiscriminately». La differenza è che quel testo definisce la licenza, mentre l’articolo 3(48) definisce il software, e ne fa la porta d’ingresso a un regime di conformità con vigilanza del mercato. La Open Source Definition ragiona sui diritti che la licenza concede; questa aggiunge un requisito sul comportamento di chi pubblica. Un progetto può avere una licenza approvata OSI e restare fuori dalla nozione di FOSS del regolamento, se il sorgente non è pubblico.

Chi pubblica e chi contribuisce

Il paragrafo 49 affronta il problema che la comunità si pone da anni quando si parla di responsabilità: in un progetto con molti contributori, chi risponde. La risposta della guida è che il software libero è «under the responsibility» delle persone fisiche o giuridiche che lo pubblicano ed esercitano il controllo principale su sviluppo, rilasci e decisioni di distribuzione, cioè i manutentori. Chi contribuisce codice senza controllare rilasci, roadmap o governance è un contributor, e il software non è sotto la sua responsabilità anche se ne ha scritto una parte. È la distinzione che quindici anni fa non aveva rilevanza giuridica e serviva solo a capire chi ringraziare.

La guida precisa poi che «the mere existence of technical permissions, such as commit access, is not sufficient to establish that the FOSS is under that person’s responsibility». Il permesso di scrittura sul repository non trasferisce la responsabilità. L’Esempio 13 la applica al caso più comune, una pull request con una patch di sicurezza accettata dai manutentori: chi l’ha inviata è un contributore e non è soggetto al regolamento.

Le donazioni

Il regolamento non guarda a come un progetto è stato finanziato ma a se viene monetizzato. I paragrafi 63 e 64 lo dicono per il finanziamento dello sviluppo: che una terza parte abbia pagato, sponsorizzato o altrimenti finanziato lo sviluppo non determina di per sé se il software sia immesso sul mercato, perché — richiamando il considerando 18 — le circostanze dello sviluppo e le modalità del suo finanziamento non vanno prese in considerazione nel determinare la natura commerciale dell’attività.

Sulle donazioni la guida è più esplicita di quanto ci si aspetterebbe. Il paragrafo 61 afferma che il solo fatto di includere un link a una piattaforma di donazioni non va letto come intenzione di lucro anche quando l’importo raccolto eccede i costi di progettazione, sviluppo e fornitura, e che questo comprende la remunerazione ragionevole dei contributori assunti da una persona giuridica e le spese di sostentamento ragionevoli di una persona fisica. La conclusione testuale è che un progetto sostenuto solo da donazioni «is therefore unlikely to be considered to be placed on the market».

Lo stesso vale per il supporto tecnico offerto a copertura dei costi: il paragrafo 58 include fra i costi effettivi recuperabili «the person’s reasonable living expenses», quindi una persona fisica che pubblica software libero e offre assistenza tecnica per coprire i propri costi e ottenere un compenso equo non immette per ciò solo il software sul mercato.

Il confine cade dove la donazione diventa di fatto un prezzo. Il paragrafo 62 e i due esempi che lo accompagnano lo collocano con precisione: se le release scaricabili e gli aggiornamenti di sicurezza vanno solo a chi dona (Esempio 21), o se i binari precompilati e le correzioni garantite sono riservati ai donatori mentre il sorgente resta pubblico (Esempio 22), allora la donazione è remunerazione e il software è immesso sul mercato.

Enti senza scopo di lucro, fondazioni, steward

Il paragrafo 66 tratta le persone giuridiche senza scopo di lucro costituite in modo da destinare tutti i proventi al netto dei costi a finalità non lucrative: il software che pubblicano non è considerato immesso sul mercato. L’Esempio 24 lo illustra con un browser libero monetizzato tramite accordi con motori di ricerca i cui utili vanno a finalità non lucrative, e conclude che quel soggetto non immette sul mercato ma è soggetto agli obblighi degli steward.

Lo steward è la categoria che l’articolo 3(14) introduce per i casi in cui il software libero è pubblicato ma non immesso sul mercato: una persona giuridica, diversa da un fabbricante, che ha lo scopo di fornire sistematicamente sostegno continuativo allo sviluppo di software libero destinato ad attività commerciali e ne assicura la sostenibilità. Il paragrafo 78 vi fa rientrare le fondazioni che offrono piattaforme di collaborazione con forme di governance che permettono ai fabbricanti di contribuire regolarmente, o che sono regolarmente finanziate da fabbricanti.

Due precisazioni evitano la lettura sbagliata, che sarebbe di attribuire lo status all’ente invece che al progetto. Lo status si valuta progetto per progetto: il paragrafo 72 stabilisce che essere steward di un software libero non implica esserlo di altri pubblicati dallo stesso soggetto, e il 73 che la stessa persona giuridica può essere steward di un progetto e fabbricante di un altro. Il caso tipico è quello di chi pubblica una versione community e una a pagamento dello stesso software: steward della prima, fabbricante della seconda.

Tre livelli di sostegno, tre insiemi di obblighi

La parte operativa è il paragrafo 79, che distingue il tipo di sostegno continuativo e ne fa discendere obblighi diversi per il tramite dell’articolo 24(3). Tutti gli steward devono comunque rispettare l’articolo 24(1) e (2), cioè dotarsi di una politica di cibersicurezza documentata in modo verificabile e cooperare con le autorità di vigilanza del mercato. La documentazione richiesta è dello stesso genere di quella che il regolamento chiede ai fabbricanti, dove l’obbligo che conta è che qualcuno la verifichi davvero.

  • Solo sostegno non tecnico — gestione del marchio, regole di governance, eventi, raccolta di donazioni. Il paragrafo 80: non essendo coinvolto nello sviluppo, questo steward non è tenuto a segnalare le vulnerabilità sfruttate attivamente, e non fornendo sistemi di rete e informativi non è tenuto a segnalare incidenti gravi. Se viene a conoscenza di una vulnerabilità sfruttata attivamente dovrebbe condividerla con i manutentori.
  • Infrastruttura informatica — repository, sistemi di versionamento, generazione delle chiavi di firma. Il paragrafo 81: è tenuto a notificare a ENISA e ai CSIRT, ai sensi dell’articolo 14(3), gli incidenti gravi relativi a quell’infrastruttura che abbiano impatto sulla sicurezza dei prodotti, e a informare gli utenti quando opportuno.
  • Risorse di ingegneria — sviluppatori assunti, coordinamento dello sviluppo, revisione e merge del codice, gestione dei rilasci, gestione delle segnalazioni di vulnerabilità e delle patch. Il paragrafo 82: è tenuto a notificare ai sensi dell’articolo 14(1) le vulnerabilità sfruttate attivamente di cui viene a conoscenza, a informare tutti gli utenti quando opportuno, e a informare direttamente gli utenti impattati quando ha con loro un rapporto diretto, ai sensi dell’articolo 14(8).

È la scala che permette a una fondazione di capire in quale scaglione cade, e non dipende dalle dimensioni ma da cosa concretamente fa per quel progetto.

La data che il testo non dice

Su questo punto i due testi non danno una risposta univoca.

L’articolo 71(2) del regolamento stabilisce che il testo si applica dall’11 dicembre 2027, con due anticipazioni: «However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026». L’articolo 24, che contiene gli obblighi degli steward, non è fra le norme anticipate.

L’articolo 14 però si intitola «Reporting obligations of manufacturers» e al primo comma dispone che «a manufacturer shall notify». Per come è formulato vincola i fabbricanti. Lo steward ci arriva soltanto attraverso l’articolo 24(3), che estende agli steward gli obblighi dell’articolo 14(1), (3) e (8) nei limiti visti sopra.

Ne discende una domanda che il regolamento non chiude: se l’obbligo di segnalazione raggiunge lo steward tramite una norma che si applica dal dicembre 2027, l’anticipazione al settembre 2026 lo tocca? La lettura più aderente al testo è che non lo tocchi, perché l’articolo 14 da solo non si rivolge agli steward. Si può sostenere anche la lettura opposta, che tratta l’articolo 24(3) come una regola sull’ampiezza di obblighi che viaggiano con la norma anticipata. La guida della Commissione discute gli steward dentro la sezione dedicata all’articolo 14 senza affrontare il punto.

Per un manutentore la differenza è di quindici mesi, e allo stato non si ricava dai documenti pubblicati.

Limiti

Quanto sopra è la lettura di due testi, il regolamento e una guida. La guida stessa dichiara al paragrafo 89 che gli scenari del capitolo sono del tutto ipotetici, e una comunicazione della Commissione non vincola i giudici: l’interpretazione definitiva delle definizioni dell’articolo 3 spetta alla Corte di giustizia, e le autorità nazionali di vigilanza potranno discostarsene.

Non esiste un censimento di quante fondazioni o quanti progetti ricadano nella definizione di steward, quindi qualunque numero in proposito sarebbe inventato. Non ho verificato quali norme armonizzate a supporto del regolamento siano state citate in Gazzetta ufficiale, e non lo affermo. E la classificazione di un singolo progetto dipende da circostanze che stanno fuori dai documenti — chi controlla i rilasci, come è costituito l’ente, cosa esattamente riceve chi dona — quindi le tre categorie qui descritte servono a leggere il proprio caso, non a chiuderlo.

Immagine di copertina: apparato per la misura di linee di base, Gebrüder Brunner, Parigi 1876-1878, esposto dal GeoForschungsZentrum di Potsdam — fotografia di Bautsch, CC0 — https://commons.wikimedia.org/wiki/File:Basisapparat.Gebrueder.Brunner.Paris.1878.jpg