Diritto d'autore sul software nel report su un'azienda cinese

Una registrazione del diritto d'autore sul software può collegare una specifica versione del software a un titolare dei diritti registrato. Non certifica che il software funzioni, che la build corrente sia la versione registrata o che il fornitore possieda ogni componente del prodotto.

Questa distinzione è particolarmente importante quando si esamina una piattaforma industriale, un'app mobile, un controller embedded, un fornitore SaaS o un fornitore di dispositivi intelligenti. Un report aziendale può far emergere una registrazione utile, ma la domanda di approvvigionamento è più circoscritta: questa registrazione supporta il ruolo dichiarato dal fornitore per questo prodotto?

Che cosa viene registrato?

I Regolamenti sulla protezione del software per computer della Cina definiscono il software come programmi per computer e la relativa documentazione. Il codice sorgente e il codice oggetto dello stesso programma sono considerati la stessa opera ai sensi di tale definizione. Il concetto è quindi più specifico di un'idea di prodotto, un servizio cloud, un marchio o un'intera attività tecnologica.

La panoramica sul software dell'OMPI traccia un'altra linea utile: il diritto d'autore protegge l'espressione, non le idee, le procedure, i metodi operativi o i concetti matematici in quanto tali. Una registrazione per `Piattaforma di instradamento magazzino V1.0` non equivale alla proprietà esclusiva di ogni concetto o algoritmo di instradamento magazzino descritto in una presentazione commerciale.

Quando un report aziendale elenca registrazioni software insieme a brevetti e marchi, mantenere separati i loro scopi. La mappa d'uso delle registrazioni PI illustra il portafoglio più ampio; questa pagina resta focalizzata sulla registrazione software.

La registrazione è una prova, non la nascita del diritto d'autore

I regolamenti sulla protezione stabiliscono che il diritto d'autore sul software sorge al completamento dello sviluppo. Consentono inoltre al titolare dei diritti di registrare e descrivono il documento di registrazione risultante come prova preliminare degli elementi registrati. Le Misure per la registrazione del diritto d'autore sul software della Cina incoraggiano la registrazione e definiscono i requisiti per il richiedente e la documentazione.

Evitare quindi due affermazioni comuni:

• `L'azienda ha ottenuto il diritto d'autore alla data di registrazione.` Il diritto sottostante non viene creato da quella data amministrativa.
• `Non è stata trovata alcuna registrazione, quindi l'azienda non ha alcun diritto d'autore.` L'assenza di risultati nella ricerca non risolve la questione dell'esistenza di software tutelabile o di diritti contrattuali.

La distinzione spiega anche perché il volume delle registrazioni non costituisce una classifica di qualità. L'Amministrazione nazionale del diritto d'autore ha riportato 3.182.829 registrazioni di diritto d'autore sul software nel 2025. Si tratta di un ampio contesto amministrativo, non di una prova che un fornitore con 100 registrazioni sia migliore di uno con cinque registrazioni pertinenti.

Leggere sei campi come scheda versione

La disponibilità varia a seconda della fonte, ma un estratto utile della registrazione può contenere i seguenti campi. Conservare il testo cinese e la data di recupero invece di omettere un suffisso di versione o il nome dell'entità nella traduzione.

Nome completo del software e nome breve

Confrontare la formulazione esatta con il preventivo, la schermata di accesso, il manuale utente e l'allegato contrattuale. Nomi simili possono descrivere una famiglia di prodotti piuttosto che la build acquistata.

Numero di versione

`V1.0` non è intercambiabile con una `V3.2` dimostrata. Chiedere come le release, i moduli e le edizioni white-label si rapportano alla versione registrata.

Registrante o titolare dei diritti registrato

Far corrispondere la denominazione legale cinese all'azienda contraente. Se viene nominato un fondatore, un dipendente, un'affiliata o uno sviluppatore esterno, documentare la catena di proprietà o licenza invece di considerare la differenza automaticamente legittima o sospetta.

Data di completamento dello sviluppo

Rappresenta il punto di completamento segnalato per il software registrato. Non costituisce un audit indipendente del repository del codice, della completezza delle funzionalità o della qualità della release.

Data di prima pubblicazione, se indicata

Può aiutare a ricostruire la cronologia. `Non pubblicato`, vuoto o non disponibile non deve essere interpretato come `mai utilizzato` o `mai consegnato`.

Data e numero di registrazione

Utilizzarli per identificare e datare il record amministrativo. Non sostituire la data di registrazione alla data di completamento, alla data di prima pubblicazione o alla data di rilascio attuale del prodotto.

Il titolare dei diritti potrebbe non essere il venditore

Una discrepanza richiede una spiegazione del rapporto giuridico. Il software potrebbe essere stato sviluppato da dipendenti, creato congiuntamente, commissionato a un contraente esterno, trasferito, concesso in licenza o detenuto da un’altra società del gruppo. Le norme di tutela contengono regole suppletive specifiche per il software commissionato e per quello sviluppato da determinati dipendenti, ma l’acquirente non dovrebbe cercare di risolvere la titolarità legale sulla base di un breve risultato pubblico.

