2021

• Is Open Source Compliance Necessary Even When Providing a Service as SaaS?
• The Log4j 2 Security Vulnerability Incident (Log4Shell)
• NIPA Publishes Four Guides for Using Open Source Software
• China's First GPL Lawsuit Case: VirtualApp
• Does GPLv2 Also Require Installation Information?
• Distribution of Dockerfiles: Who Is Responsible for Compliance?
• What Is an OSPO?
• Elastic License 2.0 and the Evolution of Open Source Licensing
• Opensource license used by IT Companies

Is Open Source Compliance Necessary Even When Providing a Service as SaaS?

Most open source licenses place no restrictions on simply running the software, but they do require compliance with obligations such as source code disclosure and attribution when the open source is redistributed. Here, “distribution” generally means the physical delivery of software, such as selling an embedded device that carries the software or distributing a mobile app through an app market.

SaaS providers do not distribute software to deliver their service, so they can be relatively free of license obligations even when they use open source. However, some open source licenses, such as AGPL, impose license obligations even when a service is provided over a network, so care is needed there.

Heather Meeker, a well-known open source attorney in the United States, published a post titled Open Source Compliance for SaaS Vendors, explaining the open source compliance issues SaaS vendors need to watch for. Today I’d like to introduce this content.

1. Consider the software distributed to the client side.

Heather first discussed client-side software. On a SaaS platform, most of the software resides on the vendor’s server side, but some software is delivered to and runs on the user’s computer (“client-side”).

Heather used WordPress, which provides website-building functionality as SaaS, as an example. Suppose you access WordPress in the Chrome browser and open the screen for building a blog. If you press control-u there (Command + Option + U on a MacBook), you can view the page source code, and you’ll see roughly 3,000 lines of source code (of course, most of the source code that makes up the blog-writing functionality runs on WordPress.com’s servers).

This client-side code mainly consists of simple logic, such as checking whether values like a date or address entered into a web page’s input “form” are valid. There’s no need to spend time coordinating with the server for these small tasks. This client-side code is mostly “scripting language” code, typically HTML, JavaScript, and CSS. What’s notable here is that, as you can see in the browser, this script code is always delivered in source code form. So even if the code is under a copyleft license like LGPL, there’s no need to separately provide the source code.

How should notice content be provided?

Heather explains that the notice obligation still needs to be considered, and raises an issue. Developers, wanting to keep loading times fast, tend to keep only the minimal amount of open source HTML/CSS/JavaScript code, and because of this they often strip out the copyright and license notices in the code. But when distributing software under a copyleft license like LGPL, you must provide not only the source code but also the full license text.

LGPL-2.1

1. … and distribute a copy of this License along with the Library.

So how should the full text of the LGPL license be delivered while delivering LGPL-licensed JavaScript code to the client side?

One approach Heather suggests is to create a page for open source notices within a screen such as the SaaS system’s dashboard, and include a link there showing the full license text.

However, Heather also raises some doubt as to whether even this approach can be considered to fully satisfy the license conditions. In fact, most of the notice obligation clauses in open source licenses were written long before web services existed, and they only assumed the software delivery methods of that time — that the notice would be delivered together with the installation program.

MIT also requires the following.

MIT

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Given this clause, one could argue that providing the license notice on a separate web page within the SaaS system isn’t sufficient either. Of course, providing it this way is still much better than not providing it at all.

Is minified JavaScript an appropriate way to disclose source code?

Developers minimize the size of code delivered to the client side as much as possible in order to minimize the loading time. To do this, they remove unnecessary comments in the JavaScript code and also strip “white space,” among other minification steps.

<script id=’wp-media-utils-js-translations’>
	( function( domain, translations ) {
		var localeData = translations.locale_data[ domain ] || 
			translations.locale_data.messages;
		localeData[“”].domain = domain;
		wp.i18n.setLocaleData( localeData, domain );
	} )( “default”, { “locale_data”: { “messages”: { “”: {} } } } );
</script>

For example, minifying the code above converts it into the following, and readability naturally suffers.

<scriptid=’wp-media-utils-js-translations’>(function(domain,translations){varlocaleData=translations.locale_data[domain]||translations.locale_data.messages;localeData[“”].domain=domain;wp.i18n.setLocaleData(localeData,domain);})(“default”,{“locale_data”:{“messages”:{“”:{}}}});</script>

Now, open source licenses that require source code disclosure define “source code” as a form that is convenient to modify.

GPL-2.0

3. … The source code for a work means the preferred form of the work for making modifications to it.

Given that, if LGPL-licensed JavaScript code is minified while being delivered to the client side, can this be considered compliant with the source code provision obligation? Since a user would have difficulty modifying it while minified, shouldn’t a separately readable, unminified version of the code be provided?

On this point, Heather says it isn’t a problem, because most development tools automatically improve readability by inserting white space and the like, even for minified JavaScript code. In other words, she explained that delivering minified JavaScript code can also be regarded as “the preferred form of the work for making modifications,” which is what GPL and LGPL require as the definition of source code.

2. Watch out for network copyleft licenses.

Another potential issue Heather raises for SaaS is network copyleft licenses. Some open source licenses, such as AGPL, require disclosure of server-side source code when a user interacts with the software over a network, even without any physical distribution of the software. Heather calls these “network copyleft licenses.” AGPL-3.0, a representative network copyleft license, defines the obligation regarding remote network interaction in Section 13 as follows.

AGPL-3.0

13. Remote Network Interaction; Use with the GNU General Public License.

… if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

In other words, if AGPL software is used in the following two ways, you must provide the source code:

1. You modify the software, and
2. Users interact with the software over a network

One might then ask, isn’t it perfectly fine to just use it without modification? Even if a developer doesn’t modify it at first when introducing AGPL-3.0 open source, over time a situation may arise where modification becomes necessary. As time passes, some other developer may make modifications for functional, performance, or compatibility reasons, without taking the AGPL license into account. So while claiming “no one will modify this AGPL-3.0 open source, so there’s no need to worry about license compliance” may sound plausible for now, it can’t account for the possibility of future changes.

For reference, Google created an “AGPL Policy” to make clear that code under AGPL cannot be used at Google.

Google’s AGPL Policy

*WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits.*

Google explains that it created the AGPL Policy for the following reasons.

• AGPL requires that anything that links with AGPL software also be licensed under AGPL. (a “viral” effect)
• This viral effect is triggered not only when the software is distributed, but also when a user accesses a product or service through a remote network interface.
• Because Google’s core products (Search, Gmail, Maps, YouTube, etc.) are services that users interact with through a remote network interface, the situation becomes serious if engineers depend on AGPL software when developing such services.
• Given this, Google finds it very difficult to comply with AGPL’s requirements for software used over a network.

Heather explains that, besides AGPL-3.0, there are several other licenses that include network provisions like this.

• Server Side Public License
• Open Software License
• Non-Profit Open Source License
• Artistic 2.0
• Apple Public Source License
• RealNetworks Public Source License
• Reciprocal Public License
• Honest Public License
• Academic Free License [Note: this license is permissive. The others are copyleft.]

Heather says that most companies classify these network copyleft licenses as high-risk licenses and have a policy of not using them in SaaS development.

Actually, I used to think that since AGPL-3.0 only imposes the source disclosure obligation when the software has been modified, using it without modification should be fine. So my position was that there was no real need for a company to have a policy specifically banning the use of AGPL-3.0. But when I consider whether a company actually has systems in place internally to guarantee that the software won’t be modified even years down the line, even if it isn’t modified when it’s first introduced, I can no longer be so sure it won’t ever be modified. So, like Google, I think it’s reasonable, from a license management perspective, to adopt a default policy that restricts the use of AGPL-3.0 open source.

3. Consider that SaaS code may need to be distributed someday.

Heather says that because the server-side code of a SaaS platform is also almost always distributed at some point eventually, open source compliance needs to be considered for the server-side code as well. Situations where SaaS code ends up being distributed include the following.

• Sale of the organization responsible for the SaaS
• Migration of the SaaS server to a customer’s server
  • Server migration due to requirements from heavily regulated industries such as finance or health
  • Server migration due to security issues
  • Server migration to prevent privacy problems arising from cross-border data movement, etc.
• Productization of an internal SaaS tool, etc.

Considering that such situations can arise, Heather explains that even when developing a SaaS service, companies should avoid combining GPL or AGPL open source with their own proprietary code, in anticipation of possible future distribution.

Some may see this as an overly cautious policy, but I think it’s an argument well worth considering. In particular, given the recent trend of open source commonly used on servers changing its license, establishing a system to identify and manage the Software Bill of Materials even for server-side programs is becoming an essential process for companies.

In the past, some companies’ open source compliance policies excluded open source used only on internal servers, without external distribution, from open source review altogether. However, given (1) open source licenses with network copyleft clauses such as AGPL, and (2) the trend of software changing its license from open source to a commercial software license, a management system for license compliance is becoming necessary for server-side software as well. Companies will need to improve their policies and processes for this, and adopt tools that can automatically generate a Bill of Materials for server-side software.

The Log4j 2 Security Vulnerability Incident (Log4Shell)

A vulnerability in Apache Log4j 2 (CVE-2021-44228, NVD) could lead to further damage such as malware infection, prompting urgent security update measures worldwide (2021.12.10). This post summarizes the related details.

Log4j

Log4j is an open source project from the Apache Software Foundation, used for logging purposes in most Java-based web services.

Timeline

• 2021.11.24 First discovered by the Alibaba Cloud security team (Apache announcement)
• 2021.11.30 The Log4j team opened the pull request Restrict LDAP access via JNDI (merged 12/5)
• 2021.11.30 The Log4j team opened the pull request no longer formats lookups in messages by default (merged 12/5)
• 2021.12.09 The issue began to spread after a tweet posted the Log4j 2 security PR along with a screenshot reproducing the vulnerability
• 2021.12.10 The issue gained widespread attention after Minecraft’s technical lead announced via tweet that the issue had been fixed
• 2021.12.10 The security vulnerability was patched with the release of Log4j 2.15.0
• 2021.12.12 The Log4j team added Disable JNDI by default
• 2021.12.12 Log4j 2.15.1 release candidate (JNDI disabled by default)

Press Coverage (Korea)

• 2021.12.11 “Worst vulnerability in the history of computing found” — global security industry stunned
• 2021.12.11 Worst-ever ‘Log4j’ security flaw discovered, threatening nearly every server
• 2021.12.11 Following reports of “the worst vulnerability in the history of computing,” the National Intelligence Service says it has “taken preemptive measures”
• 2021.12.12 Ministry of Science and ICT recommends urgent security measures for the “critically vulnerable” open source project Log4j
• 2021.12.12 “The worst security flaw” — the IT industry thrown into turmoil
• 2021.12.12 Electronic Times: damage is hard to assess — software details need to be identified
• 2021.12.12 ‘Emergency response team’ activated amid concerns over IT server hacking
• For coverage outside Korea, search for “Log4Shell”

Response Measures

• Security advisories/notices related to Log4Shell (CVE-2021-44228)
• 2021.12.06 Apache notice on 2.15.0 regarding CVE-2021-44228
• 2021.12.10 Spring, Log4J2 Vulnerability and Spring Boot
• 2021.12.11 KISA (Korea Internet & Security Agency), advisory on the Apache Log4j 2 security update
• 2021.12.12 Ministry of Science and ICT, urgent security patch recommendation for Apache Log4j 2 web services (the guidance is the same as above)

Response Examples (Reference)

• 2021.12.10 AWS, Apache Log4j2 Issue
• 2021.12.11 How Cloudflare Security responded to the Log4j 2 vulnerability

