COMPLIANCE & RIGHT · TREATY
Software is purchased, developed, assembled from existing components and used via different models. This creates different rights and obligations. A license invoice does not yet prove that any actual use is permitted. We check usage rights, development contracts and the handling of open source components.
Capture the actual use
At the beginning there is an inventory: Which programs and versions are used where, by whom and to what extent? License metrics can relate to users, devices, processors, accesses or certain applications. Virtualization, test environments, cloud operations and Group use must be compared with the respective conditions.
The change of service providers or a restructuring can also be relevant. A licence for a particular company does not automatically cover all associated companies. Before renewing the contract, actual use and procurement should be brought together in a comprehensible manner.
Rights to self-developed software
For employee programs, § 69b UrhG contains a special regulation if the software is created in the performance of the tasks or according to the instruction of the employer. This rule cannot be applied to free developers or any other work result.
For external developers, the required usage rights must be secured contractually. Depending on the project, this includes processing, further development, transfer to customers, integration into products and use by affiliated companies. Source code access, documentation, third party components and participation in a change of supplier should be treated explicitly. The payment of the development fee does not answer these questions alone.
Open Source is not a legal stock
Open source software may be used according to the terms of the respective license. These conditions differ considerably. Often it is about copyright notices, license texts and references to changes. For certain copyleft licenses, obligations to provide source code may be added. Whether and to what extent this happens depends in particular on license version, editing, connection with other code and usage or distribution form.
The AGPL contains special requirements for certain uses over a network. This does not imply that any use of open source software requires the publication of the entire own code, nor that a pure hosting model always remains without license obligations. The evaluation must be based on the concrete architecture.
A component directory and automated scans facilitate the inventory. They do not replace the legal assessment of unclear references, different licensing options or conflicting metadata. Subcontractors must also provide the necessary information.
A release process for development
- New components are recorded with version, source, license and intended use.
- Distinctive terms and license conflicts are checked before product release.
- All necessary information, license texts and, where applicable, source code offers are provided.
- Changes, dependencies and later security updates remain understandable.
The process should support everyday development. Clear responsibilities and a short rule for unclear cases are useful. A general ban on all free components is neither an appropriate test nor a release without knowledge of the conditions.
Licensing and audit requests
In the case of an audit request, contractual basis, scope, deadlines and confidentiality are first examined. Data should not be issued in a disorderly manner. At the same time, existing cooperation obligations must be respected. A technical inventory, the examination of the license metric and the legal classification of claims belong together.
We support licensing agreements, development agreements, open source regulations and the handling of concrete complaints. For a Request Product or project, licensing conditions, operating model and deadlines already set are helpful.
Legal basis and decisions: UrhG, in particular §§ 69a–69g; GNU General Public License, Version 3; GNU Affero General Public License, Version 3.
Situation as at 2 November 2026.
Further reading: Software businesses · Cyber Resilience Act for manufacturers and software providers · Acquisitions and investments
Four practical examples
The following fictitious cases illustrate typical examination questions. The concrete solution depends on the circumstances of the individual case.
01 · Overuse of licences
A company has more productive users than booked accesses. Licensing metric, scope of contract and adjustment are checked before unsecured information is provided to the provider.
02 · Copyleft in the product
A developer integrates a library. License text, technical integration and sales form determine the examination of possible disclosure obligations.
03 · Development by Freelancer
The contract is silent about further development and transfer. Extent of rights and required processing rights are clarified before product marketing.
04 · License audit of the manufacturer
A provider requires system data. Examination law, scope, confidentiality and a controlled procedure are agreed; not all required information must be issued without verification.
Your next step
Do you want to transfer the requirements to your company or have a specific process checked? A brief description and a reference to existing deadlines are sufficient for the first contact. We shall vote on the scope of examination and compensation prior to commissioning.