Can You Use Open-Source Code in a Commercial Product? MIT, Apache, GPL and the Licence Traps

Most software products are a thin layer of original work sitting on top of a very large amount of other people’s code, pulled in free from public repositories. Every one of those components arrived with a contract attached, and almost nobody reads them. The good news is that the great majority of those contracts ask for very little. The complication is that a small number of them can require you to publish parts of your own source code, and they tend to be discovered by somebody else’s lawyer rather than your own.

Let us settle the basic question first, because founders worry about it unnecessarily. Yes, you can use open source in a commercial product. Freedom to use software commercially is part of the definition of open source, not an exception to it. The real question is never whether you may use it, but on what conditions, and what those conditions mean for the way you actually ship your product.

Open source is not public domain. Every component is protected by copyright, and the author gives you permission to use, copy, change and distribute it through a licence. That permission is conditional. Satisfy the conditions and you are properly licensed. Fail them and your permission falls away, which means you are copying protected code with no permission at all. That is copyright infringement, and it is enforceable with injunctions and damages rather than a polite request to pay an invoice.

This is not a theoretical risk. Courts in Germany have been granting injunctions over open source licence breaches since 2004, in a line of cases that has continued ever since. In the United States, the Federal Circuit confirmed in Jacobsen v Katzer that open source licence terms operate as genuine conditions of the copyright grant, not merely as side promises, which is what makes infringement the right frame. More recently, in Software Freedom Conservancy v Vizio, a Californian court has declined to dismiss the argument that a customer who buys a device can enforce the source code obligation as a beneficiary of the licence. That question has not yet been decided and the case is heading to trial, but the fact that it has survived this long is itself the point. The pool of people who might enforce these terms against you may be larger than the original authors.

So the mindset that matters is simple. Free means free of charge. It never means free of obligations. Those obligations come in two temperaments, and everything else follows from which of them is sitting in your codebase.

The permissive licences, meaning MIT, the BSD family and Apache 2.0, ask for very little, and they account for most of what founders are anxious about.

MIT is the most common licence on the internet and it asks for essentially one thing. Keep the copyright notice and the licence text with the code. Beyond that you may build on it, keep your own work closed, and sell the result. Apache 2.0 is the preferred choice in corporate settings because it includes an express patent licence from every contributor, which removes a risk MIT simply says nothing about. In return it asks slightly more. You carry the licence and any NOTICE file through to your users, and you indicate where you have made significant changes to the files.

Here is the part that surprises people. Precisely because these duties feel so minor, they are the ones most often broken in real products. Shipping an application built on MIT components with no attribution anywhere is a licence breach, with all the consequences described above, even though nothing about your business feels wrong. This is why every serious application has an open source licences screen somewhere in its settings. That screen exists because somebody read MIT properly.

The remedy is cheap and permanent. Generate the notices automatically as part of your build process rather than maintaining them by hand. Do that once and this entire family of licences stops being a problem you ever think about again.

The copyleft licences take a different position. The GPL family says that if you build on this code and distribute the result, the result must travel with the same freedoms, including source code for the people who receive it. People call this viral. It is more useful to think of it as a price, paid in source code rather than in money.

Three points decide how this affects you in practice.

The first is what actually triggers the obligation. Under the ordinary GPL, the trigger is distribution, or in the newer wording, conveying the software to somebody else. Code that runs on your own servers and never leaves them is being used rather than distributed, which is why a GPL component quietly running in the back end of a hosted product usually does not oblige you to publish anything.

The second is that this gap is exactly why the AGPL exists. If you modify an AGPL component and users interact with your modified version remotely over a network, you must offer those users the corresponding source. Two details make this broader in practice than it first sounds. Integration work often counts as modification, and the boundary is not comfortable to argue about after the fact. For that reason careful companies treat any AGPL component in a hosted product as something requiring a deliberate decision rather than a default yes, and some large technology companies prohibit it internally altogether.

The third is that the edge of what counts as a derivative work, meaning questions about linking, separation and architecture, remains one of the genuinely unsettled arguments in software law. Nobody can give you a clean universal answer. What you can do is make the question easier by keeping copyleft components cleanly separated behind clear interfaces, and by writing down why the separation is real.

Two gentler relatives are worth knowing. The LGPL lets you link to a library and keep your own application under your own terms, provided changes to the library itself flow back. The MPL keeps its copyleft at the level of individual files rather than the whole work. And two exits exist when a component is otherwise perfect. Many copyleft projects sell a commercial licence alongside the open one, which is a standard business model rather than a favour. Separately, several well known projects have moved to source available licences that are not open source at all, so check what you are actually agreeing to rather than assuming from reputation.

In any serious funding round or acquisition, the other side scans your codebase and has a full component list within hours, including the transitive dependencies nobody chose deliberately. If an AGPL component in your hosted product appears in their report before it appears in yours, the cost is commercial. A lower price, money held back in escrow, remediation conditions, or a buyer who quietly cools off.

So run it first. Build a component inventory, commonly called a software bill of materials, straight out of your build tooling and keep it current. Set a licence policy that matches your architecture, separating what is acceptable in a back end you never distribute from what is acceptable in anything that reaches a customer’s device. Automate the notices. Require contractors to declare what they bring in, and treat AI coding assistants the same way, since they can reproduce licensed code without its terms.

One accurate note on regulation. The EU Cyber Resilience Act does require a machine readable software bill of materials under Annex I, with reporting duties applying from 11 September 2026 and the regulation applying in full from 11 December 2027. It covers products with digital elements placed on the EU market rather than software generally, and pure cloud SaaS usually falls outside it. If you ship software or connected devices into the EU, this is law. If you run a hosted service, it is good practice that buyers increasingly expect anyway.

Whatever the audit finds, there are only four fixes. Isolate the component, replace it, rewrite the functionality, or buy a commercial licence. All four cost less before the term sheet than after.

In summary, open source is commercial friendly by design, but it is licensed rather than given away, and failing the conditions turns a routine dependency into a copyright problem. The permissive family asks mainly for notices and attribution, which you should automate and then forget. The copyleft family asks for share alike, with the ordinary GPL triggered by distribution and the AGPL triggered by network interaction with a modified version, which is aimed squarely at hosted products. The boundaries of what counts as a derivative work remain unsettled, which makes clean separation and written reasoning valuable. And the licence audit belongs in every funding round, ideally run by you rather than discovered by somebody else.

Have specific questions?

Not ready for a call

No worries! In the meantime, subscribe to our Knowledge center to stay updated on the latest legal developments.

And don't worry, it's free!

Share the Post:

Related Posts

Related Posts
Loading related posts…
Scroll to Top