What open source is in your product – and does it matter?

Almost no custom-built code is written from scratch. It’s built on top of thousands of ready-made open source components, and that’s both smart and necessary – reinventing everything yourself would be wasteful. But every component comes with a license, and those terms travel into your product. Most of the time, it’s unproblematic. Sometimes a single wrongly chosen component can create an issue that only surfaces when an investor reviews the code. This guide sorts out what applies and how to keep track.

Permissive versus copyleft – in plain terms

There are many open source licenses, but in practice they fall into two camps worth understanding. The difference is about what the license requires back from you.

Permissive licenses – the most common are MIT, Apache, and BSD – let you basically do whatever you want with the code, including building it into a closed, commercial product you sell. The requirement is essentially just that you keep the copyright notice. They rarely create any headaches and form the backbone of most products.

Copyleft licenses impose a counter-requirement: if you use the code, modifications, and in strong variants entire works built on it, must be made available under the same open terms. The best known is GPL. The idea is that what’s built open should stay open. It’s a fully legitimate model – but it fits poorly if your business idea depends on keeping your own code closed. A common misconception is that “open source means free and unrestricted.” Free to use, often, but not always free of conditions.

Require a license inventory from your vendor

The problem with licenses is that they’re invisible in the finished system. The code works the same regardless of what terms the components carry, so an unsuitable license doesn’t show up in operation – only in a review. The solution is to make the invisible visible.

So require a license inventory from your vendor: a list of every open source component included and which licenses they carry. A modern project can contain hundreds of dependencies, often dependencies of dependencies, so the list is generated with tools rather than by hand. What matters is that it exists, that it’s kept updated as new components are added, and that someone actually looks at it. Then it’s immediately visible if a strong copyleft license sits somewhere it shouldn’t, while it’s still easy to swap the component out. A serious vendor has this under control and doesn’t find the question strange – on the contrary, reluctance to produce an inventory is itself a warning sign.

The license question in contracts and during review

License handling shouldn’t rest on goodwill – it should be written into the contract. A couple of clauses make a big difference. Have the contract state that the vendor is responsible for ensuring delivered code doesn’t contain components whose license conflicts with how you intend to use the product, and that an up-to-date license inventory must be included in the delivery. That way it becomes the vendor’s job to keep things clean, not your surprise afterward.

The issue carries extra weight during an investment or acquisition. There, the code’s licenses are routinely reviewed as part of due diligence, and a strong copyleft component at the core of the product can become a real business risk – something that lowers the valuation or pauses the deal until it’s resolved. A clean, documented license situation is therefore not just technical hygiene, but an asset that makes the company easier to invest in. Putting in a small effort toward order early is cheap; untangling a license mess in the middle of an ongoing deal is expensive and stressful.

A concrete scenario

A company had spent a couple of years having its product built without anyone keeping track of the licenses. Ahead of an investment round, the investor’s advisor did a license review and found a component under strong copyleft buried deep inside a central function. The immediate question became whether the core of the product risked having to be opened up.

The investigation took time and created uncertainty during a sensitive phase. In the end, it turned out the component could be swapped for a permissive alternative without much work, and the deal could proceed. But the lesson was clear: had a license inventory existed and been kept updated from the start, the component would never have been built in – or at least would have been swapped out long before it became an issue at the negotiating table.

Keep things in order from the start

Open source is an asset, not a risk – as long as you know what you’re using. The vast majority of components are unproblematic, and the point isn’t to become afraid of open code, but to keep track of it. A license inventory, a couple of lines in the contract, and someone who actually reads the list go a long way toward avoiding the surprises that otherwise show up at the worst possible moment.

At Weapp we keep the licenses in order in what we build, and we’re glad to help buyers review what’s inside an existing product, as part of our services. Not sure what your code rests on? Get in touch and we’ll look at the license situation together before it becomes someone else’s question.