What are open-source licenses?

Open-source licenses: definition

Open source does not mean “free of rights.” Free software is also protected by copyright; the license grants usage rights and ties them to conditions. Software counts as open source if its source code is openly available and may be freely used, modified and passed on, as defined for example by the Open Source Initiative.

What matters is that the license applies to each component individually. A modern project often consists of dozens or hundreds of libraries, each with its own license. Anyone who creates or distributes software therefore needs to know which components are included and which conditions attach to them.

The main license types

Roughly speaking, permissive licenses, which impose few obligations, are distinguished from copyleft licenses, which require derivative works to be placed under the same license. The obligations generally apply only when the software is distributed, and under the AGPL also when it is provided over a network.

• MIT and BSD: very permissive, license text and copyright notice must be retained
• Apache 2.0: permissive, with a patent clause and a duty to mark changes
• LGPL and MPL 2.0: weak copyleft, changes to the library itself must be released
• GPL: strong copyleft, derivative works must be offered under the GPL when distributed
• AGPL: like the GPL, and additionally when used as an online service (SaaS)

Real-world example: industry software with a GPL library

A mid-sized software vendor delivers an industry solution to several customers. A developer has embedded a handy library that is licensed under the GPL. During a review by a customer, it turns out that the solution contains GPL code, but the source code of the vendor’s own product is not disclosed and a license notice is missing.

The vendor has two options: replace the library with a permissively licensed alternative, or comply with the license terms, which on distribution can entail disclosure. It decides to replace it, adds a license list to the product and from now on checks new components before integrating them.

Risks, limits and common mistakes

Open-source components are usually provided without warranty and liability. That is unproblematic if you plan for it, but it means security updates are your responsibility. Violating license terms can cause the right of use to lapse; injunctions and damages claims from the rights holders are possible.

Typical mistakes: licenses are not recorded, license texts are removed on delivery, GPL code is built into proprietary products, license changes in projects are overlooked, or restrictions on commercial use are not checked. Not every piece of software with visible source code is open source under a recognized license.

What companies should look out for

Keep an inventory of all components used, with version and license, for example as a software bill of materials (SBOM), and check new libraries before integrating them. Define internally which licenses are permitted. For commissioned development, the contract should say who performs the license review. Nano Concepts supports the documentation of the components and licenses used. This article does not replace legal advice.