5,0/5 Google · 167 reviewsWe do not check reviews of us on other platforms that we do not quote verbatim for authenticity. They may therefore also come from people who are not our clients. The rules of the respective platform apply. Reviews that we quote verbatim on our website, by contrast, have been checked for authenticity within the meaning of Section 5b(3) UWG (German Act against Unfair Competition): we compared the reviewers’ names with our client register. We also asked the respective platform to check the reviews for authenticity.Period: October 2016 to date · As of: 28 October 2026
Open source compliance audit for software
Deliver OSS evidence before the deal falters
When SBOM, notices, copyleft questions, source offer or supplier commitments suddenly count, a scanner report is not enough. We deliver the legal classification with a clear picture of approval and measures.
Please enter a short description first.
The first contact is free of charge. We will tell you explicitly before any costs arise.
Response within 24 hours on working days
As of: 23 October 2026
Approval status1 of 5
- SBOM with build referencePresent
- AGPL component in the backendCheck
- Third-party noticesMissing
- Customer warranty in contractCheck
- Supplier artefactsMissing
Point of review: Warranty in the contract does not match the SBOM
- 1Secure the pictureScans, SBOM, contracts
- 2Prioritise risksObligations in the model
- 3Prepare approvalPicture of measures
Schematic illustration of an OSS audit. Simplified example.
We review open source for
- SaaS providers
- OEM suppliers
- Scale-ups
- Investors
Key points at a glance
- A scanner report does not replace an approval decision.
- ITMR checks where your product, SaaS offering, SDK, API or embedded set-up is vulnerable and which obligations must be met immediately.
- You learn which documents you can present to customers, investors, buyers or OEMs with a clear conscience.
- The result is a decision paper that can be used internally and is robust externally.
- Your contact is Dr. Alexander Pleh and his team. He is a specialist lawyer for IT law and family law. Response on working days within 24 hours.
- SaaS
- Software as a Service. Software used over the internet rather than installed.
- Open source
- Software with open source code. Its use is governed by the respective licence.
Reason for instruction
When does open source become relevant for approval?
In our experience, escalation rarely starts in the repository.
A developer detail becomes a management question.
It starts when a product is to go live, an enterprise customer demands robust documents, an investor opens the data room or an OEM wants to know how your OSS stack is managed.
This specialist page is built for situations in which it must be decided at short notice whether a software product, a SaaS set-up or embedded software can be approved, disclosed or improved with an acceptable risk. It deliberately does not cover general OSS basics.
Our main IT law page answers fundamental questions on contracts, digital services and IT projects. A specific open source problem can first be briefly classified here before a full audit is commissioned.
For products with digital elements, the pressure grows further, because security, update and supply chain issues converge more closely with OSS evidence. Anyone treating open source purely as a licensing question starts too small in the wrong place.
- Trigger
- Release, enterprise deal, due diligence, OEM
- Subject of review
- Licences, SBOM, notices, contracts
- Result
- Risk matrix and action plan
- Legal basis
- Sections 31, 69c UrhG, licence terms
Describe your OSS problem using the form. We will get back to you on working days within 24 hours.
How it works
How does the open source audit work?
Three steps from the situation picture to approval.
01
Secure the picture We bring together existing scans, SBOM, notices, contracts, supplier commitments and the specific distribution or transaction context.
02
Prioritise risks Not everything is equally critical. What matters is which licence obligations, copyleft questions, disclosure issues or contract gaps have an effect in the specific model.
03
Prepare approval You receive a basis for decisions with a picture of measures, a disclosure plan and clear next steps for management, legal, product and sales.
What the audit specifically reviews
- 1
Product and version Which OSS components are contained in the relevant build, product or SaaS stack, are there local modifications and is the release path traceably documented?
- 2
Licence and obligations matrix Well-known abbreviations alone do not help. We assess which obligations are triggered in the use and distribution model, where copyleft becomes critical and where risks are put into perspective.
- 3
Contracts and supply chain Many OSS problems arise from imprecise customer warranties, weak supplier obligations, missing audit rights or unclear responsibility along the chain.
- 4
Approval and disclosure Which artefacts must be in place immediately, what should be disclosed, what must be remedied before signing or release and what can consciously be decided with residual risk?
How long does it take? We complete most work steps within a few working days. How quickly it goes depends on the scope and your feedback. Do you have a fixed date, such as a launch? Tell us right away in your enquiry and we will plan for it.
Work product
What do you have in hand at the end?
Service package: OSS compliance audit
Prioritised risk matrix You see which points are critical for approval, which only need to be documented and where later action is sufficient.
Concrete action plan Notices, licence texts, source offer, SBOM, contract clauses, supplier requirements and internal approvals in a traceable order. The open source/SBOM check helps in advance.
Disclosure and basis for discussion For customers, investors, buyers or OEMs, it becomes clear what is disclosed, what is explained and what should not be warranted too hastily.
Bridge to contract, DD or conflict If the situation goes beyond an audit, we transfer it into contract restructuring, transaction support, supply chain management or a contentious response.
- For whom
- Software companies under review pressure
- First response
- within 24 hours on working days
- Costs
- We tell you the costs transparently before you instruct us.
- Not included
- Technical scans. Your team or your service providers deliver these.
Who delivers what and who decides
- Scan reports and SBOM
- Third-party notices
- Customer questionnaires and contracts
- Description of the product or SaaS model
- Licence and obligations assessment
- Contract review
- Risk matrix and action plan
- Disclosure strategy
- Your management decides on approval
- In a dispute, the court
How does the engagement work?
- 1
First assessment You describe your problem using the form. We assess whether an audit is needed. The first contact is free of charge.
- 2
Offer Before the audit starts, we tell you the scope and costs transparently.
- 3
Court steps separately We agree court proceedings and representation in conflicts separately.
Client situations
At which moments does review pressure arise?
Four occasions from which audits arise in our experience.
There are scanner results or individual lists, but no reliable statement on which builds are affected, which obligations are triggered and whether notices, licence texts or source offer match the release.
Questionnaires, contractual warranties, audit rights or security requirements reveal that OSS is used but the documentation is not prepared to customer level.
Buyers, investors or advisers want to see which processes exist, which risks are known and how remediation works if in doubt.
In product chains based on division of labour, general warranties are not enough. Release-specific evidence, clear responsibilities and contracts regulating recourse and remediation are required.
Friction losses
Where do companies lose time and room for manoeuvre?
Typical failure patterns that cost negotiating room and credibility.
Many teams have technical reports but no robust statement on what of it counts legally and contractually in the current product context.
A list only helps if it can be assigned to the specific product version. Anything else tends to raise new questions in the audit rather than create certainty.
Even if classic distribution rules do not apply one-to-one to SaaS, AGPL-type constellations, warranties, documentation and supply chain obligations remain highly relevant.
General compliance statements from suppliers help little in procurement, DD or recourse if notices, SBOM, audit trails or clear remediation obligations are missing.
Constellations
Which companies is the audit right for?
Suitable for software companies under real review pressure.
Useful when sales, customer warranties and release cycle are closely linked and a later withdrawal would be economically expensive.
Here, besides internal order, the ability to provide evidence and contract towards third parties in a liability-sensitive chain counts.
The more closely software is tied to the valuation, the faster missing approval processes and weak documentation become a deal issue.
When sales scale faster than governance, an early legal sorting helps to avoid making commitments by gut feeling.
Alternatives
Where does this page end and where does it continue?
Broad fundamental questions on IT projects and contract architecture belong on IT law. Open source law covers licence families, copyleft doctrine, chain of title, cease-and-desist letters or strategic OSS use in depth. This page stays with auditable approval and evidence questions.
When warranties, audit rights, indemnities, subcontractors or exit rules need to be added to contracts.
When OSS evidence coincides with security, update, incident or regulatory pressure.
When it should become visible how quickly OSS compliance can tip into warranty, recourse and operational escalation.
Legal framework
Which legal bases apply to open source?
Software is protected under Section 69a UrhG. Anyone who reproduces, modifies or distributes it needs a right of use under Section 69c UrhG. Open source licences grant this right only subject to conditions.
If licence conditions such as notices, licence texts or disclosure of the source code are breached, the right of use may lapse. Claims for injunctive relief and damages under Section 97 UrhG may then follow.
Copyleft licences such as the GPL require disclosure of derivative works on distribution. The AGPL extends this obligation to provision over a network and thus also affects SaaS models.
- Section 69c UrhG Acts requiring consent in relation to software.
- Section 97 UrhG Injunctive relief and damages.
- Section 69a UrhG Copyright protection of computer programs.
Limits
What does the audit not cover?
We assess legally and contractually. Some points remain with you.
- 1
No technical scans Your team or scanner service providers deliver the factual basis.
- 2
No carte blanche Not every finding stops a release or deal. It becomes critical where obligations are triggered or warranties can no longer be upheld.
- 3
Residual risk remains a decision Your management decides which points are consciously approved with residual risk.
What you should have ready
- Scan reports, SBOM and notices.
- Release or build reference.
- Customer questionnaires and contractual warranties.
- Supplier contracts.
Your contact
Lawyer · Partner · Specialist lawyer for IT law · Specialist lawyer for family law
View profile Düsseldorf, Schirmerstraße 80 · Hamburg, Palmaille 124
ReviewsWe do not check reviews of us on other platforms that we do not quote verbatim for authenticity. They may therefore also come from people who are not our clients. The rules of the respective platform apply. Reviews that we quote verbatim on our website, by contrast, have been checked for authenticity within the meaning of Section 5b(3) UWG (German Act against Unfair Competition): we compared the reviewers’ names with our client register. We also asked the respective platform to check the reviews for authenticity.
What clients say
5,0 von 5 · 71 Bewertungen auf anwalt.dePeriod: October 2018 to date · As of: 28 October 2026
“Mr Pleh advised us excellently, was very attentive and took a lot of time for us. That is how legal support should be.” (translated from German)
“Very helpful and fast” (translated from German)
“Competent and friendly advice. Getting in touch was very straightforward and the guy knows what he's doing. Always worth a call for legal problems.” (translated from German)
FAQ
What do companies ask about the OSS audit?
When does an open source compliance audit make sense?
When a release, enterprise contract, OEM approval, audit or due diligence demands robust statements on OSS components, licence obligations, SBOM, notices or source offer at short notice. The later these questions arise, the more expensive the response.
Is a scanner or an SBOM alone enough?
No. Scanners and SBOMs are important factual bases. But they do not answer which obligations are triggered in the specific distribution model, which contractual statements are risky and which evidence is robust externally.
Is SaaS automatically uncritical with open source?
No. Even without classic distribution, contractual warranties, supply chain obligations, documentation and, depending on the licence type, additional risks remain relevant. You should not approve AGPL-type constellations out of habit.
What should we have ready for the first call?
Helpful are scan reports, SBOMs, third-party notices, release or build reference, customer questionnaires, contractual warranties, supplier contracts and a short product description. Completeness is not necessary. The aim is to grasp the situation quickly.
Can weak documentation still be cleaned up before a due diligence?
In our experience, in many cases yes, but not at will. What matters is whether technical attribution, documentation and responsibilities can still be traceably established. The earlier the gaps become visible, the more room for negotiation remains.
What happens if a critical point emerges in the audit?
Then prioritisation is needed, not panic. Not every finding automatically stops a release or deal. It becomes critical where obligations are triggered, warranties can no longer be upheld or external evidence is missing at short notice. That is what the audit is for.
Next step
Would you like to classify your approval risk now?
If OSS questions are currently affecting a release, enterprise contract, supply chain or data room, speed matters, but not at the expense of robustness. ITMR sharpens the picture, prioritises risks and turns scattered documents into an approval or remediation decision. Open source becomes economically relevant where IT law, contracts, copyright, supply chain and product management converge. At ITMR, Dr. Alexander Pleh, specialist lawyer for IT law, and Christoph Schleusener, MBA, with a focus on IT contracts, copyright and open source strategies, work at this interface.
Helpful for your enquiry
- Product and release
- Occasion and date
- Existing scans or SBOM
- Contracts affected
You can submit confidential documents after the first contact.
Briefly classify your OSS problem
For software companies under specific review pressure.
Confidential documents such as the SBOM, scan report, customer questionnaire, contract clauses or notices can be submitted in a structured way after the first contact.
Related services
Open source law Licences, copyleft, conflicts.Open source/SBOM check Structure in advance.IT contract / software contract Warranties and audit rights.Cybersecurity Security and regulatory pressure.IT-Recht Fundamental questions.Review software licence agreements Review the scope of the licence.
From our blog: MG4 and open source · CRA and open source