How to Copyright Software & Source Code (2026 Developer Guide)

An independent developer named Kavi spent eighteen months building a niche iOS app for amateur birders. Six months after launch, a near-identical app appeared in the App Store with a different name and a slightly different icon. The code was suspiciously similar. The UI flows were nearly identical. The list of bird species was in the same idiosyncratic order he’d chosen.

Apple’s response when he reported the apparent clone was reasonable: provide proof of original authorship and we’ll investigate. Kavi had Git history showing his commits going back to the beginning of the project. He had design files dated from his Figma account. He had the original Pages document of his app proposal from before he’d started coding.

What he didn’t have was anything from outside his own custody. Every piece of “proof” he could produce was a record he could theoretically have backdated. Apple’s review of the case took 11 weeks. The competing app stayed in the store the entire time. Kavi eventually won, but the resolution would have taken 48 hours instead of 11 weeks if he’d registered the codebase with a third party before launch.

Here’s how to avoid being Kavi.

What software copyright protects

The source code as you wrote it (any language)
The compiled binaries
The structure and organization of the codebase
Documentation, comments, and embedded text
UI design as expressed in code (not the underlying ideas)
Database schemas as creative arrangement

The functionality the software performs (that’s potentially patent territory)
Algorithms expressed only as ideas
Programming language syntax (you can’t copyright “for loops”)
Common patterns and idioms
APIs and interfaces in many jurisdictions, though this is contested

The Supreme Court’s 2021 decision in Google v. Oracle clarified that the use of API declarations can be fair use in some circumstances. This narrowed copyright protection for pure interface definitions, but the underlying code implementation remained protected.

For a fuller treatment of where copyright stops and patent starts, see our IP-types breakdown. The short version: copyright protects your specific code; patent protects novel technical methods regardless of how they’re expressed.

What to register, exactly

Choose carefully because the registration covers specific files at a specific moment.

Register the source code, not just the binaries. Binaries are derivative works. Source is the primary creative expression. The deposit should include source.

Register the entire codebase as a single work for most cases. A modern web or mobile app might be tens of thousands of lines across hundreds of files. Registering the whole thing as one work simplifies enforcement against anyone copying any substantial part.

For libraries you ship separately, register them individually. If you publish multiple npm packages, Python libraries, or open-source modules, each is a distinct work and warrants its own registration.

Register documentation separately when it’s substantial. A 50-page developer documentation document is its own copyrightable work. The same goes for API reference manuals, getting-started guides, and tutorial content.

How to package a codebase for upload

Modern registration services accept files up to several GB. Most codebases compress to a few hundred MB or less.

The cleanest packaging methods:

Method 1: Git bundle

git bundle create my-project.bundle --all

This creates a single file containing your complete repository history, all branches, all commits. The bundle is byte-identical regardless of who creates it from the same repo state, and it captures the entire chain of development.

For copyright purposes, the bundle is excellent because it includes the complete history of authorship as recorded in your commits.

Method 2: Source ZIP

git archive --format=zip --output=my-project.zip HEAD

This creates a ZIP of your current working tree without the .git directory. Cleaner if you don’t want to include history, smaller file, sufficient for proof of the current state.

Method 3: Filtered tarball

tar --exclude='node_modules' --exclude='.git' --exclude='dist' -czf my-project.tar.gz .

Useful if you want to include the .git but exclude generated artifacts (dependencies, build outputs).

For most registrations, the Git bundle is the best choice. It captures everything an enforcement action might need, including the timestamps of individual commits.

The 5-minute workflow

The sequence working developers use.

Step 1: Pre-release registration with an online service

Before pushing your app to the App Store, the Play Store, npm, PyPI, or any public registry, register the current state with an online registration service.

Sign up at the service, package your codebase as a Git bundle or ZIP, upload, complete the registration. Add your name (or your company’s) and any co-authors as joint copyright holders. Takes about 60 seconds.

You get back:

A reference number
A SHA-256 hash of the codebase file
A blockchain-anchored timestamp
A public verification URL

The verification URL is what you’ll include in the README, in your support documentation, and in any takedown notices. The hash uniquely identifies your exact code at the moment of registration.

Step 2: US Copyright Office registration

For US-based developers releasing commercial software, file Form TX with the US Copyright Office. The fee is $45-$65. Processing takes 3 to 9 months.

The deposit copy for software is somewhat unusual. The US Copyright Office’s “rule of doubt” deposit option lets you submit:

First 25 pages and last 25 pages of source code, or
First 25 pages and last 25 pages with redactions of trade secret portions, or
25 pages of source code plus the object code if you’re protecting trade secrets

This is a deliberately limited deposit because the Copyright Office recognizes that publishing full source code as a deposit would defeat trade-secret protection. The registration still covers the entire work; the deposit is just a sample.

USCO registration enables statutory damages and attorney’s fees in US litigation, which can be substantial for commercial software infringement.

Step 3: Add license metadata

Independent of registration, declare your license clearly in the project:

