Lawyer for open source law – licences, compliance & copyleft

Using open source with legal certainty

Quick start: what is your matter about?

Your contact: Dr. Alexander Pleh

Partner and Fachanwalt für IT-Recht (certified specialist lawyer for IT law). Together with Christoph Schleusener, MBA, lawyer.

Send open source enquiry

What happens after your enquiry?

After your enquiry, we will get back to you within 24 hours on working days. The first contact is free of charge. Before any costs arise, we will expressly inform you.

1. A short description is enough. Briefly describe the product, distribution channel and the components concerned. Helpful are an SBOM or scan result, licence notices and existing customer or supplier contracts.
2. Receipt and initial sorting. We assess the enquiry on the basis of the project described, the documents and the apparent goal. Deadlines and dates should be clearly recognisable.
3. Suitable starting point and cost range. We clarify whether an initial consultation, a service package or a specific mandate is the next step. As soon as the scope of the review is clear, we tell you the cost range – before work begins.

Typical cases from our open source law practice

We regularly encounter the following constellations. They are abstracted and simplified. Which obligations apply always depends on the licence text, version, architecture and distribution channel.

What you will have at the end

When open source becomes legally and commercially critical

Open source is neither a side issue of development nor a mere licence label. It becomes commercially relevant where product strategy, release, distribution, procurement, documentation and chain of title converge.

In practice, the core rarely lies in the abstract question of whether a licence is “free” or “strict”. What matters is which obligations are actually triggered in the specific use and whether they are compatible with product architecture, customer contract, supplier model and business strategy.

Especially for software companies, SaaS providers, platforms, agencies, OEM-related providers and investors, open source is therefore a cross-cutting matter of IT law, copyright law, licensing, compliance and, depending on the case, contentious enforcement.

Legal foundation: Computer programs are protected by copyright. Decisive are in particular Section 69a UrhG (opens in a new tab) in German law and the European Directive 2009/24/EC (opens in a new tab). Open source leaves this protection in place and governs use through licence conditions and their limits. Under Section 69c UrhG (opens in a new tab), reproduction, modification and distribution require the consent of the rights holder.

When you need us

Clients rarely seek just a general assessment of GPL or MIT. It is usually about specific commercial situations in which release pressure, contract logic or transaction requirements demand fast and reliable action.

Licence families and business consequences

For companies, it is less important whether a licence is “well known”. What matters is which obligations it triggers in the specific usage model and whether these fit with architecture, product strategy and contractual position.

Typical fallacy: “Open source is free, so legally uncomplicated” is a risky oversimplification for companies. Even small errors in notices, source offer, build allocation or chain of title can become commercially significant.

Copyleft, AGPL and architecture questions

Whether an open source licence leads to disclosure, distribution or information obligations is often decided by the overall technical and distribution structure. A single term rarely carries this decision.

Advice therefore regularly concerns questions such as: Is there only loose integration or close coupling? Are components modified? Is software only used internally, delivered to customers or provided over a network? What role do APIs, containers, plug-ins, mobile clients, edge components or embedded systems play?

Particularly with GPL- and AGPL-related topics, blanket statements are regularly unreliable. This applies especially to discussions about linking, distribution, network provision or the scope of possible source code obligations. For sound decisions, the licence text, version, technical integration and business model must be read together.

Go deeper: Operational compliance in depth · Review contract logic

Licence infringements, claims and liability

An OSS conflict is rarely just a technical problem. Depending on the case, copyright, contractual, sales law and, depending on the situation, competition law consequences are at stake.

First, a clean classification counts: Who is entitled to assert claims at all? Which licence version applies? Is it only about an ancillary obligation or about the allegation that rights of use have lapsed? Which builds, notices and documents can be proven? Only then can it be assessed reliably whether injunction, information, reimbursement of costs, remediation or further claims are realistic.

In the event of an infringement, removal, injunctive relief and, in case of fault, damages come into consideration under Section 97 UrhG (opens in a new tab). For GPL-related infringements, the decision of the OLG Hamm (Higher Regional Court of Hamm), judgment of 13 June 2017 – 4 U 72/16 (opens in a new tab) is an important German reference point. In product and supply chain cases, the logic of defects of title under Section 435 BGB (opens in a new tab) may additionally become relevant if third-party claims or licence encumbrances attach to the item.