Scope of Impact

• Log4j versions from 2.0-beta9 up to (but not including) 2.15.x

• Regarding Spring Boot

  • Spring Boot defaults to a different logging library, Logback, and is affected by the vulnerability only
    if the default logging system has been switched to Log4j2.
  • As of 2021.12.12, in Spring Boot 2.6.1 (the latest version at the time), switching to Log4j2 without specifying a version installs 1.14.1
  • Spring Boot 2.6.2, not yet released at the time, was planned to update to Log4j 2.15.x

Known Vulnerability Scanners

• Labrador Log4Shell code-level inspection tool (jointly developed by Labrador Labs and the Korea University Security Research Institute)

• Huntress Log4Shell Testing Application

• Labrador Log4Shell test

  • (Step 1) Scan via package management, then (Step 2) scan Jar files
  • Tested using a Spring Boot 2.6.1 sample project (GitHub) (create your own)
    $java -jar LabradorLog4ShellDetector.jar -project [path]
  • Scanning the default Spring project: no vulnerability found
  • After switching the logging system to Log4j2

Attack Method

• Log4Shell is classified as an RCE (Remote Code Execution) vulnerability.
• It carries the risk of zero-day attacks (attacks that exploit a publicly disclosed but not yet patched security vulnerability).
• See here for details Image source

Government Considers Surveying Open Source Usage

The government is also considering ways to raise the security level of open source software. A Ministry of Science and ICT official said, “Because there is so much open source in use, similar incidents are likely to occur again,” and added, “we are considering follow-up measures, including a usage survey.”

(excerpted from this article)

NIPA Publishes Four Guides for Using Open Source Software

NIPA has published four guides for using open source software. (Source: https://www.oss.kr/news/show/ef0900db-f5b4-40fb-8745-f1b937fbd8d0)

The four open source software guides cover the following. The Corporate Open Source Software Governance Guide was co-authored by current OpenChain KWG steering committee members Haksung Jang, Seoyeon Lee, and Minho Hwang.

Open Source Software License Guide (Revised Edition)

Download the Open Source Software License Guide

Covers an overview and introduction to open source software licenses, how to comply with license obligations, copyright and patent considerations, license-related checklists, management approaches, notable dispute cases, and frequently asked questions, organized so the core content applicable to a company or organization can be identified and used across a range of situations.

The Open Source Software License Guide gives developers and managers at companies and organizations an easier way to understand the general concepts and key compliance requirements of open source licenses, and provides guidance on the matters they need to review to apply that understanding in practice. It is organized into: open source software concepts and definitions; open source license concepts and obligations; copyright and patent issues in open source software; open source license compatibility and dual licensing; open source license checklists by distribution method; open source license management; open source license dispute cases; and support available for open source license matters. Because the obligations a user must review and apply differ depending on the license, the mode of use, and the distribution method even when using the same open source software, this guide also offers separate tips for each section to help readers identify the content that matters most for their own company or organization and apply it across different situations.

Public Sector Open Source Software Governance Guide

Download the Public Sector Open Source Software Governance Guide

Provides the relevant laws and guidelines, and the considerations and checkpoints to review, at each stage of a public-sector IT project when using open source software: planning, plan development, vendor selection and contracting, project execution, inspection and operation, and performance evaluation.

The Public Sector Open Source Software Governance Guide reflects an analysis of domestic and international open source policy and technology trends, and provides the laws and guidelines that must be checked, along with practical information and approaches, for using and managing open source software when carrying out an IT project in the domestic public sector. Each chapter covers the need for open source software management in IT projects and how to manage open source software in IT projects. The section on the need for management introduces the open source policies and use cases of governments at home and abroad, organizes the relevant laws, guidelines, and commentaries for IT projects, and explains the provisions relevant to open source software management. The section on managing open source software in IT projects introduces a basic management and review process for each stage — planning, plan development, vendor selection and contracting, project execution, inspection and operation, and performance evaluation — provides a list of guidelines and commentaries practitioners can reference at each stage, and offers management factors and review items for checking open source software management.

Corporate Open Source Software Governance Guide

Download the Corporate Open Source Software Governance Guide

Explains three cases of using open source software in enterprise software development and delivery — use, contribution, and release — in a way practitioners can apply directly, and closes with guidance on the organizational structure a company needs for open source software governance.

As companies increasingly develop and release software products and services built on open source software, the Corporate Open Source Software Governance Guide provides the guidance needed to establish open source software governance — covering source code management and supply policy, compliance processes, management tools, and organizational structure — as well as how a company can contribute to and release into the community. Each chapter covers using open source software, contributing to open source software, releasing open source software, and the OSPO (Open Source Program Office). Each topic is explained separately from the perspective of the company and of the developer to aid understanding. The company section focuses on what an open source software manager needs to know to establish policy and process, while the developer section explains what a developer at a company needs to use open source software.

Open OS Adoption Guide

Download the Open OS Adoption Guide

Introduces open operating systems for transitioning office PCs, their types, the adoption process and scope, ongoing maintenance, and case studies, giving practitioners a guide to the overall project plan when considering adoption of an open OS.

The Open OS Adoption Guide addresses the policy of expanding open OS adoption, a topic under active discussion domestically as part of open source software policy, and helps institutions considering adoption understand open operating systems, drawing on real adoption cases to make the guide useful throughout the review and implementation process. Each chapter covers an overview of open OS; open OS adoption case studies; matters to review before adopting an open OS; the project procurement process for adopting an open OS; the open OS maintenance process; and how to use this guide. Drawing on a range of reference models and cases for open OS adoption, it offers guidance on the overall project plan and the procedures and considerations practitioners need when reviewing adoption of an open OS.

China's First GPL Lawsuit Case: VirtualApp

Hello, this is Haksung Jang.

In September 2021, it was reported through a Chinese news article that the first GPL-related ruling in China had been handed down. I’ve summarized what I understood of it using a translation tool. Please keep in mind that, since I’m not a lawyer and don’t know Chinese, there may be errors in the content. :) If you find any errors, I’d be grateful if you’d let me know at any time (haksung@sk.com).

(Thanks to Jin-Young Choi, Center Director at the Korea Copyright Commission, for helping review this. ^^)

Summary

In April 2021, a first-instance civil ruling was handed down in China in a copyright infringement dispute. The ruling found that, because the defendant used code the plaintiff had released under GPL-3.0 without complying with GPL-3.0’s obligations, the license rights granted by GPL-3.0 had terminated, and this constituted infringement. The court confirmed the infringement and ordered the defendant to pay damages of RMB 500,000 (about KRW 100 million).

Parties to the Dispute

The plaintiff, the defendants, and the software at issue in this dispute are as follows.

Plaintiff

The plaintiff is Jining Luohe Network Technology Co., Ltd, the copyright holder of VirtualApp.

Defendants

There are three defendant companies in total.

1. Fujian Fengling Chuangjing Technology Co., Ltd.
   • Copyright holder of Dim Sum Desktop
   • Operates the official Dim Sum Desktop website
2. Beijing Fengling Chuangjing Technology Co., Ltd. (parent company of Fujian Fengling)
   • Listed as the developer of Dim Sum Desktop
3. Shenzhen Tencent Computer System Co., Ltd.
   • Operates “Application Bao” (a service for downloading, installing, and running Dim Sum Desktop)

Software at Issue

1. VirtualApp (plaintiff’s software)

The plaintiff developed and distributed VirtualApp, software that provides a virtual Android environment.

• Gitee: https://gitee.com/mirrors/VirtualApp
• GitHub: https://github.com/asLody/VirtualApp

Let’s take a closer look at the history.

1. Lody, one of the plaintiff company’s founders and the original contributor of VirtualApp, published VirtualApp on GitHub on July 7, 2016.
2. On July 8, 2016, LGPL-3.0 was applied, and
3. On August 12, 2016, the license was changed to GPL-3.0.
   • Looking at the code at that point in time, you can confirm that a copy of the GPL-3.0 license was included in the repository, and the license information in the README also explicitly stated “GPL-3.0”.
4. Then, on January 24, 2017, a notice was suddenly added stating “you do not have permission to use this project for free”.
   • After that, from March through July 2017, notices stating that a commercial license was required to use this project commercially were added repeatedly on several occasions.
   • Regarding this change in licensing policy, one Chinese attorney speculated that Lody had initially released VirtualApp for free under an open source license during early development, but later changed his mind and decided to try to profit from it.
   • However, adding conditions like this to open source software already released under GPL is not permitted under GPL, and the Chinese attorney noted that Lody appeared to have attempted a licensing policy that violated GPL-3.0 because he didn’t fully understand open source licensing.
5. In August 2017, Lody founded VirtualApp (the plaintiff). In other words, he was now formally going into business with VirtualApp.
6. And Lody ultimately removed the open source license from GitHub on October 29, 2017.
   • https://github.com/asLody/VirtualApp/commit/00f152f98a922ced0d858c31e1a9c2f0afb53ab6
     
7. On November 8, 2017, the plaintiff registered a software copyright for VirtualApp v1.0, obtained a registration certificate, and sought to hold all rights to the software copyright.
8. On December 30, 2017, the plaintiff announced that a commercial license must be purchased in order to use VirtualApp commercially, as shown below, and after that no longer updated the source code in the GitHub repo.

"VirtualApp (Chinese name: Luo box) was formally established in August 2017.
If you need to use VirtualApp for commercial purposes, please
contact QQ: 10890 to purchase a commercial license.
If you use VirtualApp's code as your own code for commercial gain or internal use,
or upload it to a software marketplace without authorization,
we will directly report this to the police (copyright infringement),
resulting in legal action and criminal liability for your company."

For reference, Lody was the primary contributor to VirtualApp, with about 30 additional developers contributing afterward.

2. Dim Sum Desktop (defendant’s software)

Like VirtualApp, Dim Sum Desktop is software that provides a virtual Android environment, and it was developed by defendant Fujian Fengling Chuangjing Technology Co., Ltd.

While developing Dim Sum Desktop, the defendant obtained and included the August 16, 2017 version of VirtualApp published on GitHub. This version was under GPL-3.0 while also (inconsistently) including language prohibiting commercial use.

In September 2018, the plaintiff confirmed that “Dim Sum Desktop v6.5.8” was using code from VirtualApp V1.0.

• Of 421 comparable pieces of code between the two programs, the following similarities were found.
  • 308 codes - substantial similarity
  • 27 codes - high similarity
  • 78 codes - general similarity

Relief Sought

In 2019, the plaintiff filed suit seeking the following relief.

1. Defendants Fujian Fengling Company and Beijing Fengling Company shall immediately cease infringing the plaintiff’s computer software copyright.
   • That is, they must immediately stop providing all services for downloading, installing, and running any version of the “Dim Sum Desktop” software over the internet.
2. Defendants Fujian Fengling Company and Beijing Fengling Company shall pay the plaintiff RMB 20 million in economic damages.
3. Defendants Fujian Fengling Company and Beijing Fengling Company shall compensate the plaintiff for a reasonable fee of RMB 500,000 for the infringement _{compensate the plaintiff for a reasonable fee of 500,000 yuan for stopping the infringement}.
4. Defendants Fujian Fengling Company and Beijing Fengling Company shall bear the litigation costs of this case.

Court Ruling

In April 2021, the court ruled that this case was a dispute concerning copyright infringement of computer software and involved issues related to open source, and offered its opinion on the following issues.

Issue 1. Whether GPL-3.0 has legal effect

The court determined that GPL-3.0 has a contractual nature and can be regarded as a copyright agreement between the licensor and the user, and that it falls within the scope of adjustment of China’s “Contract Law”. It further explained tort liability for GPL-3.0 violations as follows.

