Free and Open Source Software (FOSS) is used extensively in software development — yet even this free code comes with license terms that must be observed. We support companies in avoiding civil claims and criminal liability arising from license and copyright infringements.
Guiding the establishment of effective open-source compliance processes — from kick-off through process design to lasting integration into development and procurement workflows. With an eye to scalability, auditability and the reality of your engineering teams.
Assessment of the open-source licenses in use — from permissive models (MIT, BSD, Apache 2.0) through weak copyleft (LGPL, MPL) to strict copyleft (GPL, AGPL). We name the risks in each component before they become an issue in an audit or a dispute.
Ensuring technically and legally license-compliant use — avoiding unintended copyleft obligations, resolving license incompatibilities, structuring combined distributions to avoid license conflicts. So that one forgotten clause does not trigger a demand to release the entire product as open source.
Producing license-compliant product materials — notice files, attribution lists, a software bill of materials (SBOM) in SPDX or CycloneDX format, source code disclosure packages for copyleft components. So that every delivery survives the audit.
One forgotten license clause
can trigger a demand
for source disclosure.
JUN Legal GmbH is a partner of the OpenChain Project — the initiative backed by the Linux Foundation that, with ISO/IEC 5230:2020, created an international standard for open-source compliance in companies.
We support companies in building structures that conform to OpenChain, in gap analyses against the standard and in preparing for self-certification or third-party certification — starting with the six core requirements (program, staff, competence, materials, verification, conformance).
Open-source compliance is not only a legal issue; it is also an engineering issue. Legal processes have to fit the way software is actually built. We work directly with your development, DevOps and product teams: on component selection, on build pipeline integration and on defining acceptable license stacks for each product line.
To that end, we set up semi-automated legal checks — license scanners (FOSSology, ScanCode, ORT), SBOM generators and policy engines, integrated into CI/CD pipelines. License issues are identified before they become release blockers.
Training formats for everyone who works with open source: from a license fundamentals module for mixed teams (What is copyleft? When do I become a distributor?) to deep dives into license combinations, patent clauses and SBOM standards. Also available as a kick-off workshop at the start of a compliance initiative.
When LLM tools may incorporate paraphrased open-source code into proprietary products, two fields of law come together — open-source license law and copyright questions around AI-generated code. Read more in our practice area AI & legal tech.
Client experience translated into a standard reference work: the practitioner's handbook on open-source compliance, edited and written by Christian Galetzka, Chan-jo Jun and Yvonne Roßmann — all of JUN Legal GmbH. Published (in German) in the “Kommunikation & Recht” series by Fachmedien Recht und Wirtschaft (Frankfurt), 415 pages.
For licenses that meet the Open Source Definition, yes: they permit use for any purpose, including commercial use. Much of what is labeled open source does not qualify, however. Creative Commons licenses with the NC element permit only non-commercial use, even in internal deployment. Other licenses prohibit specific business models, such as offering the software as a cloud service. What counts is the license of each individual component.
Only if you distribute the software. You must then include the source code of the GPL component or offer it as the license requires. Your own code is affected if, together with the component, it forms a work based on it: you may distribute that work only as a whole under the GPL. Your code does not become open source by itself. Where the line falls depends on the technical integration and on any exception clauses in the license.
Under the GPL, as a rule, no: if you only run the software on servers and do not give users a copy, you are not distributing it. Code that you as the provider deliver to users, such as JavaScript, is different: that is your distribution. Merely using the service distributes nothing. Licenses with a network clause are stricter: under the AGPL-3.0, you must offer the source code of a modified version to all users free of charge. That is why you should check every component on both server and client.
The GPL is the clearest on this: your rights under the license terminate as soon as you distribute the software in breach of the license terms. Rights holders can then claim injunctive relief and enforce it by preliminary injunction, which can mean a halt to distribution. Cease-and-desist costs come on top. If you supply the product to customers, it may also have a defect in title, for which you are liable under warranty law.
For products with digital elements placed on the market from December 11, 2027, yes: manufacturers must draw up a machine-readable SBOM covering at least the top-level dependencies (Art. 71(2), Annex I Part II No. 1 of Regulation (EU) 2024/2847, Cyber Resilience Act). The regulation does not require publication. For license review, that scope is not enough: you need all components with their licenses, including indirect dependencies.
