# Open Source & Software IP

> Intellectual property for software companies — how code is protected, open-source licenses, AI-generated code ownership, and protecting source code.

Guide  |  Author: Lidiia Levitska  |  Source: Intellectual Property Law (outsideipcounsel.com)
Canonical: https://outsideipcounsel.com/guides/open-source-and-software-ip/


<div class="quick-answer"><p><strong>Quick answer:</strong> Software isn't protected by one law — it's protected by four overlapping layers. <strong>Copyright</strong> automatically covers your source and object code the moment it's written. <strong>Patents</strong> can cover novel functionality (a method or system), but only if you file and clear the eligibility test. <strong>Trade secret</strong> protects source code and algorithms you keep confidential. And <strong>trademark</strong> protects the product's name and logo. Layered on top are open-source licenses that dictate what you can and must do with third-party code, and open questions about who owns AI-generated code. Understanding which layer does what is the foundation of any software IP strategy.</p></div>

Software is the rare asset where a single product can implicate every branch of intellectual property law at once. A founder shipping a SaaS app is simultaneously an author (copyright), possibly an inventor (patent), a keeper of secrets (trade secret), a brand owner (trademark), and a licensee of dozens of open-source dependencies. Getting the layers straight — and knowing where the open-source and AI landmines are — is what separates a clean cap-table diligence from a deal-killing one.

## How is software protected by intellectual property law?

There is no single "software IP" statute. Instead, four distinct regimes each protect a different aspect of the same product:

- **Copyright** protects the *expression* — your actual source code and object code — as a literary work under **[17 U.S.C. § 102](https://www.law.cornell.edu/uscode/text/17/102)**. It attaches automatically and lasts for the life of the author plus 70 years (or 95 years from publication for works made for hire).
- **Patents** protect the *functionality* — a novel, non-obvious method, process, or system implemented in software. Protection requires filing with the USPTO and lasts 20 years from filing.
- **Trade secret** protects confidential code, algorithms, architecture, and know-how *as long as you keep them secret*, under the federal Defend Trade Secrets Act and state law.
- **Trademark** protects the *name and logo* — the brand customers associate with your product.

The critical insight is that these layers are not mutually exclusive. Your closed-source backend can be simultaneously copyrighted, held as a trade secret, and covered by a patent, while your product name is trademarked. The boundaries between them — especially copyright versus patent — are the subject of [software patent vs. copyright](/guides/software-patent-vs-copyright/), and you can see how courts sort these disputes in the [copyright case archive](/topics/copyright/).

## Is your code protected by copyright automatically?

Yes. This surprises many founders: **you do not have to register anything for copyright to exist.** The moment original code is "fixed in a tangible medium" — saved to disk, committed to a repo — it's protected. Copyright covers both human-readable source code and compiled object code, plus non-literal elements like the structure, sequence, and organization of a program (though functional aspects and ideas are excluded under the **idea/expression dichotomy** of § 102(b)).

Registration with the **U.S. Copyright Office is optional but strategically important**:

- It's a **prerequisite to filing an infringement suit** for U.S. works.
- Registering **before infringement** (or within three months of publication) unlocks **statutory damages of up to $150,000 per work for willful infringement, plus attorney's fees** — otherwise you're limited to hard-to-prove actual damages.
- The registration fee is modest — **$45 for a single-author online filing, $65 for standard**.

One nuance for software: the Copyright Office lets you register code while **redacting trade-secret portions** (for example, depositing the first and last 25 pages with confidential material blocked out), so registration doesn't force you to publish your secret sauce.

What copyright *won't* do is stop a competitor who independently writes their own code to achieve the same function. That's where patents and trade secrets come in.

## When should software be patented instead of kept as a trade secret?

Copyright stops copying; it doesn't stop reimplementation. If the value is in *what the software does* rather than the specific lines that do it, you're choosing between a **patent** and a **trade secret** — and it's often a one-way door.

- **Patent** the functionality when a competitor could reverse-engineer or independently build the same feature from your shipped product, and you want an enforceable 20-year monopoly you can license or assert. The catch: patents require public disclosure, and software patents must survive the **_Alice Corp. v. CLS Bank_ (2014)** two-step eligibility test, which invalidates claims directed to "abstract ideas" without an "inventive concept." Whether you *can* patent an app at all is covered in [can you patent an app?](/guides/can-you-patent-an-app/).
- **Keep it a trade secret** when the code runs server-side behind your walls (most SaaS backends), can't be easily reverse-engineered from the product, and would lose value if disclosed. Trade secret protection is free, automatic, and potentially perpetual — but only if you actually guard it.

For SaaS especially, trade secret is frequently the better fit because customers never receive the code — they interact with it over the network. The mechanics of locking that down are the subject of [how to protect source code](/guides/how-to-protect-source-code/).

## What do open-source licenses actually require?

Nearly every modern codebase depends on open-source software, and **"open source" is not "no strings attached."** Every OSS license is a copyright license with conditions. They fall into two broad families:

- **Permissive licenses** — **MIT, BSD, Apache 2.0** — let you use, modify, and redistribute the code in *closed-source, commercial* products. The main obligation is to **preserve the copyright and license notices**; Apache 2.0 adds an express patent grant and a notice-file requirement.
- **Copyleft licenses** — **GPL, LGPL, AGPL, MPL** — require that derivative works (and, for AGPL, even network-deployed services) be released under the *same* license, including your source code. This is the "viral" or **reciprocal** effect that can force a proprietary product open if you're not careful.

The obligations turn on two questions: *are you distributing the software*, and *have you created a derivative work?* Internal-only use of GPL code generally triggers no source-disclosure duty (except under AGPL). Statically linking a GPL library into your product usually does.

The real trap is **combining incompatible licenses** in one project — for example, mixing GPLv2-only code with Apache 2.0 code. We break down which licenses can and can't coexist in [open-source license compatibility](/guides/open-source-license-compatibility/).

## Can you build a company on open-source software?

Absolutely — most do — but the license discipline has to be deliberate. The risks fall into a few buckets:

- **Copyleft contamination.** Pulling an AGPL dependency into your SaaS backend can, in theory, obligate you to release your entire service's source code.
- **License-compliance failures.** Even permissive licenses require preserving notices; stripping them is infringement and a common diligence red flag.
- **Dependency sprawl.** A typical app pulls in hundreds of transitive dependencies, each with its own license — you can't manage what you haven't inventoried.

The professional fix is a **software bill of materials (SBOM)** and automated license-scanning in your CI pipeline, plus a written OSS policy governing what licenses engineers may introduce. This matters enormously in fundraising and M&A, where acquirers run code scans — a topic we cover in [IP in fundraising due diligence](/guides/ip-in-fundraising-due-diligence/). For a full playbook on doing it right, see [building a company on open source](/guides/building-a-company-on-open-source/).

## Who owns AI-generated code?

This is the newest and least settled layer. The U.S. Copyright Office's position, refined through its 2023 registration guidance and its 2025 report on copyrightability, is that **copyright protects only human authorship**. Applied to code:

- **Purely AI-generated code** — where a human just prompts and accepts the output verbatim — likely has **no copyright owner at all**, echoing the reasoning behind *Thaler v. Perlmutter* (D.D.C. 2023, affirmed 2025), which denied registration to a work with no human author.
- **AI-assisted code** — where a developer selects, arranges, edits, and integrates AI suggestions with meaningful human creative control — is protectable in the human-authored portions.

Beyond copyrightability, there's the **contractual layer**: tools like GitHub Copilot, Cursor, and ChatGPT each set ownership and license terms in their ToS, and some raise concerns about suggestions that mirror copyleft training data. Ship AI-assisted code without reading those terms and you may inherit obligations you never agreed to. The deeper analysis lives in [who owns AI-generated code](/guides/who-owns-ai-generated-code/), and the broader question of AI output ownership across media is in [who owns AI output](/guides/who-owns-ai-output/).

## How do you make sure your company actually owns its code?

The most common and dangerous IP gap in software startups isn't a licensing question — it's an **ownership** question. Code doesn't automatically belong to the company just because the company paid for it.

- **Employees:** Code written by W-2 employees within the scope of employment is generally a "work made for hire" owned by the employer — but you still want an **invention-assignment agreement** to remove all doubt and cover edge cases.
- **Contractors and freelancers:** Here's the trap. Absent a written assignment, an **independent contractor owns the copyright in what they create**, even after you pay them — commissioned software is not automatically a work made for hire. You *must* have a signed IP assignment.
- **Open-source contributors:** If you accept outside contributions to your codebase, you need a **Contributor License Agreement (CLA)** or a Developer Certificate of Origin so you have clear rights to the contributed code. See [contributor license agreements](/guides/contributor-license-agreements/).

For founders, buttoning up who owns what is foundational — get the framework in [startup IP checklist](/guides/startup-ip-checklist/) and the ownership deep-dive in [who owns startup IP](/guides/who-owns-startup-ip/).

## What about the product name and brand?

The fourth layer is easy to overlook because it protects the wrapper rather than the code, but it's often what customers actually value. **Trademark** protects your product's name, logo, and sometimes its distinctive look — the brand identifiers that let users distinguish your software from a competitor's. Copyright and trademark solve different problems: a competitor can independently write functionally identical code (copyright won't stop them), but they can't sell it under a confusingly similar name.