Tort liability for violation of GPL-3.0

• Copyright law protects the exclusive rights of the copyright holder.
  • The rights of reproduction, modification, and distribution belong solely to the copyright holder (anyone other than the copyright holder may only use the work within the scope of “fair use”).
  • Anyone who performs these acts without permission commits infringement.
• GPL-3.0 8. Termination
  • If the terms of use of GPL-3.0 are violated, the rights obtained through GPL-3.0 are automatically terminated.
  • “You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License”
• Article 158 of the General Provisions of the Civil Law of China
  • Provides that “a civil juristic act may have conditions attached… a civil juristic act with a condition subsequent becomes void once the condition is fulfilled.”
• Given the nature of open source software, the conditions of use specified in GPL-3.0 (source code disclosure, copyright/modification notices, etc.) are a precondition set by the licensor for allowing the user to use the software.
  • If the user violates this precondition of use, the GPL-3.0 agreement between the licensor and the user is automatically terminated.
  • The user’s license under the contract is immediately terminated.
  • Any subsequent acts of reproduction, modification, or distribution performed by the user constitute infringement due to the loss of rights.

Issue 2. Whether the plaintiff has standing to bring this lawsuit

The court did not clearly explain the nature of ownership (e.g., sole work, joint work, combined work) of a work created by multiple contributors on GitHub. However, it determined that, because the plaintiff registered a copyright for VirtualApp and for other reasons, the plaintiff holds the copyright and has the right to bring suit without the consent of other contributors.

1. Based on the upload records and authentication history on the code hosting website, it can be proven that the plaintiff is the copyright holder of VirtualApp.
2. The plaintiff has the right to bring suit without the consent or approval of contributors.
   • Lody, a shareholder of the plaintiff, published a total of 31,097 lines of the initial version of VirtualApp’s source code on GitHub as the project owner, which forms the basis of the plaintiff’s claim.
   • Contributors uploaded their own source code to the VirtualApp project and granted a license under GPL-3.0.
     • This is regarded as their consent to grant a license for their contributions to the project owner and other users.
   • If unanimous consent or approval from all contributors were required, it would in practice be impossible even to begin taking rights-protection measures. This would not help protect the litigation rights of open source projects.
   • In other words, the plaintiff does not need the consent or approval of contributors in order to initiate the lawsuit.
3. GPL-3.0 only restricts the licensor from asserting patent rights against the user; it does not restrict the licensor from asserting copyright claims against a user who violates the license agreement.
   • Therefore, the plaintiff’s lawsuit can be seen as not violating the GPL-3.0 agreement regarding dispute resolution methods.

However, the court did not rule on whether the plaintiff has the right to relicense VirtualApp. Nor did it rule on the question of whether relicensing, by including contributions from other contributors, tainted GPL-3.0.

Issue 3. Whether the defendant’s conduct infringed the plaintiff’s copyright

The court pointed out that VirtualApp’s “prohibition on commercial use” clause violates GPL-3.0 (Section 7, Additional Terms; Section 10, Automatic Licensing of Downstream Recipients), and determined that the GPL-3.0 license still takes precedence.

1. The plaintiff split VirtualApp into an open source version and a commercial version, and removed the “GPL-3.0” license from subsequent open source versions.
   • Separately from this, the plaintiff asserted its rights based on the open source version of VirtualApp. Therefore, there is no need to determine the relationship and effect between VirtualApp’s open source version and commercial version.
   • Under GPL-3.0, files bound by GPL-3.0 in an earlier version remain bound by GPL-3.0 even in subsequent versions.
2. GPL-3.0 allows users to make commercial use, and the licensor cannot restrict this.
   • Accordingly, the court did not support the plaintiff’s following argument: “Is commercializing Dim Sum Desktop a violation of GPL-3.0?”
3. Although the “Dim Sum Desktop” app (V6.5.8) was required to freely disclose its source code under GPL-3.0, defendant Fujian Fengling Company failed to comply with this.
   • Accordingly, under Section 8 of GPL-3.0 and Article 158 of the General Provisions of the Civil Law of China, the rights obtained by defendant Fujian Fengling Company were automatically terminated.
   • Therefore, defendant Fujian Fengling Company’s copying, modification, and distribution of VirtualApp constitute infringement due to the loss of the source of its rights.

However, the court made no mention of the “license reinstatement clause” of Section 8 of GPL-3.0 (which permanently reinstates the license if this is the first time the copyright holder has notified the violator of a violation, and the violation is cured within 30 days of receiving the notice). A Chinese attorney raised questions such as “Did the plaintiff notify the defendant of the violation beforehand?”, “Did the plaintiff file suit directly without prior notice?”, and “If so, does the opportunity for ‘permanent reinstatement of the license upon cure within 30 days’ still remain available?” (Shouldn’t filing the lawsuit itself be regarded as constituting notice?)

Issue 4. Scope of the defendant’s legal liability upon confirmation of infringement

The plaintiff requested that damages be calculated based on the defendant’s profits. However, the court appears to have determined the damages based on statutory damages.

• As the developer, operator, and publisher of the “Dim Sum Desktop” app (V6.5.8), defendant Fujian Fengling Company is liable under law to cease its infringement of VirtualApp’s copyright.
  • Given that defendant Fujian Fengling Company is a wholly owned subsidiary of defendant Beijing Fengling Company, the plaintiff’s claim that the two defendants jointly bear tort liability is lawful and is supported by the court.
• Defendant Tencent established relevant rules and a complaint channel for potential infringement on the “AppBao official website” and promptly removed the accused software upon complaint.
  • The plaintiff also did not file any specific complaint against defendant Tencent.
  • Accordingly, defendant Tencent is not required to bear legal liability.
• Compensation issue
  • The plaintiff claimed that it calculated damages based on the infringement profits of defendants Fujian Fengling Company and Beijing Fengling Company.
  • The court set the damages amount at RMB 500,000.

RMB 500,000 is reportedly close to the maximum level of statutory damages for copyright infringement.

Closing Thoughts

There has long been a perception that China is lenient toward violations of copyright law, so it was striking that the court recognized the legal effect of an English-language open source license and ruled that a license violation constituted copyright infringement. Companies need policies and processes in place to comply with open source license obligations in order to minimize the risk of getting caught up in disputes like this.

It is reported that the defendant has appealed the case to the Supreme Court. I’m curious to see what arguments the defendant will make on appeal. :)

Does GPLv2 Also Require Installation Information?

Hello.

P. McCoy Smith, a well-known open source license attorney in the United States, recently published an article titled Does GPLv2 Require ‘Installation Information’ in JOLTS (Journal of Open Law, Technology & Society) (JOLTS).

In March 2021, the SFC (Software Freedom Conservancy) (SFC) blog published a post titled “Understanding Installation Requirements in GPLv2,” arguing that GPLv2 also requires the provision of installation information. This article analyzes that claim and explains, with detailed grounds, the view that GPLv3’s ‘Installation Information’ requirement does not apply to GPLv2.

This translation renders the original text while adding background explanations wherever possible to improve readability and help readers understand the content.

If you find any errors or have additional comments, please feel free to contact me at haksung@sk.com.

Thank you. :)

Abstract

One of the key features added in GPLv3 (GNU General Public License version 3) is the requirement to provide ‘Installation Information’ in addition to source code when distributing software. This was newly added to GPLv3 to address a loophole in GPLv2 (Tivoization). Recently, however, a claim has been raised that this installation information requirement should be considered to apply to GPLv2 as well.

This article reviews the historical basis for including the ‘Installation Information’ requirement in GPLv3 and explains that this requirement is newly applied in GPLv3, not GPLv2. It also arrives at the same conclusion through an analysis of the GPLv2 text.

1. Introduction

GPLv2 (GNU General Public License, version 2)¹, released by the FSF (Free Software Foundation) in 1991, adopted a Copyleft (or Reciprocal) licensing approach. The Copyleft approach requires disclosure of source code in a specified manner at a specified time, and requires the same license to be applied when the software is redistributed. This is considered the best means of ensuring that software remains “free,” a view still widely held today². Here, “free” means the following³.

• The freedom to share modifications
• The freedom regarding what users can do with the code
• The freedom for users to modify the code as they wish

Nevertheless, in 2005 the FSF recognized the need to revise the license to address legal⁴ and technical⁵ issues that had not been considered⁶ when GPLv2 was released. Accordingly, the FSF began a large-scale, multinational collaborative effort from 2006⁷ through 2007 to create a new version of the GPL, and released GPLv3 on June 29, 2007⁸.

2. GPLv3’s ‘Installation Information’ Requirement

GPLv3 added numerous features to address the problems and concerns raised during the 15 years GPLv2 was in widespread use. Among these, the most notable (and also most controversial⁹) are (1) the provision defining ‘Installation Information’ and (2) the provision specifying the circumstances under which installation information must be provided when ‘conveying’¹⁰ software licensed under GPLv3. Understanding the extent to which GPLv3’s ‘Installation Information’ requirement includes, and does not include, elements required under GPLv2 requires a detailed review of the language and history of both licenses.

GPLv3, Section 6¹¹ (which specifies the obligations that apply when GPLv3 code is “conveyed in Non-Source Form”) defines the disclosure obligations specific to ‘Installation Information’.

“‘Installation Information’ ... means any methods, procedures, authorization keys, or other 
information required to install and execute modified versions of a covered work ... from a 
modified version of its Corresponding Source. The information must suffice to ensure that the 
continued functioning of the modified object code is in no case prevented or interfered with 
solely because modification has been made.”

What is notable about GPLv3’s definition of ‘Installation Information’ is that it specifically mentions ‘authorization keys’ and ‘other information’. This was included to address specific instances of abuse of GPLv2 software that concerned the FSF when the process of creating GPLv3 began¹².

The detailed requirements of GPLv3’s ‘Installation Information’ obligation, and how and when GPLv3 requires the provision of installation information, are beyond the scope of this article¹³. Nevertheless, a general understanding is needed of what similarities might support the argument that the installation information obligation also applies to GPLv2, what evidence demonstrates that the installation information obligation is unique to GPLv3, and through what process this content came to be adopted. It is therefore important to understand the historical background behind the addition of the ‘Installation Information’ obligation to GPLv3, the specific language added to GPLv3, and how that language differs from the obligations stated in GPLv2.

3. Historical Background of the ‘Installation Information’ Requirement: ‘Tivoization’

Around 2006, when GPLv3, the new version of the GPL, was proposed, the FSF expressed concern about a practice that could potentially undermine the concept of ‘software freedom’. The FSF named this practice ‘Tivoization’¹⁴, and at the time, the FSF considered that TiVo, a DVR (digital video recorder) company, was infringing on users’ freedom.

In the mid-2000s, certain TiVo DVR hardware devices had a GPLv2-licensed Linux kernel installed. These devices included a mechanism to verify the version of the Linux kernel to be installed on the TiVo hardware device. This validation mechanism used a checksum or cryptographic hash function to compare against the kernel version installed on the device, and refused to install any version of the Linux kernel whose checksum or cryptographic hash¹⁵ did not match a specific value. In this way, TiVo devices allowed only TiVo — as the hardware manufacturer and the sole party with the necessary information about the embedded checksum or hash value — to install authorized versions of the Linux kernel on the device. If a user of a TiVo device (e.g., a customer who purchased the device) obtained the source code of the kernel installed on the device, modified that kernel, and tried to reinstall it, the checksum or hash would differ for the modified kernel, so the modified kernel could not be reinstalled or executed¹⁶.

