Open Source Licensing Risks That California Startups Ignore

A startup founder in Playa Vista called me two weeks before his Series B closed. The acquirer’s legal team had flagged 47 open source components in his codebase, three of which were licensed under GPL v3. His entire SaaS product was proprietary. The GPL code had been pulled in by a junior developer through a dependency chain that nobody had audited. The investor’s counsel wanted either full remediation or a $2 million escrow holdback. Two weeks to fix what should have been caught on day one.

This happens constantly. The Linux Foundation’s 2024 survey found that 96% of commercial codebases contain open source components, and the average application includes 500 or more open source dependencies. Most startup founders in Los Angeles treat open source like free beer. It’s not. Every open source license imposes conditions, and violating those conditions can trigger copyright infringement claims, mandatory disclosure of proprietary source code, or both.

I’m Evan Dotta, a partner at Mister Wolf P.C. I handle intellectual property disputes and licensing compliance for technology companies, many of them in LA’s Silicon Beach corridor from Venice to El Segundo. Startup founders need to understand three things: what open source licensing actually does, the real risks of getting it wrong, and what to do about it.

What Open Source Licenses Actually Require

Copyleft Licenses: GPL v2 and GPL v3

The GNU General Public License is the open source license that causes the most legal headaches. The core principle is “copyleft”: if you use GPL-licensed code in your software, any derivative work you distribute must also be licensed under the GPL. That means making your source code available to anyone who receives your software, under the same GPL terms.

GPL v2 (1991) and GPL v3 (2007) differ in several ways. GPL v3 added explicit patent license grants, anti-tivoization provisions (preventing hardware restrictions on modified software), and compatibility terms with certain other licenses. But the copyleft obligation is the same in both versions: distribute a derivative work, and the derivative work must be GPL-licensed.

The critical question is what constitutes a “derivative work.” Under copyright law (17 U.S.C. Section 101), a derivative work is a work based upon one or more preexisting works. In the software context, courts have looked at whether the new code is substantially based on, incorporates, or is linked to the GPL-licensed code in a way that creates a single combined work.

Static linking (compiling GPL code directly into your binary) almost certainly creates a derivative work. Dynamic linking is murkier, but the Free Software Foundation takes the position that dynamically linked programs are also derivative works of the GPL libraries they use.

Permissive Licenses: MIT and Apache 2.0

Not all open source licenses are copyleft. The MIT License and Apache License 2.0 are “permissive” licenses that allow you to use, modify, and distribute the code in proprietary products. But permissive doesn’t mean unconditional.

The MIT License requires you to include the original copyright notice and license text in all copies or substantial portions of the software. Skip that attribution, and you’ve violated the license terms. Jacobsen v. Katzer (2008), decided by the Federal Circuit, established that open source license conditions (including attribution requirements) are enforceable as conditions on the copyright license, not merely contractual covenants. Violate a condition and the license evaporates. You’re using copyrighted code without permission. That’s infringement.

Apache 2.0 goes further. Beyond attribution, it requires you to include a NOTICE file, disclose any changes you’ve made to the original code, and grant an express patent license to recipients. If you distribute Apache-licensed code without meeting these conditions, you’ve lost the license grant.

LGPL: The Middle Ground

The GNU Lesser General Public License sits between full copyleft and permissive. LGPL allows you to dynamically link proprietary code with LGPL-licensed libraries without triggering the full copyleft obligation. Your proprietary code stays proprietary, as long as the LGPL library itself remains LGPL-licensed and users can replace the LGPL library with a modified version.

Static linking with an LGPL library is different. If you statically link, you must either release your source code or provide the object files necessary for users to relink with a modified version of the LGPL library. Many startups miss this distinction. Many build systems default to static linking without a conscious developer choice.

Run a software composition analysis (SCA) scan on your codebase this week. Tools like FOSSA, Snyk, Black Duck, and WhiteSource identify every open source component in your project and flag license conflicts. If you’ve never done this, expect surprises.

What Happens When Open Source Licenses Conflict?

License Compatibility

The real problems start when you combine open source components with different licenses. GPL v2 code cannot be combined with code under the Apache 2.0 license (according to the Free Software Foundation’s compatibility analysis, though this specific conflict was resolved in GPL v3). Mixing MIT-licensed code with GPL-licensed code means the combined work must be distributed under the GPL. Mixing code from two different copyleft licenses (like GPL v2 and the Eclipse Public License) may create an impossible situation where you can’t satisfy both licenses simultaneously.

