How software companies can make Copyright Office deposits useful evidence, without exposing the crown jewels.
At 2:13 a.m., the alert does not come from a lawyer. It comes from a customer or sales channel. A competitor has launched a product that behaves in ways that feel too familiar. It gives the same unusual error message. It follows the same workflow. It solves a corner case the same way your team solved it. Someone remembers that a former employee, contractor, vendor, or integration partner once had access to the code.
The natural reaction is to call engineering. The engineers open the company repository and say, “we can prove this.” Often they can. But in a copyright case, the first question may be more basic: what exact version of the software did the company register, what source-code pages were deposited with the U.S. Copyright Office, and do those pages match the version that was allegedly copied?
That is why software copyright deposits should not be treated as a clerical task. They are part of the evidence system for the business. A good deposit helps the company later explain what it owned, when it existed, which version mattered, and how the accused product relates to the original work.
The deposit is evidence, not paperwork
Copyright protection exists when original source code is fixed in a tangible form. Registration is not what creates the copyright. But for a U.S. work, 17 U.S.C. Section 411(a) generally requires registration before an infringement lawsuit can be filed. Timing also matters. Under 17 U.S.C. Section 412, a timely registration can preserve statutory damages and attorney fees. Under 17 U.S.C. Section 410(c), a certificate issued before or within five years after first publication can carry evidentiary weight in court.
For computer programs, the Copyright Office usually wants identifying portions of source code under 37 C.F.R. Section 202.20 and Circular 61. Think of the deposit as the official bridge between the certificate and the software. It does not have to be the entire bridge, but it must honestly identify the work being claimed.
Why the first edition deserves special treatment
The first commercial or production edition often matters most. It is the version shown to pilot customers, investors, contractors, integration partners, and early users. It is also the version most likely to be copied before the company realizes a problem exists. Waiting until version 3.7 to register the software may be better than never registering, but it is not the same as registering version 1.0.
The Copyright Office treats each version of a computer program that contains new copyrightable authorship as a separate work. A later registration usually covers the new or revised material in that later version, not every prior published version. The recent HEALTHeSTATE, LLC v. United States litigation shows the risk: if the applicant claims one version but deposits source code from a materially different later version, the registration can become the fight instead of the copying.
The practical rule is simple. Register the first real release promptly. Register major later releases when they add meaningful new code. Do not use today’s cleaned-up codebase to represent yesterday’s product.
GitHub, translated for non-developers
GitHub is not the copyright registry. It is a widely used online service that stores source code and helps software teams work together. Most teams use GitHub with a tool called Git. Git records changes to the code over time. Each recorded snapshot is called a commit, and each commit has a long unique identifier. A tag is a human-readable label that says, in effect, “version 1.0 shipped here.” A branch is a parallel line of work, such as a release line, a testing line, or a future-feature line.
Business leaders and lawyers do not need commands. They need to ask the development team for the right evidence. For the version being registered, the team should identify the product name, version number, release date, Git commit identifier, release tag, build number, and records showing what actually shipped. If the team did not create a tag at release time, it can often reconstruct the correct snapshot from release notes, package records, deployment logs, customer delivery records, or archived build files.
The key is not the label inside GitHub. The key is proving that the deposit was generated from the same codebase as the version the company says it is registering.
What the team should prepare
Before filing, legal and engineering should create a short release evidence memo. It should identify the title of the program, the version, the author or work-made-for-hire owner, the copyright claimant, the publication status, the first publication date if any, and whether the code includes earlier versions, third-party code, open-source code, generated code, or AI-assisted code.
The development team should preserve two things. First, keep the complete internal source snapshot for the registered version. That is not necessarily what gets sent to the Copyright Office, but it may become essential in litigation. Second, keep the exact deposit file that was uploaded, along with a note explaining how it was generated. A repeatable method is better than a memory.
What code belongs in the deposit
The default source-code deposit for a new program is usually the first 25 and last 25 pages, or the entire source code if the program is 50 pages or fewer. That sounds awkward for a modern product spread across many services, modules, and repositories. The Copyright Office’s eCO guidance recognizes the problem: if a program has no clear beginning or end, the applicant should select pages that reasonably represent the first and last portions of the program.
For a large application, choose authored code that reflects real creative choices. In C# applications built around MVC or MVP patterns, that may include domain models, service classes, controllers, presenters, view models, and nontrivial business logic. In Blazor, include human-written Razor components and code-behind files. In React, focus on authored components, state-handling logic, routing, data transformations, and custom hooks. In Rust or C++, include authored modules, traits, templates, headers, implementation files, adapters, and performance-sensitive routines.
Do not spend scarce deposit pages on material the company did not write or should not claim. That usually means excluding third-party libraries, package directories, generated designer files, compiled binaries, minified bundles, routine build output, ordinary configuration files, and vendor templates unless the original authorship is actually there. The deposit should identify the company’s protected expression, not the ecosystem around it.
If a module is independently distributed, separately licensed, separately versioned, or especially likely to be copied, consider a separate TX registration for that module. For an integrated product released as one application, a single registration with a coherent representative deposit is usually cleaner.
The safe file to send
The Copyright Office accepts several electronic file types, including PDF, TXT, DOC, DOCX, HTML, and ZIP, although the files inside a ZIP must also be acceptable. For most proprietary software, the best deposit output is a searchable PDF of the selected source-code pages. A TXT file is easy to generate, but pagination and redactions are harder to control. A DOCX file can reflow. A ZIP file can look like a repository dump rather than a curated identifying deposit.
The PDF should be boring, readable, and durable. Put the title, version, claimant, release date, commit identifier, and generation date on the first page. Add file-path headers, page numbers, and line numbers. The rules do not prescribe a programming font size or line spacing, but the deposit must be visually perceptible and examiner-friendly. Ten- or eleven-point monospaced type, with about 40 lines per page, is a sensible working standard.
Do not expose more than the law requires
Depositing all source code may feel like the strongest proof. For proprietary software, it may also be unnecessary and unsafe. A Copyright Office deposit is not like posting the repository on the open internet, but it is not a private escrow vault either. The public may inspect deposits associated with completed registrations or refusals. Copying is restricted, but inspection itself is real.
If the code contains trade secrets, use the trade-secret deposit options in 37 C.F.R. Section 202.20. Common options include first and last 10 pages with no blocking, first and last 25 pages with trade-secret portions blocked out, or object code plus at least 10 consecutive pages of unredacted source code. Redactions must leave an appreciable amount of original code visible. Never deposit credentials, API keys, customer data, private endpoints, signing certificates, or internal comments that reveal secrets unrelated to authorship.
If litigation later requires a copy of the deposit, the request is made through the Copyright Office’s Records Research and Certification Section. Copies are generally supplied only with written authorization from the claimant or rights owner, a litigation statement from an attorney or authorized representative in actual or prospective litigation, or a court order. That protection is useful, but it is not a reason to over-deposit.
Three case files worth knowing
Data General Corp. v. Grumman Systems Support Corp. is the success story. Data General won a major software copyright verdict after a competitor used its diagnostic software. The court rejected the argument that protection was limited to the pages deposited with the Copyright Office. The deposit identified the work; it did not define the outer boundary of the copyright.
Fonar Corp. v. Domenick is the modular-software story. The accused infringer argued that the owner should have deposited code for each subprogram. The Second Circuit declined to impose that burden and recognized that a single computer program may include modules, subroutines, and sub-subroutines serving an overarching purpose.
HEALTHeSTATE and PaySys International, Inc. v. Atos are warning labels. One teaches that the deposit must match the version being registered. The other teaches that the title, description, and deposit should all point to the same work. A company should not title a registration as if it covers one component when it means to protect the whole platform.
These cases show where deposits pay off: former-employee disputes, contractor disputes, vendor and support-software disputes, license overuse, integration-partner copying, and acquisition diligence. In each setting, the registered version, deposited pages, full internal source snapshot, and chain of ownership should tell the same story.
AI will make clean deposits more valuable
AI-assisted coding will make disciplined deposits more important. The Copyright Office’s AI registration guidance and its 2025 copyrightability report emphasize human authorship. In software terms, that means companies should be able to show human architecture, selection, editing, review, debugging, integration, and approval. The stronger the human record, the easier it is to claim the protected expression in the program and exclude what should not be claimed.
The answer is not to paralyze development teams with legal paperwork. It is to preserve ordinary records that already matter: release notes, code reviews, ticket histories, authorship assignments, contractor agreements, AI-use policies, and final source snapshots.
The enduring lesson
At 2:13 a.m., when the clone ships, the company should not be asking engineers to reconstruct history under litigation pressure. The better answer is already in the file: the first edition was tagged, the release record was saved, the correct source-code pages were deposited, the trade secrets were protected, the full source snapshot was preserved internally, and later major versions were registered when they mattered.
Copyright deposits will not replace patents, contracts, trade secrets, security controls, or careful hiring and offboarding. But they do something those tools do not. They create an official, version-specific record that can turn a vague accusation of copying into a disciplined proof story. In software disputes, that boring record may become the most important evidence in the room.
Anton Hopen is a registered patent attorney and a shareholder at Trenam Law in Tampa, Florida. He is board certified in intellectual property by The Florida Bar. He can be reached at ahopen@trenam.com.
