Open-Source Licences and Your Own IP: How MIT, GPL and Apache Code Affects What You Own

An acquirer's lawyers open a folder, run a scanner across the codebase they are about to pay for, and find a single GPL-licensed library buried four levels deep in the dependency tree. The product was built on top of it. Nobody on the founding team remembers adding it; it came in as a transitive dependency of a package that pulled in another package. The deal does not collapse, but it pauses, the price moves, and the founders spend the next three weeks proving that this one component did not poison the very thing they are selling. This is the quiet way open-source licensing turns from a convenience into a liability.

Open-source code is the foundation of almost every modern software product, and using it is not a problem. The problem is using it without knowing what each licence asks of you in return. A licence is a contract. When you pull a library into your product, you accept its terms, and some of those terms reach into the code you wrote yourself. For a company that intends to sell a product, raise money on it, or license it to customers, the question is not whether you used open source. It is whether the licences attached to it are compatible with owning and commercializing what you built.

A permissive licence asks for credit; a copyleft licence asks for your code

The licences a product company meets most often fall into two camps, and the difference between them decides how much freedom you keep. Permissive licences, the MIT Licence and the Apache Licence 2.0 chief among them, let you take the code, change it, fold it into a closed product, and sell that product without releasing your own source. What they ask in return is light: keep the copyright notice, reproduce the licence text, and in Apache's case respect its patent and attribution terms. You can build a proprietary business on permissively licensed code and still own and close your own work. This is why most commercial software sits on an MIT and Apache foundation.

Copyleft licences operate on a different principle. The GNU General Public Licence, the GPL, is built to keep software free in the legal sense, and it does that by attaching a condition: if you distribute a work based on GPL code, you must release the source of that work under the GPL too. The licence is designed to propagate. Take a GPL component, build it into your product, ship that product to customers, and the obligation can extend to your own source. That is the mechanism people are describing when they talk about a licence being "viral." It is not a bug or an aggressive interpretation. It is the licence working exactly as written, and it is the single most expensive thing to discover late.

The distribution trigger is where most teams misread the GPL

The GPL's source-release obligation generally turns on distribution, on conveying the software to someone else. A team that runs GPL code purely on its own servers to power a hosted service is, under the ordinary GPL, not distributing the binary to users at all, and the source-release duty does not bite in the same way. This is exactly why so many companies assumed software-as-a-service let them sidestep copyleft entirely. The Affero GPL, the AGPL, was written to close that gap: it extends the obligation to software made available to users over a network, so running modified AGPL code behind a web service can trigger the same source-release duty as shipping it. The practical lesson is that "we only use it on the backend" is not a safe answer until someone has checked which copyleft licence is actually in play and how your product reaches its users.

Attribution is not optional, even when the licence is permissive

It is tempting to treat the permissive licences as having no strings, but they do, and ignoring them is its own breach. The MIT Licence requires that its copyright and permission notice travel with the code. Apache 2.0 goes further: it asks you to retain notices, state significant changes you made, and pass along its NOTICE file. A product that strips these out is not in compliance, even though the underlying licence is generous. The risk here is rarely a lawsuit. It is the audit. When an investor or acquirer runs a licence scan, missing attributions read as sloppiness at best and as an unmanaged legal exposure at worst, and either reading slows a deal and weakens your position at the table.

Licence compatibility decides whether your stack can legally coexist

The harder problem is not any single licence but the way several of them interact inside one codebase. Licences have to be compatible with each other to live in the same distributed product. Permissive licences combine cleanly with almost anything, including each other and proprietary code. Copyleft licences are choosier. You cannot take GPL code and relicense it under terms that contradict the GPL, which means certain combinations are simply not allowed to ship together. A team that mixes a strong copyleft component with a licence that forbids the GPL's downstream conditions has built something it may not be able to distribute at all without ripping one side out. Compatibility is not a detail to settle after launch. It shapes what your product is legally allowed to be.

The cost of getting this wrong scales with how late you find it. During early development, swapping out a problem dependency is an afternoon of work. After a product has shipped, with the offending library woven through the architecture and a customer base relying on it, the same swap becomes a structural rewrite. And in the worst timing of all, during due diligence on a funding round or an acquisition, an unexpected GPL dependency or a broken attribution chain hands the buyer the upper hand. They will not walk away over it in most cases. They will use it to lower the price or to demand that you fix it on a clock, on their terms, while the deal hangs.

Audit the dependency tree before money is on the table, not after

The defence is unglamorous and entirely effective: know what is in your code before anyone else looks. A dependency tree is not just the libraries your developers chose deliberately. It is every package those libraries pulled in, and every package those pulled in, down through the transitive layers where the surprises hide. An open-source compliance audit walks that whole tree, lists the licence on every component, and flags the copyleft and incompatible entries while they are still cheap to address. The output is a software bill of materials, a plain inventory of what you are shipping and under what terms, and it is the document a serious investor will ask for.

Building this habit early changes the economics. A company that tracks its licences from the first commit treats a problematic dependency as a routine swap. One that audits for the first time the week before a term sheet is negotiating from the back foot. The same discipline that protects you in a financing round also protects the rest of your intellectual property: the proprietary code you wrote, the algorithms you keep as trade secrets, and the wider body of work you may one day need to defend. A clean licence position is part of being able to say, credibly, that you own what you claim to own.

Open-source compliance sits inside a larger intellectual property picture, and it pays to treat it that way. The code you build on top of these libraries is itself protected by copyright the moment you write it, and putting a dated software copyright registration in place gives that original work an owner of record, separate from the question of which third-party licences it incorporates. The two issues are distinct: licence compliance governs the code you borrowed, while registration documents the code you authored. Both matter when you need to prove, to a buyer or in a dispute, that your product is genuinely yours to sell.

Where licensing crosses into ownership, the analysis stops being a developer task and becomes a legal one. Reading whether a particular copyleft term reaches your code, whether two licences in your stack can coexist, or whether a contractor's contribution came with a hidden open-source obligation is a question of intellectual property law, not engineering preference. The same is true when a dispute arrives: if you ever face an intellectual property infringement claim, the licences in your dependency tree are among the first things the other side will probe. And the proprietary assets you build alongside the borrowed code, the original modules and creative materials worth defending, deserve their own dated work registration record so that your authorship is documented before anyone asks you to prove it.

Using MIT, Apache or GPL code is not a risk in itself. Using it blind is. The companies that get burned are not the ones that chose open source; they are the ones that never checked what they accepted in return. If you are heading toward a funding round, an acquisition, or a customer licensing deal, the practical move is to audit your dependency tree now, while a problem is still a quick fix rather than a price cut. Sistem Patent can help you map where open-source obligations meet your own intellectual property, so that what you intend to sell is genuinely, demonstrably yours.