These compatibility issues cascade through dependency chains. You pull in a library under MIT. That library depends on a package under LGPL. That package depends on a utility under GPL v3. Your proprietary application now has GPL v3 code in its dependency tree. You might not even know it.

The Software Package Data Exchange (SPDX) standard helps identify and track license information across software supply chains. SPDX is maintained by the Linux Foundation and has been adopted by the National Telecommunications and Information Administration (NTIA) as the recommended format for Software Bills of Materials (SBOMs). Executive Order 14028, signed in 2021, requires software vendors selling to the federal government to provide SBOMs. Even if you’re not a government contractor, maintaining an SBOM is becoming standard due diligence practice.

Security diligence is moving the same direction. NIST reported in April 2026 that CVE submissions increased 263% between 2020 and 2025, and that NVD enriched nearly 42,000 CVEs in 2025. Buyers know the vulnerability volume is too high to review manually. They want an SBOM, an SCA report, and a record showing how your team decides which open source components are allowed into production.

M&A Due Diligence

Acquirers check open source compliance. Every competent buyer in a technology M&A transaction will run an SCA scan during due diligence. I’ve worked on deals where the acquirer’s team found GPL code in a target company’s proprietary SaaS product and demanded remediation before closing. In some cases, the discovery reduced the purchase price. In others, it killed the deal entirely.

A 2024 Synopsys audit report found that 84% of commercial codebases contained at least one open source component with a known license conflict. The problem is the norm, not an anomaly. Startups that defer compliance until acquisition talks begin are betting the issue won’t affect valuation. That bet usually loses.

What Acquirers Actually Look for in Open Source Diligence

The buyer’s legal and technical teams will request a complete SBOM and independently verify it by running their own SCA scan. They’ll compare the two results. Discrepancies raise red flags immediately because they suggest the target company doesn’t know what’s in its own codebase.

Acquirers examine five specific risk categories. First, they catalog every copyleft-licensed component and determine whether any trigger obligations to release proprietary source code. Second, they check whether all permissive license attribution requirements have been met. Missing MIT or Apache NOTICE files is a common finding. Third, they examine whether any components carry license restrictions that conflict with the buyer’s intended use of the product (for example, a “non-commercial use only” restriction in a commercial product). Fourth, they look for components with known security vulnerabilities, because unpatched dependencies create liability. Fifth, they review the target company’s open source governance: is there a policy? Has it been followed? Are there records?

A client I worked with in Culver City had built a SaaS product with over 1,200 open source dependencies. The acquirer’s scan flagged 23 components with copyleft licenses and 11 with attribution violations. The remediation plan took eight weeks to execute. Replacing the copyleft components required rewriting several core modules. The acquirer held back $1.5 million in escrow until remediation was complete and independently verified. That holdback reduced the founders’ immediate payout and tied up capital for months. Had the company run its own audit six months earlier, early remediation would have cost under $40,000.

If you’re planning a fundraise or exit in the next 12 months, get an open source audit done now. Fix conflicts before they show up in a buyer’s report. The cost of an audit and remediation is a fraction of what you lose in deal value if issues surface during due diligence.

How Have Courts Enforced Open Source Licenses?

Artifex v. Hancom

Artifex Software v. Hancom (2017), decided in the U.S. District Court for the Northern District of California, is the most significant GPL enforcement case. Artifex makes Ghostscript, a PDF rendering tool licensed under GPL or a commercial license. Hancom, a South Korean office software company, used Ghostscript in its products without complying with the GPL and without purchasing a commercial license.

Artifex sued for copyright infringement and breach of contract. The court denied Hancom’s motion to dismiss, holding that the GPL is an enforceable contract and that using GPL-licensed code without complying with its terms constitutes copyright infringement. The case settled, but the court’s reasoning established that GPL violations are actionable in federal court.

Jacobsen v. Katzer

Jacobsen v. Katzer (2008) established that open source license conditions are not just contractual promises. They are conditions on the copyright license itself. The Federal Circuit held that violating an open source license’s attribution and distribution requirements removes the user from the scope of the license, making their use of the code unauthorized copying under copyright law.

This distinction matters because copyright infringement carries stronger remedies than breach of contract. Copyright plaintiffs can seek statutory damages up to $150,000 per work for willful infringement (17 U.S.C. Section 504(c)), injunctive relief, and attorney’s fees. Contract plaintiffs are generally limited to actual damages.

