Review open-source components in an acquisition: licence inventory, SBOM, copyleft scope, pre-closing remediation and SPA protection.
BRANDAUER Rechtsanwälte
Salzburg law firm for corporate, company and transaction law
Every transaction is handled by a coordinated team of lawyers, legal staff and specialists. In company acquisition matters we look at structure, contract, tax and liability together.
An incomplete open-source register can be more than a documentation gap in a technology deal. It may affect the product rights, source-code obligations and the buyer’s negotiating position in the acquisition.
A software scan alone is therefore not enough. Buyers need to combine the versions in use, the actual licence texts, the technical integration and the way the product is distributed or made available. Only that combination allows a meaningful assessment of copyleft risk.
This article deepens the broader guide to buying a software or SaaS business and separates licence review from general IP and IT due diligence.
An SBOM is a starting point. Check the licence text, version, integration, distribution model and intended post-closing use.
Already know you want to get in touch? Go straight to the enquiry form.
An SBOM is a starting point. Check the licence text, version, integration, distribution model and intended post-closing use.
Keep the reviewed component list as a data-room schedule and specify in the SPA which licences, notices and source-code offers must be available by completion. Reassess each copyleft component against its actual use and distribution method.
Do not cover the uncertainty with a general warranty. Create a versioned inventory, preserve the licence texts and review the affected components and their integration. Depending on the result, remediation may involve replacement, separation, an additional licence or a documented source-code offer.
A useful inventory records at least the package, exact version, origin, SPDX identifier, licence file, copyright notices, dependencies and use in the product. An SBOM can provide or prepare these details, but it does not replace review of the artefact that is actually released.
Compare manifests, lockfiles, build images, containers, plugins, vendored libraries and source repositories. If a licence file is missing or the deployed version differs from the register, make that gap visible in the data room.
The MIT licence generally permits use, modification and distribution, subject to retaining the copyright and licence notice. Apache License 2.0 also grants broad rights and includes requirements concerning the licence text, modification notices, copyright and NOTICE information, as well as a separately worded patent licence. Those obligations must remain findable in the product and distribution materials.
GPL 2.0 attaches its additional requirements to copying, modifying and conveying the program or a work based on it. When object code is conveyed, it generally requires corresponding machine-readable source or an allowed alternative. AGPL 3.0 adds rules for modified programs that users can interact with over a network. Whether a rule applies depends on the actual licence text, modification and technical delivery. A licence name alone does not support a blanket conclusion.
For each flagged component, determine whether it is unchanged or modified, linked statically or dynamically, operated as a separate service or distributed alongside the product. Calling something a library or microservice does not answer the question. The communication method and the nature of any combined work need technical and copyright analysis.
A SaaS operation also requires a distinction between running software on a server and conveying it to customers. AGPL components deserve particular attention where users interact with a modified program over a network. Directive 2009/24/EC and Austrian copyright law provide the copyright framework for computer programs, while the project’s concrete obligations still come from the applicable licence text and actual use.
Not every deviation requires the same response. Options may include removing or replacing a component, upgrading to a suitable version, separating a service, meeting notice and source-code obligations or obtaining an additional commercial licence. The technical decision should be aligned with the product roadmap, release plan and support commitments.
For every open component, buyers should record the owner, effort, dependencies, deadline and evidence of completion. A risk that can only be fixed after completion needs a precise handover obligation and should not be hidden behind an undefined assurance. The due-diligence gap check helps structure missing documents and responsibilities.
The warranty catalogue should not merely confirm that the company owns its source code. It should address the inventory, known violations, outstanding notice or source-code obligations, infringement claims and changes between signing and completion. Disclosures should identify the affected component and link to the supporting record.
Depending on the finding, the parties may use remediation as a completion condition, a purchase-price holdback, a specific indemnity, escrow or a post-completion cure obligation. The general SPA warranty catalogue and the completion conditions must match the technical action plan.
No blanket open-source warranty: A general statement that all licences have been complied with is weak where the inventory is incomplete. First secure the components, licence texts and remediation plan. Subscribe to legal updates for new articles and legal guidance from the firm.
The risk usually arises from the combination of text, code, architecture and transaction documents, not from the licence name alone.
| Layer | Review question | Possible deal consequence |
|---|---|---|
| Inventory Which components and versions are actually used? | Reconcile SBOM, lockfiles and build artefacts | Complete the data-room schedule |
| Licence Which complete licence text applies to this version? | Compare SPDX data with LICENSE and NOTICE files | Provide notices, licence copies or source offer |
| Architecture How is the component integrated or provided? | Assess linking, modification, service boundary and network access | Remediation, separation or deeper legal review |
| Remediation What must happen before release or completion? | Assign owner, cost and evidence | Completion deliverable, holdback or indemnity |
| Contract How is the residual risk allocated? | Align warranty, disclosure and claim mechanics | Specific indemnity, escrow or cure obligation |
The assessment depends on the applicable licence version, the program and its use. An automated licence list does not replace code or contract review.
No. An SBOM is an important starting point, but it must be checked against the versions actually released, complete licence texts, copyright and NOTICE information and the technical integration.
No. The consequences depend among other things on modification, integration and distribution. The relevant GPL text must be applied to the specific program and delivery model.
AGPL contains additional rules for modified programs that users can interact with over a network. Server operation, modifications, user interaction and the source-code offer should therefore be reviewed separately.
Request at least an SBOM or comparable inventory, repositories, manifests and lockfiles, LICENSE and NOTICE files, release artefacts, internal approvals and a list of known exceptions and open remediation items.
Depending on the finding, use disclosure, specific warranties, pre-completion remediation, a specific indemnity, a purchase-price holdback or a cure obligation. The clause should identify the component and the evidence required.
Source code, contracts, data and operations in context.
Review title, licences and change of control.
Product obligations and security processes in a deal.
Translate due-diligence findings into contract protection.
When buying a company, structure, review and contract decide. Call us directly or send an email, callback within one business day.
Address
BRANDAUER Rechtsanwälte GmbH Giselakai 51 5020 Salzburg
Phone
+43 662 6280000