LICENSE file in the root of the repo with your chosen license text Package metadata (package.json, setup.py, Cargo.toml, etc.) referencing the license Source file headers with copyright notices and license references

Common license choices for software:

All rights reserved for proprietary commercial software
MIT, Apache 2.0, BSD-3-Clause for permissive open source
GPL, AGPL for copyleft open source
Commercial-use licenses for source-available proprietary software

The license is a separate question from registration. You can register copyleft open source software and that registration still serves enforcement purposes against violators (people who use your AGPL code without complying with AGPL).

Step 4: Establish ongoing version registration

Software evolves. The version you registered at launch isn’t the version that’s in production six months later. Two approaches to keeping current:

Approach A: Register every major release. Each tagged release gets its own registration with version tracking linking the chain. V1.0, V1.1, V2.0, etc.

Approach B: Periodic snapshot registration. Every quarter, register the current state of the main branch. Less granular than per-release but cheaper for fast-evolving projects.

For most projects, Approach A is cleaner. Each release is a meaningful milestone, and the registration cadence matches your release cadence.

Open source complications

If your software uses open source dependencies, two questions matter:

1. Your code is yours. Your original contributions are copyrightable in your name. The dependencies are copyrighted by their respective authors. The combined work has multiple copyright holders for different portions.

2. License compliance is separate from registration. Your registration covers your original work. Compliance with the licenses of your dependencies (attribution requirements, source disclosure requirements, copyleft propagation) is a contract-and-license question, not a copyright registration question.

When you register your codebase including dependencies, you’re not claiming copyright over the dependencies. The registration document should be clear: this work includes [list of open source dependencies] which are copyrighted by their respective authors under [respective licenses]. Your own contributions are what you’re claiming.

For a deeper analysis of how blockchain timestamping helps with software ownership disputes, see our piece on the technology.

Trade secret considerations

For commercial software with proprietary algorithms or methods, copyright is layered with trade secret protection:

Copyright protects the specific code expression
Trade secret protects undisclosed know-how, methods, and proprietary information

For registration purposes, the practical tension is: registering the full source code as a public document conflicts with keeping it secret. The US Copyright Office’s “rule of doubt” deposit (above) is designed for exactly this conflict.

If you have genuine trade secrets in your code, work with a copyright attorney on registration so the deposit doesn’t waive the trade-secret protection.

App Store / Play Store enforcement

The App Store and Play Store have IP infringement reporting systems. The mechanics are similar across both:

Identify the infringing app in the store
File a copyright complaint through the platform’s IP form
Include your registration verification link as evidence of prior authorship
The platform reviews and takes action (typically removal of the infringing app)

Apple’s reviews tend to be slow but thorough. Google’s are faster but less rigorous. Both platforms accept registration certificates and blockchain-anchored verification links as valid proof.

The key fact: platforms strongly prefer third-party verifiable evidence over claimant-supplied evidence. A registration with a public verification URL is what they want. Your local Git history is what they’re skeptical of.

GitHub-specific considerations

For open source maintainers on GitHub, copyright infringement situations have a particular flavor: forks that strip attribution, repositories that copy code with different licensing, “private” forks that get republished as original work.

GitHub has a DMCA takedown process for copyright violations. The process is well-established and works reliably for clear cases. You file at https://github.com/contact/dmca, providing:

Identification of the infringing repository
Identification of your original work (with verification URL)
Statement of authorship and good-faith belief
Contact information and signature

GitHub typically responds within a few business days. Disputed cases get a counter-notice procedure. Repeat offender repositories may be removed entirely.

For projects you actively maintain, periodic searches for your project name, distinctive function names, or unique comments can surface unauthorized copies. Copyright registration makes the takedown much faster than relying purely on Git history.

What to skip

Some things you don’t need to do:

Don’t register every single commit. Registration covers the version you upload. Per-commit registration is overkill and impractical.

Don’t register configuration files separately. Config files are typically not creative works; they’re parameters for the underlying software.

Don’t try to register obvious patterns. “For loops that iterate over arrays” is not copyrightable. Standard idiomatic patterns can be reused freely.

Don’t register dependency code. It’s not yours. Your registration covers your contributions.

The honest assessment for developers

For a working software developer:

Annual cost of online registration plus quarterly snapshots: about $50
USCO registration for commercial releases: $45-$65 per release
Average cost of resolving an app-clone or code-theft dispute without registration: $5,000 to $25,000 in time, legal fees, and lost App Store revenue

The math is more lopsided in software than in any other creative field. Source code is uniquely easy to copy (it’s literally just text), uniquely easy to verify (compare hashes), and uniquely valuable to protect (years of work compress into a tarball).

The cost of doing this right is trivial. The cost of not doing it surfaces only after the theft, by which time the damage is done. Kavi, from the opening, now registers every release with a Git bundle the moment it’s tagged. The whole process takes about a minute. He’s never had another 11-week investigation.

Start with the codebase you have right now. Even retroactively, a registration today establishes proof of the current state and lets you enforce going forward. Then add registration to your release process so you never have to think about it again.

How to Copyright Software and Source Code