Copyright Registration for Software: Source Code, Deposits, and Trade Secrets

For a software company, “register the code” sounds simple until the filing asks which version is being registered, who authored it, whether it has been published, what preexisting material it contains, and what source code will be deposited with the U.S. Copyright Office. Those questions are not clerical. They determine what the registration covers and whether the deposit exposes more confidential code than necessary.

Copyright registration for software works best when it is treated as part of product and intellectual-property management—not as a form completed after a dispute begins. A thoughtful filing connects the registration to a specific release, confirms ownership, separates new authorship from third-party or previously registered code, and uses the Copyright Office’s deposit options correctly.

What software copyright protects—and what it does not

A computer program is copyrightable as a literary work. Copyright can protect original expression in source code and object code. It may also reach copyrightable screen displays generated by the program. Tucker Law’s copyright practice works with creators and businesses on registration, ownership, and enforcement questions involving software and other digital content.

That protection has an important boundary. Under 17 U.S.C. § 102(b), copyright does not extend to an idea, procedure, process, system, method of operation, concept, principle, or discovery. The Copyright Office’s Circular 61 similarly explains that copyright does not protect the functional aspects of a program, including algorithms, functions, logic, and system design.

In practical terms, copyright may address copying of protected code or other original expression. It does not give the owner a monopoly over the underlying product idea or every program that produces a similar result. Depending on the technology and business model, patents, trade-secret controls, contracts, and trademark protection may complement copyright rather than duplicate it. Tucker Law’s broader intellectual property practice can help evaluate how those tools fit together.

Define the exact version before filing

A registration should identify a specific version of the program. Circular 61 states that each version containing new copyrightable authorship is considered a separate work. A registration for a new version generally covers the new material contributed to that version—not every line that ever appeared in the product.

This distinction matters for software that changes continuously. A company may have a production release, a mobile build, a customer-specific branch, and a development branch in the same repository. “Our platform” is not a precise filing unit. Before an application is prepared, the company should identify:

• the product name and version number;
• the code commit, build, or release date tied to the deposit;
• whether that version was published and, if so, when and where;
• which portions are new in that version;
• which portions were previously published or registered; and
• which portions came from open-source libraries, vendors, or other third parties.

A release ledger connecting version numbers to repository tags, completion dates, publication facts, registrations, and ownership records can make later filings much more reliable. It also helps a business explain the lineage of its code during diligence, licensing, or a dispute.

Confirm ownership before naming the claimant

The person who paid for software development is not always the copyright owner. Code created by an employee within the scope of employment may qualify as a work made for hire, making the employer the author for copyright purposes. Contractor-created code presents a different analysis. The statutory work-made-for-hire rules are limited, and software commissioned from an independent developer does not automatically belong to the customer merely because the invoice was paid.

A written assignment is often the cleanest way to address ownership of contractor-created code. The agreement should be examined for the work covered, the rights transferred, when the transfer occurs, treatment of background technology, and any retained license. Tucker Law’s discussion of work made for hire and commissioned work explains why payment alone is not the same as copyright ownership. Similar chain-of-title issues arise when employees, founders, and contractors contribute to a codebase; the firm’s employee invention rights guide addresses related ownership records and agreements.

Ownership should be resolved before the application identifies an author and claimant. If a founder wrote code before forming the company, for example, formation documents or an IP assignment may be needed to establish how the company acquired the rights. If multiple contributors retained rights, a single company may not be able to claim the entire program as its own.

Publication status requires a factual analysis

The application asks whether the work is published. Under the Copyright Act, publication generally involves distribution of copies to the public, or an offer to distribute copies for further distribution, public performance, or public display. Public performance or display alone does not constitute publication. That means “the product launched” and “the code was published” are not necessarily the same statement.

Software distributed through downloads, physical media, app stores, enterprise installations, or licensed copies can present different facts from software that users access only through a hosted service. Contracts and technical delivery methods may also affect the analysis. The applicant should preserve records showing what was distributed, to whom, under what terms, and on what date rather than guessing from a marketing launch date.

The distinction affects the information required in the application, the deposit, and whether multiple unpublished works may qualify for a group-registration option. If publication status is uncertain, it should be analyzed before submission rather than corrected after examination begins.

How much source code must be deposited?

A copyright application requires a deposit: material that allows the Office to examine the work. For a computer program without trade-secret material, Circular 61 permits an applicant to submit the entire source code or a representative portion. The standard representative deposit is one copy of the first 25 pages and last 25 pages of the specific version. If the entire program is 50 pages or fewer, the applicant submits the entire code and tells the Office that the deposit is complete.

The first page should identify the program title and version number. If the program contains a copyright notice, the deposit should include the page containing it. For JavaScript and other scripted languages, the script is treated as source code; screenshots of buttons, commands, or on-screen text are not substitutes.