Accordingly, in 2006 the FSF considered the inability to reinstall a modified version of GPLv2 software on an existing device to be an infringement of the freedom users should have over software, and did not hesitate to describe this practice in highly disparaging terms.

      “A tyrant is a malicious device that refuses to allow users to install a different operating system or a modified operating system. These devices have measures to block execution of anything other than the ‘approved’ system versions.”¹⁷

4. Historical Analysis: The Relationship Between GPLv3’s ‘Installation Information’ Obligation and GPLv2

Although the FSF had long opposed the practice of ‘Tivoization’ (preventing the reinstallation of modified binaries), during the drafting of GPLv3, statements by the FSF’s President, General Counsel, and Executive Director also made clear that this practice could be permitted under GPLv2.

      “[T]he Tivo itself is the prototype of [T]ivoisation. The Tivo contains a small GNU/Linux operating system, thus, several programs under the GNU GPL[v2]. And, as far as I know, the Tivo company does obey GPL version 2. … [T]he trouble begins because the Tivo will not run modified versions, the Tivo contains hardware designed to detect that the software has been changed and shuts down.”¹⁸

      “TiVo is a provider of hardware and software …. Our concern with them is that they have rights as users, but they should respect the rights of the users to whom they sell. Having a personal video recorder … which won’t run software if you modify the box … is not user-respecting conduct. (TiVo) complied with GPL 2 by the skin of its teeth.”¹⁹

      “TiVoization is described by Peter Brown [Executive Director of FSF in 2006-07 during drafting of GPLv3] as circumventing GPL2 ‘in spirit, not technically.’”²⁰

This difference (between GPLv3, which prohibits ‘Tivoization’, and GPLv2, which permits it) was the decisive reason why Linus Torvalds, the author of the Linux kernel, decided not to change the license to GPLv3 and to keep it ‘GPLv2 only’.

      “’The FSF is trying to make some things no longer permissible under the GPLv3 that the GPLv2 left open, and I just happen to think that those things were better off being left open.’”²¹

      “‘I don’t think the GPL v3 conversion is going to happen for the kernel, since I personally don’t want to convert any of my code.’ … ‘I think it’s insane to require people to make their private signing keys available, for example. I wouldn’t do it,’ [Torvalds] said.”²²

      “[If] you can not install or run your changes on somebody else’s hardware … it in no way changes the fact that you got all the source code, and you can make changes (and use their changes) to it. That requirement has always been there, even with plain GPLv2. You have the source. The difference? The hardware may only run signed kernels. The fact that the hardware is closed is a hardware license issue. Not a software license issue. I’d suggest you take it up with your hardware vendor, and quite possibly just decide to not buy the hardware. Vote with your feet. … [I]t’s important to realize that signed kernels that you can’t run in modified form under certain circumstances is not at all a bad idea in many cases.”²³

Several major kernel developers also shared Torvalds’s view on GPLv3’s ‘Installation Information’ requirement, as shown below²⁴. Torvalds maintained a consistent position even a decade later, which is one of the reasons the Linux kernel continues to maintain a ‘GPLv2 only’ license to this day²⁵.

      “I give you source code, you give me your changes back; we’re even. … That’s my take on GPL version 2 and it’s that simple. … Version 3 extended that in ways that I personally am really uncomfortable with. Namely I give you source code, that means if you use that source code, you can’t use it on your device unless you follow my rules. And to me that’s a violation of everything version 2 stood for. And I understand why the FSF did it, because I know what the FSF wants, but to me it’s not the same license at all. So I was very upset, and made it very clear, and this was months before version 3 was actually published.”²⁶

In the process of creating and releasing GPLv3, the FSF made clear that, unlike GPLv2, GPLv3 was adding content that could prevent ‘Tivoization’.

      “There are several primary areas where version 3 is different from version 2. One is in regard to [T]ivoisation."²⁷

      “The Tivo includes some GPL-covered software. …[Y]ou can get the source code for that, as required by the GPL … and once you get the source code, you can modify it, and there are ways to install the modified software in your Tivo and if you do that, it won’t run, period. Because, it does a check sum of the software and it verifies that it’s a version from them and if it’s your version, it won’t run at all. So this is what we are forbidding, with the text we have written for GPL version three. It says that the source code they must give you includes whatever signature keys, or codes that are necessary to make your modified version run.”²⁸

The FSF has made clear (consistently from when GPLv3 was first proposed to the day this article was published) that GPLv3 in fact contains a definition of the ‘Installation Information’ requirement that is broader than any requirement contained in GPLv2.

      “GPLv2 did not address the use of technical measures to take back the rights that … GPL[v2] granted, because such measures did not exist in 1991 [when GPLv2 was written], and would have been irrelevant to the forms in which software was then delivered to users. … GPLv3 must address these issues: free software is ever more widely embedded in devices that impose technical limitations on the user’s freedom to change it.”²⁹

      “Does GPLv2 have a requirement about delivering installation information?…

      “GPLv3 explicitly requires redistribution to include the full necessary ‘Installation Information.’ GPLv2 doesn’t use that term, but it does require redistribution to include scripts used to control compilation and installation of the executable with the complete and corresponding source code. This covers part, but not all, of what GPLv3 calls ‘Installation Information.’ Thus, GPLv3’s requirement about installation information is stronger.”³⁰

Richard Stallman appealed to software developers to “upgrade” their licensing policy to GPLv3 to address the existing problems with GPLv2, and cited the newly introduced installation information requirement as the first reason developers should switch to GPLv3.

      ““Keeping a program under GPLv2 won’t create problems. The reason to migrate is because of the existing problems which GPLv3 will address.

      “One major danger that GPLv3 will block is tivoization. Tivoization means computers (called “appliances”) contain GPL-covered software that you can’t change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer thinks lots of people won’t like. The manufacturers of these computers take advantage of the freedom that free software provides, but they don’t let you do likewise.³¹

5. GPLv2’s Source Code Disclosure Obligation

One of the most notable features of a Copyleft license such as GPLv2, released in 1991, is that any individual or entity that distributes³² code licensed under the terms of GPLv2 has an obligation to provide the ‘source code’³³. GPLv2’s Section 3 specifically defines the components of ‘source code’ that must be provided when code under GPLv2 is distributed in object or executable code form³⁴.

“The source code for a work means the preferred form of the work for making modifications to it.
For an executable work, complete source code means all the source code for all modules it 
contains, plus any associated interface definition files, plus the scripts used to control 
compilation and installation of the executable.”

The explanation of the obligation to provide source code can generally be understood in connection with common knowledge of what ‘source code’ means in computer programming.

      “Source Code: … The form in which a computer program (software) is written by the programmer. Source code is written in some formal programming language which can be compiled automatically into object code or machine code or executed by an interpreter.”³⁵

GPLv2 also includes two other items that fall within the license’s definition of ‘source code’.

• ‘associated interface definition files’
• ‘scripts used to control compilation and installation of the executable’

To understand how GPLv2’s disclosure obligation differs from GPLv3’s disclosure obligation, it is necessary to review the meaning of these provisions.

6. Textual Analysis: GPLv3’s ‘Installation Information’ Obligation and GPLv2’s Source Code Obligation

As discussed above, GPLv3’s disclosure obligation for distributing executable code includes both ‘Corresponding Source’³⁶ and ‘Installation Information’³⁷.

“[A]ll the source code needed to generate, install, and (for an executable work) run the object 
code and to modify the work, including scripts to control those activities.”

“[A]ny methods, procedures, authorization keys, or other information required to install and 
execute modified versions of a covered work ... from a modified version of its Corresponding 
Source.”

GPLv3’s original draft included the obligation to provide authorization keys within the definition of “Corresponding Source”³⁸. However, there was opposition to defining data such as authorization keys together with source code, and accordingly the FSF moved the authorization key requirement to a different section.

      “We have moved the technical restrictions provisions from section 1, where they formed part of the definition of Corresponding Source, to section 6, where they are presented as a condition on the right to convey object code works. Some critics of the provisions in our earlier drafts focused on what they regarded as an inappropriate equation of cryptographic keys with source code. Placing the requirements in section 6 should make their purpose and reasonableness more evident.”³⁹

Thus, during the draft revision stage of GPLv3, the FSF recognized and acknowledged that the ‘Installation Information’ requirement is a separate obligation beyond the ‘Corresponding Source Code’ obligation that existed in GPLv2 and was also included in GPLv3.

GPLv2’s source code disclosure obligation is as follows⁴⁰.

“For an executable work, complete source code means all the source code for all modules it 
contains, plus any associated interface definition files, plus the scripts used to control 
compilation and installation of the executable.”

To the extent that anything within GPLv2’s ‘corresponding source code’ requirement resembles GPLv3’s ‘Installation Information’ requirement, it would be the two separately specified items below.

• ‘any associated interface definition files’
• ‘scripts used to control compilation and installation of the executables.’

‘Interface definition file’ is a term commonly used in computer programming (GPLv2 does not provide a more detailed definition of this term). It can be interpreted as a separate file containing attributes and definitions of a particular software’s programming interface⁴¹. This requirement in GPLv2 does not appear to impose an obligation to provide authorization keys, checksums, or other information necessary to permit the installation or execution of a modified binary. Instead, it requires the disclosure of information necessary to understand the interface of the distributed binary (because this is difficult to determine from the disclosed source code alone).

By contrast, the second item — scripts used to compile and install the executable — is clearly material related to the installation of a GPLv2-covered executable. However, this requirement concerns the term ‘script’ itself, in the sense commonly understood in computing.

      “A computer script is a list of commands that are executed by a certain program or scripting engine. Scripts may be used to automate processes on a local computer …. Script files are usually just text documents that contain instructions written in a certain scripting language. … [W]hen opened by the appropriate scripting engine, the commands within the script are executed.”⁴²

      “Script[:] … a sequence of instructions or commands for a computer to execute … especially … one that automates a small task (such as assembling or sorting a set of data).”⁴³

An installation script⁴⁴ is generally a small, simple program used to automate the process of installing a particular program on a particular device⁴⁵.

Therefore, from the standpoint of textual interpretation, there appears to be no doubt that GPLv2’s obligation to provide ‘scripts used to control … installation of the executable’ cannot be interpreted as including the provision of checksums, hashes, authorization/signing keys, or other numerical data needed to install GPLv2 executable code. Such data does not fall within the ordinary scope of a ‘script’.

A more interesting interpretive question would instead be a case where firmware embedded in the hardware device itself runs an installation program that validates the executable in some form (for example, a feature that restricts installation by determining that the executable is invalid if it has been modified). Even in such a case, however, given that both the FSF and Linux kernel developers consistently maintained, over a long period during the drafting and release of GPLv3, the position that any form of installation validation (such as the use of PROM-loaded information, as with TiVo) was permitted under GPLv2, it would be difficult to argue that such an immediate check performed by firmware would trigger an obligation to provide installation information under GPLv2’s ‘scripts used to … installation of the executable’ requirement.

7. Backporting the Installation Information Requirement to GPLv2

Some attempt to backport the entirety of GPLv3’s ‘Installation Information’ definition into GPLv2’s source code obligation, but such an effort produces results that are historically and textually incorrect. Suppose the complete ‘Installation Information’ definition were included in GPLv2’s Section 3. The moment one does so, a dilemma arises. GPLv3’s ‘Installation Information’ requirement is limited in its application to a specific type of product, namely a ‘User Product’⁴⁶. The obligation to provide ‘Installation Information’ under GPLv3 applies only to ‘User Products’ and does not apply to other products⁴⁷.

