Componenti open source nel software commissionato: controlli prima della consegna

Prima di accettare un software sviluppato su commissione occorre identificare i componenti open source inclusi, le versioni e le licenze effettive, collegandoli alla modalità di utilizzo e distribuzione del prodotto. Il pagamento dello sviluppo e una clausola generica di cessione non rendono automaticamente esclusivi i diritti sulle librerie di terzi. La consegna dovrebbe comprendere inventario, avvisi di licenza, sorgenti quando dovuti e prova delle verifiche svolte.

Aggiornato al 25 ottobre 2026 — A cura dell’avvocato Carmine Coviello. Indicazioni operative per imprese e responsabili acquisti, da adattare al contratto, all’architettura tecnica e alla legge applicabile.

Fotografie illustrative di lavoro al computer e codice da Unsplash; documenti contrattuali dalla libreria del sito. Non rappresentano un cliente o un controllo effettivamente eseguito.

Perché il collaudo funzionale non esaurisce l’accettazione

Un’applicazione può superare i test e restare difficile da distribuire secondo il modello commerciale promesso. Il problema emerge quando il cliente vuole concederla in licenza, consegnarla a una controllata o installarla presso un acquirente e scopre obblighi non considerati. La domanda da porre al fornitore è concreta: con quali componenti è stata costruita questa versione e quali condizioni accompagnano le attività che intendiamo svolgere?

Il controllo deve iniziare nelle specifiche, non alla vigilia del lancio. Direzione, sviluppatori e consulente legale dovrebbero concordare se il risultato sarà usato internamente, fornito come servizio online, distribuito in forma eseguibile o consegnato con il sorgente. Queste scelte incidono sulle verifiche necessarie. L’approfondimento sulla protezione del codice e degli algoritmi inquadra i diversi diritti; qui l’attenzione è rivolta alla documentazione di accettazione della fornitura.

Distinguere codice dedicato, materiale preesistente e dipendenze

L’allegato IP dovrebbe distinguere gli sviluppi realizzati per il cliente dal patrimonio preesistente della software house, dalle librerie open source e dagli eventuali moduli commerciali. Non basta una formula secondo cui il cliente acquista ogni diritto: il fornitore non può trasformare il codice di terzi in proprietà esclusiva del committente soltanto descrivendolo così nel contratto.

Per ciascuna categoria occorre indicare quali usi sono consentiti e quali materiali saranno consegnati. È utile separare anche documentazione, script di compilazione, font, immagini e dati dimostrativi: un pacchetto può contenere materiali con condizioni diverse da quelle del programma principale. La disponibilità del repository non risolve automaticamente queste differenze.

Inventario dei componenti: che cosa chiedere nella SBOM

Una software bill of materials, o SBOM, è un inventario strutturato dei componenti. Nel dossier contrattuale dovrebbe consentire di collegare nome del pacchetto, versione esatta, provenienza, identificativo della licenza, modifiche apportate e posizione nella versione consegnata. Vanno considerate anche le dipendenze indirette e i frammenti inseriti manualmente, che un semplice elenco del gestore dei pacchetti potrebbe non descrivere.

L’inventario va riferito a un rilascio identificato con data, versione e riferimento tecnico verificabile. Una lista aggiornata mesi prima del collaudo non dimostra la composizione del prodotto finale. La scheda dovrebbe riportare inoltre responsabile della verifica, documento consultato ed eventuale questione ancora aperta. Non è una certificazione automatica di conformità e non sostituisce l’analisi delle licenze.

Per una verifica più ampia dei programmi e servizi utilizzati dall’organizzazione, la guida all’audit delle licenze software distingue inventario tecnico, contratti e uso effettivo.

MIT e Apache: permissivo non significa privo di condizioni

Il testo ufficiale della licenza MIT consente ampie attività, compreso l’uso commerciale, ma richiede la conservazione dell’avviso di copyright e dell’avviso di autorizzazione nelle copie o porzioni sostanziali del software. La verifica pratica consiste nell’accertare dove tali informazioni siano conservate e come accompagnino il materiale distribuito. Una nota nel fascicolo interno non coincide necessariamente con gli avvisi dovuti al destinatario.

La Apache License 2.0 contiene condizioni specifiche per la redistribuzione: copia della licenza, indicazione delle modifiche e conservazione degli avvisi pertinenti; disciplina anche il trattamento di un eventuale file NOTICE. Il contratto dovrebbe assegnare a una parte la preparazione di questi materiali e all’altra la loro verifica prima del rilascio. Il permesso sul codice non costituisce un’autorizzazione generale a usare i marchi del progetto.

Copyleft e servizio online: leggere licenza e configurazione

La GPLv3, nel testo pubblicato da SPDX, disciplina la trasmissione di copie e gli obblighi relativi al sorgente corrispondente. Non è corretto affermare che ogni presenza di codice GPL obblighi automaticamente a rendere pubblico tutto il patrimonio software dell’impresa. Occorre identificare l’opera interessata, le modifiche, il rapporto tra i componenti e gli atti concretamente previsti.

La AGPLv3 contiene inoltre una previsione specifica per le versioni modificate con cui gli utenti interagiscono attraverso una rete: ricorrendone i presupposti, deve essere offerta la possibilità di ricevere il sorgente corrispondente. Per questo una decisione basata soltanto sulla frase «non consegniamo eseguibili, è tutto online» può essere incompleta. Il contratto deve descrivere il servizio realmente progettato.

Compatibilità: confrontare licenza in ingresso e licenza in uscita

