Open Source

What is open source?

Open Source (in German: quelloffene Software) means software whose source code is publicly accessible and may be used, examined, modified and passed on by anyone under the terms of a licence. Source code is the human-readable program code from which the executable software is produced. What matters is not the price but the licence: it grants far-reaching rights of use but, depending on the type of licence, ties them to obligations. This is comparable to a published recipe that anyone may cook and adapt, as long as the person observes the author's conditions, for example by naming the author.

Almost every software product today contains open source components, often indirectly, because an embedded component itself brings further ones with it. They are thus a fixed part of the tech stack. Under German law, with the licence the author grants everyone non-exclusive rights of use under copyright law. German courts have recognised widely used open source licences as effective. According to a widespread view, the rights of use lapse as soon as the licence obligations are breached; injunction and damages claims under Section 97 of the German Copyright Act (Urheberrechtsgesetz, UrhG) are then threatened. Individual licences, such as the GPL in version 3, allow the rights to be regained by promptly remedying the breach.

In financing rounds and company sales, open source is therefore a fixed component of technical and legal due diligence, that is, the examination by investors and buyers before they invest or buy. Special warranties in the purchase agreement are added to this.

Types of licence

Permissive licences

Permissive licences such as MIT, BSD or Apache 2.0 allow the code to be built into one's own products and those products to be distributed under one's own terms, including closed ones. Essentially, what is required is to retain copyright and licence notices. The Apache licence additionally contains a patent licence and requires changes to be identified.

Copyleft licences

Copyleft licences require that modified versions and works built on them, when passed on, are under the same licence and that their source code is made accessible. With strong copyleft such as the GNU General Public License (GPL), this can also capture one's own code that is combined with the GPL component into a single program. How far this effect extends depends on the technical integration, for example whether the component is firmly inserted into one's own program or called as a separate program. For some constellations this is not conclusively settled in law.

Weak copyleft essentially limits the obligations to the component itself and its modifications. Under the GNU Lesser General Public License, one's own code remains free if it merely uses the library and recipients can replace it with a modified version. The Mozilla Public License attaches to individual files: modified files of the component stay open, one's own files do not.

Distribution and use over a network

The obligations of the GPL attach to the distribution of the software, for example delivering an app or installable software to customers. If the software is merely operated on one's own servers and offered to customers for use over the internet, there is, on a widespread understanding, no distribution within the meaning of the GPL. The GNU Affero General Public License (AGPL) extends the obligations to this case: anyone who makes a modified version of an AGPL program available to users over a network must offer them the source code of that version.

Obligations on distribution

In simplified terms: permissive licences require the author to be named; copyleft licences additionally require the source code to be shared. In detail, the following are customary on distribution:

• for all licences: supply the licence text and copyright notices, for example in an overview in the app or in the documentation, and for Apache 2.0 additionally a notice file supplied with the software,
• for copyleft: supply the source code of the component with all modifications or offer it in writing, and for the GPL also the source code of the program combined with it,
• for copyleft in addition: impose no further restrictions on recipients that contradict the licence.

Open source as a business model

Some companies deliberately publish their own software as open source in order to achieve distribution without sales effort. Revenue arises from operation as a managed online service, from paid additional functions for companies (open core) or from support contracts. A further form is dual licensing: customers acquire a commercial licence so as not to have to comply with the obligations of the copyleft licence. Here, investors examine above all the conversion of free users into paying customers. For dual licensing, the company needs the necessary rights of use in all of the code, including contributions from external developers, which presupposes contribution agreements (contributor licence agreements).

Review in due diligence

The basis is a software bill of materials, which lists all components in use with their version and licence. Reviewers create or check it with tools that automatically compare the code with known open source components. They pay particular attention to:

• copyleft components in delivered software, such as apps or installable products,
• AGPL components in services that customers use over the internet,
• missing copyright and licence notices, including for permissive licences,
• components without a recognisable licence or with known security vulnerabilities.

