Dimostrare la proprietà del software: sigillo crittografico per il codice sorgente (2026)

Se credete che la cronologia dei commit git dimostri che avete scritto il codice, un avvocato della controparte smontarà quella tesi in pochi minuti. I timestamp git sono impostati dall'orologio locale del committer — non da un'autorità indipendente e accreditata. Chiunque abbia accesso al repository può riscrivere la cronologia, antidatare i commit o ricommittare da un timestamp manipolato. Un sigillo crittografico qualificato non presenta queste debolezze.

Perché la cronologia git è una prova debole in tribunale

Git è uno strumento di collaborazione, non un sistema di conservazione legale dei documenti. La cronologia è mutabile per progetto: git commit --amend modifica il timestamp di un commit, git push --force riscrive un intero branch, e un malintenzionato può clonare il vostro repository pubblico, aggiungere commit antidatati e pubblicare il fork come originale.

Anche senza frode deliberata, i timestamp git sono contestabili. Un orologio di sistema mal configurato o una pipeline CI/CD che ricommitte artefatti compilati produce timestamp che i tribunali trattano come prove circostanziali. In una controversia su chi ha scritto per primo un algoritmo proprietario, la cronologia git è un punto di partenza — non una conclusione.

Cosa aggiungono i timestamp elettronici qualificati

Swiss Trust Layer calcola un hash SHA-256 del vostro file sorgente o dell'archivio ZIP del repository — modificate un singolo carattere e l'hash cambia completamente — e invia quell'hash a Swisscom Trust Services, un Qualified Trust Service Provider (QTSP) accreditato ai sensi del diritto europeo e svizzero. Swisscom emette un timestamp conforme a RFC 3161, vincolando il vostro hash a un preciso orario UTC con una firma crittografica che nessuna delle parti può alterare.

Il risultato è un certificato conforme a PAdES che chiunque può verificare su swisstrustlayer.com/validate — senza necessità di contattarvi. Ai sensi dell'eIDAS Art. 41, il timestamp porta una presunzione legale di accuratezza in tutti i 27 Stati membri dell'UE. ZertES Art. 2 prevede la stessa presunzione ai sensi del diritto svizzero. Questa è una valenza probatoria fondamentalmente diversa rispetto a un git log.

Tre scenari critici in cui gli sviluppatori ne hanno bisogno

Controversia con un contractor — chi ha scritto l'algoritmo per primo?

Un freelance consegna un modello di machine learning. Mesi dopo, il cliente afferma che l'algoritmo era stato sviluppato internamente prima dell'inizio del contratto. Il repository interno del cliente può essere fabbricato retroattivamente. Un sigillo qualificato sul prototipo iniziale del contractor, con timestamp precedente alla data rivendicata dal cliente, fornisce un prior art presunto legalmente che non può essere liquidato come errore di orologio o commit riscritto.

Due diligence degli investitori — dimostrare la catena di titolo IP

I team VC e M&A ora richiedono sistematicamente la provenienza del software IP. Un sigillo crittografico sulla base di codice a ogni traguardo — prototipo, Series A, Series B — crea una catena di titolo verificabile che soddisfa i team legali senza fare affidamento esclusivamente sulla cronologia git.

Licenza open-source — stabilire il prior art prima di un fork

Se un'entità commerciale fa fork della vostra libreria, rimuove l'attribuzione e la rilicenzia, la vostra difesa più solida è la data di pubblicazione originale. Un timestamp qualificato sulla prima versione pubblica vi fornisce un archivio di prior art giuridicamente robusto che il fork non può antidatare.

Passo dopo passo: sigillare un file sorgente o un archivio ZIP del repository

Passo 1: Preparare l'artefatto. Per un singolo file, utilizzate direttamente il file sorgente. Per un repository completo, esportate un archivio ZIP — git archive --format=zip HEAD > repo-v1.0.zip. È supportato qualsiasi file fino a 500 MB.

Passo 2: Caricare su swisstrustlayer.com. L'hash SHA-256 viene calcolato lato client. Il vostro codice sorgente non lascia mai il browser — solo l'hash viene trasmesso ai server di Swiss Trust Layer.

