License Compliance

Once pulling in published software became the default, a single product started carrying hundreds of outside components. Only a few dozen of them were picked by a person; the rest arrived because something else brought them along. Add one library for handling dates and it drags in six more, each with its own terms that nobody on the team has read.

The catch is that published does not mean free of conditions. An open source license is the document spelling out what you have to do in exchange for using the software, and the common requirement is mild — keep the author's name and the license text somewhere in the product.

The conditions don't all pull with the same force, though. Copyleft licenses require that whatever you build from the code be released under the same terms. Let that kind of code into a product you sell and your own code can fall into scope. Treat every component as one undifferentiated category and eventually you pick up a strong one by mistake.

Pagedeck learned this at the end of an enterprise deal. The customer's legal team asked for a list of the open source in use with the license for each, and no such document existed. Theo spent two days assembling it by hand while the contract sat still, and the exercise turned up more than ten components missing from the product's attribution screen.

Build the list first, attach a condition to every entry and rule on it, then put a check on the way in.

1. List every outside component in the product, down to the version. Include both what someone chose and what those choices dragged in. Counting hundreds of entries by hand goes stale with the next release, so the list gets generated during the build.
2. Attach a license name and text to each entry. Widely used names like MIT or Apache 2.0 usually resolve automatically, but entries with a blank name or two overlapping licenses need a person to open the text and read it. That is where the real incidents start.
3. Sort the conditions into three buckets: attribution is enough, conditions apply, and cannot ship in the product. Rule on entries against an allowlist the company decided in advance rather than judging them one at a time, otherwise the verdict changes with whoever is looking. The allowlist is a short page naming which licenses are fine anywhere, which are fine only in internal tools, and which are out.
4. Deal with what the check caught. A missing attribution is fixed by adding a line to the notice screen. Code sorted into the cannot-ship bucket has to be swapped for something equivalent or pulled out of the product, and when it surfaces in a feature you already sell, that swap runs into weeks.
5. Prepare the documents you hand outward: the open source notice at the bottom of the settings screen, and a list file for enterprise customers. Building them after someone asks is already late, because the request usually arrives with a deadline attached to something else.
6. Put a check on the way in. When a new entry appears, its license is resolved automatically and anything outside the allowlist is blocked from merging. It hangs in the same place as static analysis, the check that reads code without running it to find problems.

Engineers produce the list and whoever holds legal sets the criteria for ruling on it. Leave the ruling to engineers and the bar moves from person to person; leave the list to legal and it gets assembled without knowledge of how the build works.

• Engineers generate the list, wire the check into the build, and replace what gets flagged.
• Whoever holds legal maintains the allowlist and rules on ambiguous licenses. In an early-stage company the founder usually covers this seat with outside counsel.
• Sales brings back the format and the deadline the customer's legal team wants.
• The product manager decides which cycle absorbs the replacement work.

There are four moments. An automatic check runs on every merge, the notice screen gets verified before a release, the list goes out during contract work with an enterprise customer, and the same list is requested again during due diligence ahead of a funding round. The aim is to have the first two run themselves so the last two are just a matter of pulling the file.

"What's this library licensed under? If it's copyleft we can't use it here."

The code ships inside the product, so a strong condition means finding something else.

"The customer's legal team wants our open source list — when can we get it to them?"

The document is a contract condition, which ties its deadline to the deal's schedule.

"These three are missing from the notice screen. Please add them in the next release."

The generated list and the published attribution have drifted apart and need to match again.

After that deal, Pagedeck reversed the order. Grace worked with outside counsel to write the allowlist onto a single page, and Theo wired a check into the build so a license outside that page can't be merged. Mia put the replacement of the two copyleft components already in the codebase into the next cycle, and Sofia started sending the list up front in enterprise deals rather than waiting to be asked.

What changed after the check went in is when things get caught. A problem used to surface in a shipped feature and turn into weeks of replacement work; now it surfaces before the merge and ends with thirty minutes of picking a different library.

The most common reading is that free software comes without conditions. Nothing was paid, so it feels like nothing is owed. What was free is the price; the conditions sit separately. Fail to keep the author's name and the license text and you are infringing copyright — not a question of unpaid fees but of using someone's work without permission.

The other frequent mistake is treating it as a one-time audit — clean once, filed, done. The component list changes weekly. New libraries come in with new features, and a maintainer occasionally changes the license between versions. Describe this quarter with last quarter's cleared list and the entry that caused the problem is the one that wasn't on it.