Most findings can be remedied, for example by replacing a component or adding missing notices. It becomes time-critical when a component is deeply anchored in the product and replacement takes months. For buyers and investors, what counts is therefore less the number of findings than whether a finding touches the business model, for example because a core part of the product would have to be disclosed.

Warranties in the purchase agreement

In the company purchase agreement and often also in the participation agreement, acquirers protect themselves through special warranties. Three assurances are customary:

• All open source components in use are disclosed in a schedule to the agreement (disclosure schedule).
• The licence terms of these components are complied with.
• No copyleft component triggers an obligation to disclose one's own source code.

Known findings, by contrast, are not dealt with through a warranty, because the purchase agreement as a rule excludes warranty claims for circumstances that the buyer knows about. Customary instead are a separate indemnity (indemnification), that is, the promise to compensate certain losses, or remediation before closing. Closing is the day on which the company actually passes.

Practical example

A provider of an online contract management service is sold to a financial investor. The software bill of materials comprises around 1,400 components. The review produces two findings:

• In the user interface, the required licence notices for several components under permissive licences are missing. The company adds them within a few days.
• A document conversion module is under the AGPL and was adapted by the development team. Because customers use the service over the internet, the company would have to offer the source code of the adapted version. The module is closely linked to the company's own core product, and it cannot be reliably delineated how much of the company's own code would be caught by the disclosure. The company therefore decides to replace it with a commercially licensed component, which the reviewers estimate will take four months.

The parties agree that the seller begins the replacement before closing. The remaining risk is secured through an indemnity and a retention from the purchase price on an escrow account, which is released only after replacement has been demonstrated. The first finding is a formality. The second does not prevent the sale but ties up part of the purchase price and could have been resolved without time pressure with a bill of materials maintained early on.

Distinctions from related terms

• Source available: licence models under which the source code can be viewed but use remains restricted, for example for operation as a service for third parties. They do not count as open source because they exclude certain uses.
• IP assignment: secures for the company the rights in code created for it. Open source licences, by contrast, govern the use of other parties' code.

Common mistakes

• No software bill of materials. Without a complete list, it cannot be demonstrated in due diligence which licence obligations exist.
• Review only before the sale. If licence questions are clarified only during an ongoing process, replacing a component is expensive and time-critical.
• Notice obligations overlooked. Permissive licences also require copyright and licence notices; if they are missing, the use is not fully licence-compliant.
• AGPL underestimated. Providers of online services often assume that copyleft does not affect them because there is no distribution. For adapted AGPL components, this is not the case.
• No internal rule. Without a list of permitted licences and licences requiring approval, each developer decides for himself or herself what gets built in.

Frequently asked questions

May a company use GPL software?

Yes. Purely internal use within the company triggers no disclosure obligation; even handing it over to another group company can, however, count as distribution. Obligations arise when GPL code is built into software that is passed on to customers and, under the AGPL, additionally when a modified version is offered over a network.

Must a company publish its source code if GPL code is found in the product?

Not necessarily. The licence permits distribution only under its conditions but does not force publication. The company can comply with the conditions or replace the component and stop distributing the affected version. For the past, claims by the rights holders remain possible.

Do open source findings reduce the purchase price?

Rarely directly. Most findings are remedied before closing or secured contractually. Buyers demand a discount mainly where replacement is costly and touches the business model.

Do customers also ask for a software bill of materials?

Increasingly yes, above all larger corporate customers and customers from regulated industries. They use the list to monitor licence risks and security vulnerabilities in purchased software.

How can licence compliance be secured permanently?

Through automated checks in the development process, a continuously maintained software bill of materials and a written rule on which licences may be used without approval.

The Roemer Capital view

At Roemer Capital, the software bill of materials belongs in the data room of a financing round or a sale before the first investor or buyer asks for it. Findings that become visible there can still be remedied calmly; in an ongoing process, only under time pressure and with concessions in the contract.

The licensing assessment of individual components is carried out by the client's law firm. Roemer Capital makes sure that technical findings, the effort for replacement and contractual protection are considered together, so that warranties, indemnities and timetable fit one another.