A few practical points for software companies:

- **The name is often the most defensible asset.** Code can be rewritten and features cloned, but a strong, registered mark and the goodwill behind it are durable.
- **Clear the name before you launch,** including checking app-store listings, package registries (npm, PyPI), and domains — not just the federal register — to avoid collisions.
- **Watch open-source project names too.** If you build a business around an OSS project, decide early who owns the project's name and trademark, because that's frequently separate from the code license.

For the full registration walk-through and the distinctions between the systems, see [trademark vs. copyright vs. patent](/guides/trademark-vs-copyright-vs-patent/).

## The bottom line

Software IP isn't one right — it's a stack. Copyright gives you automatic, cheap protection against copying and should usually be registered for anything valuable. Patents are the expensive, powerful option for genuinely novel functionality that would otherwise be reverse-engineered. Trade secret is the quiet workhorse protecting server-side code you never ship. Trademark protects the brand. Layered over all of it, open-source licenses impose real obligations you must track, and AI-generated code introduces ownership gaps the law is still sorting out. The companies that win diligence are the ones that inventoried their dependencies, papered their contractor and contributor assignments, and made deliberate choices about each layer — before an acquirer's code scanner did it for them.

*This guide is general education, not legal advice, and does not create an attorney-client relationship. Open-source compliance and code-ownership questions turn on your specific licenses, contracts, and how your software is distributed — consult an attorney licensed in your jurisdiction before acting.*


## Frequently asked questions

### Is software protected by copyright or patent?

Both, but they protect different things. Copyright automatically protects the expression of your code — the actual source and object code — the moment it's written, under 17 U.S.C. § 102. A patent can protect the functional invention behind the software (a novel method or system), but only if you file with the USPTO and it clears the Alice eligibility test. Most software companies rely on copyright plus trade secret for the code and reserve patents for genuinely novel functionality.

### Can you copyright software source code?

Yes, and protection is automatic. Original source code is a 'literary work' under U.S. copyright law and is protected the instant it's fixed in a tangible medium — no registration required. Registration with the U.S. Copyright Office is optional but valuable: it's a prerequisite to suing for infringement and unlocks statutory damages and attorney's fees if you register before the infringement or within three months of publication.

### Who owns code written by AI tools like Copilot?

Under current U.S. Copyright Office guidance (2023–2025), purely AI-generated code with no human authorship isn't eligible for copyright — no one owns it. Code you write with an AI assistant is protectable to the extent a human selected, arranged, or meaningfully edited it. Ownership between you and the tool vendor is set by the tool's terms of service, so read them before shipping AI-assisted code in a product.

### Does using open-source code mean my software becomes open source?

Only if you use code under a strong copyleft license like the GPL and distribute your product. Permissive licenses (MIT, Apache 2.0, BSD) let you use the code in closed-source software as long as you keep the notices. Copyleft licenses can require you to release your own source code under the same terms — the 'viral' effect. License compatibility, not the mere act of using open source, is what determines your obligations.
