When open source is found in the delivery: what to do first
When an audit or a routine scan turns up open-source code inside a delivered product, the acceptance clock stops being the main concern. The licence terms attached to that code take over. Freeze the affected build, request a full component list from the vendor, and treat the found code as governed by its own licence until a lawyer confirms otherwise. Nothing else moves until that confirmation exists.
What the law actually protects
A computer program is protected as a literary work under Directive 2009/24/EC. The rightholder controls reproduction, adaptation, and distribution of that program. An open-source licence is the mechanism by which the rightholder grants some of those rights back, on stated conditions, not a general exemption from ownership. Nothing in that directive makes open-source code free of obligations. It only tells you who was entitled to attach the conditions in the first place, and on what terms someone else may rely on them.
This matters for the contract sitting on your desk. A vendor's warranty of clean, unencumbered title is not broken by open source as such — plenty of deliveries legitimately include it. The warranty breaks when the vendor delivered code under conditions it did not disclose, or under a licence it did not honour, and the delivered product no longer matches what was promised in the specification.
What changes once open source is found
Three things move at once. Acceptance, if it has not been signed off yet, should be held rather than waved through on the original timetable. Any warranty or indemnity clause tied to intellectual property title becomes live, because the delivery may no longer match the representation made when the agreement was signed. And if your organisation falls within the scope of Directive (EU) 2022/2555 (NIS2), an unmanaged third-party component sitting in production is exactly the kind of supply-chain exposure that directive expects you to assess, not simply note and forget.
None of this depends on the component being malicious, outdated, or broken. A perfectly working library delivered under an incompatible licence produces the same three consequences as a defective one, because the problem is contractual, not technical.
What to do, in order
| Licence family | Typical condition attached | Immediate action |
|---|---|---|
| Permissive (MIT, BSD, Apache-2.0 style) | Attribution and licence notice preserved | Log the component, check the notice is present |
| Weak copyleft (LGPL, MPL style) | Modified files must be shared under the same terms | Isolate the file, check whether it was modified |
| Strong copyleft (GPL, AGPL style) | Obligation may extend to the combined work | Freeze distribution pending legal review |
| No licence file found | No use has been authorised by the rightholder | Treat as unauthorised code, escalate immediately |
- Technical lead: freeze the affected build; stop it moving to production or to the customer while the position is unclear.
- Vendor, on written request: produce a full list of open-source components and their licences for the exact build delivered, not a generic list for the product line.
- In-house counsel: match each licence against what the master agreement actually permits you to do with the delivered code.
- Technical team: keep any copyleft-licensed file separate from proprietary modules while the legal review runs, so the two do not merge further.
- Contract owner: put the vendor on notice in writing, citing the specific acceptance or warranty clause that applies.
- Legal: decide, once the component list is in, whether the position is remediable within any cure period the contract allows.
Who decides, and where
Inside your organisation, the acceptance committee or the contract owner named in the agreement decides first, on the strength of the component list and the licence texts. That is a commercial decision about whether to accept, reject, or conditionally accept the delivery, and it does not require a court.
If the vendor disputes the finding, the forum is whatever the agreement names for disputes — arbitration or a named court. That forum weighs the same evidence: the component list, the licence texts themselves, and the delivery documentation, rather than a summary of what either side believes the licence says. Neither party's internal opinion about the licence carries weight on its own.
For components that also process personal data, the contractual layer runs separately from the licensing question. The Data processing agreement overview sets out where that obligation sits and how it interacts with a delivery that has just failed acceptance.
If the delivery mixes licence types
If the flagged component carries a permissive licence, the fix is usually paperwork: add the missing notice, log the component, and move on without touching the acceptance timetable.
If it carries a copyleft licence, the live question is whether your own code counts as a derivative or a combined work under the reproduction and adaptation rights set out in Directive 2009/24/EC. If it does, the licence's distribution terms may reach further into your codebase than the vendor assumed when the contract was signed.
If the same flagged component also feeds a royalty-tracking mechanism, the conflict does not stay contained to the codebase: When royalties encoded on-chain are ignored and the evidence trail depends on that same delivered codebase, so the open-source question becomes part of that dispute as well, not a separate one.
What this page does not settle
This page does not read the licence text for you, and it does not tell you whether a given piece of code is, in fact, a derivative work under the applicable rules. Both are technical legal questions that turn on the specific code and the specific licence, not on a general rule that applies to every delivery the same way.
When a customer wants ownership of improvements and the delivery also contains unlicensed components, the two questions tend to surface in the same acceptance meeting, and each needs its own separate answer rather than one combined guess.
Where the vendor is a Polish entity, a Counterparty in Poland and its limits in detail register check shows what a public search can confirm about that vendor, and equally what it cannot confirm.
The Document in Poland and its limits in practice check works the same way once the licence file or the delivery record itself needs to be verified as authentic, rather than simply assumed to be what it claims.
Verified
Checked 4 November 2025. Primary sources: Directive 2009/24/EC on the legal protection of computer programs; Directive (EU) 2022/2555 (NIS2) on measures for a high common level of cybersecurity across the Union. Neither source is quoted for a specific article number on this page; both are cited for the general obligation they establish.
FAQ
What is the first step when open source is found in the delivery?
Freeze the affected build and request the full list of open-source components and their licences from the vendor before taking any other step.
Which deadline is already running?
Whatever acceptance or notice period your agreement sets starts running from discovery, not from the vendor's admission. Check the acceptance clause first, not the calendar.
Who decides, and on what evidence?
The contract owner or acceptance committee decides first, on the component list and the licence texts. A dispute forum named in the agreement decides second, on the same evidence, not a fresh account of it.