Software Copyright Registration (US): When and How to Protect Your Code Without Slowing CI/CD

By [Name], [Role]

Fundraising, enterprise sales, and M&A all trigger the same uncomfortable question: do you actually own what’s in production? If the answer depends on memory, Slack threads, or a contractor who’s gone dark, a dispute can freeze a deal — or turn a copied feature into a costly, slow enforcement problem. This guide is written for founders, CTOs, and product counsel who want a practical registration workflow that fits CI/CD: minimal drag, maximum diligence and enforcement leverage.

Hook: your main branch is production — and a single disputed commit can become legal debt. Start by tightening code ownership metadata so your registration scope matches what you can prove (authorship, assignments, third-party components, and release tags).

• When to file: register around real “exposure” events (launches, app store releases, public repos), and file quickly if you may need statutory remedies.
• What to deposit: use a tagged snapshot; redact trade secrets; clearly exclude open-source/third-party code from your claim.
• What registration unlocks: stronger settlement posture, and (if timely) eligibility for statutory damages and attorney’s fees under 17 U.S.C. § 412.

CTA: Get the Implementation Guide.

Why software copyright registration matters (and when trade secrets are the better system)

Registration changes your enforcement options. In the US, you generally can’t file a copyright infringement lawsuit over a “United States work” until the Copyright Office has acted on the application (registered it or refused it). The Supreme Court confirmed this “registration approach” in Fourth Estate, so waiting to register can mean waiting to sue.

Timing changes leverage. If you register early enough, you preserve eligibility for statutory damages and (potentially) attorney’s fees; if you register late, you may be stuck proving actual damages — often hard in software disputes where value is bundled across features and contracts. That delta affects settlement dynamics: the other side has less incentive to “run out the clock” when exposure is clear.

Operational tools get easier. Registration doesn’t replace the DMCA, but it can strengthen platform/vendor escalations (app stores, hosting providers, marketplaces) because you can point to a registration record number while asserting a good-faith claim.

• Registration = reduce legal debt: best for distributed software (desktop/mobile clients), SDKs, visible UI flows, and code shipped to customers.
• Trade secret = preserve run-time secrecy: best for non-distributed back-end services, security-sensitive logic, and secret algorithms you can keep off user devices.

Example: a seed-stage SaaS ships a desktop client; a competitor clones the UI and core modules. With timely registrations tied to release tags, you can move faster (credible demands + clearer remedies) instead of rebuilding provenance under pressure.

Limits: registration doesn’t stop copying; it improves remedies and proof posture. And deposits can expose secrets if you don’t plan redactions and exclusions carefully (we’ll cover a deposit strategy next).

Trigger events: when startups should register code (mapped to lifecycle + release cadence)

Don’t wait for “perfect.” Build a trigger-based rule: register when exposure increases and when you can still preserve “timely registration” benefits (statutory damages/fees generally require registration before infringement begins, with a key exception if you register within 3 months of first publication). See 17 U.S.C. § 412.

• Launch/public distribution: app store releases, shipped desktop/mobile clients, customer-delivered binaries, or a public GitHub repo are practical “publication” flags — plan a filing around the release tag.
• Investor demos & pilots: a private demo isn’t always “publication,” but it’s still disclosure. Conservative approach: register the core module before broad demo days or large pilot rollouts.
• Open-sourcing a component: file (or at least snapshot) proprietary core before pushing the OSS wrapper public; clearly exclude third-party/OSS code in the claim.
• Fundraising/M&A: register the repos that appear on diligence asset schedules (and fix ownership chain issues) to reduce closing friction.
• Hiring bursts/contractor builds: treat heavy external contributions as a trigger to lock snapshots and register, because authorship/assignment gaps are common.

Cadence tip: if you deploy weekly, don’t file weekly — batch quarterly and treat major release tags (e.g., v1.3.0) as “registration snapshots.”

Scenario: Open beta in 30 days — tag and register the core client code now; file a follow-on registration after the first big post-beta release. Open-sourcing a CLI — register the proprietary service/client modules first, then publish the CLI with clean exclusions.

