← All insights Technology

Open source in your product: the conditions attached to code you did not write

Nothing modern is built from nothing. Every product of any size carries components written by other people, taken on terms somebody accepted quickly and nobody has looked at since. Treating that as a matter for engineering is the common instinct, and it leaves a set of commercial conditions outside the view of the people who are answerable for them.

A licence for an open source component is a permission granted on conditions. The permission is generous and the conditions are real. Nothing ever arrives to remind anybody they exist: no renewal, no invoice, no account manager, no annual review. The conditions sit behind the code, enforceable by whoever holds the copyright in it, and they remain exactly as they were on the day the component was pulled in.

They attach, in the main, to what leaves the business rather than to what happens inside it. Running a component on your own systems engages very little. Putting it into something a customer receives, and under some terms into something a customer reaches across a network, is where obligations begin. An assessment made when a component was chosen therefore says little about the position once the product ships in a shape nobody had in mind at the time.

Two things follow from that. The obligations belong to the product as delivered rather than to a decision recorded in a planning meeting. And the person who eventually raises them is rarely the person a business expects.

The obligations nobody disputes, and nobody meets

Start with the dull ones, because they apply almost everywhere. Even the most permissive terms in common use generally require that the licence text and the copyright notice travel onwards with the software. There is no argument to be had about whether that is required. It is simply not done, because notices live in files a build process discards, and because the task belongs to nobody in particular.

Where a product ships as a website, meeting the requirement is a small piece of work. Where it ships as a compiled application, a mobile app or a physical device, somebody has to decide where a notice actually lives, and that is a product decision about screens, packaging or documentation rather than a legal one. It tends to get designed at the point it is asked for, which is late.

The related difficulty is that the engineering answer to the question is honest and incomplete. A team saying it uses only permissive components is describing what it chose. Components arrive carrying components of their own, taken in automatically, several removes from anything a person selected. What matters is a record of what the build actually produces, and that is a different document from the one the team has in its head.

Reciprocal terms, and where your own code ends

A different family of terms grants permission on condition that, when you pass the software on, those receiving it get the same freedoms you did, including access to source. Applied to the component by itself, that is unremarkable and was the point of the exercise. The commercial question is how far the condition reaches into the code your own people wrote around it.

That turns on how the pieces have been combined and on how far the particular terms extend, and it is a genuinely contestable question rather than something to be looked up. Saying that you only call the component and never altered it describes an intention. Whether what you ship is one work or two is a legal characterisation, and capable people take different views of it. Under United Kingdom copyright law the analysis starts from what has in fact been copied or adapted, not from how the arrangement is described in an internal document.

The assumption that fails most often is that a hosted product sits outside all of this. Some terms are drafted precisely so that making software available to users over a network engages the same conditions that handing over a copy would. A business that began by shipping software and now provides it as a service, without revisiting what is inside it, has changed the facts its original assessment rested on.

Permission that can end

These licences are permissions, and a conditional permission is capable of failing. It is common for such terms to end automatically where the conditions are not observed, with restoration depending on what the particular terms provide. A business that has been shipping without meeting a notice requirement may discover that permission it assumed it held had lapsed some time ago, and that putting matters right is not simply a question of adding a file to the next release.

Some licences also grant rights under any patents the contributor holds, and withdraw that grant if the recipient brings patent proceedings against other users of the same software. For a company holding a patent portfolio and contemplating any use of it, that creates a connection between two parts of the business which ordinarily never speak to one another. A choice made by an engineer years earlier can condition what the commercial strategy is free to do now.

When the upstream terms change

Upstream does not stand still. Projects change hands, change terms, and are abandoned. Projects have moved to terms drafted to restrain hosted competitors, which alters what a downstream business is free to do with later versions of something it has depended on for years.

What was taken under one set of terms generally continues under those terms, so the immediate position usually holds. The difficulty is forward looking. The upgrade path may carry conditions the current version does not, and a component that cannot be upgraded for commercial reasons stops receiving security work. The legal position and the security position then pull against each other, and that decision belongs to the business rather than to the team maintaining the code.

What you have promised your customers

This is usually where the exposure becomes real, and it does not arrive from the author of a component.

A business cannot pass on more than it was given. Standard commercial terms frequently promise a customer that the product infringes nobody's rights, and offer an indemnity if it turns out otherwise. That promise covers the whole deliverable, including parts licensed in on terms that provide no warranty and no indemnity at all and say so in plain words. The gap between what has been promised and what was received sits with the company, and it is governed by a contract under the law of England and Wales with a customer who has both a claim and a relationship to protect.

The moments the question actually gets asked are predictable.

• Enterprise procurement. Questionnaires asking what the product contains, and on what terms, are a familiar feature of selling to larger organisations and to anyone regulated.
• The customer's own legal review. A customer whose product incorporates yours inherits your position, and their advisers understand that perfectly well.
• A funding round or a sale. Technical diligence commonly includes an automated review of what the codebase contains, and it surfaces components nobody in the building remembers.
• A negotiated warranty schedule. The company may be asked to state positively that particular categories of component are absent from what it delivers.
• Contact from a contributor or a compliance organisation. Less common, and harder to manage once it has happened, because the correspondence itself becomes something to be disclosed in any later transaction.

The sequence matters more than the substance. A company that has already looked at its position answers these calmly and on its own terms. A company that has not is doing the work to a deadline set by somebody else, with a signature or a payment waiting on the answer.

What is not worth doing

A great deal of money can be spent here to no purpose, because the subject attracts a completeness instinct it does not repay.

Components used only to build, test or deploy, and never delivered to anyone, rarely carry the obligations that matter, since the conditions generally attach to what is passed on. Running those to ground produces a long document and very little protection. The same goes for tracing every dependency of every dependency in a product not yet sold to anybody, and for commissioning a full review of a prototype that may well be discarded.

Rewriting is also not the answer to most of what gets found. Replacing a component under time pressure, using the engineers who have read its source, can create a fresher problem than the one being solved, and it does nothing about what has already been delivered. Where an obligation has been missed, meeting it is usually cheaper and less disruptive than removing the thing that triggered it.

The useful exercise is narrower than the exhaustive one: knowing which components actually reach what customers receive, and which of those carry conditions capable of affecting how the business sells. That is a far smaller question than an audit of everything the build touches, and it is the only question anybody is going to ask.

This guide is general information about how these matters usually run. It is not advice, and nothing becomes advice until terms are agreed in writing. Brandleys Legal Ltd delivers reserved legal activities alongside regulated partners.