Passo 3: Viene emesso il timestamp qualificato. Swisscom Trust Services ancora il vostro hash a un timestamp elettronico qualificato conforme a RFC 3161. Questo è l'evento giuridicamente vincolante.

Passo 4: Scaricare il certificato. Il certificato conforme a PAdES contiene l'hash del file, il timestamp, la catena dell'emittente e l'identità verificata. Conservatelo accanto al file originale o committatelo in un repository di prove separato.

Passo 5: Verificare in modo indipendente. Condividete il link di verifica su /validate con qualsiasi terza parte — investitore, avvocato, fondazione open-source — che deve confermare la vostra rivendicazione di prior art senza fare affidamento sulla vostra parola.

Peso legale: il fondamento normativo

Il software è protetto come opera letteraria ai sensi della Convenzione di Berna Art. 5 — il diritto d'autore esiste dal momento della creazione in 181 Stati membri, senza necessità di registrazione. Ma la Convenzione protegge il diritto; non prova la data. È questo il compito di un timestamp qualificato.

L'eIDAS Art. 41 concede una presunzione legale di accuratezza alla data e all'ora indicate da un timestamp elettronico qualificato — operativa in ogni tribunale dell'UE, con onere della confutazione a carico del contestante. ZertES Art. 2 è l'equivalente ai sensi del diritto svizzero. Queste sono presunzioni di legge, non linee guida.

Domande frequenti

Un timestamp di commit git è una prova legalmente vincolante di paternità?

No. I timestamp git sono impostati dall'orologio di sistema locale del committer e possono essere alterati da chiunque abbia accesso al repository utilizzando comandi git standard. Sono trattati come prove circostanziali, non come prove autorevoli. Un timestamp elettronico qualificato di un QTSP accreditato ai sensi dell'eIDAS Art. 41 porta una presunzione legale di accuratezza che la cronologia git non possiede.

Posso sigillare un intero repository, non solo un singolo file?

Sì. Esportate il vostro repository come archivio ZIP con git archive --format=zip HEAD > repo.zip, poi sigillate il file ZIP. Swiss Trust Layer supporta qualsiasi formato di file fino a 500 MB, così un'intera base di codice — inclusi documentazione, test e script di build — può essere sigillata in un'unica operazione. L'hash SHA-256 copre il contenuto binario esatto dell'intero archivio.

La sigillatura del codice sorgente espone il mio codice proprietario a Swiss Trust Layer?

No. L'hash SHA-256 viene calcolato nel vostro browser prima che qualsiasi cosa venga trasmessa. Swiss Trust Layer riceve solo l'hash — una stringa esadecimale di 64 caratteri — mai il codice sorgente stesso. I vostri algoritmi proprietari e i dettagli di implementazione rimangono completamente privati.

Cosa succede se sigillo un file e poi faccio commit sopra di esso?

Ogni sigillo è un'istantanea in un momento specifico. Sigillate nuovamente quando rilasciate una nuova versione. La serie di sigilli crea una traccia di provenienza che mostra l'evoluzione della vostra base di codice — utile per la due diligence degli investitori e le prove di sviluppo continuo.

Quanto costa sigillare codice sorgente su Swiss Trust Layer?

La sigillatura parte da CHF 5 per documento. Sono disponibili piani a volume per team con cicli di rilascio frequenti. Il costo di un timestamp qualificato è una frazione delle spese legali in qualsiasi controversia IP.

La cronologia git è un registro di sviluppo. Non è uno strumento legale. Per contractor, fondatori e maintainer open-source che devono dimostrare di aver scritto il codice per primi, un sigillo crittografico qualificato — ancorato a un'autorità di timestamp indipendente e accreditata e ammissibile ai sensi di eIDAS, ZertES e della Convenzione di Berna — è l'unica prova che i tribunali trattano come presumibilmente accurata. Sigillate la vostra base di codice prima che sorga la controversia. Scoprite di più sul quadro giuridico su /eidas e /zertes.