Progetti software: come gestire librerie open source e API di terze parti

Quali licenze open source sono più sicure per un progetto commerciale?

In genere, le licenze open source più semplici da gestire in un progetto commerciale sono quelle permissive, come MIT, BSD e Apache. Consentono di usare, modificare e distribuire il software anche all’interno di prodotti proprietari, purché vengano rispettate le condizioni previste dalla licenza.

Questo non significa che siano sempre “sicure” in senso assoluto. Significa che, rispetto ad altre licenze, tendono a imporre meno vincoli sul prodotto finale.

Le licenze MIT e BSD sono spesso considerate più adatte ai progetti commerciali perché richiedono soprattutto di mantenere gli avvisi di copyright e il testo della licenza. Di solito non impongono all’impresa di rendere pubblico il codice del proprio software né di distribuire il prodotto con la stessa licenza della libreria utilizzata.

Anche la licenza Apache è generalmente compatibile con progetti commerciali, ma richiede una verifica leggermente più attenta. Oltre agli obblighi di attribuzione, contiene previsioni specifiche sui brevetti e sulle modifiche al codice. Per molte imprese resta una licenza gestibile, ma va letta con attenzione quando il software ha un valore tecnologico rilevante o viene sviluppato per essere ceduto, concesso in licenza o valorizzato in una due diligence.

Diverso è il caso delle licenze LGPL, GPL e AGPL. Non sono licenze “vietate” per un progetto commerciale, ma possono incidere in modo più forte sul modo in cui il software viene integrato, distribuito o offerto ai clienti.

• La LGPL può essere compatibile con un prodotto proprietario, soprattutto quando la libreria resta separata dal software principale. Tuttavia, richiede attenzione sul modo in cui avviene il collegamento tecnico tra la libreria e il resto del programma.
• La GPL richiede una valutazione più rigorosa e può far sorgere obblighi anche sul codice del prodotto finale. Per questo, prima di usarla in un progetto commerciale, è necessario capire se il software verrà distribuito ai clienti, incorporato in un prodotto proprietario o usato solo internamente.
• La AGPL merita un controllo ancora più specifico nei modelli SaaS. A differenza di altre licenze, può far sorgere obblighi anche quando il software non viene consegnato al cliente, ma viene usato per offrire un servizio online. Per un’impresa che sviluppa piattaforme digitali, applicazioni web o servizi cloud, questo punto può incidere direttamente sul modello di business.

In pratica, una prima scelta operativa può essere questa: se il progetto è commerciale e proprietario, le licenze MIT, BSD e Apache sono di solito le più semplici da gestire. Le licenze LGPL, GPL e AGPL non vanno escluse automaticamente, ma richiedono una verifica tecnica e legale prima dell’integrazione.

La decisione, quindi, non dovrebbe basarsi solo sul nome della licenza, ma su alcune domande concrete: il software sarà usato solo internamente o distribuito ai clienti? La libreria sarà modificata? Verrà integrata nel codice proprietario? Il prodotto sarà offerto in modalità SaaS? Il software potrà essere oggetto di investimento, cessione o due diligence?

Queste domande permettono all’impresa di scegliere con maggiore controllo. Una libreria con licenza permissiva può essere una scelta lineare per un prodotto commerciale. Una libreria copyleft può essere utilizzabile, ma solo se i suoi obblighi sono compatibili con il progetto. Il problema, quindi, non è evitare l’open source: è scegliere licenze coerenti con il modo in cui il software verrà sfruttato economicamente.

E questa verifica diventa ancora più delicata quando il progetto non incorpora una libreria, ma si collega a servizi esterni tramite API di terze parti.

Quali sono i profili legali nell’impiego di API di terze parti?

Usare una API di terze parti significa collegare il proprio software a un servizio esterno. Per esempio: un sistema di pagamento, una mappa, un servizio di intelligenza artificiale, un gestionale, un CRM o una piattaforma di messaggistica.

Ebbene, prima di integrare una API, l’impresa deve sapere a quali condizioni può usarla.

La prima cosa da controllare sono i termini di servizio del fornitore. Di solito stabiliscono cosa si può fare, cosa è vietato, quali limiti di utilizzo esistono e quando il servizio può essere sospeso o modificato.

In pratica, l’impresa dovrebbe verificare almeno questi aspetti.

1. Non tutte le API possono essere usate per qualunque scopo. Alcune vietano determinati usi commerciali, l’integrazione in prodotti concorrenti, lo scraping o l’uso dei dati per addestrare sistemi di intelligenza artificiale.
2. Molte API prevedono limiti di chiamate, soglie di traffico, piani a pagamento o costi crescenti in base all’utilizzo. Una API sostenibile in fase di test può diventare costosa quando il prodotto cresce.
3. Se attraverso la API passano dati personali, dati dei clienti o informazioni aziendali, occorre capire chi li tratta, dove vengono conservati, per quali finalità e con quali responsabilità.
4. Una API può essere modificata, limitata o sospesa dal fornitore. Se quella API è essenziale per il funzionamento del prodotto, l’impresa deve valutare cosa succede se il servizio cambia o non è più disponibile.
5. Anche le API devono rispettare la normativa sul diritto d’autore. Tuttavia, la Corte di Giustizia dell’Unione Europea, nella causa SAS Institute Inc. contro World Programming Ltd. (C-406/10), ha chiarito che la funzionalità di un programma, il linguaggio di programmazione e il formato dei file utilizzati per sfruttarne le funzioni non costituiscono, da soli, una forma di espressione tutelata dal diritto d’autore.