In federal court, the claim usually traces back to the copyright owner’s exclusive rights under 17 U.S.C. Section 106 and the infringement remedy under 17 U.S.C. Section 501. That statutory footing is why a license-header cleanup issue can turn into a real IP lawsuit.

Enforcement in Los Angeles

The Central District of California, which covers Los Angeles and much of Southern California, sees a high volume of software IP disputes. Silicon Beach startups, entertainment technology companies, and digital media businesses headquartered in Santa Monica, Venice, Culver City, and Marina del Rey are all within this jurisdiction. Many open source compliance disputes filed here settle before trial, but the existence of clear case law from Artifex and Jacobsen gives plaintiffs real settlement pressure at the demand letter stage.

What Are the Most Common Open Source Mistakes Startups Make?

Using GPL Code in Proprietary SaaS

This is the number one mistake. A developer finds a GPL-licensed library that solves a problem perfectly. They include it in the codebase. Nobody reviews the license. The startup ships a proprietary SaaS product containing GPL code. Under the GPL, any user who receives the software can demand the source code. In a SaaS context, whether server-side use counts as “distribution” depends on which version of the GPL applies (the Affero GPL, or AGPL, explicitly covers network use; standard GPL may not).

The safest approach: treat any GPL code in your proprietary product as a compliance risk needing immediate review.

Ignoring Attribution Requirements

Even permissive licenses require attribution. I’ve seen startups strip MIT and Apache license headers from files during code cleanup, not realizing that attribution is a license condition. Remove it, and you’ve violated the license. The code becomes unauthorized.

This applies to frontend libraries, CSS frameworks, icon sets, and JavaScript utilities, not just backend code. If your marketing site uses an open source component, the license still applies.

Not Tracking Dependencies

Modern software development relies on package managers (npm, pip, Maven, Cargo) that pull in transitive dependencies automatically. A single npm install can add hundreds of packages to your project, each with its own license. If you’re not actively tracking what gets installed and what licenses it carries, you have no idea what’s in your codebase.

The 2024 Linux Foundation survey found that the average enterprise application includes over 500 open source dependencies. The dependency tree for a typical JavaScript application runs into the thousands. Without automated scanning, manual compliance is impossible.

Relying on AI Code Generators Without Review

AI code generation tools like GitHub Copilot produce code that may be substantially similar to open source code in their training data. For a broader look at the IP implications of AI-generated output, read our post on AI-generated content and intellectual property ownership. If Copilot generates a function that’s nearly identical to a GPL-licensed function in a public repository, using that code in your proprietary product carries the same risk as copying the GPL function directly. The AI tool doesn’t label the license. It doesn’t warn you about copyleft obligations. It just writes code.

Add an SCA scanning step to your CI/CD pipeline. Every pull request should be automatically checked for new dependencies and license conflicts before it’s merged. Most SCA tools integrate with GitHub, GitLab, and Bitbucket in under an hour.

How Should Startups Build an Open Source Compliance Program?

The Minimum Viable Program

You don’t need a team of compliance lawyers. You need a few basic systems.

1. Maintain a Software Bill of Materials. Track every open source component, its version, its license, and where it’s used in your codebase. Update this list with every release.
2. Run SCA scans regularly. Automate scans in your build pipeline. Flag any new components with copyleft licenses for manual review before they enter the codebase.
3. Create a license allow list. Decide which open source licenses your company will accept (most startups approve MIT, Apache 2.0, BSD 2-Clause, and BSD 3-Clause without restriction) and which require legal review (GPL, LGPL, AGPL, MPL).
4. Train your developers. Most license violations happen because developers don’t know the rules. A 30-minute training session covering copyleft versus permissive licensing prevents most problems.
5. Document everything. Keep records of your license reviews, compliance decisions, and remediation efforts. This documentation matters during due diligence and in any enforcement action.

At Mister Wolf P.C., we help startups build open source compliance programs and conduct pre-funding audits to identify and fix license issues before they affect valuations. The work is straightforward when done early. It becomes expensive and disruptive under closing deadline pressure.

Los Angeles has one of the fastest-growing startup ecosystems in the country, with hundreds of technology companies operating along the Silicon Beach corridor and in downtown’s Arts District. Many are building on open source foundations without understanding the legal obligations that come with the code. The risk is real, the case law is clear, and the fix is usually simple.

If your startup uses open source software (and it does), run an SCA scan, review the results against your license allow-list, and remediate any conflicts. Start with the components in your core product, then work outward through your dependency tree. That one step will put you ahead of 84% of the market.