Il Licensing Assistant del portale della Commissione europea distingue la licenza del codice ricevuto da quella prevista per il prodotto distribuito. È una distinzione utile per le specifiche: il fornitore deve conoscere il modello di sfruttamento atteso prima di scegliere le dipendenze. Lo strumento supporta l’orientamento, ma il portale precisa che non sostituisce una valutazione legale professionale.

Il verbale dovrebbe identificare i casi analizzati e le ipotesi tecniche utilizzate. Non basta annotare che due licenze sono compatibili senza indicare versioni, componenti e modalità d’integrazione. Se resta un dubbio, va assegnata un’azione: approfondimento, autorizzazione del titolare, componente alternativo o diversa organizzazione della soluzione. Nessuna di queste opzioni dovrebbe essere presentata come automaticamente praticabile.

Clausole da negoziare prima dello sviluppo

È utile prevedere un obbligo di informazione sulle componenti di terzi e una procedura di approvazione per quelle che possono incidere sulla distribuzione o sulla riservatezza del sorgente. La procedura deve definire chi decide, quali documenti riceve e quando una variazione richiede una nuova verifica. Un divieto assoluto e generico può essere difficile da applicare se l’architettura approvata dipende già da librerie esterne.

Garanzie e manleve vanno riferite a un perimetro comprensibile, coordinando obblighi del fornitore, collaborazione del cliente e gestione delle contestazioni. Il contratto dovrebbe distinguere correzione documentale, sostituzione del componente e revisione tecnica, con tempi e responsabilità negoziati. Anche chi firma deve poter assumere questi impegni: la guida sui poteri di firma nei contratti IP aiuta a preparare il relativo controllo.

Checklist di accettazione della versione consegnata

1. Identificare rilascio, repository e materiali effettivamente ricevuti; verificare che corrispondano al prodotto collaudato.

2. Acquisire inventario dei componenti diretti e indiretti, licenze applicabili, avvisi e indicazioni sulle modifiche.

3. Confrontare uso interno, servizio online e distribuzione ai clienti con le condizioni dei componenti rilevanti.

4. Verificare dove saranno inseriti gli avvisi destinati agli utenti e come verrà fornito il sorgente quando richiesto.

5. Registrare decisioni, anomalie, responsabili e azioni correttive, evitando un’accettazione indistinta delle questioni ancora aperte.

6. Concordare l’aggiornamento del dossier dopo nuove versioni e il trasferimento delle informazioni in caso di cambio fornitore.

Quanto costa correggere un problema scoperto tardi

Non esiste una tariffa ufficiale unica per una verifica open source. Il preventivo professionale dipende da numero dei componenti, qualità dell’inventario, disponibilità dei contratti e complessità tecnica. Il costo di un rimedio può comprendere anche sviluppo, nuovi test, documentazione e ritardo nel rilascio. Non è prudente stimarlo senza conoscere il prodotto e l’effettivo obbligo non rispettato.

Se il problema emerge dopo la consegna, è opportuno preservare versione e documenti, classificare la questione e coordinare le comunicazioni. La sostituzione immediata di una libreria può alterare funzionalità e prove; una dichiarazione affrettata può descrivere obblighi non ancora accertati. La guida sul cambio del fornitore software approfondisce la continuità della manutenzione. L’eventuale valutazione brevettuale del software resta un esame distinto dalla conformità alle licenze.

Domande frequenti sui componenti open source

Pagare lo sviluppo rende proprietari di tutte le librerie?

No. I componenti di terzi restano soggetti ai rispettivi diritti e licenze. Il contratto deve separare gli sviluppi dedicati dai materiali preesistenti e dalle dipendenze, indicando le facoltà effettivamente disponibili al cliente.

Una SBOM dimostra che ogni licenza è rispettata?

No. L’inventario aiuta a identificare i componenti, ma non prova da solo compatibilità, completezza, corretta attribuzione o adempimento degli obblighi sul sorgente. Va confrontato con la versione consegnata e con gli usi previsti.

Un prodotto commerciale può includere codice open source?

Sì, quando il progetto rispetta le condizioni delle licenze applicabili. Occorre verificare versioni, integrazione e distribuzione; la natura commerciale non determina da sola l’esito della valutazione.

Offrire il programma soltanto online evita ogni obbligo sul sorgente?

Non si può generalizzare. Le licenze hanno condizioni differenti: AGPLv3 contiene una specifica disciplina per l’interazione remota con versioni modificate. Il servizio va analizzato rispetto al testo effettivamente applicabile.

Il controllo va ripetuto dopo la prima consegna?

Sì, quando cambiano dipendenze, versioni, architettura o modalità di distribuzione. La procedura dovrebbe prevedere un aggiornamento del dossier per ogni rilascio rilevante, con responsabilità e decisioni documentate.

Per un’introduzione al diritto d’autore, il video dello Studio Copyright: come funziona? offre un inquadramento generale. Le condizioni dei singoli componenti open source richiedono comunque la lettura delle licenze e una verifica specifica del progetto.

Preparare il dossier prima del lancio

Per una verifica mirata servono contratto di sviluppo, inventario dei componenti, versione da consegnare, licenze e descrizione degli usi commerciali previsti. Lo Studio può coordinare il controllo dei diritti con il confronto tecnico sui materiali ricevuti. Consulta i servizi dello Studio per i contratti di licenza indicando il progetto software e le decisioni ancora aperte. L’esito dipende dal fascicolo concreto; non è garantito da una clausola standard.