The second of two main requirements put upon distributors of open-source code is to provide the corresponding source code of any copyleft-licensed code they distribute to recipients. If you are an end-user only, this does not apply to you.

To recapitulate: The copyleft obligation requires that any incoming open source code (of a license with a copyleft obligation) be distributed to third parties (like customers) only under the same license as the incoming license: The incoming license must be the outgoing license. If you don’t comply, you don’t receive the usage rights to the open source code.

The copyleft obligation only applies to so-called covered work and if the distribution conditions are triggered.

• Covered work. What is covered work, that is, affected code, is defined in the license using copyright law. Any code you write that taps into copyleft-licensed code by incorporating some of the copyrighted text (and be it interface symbols) is typically covered code. Then, any further code that taps into your code may also become covered code. This propagation is sometimes called a “viral effect” and is intentional.
• Obligation trigger. Distribution of the covered code to third-parties triggers the copyleft obligation. Before the advent of the web, this was easy: Distribution meant passing on binary code to recipients. Since the web and cloud services, new licenses have tried to frame the provision of software as a service as distribution, with mixed success. The most well-known cloud copyleft license is the AGPL-3.0 license family.

Your system’s architecture, how your code is coupled, and the specifics of the licenses therefore determine which of the code in a distribution is affected by the copyleft obligation of some copyleft-licensed code you are using. A simple example is a device you are selling, running Linux, with a user-space application. Linux is mostly covered by GPL-2.0 and hence you have to provide corresponding source code for the Linux-related code on your device. Your application is shielded from the copyleft obligation, because of the Linux Syscall Note, and hence you do not have to provide the corresponding source code to your customers.

Many open source licenses contain a copyleft obligation, sometimes weakened by exceptions like the Linux Syscall Note, sometimes unmitigated. Details vary, and you may sometimes believe you found a loophole in a license so that you could comply with the license by letter, but not in spirit. I generally advise not to go against the grain of a license, but to comply with its intentions.

The intention of a copyleft obligation is to empower recipients to enhance the software or to help themselves if something is wrong. To modify the software or a component, users typically need the source code for this component. If the component is covered by a copyleft license, you need to provide the source code for it and everything that is needed to put a replacement in place, including but not limited to custom tools, cryptographic keys, and necessary instructions. Only “standard software” i.e. off-the shelf tools can be omitted.

The comprehensiveness (tools, keys, etc.) was added only in more recent license generations, most notably the GPL-3.0 family. It was caused by vendors’ active attempts to work around the copyleft obligation, dubbed tivoization.

Recipients of corresponding source code generally expect one file, an archive, with all relevant files and information, prepared in a way that allows the recreation, modification, and deployment of the covered work.

The provision of corresponding source code does not necessarily require you to ship the source code with the binary code. Some licenses only require that you make an offer and maintain this offer for a defined period of time. However, if recipients ask for the source code, you have to comply. For this reason, you should create the corresponding source code together with the binary code and archive it, even if you don’t ship it.

Creating corresponding source code for old software versions is a difficult task and highly error-prone. The creation and archiving of corresponding source code should be part of your build processes. Then, if a recipient comes asking, you simply pull the code from the archive and provide it to the recipient.

Also, not everyone has a right to ask and receive, only recipients of the binary distribution do. However, because of the copyleft license, recipients have a right to put the source code they receive from you onto the web under the open source license. Hence, you might as well provide your corresponding source code on the web as well. To protect yourself from copyright trolls, you may want to password-protect access, though.

Past relationships between vendors and copyleft enthusiasts were often adversarial. These fights have calmed down, including a more amicable approach to remediation and license compliance.

© 2024 Dirk Riehle, used with permission.