What to register: scope and deposit strategy for modern codebases (and how not to leak secrets)

Register the parts of your product where your team’s expression lives: source code (and sometimes the selection/arrangement of modules), plus limited supporting materials when they help tell the story of copying. Build scripts, configs, and templates can help if they reflect creative choices, but don’t expect thin boilerplate to carry a dispute. For UX-heavy products, screenshots or key UI flows can be useful supplementary material when the “look and feel” is what gets cloned.

Exclude what you don’t own. Don’t over-claim third-party/OSS libraries, SDK code, or vendor boilerplate — list them as excluded material and keep your deposit focused on proprietary modules. For generated code (including AI-assisted output), be conservative: label machine-generated chunks and claim only what your team actually authored/edited in a copyrightable way.

Deposit strategy (developer-first): decide between (1) whole-repo filings (simpler diligence story) and (2) modular filings (cleaner boundaries when you have mixed licensing or multiple products). The Copyright Office’s common electronic deposit for a new program is the first 25 and last 25 pages (or “equivalent units”) of source code, with specific options for trade secret blocking when needed.

• Redact secrets: API keys, private endpoints, auth logic, proprietary schemas — block out only what’s necessary and keep redactions proportionately small.
• Make it reproducible: tag the release, store a zip of the deposited snapshot, and record a commit hash/build hash.
• Pick a “deposit slice”: core domain modules + key UI assets, not dependency directories.

Pattern: “proprietary core + OSS edge.” Deposit the core service/client modules and explicitly disclaim the OSS wrapper. Keep an internal inventory list: repo, tag (v1.3.0), commit SHA, directories included/excluded, and any redaction notes.

How to register software: step-by-step US Copyright Office walkthrough (Form TX + pro tips)

Step 1: Gather inputs before eCO. Confirm claimant/author details and whether contributions are work made for hire (employees) or require written assignments (contractors). Decide whether the work is published and lock the first publication date — this date drives remedy timing and is a common diligence question.

Step 2: Pick the right path. Most software is registered as a literary work through the eCO system (often described as “Form TX” in practice). If you have materially separate products/modules, multiple filings may be cleaner than one oversized “everything” claim.

Step 3: Build the deposit package (without leaking secrets). For a new computer program, the Copyright Office’s eCO guidance is typically the first 25 and last 25 pages (or equivalent units) of source code; “equivalent” can be measured in lines (the Office suggests 40 lines ≈ 1 page). If trade secrets are present, you can submit source with portions blocked out, but the blocked-out portions must be proportionately less than what remains. Keep an unredacted internal copy for evidence, and add a short cover letter noting redactions and excluded OSS/third-party code.

Step 4: Submit, pay, track. Fees change — treat them as a variable line item. Timelines vary from weeks to months; expedited “special handling” may be available in limited circumstances.

Step 5: Time for remedies. File promptly, and aim for within 3 months of publication when you want statutory damages/fees leverage (17 U.S.C. § 412).

• Failure modes: wrong publication date, unclear authorship, over-claiming dependencies.
• Pro tip: keep a private “registration packet” in the repo: tag, commit SHA, deposit zip, redaction notes, and ownership docs.

Legal architecture: employees, contractors, OSS, and the ownership chain you’ll be asked for in diligence

Copyright registration is only as strong as your ownership chain. In diligence, buyers and investors don’t just ask “who wrote it?” — they ask “who owns it, under signed paper, for every material contributor?”

• Employees: US law often treats employee-created code as within scope of employment, but you still want clean invention assignment + confidentiality agreements (and consistent onboarding/offboarding) so there’s no argument about scope or carve-outs.
• Contractors: the default is dangerous — independent contractors generally own what they create unless there’s a written assignment (and “work made for hire” is limited to specific categories). Treat every contractor PR as “unowned until assigned.”
• Inbound OSS: CLAs and an intake process reduce surprises when community or vendor contributions enter your core repo. Track licenses and make sure the license terms match your distribution model.