Richiedere i documenti coerenti con la situazione concreta: accordo di sviluppo, clausole sulla proprietà intellettuale nel contratto di lavoro, atto di trasferimento, licenza, autorizzazione della società capogruppo, registro di fusioni o cambi di denominazione sociale ed elenco dei componenti di terze parti e open source. Verificare ogni società mediante la sua identità legale cinese. Se il venditore afferma che lo sviluppatore è una società affiliata, confrontare il rapporto con la parte contrattuale e il team di servizio, anziché assimilare entrambe le denominazioni a un’unica società.

L’oggetto sociale può fornire contesto sullo sviluppo di software o sui servizi tecnologici, ma non determina la titolarità del diritto d’autore. Utilizzare la revisione dell’oggetto sociale per quel campo distinto.

Tre date non costituiscono una cronologia delle release

Una registrazione può fornire una data di completamento, una data di prima pubblicazione e una data di registrazione. Nessuna di esse indica necessariamente quale build è in esecuzione nella demo odierna, quando è stata aggiunta una funzionalità, chi gestisce l’ambiente di produzione o se il fornitore è in grado di ripristinare il servizio dopo un guasto.

Costruire una breve cronologia sulla base di documenti creati ai fini della consegna del software:

1. titolo registrato, versione e data di completamento dichiarata;
2. note di rilascio e identificativi di build per la versione indicata;
3. registri di accettazione da parte del cliente o interni, datati;
4. prove relative al repository, al deployment o all’escrow, adeguate alla transazione;
5. attuale responsabile del supporto, subappaltatori e politica di fine vita del prodotto.

L’obiettivo non è esigere il codice sorgente per ogni acquisto, bensì rendere le prove proporzionate al livello di dipendenza: un’utilità offline utilizzata da un solo analista richiede meno prove di continuità rispetto a un software che controlla una linea di produzione o archivia dati soggetti a regolamentazione.

Caso: il report indica V1.0, la demo indica V3.2

Un fornitore fittizio dimostra `PlantWatch 3.2`, una piattaforma di monitoraggio in bundle con sensori di fabbrica. Il report societario elenca `PlantWatch Equipment Monitoring Platform V1.0`, registrata tre anni prima alla stessa entità legale cinese. L’intestazione, il titolare e la cronologia sono plausibili. Il registro supporta la continuità tra la società e una versione precedente del prodotto.

Ciò non attesta l’autenticità della V3.2. L’acquirente richiede note di rilascio che colleghino la V1.0 alla V3.2, il numero di build mostrato nella demo, un elenco delle funzionalità per versione, prove recenti di accettazione e la divulgazione del componente di mappatura fornito da un altro sviluppatore. Il contratto specifica quindi la versione consegnabile, la durata del supporto, il metodo di esportazione dei dati, gli obblighi di sicurezza, i test di accettazione e la responsabilità per le licenze di terze parti.

La conclusione risultante non è né `diritto d’autore verificato, approvare` né `mancata corrispondenza di versione, respingere`. È: `La registrazione supporta un rapporto precedente tra prodotto e società; la titolarità della versione corrente, i componenti e i controlli di consegna richiedono le prove elencate.`

Ciò che la registrazione non verifica

• Funzionalità: se le funzionalità promesse funzionano sotto il carico di lavoro dell’acquirente.
• Sicurezza: gestione delle vulnerabilità, controllo degli accessi, crittografia, risposta agli incidenti o sviluppo sicuro.
• Provenienza del codice: se ogni modulo è originale, in licenza, open source o fornito da un contraente esterno.
• Operatività: titolarità dell’hosting, backup, disaster recovery, organico del supporto e uptime.
• Diritti sul prodotto: se il venditore ha l’autorità di concedere in licenza la build corrente nel territorio e per il caso d’uso dell’acquirente.

Questi aspetti richiedono test tecnici, analisi della composizione del software o revisioni di sicurezza, prove contrattuali e, talvolta, consulenza legale specialistica. Un registro societario può aiutare a mirare tali verifiche, ma non può eseguirle.

Redigere una conclusione circoscritta del report societario

Indicare l’esatto registro, la corrispondenza dell’identità, il rapporto tra versioni, il limite temporale e la prossima azione. Ad esempio:

Il report identifica `PlantWatch Equipment Monitoring Platform V1.0` registrata presso l’entità contraente verificata. Ciò supporta un rapporto software-società per la versione nominata alle date registrate. Non stabilisce la titolarità, la sicurezza o le prestazioni della build V3.2 indicata. Ottenere la catena di rilascio, la divulgazione dei componenti, le prove di accettazione e la licenza contrattuale prima dell’approvazione.

Allegare l’estratto della fonte e la risposta del fornitore al fascicolo di approvazione del fornitore. Un report societario di esempio mostra come il modulo IP si affianca ai dati sull’identità e sull’operatività; non deve essere letto isolatamente.

Segnalare a revisori tecnici e legali qualificati gli sviluppi personalizzati ad alto valore, le controversie sulla titolarità, l’accesso al codice sorgente, le licenze transfrontaliere, i timori di violazione e la continuità operativa critica. Per gli approvvigionamenti ordinari, inserire il risultato nella sequenza di prove precontrattuali e registrare la formulazione circoscritta nel memorandum di approvazione interno.