“If you convey an object code work under this section in, or with, or specifically for use in, 
a User Product ... the Corresponding Source conveyed under this section must be accompanied by the 
Installation Information.”

GPLv2, by contrast, contains no definition or limitation on the type of product to which the source code obligation applies. Source code must be provided under the GPLv2 obligation regardless of whether the product is a ‘User Product’ or not. Therefore, if GPLv3’s complete definition of the ‘Installation Information’ obligation were merely a restatement or clarification of GPLv2’s existing disclosure obligation, GPLv3 would have narrowed the circumstances under which that disclosure obligation could exist. The result would be that GPLv3 applies to a narrower range of software than GPLv2, thereby narrowing its scope in terms of ‘software freedom’. This interpretation is the exact opposite of what GPLv3 was originally intended to achieve.

       “As a free software license … this license [GPLv3] intrinsically disfavours technical attempts to restrict users freedom to copy, modify, and share copyrighted works. Each of [the licenses] provisions shall be interpreted in light of this specific declaration of the licensor’s intent. We wish courts all over the world to understand that our intent [in creating GPLv3] is to maximise freedom, not to restrict it, and that everything should be so understood when effect is given to its terms”⁴⁸

Stated differently, GPLv3 can maximize freedom in line with its original intent only if the ‘Installation Information’ obligation itself extends ‘freedom’ beyond GPLv2’s disclosure obligation. Otherwise, since GPLv2’s obligation is not limited to a specific product type, GPLv3 — which imposes the obligation only on User Products — falls into the interpretive dilemma of having narrowed the scope of ‘freedom’.

8. GPLv2’s Textual and Historical Revisionism

As explained in detail above, textual analysis and a review of the historical record make it clear that GPLv3’s ‘Installation Information’ obligation does not exist within GPLv2’s source code obligation, and that it cannot be backported to GPLv2 in any way. Despite this fact, there have recently been efforts to alter the historical record and reinterpret GPLv2’s requirements so as to equate GPLv2’s source code obligation with GPLv3’s ‘Installation Information’ requirement.

       “GPLv2 §3 requires that the source code include ‘meta-material’ like scripts, interface definitions, and other material that is used to ‘control compilation and installation’ of the binaries.”⁴⁹

       “GPLv2 included a clear obligation to provide ‘the scripts used to control … installation’ that function for the GPLv2’d works. GPLv2 assures, to the purchaser of an embedded product, their absolute right to receive the information necessary to install a modified version of the GPLv2’d works. … The GPLv2 was designed to assure bug-fixing. Furthermore, the drafters knew that, on embedded systems and devices, you need to know how to install those fixes. Scripts can be technical [artefacts] like shell scripts, but can also be merely a recipe and/or guidance — written instructions that explain how to succeed at install.”⁵⁰

As shown in these statements, an effort is currently underway to fold GPLv3’s concept of the ‘Installation Information’ requirement (information, recipes, guides, instructions, etc. for installing and executing an executable) into GPLv2, so that GPLv2 would also require the provision of a ‘script’ for installation. All such efforts are not only counter-textual to GPLv2’s actual requirements but also ahistorical. Again, GPLv2’s drafters acknowledged that GPLv2 could not require TiVo to provide the information necessary to reinstall a modified executable on a TiVo device⁵¹.

9. Conclusion

• The text of GPLv3 and the historical record make clear that GPLv3 was specifically designed to add the provision of ‘Installation Information’ — a new requirement not found in GPLv2.
• This historical record also makes clear that, under GPLv2, distribution without providing installation information (such as authorization keys or other hardware-embedded information that could prevent the installation of a modified version of GPLv2 code) was entirely permitted, and that GPLv2 required only a narrow category of information (installation scripts).
• All efforts to backport GPLv3’s ‘Installation Information’ requirement to GPLv2 are ahistorical and produce the counterintuitive result of making GPLv3 more restrictive of ‘freedom’ than GPLv2. This was never the purpose for which GPLv3 was created in the first place.
• Those who assert this counterintuitive result would in effect be advising developers who love software freedom to prefer GPLv2 over GPLv3, a result contrary to every purpose for which GPLv3 was created and released.

Whether this ahistorical and textually unsupported interpretation of GPLv2 remains merely a theoretical debate, or is ultimately decided by a court as a result of compliance litigation, remains to be seen. The many statements made during the drafting of GPLv3 (as detailed above), together with the actual language of GPLv2, will serve as the basis for any determination of the scope of GPLv2’s source code obligation.

About the author

P. McCoy Smith is Founding Attorney at Lex Pan Law (www.lexpan.law), a full-service intellectual property law firm in Portland, Oregon, U.S.A., that has a sub-speciality in free and open source licensing, as well as Founder at Opsequio (www.opsequ.io), an software licence compliance consultancy. As a member of GPLv3 Discussion Committee B, he was an active participant in the debate over, and revision of, the ‘Installation Information’ requirement in that licence.

Distribution of Dockerfiles: Who Is Responsible for Compliance?

Hello!

In April 2021, Till Jaeger, a well-known German open source lawyer, published an article on who is responsible for the license compliance of the open source software included in the Docker image generated from a Dockerfile. Based on German law and the case law of the Court of Justice of the European Union (CJEU), Till explains that the Dockerfile provider must comply with license obligations.

This is a Korean translation of Till’s original English text. I added images to aid understanding, and here and there I added my own personal comments as blockquotes (in the polite register).

• If you find translation errors or have questions, please contact me by email at haksung@sk.com
• I am deeply grateful to Sean of Kakao for his help reviewing this translation. ^^

1. Introduction and the Problem

FOSS license compliance issues related to Docker technology have been a major subject of research in recent years. In particular, Armijn Hemel’s white paper, “Docker Containers for Legal Professionals”¹, which explains the technical foundations of Docker and raises related license compliance issues, provides an extensive analysis. Hemel openly raised the question of who is responsible for the license compliance of the software components that a recipient of a Dockerfile downloads from a third party in order to use the Dockerfile.

Almost all FOSS licenses tie compliance with license obligations to “distribution” (or, in the case of GPL-3.0, “conveying”). Because most licenses do not further define what “distribution” or “conveying” means within the license itself, the definition of “distribution” must be determined by reference to the applicable copyright law².

Most open source licenses require compliance with license obligations at the point when open source software is “redistributed.” In other words, if the open source software is not redistributed, compliance with license obligations is not required. How far the scope of “distribution” extends must be interpreted according to the copyright law applicable in the relevant jurisdiction.

Because of its importance to license compliance, the term “distribution” continues to be the subject of legal analysis. Heather Meeker wrote about distribution in open source licenses from the perspective of U.S. copyright law³. Although many open source licenses were drafted against the background of U.S. copyright law, European courts are expected to rule based on the definition of “distribution” elaborated by the CJEU.

This article first provides an overview of the technical fundamentals of Docker and an interpretation of the term “distribution” under European copyright law. It then discusses who should be responsible for license compliance when distributing a Dockerfile.

2. Technical Background of Docker

Docker is a technology for installing and distributing programs in containers. It has the advantage that all dependencies exist within a single technical unit and are largely independent of the host system. Unlike virtualization through a hypervisor, a Docker container does not include an operating system kernel. Instead, a specific operating system command causes the container’s file system tree to be displayed as the root directory for all programs in the container. As a result, the rest of the file system outside the container remains invisible to programs inside the container. Docker containers require a Unix-family operating system and are mainly intended for use with the Linux kernel.

Docker image

A preconfigured container can be distributed as a “Docker image,” which, in addition to the base program, may also include applications, dependencies as program code, and, where necessary, utilities and configuration files. A Docker image can be distributed individually, but it can also be distributed through a public repository such as “Docker Hub.” The same applies to what is known as a “Base Image,” which includes essential system components such as C libraries, a package manager, a shell, and a directory tree, and which refers to a specific Linux distribution. On top of this Base image, additional functionality can be distributed separately as individual archive files, but it can also be added as so-called “layers” that are built on top of one another to form a complete Docker image.

Dockerfile

A “Dockerfile” is a text file that, similar to a script, contains step-by-step instructions for building a Docker image. A Dockerfile generally can have its own license that applies only to the Dockerfile itself, and this license does not apply to the programs included in the Docker container.

The Docker Engine

The “Docker Engine,” the management software for Docker containers, processes the instructions in a Dockerfile sequentially to generate a Docker image. Typically, each component for the Base image or the individual layers is downloaded from an internal or external repository. This means that it is possible for a provider to supply a Dockerfile without transmitting the physical program code, and this is in fact common practice. Using the Dockerfile they receive, customers can build a Docker container by independently obtaining all or part of the program code from a public repository.

This raises the question of whether, and which, license obligations the Dockerfile provider must comply with for the FOSS included in a Docker image built using such a Dockerfile.

3. Legal Background - The Right of Distribution under EU Law

Almost all FOSS licenses, under copyright law, require compliance with license obligations as a condition for the act of distributing or conveying software. In other words, license obligations must be complied with when a copy of the program is transferred to a third party. Some licenses include a definition of “distribution” within the license itself (for example, GPL-3.0 includes a definition of the term “convey”), but most licenses do not define this. It is therefore common to refer to how the applicable copyright law interprets distribution. In Germany, §69c no. 3 UrhG of the German Copyright Act uses the term “Verbreitung” and defines distribution as “any form of distributing the original or copies of a computer program (including rental).” Here, “Verbreitung” can be understood, as in §17 (1) UrhG, as granting the right to make use of a work generally, not only a computer program.

This was interpreted in light of Article 4 of the Directive 2009/24/EG of the European Parliament and of the Council on the legal protection of computer programs⁴. The highest German and European courts, the German Federal Court of Justice (Bundesgerichtshof, BGH) and the CJEU, have made numerous contributions in their judgments that help interpret the right of distribution. This is explained in more detail below.

4. Distribution of Dockerfiles - Analysis

This section first examines whether distribution under copyright law necessarily requires the physical transmission of program code. It then discusses the various components of a Docker image, namely the Base image, program libraries, patches, and updates.

4.1 Is Distribution Only the Physical Distribution of Program Code?

Not only in the first case below, but also in the second case, responsibility for “distribution” lies with the Dockerfile provider.

• The “physical” distribution of a program copy, the concept of distribution as defined in copyright law
• Any other act that causes a third party to obtain a copy of the program

Note that the highest German and EU courts have frequently held that both of the following must be considered.

• The physical act
• A third party who physically performs an act that is legally relevant to reproduction or distribution is regarded merely as a “tool” of the party concerned

This aspect includes, in particular, the organizational control that the CJEU calls an “essential role”⁵. One example is the BGH’s judgment on an “internet radio music recording service.” That judgment addressed whether the fully automated recording of digital radio stations by an internet service constitutes a personal copy of the client (permitted) or a copy made by the service provider (not permitted). On this point, the BGH stated as follows⁶:

For more details on the internet radio music recording service, see the Korea Copyright Commission’s 2019 material⁷.

The plaintiff in this judgment was the record producer Sony Music Germany, and the defendant was MusicMonster.FM, which operates a service that records and provides music broadcast on internet radio.

The German court ruled that, because the defendant’s service went beyond simply providing the technical means for reproduction and exceeded the scope justified by private use, the defendant was the actor performing the reproduction and communication to the public, and that the defendant had infringed the plaintiff’s reproduction right and right of communication to the public.

The CJEU relied on several determinations as to who performed the “essential role” in relation to acts of copyright infringement. This is particularly evident in §17 UrhG (German Copyright Act). The UrhG designates a mere “offer,” that is, a preparatory act of a physical distribution, as itself an act of distribution⁸.