Developer-first evidence: preserve provenance in systems you already run: commit history, protected branches, CI logs, signed commits, tickets linking specs to implementation, and a folder of executed assignments keyed to contributor identity.

Red flags: missing assignments, misclassified contractors, founder side-project code merged in, and copyleft dependencies creeping into proprietary core.

Fixes that scale: run a retroactive assignment sprint (identify contributors → confirm scope → sign + attach repo/module list), add SOW language (assignment, confidentiality, OSS policy), and adopt a lightweight OSS approval + attribution + scanning workflow. For engineering teams mixing licenses, use the license compatibility matrix to avoid “accidental” obligations that complicate registration and enforcement.

Enforcement & operational readiness: DMCA, demand letters, and a litigation-ready CI/CD evidence trail

When you spot suspected copying, speed matters — but so does not over-claiming. Your first 48 hours should be about preserving a clean record and separating proprietary expression from third-party code.

Triage (do this before you email anyone):

• Preserve evidence: tag the relevant release/commit, export the repo state, archive build artifacts/binaries, capture screenshots, and retain CI logs showing build times and authorship context.
• Confirm what’s yours: identify the copied modules and strip out OSS/vendor components so your claim targets only protectable, owned code.

Staged escalation: A DMCA takedown can remove infringing material from a specific host (Git platforms, app stores, web hosts), but it won’t resolve ownership disputes or force a competitor to stop building — treat it as a containment tool. A demand letter is stronger when it includes (1) your registration number or pending application status, (2) side-by-side infringement examples, and (3) a concrete ask (remove, license, certify deletion, preserve evidence).

When litigation becomes real: registration timing drives leverage (eligibility for statutory damages/fees and how quickly you can file). Engineering can help by maintaining a litigation-ready trail:

• Immutable artifact storage; reproducible builds; commit/build hashes and timestamps
• Access logs and tamper-evident controls (protected branches, signed commits)
• Lockfiles and SBOMs to distinguish proprietary code from dependencies

Example: a competitor ships an identical module structure. In 48 hours you can assemble an evidence packet: your tagged release + deposit snapshot, build hashes, diff excerpts highlighting copied files, screenshots of the competitor’s distribution, and a dependency report showing what is (and isn’t) your proprietary code.

Startup checklist & 0–90 day timeline (implementation you can run like a sprint)

Run copyright registration like an engineering sprint: assign owners, define “done,” and produce a repeatable packet you can hand to counsel, investors, or acquirers.

• CTO: inventory repos/modules; dependency list (lockfiles/SBOM); authorship map by contributor; choose release tags to register.
• Founder/ops: confirm every contributor’s status (employee vs contractor) and collect missing signatures.
• Counsel: review assignments/SOWs/CLAs; define deposit scope; approve redaction/exclusion notes; submit and track filings.
• Deposit prep: set redaction rules, OSS exclusion list, and a snapshot workflow (tag + commit hash + stored zip).
• Filing: eCO submission, status tracking, and secure certificate storage (plus a pointer in your diligence folder).

0–90 day timeline: Day 0–7 clean ownership/provenance and pick tagging strategy; Day 8–30 prepare deposits and file core modules; Day 31–60 cover post-launch filings (and a second filing if a major release ships); Day 61–90 build an enforcement-ready packet (evidence trail + dependency separation) and a diligence bundle.

Cost drivers: number of codebases/versions, contractor cleanup, and OSS complexity. Promise Legal typically offers a flat-fee entry option (strategy + scoping), with packages scaling by filing volume and cleanup needs.

CTAs: Get the Implementation Guide. Join the Dev-Legal Newsletter.

• Tag your next release (vX.Y.Z) and archive the source snapshot
• Run an OSS/license scan and create an exclusion list
• Close assignment gaps for contractors and founders
• Prepare the first/last 25-page (or equivalent) deposit excerpt with redactions
• Schedule your first filing date (and a 3-month post-publication backstop)