Setting up contracts, procurement and supply chain properly

Many OSS risks arise in contracts, ordering processes and diffusion of responsibility long before they become visible in the code. That is exactly where later disputes can often be avoided most effectively.

Companies should clearly regulate who approves components, who supplies SBOM and notices and how source offers are organised. Equally important are the update and information obligations of suppliers and cooperation in conflicts, security notifications or due diligence enquiries.

This is particularly important in OEM, white-label, integrator, agency and enterprise constellations. The more complex the supply chain, the more important reliable warranties, audit rights, indemnities, escalation paths and clean integration with IT contracts and software contracts become.

Rule of practice: Open source should not only appear in a legal annex. What is critical is whether procurement, development, product, release and sales use the same documentation and escalation logic.

Governance, approvals and compliance

Open source compliance is a manageable business process and not a single document. The goal is reliable decision-making capability before release, in audits and in the event of conflict, without unnecessary bureaucracy.

The operational deep dive into policies, whitelists, scans, SBOM, training and implementation belongs on the specialist page Open source compliance. The overarching governance framework connects to compliance and, for security-critical products, often also to cybersecurity.

Review questions that create immediate value internally

• Which open source components are actually contained in the current production builds?
• Which licence versions apply and where are there local patches or special versions?
• Who is responsible for notices, licence texts and source offer towards customers or users?
• Which suppliers only give blanket warranties of conformity and where is real evidence missing?
• How does the company react if an investor, OEM, major customer or rights holder requests reliable documents tomorrow?

Due diligence, financing and exit

OSS is normal in transactions. It becomes critical where use, approvals and remediation are not documented or cannot be reliably proven.

Investors and buyers regularly ask about repositories, SBOM, internal approval processes, documented exceptions, copyleft risks, customer-side disclosure questions and existing remedial measures. Anyone who sorts out these topics for the first time in the data room regularly loses time and negotiating leeway.

For founders and growing product companies, the connection to start-up advice, licensing and the general IT contract and IP structure therefore makes sense early on. For ongoing support, involvement via the outsourced legal department can also be expedient.

Commercial core point: A well-documented OSS situation is rarely a deal breaker. An unclear, unprovable or only belatedly visible situation, on the other hand, can become one.

Interfaces with other areas of law at ITMR

Open source rarely runs in isolation within a company. Commercially relevant mandates almost always lie at the transitions to contract law, IP, data protection, security, AI and contentious enforcement.

How we support you in open source law

Our advice is geared towards sound decisions: fast enough for product and negotiation pressure, deep enough for governance, conflicts, supply chain and due diligence.

Discuss a mandate · Read the MG4 case

Key terms in open source law

Open source licence

A licence that permits the use, modification and distribution of software under certain conditions.

Permissive licence

A licence such as MIT, BSD or Apache with few distribution conditions, usually retention of the licence text and copyright notices.

Copyleft

A licence mechanism under which modifications and derivative works must be distributed under the same conditions.

AGPL

A copyleft licence that can additionally cover provision over a network.

Notices

Licence and copyright notices that must be included on distribution.

Source offer

An offer to provide the source code of a component in accordance with the licence conditions.

SBOM

Software Bill of Materials, a structured list of the components and dependencies of a product.

Chain of rights

The verifiable sequence of grants of rights from the author to the user.

The terms describe the practice of licence review. The text of the respective licence version always remains decisive.

Legal bases and helpful guidance

For a reliable initial review, official sources are more important than mere secondary summaries. The following references help with classification, review of claims and further study. German law (DE) and EU law (EU) are marked separately.

Practical deep dive at ITMR: MG4 and open source: warranty, recourse, compliance

Articles from our blog on open source law

These articles explore two topics that currently shape open source compliance strongly.

FAQ for companies on open source law

The following answers provide reliable initial guidance. For architecture, release, supply chain and conflict questions, the licence text, version, distribution channel and specific technical integration are regularly decisive.

Contact and contact persons