This CJEU judgment, and others, show that not only technical distribution but also preparatory acts for distribution can constitute distribution, at least where the distributor plays an “essential role” in the distribution process. This is exactly the case with a Dockerfile. Because a Dockerfile provides organized instructions for transmitting a complete functioning system to the Dockerfile’s recipient (depending on its intended use), the Dockerfile provider plays an essential role in the distribution of the software included in the Docker image. In this respect, it is the Dockerfile provider who holds organizational control. Accordingly, the Dockerfile provider must comply with the license obligations of the FOSS (to be included in the Docker image) that is distributed in this form.

The fact that the Dockerfile provider distributes the software referenced by the Dockerfile does not conflict with the fact that the operator of the repository from which the Base image or layers can be downloaded also performs an act of distributing the program code, or “makes it available to the public,” respectively⁹. This is because most Base images or layers are offered not only for a specific container but also as a general download. In the case of a general download, it is the individual or entity providing the Base image or layer through the repository - rather than the repository operator - that can potentially be regarded as performing the act of distribution (or communication to the public).

4.2 Patches

Using an additional layer, an already-installed program can also be modified. In this case, the Docker container includes the unmodified program in one layer and the modified program in another layer, so that the modified program is run. Even in this situation, the Dockerfile provider must bear responsibility for the “essential role,” because the modifications to be applied are defined in the Dockerfile. Accordingly, the Dockerfile provider must comply with the license obligations for the modifications.

It should be noted that, because both versions are distributed to the recipient (even if only the modified version is actually used), this applies to the original version as well as the modified version¹⁰. The same is true even where the program is removed by a new layer but remains physically included in the Docker image.

4.3 System Requirements and the Base Image

System Requirements

This section starts from the premise that an open source license does not extend to granting permission to use independent programs that are necessary to use the open source software but are not included within the scope of the license. A representative example is the operating system or web server needed to run an application. Such independent programs necessary to run an application will be referred to as “system requirements.” A provider who distributes a Dockerfile is not responsible for complying with the license obligations for system requirements such as the Docker Engine or the Linux kernel. Such system requirements are not even referenced in the Dockerfile.

For reference, Section 3 of GPL-2.0 provides the following exception, under which major components of the operating system, such as the compiler and kernel, are not included within the scope of source code disclosure.

“3. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

Base image

Can a Base image also be regarded as a system requirement? Generally, the programs included in a Base image are independent of the application running in the Docker container. As long as the programs included in the Base image are used unmodified, the Base image can be regarded as a system requirement even though the Dockerfile contains a download instruction, because the Dockerfile provider is not the provider of the Base image. Furthermore, if the repository operator denies access, the download is no longer possible. In light of these facts, the Base image is outside the Dockerfile provider’s control. The situation is similar for patches, but patches and system requirements must be treated differently.

Computer programs generally operate together with other independent programs. This is a characteristic that distinguishes them from other forms of work. For example, most applications do not run without an operating system. However, the fact that system requirements must be installed to run such an application does not mean that the application provider plays an essential role in distributing the system requirements.

This situation is somewhat similar to that of a download link. Whether a link to download a copyrighted work constitutes an act relevant under copyright law - that is, an act of communication to the public (and therefore potentially giving rise to copyright infringement) - is a fiercely debated issue in the EU. The CJEU has established a set of complex criteria on this point¹¹. These criteria present, among others, the following case-by-case questions: whether the work is made available to a new group of purchasers, whether the intended use is commercial, whether the act plays an important role in the offer, and whether the offer is illegal. Because the matter must be addressed case by case in this way, a comprehensive judgment is almost impossible. In fact, Member States have not commonly taken these criteria into account. Nevertheless, these criteria were likely established out of the CJEU’s desire to better harmonize the legal situation regarding internet copyright.

According to the view presented so far, the operator and provider of the Base image repository play an essential role in the distribution of the Base image, whereas a Base image that the Dockerfile merely references serves only to make it easy to obtain the system requirements. Therefore, it is the repository operator who performs the act of communication to the public, and it is the repository operator - at least where this provision is lawful - who must solely comply with the license obligations of the FOSS included.

The interpretation described above is the legal opinion of this article’s author. There is generally no case law on this specific situation with respect to computer programs, and Dockerfiles in particular. Other interpretations are certainly open to debate (in particular, the view that all referenced layers, including the Base image, are distributed by the Dockerfile provider).

One point worth mentioning is that many repository operators currently do not properly comply with the license obligations of FOSS (for example, by failing to properly provide the source code for GPL and LGPL components), which gives rise to liability for copyright infringement. In this case, if the Dockerfile provider knows, or should know, of the license violation, providing a Dockerfile that includes a reference in violation of the license may be regarded as an independent act of distribution, or at least as contributory copyright infringement (that is, inciting or aiding the license violation). Accordingly, the Dockerfile provider should review whether the Base image provided by the designated repository complies with the license¹².

A recipient who intends to use a Docker image solely within their own organization can use it without issue, because the mere execution of a FOSS program is not restricted. For example, Section 4 of GPL-2.0 states this clearly¹³. However, if the recipient intends to redistribute the Docker image, the recipient who wishes to redistribute it must ensure compliance with the license terms, because the distribution right is not exhausted where the distribution of the Dockerfile infringes copyright (see section 4.6 below).

4.4 Program Libraries

In the case of a library linked with a program, there is some difference of opinion as to whether the library is regarded as an independent program or becomes part of the linked program¹⁴. In this context, a distinction can be made as follows.

• System libraries
• Non-system libraries linked with GPL and AGPL applications
• Non-system libraries linked with applications under licenses other than GPL and AGPL

GPL-2.0 Section 3 and GPL-3.0 Section 1(3) include a provision exempting “System Libraries” from the scope of the obligation to provide source code among the license obligations¹⁵. Accordingly, where a Dockerfile includes an instruction to use such unmodified system libraries in a Docker container, there is no need to comply with license obligations for these system libraries. The legal situation for such system libraries is therefore the same as that applying to a Base image (see 4.3 above), in which case the essential role for distribution does not lie with the Dockerfile provider.

However, if a Dockerfile downloads a library (other than a system library) from a third-party repository, and specifies a layer that links this library with a GPL-3.0 or AGPL-3.0 application within the Docker container, then the obligations of the license (GPL-3.0 or AGPL-3.0) of the respective linked application must be complied with for this library. For example, the library’s source code must be provided (cf. section 1 GPL-3.0: “Corresponding Source includes …, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, …”). The same applies equally under GPL-2.0. As in the case of the library’s physical distribution, the applicable license terms must be complied with (provided there is no license conflict issue). In other words, the copyleft requirements cannot be circumvented through a decentralized distribution process.

Because the Dockerfile provider has organizational control over the selection of a program library as a dependency, it can be concluded that the Dockerfile provider distributes the program library. Accordingly, the Dockerfile provider plays an essential role in the process of distributing the program library.

4.5 Updates

How updates are treated depends on whether the Dockerfile provider controls the update. If the Dockerfile provider (or an agent) uploads the update directly to the repository so that the Dockerfile’s recipient can retrieve it, the Dockerfile provider can be regarded as distributing the update. By contrast, if the update is provided under the control of the repository operator (for example, where the Dockerfile references the “latest version”), this is not distribution by the Dockerfile provider. In this case, in contrast to the situation where the Dockerfile provider selects a program version and names it within the Dockerfile, the Dockerfile provider has no influence over the content of the update.

4.6 When License Obligations Must Be Fulfilled

License obligations must be complied with at the point of distribution (or communication to the public). Because a preparatory act within the same series of distribution steps, such as the delivery of a Dockerfile, may already be regarded as distribution, strictly speaking, license obligations must be fulfilled at the time the Dockerfile is delivered. However, open source licenses can be interpreted in a way that treats compliance with license obligations at the time of downloading from the repository as sufficient. This interpretation is further supported by the fact that, particularly at the time a Dockerfile is distributed, it is not clear what program code will be included in the layers to be downloaded - for example, where a program version is specified as “latest.”

However, if the relevant repository does not fully satisfy the license obligations, it is advisable for the Dockerfile provider to independently comply with the license obligations and to provide, together with the Dockerfile, a file containing the necessary essential information (for example, the license text, copyright notices, and the provision of source code).

5. Conclusion

• The Dockerfile provider is responsible for compliance with the license terms of the FOSS included in the Docker container during the process of building/running the Dockerfile. Even where the Dockerfile’s recipient downloads the software from an external public repository, this does not relieve the Dockerfile provider of responsibility.
• Case law of the Court of Justice of the European Union shows that providing a Dockerfile constitutes a preparatory act, and that this is included within “distribution.”
• However, in light of the particular nature of the interaction between computer programs, the Dockerfile provider is not responsible for license compliance with respect to “system requirements” such as the operating system and the web server.
• That said, if a Docker layer is provided from a repository in a state that does not comply with the FOSS license, this also creates risk for the Dockerfile provider who references it.
• Accordingly, FOSS license compliance is a matter for which the Dockerfile provider and the distributor who published the Docker layer to the public repository are jointly responsible.

What Is an OSPO?

Hello!

TODO Group¹ is a group² under the Linux Foundation that advocates Talk Openly, Develop Openly, aiming to build successful open source projects and programs through collaboration. TODO Group creates and publishes open source guides³, tools⁴, and more, making them available to anyone interested in open source.

For an organization such as a company to effectively manage and use open source, it is said that establishing an OSPO_{Open Source Program Office} is needed for activities such as developer education, ensuring compliance, engaging with and building community, releasing open source, and code review. This article carries over the article defining⁵ what an OSPO is and what role it plays, as written by TODO Group.

Definition of an OSPO

An OSPO_{Open Source Program Office} is designed to concentrate an organization’s capabilities centrally for the organization’s open source operations. This can include the use, distribution, selection, and inspection of open source and the establishment of related policies, as well as activities that facilitate developer education, ensuring compliance, and engaging with and building community in ways that benefit the organization.

There is no broad template for building an open source program that can be applied across all industries, but here we have classified the general functions of an OSPO into three categories.

1. Legal Risk Mitigation
2. Improving Engineers’ Practices
3. Enabling Financial Benefits

Classifying them into these three categories brings to mind Fear, Love, and Money, respectively.

Legal Risk Mitigation

A company’s primary concern is legal compliance. Accordingly, the OSPO builds and manages the company’s open source license compliance process. Companies that distribute software generally have the most interest in this issue, and it is this legal risk mitigation that most often gets an OSPO started in the first place.

For legal risk management, the OSPO holds the following responsibilities.

• Overseeing open source license compliance management
• Running a review process for the use of inbound code_{note: code obtained from external sources such as open source}
• Ensuring effective contribution to open source projects

Improving Engineers’ Practices

The OSPO improves engineering functions by providing guides and policies for code management in an open source environment. Companies with many software engineers tend to focus their OSPO on engineering policy and practices.

The OSPO’s responsibilities in this area are as follows.

• Clearly communicating the company’s open source strategy both inside and outside the company
• Fostering an open source culture within the organization
• Ensuring that high-quality code is released to open source communities frequently

Enabling Financial Benefits

Some companies focus on the financial benefits related to open source. They use the OSPO to establish a strategy for whether to use commercial vendors or open source vendors. Meanwhile, some technology companies leverage their own OSPO (and open source projects) to drive customers toward purchasing their commercial products.

The OSPO’s responsibilities in this area are as follows.

• Ownership and oversight of strategy execution
• Promoting the effective use of open source in commercial products and services
• Collaborating with the developer community to encourage adoption of strategic open source projects

In this way, each OSPO is structured to fit the company’s business, products, and goals.

OSPO Guides

