COMPLIANCE & RIGHT · TRATTATO
Il software viene acquistato, sviluppato, assemblato da componenti esistenti e utilizzato attraverso diversi modelli. Ciò crea diritti e obblighi diversi. Una fattura di licenza non dimostra ancora che qualsiasi uso effettivo è consentito. Controlliamo i diritti d'uso, i contratti di sviluppo e la gestione dei componenti open source.
Catturare l'uso effettivo
All'inizio c'è un inventario: Quali programmi e versioni vengono utilizzati dove, da chi e in che misura? Le metriche di licenza possono riguardare utenti, dispositivi, processori, accessi o determinate applicazioni. Virtualizzazione, ambienti di test, operazioni cloud e utilizzo di Gruppo devono essere confrontati con le rispettive condizioni.
Anche il cambiamento dei prestatori di servizi o una ristrutturazione può essere rilevante. Una licenza per una determinata società non copre automaticamente tutte le società associate. Prima di rinnovare il contratto, l'uso effettivo e gli appalti dovrebbero essere riuniti in modo comprensibile.
Diritti al software sviluppato autonomamente
Per i programmi dei dipendenti, § 69b UrhG contiene una regola speciale se il software è creato nell'esecuzione dei compiti o secondo l'istruzione del datore di lavoro. Questa regola non può essere applicata agli sviluppatori liberi o a qualsiasi altro risultato lavorativo.
Per gli sviluppatori esterni, i diritti d'uso richiesti devono essere garantiti contrattualmente. A seconda del progetto, questo include la lavorazione, l'ulteriore sviluppo, il trasferimento ai clienti, l'integrazione nei prodotti e l'uso da parte di aziende affiliate. L'accesso al codice sorgente, la documentazione, i componenti di terzi e la partecipazione a un cambiamento del fornitore dovrebbero essere trattati esplicitamente. Il pagamento della tassa di sviluppo non risponde da solo a queste domande.
Open Source non è uno stock legale
Il software open source può essere utilizzato secondo i termini della rispettiva licenza. Queste condizioni differiscono notevolmente. Spesso si tratta di avvisi di copyright, testi di licenza e riferimenti a modifiche. Per alcune licenze copyleft, possono essere aggiunti gli obblighi di fornire codice sorgente. Se e in quale misura ciò accada dipende in particolare dalla versione di licenza, dalla modifica, dalla connessione con altri codici e dall'utilizzo o dal modulo di distribuzione.
L'AGPL contiene requisiti speciali per determinati usi su una rete. Ciò non implica che qualsiasi uso di software open source richieda la pubblicazione dell'intero codice, né che un modello di hosting puro rimanga sempre privo di obblighi di licenza. La valutazione deve basarsi sull'architettura concreta.
Una directory di componenti e scansioni automatizzate facilitano l'inventario. Essi non sostituiscono la valutazione giuridica di riferimenti poco chiari, diverse opzioni di licenza o metadati contrastanti. I subappaltatori devono inoltre fornire le informazioni necessarie.
Un processo di rilascio per lo sviluppo
- I nuovi componenti sono registrati con versione, sorgente, licenza e destinazione d'uso.
- Termini distintivi e conflitti di licenza vengono controllati prima del rilascio del prodotto.
- Sono fornite tutte le informazioni necessarie, i testi di licenza e, se del caso, le offerte di codice sorgente.
- Le modifiche, le dipendenze e gli aggiornamenti successivi alla sicurezza rimangono comprensibili.
Il processo dovrebbe sostenere lo sviluppo quotidiano. Sono utili chiare responsabilità e una breve regola per casi poco chiari. Un divieto generale su tutti i componenti liberi non è né un test appropriato né un rilascio senza conoscenza delle condizioni.
Licenze e richieste di audit
Nel caso di una richiesta di revisione contabile, vengono esaminate in primo luogo la base contrattuale, la portata, i termini e la riservatezza. I dati non devono essere emessi in modo disordinato. Allo stesso tempo, gli obblighi di cooperazione esistenti devono essere rispettati. Un inventario tecnico, l'esame della metrica di licenza e la classificazione legale dei crediti appartengono insieme.
Sosteniamo gli accordi di licenza, gli accordi di sviluppo, i regolamenti open source e la gestione di reclami concreti. Per Domanda Prodotto o progetto, condizioni di licenza, modello operativo e scadenze già stabilite sono utili.
Base giuridica e decisioni: UrhG, in particolare §§ 69a 0,069g; GNU General Public License, Versione 3; GNU Affero General Public License, Versione 3.
Situazione al 2 novembre 2026.
Per ulteriori informazioni: Imprese di software · Cyber Resilience Act per produttori e fornitori di software · Acquisizioni e partecipazioni
Quattro esempi pratici
I seguenti casi fittizi illustrano domande d'esame tipiche. La soluzione concreta dipende dalle circostanze del singolo caso.
01 · Utilizzo eccessivo delle licenze
Un'azienda ha utenti più produttivi degli accessi prenotati. La metrica delle licenze, la portata del contratto e l'adeguamento sono controllati prima che al fornitore siano fornite informazioni non garantite.
02 · Copyleft nel prodotto
Uno sviluppatore integra una libreria. Il testo della licenza, l'integrazione tecnica e il modulo di vendita determinano l'esame dei possibili obblighi di divulgazione.
03 · Sviluppo da parte di Freelancer
Il contratto tace sull'ulteriore sviluppo e trasferimento. L'estensione dei diritti e i diritti di trattamento richiesti sono chiariti prima della commercializzazione del prodotto.
04 · Verifica della licenza del produttore
Un fornitore richiede dati di sistema. La legge di esame, la portata, la riservatezza e una procedura controllata sono concordate; non tutte le informazioni richieste devono essere rilasciate senza verifica.
Il tuo prossimo passo
Vuoi trasferire i requisiti alla tua azienda o avere un processo specifico controllato? Per il primo contatto sono sufficienti una breve descrizione e un riferimento alle scadenze esistenti. Voteremo sulla portata dell'esame e del risarcimento prima della messa in servizio.