Un software libero si definisce attraverso quattro libertà fondamentali: eseguire il programma, studiare il suo codice sorgente, redistribuirlo e distribuire versioni modificate. Questa base giuridica e tecnica, formalizzata dalla Free Software Foundation, struttura oggi un ecosistema che supera di gran lunga il cerchio degli sviluppatori. Le notizie digitali del 2026 mostrano che l’open source è ormai una questione regolamentare, industriale e geopolitica a tutti gli effetti.
Cyber Resilience Act: cosa cambia il CRA per i progetti open source
Dal 11 settembre 2026, gli obblighi di segnalazione del Cyber Resilience Act (CRA) europeo sono entrati in vigore. I produttori di prodotti contenenti elementi digitali devono notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi, secondo un calendario scaglionato fino al 2027.
Il punto più strutturante per il mondo del software libero riguarda la creazione di una categoria giuridica specifica: gli open source software stewards. Questo termine designa le entità che sostengono in modo sistematico e duraturo un progetto open source a finalità commerciale. Gli sviluppatori individuali e i collaboratori volontari rimangono al di fuori del campo delle obbligazioni.
La distinzione sembra chiara sulla carta, ma solleva domande concrete. Un attore che pubblica e mantiene regolarmente su espacelibre.net risorse attorno ai software liberi non ha lo stesso status di un’azienda che integra un componente open source in un prodotto venduto. In quest’ultimo caso, l’integratore può passare allo status di “manufacturer” con obblighi di conformità completi, anche se il codice iniziale è libero.
Questa frontiera tra uso non commerciale e catena di approvvigionamento commercializzata è diventata il vero tema di conformità nel 2026. Diverse analisi giuridiche pubblicate negli ultimi mesi sottolineano che l’integrazione di un componente libero in un prodotto venduto trasforma lo status giuridico dell’attore.
Sicurezza della supply chain software: un cantiere open source prioritario
La moltiplicazione degli attacchi mirati alla catena di approvvigionamento software ha spinto la comunità open source a strutturare le proprie pratiche di sicurezza.
Il principio centrale è la tracciabilità: ogni componente integrato in un software deve poter essere identificato, versionato e auditato. I SBOM (Software Bill of Materials) diventano uno standard atteso dai committenti, siano essi pubblici o privati.
- La generazione e l’aggiornamento di un SBOM per ogni versione pubblicata consentono di identificare rapidamente un componente vulnerabile nella catena di dipendenze.
- Gli strumenti di firma crittografica del codice (come Sigstore) si stanno diffondendo per garantire l’integrità dei pacchetti distribuiti.
Per le aziende utilizzatrici di componenti open source, la questione non è più se debbano auditare le proprie dipendenze, ma con quale frequenza e con quali strumenti. La sicurezza della supply chain software condiziona ormai l’accesso al mercato europeo.
Sovranità digitale europea e software liberi: oltre il discorso
L’Unione europea ha avviato una consultazione per strutturare il proprio ecosistema di software liberi, in un contesto in cui la sovranità digitale rimane ampiamente dipendente da infrastrutture cloud americane. Il dibattito supera la semplice preferenza tecnica: si tratta di sapere chi controlla il codice delle infrastrutture critiche.
Da parte delle collettività, il movimento di migrazione verso soluzioni libere continua. Lo Stato francese mantiene una base interministeriale di software liberi raccomandati, che supera le cinquecento referenze. Questo catalogo copre usi che vanno dalla produttività alla gestione di database, passando per la messaggistica e gli strumenti collaborativi.
Il principale ostacolo rimane la dipendenza dai formati proprietari e dall’ecosistema applicativo dei grandi editori. Migrare un posto di lavoro verso LibreOffice o Thunderbird non presenta difficoltà tecniche maggiori, ma l’interoperabilità con i partner esterni che utilizzano suite proprietarie genera costi di attrito ben reali.
IA e open source: trasparenza contro “open washing”
L’intelligenza artificiale è diventata il terreno di confronto più visibile tra approcci aperti e chiusi. Diverse organizzazioni, tra cui l’Open Source Initiative (OSI), hanno lanciato allerta sulla pratica di presentare modelli di IA come open source mentre pubblicano solo i pesi della rete, senza i dati di addestramento né il codice completo della pipeline.
Il termine “open weights” non significa open source nel senso delle quattro libertà fondamentali. Un modello i cui pesi sono pubblici ma i cui dati di addestramento rimangono segreti non consente né la riproducibilità né l’audit indipendente. Questa distinzione tecnica ha conseguenze dirette sulla fiducia che gli utenti e i regolatori possono accordare a questi sistemi.
- L’EU AI Act, di cui alcune scadenze di conformità arrivano nel 2026, impone requisiti di trasparenza che vanno oltre la semplice pubblicazione dei pesi.
- Progetti come quelli portati avanti dalla Linux Foundation lavorano per definire standard aperti per la certificazione degli agenti IA, con un principio riassunto dalla formula “non fidarti, verifica”.
La battaglia dell’IA open source si gioca sulla stessa definizione del termine “aperto”. Finché gli attori dominanti potranno qualificare come open source modelli parzialmente aperti, il mercato rimarrà opaco sia per gli utenti che per i regolatori. I prossimi mesi determineranno se gli standard in fase di elaborazione riusciranno a imporre una trasparenza verificabile, o se l’etichetta “open” rimarrà un argomento di marketing senza garanzia tecnica.