TODO Group provides guides for companies to establish and operate an OSPO.

• How to Create an Open Source Program⁶
• Measuring Your Open Source Program⁷
• Tools for Managing Your Open Source Program⁸

OSPO Examples

TODO Group has compiled and published case studies of how companies that make effective use of open source, such as Microsoft, Facebook, and Uber, run their OSPOs.

• Autodesk⁹
• Capital One¹⁰
• Comcast¹¹
• Facebook¹²
• Microsoft¹³
• Red Hat¹⁴
• Salesforce¹⁵
• SAP¹⁶
• Uber¹⁷
• Yahoo/Verizon Media¹⁸

I close this article by introducing SK telecom’s OSPO: SK telecom OSPO¹⁹

Thank you.

Elastic License 2.0 and the Evolution of Open Source Licensing

Hello.

This article is based on a white paper about the Elastic License published on March 11, 2021 by Heather Meeker, a U.S. attorney specializing in open source law. Most of it is a translation of the original article, and I have added my own opinions as blockquotes.

For reference, while Heather Meeker presented this white paper as her personal view, she also disclosed that it received some funding from Elastic. Perhaps for that reason, the original article takes a favorable stance toward the Elastic License.

(A bit of digging turned up that Heather Meeker wrote Elastic License 2.0 herself.)

In any case, as the times change and software distribution methods shift, commercial open source companies have had to think about which licensing model to adopt in order to pursue both development and business at once, and I think this article helps in understanding one aspect of the background behind the Elastic License. If you find any errors in this article, please feel free to contact me at any time. :-)

• My deep thanks to Sean and Robin of Kakao, and Kyoungae Kim of LG Electronics, for their help reviewing this article.

Recently, in February 2021, Elastic introduced a new license called Elastic License 2.0 for its software products. This licensing model was applied to major software products such as Elasticsearch and Kibana. Let’s look at the purpose of this change and what it means.

Elastic License 2.0 is a representative licensing best practice available to companies doing business under an Open Development Model. Elastic License 2.0 is not an open source license, but it aims to set the minimum restrictions necessary to maintain a fair balance between the freedom to use, share, and modify software and the prevention of behavior that harms the community.

Unix, Linux, Free Software, and Open Source

To understand the trend toward new licenses like Elastic License 2.0, it helps to look at how the open source licensing movement grew.

The open source and Free Software movements began out of developers’ concerns about the privatization of software. The spark for these concerns was Unix, the most popular operating system of the time. AT&T Bell Labs, the developer of Unix, was barred by a 1956 consent decree from profiting from research projects that included Unix and the C programming language,¹ and as a result it distributed Unix for many years under very permissive license terms. Academics, researchers, and developers began modifying, improving, and sharing Unix, and it soon became the leading operating system. However, when the consent decree was lifted in 1983, AT&T applied terms to Unix that no longer allowed the sharing of modifications. As a result, each vendor used its own modified version of the operating system, Unix splintered into many incompatible variants, and users could no longer collaborate.

As Unix became privatized, the Free Software movement arose, followed by the open source movement, both seeking to prevent infrastructure software from being closed off again in this way. This movement centered on Linux, the free software that replaced Unix, and it soon grew into a larger movement based on the philosophy that all software should be “free” (free as in freedom of speech, not free as in free beer). One element of this movement was the right to access source code and to make and share improvements and changes. These principles were embodied in the GNU General Public License (GPL), under which distributors of binaries must share the corresponding source code.

As time passed, buoyed by the internet boom of the early 2000s, open source licenses grew even more popular. Some licenses, such as the GPL, raised complex legal concerns, but they also laid the groundwork for companies to collaborate. Since 2000, open source, and the collaboration it made possible, has been adopted across every technology sector. Today, open source is a core technology for e-commerce, and companies continue to collaborate on software infrastructure.

The Advent of the Cloud and AGPL

Licenses such as the GPL require that changes be shared. They impose a condition of sharing source code for binary distribution. Making and using a “private copy,” on the other hand, does not require sharing changes. This condition was effective at compelling sharing at the time, because most software was deployed on-premise. However, starting in the early 2000s, software began moving to the public cloud, and it was no longer necessary to distribute software at all. Customers could use software without ever obtaining a local copy.

As the cloud services business grew, this paradigm shift created tension between the expectations of the open source community and cloud service providers such as AWS (Amazon Web Services). Cloud service providers were free of any legal obligation to share their improvements. Because Google was well known for relying on Linux to power its search service, this was also called the “Google Loophole.” In response, the Free Software community created the Affero GPL (AGPL), a partially modified version of the GPL. AGPL 3.0 is nearly identical to GPL 3.0, but it includes the following Remote Network Interaction clause.

[I]f you modify the Program, your modified version must prominently offer 
all users interacting with it remotely through a computer network … 
an opportunity to receive the Corresponding Source of your version by 
providing access to the Corresponding Source from a network server at no 
charge, through some standard or customary means of facilitating copying 
of software….

This new license was intended to compel cloud service providers to share their source code improvements, just as the GPL had done for Linux distributions.

AGPL and Dual Licensing

The AGPL was controversial from its very first release. In 2007, as the drafting of GPL 3.0 was nearing completion, some of its authors wanted to change the GPL into a network copyleft model. However, the community decided to leave the “loophole” in GPL 3.0 as it was, and a few months later offered the AGPL as an alternative. Even so, the AGPL was not widely adopted. MongoDB, a highly popular distributed database product, is the AGPL’s one and only “killer app.” Companies initially found the AGPL difficult to understand and accept, but because most users neither modified the software nor offered it as a service, they were able to reasonably decide to use software under the AGPL.

The Remote Network Interaction clause of AGPL 3.0 only requires you to make the source code of your changes available to remote users over a computer network if you have modified the program. In other words, if you do not modify it, no obligation to disclose source code arises.

MongoDB used the AGPL under a “dual licensing” business model. It gave licensees a choice between the AGPL and a commercial software license. Users who did not want to comply with the AGPL’s requirements, or did not even want to be involved in the legal review needed to comply with them, chose the commercial license. This dual licensing business model was originally developed around a choice between the GPL and a commercial license, but over time the AGPL, with its broader copyleft scope, came to be used in place of the GPL. This licensing model was quite successful for MongoDB. Because the AGPL was the strongest copyleft license, it was useful to MongoDB in driving commercial negotiations. At the same time, the creators of the AGPL criticized the way it was used as a business tool by MongoDB, calling it a “toxic shakedown.” In any case, even the AGPL’s source-sharing condition, powerful as it was considered to be, proved insufficient to stop cloud providers from making large-scale commercial use of open source software while giving nothing back to developers or the community.

Strip-mining

Just as cloud adoption had “broken” the GPL model, the AGPL dual licensing model also began to come under pressure as cloud computing advanced through the 2010s. This time, the problem was different. The scope of the GPL or AGPL extends only to a single program executable. This “feature” was intentionally designed into the GPL, based on the theory that a copyright license can only specify usage terms for a single work. In other words, the GPL imposes a source-sharing requirement for a derivative work, but not for a collective work. The legal boundary between the two is fairly unclear, but as the GPL grew popular, it became common practice to define a single program as a single executable process. The Free Software Foundation has long asserted this principle in its GPL FAQ.

However, two things happened as cloud services advanced. First, software engineering became more focused on cloud implementation. Whereas cloud providers had once needed to improve or modify software to run it in a cloud environment, as software engineering advanced, cloud providers were able to use existing open source software in a “plug and play” fashion. This allowed cloud providers to shift the locus of innovation away from the primary executable. They developed additional software to manage, monitor, and deploy their software, and this innovation is what let them grow their cloud services. The AGPL did nothing to compel cloud providers to share these kinds of improvements.

In this way, commercial open source companies came to look like a shop the large cloud providers could raid for free. The problem was especially severe for “platform software,” or middleware (software that sits between the top-level applications and the operating system in the computing stack). Software in this category is essential to modern computing and extremely useful for cloud implementations.

This gave rise to criticism in the business world of how cloud providers used open source software. In 2018, Salil Deshpande of Bain Capital said, “It is clearly not illegal. But we think it is wrong, and does not do right by the open-source community.” Another expert said, “AWS is exploiting open source’s Achilles heel: taking someone else’s creation for free and building a business by renting out access to it.” The problem is that none of the major open source licenses prevent software from being used this way.

When the major open source licenses were drafted, there was no such thing as an AWS-style “program as a service,” so their terms could not have accounted for it.

Commercial open source companies developed open source programs and ran their business on a dual licensing model (GPL or commercial), while cloud providers simply took those open source programs, offered them as cloud services, and generated no profit for the companies in return. It’s easy to imagine this had a negative effect on both the business and development sides.

A representative example would be cloud providers offering MongoDB as Amazon DocumentDB or Azure Cosmos DB to win over customers.

Commercial open source companies and their investors were troubled by these limitations of the open source model. No license, whether GPL, AGPL, or otherwise, could use copyright law to compel cloud providers to share their changes. In addition, cloud providers with a large customer base, such as AWS, Azure, or Google Cloud, maintained “sticky” relationships with customers by making it easy to add software with the click of a button. Some open source vendors offered their own cloud services, but found it too difficult to compete with large cloud providers using their software for free. Even when an open source vendor’s service was superior, customers turned away because using a new service, unlike simply “checking a box” to add a software product within an existing cloud account, carried a transaction cost.

SSPL and Source-Available Licensing

In 2018, the industry found a breakthrough. As AWS continued to gain popularity by hosting open source platform software, open source vendors began to take action. They changed their licenses.

Open source vendors responded to the strip-mining problem through two different paths.

1. An ultra-strong network copyleft license
2. Source-available licensing with restrictions

Both of these categories were previously undefined. Both were intended to support a dual licensing model, as with MySQL and MongoDB.

SSPL

MongoDB, which created the SSPL (Server Side Public License) in 2018, attempted the ultra-strong copyleft approach.

1.  Offering the Program as a Service.

If you make the functionality of the Program or a modified version 
available to third parties as a service, you must make the Service 
Source Code available via network download to everyone at no charge, 
under the terms of this License. Making the functionality of the 
Program or modified version available to third parties as a service 
includes, without limitation, enabling third parties to interact 
with the functionality of the Program or modified version remotely 
through a computer network, offering a service the value of which 
entirely or primarily derives from the value of the Program or 
modified version, or offering a service that accomplishes for users 
the primary purpose of the Program or modified version.

"Service Source Code" means the Corresponding Source for the Program 
or the modified version, and the Corresponding Source for all programs 
that you use to make the Program or modified version available as a 
service, including, without limitation, management software, user 
interfaces, application program interfaces, automation software, 
monitoring software, backup software, storage software and hosting 
software, all such that a user could run an instance of the service 
using the Service Source Code you make available. [emphasis added].

This license was written to create an open source solution to the strip-mining problem. Its source-sharing requirement is far broader than that of the AGPL. The scope of this requirement was designed to work like the GPL’s requirement even for distributed software. MongoDB applied a dual licensing model under which its software could be used under either the SSPL or a commercial license.

MongoDB submitted the SSPL to the OSI (Open Source Initiative) for approval. After months of debate it was not approved, but MongoDB continues to use the SSPL as the open source option in its dual licensing model. The discussion of why this license does not fit the Open Source Definition was complicated, and meeting that definition was not the only criterion at issue. In short, it was not clear whether a license with such a broad source-sharing requirement would “ensure software freedom.”

Source-Available Licenses with Restrictions