Pertanto, il principio è utile anche quando si ragiona sulle API: collegarsi a una funzionalità tecnica altrui non equivale, di per sé, a riprodurre codice protetto.

Il discorso cambia se l’impresa copia codice sorgente, codice oggetto, esempi tecnici, manuali, documentazione o altri materiali messi a disposizione dal fornitore. In quel caso non si sta solo usando un’interfaccia o una funzione: si può entrare nel perimetro dei diritti esclusivi del titolare. La stessa sentenza sottolinea infatti che la documentazione tecnica può essere protetta dal diritto d’autore, così come il software stesso.

Per questo, l’impiego di API di terze parti va trattato come un rapporto con un fornitore esterno. Non basta verificare che l’integrazione funzioni: bisogna capire quali condizioni regolano l’accesso, quali limiti esistono e quali conseguenze può avere una modifica del servizio.

In sintesi, una API può essere usata in un progetto software se i suoi termini sono compatibili con il prodotto che l’impresa vuole costruire. Il controllo va fatto prima dell’integrazione, perché una dipendenza tecnica può diventare rapidamente anche una dipendenza contrattuale.

Dopo aver scelto librerie e API, resta un ultimo passaggio: documentare ciò che è stato integrato e stabilire chi risponde se una componente esterna crea problemi.

Quando serve una SBOM per gestire librerie, API e componenti di terzi?

Dopo aver scelto librerie open source e API di terze parti, resta un passaggio spesso trascurato: documentare ciò che è stato integrato nel progetto software.

Non basta sapere che una libreria “si può usare” o che una API “funziona”. L’impresa deve poter ricostruire quali componenti sono stati utilizzati, in quale versione, con quale licenza o termine di servizio, e per quale funzione del prodotto.

Questa documentazione viene spesso chiamata Software Bill of Materials, o SBOM. In termini semplici, è la distinta dei componenti software: un elenco ordinato di librerie, framework, moduli, pacchetti, API e altre componenti esterne presenti nel progetto.

La SBOM serve a rispondere a domande molto concrete: cosa c’è dentro il software? Chi lo ha sviluppato? Quale licenza lo regola? Ci sono obblighi da rispettare? Il componente può essere usato in un prodotto commerciale o SaaS?

Se l’impresa sviluppa software internamente, la SBOM dovrebbe essere costruita durante il progetto, non ricostruita alla fine. Ogni volta che viene inserita una nuova libreria o aggiornata una componente, la documentazione dovrebbe essere aggiornata insieme al codice. In questo modo, la verifica legale non diventa un controllo tardivo, ma parte della gestione ordinaria dello sviluppo.

Se invece l’impresa affida lo sviluppo a una software house, a un freelance o a un fornitore esterno, la SBOM va richiesta contrattualmente. Il committente dovrebbe pretendere un elenco dei componenti usati, delle relative versioni, delle licenze applicabili e degli eventuali limiti di utilizzo, distribuzione o modifica.

Questo punto è particolarmente importante per le PMI. Spesso l’impresa non ha un reparto tecnico interno in grado di verificare ogni libreria usata dal fornitore. Per questo, il contratto di sviluppo dovrebbe prevedere almeno tre obblighi: consegna della SBOM, garanzia di compatibilità delle componenti con gli obiettivi del progetto e responsabilità del fornitore in caso di uso non autorizzato o non dichiarato.

La SBOM è utile anche quando il software deve essere venduto, concesso in licenza, presentato a un investitore o valutato in una due diligence. In questi casi, un prodotto privo di documentazione sulle componenti esterne può perdere valore, perché chi lo acquista o lo finanzia non riesce a capire se il codice sia davvero sfruttabile senza vincoli inattesi.

In pratica, la SBOM non serve solo agli sviluppatori. Serve all’impresa per mantenere controllo sul proprio asset digitale. Senza una mappa dei componenti, diventa difficile gestire aggiornamenti, vulnerabilità, obblighi di licenza, dipendenze da fornitori esterni e responsabilità contrattuali.

Per questo, nei progetti software, la regola dovrebbe essere semplice: chi sviluppa internamente documenta; chi commissiona pretende documentazione. Librerie open source e API di terze parti possono essere strumenti utili e perfettamente compatibili con un progetto commerciale, ma solo se l’impresa sa cosa sta usando e può dimostrarlo.

Così il progetto resta gestibile anche quando cresce, cambia fornitore, entra in una trattativa commerciale o viene sottoposto a verifica legale. La differenza non sta nell’evitare componenti esterne, ma nel non lasciarle invisibili dentro il software.