Hardly any software codebase in 2026 still gets by without open source — and that’s economically sensible. What many businesses underestimate: open source is free of charge to use, but not unconditional. Anyone who ignores the licence conditions loses the right of use and commits a copyright infringement as with any other unlicensed software adoption. In M&A transactions, OSS compliance is today an independent audit workstream — anyone who messes it up jeopardises the deal.

Open source = free of charge, not unconditional

Open-source licences are private-law contracts between rights holders and users. Every licence sets conditions to be complied with:

  • Attribution of author and licence — mandatory in almost all OSS licences
  • Delivery of the licence text — typically as an appendix in the distribution
  • Retention of copyright notices in the source code — anyone modifying the code may not remove existing copyright notes
  • For copyleft licences additionally: disclosure of derived works under the same licence

Anyone who breaches these conditions uses the software without a licence — and that is a copyright infringement within the meaning of the UrhG, with all associated claims.

Permissive vs. copyleft — the everyday difference

The most important practical distinction:

Permissive licences — e.g. MIT, BSD, Apache 2.0:

  • Allow practically any use, including in proprietary products
  • Duty usually only: deliver licence text and author notices
  • Apache 2.0 additionally: explicit patent licence, notice duty for modifications
  • Low legal risk, provided notice duties are observed

Copyleft licences — the two most important families:

  • GPL (GNU General Public License) — anyone who incorporates GPL code into their software and distributes the product must disclose the entire source code under the GPL
  • AGPL (GNU Affero GPL) — requires disclosure even when the software runs only as a server service (no classic distribution required) — critical for SaaS providers
  • LGPL — milder copyleft, allows linking with proprietary code under certain conditions

The classification in the specific case is not trivial: dynamic vs. static linking, plug-in architectures, containers, microservice separation — all of this affects whether a “derived work” exists or not.

Frequent breaches in practice

From our advisory practice and the international OSS litigation landscape, four typical constellations can be derived:

  • Missing licence notes. Even permissively licensed code (e.g. an MIT-licensed JavaScript library) triggers a copyright infringement if the licence text and author attribution are not delivered with the end product — typical in mobile apps and in Docker images.
  • GPL code in proprietary products. Anyone who statically links GPL-licensed code into commercially distributed software and fails to comply with GPL duties risks the obligation to disclose their own source code.
  • AGPL and SaaS. Many cloud/SaaS providers are not aware that AGPL components also trigger the disclosure duty in server operation — differently from classic GPL.
  • Licence incompatibilities. Certain OSS licences cannot legally be combined. Anyone who mixes obvious but legally incompatible components breaches at least one of the two licences.

M&A risk: what buyers audit

In software M&A transactions, OSS compliance is now an independent workstream of due diligence:

  • SBOM creation (Software Bill of Materials) with automated scanner tools
  • Licence mapping — which licences are used, in which architectural position
  • Risk assessment — copyleft duties, licence incompatibilities, missing notices
  • Remediation plan — what must be fixed before closing, what can follow post-closing

If a buyer finds unrecognised AGPL or GPL use in a commercial codebase, purchase-price reductions, holdbacks or, in extreme cases, abandonment of the transaction are realistic consequences. As target, those who tidy up early avoid last-minute disputes at the negotiating table.

Building compliance — pragmatic 5-point plan

From our advisory practice the following steps are recommended:

  • Inventory — automated scanning of the existing codebase (ScanCode, FOSSology, Black Duck, FOSSA etc.) to identify all OSS components and their licences
  • Risk triage — which licences are uncritical, which need attention, which are problematic in current use
  • Compliance hygiene — deliver licence texts with end products, ensure author attribution, audit distribution channels (including app stores, container images)
  • OSS policy — internal policy on which licences are permitted for which uses and who reviews this before adopting a new component
  • Continuous compliance — integrate SBOM generation into the CI/CD process instead of a one-off effort every few years

Our role

Tonninger Schermaier & Partner advise software companies on open-source compliance — from preventive architectural advice through M&A due-diligence support to defence against OSS infringement allegations.

This article is for general information and does not constitute legal advice in any specific case.