Others followed a different path. Some companies adopted the Commons Clause, led by Salil Deshpande, while others created their own licenses, such as Redis, Confluent, and CockroachDB, just as Elastic created Elastic License 1.0. Unlike the SSPL, these licenses were not intended to satisfy the Open Source Definition. Instead, they carry restrictions specifically targeting strip-mining.

Why did these two paths diverge? It has to do with Freedom Zero, “the freedom to run the program as you wish, for any purpose.”²

A key feature of open source or Free Software licenses is that they carry no licensing constraints or restrictions.³ Compare this to a typical commercial software license. An End User License Agreement, the kind you click to accept for personal use, only permits you to use the software; you cannot modify or distribute it. An enterprise license sets limits on the number of users, servers, or physical locations where the software can be used, and requires the company to monitor that usage. Open source licenses have no such restrictions. Therefore, even if the source code is provided for free, a license that carries a restriction such as no commercial use is, by definition, not open source.

In other words, any licensing restriction at all takes a license outside the open source category.

Nearly all of the licenses released as part of the wave of license changes since 2018 carry similar restrictions. Each has its own specific terms, but they all focus on letting users use the software for free while prohibiting its use to offer a competing hosted service.

Elastic License 2.0

In early 2021, Elasticsearch blazed a path that follows both of these tracks at once. It made its software suite available under two free options: the SSPL and a new Elastic License 2.0 (ELv2).

The new Elastic License 2.0 is short (just one page), written in plain language, and grants nearly all of the freedoms of an open source license. Recipients of the software are free to use, modify, and redistribute it. Even if you have never read a software license before, this one is worth reading.

It has two main restrictions.

You may not provide the software to third parties as a hosted or 
managed service, where the service provides users with access to 
any substantial set of the features or functionality of the software.

You may not move, change, disable, or circumvent the license key 
functionality in the software, and you may not remove or obscure 
any functionality in the software that is protected by the license key.

The first restriction is focused on addressing the strip-mining problem. As a result, using the software in violation of this restriction infringes the rights granted for the software.

The second restriction is meant to prohibit hacking the software’s license key. This kind of restriction has long been common in software licenses, but it has only just begun to appear in source-available licenses. This clause allows developers to have a paid service interact with software under ELv2, or to protect part of a software component for a paid feature.

The license’s other provisions are very straightforward and will be familiar to anyone who has read an open source license.

Why Use Dual Licensing?

Elasticsearch took the unusual path of letting users choose between the SSPL and the Elastic License. Many companies today use an “open core” model, and in fact Elasticsearch itself used this model before. The distinction between the two can be described as subtle. An open core model offers the core software under an open source license (usually a permissive one, such as Apache 2.0). It then offers additional functionality, usually features useful for enterprise-scale deployment, under a restricted license or only as a service. Elasticsearch, however, stuck with a dual licensing model in which the same software can be used under two different licenses. This dual licensing model was pioneered by MySQL, and it typically uses a copyleft license, such as the GPL, AGPL, or SSPL, as the free licensing option. In recent years, though, this model has fallen out of favor because of the conflict between open source licenses and cloud services.

Elastic’s choice was even more unusual in that it offered two free licensing options, the SSPL and Elastic License 2.0. Dual licensing typically offers only one free option. Through this unusual approach, Elasticsearch emphasized the flexibility to let nearly every user use the software for free.

Elastic License 2.0 appears to reflect a resolve to prevent just one thing: cloud service providers offering Elasticsearch as their own cloud service.

In the end, AWS forked Elasticsearch to keep offering its Elasticsearch service, naming it Open Distro for Elasticsearch, applying the Apache License 2.0, and setting out to grow its own community.

Who, then, is actually contributing to the sustainability and advancement of open source?

Elastic License 2.0 and Modern Licensing Techniques

Elasticsearch moved to a new licensing model in order to remain as open as possible while maintaining a business model that is fair and sustainable for both users and developers. In doing so, it reflected the goals and aspirations of other participants in the source-available movement when drafting the license.

As summarized in the FAQ on the license change, Elastic’s license change is not expected to affect the number of customers or community users. Most users build applications on top of Elastic’s software, which is not a business of “providing [the software] to third parties as a hosted or managed service.”

Building a Better License

In addition, by devoting resources to drafting Elastic License 2.0, Elastic pursued an advance in the craft of license drafting itself. In a sense, source-available licensing is as old as software itself. In fact, binary-only licensing was a product of PC/Mac platform standardization in the 1980s. Before that, nearly all software was licensed in source code form. Over time, however, the form and method of license distribution changed considerably.

Elastic License 2.0 is the culmination of this trend. In form, it adopts the simple, intuitive drafting style and template most popular among open source licenses. It also, through its license key preservation clause, makes it easy for vendors to license software with both free and paid features.

Much like the many incompatible proprietary versions that split off from Unix decades ago, proprietary licenses are a patchwork stitched together from all manner of separate terms and conditions. Even a simple end user license for an ordinary consumer software product is typically so long and obscure that most users cannot understand it. Many say that nobody reads them at all. Yet most of this complexity is unnecessary. Open source licenses, particularly permissive ones, have taken this lesson to heart. A simple set of rules should be enough, and the easier a license is to understand, the more likely users are to respect it.

Not only is Elastic License 2.0 short, simple, and easy to understand, but people can also use it as a template. Since the debate over preventing strip-mining began, demand has grown for licenses that are frictionless, carry reasonable restrictions, and are simple and understandable. However, most small software companies lack the resources to draft their own license. It is no surprise that many software startups are looking to licenses like Elastic License 2.0 and the Confluent Community License as models they can adopt.

This space has been popularized by Fair Code, which has established a standard for it. Fair Code states the following.

Fair-code is not a software license. 
It describes a software model where software:

* is generally free to use and can be distributed by anybody
* has its source code openly available
* can be extended by anybody in public and private communities
* is commercially restricted by its authors

This initiative is still in its early stages, but it clearly shows that the industry is beginning to recognize the need for a paradigm that is fair to both users and developers, and that it is enabling commercial open source companies to strike that balance in a more flexible way than the open source model alone. One expert has even called this recent evolution in licensing the “post-open-source era.” In practice, however, these source-available licenses are typically used alongside open source licenses as business and licensing models continue to evolve. The two models are therefore not strict substitutes but complements.

There is also another standardized licensing option. In 2020, a group of attorneys launched the PolyForm Project to draft a collection of source-available license templates. These licenses were peer reviewed by attorneys experienced in both open source and proprietary licensing. Much like Creative Commons for open content licensing, it offers a menu of options, including non-commercial, evaluation-only, and anti-competition licenses. Like Elastic License 2.0, all of them provide free access to source code and grant the necessary patent license. PolyForm Perimeter and PolyForm Shield resemble their forebear, the Confluent Community License, and Elastic License 2.0 has advanced the options available along this same trend.

If you have questions or would like to learn more, refer to the following resources.

“The rise of open source IPOs” https://coss.media/rise-of-the-open-source-ipo/. This article tracks some of the spectacular business successes of open source companies.

“The After Open Source Era Has Started” https://monetize.substack.com/p/open-source-eras . This article discusses the sea change represented by companies moving to source available licenses.

US House of Representatives Committee on the Judiciary’s report on investigation into competition in digital markets, spearheaded by the Subcommittee on Antitrust, Commercial and Administrative Law. https://www.documentcloud.org/documents/7222836-Investigation-of-Competition-in-Digital-Markets.html. Note the mention of Elasticsearch on page 326.

Opensource license used by IT Companies

EPAM, Github Activity Ranking and License Status by Enterprise in 2020 (OSCI)

EPAM, which develops and consults Enterprise Software, provides a ranking service called OSCI (Open Source Contributor Index) that measures Github usage.

Measures the contributions of members of a commercial organization using publicly available Github Committed event data. Contributions from universities, research institutes and free email providers were not included. The target is contributors who have performed more than 10 commits, and the activity score is measured by an algorithm they have studied. The algorithm is published in OSCI Github.

OSCI (Open Source Contributor Index)

https://solutionshub.epam.com/osci

According to the analysis score, Google is at the forefront, with Microsoft and Red Hat coming next. Samsung is ranked 29th for Korean companies and LG Electronics is ranked 71st.

License Status used by Major Companies

The Open Source License Usage Survey, drawn from data collected through OSCI, is also worth a look. Measurement was already possible with tools like Google BigQuery, but the results were unreliable because abuse and other invalid data weren’t filtered out. Building OSCI made it possible to compile statistics over a set of meaningful GitHub repositories, which makes this data more useful.

The study examined the license choices of new public repositories created on GitHub from early 2018 through mid-2020, and also studied a year of data from GitLab to compare patterns across popular open source hosting platforms.

The Sharp Rise in New GitHub Repositories

It shows that the number of repositories created on GitHub has grown sharply over the past two and a half years. This growth in open source is a trend that deserves particular attention.

License Usage Trends Since 2018

Looking at repositories created from early 2018, several trends stand out.

• 34% of repositories do not include a license file, which puts their open source status in question.
• 21% of repositories are not recognized by GitHub as a standard license type. This is usually because the license file contains custom license text, often just a minor edit of standard license text. Finally, and most importantly, Apache 2.0 and MIT are the two most widely used license types, together accounting for more than 35% of all repositories.

Excluding repositories without a license file, more than half use the Apache 2.0 or MIT license. A third of repositories use some form of custom license text, and the remaining 13% cover a range of licenses, most commonly variants of BSD and the GNU Public License.

Repositories continue to be created without a license file despite GitHub’s guidance. The data suggests that many individual contributors do not understand the importance of including a license file in an open source project.

License Usage at the Top 5 OSCI-Ranked Companies

The chart for commercial organizations looks different from the one covering all repositories analyzed on GitHub. Apache 2.0 is by far the most widely used license, followed by custom license text. The MIT license is the only other standard license to gain significant adoption. Copyleft licenses are barely used. Finally, a non-trivial number of repositories still have no license file; a manual review of a sample found that most of these are not code repositories at all, but examples or documentation.

Looking at each of the top 5 companies individually, the results are interesting, and preferences differ from company to company.

Apache is the most preferred license at Google, IBM, and Red Hat. At Microsoft, most licenses are custom text, with MIT as the next most preferred standard license type. A manual review of some of that custom license text found that it was often actually MIT (for code repositories) or Creative Commons (for documentation).

Intel, by contrast, appears to use a much wider variety of license types, with Apache the most preferred, followed by custom license text and 3-Clause BSD. A manual study of the custom license text in Intel’s repositories shows it to be a mix based on Apache 2.0, 3-Clause BSD, and other standard license types.

GitLab Analysis

Over the 12 months from Q2 2019 through the end of Q1 2020, a pattern emerged that is very different from the GitHub results. In particular, 77.7% of public repositories created in this period have no license file. This again suggests that developers are not aware of the need for, or value of, choosing an open source license. It may also reflect some difference between the users who create open source projects on GitLab and on GitHub, with more individual use relative to commercial use.

Excluding repositories without a license file, the image below shows MIT as the most popular at 37%, followed by custom license text at 21%, GPL 3.0 at 17%, and Apache 2.0 at 10%. In summary, permissive license types are again the most widely used on GitLab, but MIT leads, and Apache 2.0 usage is much lower than on GitHub. Copyleft licenses hold a similarly small share on both GitLab and GitHub.

Conclusion

This study surfaces a number of interesting findings.

• Apache 2.0 and MIT are the clear leaders, and the trend toward permissive license types is growing. Copyleft license types see only modest use.
• The number of repositories created without a license is growing, which suggests that individual developers in particular may not understand the legal aspects of open source.
• Custom license types are especially widespread among commercial organizations, and in most cases appear to be based on standard license types.