In 2024, Orca Security sued Wiz and demanded their full git version control history. Orca wanted to see "when features and functions were added, modified, or altered, including through engineers' notes and comments." The court recognized git history as relevant evidence in a software IP dispute. It ordered production of commit logs tied to two specific features.
That ruling should concern you. Your commits record author name, email, timestamp, and content hash. Git chains them together cryptographically, replicates them across clones, and makes them discoverable in litigation. You are building a legal record whether you intend to or not.
You already use git as a development tool. It is also a chain of custody for intellectual property. And you are probably destroying yours.
A Cryptographic Chain of Custody
Every git commit stores five things: the content of the change, the author's name and email, the author's timestamp, the committer's name and email, and the committer's timestamp. That commit is hashed using SHA-1 (or SHA-256 in newer repositories), and the hash incorporates the hash of the parent commit. Change one byte anywhere in the chain and every subsequent hash changes.
This is a Merkle DAG. The same data structure that makes blockchains tamper-evident. Your commit history is a cryptographic proof linking each change to all previous changes.
Git records three layers of timestamps. AuthorDate is when the content was written. CommitterDate is when it was finalized into the repository. And the server-side push timestamp, recorded by GitHub or GitLab, marks when the remote received the data. That third timestamp is outside the developer's control.
A clone is a full copy of the entire history. Your collaborators, CI runners, and backup systems each hold an independent replica. Forensics researchers call this "evidence proliferation." Tampering with one copy does nothing if fifty others exist unchanged.
Under Federal Rules of Evidence 902(14), data verified through a process of digital identification can be self-authenticating. Hash verification qualifies. Your git history records what you wrote and proves nobody changed the record after you wrote it.
Git History in Court
In Orca v. Wiz, the court agreed git history is relevant to IP disputes but denied the blanket discovery request as overbroad. It granted a targeted request for specific features instead. Well-structured git history with clean attribution is more useful in court than a sprawling monorepo dump.
Krause v. Titleserv shows what happens without version control evidence. An independent contractor wrote 35 programs over 10 years with no written IP assignment. The relationship ended, and neither side had clean evidence of who built what. The contractor took his notebook containing the only source code copies. The company had the running executables but no development history. The Second Circuit spent years sorting out what should have been a straightforward question of authorship. A git log would have resolved it in an afternoon.
SCO v. IBM collapsed partly because SCO could not point to specific lines of infringed code. The judge called it "astonishing" that they offered no competent evidence. Version control history documenting who wrote which lines and when would have been the foundation of that case. Without it, SCO had nothing.
Doe v. GitHub, the class action against Copilot, alleges that GitHub stripped authorship metadata from training data. The DMCA Section 1202(b) claim treats attribution data as legally protected copyright management information. Your name in a git commit qualifies. Stripping it out is a potential legal violation. That case is still active.
How Developers Destroy Their Own Evidence
Squash merging is the most common way. A pull request with 15 commits gets squash-merged into a single commit. Before GitHub fixed this in December 2019, the squash commit was attributed to whoever clicked the merge button. The original author disappeared. Even now with co-author trailers, the granular timeline is gone. Fifteen data points reduced to one.
Rebasing rewrites commit hashes. Force pushing overwrites the remote. If those commits existed on one machine and one remote, the evidence is gone. New hashes, new CommitterDates, broken chain. The cryptographic proof that your history is tamper-free now proves it was tampered with.
Researchers studied 111 million repositories and found 1.22 million with altered histories. 8.7 million rewritten histories total. The reasons were mundane: retroactive license changes, removing committed secrets. From a legal perspective, each rewrite weakens the evidentiary value of the whole chain.
Shared commit accounts are worse. Teams using a single identity like deploy@company.com or generic CI bot accounts destroy attribution at the source. Research across 2 billion git commits found over 23 million author identities, with major problems linking them to real people. If your commits are attributed to a shared account, they are not attributed to you.
Leaving a company adds another layer. You lose access to the repositories. If the company deletes the repo, migrates without history, or folds, your proof of authorship goes with it. GitHub deleted repos are recoverable for 90 days. After that, years of work have no provenance.
Three Things Developers Get Wrong About Copyright
The first is that paying for code means owning it. It does not. Under 17 U.S.C. Section 201, the author owns the copyright unless there is an explicit work-for-hire arrangement or a written assignment. For independent contractors, work-for-hire requires a signed written agreement AND the work must fall into one of nine statutory categories. Software does not fit those categories. CCB Journal published an analysis concluding the work-for-hire doctrine "almost never works in software development contracts."
If you are an independent contractor and your agreement has no copyright assignment clause, you own what you wrote. The client paid for the service. They received a license to use the deliverable. They did not receive the intellectual property. This surprises both sides when it matters.
Only 28% of freelancers use a written contract for any given project. Of those who do, 68% have unknowingly signed away IP rights. The gap between what developers think their contracts say and what they actually say is where disputes start.
The second is that git history is bulletproof evidence. It is not. Author fields can be set to anything. Local timestamps can be faked by changing the system clock. Without GPG-signed commits or server-side push timestamps from a third-party platform, git history is strong corroborating evidence but not conclusive on its own. The Orca v. Wiz court treated it as relevant but still pushed back on scope. It strengthens your position. It does not guarantee it.
The third is that copyright requires registration. Under the Berne Convention, protection is automatic in 182 member states the moment you write the code. But in the US, registration unlocks three things you cannot get without it: the right to file an infringement lawsuit (Fourth Estate v. Wall-Street.com, 2019), statutory damages up to $150,000 per work for willful infringement (17 U.S.C. Section 504), and recovery of attorney's fees (Section 505). Without registration, you can recover actual damages only, and for code, proving a dollar amount is a different kind of fight.
The $45 Insurance Policy
US copyright registration for source code costs $45 through the Electronic Copyright Office. You submit the first and last 25 pages of source code. If trade secrets are a concern, you can redact portions or submit only the first and last 10 pages. Processing takes about four months. Expedited review costs $800 and takes five business days.
There is no citizenship requirement. International developers building for US clients can and should register. Without registration, you have automatic protection under Berne but no access to statutory damages or attorney's fees in US courts. For anyone doing contract work for American companies, $45 buys a legal position that is otherwise unavailable.
Timing is critical. 17 U.S.C. Section 412 limits you to actual damages if infringement starts before your registration is processed. No statutory damages. No attorney's fees. Fourth Estate confirmed the Copyright Office must process the registration before you can file suit. If a dispute starts and you have not registered, you are waiting months before you can do anything. Register before you need to.
Unicolors v. H&M (2022) confirmed that inadvertent errors on your application do not invalidate the registration. Deliberate falsehoods at the time of filing would. Honest mistakes do not.
What To Do Now
Sign your commits. GPG or SSH signatures prove the commit was made by the holder of a specific private key. GitHub stores the verification record with a timestamp that cannot be edited after the fact. A signed commit is a verified attestation. Without the signature, a commit is a self-reported claim that anyone could have authored.
Stop squashing by default. Clean git history looks nice and destroys legal evidence at the same time. A merge commit preserves the full branch history with every original author, timestamp, and message. A squash commit erases all of it.
Keep your own remote. If you are a contractor, maintain a clone on infrastructure you control. A remote with its own server-side timestamps that survives the end of the engagement. You are preserving proof of authorship, not taking code that belongs to someone else.
Use your real name. Commits attributed to deploy@company.com or ci-bot or jane@computer.local are not evidence of your authorship. They are evidence that someone pushed code. Use a real name and a verifiable email.
Write commit messages for a reader who does not know the codebase. "Fixed stuff" tells a judge nothing. "Implemented webhook deduplication using idempotency keys to prevent duplicate order processing" documents original engineering work. Your commit messages are the narrative layer of your contribution.
Register your copyright. $45 and a four-month wait. Do it before anything goes wrong. Section 412 does not care about your reasons for waiting.
Read your contracts. All of them. Look for two clauses: copyright assignment and IP ownership. If neither exists, you likely own what you build. If both exist and are specific, you likely do not. If the language is vague, that is where disputes live. Clarify it before you write the first line of code.
The Record
If you have a GitHub account, you are building a legal record right now. Your commits could be subpoenaed, analyzed, and presented in a courtroom. The name on those commits, the integrity of your history, your signatures, your registrations: those are decisions you are making today that you cannot make retroactively.
You will probably never face a copyright dispute. But if you do, your git log will be one of the first things a lawyer asks to see. Make sure it says what you need it to say.