The submitted pages should match the version named in the application. Pulling “roughly the latest” files from a repository creates avoidable uncertainty about what the registration actually covers. A defensible process preserves the deposited file, a hash or repository reference, and the corresponding release records.

Trade secrets do not require an all-or-nothing choice

Many businesses hesitate to register software because the source code contains confidential architecture, security logic, formulas, or other trade secrets. Copyright Office rules provide several limited-deposit options. The applicant must tell the Office in writing that the code contains trade-secret material and then use an accepted format.

Among the available options, an applicant may submit the first 10 and last 10 pages of source code without blocking anything out. Another option is the first 25 and last 25 pages with trade-secret portions blocked out, provided the blocked material is less than half of the deposit. For a program of fewer than 50 pages, the entire code may be submitted with less than half blocked. Circular 61 also describes an option combining portions of object code with at least 10 consecutive pages of unredacted source code.

The redaction limits are substantive. Blocked portions must be proportionately smaller than the visible portions, and the unblocked code must contain an appreciable amount of copyrightable expression. A deposit that hides nearly everything may be refused.

Submitting only object code is possible, but it has a cost. The Office strongly prefers source code. An object-code-only claim is registered under the Office’s Rule of Doubt after the applicant makes the required written statements. The Office does not determine the copyrightability of the object code, and the registration does not receive the same presumption for that aspect of the claim. For many owners, a compliant limited source-code deposit is therefore preferable to an object-code-only filing.

Revised programs need careful claim limitations

Software registrations frequently cover derivative versions. If new or revised material appears throughout the program, the Office generally accepts the first 25 and last 25 pages. If the new material does not appear there, the applicant may submit 50 pages that contain the revisions. Trade-secret deposit options remain available.

The application must also distinguish new authorship from material that is not part of the claim. Previously published or registered code, public-domain material, and third-party code generally should be excluded in the “Limitation of Claim” section. Open-source components are not automatically a problem, but the company should not claim authorship it does not own. It should also keep the applicable licenses and a software bill of materials so the registration record, licensing obligations, and product inventory tell a consistent story.

There is a limited exception when the claimant owns both the new and preexisting code and the preexisting code has never been published or registered. Even then, the application should describe the material accurately. Version numbers or copyright notices spanning multiple years may prompt an examiner to ask whether the deposit includes earlier versions, so an explanatory note can prevent delay.

Screen displays and documentation may require separate planning

The Office generally treats a computer program and the screen displays it generates as the same work. When the same party owns both, Circular 61 says the program and related screen displays may be registered with one application. A computer-program claim can cover copyrightable expression in the code and generated displays even if the application does not separately name the displays. If the application expressly claims screen displays, however, representative displays must be deposited.

Different ownership changes the answer. If one party owns the program and another owns the screen displays, separate applications are required. Similar considerations apply to user manuals and other documentation. A program and its documentation can sometimes be registered together when the same party owns both, but published works must have been distributed together as an integrated unit. Separately published documentation generally requires its own application.

Registration timing matters before enforcement

Copyright exists when original authorship is fixed, but registration has important enforcement consequences. For a U.S. work, 17 U.S.C. § 411(a) generally requires registration or refusal before an infringement action may be filed. Under 17 U.S.C. § 412, the timing of registration can also affect eligibility for statutory damages and attorney’s fees.

A business should not wait for suspected copying to decide which release it owns or to reconstruct a source-code deposit. Early planning is particularly important when product releases are frequent and older branches may be archived, refactored, or deleted. If copying is already suspected, preserve repository history, access logs, build artifacts, contracts, and examples of the competing product before taking action. Tucker Law’s copyright infringement practice can assess the registration record alongside the evidence and business stakes.

A practical software-registration workflow

The most useful registration process begins outside the Copyright Office’s form. First, identify the commercial release that matters and freeze a copy of its code. Next, confirm the authors, employment relationships, assignments, and third-party components. Determine publication status from the actual distribution model. Then prepare a deposit that complies with the ordinary or trade-secret rules, describe the new authorship precisely, and exclude material that should not be claimed.

After filing, retain the application, correspondence, certificate, exact deposit, repository reference, and ownership documents together. Repeat the analysis when a later release adds enough original authorship to justify another registration. Not every patch needs a filing, but a company should make that decision intentionally based on the value of the changes, release cadence, enforcement risk, and budget.

Software copyright registration is strongest when the certificate, the code deposit, and the company’s development records all point to the same work. If your business is preparing a software filing, reviewing a contractor-built codebase, or deciding how to protect confidential source code, contact Tucker Law to discuss a registration and ownership strategy tailored to the product.