A Pakistani software house delivers a product to a European client. Diligence before an acquisition finds a copyleft-licensed library deep in the dependency tree. The client's lawyers conclude that the obligations attach to the delivered software, and the deal stops.
This is not hypothetical, and it is not rare. It is also entirely preventable.
Open source is licensed, not free
Every open source component is used under a licence. Using it means accepting conditions. Ignoring the conditions is copyright infringement, not a technicality.
Broadly, two families:
Permissive — MIT, BSD, Apache 2.0. You may use, modify and distribute, including in proprietary products, provided you preserve copyright notices and the licence text, and comply with any patent and attribution terms. Apache 2.0 also carries notice requirements on modification. These are generally safe for commercial work.
Copyleft — GPL, AGPL, LGPL, MPL. You may use them, but conditions attach on distribution, and those conditions can require that the source of the combined work be made available under the same licence.
The distinction that matters commercially:
- GPL — obligations trigger on distribution of the software
- AGPL — obligations can trigger on providing the software as a network service, which is precisely what SaaS is. This is the one that surprises people
- LGPL — designed to permit linking from proprietary code on conditions
- MPL — file-level copyleft, generally more workable
Add to that: dual-licensed components where the free licence is copyleft and a commercial licence is sold, and components with non-commercial or "source-available" licences that are not open source at all.
Where Pakistani software houses actually get caught
Delivering client work containing copyleft code, under a contract that warrants the deliverable is free of encumbrances and assigns full ownership. Both statements are then untrue.
AGPL in a SaaS backend, on the assumption that nothing is being "distributed".
Copying code from Stack Overflow, blogs or GitHub gists without checking the licence. Snippets carry licences too.
Modifying a copyleft library and treating the modification as proprietary.
Node and Python dependency trees, where a permissive top-level package pulls in a copyleft transitive dependency several levels down. Nobody looks, because nobody installed it directly.
AI coding assistants producing code derived from licensed sources. Where output reproduces substantial licensed code, the licence question does not disappear because a tool generated it. See using AI in your business.
What enterprise clients and investors check
If you sell to enterprises, or intend to raise or be acquired, expect:
- A software bill of materials — every component, version and licence
- Evidence of a policy and an approval process
- Confirmation that no copyleft code is in the distributed product, or an explanation of why the obligations do not attach
- Attribution files shipped with the product
- Warranties in the contract about all of the above
Not being able to produce a dependency list is itself a finding. It tells the auditor nobody has been looking. See startup fundraising and what diligence finds.
A compliance process that is actually workable
This does not require a department. It requires a habit.
- Write a one-page policy. Which licence categories are pre-approved (MIT, BSD, Apache 2.0), which need review (LGPL, MPL), and which are prohibited in deliverables without written approval (GPL, AGPL, non-commercial).
- Generate a dependency and licence report automatically in your build. The tooling exists for every major ecosystem and takes an afternoon to wire in.
- Review new dependencies before they are merged — a checkbox in the pull request template does most of the work.
- Keep the notices. Ship an attribution file with the licence texts. This alone satisfies most permissive obligations, and omitting it is the most common breach of all.
- Record approvals where something in the review category is used.
- Re-run the report before every delivery and before any diligence.
An hour a month, and it answers the audit question permanently.
Contract terms to get right
In client contracts, do not warrant that the deliverable contains no third-party or open source code unless it is true. Instead: disclose what is used in a schedule, warrant that it is used in compliance with its licence, and carve open source out of the IP assignment while licensing it through to the client.
In supplier and subcontractor agreements, require disclosure of open source used, compliance with licences, and an indemnity. Software houses that subcontract without this inherit whatever the subcontractor put in.
In procurement, if you are the customer, ask for the bill of materials before acceptance rather than after.
See software development and SaaS agreements and the contracts every business should have.
Releasing your own code as open source
Deliberate open sourcing is a strategy, not an accident. Before publishing:
- Confirm the company owns everything being published — including contractor contributions, which need written assignment
- Choose the licence to match the intent: permissive for adoption, copyleft to prevent proprietary forks, dual licensing if you intend to monetise
- Use a contributor licence agreement or a developer certificate of origin so you can relicense later
- Keep trade marks separate from the code licence — a permissive licence does not give anyone the right to use your brand. See trade mark registration
Note that publishing under a permissive licence is effectively irrevocable for the version published.
If you find a problem
Do not panic and do not conceal it. In order:
- Establish which component, which licence, and how it is used — statically linked, dynamically linked, forked, or merely a build tool. The obligations differ
- Assess whether distribution actually occurs
- Consider remediation: replace the component, isolate it, or obtain a commercial licence where one is offered
- Then address the contractual position with the affected client, having established the facts
Most of these are fixed at the engineering level. The ones that become disputes are the ones nobody told the client about.
See copyright for creators and content businesses and setting up a software house.
How the firm can help
We prepare open source policies and contract terms, review deliverables and dependency reports before a delivery or a diligence exercise, draft disclosure schedules and IP warranties that are accurate rather than aspirational, and advise on remediation where a problem has been found.
See intellectual property, or contact the firm.