Blog

• AI-Generated Code: How Far Should Open Source Scanning Go?
• Rockchip and FFmpeg: A License Dispute Case Study
• The AVM Lawsuit: Revisiting LGPL-2.1 User Rights and the Obligation to Provide Installation Information
• Key Points of the EU's Three Major Digital Regulations That Korean Software Companies Need to Know
• To Mine or Not To Mine: A German Court's Ruling on the Copyright Dilemma of the AI Era
• A Chinese Copyright Infringement Case: "Since GPL-Based Software Products Already Have an Obligation to Disclose Source Anyway, Isn't It Fine to Copy Them?"
• Elasticsearch Changes Its License Again: How Should Companies Respond?
• Introduction to SPDX 3.0 and Enterprise Adoption Strategy
• French Court Orders Major Telecom Orange to Pay Damages for GPL Violation
• Effective Open Source Management Practices for Companies (2): OpenChain Korea Work Group
• Effective Corporate Open Source Management (1): The OpenChain Project for Global Collaboration
• Buy Anaconda If You Use It. If Not, Use conda-forge!
• Akka Is No Longer Open Source.
• A Quick Look at the SFC v. Vizio Ruling
• Challenges and Effects of Adopting InnerSource
• Can I Use a Publicly Available Dataset to Build a Commercial AI Service?
• Is Open Source Compliance Necessary Even When Providing a Service as SaaS?
• 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
• How to Write Copyright Statements in Source Code
• OSS Supply Chain Security
• 2019 FOSS Legal Issue Top 10

AI-Generated Code: How Far Should Open Source Scanning Go?

One point to clarify first

It is hard to answer this question directly with a “yes” or “no.” As I will explain point by point below, what determines the answer is not AI itself. AI coding increases the rate at which code fragments not declared as packages flow in, but it does not change the conditions under which license obligations arise. So rather than asking “does scanning still matter in the age of AI,” it helps more to ask “under what conditions does snippet-level scanning become more important, and under what conditions does it become less important.”

Snippet scanning and SCA are different things

First, the terms need to be separated so the discussion doesn’t get tangled.

Software Composition Analysis (SCA) refers broadly to the activity of identifying open source that has entered the code and managing its vulnerabilities and licenses. Most SCA looks at declared dependencies, as in the first row of the table above. Snippet-level matching is a separate feature found in only some commercial tools; it compares the source code body against a large number of open source projects to find the origin of fragments that are not declared as packages. What this post addresses is not SCA as a whole but this snippet matching.

How much legal risk actually exists

Let’s start with cases where AI code snippets led to license violation disputes.

The most widely known case is the Copilot class action lawsuit that open source developers filed against GitHub, Microsoft, and OpenAI in November 2022. In May 2023, the copyright infringement claim was dismissed for lack of concrete evidence of copying, and in July 2024, the claim under Section 1202(b) of the Digital Millennium Copyright Act (DMCA) was also dismissed. This section prohibits removing copyright management information attached to an original work, and the court did not accept the claim on the grounds that the Copilot output was not sufficiently identical to the original A2. Of the 22 claims originally filed, two remain: open source license violation and breach of contract A2·A3.

This carries facts that can be read in two directions.

On one hand, the defendants in disputes so far have all been vendors that built the AI tools, and no publicly reported case exists of an adopting company being sued solely for using AI-generated code C1. Also, in September 2023, Microsoft announced through its Copilot Copyright Commitment that it would cover defense costs and damages if a paying commercial customer is sued by a third party over intellectual property arising from Copilot output. This comes with the condition that the customer must not disable the product’s built-in filtering features and must not intentionally generate infringing content B1·C5.

On the other hand, the legal question has not been settled. The DMCA issue above has gone up to the Ninth Circuit Court of Appeals as an interlocutory appeal — where a specific issue is contested in a higher court before the trial court’s judgment — and as of June 2026, no ruling has come down, and the trial court proceedings remain paused A1. The absence of reported precedent does not mean there is no risk.

When do license obligations arise

One distinction needs to be made here. Whether you get sued and whether you have an obligation to comply with a license are different questions. Even if no one files a lawsuit, the obligation to comply with an open source license remains. And when that obligation is triggered matters.

The copyleft obligation of GPL-family licenses, which requires disclosing source code, arises when software is distributed. Merely running software internally is use, not distribution, so no obligation arises C3·C4. Pure SaaS that does not deliver code is likewise outside GPL obligations for the same reason. Two caveats apply here.

• AGPL is a stricter license that treats even providing a network service as distribution. If you use a component licensed under AGPL, the source disclosure obligation arises even if you provide it only as a service without directly delivering the code C3. Such components can be managed by excluding them through internal policy.
• “Internal” must mean use limited to the company’s own employees, and if distribution occurs later — through an acquisition or open-sourcing — the issue arises at that point.

Whether short code is even copyrightable is also worth examining. A few lines of functional code may be too trivial an amount of copying to pursue (de minimis), or may fall outside protection because there is effectively only one way to express it (merger doctrine) A4·A5. That said, this is a case-by-case determination, and longer, creative code blocks are protected, so it is hard to say all snippets are free to use.

In practice, it is common for small fragments to come with obligations attached. Code from Stack Overflow, which developers frequently copy, is licensed under CC BY-SA, carrying attribution and share-alike obligations. According to one study, the proportion of GitHub projects that used this code in compliance with the license was at most 1.8% C6. This means even small fragments can carry license obligations, and that obligation is widely not observed.

Do standards require snippet scanning

OpenChain ISO/IEC 5230, the international standard for open source license compliance, focuses on defining where the compliance process sits, how roles and responsibilities are allocated, and how the process is sustained A6. It is a non-prescriptive standard that sets what must be achieved while leaving the specific method to the organization, so it does not mandate a particular technique such as snippet scanning A6·A7. What the standard requires is identifying third-party components and maintaining a list of them — a Software Bill of Materials (SBOM). What matters for meeting the standard is grasping which components entered the code; it does not require analyzing the origin of every single code fragment. In fact, many widely used SCA tools on the market operate at the dependency level only, without snippet matching.

This fact can be read two ways. It means the standard can be met without snippet scanning, since the standard does not require it, and at the same time it means an area remains that the standard does not cover. Dependency-level scanning cannot see fragments that were copied or AI-generated without being declared as a package. Snippet matching is the feature that fills exactly that gap, and some organizations perform it for more thorough intellectual property management.

Under what conditions does it become more important

How much weight snippet scanning deserves depends on two conditions a company faces.

First, whether the company delivers code or binaries directly to customers. When code leaves the company — as with on-premises installed products, mobile apps, SDKs, or embedded device firmware — this counts as distribution and can trigger copyleft obligations. Pure SaaS that does not deliver code carries a smaller burden.

Second, whether the company undergoes external verification — situations where someone outside the company actually checks the origin of the code, such as M&A due diligence, a large customer’s security audit, regulatory requirements, or an SBOM submission that demands snippet-level detail.

The more these two overlap, the greater the chance that a latent obligation surfaces as an actual cost. Even if code is delivered, if there is no verification trigger, the risk stays latent, and if code is not delivered, the obligation itself rarely arises. Neither condition has anything to do with whether AI is used. AI coding is a factor that increases the inflow volume once a condition holds, not a factor that creates the condition.

Looking at it by company condition

Placing the two conditions above on two axes yields four quadrants.

Figure 1. How much weight snippet scanning deserves, by condition

The top-right quadrant carries the greatest burden: code leaves the company, creating a license obligation, and there is also a trigger — such as M&A due diligence or a customer audit — that actually looks into that obligation. In the top-left, even if an obligation arises, there is no one to check it, so it stays latent. In the bottom two quadrants, there is no distribution at all, so an obligation rarely arises to begin with.

This diagram is a starting point for judgment, not a definitive answer. Even within the same quadrant, the choice can vary depending on the nature of the code involved, the types of licenses used, and the company’s risk tolerance.

Embedded software is a different case

Everything so far has assumed software built through a package manager. Software that runs as embedded or firmware code — routers, set-top boxes, IoT devices, automotive controllers — is a different case. It is mostly written in C/C++, and open source is often copied in as raw source directly into the project without a manifest. In this case, dependency-level SCA has no manifest to read and can barely see the open source at all.

One distinction is needed. For large components brought in wholesale, such as the Linux kernel or BusyBox, the company is usually aware it is using them. That is not a discovery problem but a matter of whether the source disclosure obligation is being met. Where snippet scanning is needed is different: small code fragments pulled in bits and pieces from various open source projects that no one has listed anywhere. Finding these fragments, which dependency-level SCA cannot see, is the job of snippet scanning.

So in embedded software, snippet scanning is not a conditional supplement but closer to a basic means of finding undeclared open source fragments.

Filtering code before it comes in

Apart from scanning after the fact, there is also a way to block problem code before it comes in. GitHub Copilot has a setting that blocks suggestions matching public code verbatim. Suggestions that match public code exactly at a certain length (on average, roughly 150 characters) or longer are simply not shown B2·C2. GitHub has stated that verbatim duplication over 150 characters occurs at about the 1% level, though independent studies report higher figures depending on context. Either way it is not zero, but turning on this setting reduces the inflow of fragments with unclear provenance. It costs almost nothing, and it is also a precondition for the vendor indemnification discussed earlier.

This setting overlaps in purpose with after-the-fact snippet scanning. One finds fragments after they come in; the other blocks them before they come in. Which of the two to use, and to what extent, is a matter to decide by weighing the conditions above together with cost.

Putting the inflow paths and inspection methods covered so far in one place looks like this.

Figure 2. Code inflow paths and the methods that catch them

Where the blind spot of dependency-level SCA lies, and how snippet matching fills that spot, is the starting point for this judgment.

Criteria for the decision

There is a reason this decision is not simple. Snippet matching is effectively the only way to find code fragments that entered without being declared as a package, whether copied or AI-generated. Neither dependency-level SCA nor code-filtering settings catch all of those fragments. So a small residual area remains that only snippet matching fills. Yet at many companies, that small area rarely translates into actual loss, and snippet scanning costs tool spend and review effort. In the end, this comes down to deciding whether to spend that much to guard against this small risk.

There are four points to examine when making this decision.

• Does the company send code outside the organization? — The more it does, the greater the room for a copyleft obligation to actually arise.
• Does the company undergo external verification? — M&A due diligence or a customer audit can surface an obligation that had been buried until then.
• How much license risk is the company willing to accept? — There is no reported litigation precedent, but the legal question is not settled either. How to weigh this uncertainty is up to the company to decide.
• Are other inspection measures already in place? — If dependency-level SCA, an AI tool setting that blocks suggestions matching public code verbatim, and a policy excluding AGPL components are already running, the additional share that snippet scanning would catch shrinks accordingly.

One more point is worth adding. Snippet scanning does not have to be decided as an all-or-nothing choice, always on or never done. The occasions when an outside party actually looks into code provenance are largely predictable: M&A due diligence or a large customer’s audit. So one option is to run only dependency scanning and the blocking setting normally, and undergo a one-time snippet scan when such an occasion is anticipated.

Weighing the four points above and this operating approach against your own company’s situation, the answer to how much weight to give snippet scanning will differ from company to company. The exception is embedded software built without a manifest. There, snippet scanning is not a conditional supplement but a basic means of finding undeclared open source fragments.

Security vulnerabilities are a separate matter

Everything up to this point has been about licensing. Security vulnerabilities are a different axis, and the conditional conclusions above should not simply be applied here. If vulnerable open source is present in the code, it is dangerous whether or not it is distributed and whether or not it is audited, because even code that stays internal-only or sits in a pure SaaS backend is exposed to attack. So vulnerability inspection is broadly needed at nearly every company.

Tools handling security inspection fall broadly into two kinds.

• Dependency-level SCA — Looks at the name and version of declared open source libraries and checks them against known vulnerability (CVE) lists D1. Known vulnerabilities in libraries that AI pulled in are caught here.
• SAST (static analysis) — Finds risky coding patterns in the source code itself, regardless of where the code came from. This is where the primary security risk of AI code lies. One study found vulnerabilities in about 40% of 1,689 programs generated by Copilot D2.

Whether code was copied in or generated by AI, security vulnerability inspection is no different from any other code. SAST catches risky coding patterns in the code itself, and dependency-level SCA catches known vulnerabilities in libraries that were pulled in. Snippet scanning is a feature for finding license origin, so it is not a tool used for security inspection.

One exception worth noting: the rare case where code with a known vulnerability was copied in verbatim, yet it triggers no SAST pattern and appears in no dependency list. Catching this requires not the snippet feature that finds license origin, but an inspection that directly compares a vulnerable-code signature built from a CVE patch against your own code — vulnerable code clone detection D3. Academic tools and some commercial tools provide this.

Sources

A1. BakerHostetler (2025). Doe v. GitHub, Inc. — The Copilot Litigation. https://www.bakerlaw.com/the-copilot-litigation/ (accessed: 2026-06-08). — Claim-by-claim progress of the Copilot class action and its status pending before the Ninth Circuit Court of Appeals. ↩

A2. Claburn, T. (2024). Judge dismisses DMCA copyright claim in GitHub Copilot suit. The Register, 2024-07-08. https://www.theregister.com/2024/07/08/github_copilot_dmca/ (accessed: 2026-06-08). — Dismissal of the DMCA §1202(b) claim; 2 of the original 22 claims remain (license violation, breach of contract). ↩

A3. Pearl Cohen (2024). Copyright Claims Against GitHub, Microsoft, and OpenAI Largely Dismissed. https://www.pearlcohen.com/copyright-claims-against-github-microsoft-and-openai-largely-dismissed/ (accessed: 2026-06-08). — Overview of the dismissal of most claims and the claims that remain. ↩

A4. Goldstein Patent Law. Understanding the Copyright Merger Doctrine. https://www.goldsteinpatentlaw.com/copyright-merger-doctrine/ (accessed: 2026-06-08). — The merger doctrine, which denies copyrightability to functional code. ↩

A5. NYU Journal of Intellectual Property & Entertainment Law. Clarifying the De Minimis Doctrine in Copyright Law. https://jipel.law.nyu.edu/clarifying-the-de-minimis-doctrine-in-copyright-law/ (accessed: 2026-06-08). — The de minimis doctrine, which does not treat trivial copying as infringement. ↩

A6. OpenChain Project. OpenChain ISO/IEC 5230 — License Compliance. https://openchainproject.org/license-compliance (accessed: 2026-06-08). — That the standard defines process and roles but does not mandate a specific technique such as snippet scanning. ↩

A7. ISO. ISO/IEC 5230:2020 — Information technology — OpenChain Specification. https://www.iso.org/standard/81039.html (accessed: 2026-06-08). — Bibliographic information for the standard text. ↩

B1. Microsoft (2023-09-07). Microsoft announces new Copilot Copyright Commitment for customers. https://blogs.microsoft.com/on-the-issues/2023/09/07/copilot-copyright-commitment-ai-legal-concerns/ (accessed: 2026-06-08). — Intellectual property indemnification for paying commercial customers and the condition of keeping the built-in filtering feature enabled. ↩

B2. GitHub. GitHub Copilot (product page). https://github.com/features/copilot (accessed: 2026-06-08). — The existence and operation of the setting that blocks matches with public code. ↩

C1. TechTarget. AI lawsuits explained: Who’s getting sued?. https://www.techtarget.com/whatis/feature/AI-lawsuits-explained-Whos-getting-sued (accessed: 2026-06-08). — Evidence that lawsuit defendants have been concentrated among vendors, with no reported cases of adopting companies being sued. ↩

C2. Microsoft Community Hub. Demystifying GitHub Copilot Security Controls. https://techcommunity.microsoft.com/blog/azuredevcommunityblog/demystifying-github-copilot-security-controls-easing-concerns-for-organizational/4468193 (accessed: 2026-06-08). — The roughly 150-character match threshold for the public-code-match blocking setting and the roughly 1% duplication rate. ↩

C3. Mend.io. The SaaS Loophole In GPL Open Source Licenses. https://www.mend.io/blog/the-saas-loophole-in-gpl-open-source-licenses/ (accessed: 2026-06-08). — The distribution trigger for copyleft, why internal use and SaaS do not qualify, and the AGPL Section 13 exception. ↩

C4. Revenera. Understanding the SaaS Loophole in GPL. https://www.revenera.com/blog/software-composition-analysis/understanding-the-saas-loophole-in-gpl/ (accessed: 2026-06-08). — Additional support on the distribution trigger and the SaaS exception. ↩

C5. TechTarget. Microsoft Copilot Copyright Commitment explained. https://www.techtarget.com/searchenterprisedesktop/tip/Microsoft-Copilot-Copyright-Commitment-explained (accessed: 2026-06-08). — Additional support on the scope and conditions of the indemnification. ↩

C6. Baltes, S. & Diehl, S. (2019). Usage and Attribution of Stack Overflow Code Snippets in GitHub Projects. Empirical Software Engineering, arXiv:1802.02938. https://arxiv.org/abs/1802.02938 (accessed: 2026-06-08). — An empirical study finding that the rate of license-compliant use of Stack Overflow code (CC BY-SA) in GitHub projects was at most 1.8%. ↩

D1. Cycode. What Is Software Composition Analysis (SCA)?. https://cycode.com/blog/what-is-software-composition-analysis-sca/ (accessed: 2026-06-08). — How SCA finds vulnerabilities by checking components and versions against CVE/NVD. ↩

D2. Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. IEEE S&P 2022, arXiv:2108.09293. https://arxiv.org/abs/2108.09293 (accessed: 2026-06-08). — Vulnerabilities in about 40% of 1,689 programs generated across 89 scenarios. ↩

D3. Kim, S., Woo, S., Lee, H., & Oh, H. (2017). VUDDY: A Scalable Approach for Vulnerable Code Clone Discovery. IEEE S&P 2017. https://seulbae-security.github.io/pubs/vuddy-sp17.pdf (accessed: 2026-06-08). — The problem of vulnerabilities propagating through copied code and copies remaining unpatched even after an upstream patch, and detection of this. ↩

Research as of: 2026-06-08

Rockchip and FFmpeg: A License Dispute Case Study

Hello.

I have put together a summary of the Rockchip and FFmpeg license dispute, which became a hot topic in the embedded Linux industry. I first wrote this article in December 2025, when the repository was taken down. Since then, Rockchip has taken action and the repository was restored. I have thoroughly revised the article to reflect these developments, and replaced the evidence with the actual code that became available for review once the repository reopened.

This case is not just about one company’s mistake. It also shows the kind of supply chain risk that comes with taking an SDK or BSP provided by a hardware vendor and using it as-is, and how a misunderstanding of licensing can inflate a simple fix into a two-year-long task.

1. Overview of the Incident

In December 2025, Rockchip’s GitHub repository rockchip-linux/mpp (Media Process Platform) was disabled. This was in response to a DMCA (Digital Millennium Copyright Act) takedown notice filed by an FFmpeg contributor.

Rockchip has provided a middleware library called mpp for hardware video acceleration on its chipsets (such as the RK3588). The problem is that this library’s stream header parser code came from FFmpeg’s libavcodec. Simply taking the code was not, by itself, the problem; the compliance violation arose from three overlapping acts. Rockchip deleted the original copyright notices, rewrote the headers to make it appear that Rockchip was the author, and redistributed code that had been LGPL 2.1 under Apache-2.0.

The notice specified exactly these three acts, and stated as grounds for infringement that this is “evident from the identical code structure and comments, including commented-out calls to FFmpeg internal functions retained under their original names.”

Timeline

Figure 1. Dispute timeline (Source: DMCA notice, MPP commit history, Issues 530 and 73, Internet Archive. Verified 2026-07-23.)

The exact date the repository reopened was not publicly disclosed. Internet Archive snapshots returned HTTP 451 (Unavailable for Legal Reasons) through March 6, 2026, and new forks began appearing starting March 11, so the reopening is estimated to have occurred sometime in between. The repository was inactive for roughly 10 weeks.

One point worth noting about the DMCA process: it is commonly said that a platform must take content down within a set time after receiving a notice, but 17 U.S.C. §512(c)(1)(C) of the US Copyright Act only uses the term “expeditiously,” with no specific deadline. As a matter of operating policy, GitHub gives repository owners roughly one business day to self-correct when a notice identifies specific files, before taking the repository down.

2. What Was Copied

The notice identified 12 infringing files: 4 related to AV1, 3 related to H.265, and 5 related to VP9. With the repository restored, it became possible to pull the commit as it stood at the time infringement was alleged and compare it directly against the FFmpeg original. Below are the results of that comparison.

Copyright Header Replacement

The header from FFmpeg’s libavcodec/vpx_rac.h:

/*
 * Copyright (C) 2006  Aurelien Jacobs <aurel@gnuage.org>
 *
 * This file is part of FFmpeg.
 *
 * FFmpeg is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
...
*/

The same location in MPP’s mpp/codec/dec/vp9/vpx_rac.h:

/*
*
* Copyright 2015 Rockchip Electronics Co. LTD
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
...
*/

The name of the original author, Aurelien Jacobs, the LGPL terms, and any reference to FFmpeg all disappeared, replaced with an Apache-2.0 header under Rockchip’s name. The original authors of vpx_rac.c, Fiona Glaser, and of vp9data.h, Ronald S. Bultje and Clément Bœsch, likewise vanished without a trace.

Matching Function Bodies

Let’s compare the core function of the VP9 range coder.

FFmpeg libavcodec/vpx_rac.h:

static av_always_inline int vpx_rac_get_prob(VPXRangeCoder *c, uint8_t prob)
{
    unsigned int code_word = vpx_rac_renorm(c);
    unsigned int low = 1 + (((c->high - 1) * prob) >> 8);
    unsigned int low_shift = low << 16;
    int bit = code_word >= low_shift;

    c->high = bit ? c->high - low : low;
    c->code_word = bit ? code_word - low_shift : code_word;

    return bit;
}

MPP mpp/codec/dec/vp9/vpx_rac.c (commit 14667441, as of the time infringement was alleged):

rk_s32 vpx_rac_get_prob(VpxRangeCoder *c, uint8_t prob)
{
    unsigned int code_word = vpx_rac_renorm(c);
    unsigned int low = 1 + (((c->high - 1) * prob) >> 8);
    unsigned int low_shift = low << 16;
    int bit = code_word >= low_shift;

    c->high = bit ? c->high - low : low;
    c->code_word = bit ? code_word - low_shift : code_word;

    return bit;
}

The only changes are dropping the inline specifier and changing the return type from int to rk_s32. The function body is identical down to the whitespace, and the uint8_t parameter type and unsigned int in the body remain exactly as written in FFmpeg.

Traces Left in the Code

Comments unrelated to functionality are exactly what reveal provenance. The following comments remained untouched in the MPP files.

// branchy variant, to be used where there's a branch based on the bit decoded
// rounding is different than vpx_rac_get, is vpx_rac_get wrong?

The first is a word-for-word match with FFmpeg’s vpx_rac.h. The second is a question the FFmpeg developer posed to themselves; the original refers to vp56_rac_get, and MPP simply substituted its own function name while carrying the comment over unchanged. A rhetorical question-style comment like this could not coincidentally appear as an identical sentence in independently written code.

At the top of the file, a description referring to a codec that MPP doesn’t even support was left in place.

/**
 * vp56 specific range coder implementation
 */

In FFmpeg, this description exists because the file is shared across VP5 through VP9, but it carried straight over into MPP, which doesn’t handle VP5 or VP6 at all. There is also a spot where an alignment macro was redefined to do nothing.

#define DECLARE_ALIGNED(n,t,v)      t v

This macro name exists in both FFmpeg and libvpx, so by itself it doesn’t establish provenance. However, where it is used tracks FFmpeg exactly. FFmpeg’s vp56.h declares the first field of its motion vector struct as DECLARE_ALIGNED(4, int16_t, x);, and MPP’s corresponding struct carries this line over verbatim. The equivalent struct in libvpx does not use this macro at all.

A match at this level would be unlikely to survive a substantial similarity analysis under copyright law. Changing type names or macros alone does not make a work independent. This approach is sometimes used when absorbing external open source into an internal codebase, and this case demonstrates exactly the risk that carries.

The Probability Tables Are a Somewhat Different Matter

The codec’s probability tables, however, are an area where snap judgments should be avoided. These figures are constants defined in the VP9 bitstream specification, and comments like /* a/l both not split */ next to the values are not expressions FFmpeg created either. The same wording already appears in libvpx (Google, BSD-family license), the reference implementation of VP9. FFmpeg, too, should be understood as having taken these from libvpx.

So the fact that the comments match does not by itself tell us where they were taken from. Placing the three codebases side by side, the point where they diverge is not the wording but the formatting.

libvpx:

      { 222, 34, 30 },  // a/l both not split

FFmpeg:

            { 222,  34,  30 } /* a/l both not split */,

libvpx places a comma and then attaches a // comment, while FFmpeg places a /* */ comment before the comma and aligns the numbers to two-character width. MPP’s version matches FFmpeg’s format byte-for-byte. While the values and wording trace back to libvpx, the formatting fits the conclusion that the actual copying source was the FFmpeg version.

The reason this distinction matters is clear. In areas where implementing the same algorithm naturally produces similar code, similarity by itself is not grounds for infringement. One has to pin down which version’s specific traces were followed.

3. Why It Took 22 Months

This is the part of the case with the most to learn from. The issue was first made public on February 23, 2024. FFmpeg’s official account posted the callout on X, and on the same day, the developer maintaining the ffmpeg-rockchip fork opened Issue 530 on the MPP repository to relay it. It took 22 months from there to the DMCA notice.

Contrary to what is commonly assumed, Rockchip did not stay silent. The person in charge issued a public apology in February 2024, and continued to respond afterward with statements such as “it’s delayed,” “it’s in progress,” and “the refactor is on hold.” This was a case of responding without correcting.

Rockchip later revealed the reason for the delay.

But after studying the license details, we realised that simply restoring
the LGPL headers would convert the entire MPP library to LGPL-licensed code.
While this is acceptable for dynamically linked libraries, it would mandate
that any project statically linking MPP also adopt the LGPL license.
To avoid this mixed-license scenario, we decided to develop a brand-new parser.

Rockchip’s reasoning was that restoring the LGPL headers would make all of MPP LGPL-licensed, forcing even customer projects that statically link MPP to adopt the LGPL as well. To avoid that outcome, they decided to write a new parser from scratch — but they underestimated the amount of work involved, and progress stalled as it was crowded out by day-to-day work.

This reasoning is only half right. The first part has a basis. If FFmpeg code was incorporated into MPP, MPP becomes a “work based on the Library” as that term is used in LGPL 2.1, and Section 2(c) requires that the entire work be licensed under the terms of the LGPL.

The second part is different. Section 6 provides an exception for combined works, including those using static linking.

6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, ...

A combined work can be distributed under terms of the distributor’s choosing. The conditions are that customers must be permitted to modify it for their own use, reverse engineering for debugging must be permitted, and either a re-linkable form must be provided or a shared library mechanism must be used. A customer company that statically links MPP is not required to release its own product under the LGPL.

Because the license clause was misread, a task that would have ended with restoring the headers instead inflated into a full parser rewrite, and because that task was heavy, it sat neglected for nearly two years. Distribution in a state of violation continued the entire time. This is the kind of way costs balloon when a compliance judgment is wrong.

4. Rockchip’s Response and Remaining Issues

After the DMCA notice, Rockchip moved quickly. Within a little over ten days of the notice, it restored the LGPL headers on the 12 identified files, and then went on to replace the VP9, AV1, and H.265 parsers in turn. In mid-February 2026, it announced that it had “removed all FFmpeg LGPL code” and requested review.

A substantial portion of this was actually carried out. Eight of the 12 identified files disappeared from the repository, and the range coder was replaced with an implementation with an entirely different function naming scheme and structure. Scanning all 778 source files in the repository for FFmpeg-specific identifiers such as ff_vp9_, av_always_inline, AVCodecContext, and libavcodec turned up none. No source file mentions the LGPL either. The only trace left is the title of the restoration commit in the changelog document.

Still, a few things remain.

The identified file vp9data.h was not deleted; it was renamed to vp9d_codec.c. In the commit history, this file’s status is shown as a rename, not a deletion. In the process, the header was changed again. The FFmpeg copyright notice and LGPL terms that the LGPL-restoration commit had added were removed, reverting to sole Rockchip copyright with an Apache-2.0 notice. The two commits were made the same day, three hours apart. Of 1,299 lines, 1,045 remain unchanged, and the probability tables and comments also remain in the FFmpeg formatting seen earlier.

Files not listed in the notice were left untouched. In the hardware abstraction layer’s hal_vp9d_com.c, the VP9 probability tables discussed earlier remain in FFmpeg’s exact formatting. This bears out the caveat the notice attached before its file list: “(and possibly others).”

Whether this portion constitutes infringement is hard to say definitively. Since the values and comment wording trace back to libvpx and the specification document, the scope of copyright protection itself is open to dispute.

Above all, there is no public record that FFmpeg has reviewed or accepted this state of affairs. Issue 530 was closed on April 1, 2026, but it was closed by the third-party fork maintainer who had opened it, not by the FFmpeg project. That is not the same as a release from the rights holder. Neither side has stated a policy on how already-distributed past versions will be handled.

5. Why License Laundering Is Dangerous

It is easy to assume that “code released under Apache-2.0 is safe.” This case shows that Apache-2.0 code with an opaque copyright provenance can actually be a greater risk. This is because it is the code’s actual origin, not its stated license, that determines the obligations that attach to it.

Mapping each violation to the relevant clause looks like this.

Falsely altering attribution is treated differently depending on the country. In Korea and France, this constitutes infringement of the right of attribution, one of the moral rights of authors. US copyright law has no general moral rights regime; the Visual Artists Rights Act (VARA) applies only, and narrowly, to works of visual art.

What the Correct Structure Looks Like

The Linux kernel provides a standard interface called V4L2 (Video for Linux 2) for hardware acceleration. In this structure, FFmpeg is left unmodified in user space, and hardware-dependent code is kept separate in the kernel driver.

Figure 2. Comparison of hardware acceleration integration structures

Because FFmpeg and the kernel driver are cleanly separated into user space and kernel space, there is no longer any reason for a vendor to tear apart and redistribute FFmpeg code itself.

Progress in this direction was led not by Rockchip but by Collabora. Decoder support for the RK3588’s VDPU381 and the RK3576’s VDPU383 was merged into mainline in February 2026 and landed in Linux 7.0 (April 2026). The current scope covers H.264 and H.265, while AV1, VP9, and multi-core decoding remain as follow-up work.

One point of caution: the nyanmisaka/ffmpeg-rockchip fork, commonly mentioned by developers using Rockchip hardware as an alternative, does not replace MPP. This project is an FFmpeg fork that implements hardware acceleration by calling MPP and librga, so it does not avoid MPP’s provenance problem. To escape the dependency on MPP, one must use the mainline V4L2 path.

6. The Allwinner Case, Ten Years Earlier

There is a history of embedded chip vendors repeating the same mistake with multimedia codec licenses. The closest precedent is Allwinner’s CedarX from 2015.

In March 2015, Allwinner put out an “LGPL release,” but in practice it amounted to no more than an API layer wrapping a closed binary. The eventual resolution was that a Cedrus driver, reverse-engineered by the community, was merged upstream. This is structurally similar to how, in the Rockchip case, the V4L2 driver work was led by Collabora.

There are also cases where a license violation led to actual monetary liability. On February 14, 2024, the Paris Court of Appeal ordered damages of 800,000 euros in the lawsuit Entr’ouvert brought against Orange. This consisted of 500,000 euros in economic damages, 150,000 euros for infringement of moral rights, and 150,000 euros in restitution of unjust enrichment, with 60,000 euros in litigation costs added separately. This was the conclusion reached 13 years after the suit was filed in 2011, following a first-instance trial, an appeal, and a remand from the Court of Cassation. This ruling matters because it treated the open source license violation as copyright infringement rather than as a breach of contract.

In Germany, the Hamburg Regional Court held in the 2013 Fantec case that “a supplier’s assurance of license compliance alone does not provide a defense; the distributor must verify it independently.” This applies directly to any company that takes a BSP from an SoC vendor and incorporates it into a product.

7. What Companies Should Check

The same problem may be hiding in an SDK or BSP provided by a vendor. Here are three things to check.

First, a supply-chain license audit. You need to verify that a vendor-supplied library — especially code related to multimedia, graphics, or AI acceleration — retains the original author’s license. Even if a vendor claims Apache-2.0 or MIT, if the internal code came from a GPL or LGPL project, the entire product is exposed to risk. Scanning vendor-supplied code with a source code analysis tool such as Black Duck or FOSSID can surface original license notices or copyright markings left inside. As this case shows, the decisive clue is often found in comments unrelated to functionality.

Second, check whether the vendor’s driver is upstream in the mainline kernel. Code merged into mainline has gone through review and license scrutiny by multiple developers, giving it higher reliability than a vendor’s own self-managed repository. That said, being mainlined and being feature-complete are separate questions, so you should check the scope of support alongside it.

Third, internal development rules. When bringing in external open source, committing changes that delete the copyright header at the top of a file or change it to the company’s own name should never be permitted. This can be read as willful infringement and becomes damaging evidence in any later dispute. If integration is needed, prefer a linking approach, and make it a standing rule to always preserve the original author’s license and copyright notice.

Summary

The Rockchip case shows that releasing source and complying with an open source license are two different things. LGPL code cannot be relicensed under something like Apache-2.0 without the copyright holder’s consent, and deleting copyright notices and changing attribution are infringements in themselves.

The more practical lesson lies in how the delay came about. Because the license clause was misread, a task that should have ended with restoring the headers instead became a full parser rewrite, and its weight left it neglected for nearly two years. License determinations should be made together with legal or compliance teams, and the larger the apparent cost of a remedy looks, the more that determination needs to be double-checked.

Rather than simply trusting software as delivered by a vendor, it is necessary to periodically check, using a source code analysis tool, what licenses and copyright notices are present, and to have a process in place for using those results to sort out the division of responsibility with the vendor.

References

• FFmpeg DMCA Notice on GitHub (2025-12-18)
• rockchip-linux/mpp Issue #530 — LGPL license violation reported by upstream FFmpeg
• HermanChen/mpp Issue #73 — Official explanation from Rockchip
• rockchip-linux/mpp repository
• GNU LGPL 2.1, original text
• 17 U.S.C. §512 (Cornell LII)
• Hackaday: GitHub Disables Rockchip’s Linux MPP Repository After DMCA Request
• Tom’s Hardware: Rockchip Repository Disabled
• Collabora: RK3588 and RK3576 video decoders support merged in the upstream Linux Kernel
• libvpx (VP9 reference implementation)
• CNX Software: Allwinner’s CedarX May Infringe on Open Source Licenses (2015-02-26)
• CNX Software: Allwinner CedarX GPL/LGPL Compliance Update (2015-03-23)
• nyanmisaka/ffmpeg-rockchip

Revised on July 23, 2026 to reflect subsequent developments.

The AVM Lawsuit: Revisiting LGPL-2.1 User Rights and the Obligation to Provide Installation Information

This post is based on Ars Technica’s article “German router maker is latest company to inadvertently clarify the LGPL license”. The article covers the details of the lawsuit between AVM and Sebastian Steck and the importance of LGPL license compliance.

1. Case Overview

On January 9, 2025, the Software Freedom Conservancy (SFC) announced that the lawsuit it had filed against AVM, a German network equipment manufacturer, had concluded. The core of this lawsuit concerned the rights of users specified in the GNU Lesser General Public License (LGPL) version 2.1, particularly the obligation to provide installation information.

Sebastian Steck, a German software developer, purchased an AVM router in May 2021 and discovered that the source code provided by AVM did not allow him to reinstall modified software on the router. Steck demanded that AVM “provide the complete source code and the compilation and installation scripts for the uClibc, libblkid, libexif, and libosip2 libraries.” When AVM failed to remedy this, Steck filed a lawsuit in a Berlin court in July 2023.

As a result of the lawsuit, the German court ordered AVM to pay Steck’s attorney’s fees. AVM decided not to appeal this decision. The ruling specifies the allocation of litigation costs, which reflects the economic value and importance of open source license compliance issues.

Disclaimer:

This post was not written by a legal professional and cannot be used as a legal basis. For specific situations related to license and legal issues, please be sure to seek advice from a legal professional. Also, this post was written based on publicly available information and may not reflect the positions of all parties to the lawsuit. Please refer to the original text for the full content and context of the ruling.

2. Background and Progress of the Lawsuit

Background

In May 2021, German software developer Sebastian Steck purchased AVM’s popular Fritz!Box 4020 router. Steck requested the source code used in the firmware of this router, and this is where the problem arose. The source code AVM provided did not allow him to reinstall modified software on the router.

Legal Basis of the Lawsuit

An important characteristic of this lawsuit is that Sebastian Steck was able to file the lawsuit even though he was not the copyright holder of the LGPL-2.1 software. This is because the LGPL-2.1 license has the character of a contract for the benefit of third parties. According to the complaint, users also have the right to receive the source code under LGPL-2.1:

“This license agreement represents a genuine contract in favor of third parties in accordance with Section 328 of the German Civil Code (BGB), namely in favor of the users who receive the software in object code and, in accordance with the wording of the LGPL-2.1 license conditions to be handed over to them, have a direct right to the transfer of the complete corresponding source code.”

This legal basis significantly strengthens the rights of open source software users. When a manufacturer fails to properly fulfill its license obligations, not only the copyright holder but also ordinary users can now take legal action.

Progress of the Lawsuit

1. May 7, 2021: Steck requested the source code for firmware version 6.83 of the Fritz!Box 4020 from AVM
2. May 11, 2021: An AVM subsidiary provided a source code download link
3. May 14, 2021: Steck pointed out the incompleteness of the provided source code and demanded a correction
4. January 12, 2023: Steck’s attorney explained the legal situation to AVM and demanded correction of the source code
5. March 9, 2023: Steck additionally requested the source code for firmware version 7.02
6. July 27, 2023: Steck filed a lawsuit in the Berlin Regional Court
7. Several months after the lawsuit was filed: AVM provided Steck with all the source code requested, including “the scripts that control library installation”
8. January 9, 2025: The German court ordered AVM to pay Steck’s attorney’s fees. This decision includes a ruling on litigation costs, and AVM decided not to appeal this decision

The Plaintiff’s Claims

The violations of LGPL-2.1 by AVM that Sebastian Steck raised in the complaint are as follows:

1. Failure to provide compilation and installation scripts: The source code AVM initially provided lacked the compilation and installation scripts required by LGPL-2.1. These scripts are an essential element needed to convert the source code into an executable program and install that program on the device.

2. Failure to provide environment variable information: Environment variable configuration information such as KERNEL_LAYOUT, which is essential to the compilation process, was not provided. Environment variables are important information that configure the environment in which a program runs, and without them the source code cannot be compiled properly.

3. Inability to install permanently: The information AVM provided did not allow permanent installation of the modified library on the Fritz!Box. Steck argued that this violates a core requirement of LGPL-2.1, namely that users must be able to continuously use modified software on their own device.

4. Inability to build a firmware image: The provided source code did not allow building an installable firmware image for the Fritz!Box. A firmware image is a file containing the router’s operating system and functionality, and being unable to build one effectively means the software cannot be modified and reinstalled.

Steck argued that these matters infringe on “user software freedom,” a core principle of the LGPL-2.1 license. According to his argument, merely providing the source code is not enough; users must be able to actually modify the code and reinstall it on the device.

[Note] An excerpt from the complaint disclosed by SFC:

“The information required for the reinstallation of the compiled program libraries on the Fritz!Box (“installation script”) was also deliberately withheld from the plaintiff. Upon request, the plaintiff only received information that could be used to load the libraries in dispute into the working memory (RAM). However, this is not a sufficient installation on the Fritz!Box because the copy is only created temporarily, meaning “fleetingly [volatile].” When the Fritz!Box is switched off and restarted, the modified versions of the LGPL 2.1 libraries would no longer be present on the device, and the versions created by the defendant would be used instead. This is diametrically opposed to the purpose of the LGPL-2.1, namely, to be able to customize and reinstall the software.”

3. Summary of the Ruling

The ruling includes a decision on litigation costs and specifies that AVM must pay Steck’s attorney’s fees. This reflects the economic value and importance of open source license compliance issues. AVM decided not to appeal this decision.

4. Implications and Various Interpretations

1. LGPL-2.1’s obligation to provide installation information: The complaint raised the claim that AVM must provide installation information under the LGPL-2.1 license. This includes the scripts or information needed to actually make the source code usable. The ruling does not explicitly include this content, but the decision to burden the defendant with litigation costs during the proceedings reflects the strengthening of user rights and the importance of providing installation information. However, the installation information required in this case appears to be at the level of the installation scripts required under GPL/LGPL v2, not the GPL/LGPL-3.0 level.

2. Strengthening of users’ legal rights: This decision allows open source software users to take legal action directly against license violations. This is expected to strengthen the power of the open source community and further promote license compliance by companies. In particular, the fact that the third-party beneficiary logic was also recognized in Germany is an important development.

3. Improved self-correcting capacity of the open source ecosystem: Since not only copyright holders but also ordinary users can now demand license compliance, the self-correcting capacity of the open source ecosystem is expected to improve significantly. This contributes to maintaining the freedom of open source software and a collaborative development environment.

4. Expanded scope of corporate responsibility: Companies must now fulfill their LGPL-2.1 license obligations not only to copyright holders but to all users. This expands the scope of corporate responsibility and will require more thorough license compliance. This can increase the transparency and reliability of open source software use.

5. Reconfirming the importance of open source license compliance: Companies must more thoroughly comply with the relevant license terms when using open source software. They must recognize that the obligations under LGPL are not light simply because it is LGPL. However, it is difficult to say that this decision brought a major change in the legal interpretation of GPL installation information. AVM voluntarily provided the source code and installation scripts; the court did not issue a ruling on the interpretation of GPL/LGPL.

6. Existence of various interpretations: Various interpretations exist regarding this case. There is also a view that the Software Freedom Conservancy (SFC) somewhat overstates the significance of this case, because the ruling itself does not present a clear judgment on the interpretation of GPL/LGPL. These various interpretations show that the discussion on open source licenses and user rights is still ongoing.

Considering these implications and various interpretations, companies should improve their internal processes for open source license compliance and respond to user demands more quickly and proactively. Similar cases in the future are expected to further clarify these issues.

Key Points of the EU's Three Major Digital Regulations That Korean Software Companies Need to Know

Introduction

Three major pieces of legislation the European Union (EU) has recently introduced carry very significant implications for Korean companies. The Product Liability Directive (PLD), the Cyber Resilience Act (CRA), and the AI Act present a comprehensive regulatory framework governing the development, deployment, and use of software and AI systems.

These pieces of legislation matter to Korean companies for the following reasons:

1. Access to the EU market: The EU is one of the largest single markets in the world, and many Korean companies aim to enter it. Failure to comply with these laws can restrict access to the EU market.
2. Setting a global standard: EU regulation tends to become a de facto global standard. This is the so-called ‘Brussels effect’, and other countries are likely to introduce similar regulations.
3. Expanded corporate liability: These laws significantly expand the scope of corporate liability. In particular, the strict liability principle under the PLD could pose a new challenge for Korean companies.

Important perspectives for Korean companies to keep in mind when approaching these laws include the following:

• Proactive response: Companies should prepare in advance of the laws taking effect in order to secure a competitive advantage.
• Integrated approach: Rather than viewing each law individually, companies should recognize them as a single, overall shift in the regulatory environment.
• Balancing innovation and regulatory compliance: Care must be taken not to stifle innovation in the process of complying with regulation.

Now let’s look at the key content of each law.

1. Product Liability Directive (PLD)

1.1 Overview

The Product Liability Directive (PLD) aims to modernize the EU’s legal framework for product liability and adapt it to the digital age. This directive introduces a strict liability regime for all products, including software and AI systems.

1.2 Key Changes

1. Inclusion of software in the definition of a product: The PLD expands the definition of a “product” to explicitly include software. This applies to all kinds of software, including operating systems, firmware, computer programs, applications, and AI systems.
2. Strict liability principle: The PLD introduces the principle of ‘strict liability’. This means that a manufacturer can be held liable for damage caused by a defect in a product even without fault.
3. Expanded scope of damage: The PLD expands the scope of damage to include not only harm to persons or property but also data corruption.

1.3 Scope of Application

The PLD applies to all products placed on the market or made available as a service in the EU. This applies even to products manufactured outside the EU, if they are sold in the EU market.

1.4 Key Obligations

1.5 Implementation Timeline

The PLD is expected to be published in November 2024, with penalties applying from 2026, two years later.

1.6 Impact on Companies

1. Expanded scope of liability: Software companies must now take responsibility for all kinds of damage their products could cause. This includes not only physical harm but also data loss or privacy breaches.
2. Changes to product design and development processes: Companies must consider safety and security from the product design stage onward. This means applying the ‘Security by Design’ principle.
3. Stronger documentation and transparency: Companies must provide more detailed and clear documentation regarding a product’s functionality, risks, safety features, and more.
4. Continuous monitoring and updates: Companies must continue to monitor products after they are placed on the market and provide security updates where necessary.

2. Cyber Resilience Act (CRA)

2.1 Overview

The Cyber Resilience Act (CRA) is a piece of legislation introduced in the EU to strengthen the cybersecurity of digital products. This law applies to all products with digital elements (PDEs), including software.

2.2 Scope of Application

The CRA applies to all PDEs sold in the EU market. This applies even to products manufactured outside the EU, if they are sold in the EU market.

2.3 Key Requirements

1. Essential cybersecurity requirements: Manufacturers must develop, produce, and distribute products that meet “essential cybersecurity requirements” appropriate to the product’s risk.
2. Cybersecurity risk assessment: Manufacturers must carry out a cybersecurity risk assessment related to the PDE. This assessment must be updated throughout the support period and considered across the entire product lifecycle.
3. Vulnerability management: PDEs must be placed on the market free of known vulnerabilities, and security updates for vulnerabilities must be provided without delay. Resolved vulnerabilities must also be publicly disclosed.
4. Support period: A product’s support period must correspond to its expected duration of use and must be at least 5 years. The end date of the support period (month and year) must be accessible to the user at the time of purchase.
5. Software Bill of Materials (SBOM): Manufacturers must identify and document the product’s components and vulnerabilities. This includes, at minimum, preparing a Software Bill of Materials (SBOM) covering the product’s top-level dependencies.
6. Testing: Manufacturers must regularly test the security of their products.
7. Vulnerability reporting: Manufacturers must establish a vulnerability reporting policy and make it publicly available.

2.4 Implementation Timeline

The CRA is expected to enter into force in the second half of 2024, and manufacturers must bring compliant products to the EU market by 2027.

2.5 Impact on Companies

2.6 Company Response Measures

1. Adopt security-focused design: Introduce a design methodology that considers security from the earliest stage of product development.
2. Build an SBOM management system: Build a system to track and manage all software components used in a product.
3. Improve vulnerability management processes: Establish a system to quickly discover and respond to vulnerabilities.
4. Establish a long-term support plan: Establish a long-term support plan that takes the product’s expected lifetime into account.
5. Strengthen security testing: Introduce a regular, systematic security testing process.
6. Improve documentation and reporting systems: Build a detailed documentation and reporting system that meets CRA requirements.
7. Train personnel and build capacity: Hire cybersecurity experts or build up the capacity of existing staff.

The CRA is expected to significantly strengthen the cybersecurity of digital products. Companies should treat this not as mere regulatory compliance but as an opportunity to improve product quality and reliability. A proactive response can secure competitiveness in the EU market and, further, an edge in the global market as well.

3. AI Act

3.1 Overview

The AI Act is the EU’s first comprehensive legal framework governing the development, deployment, and use of AI systems. This law aims to address the risks of AI systems while enabling Europe to play a leading role globally.

3.2 Classification of AI Systems

The AI Act classifies AI systems by risk level as follows:

1. Unacceptable risk
2. High risk
3. Limited risk
4. Minimal risk

3.3 Key Requirements

1. Requirements for high-risk AI systems: High-risk AI systems must comply with the following strict obligations before being placed on the market:
   • An adequate risk assessment and mitigation system
   • High-quality datasets to minimize risk and discriminatory outcomes
   • Activity logging to ensure traceability of results
   • Detailed documentation providing authorities with all the information needed to assess compliance
   • Clear and adequate information provided to deployers
   • Appropriate human oversight measures to minimize risk
   • A high level of robustness, security, and accuracy
2. Requirements for limited-risk AI systems: Specific transparency obligations apply to limited-risk AI systems. For example, when using a chatbot, users must be aware that they are interacting with a machine.
3. Requirements for General-Purpose AI models: Transparency obligations apply to General-Purpose AI models. Additional risk management obligations apply to particularly powerful and influential models.

3.4 Implementation Timeline

The AI Act entered into force on August 1, 2024, and will fully apply from August 2026, two years later. However, some provisions apply sooner:

• Prohibitions apply after 6 months
• Governance rules and obligations for General-Purpose AI models apply after 12 months
• Rules for AI systems embedded in regulated products apply after 36 months

3.5 Impact on Companies

3.6 Company Response Measures to Prepare for Implementation

1. Assess and classify AI systems: Companies must assess their AI systems and classify them according to the risk categories under the AI Act. This allows them to identify the regulatory requirements applicable to each system.
2. Establish a regulatory compliance roadmap: Companies must establish a phased regulatory compliance roadmap aligned with the AI Act’s implementation timeline. This should include the necessary resource allocation, process improvements, and technology development.
3. Secure and train specialized personnel: Companies must secure specialized personnel for AI regulatory compliance and train existing employees. This should cover expertise across various fields, including law, technology, and ethics.
4. Improve documentation and reporting systems: Companies must thoroughly document the development, testing, deployment, and monitoring processes of AI systems, and build a system to report to regulators as needed.
5. Strengthen stakeholder communication: Companies must actively communicate with customers, partners, investors, and other stakeholders about the impact of the AI Act and the company’s response measures.

3.7 Key Features and Significance of the AI Act

• Risk-based approach: The AI Act adopts an approach that varies the intensity of regulation according to the risk level of the AI system. This is a balanced approach that allows necessary regulation to be applied without stifling innovation.
• Strengthened transparency and accountability: This law significantly strengthens transparency and accountability throughout the development and use of AI systems. This is expected to help increase social trust in AI.
• Promoting ethical AI development: By requiring AI systems to respect the EU’s fundamental values and rights, the AI Act promotes ethical and responsible AI development.
• Setting a global standard: EU AI regulation is likely to become a global standard. This can be an opportunity for EU companies to gain competitiveness in the global market.

The AI Act is a comprehensive regulatory framework that takes into account both the advancement of AI technology and its social impact. This law aims to increase the safety and reliability of AI while also promoting innovation. By proactively responding to these regulatory changes, companies will be able to manage risk and create new opportunities. The AI Act should be used not merely as a target for regulatory compliance, but as a guideline for responsible and sustainable AI development.

4. Interrelationship Among the Three Laws

The EU’s three major laws (PLD, CRA, AI Act) are closely related to one another and together form a comprehensive regulatory framework for digital products and services. Understanding this interrelationship is important for companies in establishing an effective response strategy.

4.1 Common Regulatory Purposes

All three laws share the common goal of increasing the safety and reliability of digital technology.

4.2 Overlapping Scope of Application

In many cases, a single product or service may be subject to multiple laws at once. For example, an IoT device that includes AI functionality could be subject to all three laws as follows:

• PLD: from a product liability perspective
• CRA: cybersecurity requirements
• AI Act: regulation of AI functionality

4.3 The Need for an Integrated Approach

Rather than responding to these laws individually, companies should adopt an integrated approach. This offers the following benefits:

1. Avoiding duplicated work
2. Establishing a consistent regulatory compliance strategy
3. Efficient use of resources
4. Strengthened overall risk management

5. Recommendations for Korean Companies

The following are key recommendations for Korean companies to consider in responding to the EU’s new regulatory environment.

5.1 Form a Regulatory Compliance Task Force

• Form a multidisciplinary team of legal, technical, and business experts
• Assign this team the role of continuously monitoring and analyzing EU regulatory trends
• Build a system for smooth communication and cooperation with other departments within the company

5.2 Review the Product and Service Portfolio

• Assess whether current and upcoming products/services are subject to EU regulation
• Identify the specific regulatory requirements applicable to each product/service
• Establish a plan to redesign or improve products/services as needed

5.3 Strengthen Documentation and Transparency

• Build a detailed documentation system covering the product development, testing, and deployment process
• Introduce a process for preparing and managing an SBOM (Software Bill of Materials)
• Develop a way to explain the decision-making process of AI systems

5.4 Strengthen the Risk Management Framework

• Establish a risk assessment and management process spanning the entire product lifecycle
• Build a system for continuous monitoring of and response to cybersecurity risk
• Introduce an ethical impact assessment for AI systems

5.5 Build Human Capacity

• Hire or develop experts on EU regulation
• Run EU regulatory training programs for employees
• Build cooperative relationships with external experts and consulting firms

5.6 Reassess R&D and Innovation Strategy

• Redesign the R&D process with regulatory compliance in mind
• Apply the ‘Security by Design’ and ‘Privacy by Design’ principles
• Establish guidelines for ethical AI development

5.7 Adjust the Business Model and Strategy

• Analyze the impact of EU regulation on the business model
• Adjust the business model or develop a new revenue model as needed
• Reassess the strategy for entering or expanding in the EU market

5.8 Strengthen Stakeholder Communication

• Regularly share the status of EU regulatory response with customers, partners, investors, and other stakeholders
• Emphasize the improvement in product/service safety and reliability achieved through regulatory compliance
• Where necessary, seek understanding regarding increased costs resulting from regulatory compliance

6. Conclusion

The EU’s new digital regulatory environment is both a challenge and an opportunity for Korean companies. The PLD, CRA, and AI Act should not be treated merely as targets of regulatory compliance, but can be used as a framework for developing safer, more reliable digital products and services.

Companies that respond proactively to this regulation can gain the following benefits:

1. Securing a competitive advantage in the EU market
2. Gaining the opportunity to lead global standards
3. Improving the quality and safety of products and services
4. Enhancing customer trust
5. Securing long-term business sustainability

Korean companies can treat these regulatory changes as an opportunity for new innovation and growth, and build stronger competitiveness in the global digital economy. By going beyond mere regulatory compliance to pursue responsible technology development and use, they can increase their social value and achieve sustainable growth.

Disclaimer: I am not a legal expert, and this content should not be relied upon as a legal basis. For specific matters related to licensing or legal issues, please be sure to seek the advice of a legal professional.

To Mine or Not To Mine: A German Court's Ruling on the Copyright Dilemma of the AI Era

This post is based on JBB Rechtsanwält:innen’s blog post “To Mine or Not To Mine” (https://jbb.de/to-mine-or-not-to-mine/) and is published to explain a recent German court ruling on text and data mining (TDM) and to share related knowledge.

Please note that I am not a legal professional, and this content cannot serve as a legal basis. For specific situations related to license and legal issues, please be sure to seek advice from a legal professional.

Background

In 2021, German photographer Robert Kneschke learned that his photos had been included without authorization in an AI training dataset created by the nonprofit organization LAION (Large-scale Artificial Intelligence Open Network).

An AI training dataset refers to a large collection of data used to train artificial intelligence models. The dataset called ‘LAION-5B’ consisted of about 5.8 billion images and their corresponding description text. Such datasets are used to improve an AI’s ability to recognize and understand images.

CommonCrawl

At the heart of this case is the nonprofit organization ‘CommonCrawl’, which plays an important role. CommonCrawl regularly creates a ‘backup’ or ‘snapshot’ of the internet. It replicates, in text form, every webpage accessible through links.

• How CommonCrawl collects data:
  1. It replicates the text content of webpages.
  2. It does not directly store non-text data such as images or videos.
  3. Instead, it stores the source code of webpages, which includes links to such content.

CommonCrawl makes the datasets it collects available on its own website. This dataset includes the ‘source code’ of webpages, which researchers can use to analyze the structure and content of the internet.

LAION’s Data Processing

LAION used this dataset provided by CommonCrawl to create its own image dataset. This process is as follows:

1. Extracting image links from the CommonCrawl dataset: LAION filtered the CommonCrawl data to find only the links to image files.

2. Collecting additional information: LAION sought to collect not only image links but also additional information about each image. This additional information includes:

   • Image description
   • Presence of a watermark
   • Whether the image contains content harmful to minors

3. Downloading and analyzing images: To obtain this additional information, LAION downloaded the actual images through the collected links and analyzed the images using its own AI models.

4. Constructing the dataset: The final dataset LAION created was structured as a table, with each row containing an image link and additional information about the corresponding image.

Through this process, LAION built a large-scale image dataset that could be used for AI training. However, copyright issues were raised during this process, which eventually led to a legal dispute.

Kneschke argued that even though the terms of service of the website containing his photo prohibited automated content downloading, LAION’s unauthorized downloading and analysis of his photo constituted copyright infringement. In response, LAION countered that its activities fell under text and data mining (TDM) for scientific research purposes and were permitted under Section 60d of the Copyright Act.

This case raised important legal and ethical questions about how to strike a balance between data collection and copyright protection in the AI era.

The Start of the Lawsuit

On April 27, 2023, Kneschke filed a copyright infringement lawsuit against LAION in the Hamburg Regional Court. Copyright infringement refers to the use of a copyrighted work without the copyright holder’s permission. Kneschke objected to the unauthorized use of his photo and demanded that his image be removed from the dataset. This raised an important question about how to protect creators’ rights in the AI era.

Legal Issues

The core issues of this lawsuit are as follows:

1. The scope of application of the text and data mining (TDM) exception: The TDM exception refers to a provision in copyright law that allows a copyrighted work to be used without the copyright holder’s permission under certain conditions. This applies when large volumes of data need to be analyzed for research or technological development. In this lawsuit, the issue was whether creating a dataset for AI training falls under this exception. For example, it had to be determined whether automatically collecting and analyzing a website’s text for research purposes constitutes copyright infringement, or whether it falls under this exception and is permitted.
2. The definition of noncommercial scientific research purposes: The issue was exactly what LAION’s claimed ’noncommercial scientific research’ means, and whether its activities fall under this definition.
3. The validity of the copyright holder’s ‘opt-out’ right: ‘Opt-out’ refers to the right of a copyright holder to refuse to have their work used for TDM. The issue was how this right can be exercised and what form of refusal is valid.

The Impact of the EU Copyright Directive

In 2019, the EU adopted the Digital Single Market Copyright Directive (DSM Directive), which came into effect in EU member states starting June 7, 2021. This directive included two exceptions for text and data mining:

1. TDM for scientific research purposes (Article 3)
   • Scope: Applies only to research organizations and cultural heritage institutions.
   • Purpose: Permitted only for the purpose of scientific research.
   • Authorization: No prior permission from the copyright holder is required, and no compensation of any kind is required.
   • Access condition: Applies only to data that can be legally accessed (e.g., subscriptions, licenses, free online content, etc.)
   • Restriction: Excludes institutions under the decisive influence of private companies.
2. TDM for general purposes (Article 4)
   • Scope: Applies to all individuals or organizations.
   • Purpose: Applies to TDM for any purpose (including commercial purposes).
   • Authorization: Applies only if the copyright holder has not explicitly reserved their rights.
   • Access condition: Applies only to data that can be legally accessed.
     • Opt-out mechanism: The copyright holder can reserve their rights in an ‘appropriate manner’ (e.g., in a machine-readable format for online content).
   • Data retention: Copies may be retained for TDM purposes.

Germany incorporated this directive into domestic law and amended its Copyright Act as follows:

• Section 44b: Established a new exception for TDM for general purposes. This provision permits TDM for any purpose, including commercial purposes, but recognizes the copyright holder’s right to explicitly opt out.
• Section 60d: Expanded the existing exception for TDM for scientific research purposes. This provision grants broader freedom for TDM for noncommercial scientific research purposes and does not recognize the copyright holder’s opt-out right.

The Ruling

On September 27, 2024, the Hamburg Regional Court ruled that LAION’s conduct did not constitute copyright infringement. The main points of the ruling are as follows:

1. LAION’s dataset creation activity falls under TDM for noncommercial scientific research purposes under Section 60d of the German Copyright Act.
2. The mere fact that LAION has a cooperative relationship with commercial companies does not negate its noncommercial nature.
3. A TDM prohibition phrase written in natural language in a website’s terms of service can also be regarded as an opt-out in a ‘machine-readable format’.

Significance of the Ruling

1. A broad interpretation of the TDM exception:
   • The court recognized LAION’s image dataset construction activity as TDM for noncommercial scientific research purposes.
   • This means that modern research methods, such as building AI training datasets, can also fall under the TDM exception.
   • This interpretation could provide greater freedom for AI research and development.
2. An expanded definition of noncommercial research:
   • The court determined that the fact that LAION has a cooperative relationship with commercial companies does not negate its noncommercial nature.
   • This could strengthen legal protection for collaborative research between academia and industry.
   • Not only pure academic research but also industry-academia collaboration projects can now benefit from the TDM exception.
3. A new interpretation of the opt-out mechanism: Although the opt-out did not apply in this case because LAION’s activity was recognized as TDM for noncommercial scientific research purposes, this determination carries important meaning in a broader context:
   • Flexibility of legal interpretation: The court flexibly interpreted the requirement of a ‘machine-readable format’ in line with technological developments. This shows that the law can adapt to a rapidly changing technological environment.
   • Impact on future commercial TDM: Although not applied in this case, this interpretation could carry significant meaning for commercial TDM, because a copyright holder’s opt-out is valid for commercial TDM.
   • Guidance for copyright holders: This ruling provides guidance to copyright holders that, if they wish to exclude their content from TDM, they can specify this clearly in their website’s terms of service.
   • Impact on technology companies: AI and data mining companies may now need to review website terms of service more carefully.
4. Balance between copyright law and technological innovation:
   • This ruling can be seen as an attempt to strike a balance between copyright protection and promoting technological innovation.
   • It provided the legal space needed for the advancement of AI and data science, without completely disregarding the copyright holder’s rights.

Future Outlook

Kneschke can appeal this ruling, and given the importance of the matter, it could go to a higher court or even the Court of Justice of the European Union (CJEU). This ruling is also expected to affect similar cases in other EU member states.

This case raises important legal and ethical questions about how to strike a balance between copyright protection and technological innovation in the AI era. Further discussion and legal judgments in this area are expected to follow.

Implications for Domestic AI Companies

Although this ruling is a German case, it also offers important implications for domestic AI companies:

1. Commercial TDM: While this ruling focuses on noncommercial research, it suggests that commercial TDM may also be permitted under certain conditions. However, for commercial TDM, the copyright holder’s opt-out right must be respected.
2. Data collection methods: AI companies must carefully check a website’s terms of service when collecting data. If a provision explicitly prohibits TDM, this may need to be respected.
3. Research collaboration: Companies could consider building datasets through collaboration with nonprofit research institutions. This could be a way to secure the necessary data while reducing legal risk.
4. Transparency and ethics: It is important to maintain transparency about data use in the AI model development process and to establish ethical guidelines. This can help prevent potential legal disputes.
5. Preparing for domestic legal amendments: Laws similar to the EU Copyright Directive may also be discussed domestically. AI companies need to review their data collection and use policies in advance and adjust them as necessary to prepare for such legal changes.

This case raises important legal and ethical questions about how to strike a balance between copyright protection and technological innovation in the AI era. Domestic AI companies should also keep an eye on this global trend and continue their efforts toward responsible AI development.

A Chinese Copyright Infringement Case: "Since GPL-Based Software Products Already Have an Obligation to Disclose Source Anyway, Isn't It Fine to Copy Them?"

As the use of open source software has spread widely, the legal issues surrounding it have grown increasingly complex. In particular, the question of copyright over derivative works based on open source projects that use a copyleft license such as GPL (GNU General Public License) is a thorny subject for many companies. A recent software copyright infringement lawsuit in China offers important implications for this issue.

Parties to the Lawsuit

• Plaintiff: Wangjing Technology (Wangjing)
• Defendants:
  • Yibang Communication Technology (Yibang)
  • Qi’ao Network Technology (Qi’ao)
  • and three individuals (Liu, Wu, Xie)

Overview of the Case

In 2009, Wangjing developed a converged communication smart gateway product called “OfficeTen.”

OfficeTen SDG 1800 by Wangjing - http://www.cncr-it.com/product_detail.php?sid=26&cid=133&id=388

The “OfficeTen1800” software embedded in this product was developed based on the open source framework “OpenWRT,” and obtained a copyright registration certificate from the National Copyright Administration in 2013.

This software consisted of two components: the base system software built on OpenWRT and the upper-layer application software. Wangjing claimed that the latter was an “independent and separate program” from the OpenWRT system.

In 2015, Wangjing began an investigation after suspecting that a competitor, Yibang’s product infringed its copyright. The investigation found that former Wangjing employees had provided the source code of “OfficeTen1800” to Qi’ao, helping it develop very similar software, and that this software was used in Yibang’s product.

According to the appraisal, the proportion of identical non-open-source code between Wangjing’s “OfficeTen1800” and the software used in Yibang’s product reached 90.2%, and Wangjing’s special marks were found in Yibang’s product.

Progress of the Lawsuit

In July 2018, Wangjing filed a software copyright infringement lawsuit against Yibang and Qi’ao. Wangjing demanded that the infringement be stopped and sought damages of 3 million yuan.

The Defendants’ Arguments

Yibang and Qi’ao denied the infringement and argued as follows:

1. “OfficeTen1800” was developed based on the open source framework “OpenWRT.”
2. “OpenWRT” is subject to the constraints of the GPLv2 license.
3. Wangjing’s failure to disclose the source code of “OfficeTen1800” was a violation of GPLv2.
4. Therefore, Wangjing cannot claim copyright over the software.

The Court’s Ruling

First-Instance Judgment

The Suzhou Intermediate People’s Court ruled as follows:

1. Even where a developer modified or made secondary development of an open source product, if it created an original work, it holds copyright in that work.
2. It cannot be concluded that all related software must be disclosed under the GPLv2 agreement.

Accordingly, the court found Yibang and Qi’ao liable for infringement and ordered them to stop the infringement and pay damages of 500,000 yuan (about $70,961, roughly KRW 1 billion).

The Supreme People’s Court’s Ruling

Yibang and Qi’ao appealed, but the Supreme People’s Court upheld the original judgment. The Supreme People’s Court’s main findings were as follows:

1. Since the parties in this case are not the rights holders of the “OpenWRT” system software, whether GPLv2 was complied with cannot be examined in this proceeding.
2. Whether Wangjing violated the GPLv2 agreement and its claim for damages for copyright infringement are separate matters.
3. The copyright arising from a software developer’s original contribution must not be unreasonably deprived or restricted.

Significance of the Ruling

This ruling offers important implications for the copyright protection of derivative works based on open source software.

1. Recognition of Originality: The court held that even a derivative work based on open source software can be subject to copyright protection if the developer made an original contribution.
2. Separation of License Violation from Copyright Protection: The court treated the question of GPLv2 license violation and the claim for damages for copyright infringement as separate matters. This means that even if there is a license violation, the copyright itself can still be valid.
3. Prevention of Rights Abuse: By rejecting the defendants’ argument that “it’s fine to copy it since there’s an obligation to disclose source anyway,” the court prevented reckless copying that abuses the GPL license.
4. Protection of the Open Source Ecosystem: By recognizing copyright in derivative works, the ruling encourages open-source-based innovation and promotes the healthy development of the open source ecosystem.

Similarity to the WordPress Theme Case

In the Karlsruhe Higher Regional Court’s WordPress theme case (ruling of November 13, 2020, reference number 6 U 60/20), GPLv2 was likewise raised as a defense. In that case, the court made the following important findings:

1. A distinction must be made based on whether the copyright holder of the (alleged) derivative work licensed that work under GPLv2.
2. The mere possibility of a copyleft violation is not sufficient to defeat a copyright claim.
3. Enforcement of GPLv2 is the licensor’s responsibility, and it cannot be enforced merely because a user declares the software to be “GPL licensed.”
4. The copyleft effect does not automatically lead to GPL licensing. This is an act that the author of the derivative work must actively carry out.

This finding aligns with the ruling of China’s Supreme People’s Court, and shows a converging trend in the international legal interpretation of GPL licenses and the rights to derivative works.

Implications for Corporate Open Source Management

This ruling offers the following important implications for corporate open source managers:

1. Thorough License Compliance: When using open source software under a copyleft license such as GPL, the requirements of that license must be thoroughly complied with.
2. Importance of Original Contribution: Even when developing based on an open source project, it is important to clearly identify and document original contributions.
3. Source Code Management: Open source code and in-house developed code must be clearly separated and managed.
4. Legal Risk Assessment: Legal risks that may arise from using open source should be assessed and prepared for in advance.
5. Continuous Monitoring: The similarity between a company’s own products and competitors’ products should be continuously monitored to detect potential copyright infringement early.

Conclusion

This ruling from the Chinese court, together with a similar ruling from a German court, clearly resolves the misconception that “GPL-based software products already have an obligation to disclose source anyway, so isn’t it fine to copy them?” Even a derivative work based on open source software under the GPL license can be subject to copyright protection if the developer made an original contribution.

This can be seen as a balanced approach that encourages innovation using open source software while preventing reckless copying and copyright infringement. Companies should refer to this legal interpretation when establishing their open source policies, and strike a balance between license compliance and original development.

As the use of open source software becomes even more common, this kind of legal judgment is expected to be referenced in more countries going forward. Corporate open source managers should therefore continuously monitor these legal trends and reflect them in their own open source policies.

Finally, this ruling delivers an important message to both the open source community and commercial users. It reminds us once again that respecting the spirit of open source while recognizing developers’ effort and creativity, and pursuing innovation while complying with licenses, is the path to a healthy software ecosystem.

References

1. 2024-09-20 OpenWRT, the GPL and the Supreme People’s Court of China: https://www.ifross.org/?q=node/1676
2. 2023-12-29 Copyright dispute cases over derivative works based on open source code: https://www.copyright.or.kr/information-materials/trend/International-copyright-center/download.do?brdctsno=52544&brdctsfileno=22493

Elasticsearch Changes Its License Again: How Should Companies Respond?

Introduction: The Background of the Elasticsearch License

Elasticsearch began as an open source project and has since gone through several changes in licensing policy. Initially it was distributed under the Apache 2.0 license, but in 2021 Elastic changed its license to the Elastic License 2.0 and the Server Side Public License. Then, on August 30, 2024, it drew attention again with an announcement (Elasticsearch is Open Source, Again) adding back the AGPL-3.0.

This change has had a major impact not only on the open source community but also on the companies that use it. In this article, we look at why Elasticsearch changed its licensing policy again, and how companies using it should respond.

1. History of Elasticsearch License Changes

1.1 The Shift from Apache 2.0 to Elastic License 2.0

Elasticsearch initially used the Apache 2.0 license, but in January 2021 Elastic shifted to the Elastic License 2.0 and SSPL. Elastic made this change because of competition with cloud providers, particularly AWS. AWS was profiting from its own service based on Elasticsearch without contributing to it or paying for it, and Elastic changed its license to check this.

Elastic License 2.0 discloses source code but restricts its use in commercial cloud services, and was used as a means of protecting Elastic’s technical assets. In response, AWS started the OpenSearch project and kept the Apache 2.0 license.

This was covered in detail in a previous blog post, “**Elastic License 2.0 and the Evolving Open Source License.”

1.2 Elastic License 2.0 Is Not an Open Source License

However, Elastic License 2.0 was not an open source license recognized by the Open Source Initiative (OSI). This sparked controversy in the open source community. Elastic’s decision created tension between the free use of open source and commercial interests, and became an occasion for companies to raise their awareness of licensing issues when adopting open source.

2. Background to Elasticsearch’s Adoption of AGPL-3.0

2.1 Key Characteristics of AGPL-3.0

In August 2024, Elastic announced that it was adding the GNU Affero General Public License v3 (AGPL-3.0) as a license option for the free portions of Elasticsearch and Kibana. AGPL-3.0 differs from the traditional GPL license in that it requires source code to be disclosed even for software used over a network.

The key characteristics of AGPL-3.0 are as follows:

• Source Code Disclosure Obligation: When software is provided over a network, the source code must be provided if a user requests it.
• Strong Copyleft: AGPL-3.0 requires that modifications to the software also be distributed under the same license.

A detailed guide to AGPL-3.0 can be found here: AGPL-3.0 Guide

2.2 Why Elastic Returned to AGPL-3.0

The reasons Elastic chose AGPL-3.0 are as follows:

• Restoring the Relationship with the Open Source Community: Having lost the community’s trust due to the earlier license change, Elastic turned back to AGPL-3.0, recognized by the OSI, to restore that trust. Shay Banon, Elastic’s founder and CTO, said, “We have always strongly believed in the spirit of open source and the clarity and transparency it enables.”
• Providing Users with More Freedom and Flexibility: AGPL-3.0 is an OSI-approved license that grants users more rights.
• Improving Trust: By using an OSI-approved license, Elastic sought to raise its credibility within the open source community.

Elastic’s decision can be seen as a strategic choice that both attempts to restore its relationship with the community and still seeks to control commercial use.

However, some experts question whether this change can quickly restore the community’s trust. There is also analysis suggesting that the success of OpenSearch may have influenced Elastic’s decision.

3. In an Era of Open Source License Change, What Should Companies Do?

Such license changes carry important implications for companies that use open source. Companies need to always keep in mind the possibility that an open source software’s license may change, and establish a response strategy for it.

3.1 Monitoring License Changes

Frequent changes to open source licenses can expose a company to new legal risk. Preventing this requires continuous monitoring, which makes it important to form a dedicated team and introduce a management system. A systematic process should be built through open source governance to ensure open source license compliance across the company.

• Forming a Dedicated Team: Form a dedicated team where the legal and technical teams work together to track license changes.
• Open Source Governance: Establish clear internal policies and guidelines for open source use.
• Using Automation Tools: Use software composition analysis (SCA) tools to automatically track the open source components in use and their licenses.

3.2 Providing Training and Internal Guidelines

Companies need to provide training and guidelines so that developers who use open source internally can understand and respond to license changes. This can reduce legal disputes arising from license violations.

• Regular Training Programs: Conduct regular training on open source licenses for developers and managers.
• Providing License Guides: Produce and distribute guides summarizing the characteristics and compliance requirements of major open source licenses.
• Developing In-House Experts: Develop open source license experts to serve as internal advisors.

3.3 Responding to AGPL-3.0 in Cloud Environments

Companies operating cloud services need to clearly understand their legal obligations under AGPL-3.0 and put in place a system to prepare for source code disclosure requests. This response strategy can include strengthening internal review processes and considering alternative licenses.

• Strengthening Internal Review: Conduct thorough legal and technical review before introducing AGPL-3.0 software into a cloud service.
• Reviewing Alternative Solutions: If the constraints of the AGPL-3.0 license are burdensome, consider alternative open source or commercial solutions.
• Automating License Compliance: Build a system that automatically checks license compliance for software used in cloud environments.

For reference, AGPL-3.0 does not impose requirements such as source disclosure when open source is used only internally, without redistribution or being offered as an external service. Therefore, for purely in-house use, it can be freely used without complying with obligations such as source code disclosure. However, please discuss with your in-house legal team for a clear determination of the scope of AGPL-3.0 open source use within your company and the obligations that apply to it.

Conclusion: Open Source License Change, a Company’s Strategic Response

Elasticsearch’s decision to return to AGPL-3.0 carries significant meaning within the open source ecosystem. It is not only an effort by Elastic to find a balance between commercial interest and the spirit of open source, but also carries important implications for every company that uses open source.

Companies must respond proactively to changes in open source licenses, and through this establish a strategy that reduces legal risk and maximizes technical opportunity. A strong copyleft license such as AGPL-3.0 will draw even more attention in the cloud era, and companies should strengthen their internal systems and advance their open source management framework accordingly.

Changes in open source licenses are an unavoidable reality, but a company that responds to this appropriately, treating it as an opportunity, can secure a competitive edge. Through a systematic open source management strategy, companies can minimize legal risk and maximize technical advantage, achieving sustainable growth within the open source ecosystem.

Introduction to SPDX 3.0 and Enterprise Adoption Strategy

1. Introduction to SPDX 3.0

SPDX (Software Package Data Exchange) is an open standard for communicating software component, license, copyright, and security information in a standardized way. SPDX 3.0 is the latest version of this standard, released in April 2024, and is a major update that significantly improves the transparency and security of the software supply chain[2].

Definition and Purpose of SPDX

SPDX is a Linux Foundation project that provides a standard format for sharing important information related to software packages. Its main purposes are as follows:

• Providing transparency of software components
• Improving license compliance
• Supporting security vulnerability management
• Enhancing the reliability of the software supply chain

Key Changes in SPDX 3.0

SPDX 3.0 brings significant changes compared to previous versions:

1. Modular structure: SPDX 3.0 consists of a core model and multiple profiles, allowing it to flexibly address a variety of use cases.
2. Improved extensibility: The new version makes it easy to add custom fields and relationships, enabling it to accommodate future requirements.
3. Support for various profiles: It provides various profiles such as Software, Security, License, Build, and AI/ML to meet the requirements of specific domains.
4. Enhanced data model: It can express relationships between entities more clearly, allowing complex software structures to be described more accurately.

Significance of SPDX 3.0

SPDX 3.0 is important for enterprise open source management for the following reasons:

1. Standardization of SBOM generation: It provides a standard format for generating a Software Bill of Materials (SBOM), facilitating information exchange between organizations.
2. Support for regulatory compliance: It meets the SBOM minimum requirements of the US NTIA and complies with various international standards and regulations.
3. Enhanced security: It improves vulnerability management through integration with CVE information and strengthens software supply chain security.
4. Global standardization: It has been adopted as ISO/IEC 5962:2021, becoming an internationally recognized standard[2].

SPDX 3.0 is a powerful tool that greatly improves transparency, security, and compliance throughout the software development and distribution process. By understanding and applying this standard, enterprise open source managers can modernize their organization’s software management processes and reduce risk.

Citations:
[1] https://fossa.com/blog/understanding-using-spdx-license-identifiers-license-expressions/
[2] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[3] https://fossa.com/learn/spdx
[4] https://fossa.com/blog/sbom-examples-explained/
[5] https://ossna2023.sched.com
[6] https://ossna2023.sched.com/list/descriptions/
[7] https://fossa.com/blog/spdx-3-0/

2. Key Features of SPDX 3.0

SPDX 3.0 is the latest version of software package data exchange, offering significantly improved features compared to previous versions. The key features are as follows:

Modular Structure

SPDX 3.0 introduces a modular structure that greatly improves flexibility and extensibility[1][5]. This structure consists of the following elements:

• Core Model: Defines the core elements that form the basis of every SPDX document.
• Profiles: Provide additional information and functionality tailored to specific use cases.

This modular approach allows users to selectively use only the information they need, reducing complexity and increasing efficiency.

Improved Extensibility

SPDX 3.0 is designed to make it easy to add custom fields and relationships[5]. This provides the following benefits:

• Ability to respond quickly to new technologies and requirements
• Ability to easily incorporate industry-specific requirements
• Ability to flexibly adapt to future changes in the software ecosystem

Support for Various Use Cases

SPDX 3.0 supports various use cases through six main profiles[7]:

1. Security Profile: Includes vulnerability information and security-related metadata
2. License Profile: Provides detailed license information and compliance data
3. AI Profile: Includes information related to AI model training and characterization
4. Dataset Profile: Provides information on dataset provenance and characteristics
5. Software Packaging Profile: Includes package structure and dependency information
6. Build Process Profile: Provides detailed information about the software build process

These profiles help software engineers, security experts, and legal and compliance professionals use SPDX more easily[7].

Enhanced Data Model

SPDX 3.0 provides an enhanced data model that can express relationships between entities more clearly[1]. This enables:

• More accurate description of complex software structures
• Clearer expression of dependencies between software components
• More granular linking of security and license information

Compliance with International Standards

SPDX 3.0 complies with the ISO/IEC 5962:2021 standard, which has significant implications for global software supply chain management[5][6]. This enables:

• Generation of SBOMs in an internationally recognized format
• Compliance with various regulatory requirements (e.g., US government EO 14028, EU Cyber Resilience Act)
• Improved consistency and reliability of software information exchange between organizations

These key features of SPDX 3.0 greatly improve the transparency, security, and compliance of the software supply chain, and play an important role in meeting modern software development and management requirements.

Citations:
[1] https://scribesecurity.com/ko/blog/spdx-vs-cyclonedx-sbom-formats-compared/
[2] https://github.com/spdx/spdx-3-model/releases
[3] https://olis.or.kr/license/licenseSPDX.do?mapcode=010107
[4] https://ettrends.etri.re.kr/ettrends/203/0905203008/0905203008.html
[5] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[6] https://www.prnewswire.com/news-releases/spdx-3-0-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases-302118321.html
[7] https://www.gttkorea.com/news/articleView.html?idxno=5131

3. SPDX 3.0 Profiles

The concept of profiles introduced in SPDX 3.0 is a key feature that enables SPDX data to be organized and managed according to various use cases. Each profile defines the information and structure required for a specific domain or use case.

Core Profile

The Core Profile defines the core elements that form the basis of every SPDX document.

• Key components:
  • Element: The base class for all SPDX objects
  • Artifact: A class representing a software component
  • Agent: A class representing a person, organization, tool, etc.
  • Relationship: A class defining relationships between entities
• Purpose: Provides the basic structure and information commonly used by all other profiles.
• Example use: Every SPDX document is built on the Core Profile, with information from other profiles added on top of it.

Software Profile

The Software Profile provides detailed information related to software packages.

• Key components:
  • Package: Information about a software package
  • File: Information about an individual file
  • Snippet: Information about a portion of a file
• Purpose: Describes the structure, components, and metadata of software in detail.
• Example use: Used when documenting the structure and components of an open source library.

Security Profile

The Security Profile covers security-related information about software.

• Key components:
  • Vulnerability: Vulnerability information
  • Assessment: Vulnerability assessment information
• Purpose: Provides information on software security vulnerabilities and related assessments.
• Example use: Used when including Common Vulnerabilities and Exposures (CVE) information in an SPDX document.

License Profile

The License Profile covers software license-related information in detail.

• Key components:
  • License: License information
  • LicenseExpression: Complex license expressions
• Purpose: Describes software license information accurately and in detail.
• Example use: Used when documenting the license information of open source software.

Build Profile

The Build Profile provides information about the software build process.

• Key components:
  • BuildStep: Build step information
  • BuildTool: Build tool information
• Purpose: Provides detailed information about how software is compiled and packaged.
• Example use: Used when documenting the build process of a CI/CD pipeline.

AI/ML Profile

The AI/ML Profile covers information specific to artificial intelligence and machine learning models.

• Key components:
  • AIModel: AI model information
  • Dataset: Training dataset information
• Purpose: Describes the characteristics, training data, performance metrics, and other aspects of AI/ML models.
• Example use: Used when documenting the structure and training dataset of a deep learning model.

Each profile reflects the modular structure of SPDX 3.0, and users can select the appropriate profile as needed to generate SPDX documents. This allows various aspects of the software supply chain to be documented and managed effectively.

Citations:
[1] https://spdx.dev/leveraging-profiles-for-license-compliance-insights-from-spdx-mini-summit/
[2] https://spdx.dev/providing-transparency-at-software-developments-core-process-build-time/
[3] https://spdx.github.io/spdx-spec/v2.3/SPDX-license-list/
[4] https://spdx.dev/capturing-software-vulnerability-data-in-spdx-3-0/
[5] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[6] https://spdx.dev/understanding-spdx-profiles/
[7] https://github.com/spdx/spdx-3-model/actions
[8] https://spdx.github.io/spdx-spec/v3.0/model/AI/AI/

4. SPDX 3.0 Data Model

The data model of SPDX 3.0 is designed to be more flexible and extensible than previous versions. This model better reflects the complexity of the software supply chain and supports a variety of use cases.

Key Entities and Relationships

1. Element
   • The base class for all major objects in SPDX 3.0.
   • Every Element has a unique SPDX ID.
2. Artifact
   • Represents a software component (e.g., package, file, snippet).
   • Includes attributes such as name, version, and supplier.
3. Agent
   • Represents an entity involved in creating the SPDX document, such as a person, organization, or tool.
4. Relationship
   • Defines relationships between entities (e.g., dependency, containment).
   • Specifies the source, target, and relationship type.
5. LifecycleScopedRelationship
   • Represents a relationship specific to a particular software lifecycle stage.
6. Annotation
   • Provides additional information or comments about an entity.

Identifier Scheme

SPDX 3.0 introduces a more robust and flexible identifier scheme:

• SPDX ID: Provides a unique identifier for every Element.
• External identifiers: Can reference identifiers from other systems (e.g., CVE, PURL).
• Namespaces: Clarify the scope of identifiers and prevent collisions.

Metadata Management

1. CreationInfo
   • Includes metadata about the SPDX document itself.
   • Provides information such as creation date, author, and tool version.
2. Profile-specific metadata
   • Defines metadata fields specific to each profile (Software, Security, License, etc.).

Extensibility Mechanisms

1. Custom attributes
   • Can include additional user-defined attributes beyond the standard fields.
2. External references
   • Provides links to external systems or documents.

Data Types

SPDX 3.0 supports various data types:

• Strings, integers, booleans, date/time
• Enumerations (e.g., license type, relationship type)
• Composite types (e.g., version range, checksum)

Serialization Formats

The SPDX 3.0 data model can be serialized into various formats:

• JSON-LD
• YAML
• RDF
• XML

This support for multiple formats facilitates integration with other systems.

Profile Support

The data model is designed to support various profiles:

• Core Profile: Basic elements common to every SPDX document
• Software Profile: Information related to software packages
• Security Profile: Vulnerability and security-related data
• License Profile: Detailed license information
• AI/ML Profile: Metadata related to AI models
• Dataset Profile: Information related to datasets

Each profile defines the additional fields and relationships required for a specific use case. The data model of SPDX 3.0 can comprehensively express the complexity of the software supply chain while providing the flexibility to meet the requirements of specific domains. This enables organizations to manage and share more accurate and detailed information about their software components.

5. SPDX 3.0 Implementation Guide

This section provides a detailed guide for effectively implementing SPDX 3.0.

Tools and Libraries

The main tools and libraries that support SPDX 3.0 are as follows:

1. SPDX Java Library
   • GitHub: https://github.com/spdx/tools-java
   • Features: Parsing, generating, converting, and validating SPDX documents
   • Usage: Add as a Maven dependency for use in Java projects
2. SPDX Python Library
   • GitHub: https://github.com/spdx/tools-python
   • Features: Parsing, generating, and validating SPDX documents
   • Characteristics: Provides experimental support for SPDX 3.0
3. SPDX Online Tools
   • Website: https://tools.spdx.org
   • Features: Web-based SPDX document generation and validation
4. FOSSology
   • GitHub: https://github.com/fossology/fossology
   • Features: An open source compliance tool that supports SPDX document generation
5. SPDX SBOM Generator
   • GitHub: https://github.com/opensbom-generator/spdx-sbom-generator
   • Features: Generates SPDX SBOMs for projects in various programming languages

These tools can be used to generate, parse, and validate SPDX 3.0 documents.

File Formats (JSON, YAML, RDF)

SPDX 3.0 supports various file formats:

1. JSON-LD

   • The most recommended format

   • Example:

     {
       "@context": "<https://spdx.org/spdx-3.0-context.jsonld>",
       "@type": "SpdxDocument",
       "name": "Example SPDX 3.0 Document",
       "elements": [
         {
           "@type": "Package",
           "name": "ExamplePackage",
           "version": "1.0.0"
         }
       ]
     }
     

2. YAML

   • A human-readable format

   • Example:

     ---
     $schema: <https://spdx.org/spdx-3.0-schema.json>
     spdxVersion: SPDX-3.0
     name: Example SPDX 3.0 Document
     elements:
       - type: Package
         name: ExamplePackage
         version: 1.0.0
     

3. RDF

   • Suitable for semantic web applications

   • Example:

     <rdf:RDF xmlns:rdf="<http://www.w3.org/1999/02/22-rdf-syntax-ns#>"
              xmlns:spdx="<http://spdx.org/rdf/terms#>">
       <spdx:SpdxDocument>
         <spdx:name>Example SPDX 3.0 Document</spdx:name>
         <spdx:element>
           <spdx:Package>
             <spdx:name>ExamplePackage</spdx:name>
             <spdx:versionInfo>1.0.0</spdx:versionInfo>
           </spdx:Package>
         </spdx:element>
       </spdx:SpdxDocument>
     </rdf:RDF>
     

Each format is suited to specific use cases, and developers can choose the appropriate format based on their project requirements.

Migrating from Existing SPDX 2.x

The process of migrating from SPDX 2.x to 3.0 is as follows:

1. Understand the structural changes
   • Familiarize yourself with the modular structure and profile concept of SPDX 3.0
   • Identify new fields and relationship types
2. Update tools
   • Upgrade to the latest versions of tools and libraries that support SPDX 3.0
3. Convert documents
   • Use the spdx_tools.spdx3.bump_from_spdx2.spdx_document module of the SPDX Python Library
   • Convert SPDX 2.x documents to 3.0 using the bump_spdx_document() function
4. Add new fields
   • Add fields newly introduced in SPDX 3.0 (e.g., AI/ML-related information)
5. Redefine relationships
   • Redefine existing relationships using the new relationship types in SPDX 3.0
6. Apply profiles
   • Select and apply the appropriate SPDX 3.0 profiles
7. Validate
   • Use SPDX 3.0 validation tools to verify the validity of the converted document
8. Test and integrate
   • Integrate and test the converted SPDX 3.0 document within the existing workflow

During the migration process, it is advisable to actively make use of SPDX community resources and documentation, and to seek expert help if needed.

By following this implementation guide, organizations can effectively adopt and utilize SPDX 3.0.

Citations:
[1] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[2] https://www.youtube.com/watch?v=iqVk-Sek8Pc
[3] https://github.com/spdx/Spdx-Java-Library
[4] https://spdx.github.io/spdx-spec/v3.0/annexes/diffs-from-previous-editions/
[5] https://github.com/spdx/spdx-3-model/releases
[6] https://spdx.dev/use/spdx-tools/
[7] https://github.com/spdx/tools-python/blob/main/README.md
[8] https://fossa.com/learn/spdx

6. SBOM and SPDX 3.0

The Software Bill of Materials (SBOM) has become a core element of software supply chain security. SPDX 3.0 provides a powerful framework for generating and managing SBOMs, enabling organizations to track and manage software components more effectively.

SBOM Generation and Management

1. Automated SBOM generation
   • SPDX 3.0 can be integrated into CI/CD pipelines to automatically generate SBOMs[6].
   • This enables “machine-speed” SBOM generation, allowing SBOMs to be updated instantly in step with the software release cycle.
2. Use of a consistent format
   • SPDX 3.0 provides a standardized SBOM format to ensure consistency[6].
   • This facilitates SBOM data exchange between organizations and enables automated analysis.
3. Regular updates
   • The SBOM must be updated with every software release[6].
   • Leveraging the automation features of SPDX 3.0 makes it possible to manage this process efficiently.
4. Inclusion of metadata
   • SPDX 3.0 allows rich metadata, such as license information and patch status, to be included in the SBOM[6].
   • This greatly improves security and compliance management.

Improving SBOMs with SPDX 3.0

1. Modular structure
   • The profile-based structure of SPDX 3.0 can be used to generate SBOMs tailored to various use cases[1].
   • Information specific to each profile, such as Software, Security, and License, can be included in the SBOM.
2. Integration of security vulnerability information
   • The Security Profile of SPDX 3.0 can be used to include vulnerability information directly in the SBOM[1].
   • This allows security teams to identify and respond to vulnerabilities more quickly and effectively.
3. Strengthened license compliance
   • The License Profile of SPDX 3.0 can be used to include detailed license information in the SBOM[2].
   • This makes it easier for legal and compliance teams to identify and manage license obligations.
4. Inclusion of AI/ML model information
   • The AI/ML Profile of SPDX 3.0 can be used to include AI model and dataset information in the SBOM[2].
   • This contributes to increasing the transparency and accountability of AI systems.

Meeting NTIA Minimum Requirements

SPDX 3.0 meets the SBOM minimum requirements defined by the National Telecommunications and Information Administration (NTIA)[4][5].

1. Basic data fields
   • SPDX 3.0 includes all seven basic data fields required by the NTIA:
     • Supplier Name
     • Component Name
     • Component Version
     • Other Unique Identifiers
     • Dependency Relationship
     • SBOM Author
     • Timestamp
2. Automation and interoperability
   • SPDX 3.0 supports machine-readable formats (JSON-LD, YAML, RDF), meeting the NTIA’s automation requirements[5].
3. Practicability
   • SPDX 3.0 ensures practicability by supporting SBOM generation and management through a variety of tools and libraries.
4. Extensibility
   • The modular structure of SPDX 3.0 provides the extensibility to accommodate future requirements.

SBOM management using SPDX 3.0 goes beyond simply meeting regulatory requirements — it significantly strengthens an organization’s software supply chain security and contributes to greater transparency. This ultimately leads to the construction of a safer and more trustworthy software ecosystem.

Citations:
[1] https://spdx.dev/capturing-software-vulnerability-data-in-spdx-3-0/
[2] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[3] https://www.legitsecurity.com/blog/best-practices-for-managing-maintaining-sboms
[4] https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
[5] https://cybellum.com/blog/ntia-minimum-elements-for-a-software-bill-of-materials-sbom-a-guide/
[6] https://jfrog.com/devops-tools/article/best-practices-for-software-bill-of-materials-management/
[7] https://about.gitlab.com/blog/2022/10/25/the-ultimate-guide-to-sboms/
[8] https://scribesecurity.com/sbom/how-to-generate-an-sbom/

7. Security and Vulnerability Management

SPDX 3.0 provides powerful features for software security and vulnerability management. This enables organizations to manage the security of their software supply chain more effectively.

CVE Information Integration

Integrating Common Vulnerabilities and Exposures (CVE) information into SPDX 3.0 documents is a core element of security management.

1. How to reference CVEs

   • SPDX 3.0 uses the ExternalReference class to reference CVE information.

   • Example:

     {
       "@type": "ExternalReference",
       "referenceType": "SecurityAdvisory",
       "referenceLocator": "CVE-2021-44228",
       "referenceCategory": "CVE"
     }
     

2. Inclusion of detailed CVE information

   • Common Vulnerability Scoring System (CVSS) score
   • Affected version range
   • Patch availability and patch information

3. Automatic CVE updates

   • SPDX 3.0 tools can automatically pull CVE information from external sources such as the National Vulnerability Database (NVD) to update SPDX documents.

4. Linking CVE information to components

   • SPDX 3.0 can clearly link specific software components with related CVE information.
   • This makes it easy to identify and track vulnerable components.

Vulnerability Tracking and Reporting

SPDX 3.0 provides features for effectively tracking and reporting vulnerabilities.

1. Vulnerability lifecycle management

   • The entire lifecycle of a vulnerability, including discovery date, report date, and patch date, can be tracked.

   • Example:

     {
       "@type": "Vulnerability",
       "name": "CVE-2021-44228",
       "description": "Log4j RCE vulnerability",
       "discoveredDate": "2021-12-09",
       "publishedDate": "2021-12-10",
       "patchedDate": "2021-12-14"
     }
     

2. Vulnerability severity assessment

   • The severity of a vulnerability can be assessed and recorded using the CVSS score.

   • Example:

     {
       "@type": "VulnerabilityAssessment",
       "vulnerability": "CVE-2021-44228",
       "cvssV3": {
         "baseScore": 10.0,
         "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
       }
     }
     

3. Vulnerability report generation

   • Automated vulnerability reports can be generated based on SPDX 3.0 data.
   • The report includes the affected components, severity, patch status, and more.

4. Vulnerability trend analysis

   • Patterns in vulnerability occurrence over time can be analyzed.
   • This allows security teams to establish long-term security strategies.

Utilizing the Security Profile

The Security Profile of SPDX 3.0 enables systematic management of security-related information.

1. Security Profile structure

   • Vulnerability: A class representing vulnerability information
   • VulnerabilityAssessment: A class representing vulnerability assessment information
   • SecurityAdvisory: A class representing security advisories

2. Example use of the Security Profile

   {
     "@type": "SecurityProfile",
     "vulnerabilities": [
       {
         "@type": "Vulnerability",
         "name": "CVE-2021-44228",
         "description": "Log4j RCE vulnerability"
       }
     ],
     "assessments": [
       {
         "@type": "VulnerabilityAssessment",
         "vulnerability": "CVE-2021-44228",
         "cvssV3": {
           "baseScore": 10.0,
           "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
         }
       }
     ],
     "advisories": [
       {
         "@type": "SecurityAdvisory",
         "title": "Update Log4j to version 2.15.0 or later",
         "description": "Upgrade Log4j to mitigate CVE-2021-44228"
       }
     ]
   }
   

3. Ways to utilize the Security Profile

   • Automatically update the Security Profile by integrating with vulnerability scanning tools
   • Use as a data source for building security dashboards
   • Use as evidence of security posture during compliance audits

4. Security metric tracking

   • Security metrics such as the number of open vulnerabilities, average patch time, and the ratio of high-risk vulnerabilities can be tracked based on SPDX 3.0 data.

By leveraging the security and vulnerability management features of SPDX 3.0, organizations can greatly strengthen the security of their software supply chain. Integrating CVE information, systematically tracking and reporting vulnerabilities, and utilizing the Security Profile help security teams respond to threats more effectively and improve the organization’s overall security posture.

8. License Compliance

SPDX 3.0 provides powerful features for effectively managing software license compliance. This allows organizations to more easily identify and comply with the license obligations of open source and commercial software.

License Information Management

1. License identifiers

   • SPDX 3.0 uses standardized license identifiers.
   • Example: “MIT”, “Apache-2.0”, “GPL-3.0-only”
   • This ensures the consistency and accuracy of license information.

2. Inclusion of license text

   • The full license text can be included in the SPDX document.

   • Example:

     {
       "@type": "License",
       "licenseId": "MIT",
       "name": "MIT License",
       "text": "MIT License\\n\\nCopyright (c) [year] [fullname]\\n\\nPermission is hereby granted, ..."
     }
     

3. Custom licenses

   • For licenses not on the standard SPDX license list, a custom license can be defined.
   • In this case, the “LicenseRef-” prefix is used.
   • Example: “LicenseRef-CompanyA-Proprietary”

4. License expressions

   • Complex license combinations can be expressed.
   • Example: “(MIT OR Apache-2.0) AND CC-BY-4.0”

5. File- and package-level licenses

   • License information can be specified at the level of individual files, snippets, or packages.
   • This allows for fine-grained license management.

License Compatibility Checking

SPDX 3.0 data can be used to automatically check license compatibility.

1. License graph generation
   • A license graph is generated based on the dependencies between software components and the license information of each component.
2. Compatibility rule definition
   • Compatibility rules between licenses are defined.
   • Example: GPL-3.0 is compatible with Apache-2.0, but GPL-2.0 is not compatible with Apache-2.0.
3. Automatic compatibility checking
   • The license graph is analyzed based on the defined rules to automatically identify compatibility issues.
4. Conflict resolution suggestions
   • When a license conflict is found, possible resolutions are suggested.
   • Example: Using an alternative version of a specific component, requesting a license exception, etc.
5. Dynamic analysis
   • License compatibility can be checked in real time during the software build process.
   • This allows license issues to be identified and resolved early in development.

Compliance Report Generation

Detailed license compliance reports can be generated based on SPDX 3.0 data.

1. Report components
   • A list of all software components used
   • License information for each component
   • A summary of license obligations
   • Potential license conflicts and resolutions
   • Copyright notice text
2. Obligation tracking
   • Tracks the key obligations of each license and reports on compliance status.
   • Example: the obligation to disclose source code, the obligation to provide copyright notice, the obligation to include license text, etc.
3. Risk assessment
   • Assesses and reports the legal risk of each license and license combination.
   • Provides warnings about the use of high-risk licenses.
4. Compliance workflow integration
   • Report generation can be automated and integrated into regular compliance review processes.
   • It can be integrated into a CI/CD pipeline to generate a compliance report with every build or release.
5. Customized reports
   • Customized reports can be generated to meet the needs of various stakeholders (legal team, development team, management, etc.).
   • Example: detailed reports for the legal team, summary reports for management, etc.
6. History management
   • Changes in compliance status over time can be tracked.
   • This makes it possible to measure the effectiveness of license compliance improvement efforts.

By leveraging the license compliance features of SPDX 3.0, organizations can effectively manage and comply with license obligations within a complex software ecosystem. This helps reduce legal risk, improve relationships with the open source community, and increase the transparency and reliability of the overall software development process.

9. SPDX 3.0 Use Cases

SPDX 3.0 can be used to improve software management and security across a variety of industries. The main use cases are as follows:

Software Supply Chain Security

1. Vulnerability identification and management
   • The Security Profile of SPDX 3.0 is used to systematically track vulnerabilities in software components.
   • CVE information can be integrated into the SPDX document to assess security risk in real time.
2. Ensuring supply chain transparency
   • SPDX 3.0 makes it possible to clearly document all components of software and their provenance.
   • This helps reduce the risk of malicious code injection or supply chain attacks.
3. Build process security
   • The Build Profile of SPDX 3.0 can be used to ensure the integrity of the software build process.
   • Documenting information such as build tools, environment, and scripts supports reproducible builds.
4. Rapid application of security patches
   • SPDX 3.0 documents make it possible to quickly identify and patch vulnerable components.
   • The security update process can be optimized by integrating with automated tools.

Open Source Management

1. License compliance
   • The License Profile of SPDX 3.0 is used to systematically manage open source license obligations.
   • Complex license combinations can be accurately expressed and analyzed.
2. Open source contribution tracking
   • SPDX 3.0 makes it possible to clearly record the provenance and contributor information of open source components within a project.
   • This helps strengthen collaboration with the open source community and recognize contributions.
3. Open source policy enforcement
   • SPDX 3.0 documents can be linked to an organization’s open source policy to ensure that only approved licenses and components are used.
4. Streamlining open source audits
   • The standardized format of SPDX 3.0 makes it possible to automate and streamline the open source audit process.

Regulatory Compliance

1. Meeting SBOM requirements
   • SPDX 3.0 meets the SBOM generation requirements set out in US government Executive Order 14028 and the EU Cyber Resilience Act, among others.
2. Responding to industry-specific regulations
   • SPDX 3.0 makes it possible to effectively respond to software-related regulatory requirements across various industries, including medical devices, automotive, and aerospace.
3. Data privacy regulatory compliance
   • The Dataset Profile of SPDX 3.0 can be used to support compliance with data privacy regulations such as GDPR and CCPA.
4. Support for audits and reporting
   • SPDX 3.0 documents make it easy to provide regulators or auditors with the necessary software composition and security information.
5. Responding to AI regulation
   • By using the AI/ML Profile of SPDX 3.0 to document an AI model’s training data, algorithms, and performance metrics, organizations can proactively prepare for future AI regulation.

These use cases of SPDX 3.0 enable organizations to improve software management, security, and compliance in an integrated way. Its standardized approach promotes collaboration between organizations and contributes to increasing transparency and reliability across the software ecosystem.

Citations:
[1] https://linuxsecurity.com/news/organizations-events/spdx-3-0
[2] https://spdx.dev/spdx-announces-3-0-release-candidate-with-new-use-cases/
[3] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[4] https://www.prnewswire.com/news-releases/spdx-3-0-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases-302118321.html
[5] https://spdx.dev/leveraging-profiles-for-license-compliance-insights-from-spdx-mini-summit/
[6] https://www.synopsys.com/blogs/software-security/sboms-and-spdx.html
[7] https://spdx.dev/understanding-spdx-profiles/

10. SPDX 3.0 Adoption Strategy

A systematic approach is needed to successfully adopt SPDX 3.0 within an organization. The following is a detailed strategy for adopting SPDX 3.0.

Phased Implementation Plan

1. Current state analysis
   • Assess the current SBOM generation and management process
   • Analyze existing tools and workflows
   • Identify the benefits that adopting SPDX 3.0 can bring
2. Pilot project selection
   • Select a small, low-criticality project
   • Select and apply a specific SPDX 3.0 profile (e.g., Security or License)
3. Tool selection and configuration
   • Evaluate tools that support SPDX 3.0 (e.g., SPDX tools, FOSSology)
   • Integrate the selected tools into the existing CI/CD pipeline
4. Process definition
   • Design workflows for generating, validating, and managing SPDX 3.0 documents
   • Define owners and roles
5. Expansion plan
   • Identify improvements based on the pilot project’s results
   • Gradually expand adoption to other projects and departments
6. Monitoring and optimization
   • Set KPIs to measure the impact of SPDX 3.0 adoption
   • Conduct regular reviews and process improvements

Training and Awareness Within the Organization

1. Securing executive support
   • Present the business value of adopting SPDX 3.0
   • Emphasize regulatory compliance and risk management aspects
2. Department-specific training
   • Development team: How to generate and manage SPDX 3.0 documents
   • Legal team: Ways to improve license compliance
   • Security team: Vulnerability management and how to use the Security Profile
3. Workshops and hands-on sessions
   • Hands-on practice using SPDX 3.0 tools
   • Practice applying SPDX 3.0 to real projects
4. Internal communication
   • Publish newsletters related to SPDX 3.0
   • Build an SPDX 3.0 resource center on the intranet
5. Sharing success stories
   • Share the outcomes and lessons learned from the pilot project
   • Highlight the improvements achieved through SPDX 3.0 adoption

Tips for Successful Adoption

1. Gradual approach
   • Do not try to change everything at once; adopt it in stages
   • Collect feedback and identify improvements at each stage
2. Forming a cross-functional team
   • Form a team of experts from various departments, including development, legal, security, and operations
   • Discuss progress and issues through regular meetings
3. Emphasizing automation
   • Automate the process of generating and managing SPDX 3.0 documents
   • Integrate SPDX 3.0-related steps into the CI/CD pipeline
4. Leveraging external experts
   • Seek help from the SPDX community or consulting firms as needed
   • Benchmark the success stories of other organizations
5. Maintaining flexibility
   • Do not try to adopt all features of SPDX 3.0 at once
   • Start with the profiles and features that fit the organization’s needs
6. Emphasizing continuous learning
   • Encourage participation in SPDX community activities
   • Support attendance at related conferences and webinars
7. Measuring and reporting outcomes
   • Compare metrics before and after SPDX 3.0 adoption (e.g., vulnerability response time, improvement in license compliance)
   • Regularly report progress and ROI to management
8. Managing cultural change
   • Encourage the organization to see SPDX 3.0 not merely as a tool but as a new way of working
   • Develop strategies to overcome resistance to change

Successful adoption of SPDX 3.0 involves not only technical implementation but also changes in organizational culture and processes. Through systematic planning, continuous education, and a flexible approach, organizations can make the most of the benefits of SPDX 3.0[1][2].

Citations:
[1] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[2] https://spdx.dev/unpacking-the-spdx-3-0-tooling-mini-summit-a-new-era-of-compliance-and-security/
[3] https://spdx.dev/spdx-announces-3-0-release-candidate-with-new-use-cases/
[4] https://openchainproject.org/news/2023/03/31/webinar-50
[5] https://nand-research.com/quick-take-spdx-3-0-release/
[6] https://linuxsecurity.com/news/organizations-events/spdx-3-0
[7] https://spdx.dev/leveraging-profiles-for-license-compliance-insights-from-spdx-mini-summit/

11. Future Outlook and Direction

The release of SPDX 3.0 has opened a new chapter in software supply chain management. This section takes a closer look at the future and direction of SPDX.

SPDX Community Participation

1. Open participation model
   • SPDX has adopted an open community model, so anyone can participate[1].
   • A variety of stakeholders — individuals, companies, and organizations — can contribute to the development of SPDX.
2. How to participate
   • Subscribe to the mailing list: You can join the general SPDX mailing list to receive the latest news[1].
   • Attend regular meetings: You can join the monthly general meeting to follow project progress and share your input[1].
   • Work group activities: You can participate in various working groups such as technical, legal, and outreach.
3. Participation in tool development
   • You can participate directly in SPDX tool development. For example, students can contribute to SPDX-related projects through the Google Summer of Code program[7].

Future Updates and Improvements

1. Enhancement of AI/ML-related features
   • Profiles covering AI model training and characterization, dataset provenance, and similar topics are expected to be further developed[4].
   • Adding metadata related to AI ethics and accountability may be considered.
2. Expansion of security features
   • The linkage between vulnerability information and SBOMs is expected to be further strengthened.
   • Integration with real-time threat intelligence is a possibility.
3. Improved automation and integration
   • Deeper integration with CI/CD pipelines is expected.
   • Automated SBOM generation and update features will become more sophisticated.
4. Improved user experience
   • More intuitive user interfaces and visualization tools may be developed.
   • Simplified versions of SPDX tools for non-technical users may emerge.

Global Standardization Trends

1. Strengthening its position as an ISO standard
   • SPDX has already been adopted as the ISO/IEC 5962:2021 standard, and version 3.0 is also planned to be submitted to ISO[5].
   • This is expected to further accelerate the global adoption of SPDX.
2. Responding to international regulations
   • It is expected to become a core tool for addressing international software supply chain security regulations, such as US Executive Order 14028 and the EU Cyber Resilience Act[6].
3. Industry-specific standardization
   • Industry-specific standards based on SPDX may be developed across various sectors, including automotive, medical devices, and aerospace.
4. Strengthening international cooperation
   • The SPDX community is expected to strengthen cooperation with other international standards bodies and open source foundations.
   • This could lead to a more unified global approach to software supply chain security.

SPDX 3.0 is an important milestone shaping the future of software management. Through continued community participation, technological advancement, and international standardization efforts, SPDX is expected to continue making a significant contribution to improving software supply chain security and transparency.

Citations: [1] https://spdx.dev/engage/participate/
[2] https://www.linuxinsider.com/story/spdx-becomes-new-standard-for-open-source-software-security-87265.html
[3] https://spdx.dev/engage/join/
[4] https://sbomify.com/2024/04/28/exploring-the-new-spdx-3-0-a-game-changer-for-sboms/
[5] https://www.prnewswire.com/news-releases/spdx-3-0-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases-302118321.html
[6] https://spdx.dev/spdx-announces-3-0-release-candidate-with-new-use-cases/
[7] https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeas
[8] https://linuxsecurity.com/news/organizations-events/spdx-3-0

12. Conclusion: SPDX 3.0 Utilization Strategy for Enterprise Open Source Managers

SPDX 3.0 provides enterprise open source managers with a powerful and flexible tool. The following are strategic approaches for making effective use of SPDX 3.0:

1. Strategic adoption
   • Recognize SPDX 3.0 not merely as a tool but as a strategic asset.
   • Link SPDX 3.0 with the organization’s open source policy to build a consistent management system.
2. Automation first
   • Automate the process of generating and managing SPDX 3.0 documents as much as possible.
   • Integrate SPDX 3.0-related steps into the CI/CD pipeline to achieve continuous monitoring.
3. Strengthened risk management
   • Use the Security and License profiles of SPDX 3.0 to systematically manage the risks of using open source.
   • Conduct regular open source audits based on SPDX 3.0 to ensure compliance.
4. Decision support
   • Use SPDX 3.0 data to support informed decision-making about the adoption and use of open source.
   • Use it to develop a data-driven open source strategy.
5. Promoting collaboration
   • Use SPDX 3.0 to strengthen collaboration between the development, legal, and security teams.
   • Use its standardized format to facilitate information exchange with external partners.
6. Education and capability building
   • Open source managers should lead internal training based on a deep understanding of SPDX 3.0.
   • Actively participate in SPDX community activities to keep up with the latest trends and learn best practices.
7. Preparing for regulatory response
   • Use SPDX 3.0 to proactively address SBOM-related regulatory requirements.
   • Build a system that can flexibly respond to future regulatory changes.
8. Value creation
   • Use SPDX 3.0 to increase the efficiency of open source management and translate this into strengthened organizational competitiveness.
   • Document open source contribution activities with SPDX 3.0 to enhance the company’s technical capability and reputation.
9. Continuous improvement
   • Regularly evaluate the current state of SPDX 3.0 utilization and identify areas for improvement.
   • Quickly incorporate new profiles or features into the organization’s processes as they are added.
10. Leading innovation
    • Develop an organization-specific open source management model based on SPDX 3.0.
    • This helps secure a leading position in open source management within the industry.

In conclusion, SPDX 3.0 provides enterprise open source managers with a powerful tool for effectively managing and leveraging the open source ecosystem. By taking a strategic and systematic approach to using SPDX 3.0, organizations can maximize the benefits of open source while minimizing the associated risks. Through this tool, open source managers can play a central role in driving their organization’s digital transformation and strengthening its competitiveness.

French Court Orders Major Telecom Orange to Pay Damages for GPL Violation

Hello.

Today I want to look at a case in which a French court ordered the telecom company Orange to pay damages for violating the GPL. This case seemed especially worth noting for two main reasons.

• First, the defendant in this case is Orange, a major telecom operator. (Since I work at a telecom operator myself…)
• Second, while GPL violation lawsuits mostly arise in embedded devices, in this case the open source at issue was used to build a B2B web service. This underscores that open source license compliance matters across every area of software development.

Through these aspects, this case looks set to reaffirm the importance of open source license compliance. It stands as an important example emphasizing that companies must thoroughly understand and comply with license requirements when using open source.

Thanks to Manager Cheolung Park of SK telecom for his review and comments.

What Is GPL?

Short for GNU General Public License, GPL is one of the most representative open source licenses, a strongly copyleft license under which a software’s copyright holder “allows anyone to freely use, modify, and distribute the software, while imposing the condition that modified versions or derivative works must also follow the GPL.”

• Reference - GPL-2.0 Guide: https://sktelecom.github.io/guide/use/obligation/gpl-2.0/

Plaintiff: Entr’Ouvert

Entr’Ouvert, a French software company founded in September 2002, developed a C library named Lasso. Lasso is a library that implements authentication protocols such as the Liberty Alliance’s SAML standard.

Lasso is currently offered under two licenses.

• Open source license: GPL-2.0 + OpenSSL exception (requires source code disclosure)
• Commercial license (requires paid purchase)

We strongly recommend the use of the GNU General Public License each time it is possible. But for proprietary projects, that wouldn’t want to use it, we designed a commercial license.

https://lasso.entrouvert.org/

Defendant: Orange

In 2005, Orange, a major French telecom operator, signed a contract with the French agency for the development of electronic administration (ADAE, now DGME) to develop the “My Public Service” portal (now https://www.service-public.fr/).

At the time, this portal needed to use the SAML protocol to support an identity management service. Orange used Lasso to implement this, but did not comply with the terms of the GPL-2.0 license. That is, Orange did not identify the source and license of the Lasso software, and did not disclose the modified source code.

Entr’Ouvert discovered this and, in 2011, filed a lawsuit against Orange seeking damages.

The Ruling

The lawsuit ran for more than 10 years, and finally, on February 14, 2024, the Paris Court of Appeal ordered Orange to pay Entr’Ouvert a total of 650,000 euros (roughly KRW 940 million) for failing to comply with the GNU GPL v2 license. Orange must pay Entr’Ouvert 500,000 euros in compensation for economic loss and 150,000 euros for moral damages.

The court stated that “had Orange respected the license agreement and entered into a paid license, it would have had to pay royalties to Entr’Ouvert.” The court further noted that by using the Lasso software for free, Orange had unjustly profited over the seven years this large public-sector contract continued.

Takeaways

1. It is interesting that a telecom operator, now accelerating into non-telecom strategies as 5G growth hits its limits, became the target of this lawsuit. Telecom operators that are launching a variety of products and services in advanced technology fields such as AI, cloud, IoT, robotics, semiconductors, and UAM, and pushing into the B2B space alongside other industries, have now come to rely on open source in their software development just as companies in other industries do. Establishing policies and processes for open source management has therefore become important.

2. Open source license disputes have mostly arisen when a device or software product developed using open source is distributed without authorization. In this case, however, the subject of the dispute was open source used by a software supplier under contract to build a government agency’s website. Companies should therefore keep in mind that they need to apply open source management processes not only when distributing software devices, apps, and the like, but also when they enter into a B2B web service development contract and supply software to a government agency or client.

References

• French Court Issues Damages Award for Violation of GPL: https://heathermeeker.com/2024/02/17/french-court-issues-damages-award-for-violation-of-gpl/amp/
• https://www.entrouvert.com/actualites/2019/entrouvert-versus-orange/
• https://www.zdnet.fr/blogs/l-esprit-libre/non-respect-de-la-licence-gpl-orange-condamne-en-appel-39964312.htm

This blog post is based on a translation of an article originally written in French, and since my legal knowledge is very limited, there may be errors. If you find an error, please let me know (haksung@sk.com)

I’ll update it right away. ^^

Effective Open Source Management Practices for Companies (2): OpenChain Korea Work Group

In the previous post, I introduced the OpenChain Project for global collaboration as an effective open source management practice for companies. This time, I would like to introduce the OpenChain Korea Work Group, a collaborative community for Korean companies to effectively manage open source.

OpenChain Korea Work Group

The OpenChain Korea Work Group (KWG) is a subgroup of the Linux Foundation’s OpenChain Project. This group is a gathering where, through the open source spirit of collaboration and sharing, everyone thinks about and shares ways to succeed at effective open source management. Open source managers from Korea’s major ICT companies participate in the KWG.

OpenChain KWG Regular Meetings

Even large companies that have already established policies and processes for open source management find it difficult to escape open source license or security vulnerability risks, given today’s massive and complex software supply chains. Ultimately, it is important to raise the level of open source management across all companies in the software supply chain. To achieve this, companies with a high level of understanding of open source management practices need to first share their know-how and act as a guide so that other companies can easily participate.

Even if a company shares its open source management assets with competitors, this does not negatively affect revenue. Conversely, even if a company learns a competitor’s open source management policy, it cannot connect this to its own profit. If companies share open source management best practices with each other, each company can achieve significant results with less cost and fewer resources invested. Resonating with this idea, the first OpenChain KWG meeting, attended by open source managers from LG Electronics, SK telecom, Kakao, Hyundai Motor, and Samsung Electronics, was held in January 2019.

17th Meeting (In-Person)

The meetings are held every quarter, and were held online during the COVID-19 period. Then, on March 28, 2023, an in-person meeting was held for the first time in 3 years. About 50 open source managers from 19 companies/organizations attended. This in-person meeting was organized by LINE Plus. Thank you to LINE Plus’s open source managers Seoyeon Lee and Donghyuk Kim for providing a comfortable venue, refreshments, and souvenirs! ^^

In the first part of this meeting, there were presentations on the latest domestic and international trends in the OpenChain Project and the security assurance specification, as well as a presentation on legal issues and case studies related to AI technology. In the second part, there was a session presenting open source tools developed and shared by companies for open source management. I will cover the details of each presentation below.

Part 1: Session Presentations

OpenChain Global Update (Linux Foundation, Shane Coughlan)

Shane Coughlan, General Manager of the Linux Foundation’s OpenChain Project, attended in person and introduced the Global Trend of the OpenChain Project.

In addition to ISO/IEC 5230, the standard for open source compliance, ISO/IEC DIS 18974, a standard for security, is also under development. This standard is expected to soon be registered as an official ISO standard, and a Self-Checklist that companies must comply with has also been published. Companies can use these materials to carry out efficient open source risk management.

Shane also brought souvenirs for KWG members, which received a great response. (Thank you, Shane.)

Introduction to the OpenChain Security Standard (SK telecom, Haksung Jang)

ISO/IEC 5230 is the international standard for open source compliance. This standard was registered with ISO in 2020, and many companies around the world comply with this standard to carry out open source compliance management well. The reason companies need to manage open source is not only license compliance but also the risk of security vulnerabilities. The OpenChain Project has created a standard for security vulnerability management, ISO/IEC DIS 18974, the OpenChain security assurance specification. I gave a brief summary introduction of what this standard consists of.

This security standard is organized in the same format as ISO/IEC 5230. Instead of license compliance, it defines the requirements that must be fulfilled for security vulnerability management. In addition to license compliance, companies must establish policies and processes for security vulnerability management. They must also establish procedures to respond to discovered security vulnerabilities.

Legal Issues of AI Technologies / Case Study: Getty Images v. Stability AI (ETRI, Jungsuk Park)

Jungsuk Park of ETRI analyzed the recently filed Stable Diffusion-related lawsuit and introduced AI legal issues. The presentation materials can be found here.

Jungsuk Park analyzed the current status of AI-related legislation, and based on this, explored and shared ways to respond to AI-related open source compliance issues.

Part 2: Mini Summit - Open Source Management Automation Tools

In Part 2, there were session presentations sharing each company’s best practices for automating open source management.

Dependency Analysis Methods by Tool (Kakao, Hyunji Lim)

Hyunji Lim of Kakao presented a comparative analysis of the dependency analysis methods of open source analysis tools. The presentation materials can be found here.

She identified and shared the dependency analysis methods of the representative open source analysis tools FOSSA, FOSSLight, ORT (OSS Review Toolkit), and OLIVE Platform.

OSORI (LG Electronics, Soim Kim)

Soim Kim of LG Electronics gave a session presentation introducing the OSORI project.

OSORI is an open source project that discloses open source information data so that anyone can easily check open source information and comply with the necessary obligations. It defined a schema for building a database of the key information, license types, and related key compliance and restriction requirements for open source projects held by LG Electronics, Samsung Electronics, and Kakao, organized as tables by item, and introduced a roadmap for future data refinement, establishing operating policy, and building a guide page.

FOSSLight Roadmap (LG Electronics, Kyungae Kim)

FOSSLight is an integrated open source management system developed in-house by LG Electronics, which was open-sourced in 2021 for anyone to use. Kyungae Kim of LG Electronics introduced the 2023 FOSSLight Roadmap.

The FOSSLight Project has a roadmap for 2023 that includes improving security vulnerability features, strengthening SBOM functionality, and improving UX.

Have You Tried OLIVE Lately? (Kakao, Eunkyung Hwang)

OLIVE Platform is an open source license verification service developed by Kakao, which anyone can use for free with just a Kakao account. Eunkyung Hwang of Kakao introduced the key features of the OLIVE Platform.

The OLIVE Platform added the OLIVE CLI feature, which can be used safely even when there are concerns about source code exposure, allowing it to be adopted even in the security-sensitive financial sector.

onot Has Gotten Pretty Usable! (Kakao, Hyeonmin Han)

onot is an open source project jointly developed by SK telecom and Kakao. It is a tool that automatically converts an SBOM written in the SPDX format into an open source notice. Hyeonmin Han of Kakao introduced the new features recently added to onot. The presentation materials can be found here.

onot can now extract file information in addition to package information, and now also supports multi-license notation. It can generate open source notices from SPDX documents in RDF/XML format as well, and now supports a more convenient user environment, such as a GUI on Windows PCs.

Closing

The in-person meeting, held for the first time in about 3 years, was so packed with content that the short time felt like too little. Thank you again to Seoyeon Lee and Donghyuk Kim of LINE Plus for preparing a wonderful venue, souvenirs, and even raffle prizes.

Companies face similar difficulties in open source management work, and sharing how they overcame and streamlined these challenges is of great help to one another. The OpenChain Korea Work Group is a gathering that anyone who shares this sentiment can voluntarily join. Anyone in charge of open source management at a company or organization can participate in the OpenChain Korea Work Group: How to Join

Lastly, the OpenChain KWG holds regular meetings every quarter. The next meeting is expected to be held at Kakao.

Until then, happy days to everyone!

Effective Corporate Open Source Management (1): The OpenChain Project for Global Collaboration

Using open source has become almost essential to modern software development, to the point that it is said over 93% of the software products companies develop use open source. Yet there are reports that 53% of the open source used has license compliance issues, and 81% has security vulnerabilities. Given the complexity of modern software development environments and the vast software supply chain, companies developing products with open source need open source management efforts to minimize license compliance and security vulnerability risks. The Linux Foundation’s OpenChain Project is a project for carrying out these efforts at the community level, with multiple companies sharing and collaborating together.

On March 27, 2023, Shane Coughlan, General Manager of the OpenChain Project, visited SK telecom for a session explaining the OpenChain Project’s major activities, international standards related to open source, and global trends.

Members of SK telecom’s OSRB and the SK Group open source council (SK Planet, SK Shieldus, SK Inc., the Supex Council, and others) took part and exchanged various opinions.

On this day, Shane introduced the OpenChain Project and explained how it jointly resolves open source management issues in the software supply chain through global collaboration. This article introduces the main points.

OpenChain Project Global Community

Multiple global companies collaborate through the OpenChain Project to manage software supply chain issues: https://www.openchainproject.org/community

Platinum Members

Community Structure

The OpenChain Project has numerous Work Groups, and each Work Group develops standards for open source management and jointly builds automation tools. There are also Work Groups organized by country.

OpenChain Standard

ISO/IEC 5230:2020, ISO/IEC DIS 18974

The most visible outcome is the development of the first international standard for open source management. In December 2020, ISO/IEC 5230 was registered as the sole international standard for open source compliance. ISO/IEC DIS 18974 is the de facto standard for open source security assurance compliance, and is scheduled to be formally registered as an ISO standard in the second half of 2023.

These standards define the core requirements companies need to manage open source. By complying with the requirements of these standards, a company can transparently demonstrate that open source management is taking place within its software supply chain.

Self-Certification

The OpenChain Project also provides a checklist for Self-Certification. Companies can raise their level of open source management by working through the checklist items one by one.

Adoption of OpenChain ISO/IEC 5230:2020

A company that complies with every item on the checklist can declare itself compliant with ISO/IEC 5230. The list of companies that have declared adoption of ISO/IEC 5230 includes several Korean companies as well, such as LG Electronics, Kakao, Samsung Electronics, Naver, SK telecom, NCSOFT, and Hyundai Motor Group.

Other Interesting Items

Online Webinar

The OpenChain Project continues to hold online webinars on open source management.

Training Courses

A free training course for open source license compliance is provided, and a badge can also be earned upon completion.

This training course is put to various uses, such as companies requiring their employees or suppliers to complete it.

Update on China and Japan

China

Collaboration with the OpenChain Project is also active in China. In particular, discussions on collaboration are underway with Chinese government bodies such as CAICT and CESI.

Companies such as Huawei, Honor, and OPPO also actively participate in the OpenChain China Work Group, which has around 250 members.

Starting in the second quarter of 2023, a quarterly event co-hosted by OpenChain and CAICT is planned, and the Asian Legal Network (ALN) together with OIN is also said to be restarting.

Japan

The OpenChain Japan Work Group has around 190 participating members. Fujitsu, Hitachi, NEC, Panasonic, Sony, Toshiba, and Toyota provide ongoing support, and community events are held every other month.

In collaboration with TODO Group, OSPO events are also held every two weeks.

Korea Market: Challenges and Opportunities

Current Situation

The OpenChain Korea Work Group is an excellent Work Group that ranks second in the world in scale and enthusiasm, after Japan. Major companies such as SK telecom, LG Electronics, Samsung Electronics, and Hyundai Motor participate, and NIPA is also involved through sponsorship and other means.

That said, Korea is not immune to the risk posed by the global economic downturn. It is also a shame that there is no Korean corporate member on the OpenChain Board.

Opportunities

If the OpenChain Korea Work Group continues its community meetings and activities as it has so far, opportunities will keep coming. If possible, it would be good to work toward including the OpenChain standard in government open source policy, as Japan and China have done, and to encourage the participation of government bodies for this purpose.

Lastly, if a Korean company joins the OpenChain Board, it would increase the strategic diversity of the OpenChain Project and help grow its influence in the global supply chain.

Closing

The OpenChain Project is a community for applying the open source approach of sharing and collaboration to the field of corporate open source management itself, so that everyone can together achieve a high level of risk management practice with lower cost and fewer resources. The OpenChain Korea Work Group is where companies that share this purpose gather. Nearly 100 open source managers from various companies have joined the OpenChain Korea Work Group’s mailing list and are active there. As it happens, an offline meetup was held on March 28, the first in three years since COVID. I will cover this in detail in the next article.

After the meeting session with Shane, we enjoyed a nice lunch sponsored by SK telecom’s Tech HR team. (Thank you, Sangki~ ^^)

Thank you.

Buy Anaconda If You Use It. If Not, Use conda-forge!

Hello.

Do you often use Anaconda when setting up a Python development environment? Python is widely used for everything from simple task automation to data analysis, AI training, and modeling, and running multiple Python projects can create the inconvenience of package version conflicts. Anaconda has the advantage of providing a virtual environment for each development project to prevent version conflicts, and it is widely used because it can be easily downloaded and installed from the homepage.

https://www.anaconda.com/

But you need to buy Anaconda to use it.

In September 2020, Anaconda changed its Terms of Service to require payment when a company or government organization with 200 or more employees uses the Anaconda Repository.

Therefore, if you are a developer working at a company with 200 or more employees, you must purchase a Pro or higher license on the Anaconda website.

https://www.anaconda.com/pricing

Let’s look a bit more closely. To install Anaconda, you can typically download the Anaconda Distribution for free from the Anaconda homepage.

https://www.anaconda.com/products/distribution

Installing it sets up a development environment easily, since the conda package manager, Python, and about 150 packages are installed together.

Anaconda Inc. hosts the Anaconda Repository, providing over 8,000 open source packages, and users can reliably install and manage these packages with the conda install PACKAGENAME command.

https://repo.anaconda.com/

The Terms of Service for this very Anaconda Repository is what changed in September 2020, and free use of the Anaconda Repository is no longer possible for commercial activity.

Many developers easily download and use the Anaconda Distribution, but in doing so they end up using the Anaconda Repository. For a developer at a company with 200 or more employees, this results in “unintentionally” violating Anaconda’s Terms of Service, and to avoid this you must purchase Anaconda Pro or higher.

For reference, Miniconda is, like Anaconda, a software package that installs the conda package manager, Python, and minimal dependencies. Using Miniconda also accesses the Anaconda Repository to download packages, so it can be considered subject to the same paid-purchase requirement as Anaconda.

https://docs.conda.io/en/latest/miniconda.html

In the end, even if a developer at a company with 200 or more employees downloads and uses the Anaconda Distribution for free, they won’t immediately be charged or have features blocked. Still, for the stable development of Anaconda, it would be good for developers at companies with 200 or more employees to voluntarily purchase and use it. (Of course, a license violation notice and invoice could show up at the company at some point. ^^)

There is an alternative: ‘conda-forge’

Anaconda Inc. publishes and maintains the package manager conda as open source. conda itself is open source released under the BSD-3-Clause license, so there is no problem with companies using it for free.

https://github.com/conda/conda

conda needs a repository location to find packages to install and manage, and this is called a channel. The default channel is the Anaconda Repository. However, there is also a community-based repository: conda-forge.

https://conda-forge.org/

You can install conda and add conda-forge as a channel.

conda config --add channels conda-forge
conda config --set channel_priority strict

This way, since you are not using the Anaconda Repository, you can use conda without violating the Terms of Service described above.

Peter Wang, CEO of Anaconda Inc., has stated directly that downloading Miniconda and changing the conda config to conda-forge allows free use.

https://www.reddit.com/r/Python/comments/iqsk3y/comment/g4xuabr/

Removing the defaults channel, which points to the Anaconda Repository, entirely can more reliably restrict use of the Anaconda Repository.

conda config --remove channels defaults

You can check whether the channel has changed as intended with the command below.

### Before the change
% conda config --show channels
channels:
  - defaults

### After the change
% conda config --show channels
channels:
  - conda-forge

Miniforge adds conda-forge to the channel at installation.

Going a step further, Miniforge is an open source project that provides a minimal installer for conda, and it adds conda-forge to the channel by default at installation. Miniforge is also known to support various CPU architectures, including Apple M1.

https://github.com/conda-forge/miniforge

Therefore, if you install Miniforge instead of Anaconda, it appears you can relatively easily set up a development environment with the conda package manager without violating the license.

One interesting point is that operating conda-forge requires substantial hosting costs, which Anaconda Inc. pays. Anaconda Inc. explains that it needed the revenue from changing the Anaconda Repository’s Terms of Service in order to keep conda-forge free.

In conclusion, considering development convenience and stability, it would be good to purchase and use Anaconda Pro where possible. Until then, to avoid license issues, you might consider the Miniconda + conda-forge combination, or Miniforge, as alternatives.

Please let me know if there is anything incorrect. ^^

Thank you.

Akka Is No Longer Open Source.

There is a growing number of cases where software companies that started out as open source change their license policy. Lightbend, a US company that had maintained an Apache-2.0 open source license policy, announced in September 2022 that it would change Akka’s license to BUSL-1.1 (Business Source License). Let’s take a look at what the Business Source License is, and what the background and impact are of Lightbend changing Akka’s license to BSL.

What is Akka?

Akka is a toolkit that simplifies distributed applications, in which multiple threads work concurrently on the JVM, based on the Actor Model. It is reportedly used mainly in backend platforms that require high performance, such as live chatting.

The License Change

Lightbend, a US company, changed Akka’s license in September 2022.

The main points of the license change are as follows.

• Akka, which was open source (Apache-2.0), will be under a new license starting with v2.7.
• The new license is BUSL-1.1 (Business Source License).
• It can be used for free for noncommercial purposes, but a license fee must be paid for commercial use.

Lightbend stated that it had supported the Akka open source project under Apache-2.0 for over a decade, but that it had become difficult to sustain this.

Over the years, Lightbend has steadily borne more of the support for Akka. With Akka now considered critical infrastructure for many large organizations, the Apache 2.0 model becomes increasingly risky when a small company solely carries the maintenance effort. Balancing the global demands of our corporate community while supporting these needs of a vast open source base is a tremendous weight to bear.

In the end, Lightbend also gave up sustaining the Apache-2.0 open source model, and instead introduced BUSL-1.1, a “Source Available” license, to disclose source code to the community while generating revenue by charging enterprise users a license fee. The number of cases where companies that develop software as open source change their license policy to improve profitability has been increasing since 2018. MongoDB’s SSPL is a representative example, and Elasticsearch introduced the Elastic License. You can find the details on this in the previous post, ‘Elastic License 2.0 (subtitle: The Evolving Open Source License)’. It can be inferred that Lightbend also decided to change its license considering this background and profitability.

BUSL-1.1 had already been applied to several projects that used to be open source, even before Akka.

• MariaDB
• CockroachDB
• Sentry
• materialize

Business Source License

How is BUSL-1.1 different from an open source license?

Grants the right to use only for non-production use

Unlike a typical open source license, BUSL-1.1 grants the right to copy, modify, and redistribute only for non-production use.

The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work.

If your use does not qualify as non-production use, you are required to purchase a commercial license from the Licensor.

If your use of the Licensed Work does not comply with the requirements currently in effect as described in this License, you must purchase a commercial license from the Licensor, …

Therefore, companies using the version of Akka to which BUSL-1.1 applies (v2.7 and later) can no longer use Akka for free and must purchase a commercial license from Lightbend.

Change Date, Change License

Another characteristic of BUSL-1.1 is the Change Date and Change License. Once the Change Date passes after a version of the software under BUSL-1.1 is released, the Change License applies and BUSL-1.1 no longer applies.

Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.

For Akka’s BUSL-1.1, the Change Date is 3 years after release, and the Change License is Apache-2.0.

For example, if Akka 2.8 were released on January 1, 2023, after 3 years, from January 1, 2026, Apache-2.0 would apply and companies could also use it for free. BUSL-1.1 provides this Change License provision so that you have to pay to use the new version, but even old versions can be used for free even for commercial purposes. This appears to reflect an intent to charge large companies, the heavy users of the software.

Additional Use Grant

BUSL-1.1 has an Additional Use Grant provision that allows the Licensor to grant rights to commercial users under certain conditions.

The Licensor may make an Additional Use Grant, above, permitting limited production use.

Therefore, the Licensor can permit users to use the software for commercial purposes as needed. For example, Lightbend permitted the use of Akka when developing an application using Play Framework that utilizes akka.

Additional Use Grant: If you develop an application using a version of Play Framework that utilizes binary versions of akka-streams and its dependencies, you may use such binary versions of akka-streams and its dependencies in the development of your application only as they are incorporated into Play Framework and solely to implement the functionality provided by Play Framework; provided that, they are only used in the following way: Connecting to a Play Framework websocket and/or Play Framework request/response bodies for server and play-ws client.

Akka License FAQ

Lightbend provides an FAQ related to the Akka license change, and here are a few of the key points.

Free for startup-sized companies

First, looking at Akka’s pricing, it is provided for free to startup companies with annual revenue under $25 million.

Can I keep using older versions of Akka?

The license of older versions remains unchanged as Apache-2.0. However, additional features, improvements, non-critical security updates, and non-critical bug fixes will not be provided. For version 2.6.x, only critical security updates and critical bug fixes will be provided under Apache-2.0 for the next year, i.e., until September 2023.

We use it for production, as well as for development, testing, and staging. In which cases do we need a commercial license?

You only need a commercial license for the copies of the software used for production.

I work at a government department not related to revenue. Do I need to purchase a commercial license?

If Akka is used in production rather than for non-production use, a commercial license purchase is required even for government departments.

Government departments using Akka in production will require a commercial license.

Can I backport parts of BUSL-1.1 software to an older version under Apache-2.0?

No. This would violate Lightbend’s copyright, as well as Apache-2.0.

No. In this circumstance, you would either violate Lightbend’s copyright by re-releasing the code under Open Source, or you would violate the earlier Akka version’s Apache license by introducing incompatible BSL code (i.e., code subject to a use limitation not allowed by the Open Source Apache 2.0 license).

Closing

The role of corporate open source governance is becoming increasingly important. Using open source in products while complying with open source license obligations, such as attribution notices and source code disclosure, is a basic compliance activity that companies must maintain. However, there has recently been an increase in cases where software that used to be open source changes to a license that requires a commercial purchase, such as BUSL-1.1. Therefore, companies developing products/services using open source need to respond quickly to such license changes. Otherwise, it should be remembered that a license violation could result in significant losses.

In particular, companies should build an SBOM (Software Bill of Materials) management system so that, when they identify a license change case like this one with Akka, they can immediately determine which products/services or internal systems within the company use Akka and which version, and take the necessary action (using an older version, or purchasing a commercial license).

Thank you.

A Quick Look at the SFC v. Vizio Ruling

Hello, this is Haksung Jang.

SFC (Software Freedom Conservancy) filed suit against Vizio, a US smart TV manufacturer, alleging violations of the GPL. On May 13, 2022, a US federal court issued a ruling related to this case.

I have put together a superficial summary of the background and implications of this ruling. Since I am not a legal expert, there may be errors in terminology or interpretation. I would appreciate it if experts could provide feedback. ^^

References

First, I would like to disclose the references I consulted while writing this article.

• PROCEEDINGS: (IN CHAMBERS) ORDER GRANTING PLAINTIFF’S MOTION TO REMAND: https://storage.courtlistener.com/recap/gov.uscourts.cacd.837808/gov.uscourts.cacd.837808.30.0.pdf
• Software Freedom Conservancy files right-to-repair lawsuit against California TV manufacturer Vizio Inc. for alleged GPL violations: https://sfconservancy.org/copyleft-compliance/vizio.html
• SFC Files GPL Enforcement Suit Against Vizio Advancing Novel Legal Theories: https://heathermeeker.com/2021/11/09/sfc-files-gpl-enforcement-suit-against-vizio-advancing-novel-legal-theories/
• First Update on the Vizio lawsuit: https://sfconservancy.org/blog/2021/nov/30/vizio-update-0/
• SFC v. Vizio remanded back to California state courts: https://lwn.net/Articles/895405/
• Software Freedom Conservancy right-to-repair lawsuit against California TV manufacturer Vizio, Inc. remanded to California State Court: https://sfconservancy.org/news/2022/may/16/vizio-remand-win/
• US court holds “GPL is a contract too” … recognizes consumers’ right to demand code (Korean article): https://zdnet.co.kr/view/?no=20220518145132
• Open source license violations and copyright infringement (Korean article): https://olis.or.kr/library/openSwDetail.do?bbsId=103&bbsNum=26400
• Legal effect of open source licenses (Korean article): https://www.copyright.or.kr/information-materials/trend/the-copyright/download.do?brdctsno=10231&brdctsfileno=4699
• Characteristics of the Federal Court (Korean article): https://lawandstory.com/연방-법원federal-court-특징/

1. Background

On May 18, an article titled “US court holds ‘GPL is a contract too’ … recognizes consumers’ right to demand code” was published. The following sentence seemed to convey something important, but I did not quite understand exactly what it meant.

Out of curiosity, I looked into some materials and summarized what I understood in my own way. I hope this helps others who have had similar questions.

1-1 Copyright Law and Contract Law

Copyright Law

• A licensee may use a work within the scope of the methods and conditions of use permitted by copyright law.
  • Here, “use” refers only to acts granted by economic rights under copyright, such as reproduction, public transmission, distribution, and the creation of derivative works; it does not include “usage” in the ordinary sense.
  • If there is a method or condition attached to an act of “usage” and it is violated, this does not constitute infringement of economic rights under copyright; only liability for breach of contract arises.
• If a licensee acts outside the scope of the methods and conditions of use permitted by copyright law, this constitutes copyright infringement.
• If it constitutes copyright infringement, criminal punishment and injunctive relief are possible for violation of copyright law.

Contract Law

• A contract is generally an agreement between a licensor (in the case of open source, the copyright owner) and a licensee.
• To impose liability under contract law, it is first required that a contract was validly formed between the two parties.
• If a party breaches an obligation it bears by virtue of the contract’s (agreement’s) effect, only contractual liability for non-performance arises.
  • There is no risk of criminal punishment or injunctive relief, as with copyright infringement, but the agreed-upon amount of damages must be paid.
  • Whether a work under an open source license constitutes formation of a contract is disputed depending on jurisdiction.
• Damages amounts and remedies are limited.

Examples

• Copyright holders of GPL software have filed suit alleging copyright infringement
  • e.g., Harald Welte, Patrick McHardy
• Jacobsen v. Katzer precedent
  • If a copyright license imposing license conditions is not complied with, this constitutes copyright infringement.
  • If a license provision is a condition, copyright law applies; if it is merely a covenant, contract law applies.
• Hancom vs. Artifax
  • Hancom argued that there was no breach of contract because there was no act such as signing a contract or a process of mutual agreement.
  • The court ruled that this constituted a breach of contract.

1-2 US Federal Courts and State Courts

• The United States has federal courts and state courts, each handling cases of a different character.
  • State courts: generally handle cases affecting the personal lives of residents (family law, probate law, etc.)
  • Federal courts
    • Consist of District Courts, Appellate Courts, and the Supreme Court.
    • Handle only a limited set of cases: constitutional matters, federal crimes, military law, intellectual property, etc.
    • Copyright law (the Copyright Act) is handled in federal court.
• In the United States, federal courts have exclusive jurisdiction over copyright claims.
  • Accordingly, in the past, nearly all claims in US GPL litigation were brought in federal court, which has exclusive jurisdiction over copyright law.
• If a complaint is filed in the wrong court, the case will be dismissed or transferred to another court.
  • That is, an action filed in state court can be removed if it is preempted by federal court jurisdiction.

2. History of the SFC v. Vizio Lawsuit

SFC filed suit against Vizio in October 2021. The contents of the suit at the time and the subsequent history are as follows.

2021-10-19

• SFC filed suit in state court against Vizio, alleging violations of the GPL and LGPL in connection with SmartCast TVs.
  • plaintiff: Software Freedom Conservancy, Inc. ("SFC")
  • defendant: Vizio, Inc. ("Vizio")
  • allege:
    • Vizio uses “at least twenty-five programs, including the Linux kernel software” in its smart TVs that are covered by the GPL Agreements,
    • Vizio does not make the corresponding source code for these programs available to purchasers of its smart TVs.
  • seek:
    • to enforce SFC’s right to have access to the source code corresponding to the executable code resident on Vizio’s devices covered by the GPL Agreements.
    • as a remedy to its breach of contract claim, SFC seeks to compel Vizio to make the source code available
  • claim:
    1. breach of contract and
    2. declaratory relief
       • Declaratory relief is a procedure within US civil procedure whereby a judge declares the rights, obligations, and responsibilities of the parties in a civil suit, without ordering any performance, action, or compensation. In patent and similar litigation, it is used by an alleged infringer as a claim or counterclaim against a patent holder to seek a declaration of non-infringement, invalidity, or unenforceability.
  • See: “Recent litigation cases: Stockfish v. ChessBase, SFC v. Vizio (Wonjae Park)”

2021-11-29

Vizio responded to this as follows.

• Violating the GPL constitutes copyright infringement.
• Because copyright law is preempted by federal courts, this is not a matter for state courts.
• Under copyright law, only the copyright owner has the right to request source code under the GPL and LGPL, and SFC, as a consumer, has no right to demand source code.

For this reason, Vizio requested that the case, filed in state court, be handled by federal court instead (NOTICE of REMOVAL of ACTION to FEDERAL COURT).

If the federal court approves this, the case would need to be reviewed under US copyright law, and since SFC is not the copyright holder, it would not even have standing as a plaintiff.

In Response,

SFC rebutted Vizio’s arguments and filed a Motion to Remand with the federal court to have the case sent back to state court.

2022-05-13

The federal court granted SFC’s Motion to Remand (ORDER GRANTING PLAINTIFF’S MOTION TO REMAND) and remanded the case to state court.

3. Points Worth Noting

This lawsuit has several new aspects compared to prior GPL litigation. Heather Meeker, a US open source attorney, explained this as follows.

3-1. Breach of Contract and Specific Performance

• In the past, nearly all GPL litigation was brought as a claim of copyright infringement.
• However, this lawsuit is a claim under contract law, not copyright law.
• Rather than seeking monetary damages, it seeks to require that all TV purchasers be provided with the technical information required by the copyleft license (disclosure of source code).
  • Rather than compensation for “damages,” it seeks disclosure of source code: “specific performance.”
• Under contract law, any remedy sought other than monetary damages amounts to a demand for specific performance (specific performance is an unusual remedy under contract law).
• Generally, a plaintiff seeks specific performance instead of compensation from a defendant who breached a contract when the plaintiff wants something that money cannot replace.

3-2. Claim Brought in State Court

• In the United States, federal courts have exclusive jurisdiction over copyright claims.
• Accordingly, in the past, nearly all claims in US GPL litigation were brought in federal court, which has exclusive jurisdiction over copyright law.
• However, this lawsuit brought by SFC was filed in state court in Orange County, California.
• State court litigation, compared to federal court, is less predictable, less consistent in outcome, and more likely to produce unexpected views on novel legal theories.

3-3. No Author as Plaintiff

• SFC filed suit as a purchaser of the product.
• In past GPL litigation, the plaintiff was the copyright owner of the GPL software.
• In contrast, the plaintiff in this lawsuit is SFC, filing suit as a consumer who purchased a Vizio TV.
• SFC aims to establish that not only copyright owners but also consumers of a product have the right to receive GPL source code.

3-4. Declaratory Relief

• This lawsuit essentially asks the court to declare that the GPL and LGPL are legally enforceable and that Vizio violated them.
• Even treating the GPL as a contract, since a contract is generally an agreement between a licensor (i.e., the code copyright owner) and a licensee, it is difficult to view SFC as a party to the contract.
• For this reason, SFC brought suit under the theory that it, along with all consumers, is a third-party beneficiary of the contract.
  • Third Party Beneficiary: a person who is not a party to a contract but who can sue to enforce the contract — that is, a person who, although not a party to the contract, is directly involved in the benefit of the contract.
  • Third-party beneficiaries of the GPL: those who are not parties to the GPL contract, but who can obtain a benefit when the parties to the GPL contract perform it faithfully. One example of such a benefit is receiving the source code of GPL software.

4. Key Contents of the Federal Court Ruling (2022-05-13)

Let’s look at what the federal court ruled on May 13, 2022.

4-1. The Central Question

The court first explained the central question that the federal court needed to decide, as follows.

• The only issue the court needs to decide is whether the federal Copyright Act completely preempts SFC’s claims (breach of contract and declaratory relief) so as to create federal jurisdiction.
• If the claims are equivalent to rights within the general scope of copyright covered by federal copyright law (such as the exclusive rights of reproduction, distribution, and display of derivative works), they are preempted by federal copyright law and therefore create federal jurisdiction.
• To argue that a case is not preempted by federal copyright law, the cause of action must protect rights other than those protected by copyright, and there must be an “extra element” that changes the nature of the suit.

4-2. Relevant Precedent: “Versata Software vs. Ameriprise”

• The GPL’s requirement to disclose source code for a derivative work is separate from copyright obligations.
• The defendant was not sued for copyright infringement.
  • It was sued by the plaintiff for violating an “additional obligation” — failure to comply with the source disclosure obligation — regarding a derivative work incorporating an open source program.
• In this way, an “additional contractual promise” that does not correspond to a right provided by copyright law constitutes an “extra element.”

4-3. Whether SFC’s Claim Is an “Extra Element”

• The purpose of copyright protection is the exclusive right to restrict who may reproduce, distribute, and display a work.
• However, copyright law does not grant a right to receive source code. Such a right is, if anything, the opposite of the exclusive rights protected by copyright law.
• SFC’s assertion, as a non-copyright-holder, of standing as a third-party beneficiary of the GPL agreement is distinct from rights arising under copyright law.
• In other words, SFC’s claim that it is entitled to receive source code as a third-party beneficiary of the GPL agreement is an “extra element.”

4-4. Whether Vizio’s Argument Is Valid

• Vizio argues that violating an open source license is copyright infringement, but SFC did not make a claim of copyright infringement in this lawsuit.
  • There is no reason for the court to rule on a matter the plaintiff did not claim.
  • Furthermore, since SFC is not the copyright holder, it could not even make such a claim.
  • SFC is not trying to use copyright law to restrict Vizio’s ability to reproduce or create derivative works; it is merely requesting that Vizio provide source code.
• Vizio argued that since providing source code is a “condition” of the license, violating it is not a “breach of contract” but “copyright infringement.”
  • Accordingly, Vizio argued that SFC’s “contract claim” should be converted into a claim of copyright infringement.
  • However, only the violation of a “condition” — defined as “an act or event that must occur before a duty of performance arises” — can constitute copyright infringement; violations of all other license terms and covenants can only be litigated under contract law.
  • Furthermore, ambiguous contract provisions are interpreted as covenants, not conditions.

4-5 Ruling

• SFC’s claims were not completely preempted by copyright law.
  • A GPL agreement functions both as a copyright license and as a contractual agreement.
• Accordingly, the federal court lacks jurisdiction, and the Motion to Remand to state court is GRANTED.

5. Implications

SFC stated regarding this ruling that, while many people believe the GPL functions only as a copyright license, this decision marks a watershed moment in the history of copyleft licensing, showing that it functions as a contract as well as a copyright license. SFC also stated that this lawsuit is the first legal case to focus on the rights of individual consumers as third-party beneficiaries of the GPL, and that it looks forward to the opportunity to establish these consumer rights in state court.

Honestly, when I skimmed only the domestic (Korean) news coverage, I thought SFC had won the lawsuit and that ordinary consumers now had a legal right to demand GPL source code from companies. But this ruling was not a final decision on that question. As I understand it, it is a ruling that grants an opportunity to litigate this matter in state court going forward.

Finally, Heather Meeker’s commentary on this is a useful reference.

• SFC is trying to establish a new standard for GPL litigation. This is welcome, but there are also concerns about a backlash.
  • Over the past 25 years, many companies that build products using GPL software have not been greatly worried about GPL litigation.
  • If SFC prevails in this lawsuit, companies could become burdened in using GPL code, which could become an obstacle to the spread of free software.
  • Also, if the general public becomes able to bring GPL litigation, trolls seeking purely financial gain could emerge.
• It is also not yet known whether SFC’s attempt will succeed.
  • The fact that the federal court did not dismiss the case but instead remanded it to state court can be seen not as fully accepting SFC’s arguments, but simply as a determination that the case was not appropriate for federal court and therefore there was no basis for dismissal.
  • For now, SFC has gained a foothold to argue that it is entitled, as a third-party beneficiary of the GPL, to demand disclosure of source code from the defendant.
  • However, this lawsuit could become complex, prolonged, and costly going forward.
  • Most GPL litigation is often resolved quickly through settlement.

With that, I will wrap up this summary and take another look at the domestic article that I had trouble understanding earlier.

Now it seems to make sense. However, I still don’t understand why it says the case was remanded “(to a higher court).” A US district court is a federal court, and this case was remanded to state court — so why does it say remanded “(to a higher court)”? Is it a typo? Do Americans refer to state courts as a “higher court”? Or am I misunderstanding something? I would welcome an opinion from a legal expert. :)

Thank you.

Challenges and Effects of Adopting InnerSource

Hello, this is Haksung Jang.

InnerSource is a method of introducing open source development methodology inside an organization to maximize cross-team sharing and collaboration, and to gain effects such as faster development speed, transparent communication, and improved code quality.

Several documents explain methods for InnerSource. Today I have briefly summarized the ways to start InnerSource and the expected effects as described in the following material, so please refer to it.

• Getting Started with InnerSource (Keys to collaboration and productivity inside your company) / Andy Oram

1. Key Open Source Practices

First, let’s look at the key practices emphasized in open source development methodology. How can a massive open source project grow through voluntary participation? Why is it said that participating in an open source project can lead to individual developer growth? This is because open source projects have the following key practices.

(1) Cross-Team Collaboration

• In open source projects, code is shared with the whole world, so anyone can freely view, learn from, and improve it.
• There are rules for freely creating and merging branches, and tools that make this possible.
• This allows people to work on the same code regardless of their work location.

(2) Documentation

• Open source projects document code in as much detail as possible.
• This documentation leads to improvements in software architecture. When explaining something through documentation, you come to empathize with the need to change a complex, unintuitive architecture.
• Well-documented projects also make it easier for new contributors to join.

(3) Continuous Test

• Open source projects generally build a strict system for objectively testing each contribution. This maintains trust among collaborators and guarantees code quality.
• In other words, there are tools and procedures to verify quality before committing a change.
  • unit test
  • continuous integration
  • code coverage
  • static analysis, etc.
• Each developer must write unit tests for their own code.

(4) All Communication and Decision-Making Is Made Transparently Public

• In open source projects, all communication is made public and left as a record.
• Decisions are mostly made based on discussions on mailing lists.
• Because all communication is documented and left as a record, anyone can understand the project through the documentation and newly join it.

(5) Developers Can Have Their Skills Recognized, and Mentor Other Developers

• A developer who has contributed many commits can be regarded as a developer with a deep understanding of the project.
• Such a developer comes to be recognized as a Trusted Committer.
• A Trusted Committer is given the qualification to review / approve other developers’ work.
• They also play a role in growing contributors into excellent developers by providing them with mentoring.

2. Effects of Adopting InnerSource

When a company introduces the open source practices described in section 1 internally, this is called InnerSource. For reference, InnerSource has its techniques and practices developed more systematically by communities such as InnerSource Commons.

So what effects can a company expect when it adopts InnerSource?

1. Code reuse increases across the organization as a whole.
   • Developers on each team can understand, use, and contribute to modules and architecture developed by other teams.
2. Code quality improves.
   • Quality improves through unit tests, code coverage, CI (continuous integration), static analysis, code review, and so on.
3. Development speed increases.
   • As developers learn unit tests, code coverage, and CI (continuous integration), bugs decrease and development speed increases.
   • Communicating through written comments may seem to take time at first, but it helps new developers learn the system faster, which further improves development speed.
4. As developers learn new skills in code design, testing, and documentation, they come to think about code design more comprehensively.
5. Developers become better at documentation, which helps other team members understand the project better and make more contributions.
6. Empowering developers can increase their intellectual growth and job satisfaction.

3. Challenges to Adopting InnerSource

Now let’s look at the challenges a company must consider when trying to adopt InnerSource.

Simply opening and sharing source code internally cannot be expected to produce the effects of InnerSource on its own. The following must necessarily accompany it.

1. Documentation of all code in the repository
2. Providing a collaboration environment and guides, such as GitHub, for collaboration
3. Building a test environment and establishing rules: to guarantee the quality of newly incoming code
   • Running a code coverage test on at least 90% of the code before it is committed
   • Triggering an automatic build when a commit is made
4. Defining modular architecture and APIs to encourage contributions from other organizations
5. Giving participants pride in the work they have done, and actively encouraging them to present at conferences or contribute blog posts

4. Why Should Developers Participate in InnerSource Projects?

Even after an InnerSource environment has been built internally, developers who are busy with tasks within their own team may find it daunting to look at or contribute to another team’s code. However, participating in InnerSource projects is helpful for developers’ own growth.

1. By participating in an internal InnerSource project before jumping straight into an external open source project, developers can learn and become familiar with open source practices.
   • In InnerSource, code review, commits, and testing are carried out in the open source way.
   • Developers become accustomed to documentation.
   • By learning new skills in testing and documentation, they can become excellent developers who think about code design more comprehensively.
2. Simply observing the communication between a Trusted Committer and a Contributor is itself helpful.

For why developers should contribute to open source, please also refer to the following blog post: “Why Developers Should Contribute to Open Source”

Thank you.

Can I Use a Publicly Available Dataset to Build a Commercial AI Service?

Hello, I’m Haksung Jang.

AI has become such an essential technology in modern business that virtually no company operates without using it. Building an AI service requires large volumes of data, and publicly available datasets are also widely used for this purpose. However, even a publicly available dataset carries copyright, so using it in a commercial AI service requires checking its license to minimize legal risks such as copyright infringement.

Today, I want to introduce a recently published paper on this topic: Can I use this publicly available dataset to build commercial AI software? – A Case Study on Publicly Available Image Datasets: https://arxiv.org/abs/2111.02374

I hope this post gives some insight into the efforts and procedures needed to minimize copyright infringement when building an AI service that relies on publicly available datasets.

1. Intro

The paper first explains that, unlike open source licenses, licenses for using publicly available datasets present several difficult problems.

GitHub Copilot

Let me briefly touch on the debate surrounding GitHub Copilot here. The U.S.-based Software Freedom Conservancy (SFC) recently published a post titled “If Software is My Copilot, Who Programmed My Software?” pushing back against the claims made by Microsoft and GitHub.

Copilot is an AI service that GitHub trained on publicly available source code to help developers write code, and because this includes copyleft software, it has become a legal issue. In response, GitHub CEO Nat Friedman made the following counterargument:

However, the SFC warned that this position taken by GitHub could cause significant harm to Copilot users in the following ways. It therefore took the position that, in order to avoid infringing on someone else’s copyright, it is best not to use Copilot.

The SFC further argued that Microsoft and GitHub must prove why training on copylefted code qualifies as “fair use” and that the trained model is not a “work based on GPL’d software.”

2. Background

Let’s return to today’s paper. It explains copyright law and contract law as they relate to datasets.

In the end, the paper emphasizes that, for companies developing AI services using publicly available datasets (except in cases that can be judged as fair use), a rigorous approach to confirming the rights and obligations tied to the dataset and ensuring license compliance is important in order to prevent copyright infringement, breach of contract law, and the like.

However, as I will mention again later, checking the license of every dataset, data source, and even individual data point involved in using a publicly available dataset, and complying with each obligation, is close to impossible in practice. Personally, I think a realistic approach is to accept a certain amount of license risk in order to use a publicly available dataset, or to build a legal basis on which fair use can be argued.

Now let’s look at what rigorous approach the paper proposes for using publicly available datasets in commercial AI services.

3. Approach

The paper emphasizes that an AI engineer who wants to use a publicly available dataset must identify the applicable license, and a lawyer must analyze the rights and obligations of that license to determine whether it can be applied to a commercial AI service.

First, Phase 1 is the process in which the AI engineer confirms the license. The paper explains the details as follows.

That covers Phase 1, and there is quite a lot for an AI engineer who wants to use a publicly available dataset to confirm. A bigger problem is that no matter how much effort is put in, if a website provides no license information or provides incorrect information, the scope of what the AI engineer can confirm will inevitably be limited. In any case, let’s look further into the paper. Next is Phase 2, the stage in which a lawyer or other legal professional confirms the rights and obligations of the license.

Going through Phase 2, we’ve looked at how a legal professional documents license rights and obligations in the Enhanced MDL format and how this is used. The paper explains that checking not just the dataset’s license but also the licenses of its data sources matters, because if a data source’s license restricts commercial use, using the dataset commercially carries risk as well.

Using this same approach, the paper conducted case studies on other datasets as well. Let’s look at what it found.

4. Case Study Details

All six of these datasets are image datasets, and their licenses have the following characteristics.

Now let’s look at the results of the paper’s research on these six datasets.

Even just from the results described above, using a publicly available dataset in a commercial AI service carries the potential to cause a license compliance violation. Moreover, the paper further explains that there are additional aspects this study did not consider.

5. THREATS TO VALIDITY

Considering, as described above, both the difficulty of confirming the license of individual data points and the difficulty of confirming a license from inaccurate information, I think it may be fair to conclude that using a publicly available dataset in a commercial AI service without any license risk is genuinely close to impossible. That said, publicly available datasets cannot be excluded entirely from AI product research either. Just as GitHub is preparing the Copilot service despite the copyright infringement issues — accepting a certain degree of legal risk and, where necessary, continuing to fight it out in court — it seems worth considering that a company should be willing to bear some degree of potential copyright infringement risk in order to make use of AI technology. In fact, there is also a view that using a dataset solely for machine learning training does not constitute copyright infringement.

• Under Article 35-2 of the Copyright Act, temporary reproduction of a work on a computer is permitted. Based on this, there is room to argue that temporarily copying a publicly available dataset into memory during machine learning training is likewise permitted.
• Article 35-3 of the Copyright Act permits the use of a work as fair use when the use does not conflict with the work’s normal exploitation and does not unreasonably prejudice the legitimate interests of the author. Using a publicly available dataset made up of image data solely for machine learning training does not conflict with the normal way pictures or photographs are exploited and does not harm the author’s interests, so it could be argued that this qualifies as fair use.

That said, since there is still no clear case law on this point, it cannot be said that there is no risk at all. (And by the way, I am not a lawyer, so please note that none of this carries any legal effect. ^^)

Overseas, countries such as those in Europe, Japan, and the United States have amended their laws to allow the use of big data for AI training, and I understand that a bill to amend the Copyright Act for this purpose has also been introduced in Korea’s National Assembly. I hope the government moves quickly to pass the necessary legislation so that domestic companies can use publicly available datasets more easily and accelerate innovation in AI technology.

Thank you.

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.

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.”²³

Torvalds’s view on GPLv3’s ‘Installation Information’ requirement was shared by several major kernel developers, 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. ^^

This paper was translated by Haksung Jang from the English version available at the Distribution of Dockerfiles. The original document is licensed under CC-BY-4.0. The original author, Till Jaeger, has not reviewed 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.

“The right of distribution is the right to offer the original or copies of the work to the public or to put it into circulation."

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⁶:

BGH, judgment of 2020-03-05

“In this context, the decisive factor is whether the manufacturer is limited to ’taking the place of the reproduction device’ and acting as a ’necessary tool’ of the other party - in which case the reproduction is to be attributed to the purchaser - or whether he opens up a copyright-relevant use to an extent and intensity that cannot be reconciled with the considerations that justify the privileges of private use - then the reproduction is to be attributed to the manufacturer. Within the framework of this examination, which is based on normative standards, it must also be determined whether the client has organizational sovereignty over the recording process."

For more details on the internet radio music recording service, see the Korea Copyright Commission’s 2019 material, “A German district court rules that a provider of internet radio music recording (stream ripping) services infringes the reproduction right and the right of communication to the public.”

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⁷.

CJEU of 2015-05-13

“Taking that context into account, the Court specifically found that distribution to the public is characterised by a series of acts going, at the very least, from the conclusion of a contract of sale to the performance thereof by delivery to a member of the public. A trader in such circumstances bears responsibility for any act carried out by him or on his behalf giving rise to a distribution to the public in a Member State where the goods distributed are protected by copyright. … As regards an invitation to submit an offer, or a non-binding advertisement for a protected object, those also fall under the series of acts taken with the objective of making a sale of that object. … In the light of the foregoing considerations, the answer to the questions referred is that Article 4(1) of Directive 2001/29 must be interpreted as meaning that it allows a holder of an exclusive right to distribute a protected work to prevent an offer for sale or a targeted advertisement of the original or a copy of that work, even if it is not established that that advertisement gave rise to the purchase of the protected work by an EU buyer, in so far as that that advertisement invites consumers of the Member State in which that work is protected by copyright to purchase it."

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.

About the author

Till Jaeger has been a partner at JBB Rechtsanwälte since 2001 (www.jbb.de). He is a Certified Copyright and Media Law Attorney and advises large and medium-sized IT businesses as well as government authorities and software developers on matters involving contracts, licensing and IP rights.

One particular focus of Till Jaeger’s work is on the legal issues created by free and open source software (FOSS). He is co-founder of the Institute for Legal Aspects of Free & Open Source Software, ifrOSS (www.ifross.org), contributing to its work with academic publications, lectures and seminars in the fields of software law and copyright law.

Till Jaeger is a lecturer at the Humboldt University Berlin in the subjects of IT law and IP law and general counsel of Open Source Automation Development Lab (OSADL) eG.

He represented the gpl-violations.org project in several lawsuits to enforce the GPL and has published articles and books related to legal questions of Free and Open Source Software (among them Jaeger/Metzger, Open Source Software - Rechtliche Rahmenbedingungen der Freien Software, 5th ed. Munich 2020, and Van den Brande/Coughlan/Jaeger - The International FOSS Law Book, 2nd ed. Munich 2014). He was member of the Committee C in the GPLv3 drafting process.

Licence and Attribution

This paper was published in the Journal of Open Law, Technology, & Society, Volume 12, Issue 1 (April 2021). It originally appeared online at http://www.jolts.world

This article should be cited as follows:

Jaeger, Till (2021) ‘Distribution of Dockerfiles: Who is responsible for FOSS License Compliance?’, Journal of Open Law, Technology, & Society, 12(1), pp 13 – 20 DOI: 10.5033/jolts.v12i1.147

Copyright © 2021 Till Jaeger

This article is licensed under a Creative Commons Attribution 4.0 CC-BY available at

https://creativecommons.org/licenses/by/4.0/

1: Hemel, Armijn, (2020), ‘Docker Containers for Legal Professionals,’ [pdf] Available at: https://www.linuxfoundation.org/wp-content/uploads/Docker-Containers-for-Legal-Professionals-Whitepaper_042420.pdf [Accessed 16 February 2021]. See also Peterson, Scott, (2020), ‘Making compliance scalable in a container world.’ Available at: https://opensource.com/article/20/7/compliance-containers [Accessed 16 February 2021]. ⏎

2: Sec. 0 GPL-3.0 provides as follows: “To ‘convey’‘ a work means any kind of propagation that enables other parties to make or receive copies.” and “To ’propagate’ a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy.”⏎

3: Meeker, Heather (2012), ‘The Gift that Keeps on Giving – Distribution and Copyleft in Open Source Software Licenses’, JOLTS, 4(1), pp 29 – 40, [DOI: 10.5033/ifosslr.v4i1.66].⏎

4: Directive 2009/24/EC on the legal protection of computer programs (codified version). Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32009L0024 [Accessed 16 February 2021]. ⏎

5: See the ‘Opinion of Advocate General Saugmandsgaard Øe in the joined Cases C‑682/18 and C‑683/18 (Frank Peterson v Google LLC et al), ECLI:EU:C:2020:586. Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:62018CC0682 [Accessed 16 February 2021].⏎

6: BGH (German Federal Court of Justice), judgment of 2020-03-05 - I ZR 32/19 – Internet radio recorder. Available at: https://openjur.de/u/2202077.html [Accessed 16 February 2021].⏎

7: CJEU of 2015-05-13, C-516/13 – Dimensione Direct Sales and Labianca. Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:62013CJ0516&qid=1607613372933&from=EN [Accessed 16 February 2021]. ⏎

8: Please not that the “Right of communication to the public of works and right of making available to the public” in Art. 3 are independent rights from the “distribution right” in Art. 4 Directive 2001/29/EC. Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32001L0029 [Accessed 16 February 2021].⏎

9: See Hemel Armijn, ibid n. 1, p. 19. ⏎

10: As the CJEU, judgment of 14 June 2017 in case C-610/15 – Stichting Brein (The Pirate Bay) itself declares: “In order to determine whether a user is making a ‘communication to the public’ within the meaning of Article 3(1) of Directive 2001/29, it is necessary to take into account several complementary criteria, which are not autonomous and are interdependent. Consequently, those criteria must be applied both individually and in their interaction with one another, since they may, in different situations, be present to widely varying degrees.” Available at: http://curia.europa.eu/juris/liste.jsf?language=en&T,F&num=c-610-15 [Accessed 16 February 2021]. ⏎

11: For efforts of Red Hat to improve the situation see Peterson, S., ibid. ⏎

12: “However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.” ⏎

13: See for more details Jaeger, Till and Metzger, Aaxel, Open Source Software, 5th edition, 2020, 64 et seq; Meeker, Heather, Open Source for Business, A practical Guide to Open Source Software Licensing, 3rd edition 2020, 119 et seq; Working Paper on the legal implication of certain forms of Software Interactions (a.k.a linking), Available at: https://www.ifosslr.org/public/LinkingDocument.odt [Accessed 16 February 2021]. ⏎

14: The definition in section 1 GPL-3.0 reads as follows: ’The “System Libraries’ of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A ‘Major Component’, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.” ⏎

What Is an OSPO?

This paper was translated by Haksung Jang from the English version available at the OSPO Definition. The original document is licensed under CC-BY-SA-4.0.

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
  • Legal Risk Mitigation
  • Improving Engineers’ Practices
  • Enabling Financial Benefits
• OSPO Guides
• OSPO Examples

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

This paper was translated by Haksung Jang from the English version available at this white paper. The original author, Heather Meeker, has not reviewed this translation.

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.

• Unix, Linux, Free Software, and Open Source
• The Advent of the Cloud and AGPL
• AGPL and Dual Licensing
• Strip-mining
• SSPL and Source-Available Licensing
  • SSPL
  • Source-Available Licenses with Restrictions
• Elastic License 2.0
• Why Use Dual Licensing?
• Elastic License 2.0 and Modern Licensing Techniques
• Building a Better License

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

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

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.

1: “Modification of Final Judgment,” August 24, 1982, filed in case 82-0192, United States of America v. Western Electric Company, Incorporated, and American Telephone and Telegraph Company, U.S. District Court for the District of Columbia web.archive.org/web/20060827191354/members.cox.⏎

2: The Free Software Definition is similar to the Open Source Definition, but shorter and clearer.⏎

3: Open source licenses can contain conditions, such as notices or source code sharing. But these are not limitations that tell you what you cannot do with software, they only require that if you elect to do certain things, you also must do others.⏎

How to Write Copyright Statements in Source Code

Hello.

Matija Šuklje, a well-known attorney in the open source field, recently introduced why copyright statements are needed in source code and how to write them correctly.

The post below is based on the original article above. Most of it is translated directly from the original so that the author’s intent is faithfully conveyed.

I started out thinking of this as a simple copyright notice guide for developers, but since there was no unified guide for how to display copyright information, writing the guide wasn’t easy. In the end, I decided to write a new one.

I tried to strike a balance while keeping the following points in mind.

1. For developers who simply want a quick answer for what to do
2. For FOSS compliance staff and lawyers who want to understand not just the best practices but also the reasoning behind them

If you are extremely short on time, check the minimal guide in TL;DR. If you have about 2 minutes, read the actual HowTo a bit lower below.

Of course, if you have about 20 minutes, the best option is to read it from start to finish.

TL;DR

Add a copyright and license statement in the following format to every source code file you write.

SPDX-FileCopyrightText: © {$year_of_file_creation} {$name_of_copyright_holder} <{$contact}>

SPDX-License-Identifier: {$SPDX_license_name}

For example, if I wrote a source code file today and released it under the [BSD-3-Clause license][bsd-3-clause], I would add the following content in the header comment at the top of the file.

SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>

SPDX-License-Identifier: BSD-3-Clause

For reference, following the [REUSE.software][reuse] project’s guide lets you verify that every file has been marked appropriately.

What is Copyright?

Copyright is (following the [Berne Convention][berne]) automatically generated when an author creates a work. Every work is protected by copyright, and the copyright holder is granted exclusive rights over the work. So if you want other users to be able to use your work (source code, text, images, other media, etc.), you must grant them a license. The dictionary definition of a license is “permission granted by a competent authority to exercise a certain right,” and exercising that right without such permission constitutes an unlawful act such as copyright infringement.

Likewise, if you want to copy, modify, or otherwise work with someone else’s source code, you must be granted the necessary permission. In other words, you must obtain a license. And if that license imposes certain obligations as a condition for granting permission to exercise the right, you must also comply with those obligations in order to exercise the right.

In any case, you must comply with the basic requirements of copyright law, and at minimum this requires the following two things.

• Attribution: Identify the copyright holder and/or author. (Especially in jurisdictions that recognize moral rights)

• License: Since a license is the only way to grant someone other than the copyright holder permission to use the code, it’s good practice to state the license and provide the full license text. This applies both to the Outbound license you grant to others and the Inbound license you receive from others (when using third-party works such as copied code or libraries).

Inbound vs. Outbound Licenses

The license you grant to your users (downstream) is called the Outbound license, because it governs the rights of code flowing out (out) from you. Conversely, from the perspective of users of that same code, it is considered the Inbound license, because it governs the rights of code flowing in (in) to them. Simply put, a license that describes incoming rights is called an Inbound license, and a license that describes outgoing rights is called an Outbound license. The good news is that attribution is a right of the author, not an obligation. Also, users are only obligated to preserve attribution if the author has exercised their right of attribution. In other words, if the author did not provide attribution, users don’t need to go out of their way to add it themselves.

Why Should You Add a Copyright Statement?

Before the United States joined the Berne Convention in 1989, U.S. copyright law required an explicit copyright notice in order for a work to be protected. However, under the Berne Convention, copyright is generated automatically even without a copyright statement. Even so, copyright statements are still useful.

While a copyright statement is not legally required, in practice it is extremely useful as evidence of who holds the copyright in a given work. It is also of great help for compliance purposes and for tracking code.

A copyright statement is practically necessary for the following reasons.

1. Most licenses require a copyright statement.
2. Even where a license does not require it, the copyright law of most jurisdictions does.
3. (Even without such a requirement) a user may want to contact the original author for legal or technical reasons.

Therefore, it makes sense to include the author’s name and contact information in a work.

The Correct Way to Write a Copyright Statement and License Notice

Copyright Statement

A good copyright statement should consist of the following information.

• ​the © symbol​

• Year: the year the source code file was first written. Once written, do not modify it further.

• Copyright holder name: usually the author, but it may be the author’s employer. It could also be a different legal entity or individual under a CLA.

• a valid contact: information for contacting the copyright holder

For example, if you wrote a source code file today, you would add a copyright statement like the following in the header at the top of the file.

© 2020 Matija Šuklje <matija@suklje.name>

License Notice

It’s also very important to state the license under which the code is released. Using an SPDX ID lets you clearly identify the license of the code. If the license notice isn’t clear, it can cause confusion for the users who see it.

REUSE.software

The REUSE.software project provides a best practice for writing copyright statements and license notices using SPDX tags.

• Copyright statement tag: SPDX-FileCopyrightText

• License notice tag: SPDX-License-Identifier

The example below is a copyright statement and license notice that takes all of the above into account and complies with both the SPDX and REUSE.software requirements.

SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>

SPDX-License-Identifier: BSD-3-Clause

Now check that every source code file you have written includes this comment!

FAQ

Why should the year be included?

Some people argue that omitting the year and keeping things simple would actually make copyright statements easier to maintain. In fact, this is also the policy of Microsoft and GitHub.

I agree that omitting the year greatly simplifies the task, but keeping it helps clarify an otherwise ambiguous timeline in the codebase. It can also be useful for determining when an invention was first disclosed to the public, which can be particularly useful for patent defense.

Taking these considerations into account, Liferay’s new policy is to record the year the file was created and not change the year afterward.

Why shouldn’t you keep changing the year?

You’ve probably seen copyright statements like this:

Copyright (C) 1992, 1995, 2000, 2001, 2003 CompanyX Inc.

This practice of continually adding years is widespread, based on the idea that it extends the period of copyright protection. Unfortunately, though, this practice is useless and can even be harmful.

Moreover, adding a year every time a new change or contribution is received is legally questionable when you think it through. The issue is that not every contribution is original or substantial enough to give rise to a copyright claim. So, to avoid this problem, you would first need to determine whether each contribution is original enough to be protected by copyright under the law, and only then add a year to the copyright statement accordingly.

On the other hand, copyright lasts for at least 50 years (usually 70 years) after the death of the author (or, if the copyright holder is a legal entity, after publication). So the risk of losing the ability to claim copyright due to the expiration of the protection period, simply because you didn’t keep adding years to the copyright statement, is very low.

Furthermore, a single source code file is generally just one of many files that make up a piece of software. As the software grows, new files will be added, and when a new creation year is added to each new file, the copyright statement for the software as a whole, as a work, already ends up including the latest year.

Don’t pollute your Git/VCS history

If you add a new year statement to every file every year, this unnecessarily lengthens the Git/VCS history, consumes repository space, and can get in the way when you’re looking for genuinely important information.

What about expressing the year as a range?

Expressing the year as a range (e.g., 1999-2020) is subject to all the same considerations mentioned in the question above, because it also needs to be updated every year.

In some cases, a range is specified in a form like ‘{$year}-present’. This too is largely subject to the points mentioned above, and it can add further confusion. What ‘present’ means is abstract. What does ‘present’ refer to?

• The time the file was last modified?

• The time the package was released?

• The time it was first downloaded?

• The time it was last run?

• Or right now, this very moment?

As you can see, ‘present’ isn’t a helpful marker at all.

Isn’t Git/Mercurial better for tracking copyright information?

Not always. Git (and other VCSs) is excellent at managing metadata, but you should be cautious about relying on it entirely.

First, Git has an ‘Author’ field separate from the ‘Committer’ field. Not only does each contributor put different kinds of values into the ‘Author’ field, but even if you assume the person entered in the ‘Author’ field is actually the author, that author may not be the copyright holder.

More importantly, when a file is moved out of a repository, its metadata disappears. If you only distribute compressed source code, or copy each file into a new codebase by forking or rebasing a repository, the tracking data up to that point is no longer available.

These issues are resolved by including copyright and license information directly in every file. The REUSE.software best practice handles this very well.

Why use the © symbol?

Someone might argue that the English word “Copyright” is used more often and that many people are already familiar with it, but if you actually look at copyright law, you’ll find that using “©” (the Copyright Sign) is not the only way to make a copyright statement.

As one example from the EU, Article 175(1) of Slovenia’s ZASP states that an exclusive copyright holder may mark their work with “(c)” or “©”. Meanwhile, in the United States, 17 U.S. Code § 401(b)(1) specifies the way to mark a work as follows: “the symbol © (the letter C in a circle), or the word “Copyright”, or the abbreviation “Copr.””

Also, using © is reasonable because it is the “common global denominator.”

Whether or not people like the © symbol may be a matter of taste, but from a practical standpoint it isn’t actually all that important. As explained above, since copyright is generated automatically, the symbol you use doesn’t change the legal risk.

Why should you leave a contact address? What if there are two or more authors?

Contact information isn’t required by copyright law, but it’s very useful for practical reasons.

A user may want to contact the code’s author or copyright holder for legal or technical questions. They may want to ask how the code works or request a modification. They might discover a license issue and want to help resolve it, or need to request a separate license. Contact information is a great help in all of these cases.

• Since email is still a commonly used contact method today, providing the copyright holder’s email address is the best option.

• In cases where copyright is highly distributed or held by a legal entity, it may make more sense to provide the URL of the project’s or the entity’s homepage.

• If a project lists copyright holders in a file such as AUTHORS or CONTRIBUTORS, providing a link to that file is also a good option.

What is Public Domain?

Public Domain generally refers to a work whose copyright term has expired, but it’s a tricky concept that requires care.

In some jurisdictions (e.g., the United States, the United Kingdom), a copyright holder can waive their copyright and donate the work to the public domain, but in most jurisdictions (e.g., most EU member states) this isn’t possible. This means that, depending on the jurisdiction, even if an author states that they are dedicating their work to the public domain, that statement may fail to meet the legal requirements to actually be effective, and the copyright in the work may still remain solely with the copyright holder.

For this reason, open source compliance professionals who take copyright and licensing seriously are very wary of a “this is public domain” label.

Copyright holders can mitigate this problem in the following two ways.

• If you want to waive your copyright in your own work and dedicate it, use a very permissive license such as CC0-1.0 instead of the phrase “public domain.”

• Leave your name and contact information in the “SPDX-FileCopyrightText:” field. This lets a user who is curious about the copyright holder’s intent, or who runs into any ambiguity, reach out to resolve the issue.

How should copyright be handled in minified JavaScript?

Modern minifiers offer an option to preserve copyright and license information even while removing comments. Use this option when minifying code to keep the copyright and license information intact.

Even if source code is converted into another language, or compiled, or transformed into another form, the copyright holder retains exclusive rights over all of it. So even when using minified code, you still need a valid license.

What’s the problem with an “All rights reserved” statement?

You’ve probably seen the phrase “All rights reserved” in copyright statements before. Copyright law doesn’t require this expression. I suspect it’s simply copied from something people saw used on a music CD or in a book. But in open source, this expression causes confusion.

“All rights reserved” clearly contradicts an open source license. An open source license grants everyone the right to use, study, share, and improve the code. “All rights reserved,” on the other hand, states that all of these rights are granted solely to the copyright holder.

“All rights reserved” only brings problems like this, without offering any benefit, so it should not be used in open source.

OSS Supply Chain Security

Hello.

In February 2020, the Linux Foundation published an article about security risks in the Open Source Software Supply Chain, and this post summarizes that content.

Introduction

Modern software development has become a far more complex process than it was in past decades. It is rare for an organization to develop all of its software in-house. Instead, most organizations make use of Open Source Software (OSS). They build products by incorporating a variety of OSS and developing only the connecting pieces in-house.

The “Software Supply Chain” is already highly complex. Whereas software used to be delivered to customers on physical media such as CDs, today’s software (both OSS and proprietary software alike) is stored in “repositories” and distributed remotely on demand through a Project Dependency Manager (PDM) or Package Manager.

Most of the recent attention paid to security in the software supply chain has focused on the Developer, the first link in the chain, or the End User, the last link, but vulnerabilities exist at every level. Consider the following incidents.

Xcode Repackaging for Malware Distribution in 2015

In 2015, a security firm warned Apple that 39 applications distributed through the App Store were infecting iPhones and iPads. The malicious applications downloaded to devices connected to a remote command-and-control server and uploaded sensitive user information. Further investigation revealed that the malicious code had been inserted into the applications through a “repackaged” version of Xcode, Apple’s official development platform.

These apps were immediately removed, and Apple took additional measures to ensure that only legitimate developers could access the official version of Xcode, but the incident highlighted the risk that a software security vulnerability within the software supply chain can affect multiple applications.

Apple scrambles after 40 malicious “XcodeGhost” apps haunt App Store, Dan Goodin, ArsTechnica (Sep. 25, 2015), https://arstechnica.com/information-technology/2015/09/apple-scrambles-after-40-malicious-xcodeghost-apps-haunt-app-store/

The “left-pad” Dependency Incident of 2016

In 2016, following a naming-rights dispute over an unrelated OSS package, a well-known developer removed all of his OSS packages from npm, the software registry used to distribute Node.js code. The developer removed a total of 273 packages from npm, but the problem showed up in just one of them: “left-pad.”

“left-pad,” an incredibly simple package, right-aligns text to produce more readable text output. However, because a large number of important downstream packages depended on “left-pad,” its sudden disappearance broke countless downstream packages. Another developer replaced the missing package with a functionally equivalent one, but downstream developers were still left with the task of updating their code to reference the new package.

This incident starkly highlighted the risk developers face when depending on upstream packages over which they have little control, and it exposed a broader “dependency” problem: because the package was embedded as an upstream dependency, even developers who had no intention of depending on “left-pad” were affected.

The “left-pad” incident occurred three years ago, but problems like this remain.

Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet”, Sean Gallagher, ArsTechnica (March 24, 2016), https://arstechnica.com/information-technology/2016/03/rage-quit-coder-unpublished-17-lines-of-javascript-and-broke-the-internet/ .

Python Package (PyPI) Hijacking in 2017

In 2017, attackers created malicious libraries whose names were made to look “very similar” to those of built-in Python libraries. Unsuspecting developers downloaded these malicious libraries. The malicious packages contained the same code as the originals, but their installation scripts had been modified to include malicious code.

Goodin, Dan. 2017-09-16. “Devs unknowingly use “malicious” modules snuck into official Python repository: Code packages available in PyPI contained modified installation scripts.” Ars Technica. https://arstechnica.com/information-technology/2017/09/devs-unknowingly-use-malicious-modules-put-into-official-python-repository/

Python Package Hijacking in 2018

In 2018, a cryptocurrency-stealing package called “Colourama” was discovered in the Python Software Repository. Its name was deliberately made to resemble “Colorama,” a legitimate package that ranked among the 20 most-downloaded software packages in the Python repository, in order to cause confusion. Although the malicious package had been downloaded only 151 times by the time it was discovered, removing the infection from affected devices required considerable effort, which highlighted the security vulnerability of software repositories.

Two new supply-chain attacks come to light in less than a week, Dan Goodin, ArsTechnica (October, 23, 2018), https://arstechnica.com/information-technology/2018/10/two-new-supply-chain-attacks-come-to-light-in-less-than-a-week/.

Backdoor in the “event-stream” Library in 2018

In 2018, one of the most widely used JavaScript libraries had cryptocurrency-stealing code inserted into it as a backdoor. Notably, this insertion was far more sophisticated than similar incidents (by the time the backdoor was discovered, the library had recorded 2 million downloads).

First, the malicious actors behind the backdoor gained legitimate publishing rights to the event-stream package by offering to help the developer. Once they had obtained those rights, they used them to add a benign package, flatmap-stream, to the npm registry and added it as a dependency of event-stream itself. About a month later, the malicious actors added malicious code to flatmap-stream that targeted popular cryptocurrency wallet software (and was thereby added to event-stream as well).

This staged attack, together with the effort the attackers invested in gaining publishing rights to the event-stream package, shows not only that there are weaknesses in how new code and new developers are vetted, but also that malicious actors are willing to make that kind of effort. This suggests that similar attacks are likely to continue, and to increase in both frequency and sophistication.

Widely used open source software contained bitcoin-stealing backdoor, Dan Goodin, ArsTechnica (November 26, 2018), https://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open-source-software-to-steal-bitcoin/

Account Takeover of a Popular RubyGems Package in July 2019

In July 2019, a developer updating a codebase noticed that one of its dependencies was missing a changelog.md file. The affected package, strong_password, had been updated from 0.0.6 to 0.0.7 with no explanation of the changes, and with a discrepancy between the code hosted on GitHub and the code hosted in the Ruby repository. Through further investigation, the developer discovered that the package had been updated to reach out to a remote URL and pull in additional code when it ran in a production environment. Once that happened, the new code created an opportunity for remote code execution within the infected environment.

The developer notified the package’s original maintainer, who discovered that his Ruby repository account had been compromised. The malicious actor had taken over the maintainer’s account, changed the package’s ownership, and then published the backdoored code. Although it could not be confirmed, the original maintainer believed that the absence of two-factor or multi-factor authentication (2FA or MFA) was what allowed the malicious actor to access his developer account. Because a dependency such as strong_password is deployed in a wide variety of environments and is tied to a well-known developer with an established reputation for trustworthiness, taking over that developer’s account is highly valuable. Attacks like this will only increase.

strong_password v0.0.7 rubygem hijacked, Tute Costa (July 3, 2019), https://withatwist.dev/strong-password-rubygem-hijacked.html

The Webmin Compromise of 2018-2019

Beginning in April 2018 and discovered in August 2019, an unknown malicious actor used a backdoor in the popular Webmin administration tool. The change was relatively small but could have significant impact. A malicious actor using the backdoor could send commands to an infected server through a specially crafted URL, allowing commands to be executed with root privileges.

According to the Webmin developers, the server containing the Webmin source code was compromised in April 2018 and malicious code was inserted into it. At the time, the attacker altered the relevant server logs to make it appear that the files had not been updated for some time, hiding the change from common detection mechanisms such as code comparison tools. The altered code went undetected, and additional malicious activity continued, until August 17, 2019, when it was discovered externally that the backdoor had been disclosed as part of a zero-day attack.

The Webmin maintainer removed the infection and took additional steps, but the incident became yet another example showing the vulnerability of such software and its continuing appeal to malicious actors.

The year-long rash of supply chain attacks against open source is getting worse, Dan Goodin, Ars Technica (August 21, 2019) https://arstechnica.com/information-technology/2019/08/the-year-long-rash-of-supply-chain-attacks-against-open-source-is-gettingworse/; Webmin page explaining exploit, Webmin, http://www.webmin.com/exploit.html.

Discovery of 11 Backdoored RubyGems Libraries in August 2019

In August 2019, an analysis by a developer investigating Ruby libraries uncovered 11 backdoored packages. In each case, the backdoor allowed malicious actors holding preselected credentials to remotely execute code on infected servers.

The infected packages also enabled cryptocurrency mining. It is not clear how each library became infected, but for at least one package, the code could be modified because the developer’s account had been compromised. That account had been using a previously cracked password and was not protected by 2FA or MFA.

These incidents reveal weaknesses inherent in the current policies, processes, and procedures used by package managers and repositories. Making matters worse, because these elements of the supply chain are indispensable to modern software development, organizations are required to use them in nearly every case, and are therefore exposed to a high level of risk they cannot control.

Finally, there is one more element that stands apart from the software supply chain but is nonetheless indispensable: the “Vulnerability Database.”

Given the distributed and overwhelmingly complex nature of modern software development, identifying, analyzing, remediating, and tracking vulnerabilities found in deployed software is critically important. However, the National Vulnerability Database (NVD), provided by the CVE (Common Vulnerabilities and Exposures) program and the most heavily relied-upon vulnerability tracking database in the world, continues to struggle under the growth, speed, and complexity of modern software development. These difficulties directly affect the developers and companies that depend on the CVE and NVD programs, and affect the security and stability of the software supply chain as a whole. This section examines the security and stability issues currently affecting the software supply chain and introduces areas and ways in which things can be changed to improve it overall.

Examining the Software Supply Chain

Developer Practices

In the diagram introduced earlier, the developer is shown as the first link in the software supply chain. That is true in a sense, but developers are actually present everywhere, at every stage. Developers choose the programming language, the repository, and the PDM. They choose the libraries, packages, and OSS that make up the finished product a company’s customers will purchase. In other words, developers are the single most indispensable member of the software supply chain.

However, many developers do not follow security best practices when developing software. There are several reasons for this. One is that modern software development is an enormously complex process. This means that a “best practice” strategy for one person may turn out to be a critical weakness for another. Another reason is that security is often seen as something that gets in the way of the developer and user experience. As a result, many developers avoid or minimize the use of proper security practices.

Ignoring or being reluctant to adopt security practices in this way leads to a range of consequences, many of which were highlighted in the supply chain incidents described above. Many of these incidents could have been avoided if developers had used the following security practices.

• Using two-factor or multi-factor (2FA or MFA) authentication for developer accounts and other critical accounts involved in the design, construction, and maintenance of a given project
• Requiring that the project support change control tracking (including who made a change and when) throughout the development process
• Ensuring that the project has a unique version identifier for each release, so that downstream users can track new releases and build mechanisms to control and verify them
• Integrating testing into the project’s development lifecycle to check not only for common bugs and unexpected behavior, but also for malicious changes made without the developer’s knowledge
• Using tools or other mechanisms that ensure the project’s dependencies are documented and communicated so downstream users can easily consume them
• Using tools that properly track, analyze, and manage dependencies
• Presenting cryptographic signing or other demonstrable evidence of the project’s integrity
• Tracking and remediating vulnerabilities in both newly developed code and OSS dependencies incorporated into the project

Many developers fail to observe these practices. This may be due to a lack of the necessary resources, expertise, or support. What is clear, however, is that failing to follow these best practices carries serious consequences not only for developers but also for the end users of the software.

Repository

In the past, much software development relied on code licensed from partners or vendors, but today most development incorporates large volumes of OSS retrieved freely and without restriction from the internet. Many developers depend on software repositories, known as “repositories,” to build their software.

At its core, a software repository is a server that holds a set of software packages. These packages range from small utility libraries to full command line tools and development frameworks. Linux systems typically use an operating system repository to manage applications and their dependencies for a given Linux distribution. The developers of that distribution manage all packages within the repository’s collection, keeping packages current based on upstream software package releases and, when necessary, fixing reported security and other bugs in those packages.

Beginning with Perl and continuing as interpreted programming languages grew, it became advantageous to provide users with an expanded repository of “helper” libraries. Because of the size of these repositories, they were generally excluded from the main packaging of individual Linux distributions. As these language-specific repositories grew, developers working in that language came to rely on the language repository’s tooling to install required dependencies, not only during development but also whenever they needed to run the development software on a non-development system.

Today, a significant portion of software development depends on OSS, and because much of the most widely depended-upon OSS in the world is written in languages that rely on a language repository for their libraries, developers must pull portions of their software from these repositories. However, for a variety of historical and economic reasons, these language repositories lack even basic security or quality controls. For example:

• Few language repositories provide a mechanism to check that the code they store is what it purports to be, which increases consumer confusion and, in some cases, enables malicious activity.
• Few language repositories systematically check the stored code or deprecated packages for vulnerabilities.
• No language repository currently provides a mechanism for consumers to check whether one piece of stored code was derived from another, which limits their ability to determine whether a vulnerability or other problem carries over from a dependency.
• In most language repositories, weak or missing authentication and publisher verification mechanisms create uncertainty and risk regarding the origin of stored code.
• Some language repositories do not offer two-factor or multi-factor (2FA or MFA) authentication for developer accounts, and often neither require nor encourage it, signaling to others that developer accounts (and the packages they control) are weakly protected.
• Many language repositories offer code signing, but few provide or enable a robust mechanism for verifying the validity of those signatures.
• Some language repositories include an End User License Agreement (EULA) that restricts conscientious consumers from performing their own security and quality analysis of the stored code.
• Many language repositories do not verify that a generated package was produced from the expected, publicly available source that others could inspect, nor do they make it easy for other users to check this themselves.

Some language repositories have taken steps to address these concerns, but none has developed a mechanism that solves every problem. Moreover, some of the language repositories that have attempted to address these concerns have “commercialized” the repository itself, offering these capabilities only to customers who pay for a “premium” service. As a result, the security and quality controls that should be provided as a baseline remain out of reach for many everyday consumers.

Project Dependency Manager (“Package Manager”)

Managing large-scale software efficiently today requires tools that are both simple and powerful. Many such tools exist, but the most widely adopted of them is the “package manager.” A package manager automates the process of installing, upgrading, configuring, and removing files such as software packages and libraries on a given system. In particular, package managers known as “project/application dependency managers” (PDM) are frequently used.

By using a PDM, users can collapse the many complex steps once required to find, install, and configure software into a single step. A PDM connects to a language repository, as described above, to search for and configure the software a user specifies, including any software it indirectly depends on. By simplifying software discovery and management in this way, PDMs have greatly reduced the level of expertise and resources required for modern software development.

However, a PDM is nothing more than a software discovery tool. It does not check the software it retrieves for the following, and it has no actionable way to fix them.

• Whether the software has known security or reliability issues
• Whether it contains unexpected or malicious behavior
• Whether it has a misleading package name (“typosquatting” and/or a name resembling that of a built-in library)

Vaidya et al, “Security Issues in Language-based Software Ecosystems, March 6, 2019, https://arxiv.org/abs/1903.02613

Instead, as discussed above, these practices are generally expected to be carried out elsewhere in the software supply chain, but that is generally not the case. As a result, the efforts of PDM users and PDM maintainers to ensure some level of security and quality are undermined within the retrieved software itself. This is a problem in particular because, as can be seen from the increasing frequency of security incidents involving PDMs, the weaknesses inherent in current PDM procedures have become a popular vector for malicious actors.

Vulnerability Database

As discussed above, modern software is composed of many software packages assembled together. These “building block” packages may be proprietary code, licensed code, or OSS, and a product may be composed of anywhere from dozens to thousands of these blocks. This provides significant benefits, but it also introduces risk. Today, developers and companies must manage not only the bugs and vulnerabilities in their own code, but also those in each of the software packages their product depends on.

Just as modern software development has outpaced in-house development strategies, the number, variety, and uniqueness of vulnerabilities and bugs found in modern software make it impossible to keep up through in-house vulnerability tracking alone. This was a reality the software community recognized early on, and it led to the creation of the CVE (Common Vulnerability and Exposure) program and the NVD (National Vulnerability Database) program, standardized U.S.-based programs for assigning, describing, and tracking vulnerabilities and bugs.

These two programs have existed for more than 20 years and have become the foundation for many modern cybersecurity tools, products, and practices.

The NVD is considered so important that in 2018 it was exempted from the U.S. government shutdown. See “Closed Down: Government Shutdown Impacts Enterprise Security, December 31, 2018, https://duo.com/decipher/government-shutdown-impacts-enterprise-security

However, in recent years both programs have struggled as the astonishing growth of new technologies has driven a sharp increase in requests for additions to the NVD. These difficulties have given rise to a number of downstream problems, including the following.

• Vulnerabilities being missed or rejected, resulting in incomplete NVD coverage (Over 6,000 vulnerabilities went unassigned by MITRE’s CVE project in 2015, Steve Ragan, CSO Online (Sep. 22, 2016), https://www.csoonline.com/article/3122460/over-6000-vulnerabilities-went-unassigned-by-mitres-cve-project-in-2015.html.)
• Severe delays in assigning vulnerability identifiers, exposing unaware downstream parties to risk
• Insufficient descriptions of vulnerabilities, making remediation and management more difficult
• Vulnerability scores that are inflated or understated, leading to misallocated resources and, in some cases, “vulnerability fatigue”
• Abuse by developers who inflate their vulnerability counts to pad their resumes
• Difficulty rescinding a vulnerability once it is assigned and later found to be invalid, causing confusion and a lack of trust in the program as a whole
• Abuse by engineers at organizations who treat a CVE assignment as a way to bypass a difficult administrative process that would otherwise prevent a routine software upgrade
• Discomfort with the fact that the CVE program itself is administered by a U.S. federal agency
• An inability to handle persistent, complex vulnerabilities that require multiple packages to be fixed multiple times over an extended period

As a result, many stakeholders who rely on the CVE and NVD programs, including nearly every modern company, federal agency, and other organization, are not fully resolving their vulnerability exposure. Worse still, a lack of NVD coverage that produces few alerts can create a false sense of security, leading stakeholders to believe their products are safe and trustworthy when they are not.

End User Practices

Given their position at the very end of the software supply chain, end users would seem to have the least control over security.

However, the picture changes if you think of the supply chain as a loop.

End users will typically use a technology vendor’s solution, and in that case, they cannot make decisions about the choice of PDM or OSS packages. However, end users do control “acquisition requirements” (although many users do not make full use of this leverage).

The best practice here is for end users to add the following requirements to the contract when negotiating with a technology provider.

• A dependency list, Software BOM (bill of materials), or a similar component tracking mechanism is provided in a highly robust and transparent manner.
• Vulnerabilities within the product must be remediated within a specified period.
• All developer accounts involved in development must use 2FA or MFA.

In some cases, end users themselves carry out the same practices discussed under developer practices for the OSS packages within their own solutions. In addition to these practices and “acquisition requirement” practices, there are also practical steps end users can take on their own: checking the trustworthiness of software, downloading software only from trusted sources, and verifying that the software they received is the software they requested. They can also limit the permissions granted to software in order to reduce the impact of supply chain problems.

Even so, the following facts remain.

• There is no agreed-upon understanding of what it actually means for software to be “trustworthy,” and no effective tools exist, making it difficult to determine whether a given piece of software can be trusted.
• Similarly, it is difficult to determine whether a download location, such as the repositories discussed above, can be trusted.
• Users often find it difficult to verify whether the software they requested is the package they trust, or whether it is malicious, fraudulent, or incorrect.
• Likewise, users are unable to confirm that the software they received is the software they wanted, for example by checking a digital signature. And some users run the code the moment they receive the software, without any check of its security, quality, or otherwise.

End users occupy both the best and worst position to influence the software supply chain. Companies that acquire technology from a vendor can use acquisition practices to encourage the vendor to apply security best practices, but they still face difficulty correcting, or even discovering, defects in the products they receive. For end users who wish to manage their own software themselves, they must recognize that doing so essentially requires them to become developers and to act accordingly. In either case, end users need to understand that as modern software development continues to change, their own behavior must change along with it.

Conclusion

Modern software development relies on a “supply chain” that is distributed on a massive scale. This ever-increasing trend has reduced the average time to market for products and created substantial value, but it has also created risk and opportunities for abuse.

Software repositories, package managers, and vulnerability databases are all necessary components of the software supply chain, just as the developers and end users who make use of them are. However, unless the vulnerabilities currently inherent in these components are resolved, the companies and developers that depend on them will continue to face significant risk. This article was written to highlight known problems within the software supply chain and to spur action to address them. The Linux Foundation will convene a meeting of global technology leaders to design a comprehensive solution to these problems.

2019 FOSS Legal Issue Top 10

Hello.

Mark Radcliffe, an IP attorney at DLA Piper, recently contributed an article titled “Top 10 FOSS legal developments in 2019.” Expecting it to be useful to those interested in Open Source Compliance, I have summarized it to the extent I understand it. (Since I am not a lawyer, there may be shortcomings in the legal terminology or interpretation. I would appreciate it if you let me know of anything that needs correcting.)

1. McHardy (Linux system copyright troll, Germany) adopts a new strategy

Patrick McHardy, an early contributor to the Linux kernel, has engaged in activity in Germany resembling that of a copyright troll seeking financial gain through litigation as a weapon. He has been active for seven and a half years and is reported to have approached more than 80 companies, but since many companies settled rather than going to trial and German court proceedings are kept confidential, it is difficult to estimate exact figures. In the Geniatech case, which McHardy filed in 2017, the appellate court judge in 2018 responded skeptically to McHardy’s copyright claims alleging GPLv2 violations, and McHardy ultimately withdrew the suit.

Since then, McHardy has not been generating further lawsuits, but he continues to make claims of GPLv2 compliance violations. Whereas he previously extracted financial gain by first signing a light contractual penalty and then, after discovering additional violations, enforcing a heavier penalty, since early 2019 he has shifted to a new strategy of demanding compensation for the time he spent finding violations (demanding excessive engineering costs).

2. Richard Stallman resigns from GNU, MIT, and the Free Software Foundation

Richard Stallman resigned as President and board member of the Free Software Foundation. The Free Software (and Open Source) movement owes a great deal to Richard Stallman’s vision and sustained effort. However, over the past several years he has stirred controversy by voicing various opinions on matters outside the FOSS movement. His statements this year about a victim in the Jeffrey Epstein case led to pressure for him to resign from the Free Software Foundation.

He also resigned from MIT, and the maintainers of the GNU operating system removed him. While acknowledging his contributions, they stated the following: “However, it must be recognized that over the years Stallman’s conduct has undermined the interests of all computer users, a core value of the GNU project. GNU cannot properly carry out its mission when a leader’s conduct diverges from the values we aim to reach.”

It is not yet clear who will take up the leadership role in the Free Software movement going forward.

(Related domestic article: http://www.zdnet.co.kr/view/?no=2019091817351)

3. The trade war reaches OSS

In May 2019, the US Bureau of Industry and Security (BIS) placed Huawei Technologies Co., Ltd. and 68 non-US affiliates on the Entity List. In August 2019, BIS added 46 more non-US Huawei affiliates to the Entity List. Companies cannot export, re-export, or transfer items subject to the Export Administration Regulations (EAR) to Huawei, except in four areas for which BIS issued a temporary license (narrowed to three in August 2019).

Google immediately cut off access to Google Services such as the Google Play Store as well as the Android OS (though some updates continued to be provided under the BIS exception). Huawei had to fall back on using the Android Open Source Project. BIS extended the Temporary General License several times. Huawei announced that it is developing a version that could replace Android and may ship it with its next phone. This suspension of Huawei’s access to Google’s Android OS appears likely to be permanent, raising the possibility that Android will split into two ecosystems, one US-based and one China-based.

4. Ethical restrictions in OSS licenses

There have been repeated attempts to condition OSS use on ethical grounds. This year saw several examples of “Ethical Licenses.” In one case, developer Seth Vargo deleted his open source library project Chef Sugar, making it unavailable to users. He deleted Chef Sugar because it was used as part of a contract with U.S. Immigration and Customs Enforcement (ICE), which he criticized for detaining parents and children separately after illegal entry.

Chef, the provider of Chef Sugar, initially tried to resolve the issue by asserting that it owned the copyright to the Chef Sugar project. Chef’s CEO said Chef would continue to provide services to ICE, but four days later the CEO announced that Chef would not renew its license with ICE and would donate the proceeds of the ICE contract to charities dealing with family separation (families separated because of ICE).

Activist Coraline Ada Ehmke created the Hippocratic License. She says this license “adds ethics to Open Source projects.” The Hippocratic License adds the following clause to the MIT License:

“The software may not be used by anyone for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of other individuals or groups, in violation of the United Nations Universal Declaration of Human Rights.”

OSI promptly stated that the Hippocratic License is not an “open source” license. Unfortunately, this additional clause makes the license very difficult to interpret.

5. FOSS strategies of blockchain projects

Many blockchain projects have been released under FOSS licenses. The blockchain community has made complex and unusual choices regarding infrastructure technology. Algorand, a new blockchain project, released its SDK, example applications, and helper library under the MIT License in 2019. However, the Algorand node software was licensed under AGPLv3. Many companies’ legal or Compliance departments restrict the use of software under AGPLv3 because ensuring compliance is difficult. This may make it harder for companies to adopt the Algorand project.

6. The Oracle v. Google war

The Court of Appeals for the Federal Circuit (CAFC) issued its second decision in Oracle v. Google, ruling that Google’s unauthorized use of 37 packages of Oracle’s Java Application Programming Interface (API) in the Android operating system infringed Oracle’s copyright. In 2014, the CAFC reversed the district court’s first-instance ruling and held that the API was copyrightable, remanding the case to the district court to determine whether the use qualified as Fair Use. In 2016, the district court ruled in Google’s favor on the ground that Google’s use of the API constituted Fair Use, and Oracle appealed. In March 2019, the CAFC once again reversed the district court’s ruling, holding that Google’s use of the API did not, as a matter of law, constitute Fair Use. The Supreme Court granted certiorari (arguments scheduled to begin in March 2020). This case will be a critically important precedent in determining the scope of copyright protection for computer software.

(Related domestic article: https://byline.network/2020/02/11-94/)

7. The German Hellwig/VMware case concludes

In March 2015, Christoph Hellwig, a core Linux kernel developer, sued VMware in the Hamburg Regional Court in Germany. Hellwig claimed that VMware violated the terms of GPLv2 by (1) combining Linux with VMware’s proprietary code, called “vmkernel,” in a manner that created a derivative work, while (2) failing to provide the complete corresponding source code for vmkernel as required under GPLv2. Vmkernel, the “kernel” of the VMware ESXi operating system, manages the hardware and software resources of the physical server.

VMware responded that vmkernel is not a derivative work of Linux but merely communicates with Linux through the VMK API. VMware also stated that the drivers that operate with vmkernel need not be Linux drivers, and that “a compatibility alternative called ‘vmklinux’ (interoperating with any Linux driver) via a loadable kernel module is loaded by vmkernel and interfaces with vmkernel through the VMK API.” Because the complaint and court filings are kept confidential under German court rules, the facts underlying the dispute cannot be confirmed.

The Hamburg court dismissed Hellwig’s suit on the ground that Hellwig failed to establish which components of the Linux system he had developed and whether VMware had used those components. The Hamburg Higher Regional Court dismissed the appeal of the first-instance ruling, and Hellwig decided not to appeal that decision further. Neither court addressed the substantive issues raised in the complaint; both ruled based on insufficient evidence regarding the right of ownership or copyright-protectability of certain components taken from Linux.

In response to these rulings, VMware stated, “VMware has been actively working for several years, independent of the litigation, to remove vmklinux from vSphere and hopes to accomplish this in a future major release.”

8. OSS business models and licensing

Many commercial FOSS companies have expressed concern that traditional OSS licenses allow Cloud Service Providers to use their programs without paying the FOSS company. In June 2019, CockroachDB adopted the BSL (Business Source License), first developed for MariaDB by Bruce Perens, one of the founders of the Open Source movement. CockroachDB’s CEO said the following: “Today we are adopting a very permissive license, the BSL (Business Source License). Users of CockroachDB can scale CockroachDB across multiple nodes. They can use CockroachDB or embed it in an application (whether distributing the application to customers or running it as a service). They can also run it internally as a service. The one and only restriction is that CockroachDB cannot be offered as a commercial service without purchasing a license.”

In November, Sentry also adopted the BSL. There were also several developments regarding new licenses adopted in 2018. In 2018, Redis Labs changed the license of its Redis modules from AGPL to Apache v2.0 with Commons Clause added (these Redis modules are add-ons on top of Redis core). Commons Clause was introduced as an addition to the Apache Software License version 2 to restrict use of the product by Cloud Service Providers. The introduction of this mixed license was highly controversial, and Redis abandoned the Commons Clause, adopting the Redis Source Available License for RediSearch, RedisGraph, RedisJSON, Redis-ML, and RedisBloom. Other companies adopted similar licenses.

9. Conflicts over RAND patent licensing between FOSS-governed and standards-body-governed projects

As FOSS has become widely adopted as a development methodology, standard setting organizations (SSOs) have worked to incorporate FOSS approaches into their processes. However, the methodologies of FOSS projects and SSOs differ considerably. FOSS projects operate with much more diverse responsibilities and in a more decentralized manner. One particular source of friction is the typical SSO approach of granting members patent rights on a royalty-bearing basis (under Fair, Reasonable, And Non-Discriminatory / FRAND terms). This friction is reflected in articles addressing patent licensing disputes under open source licenses (here and here).

David Kappos, the former Director of the US Patent and Trademark Office, stated the following: “Instead, we have found substantial support for the opposite conclusion — that OSD-compliant licenses should not be assumed to grant patent licenses absent an explicit patent grant clause. That is, OSS licensors can choose licenses that grant patent licenses, or choose licenses that do not, such as MIT and Berkeley. This preserves the ability of OSS and standard-essential patents (SEP) to work together to advance innovation.”

Van Lindberg, on the other hand, responded as follows: “This is why open source and FRAND are complementary but not compatible: open source and FRAND innovate relying on different intellectual property policies. These two development models can learn from each other and compete with each other, but they are fundamentally grounded in different underlying principles.”

“It’s understandable why SSOs want to incorporate OSS. Open source is cheap, interoperable, and innovative. SSOs have the ability to change to secure interoperability with OSS. All they need to do, as many organizations have already done, is adopt a Royalty-free IPR (intellectual property rights) policy. But an SSO that wants to impose FRAND royalties ultimately has the same choice that commercial companies have when dealing with open source: either respect the licenses and rules that must be followed when using OSS, or invest the time to create a commercial version.”

The difference in how royalties are paid on patents is creating tension between the FOSS and SSO communities. And some in the SSO community have argued that they should be able to define what “open source” is. This issue does not appear likely to be resolved anytime soon.

10. Open source licensing expands into data and cryptography issues

Data has been called the “new oil.” The concept of open source has been applied to data licensing (see the Linux Foundation’s Community Data License Agreement from 2017). This year, however, it was applied to data and cybersecurity. For example, the Cryptographic Autonomy License (CAL) was developed by Van Lindberg, an open source lawyer well known from his work with Holochain. Holochain explained this license as follows: “For distributed apps, the cryptographic key occupies a strange middle ground between code and user data. Code is functional and provides the process that routes and transforms user data as input or output for a computing system. User data is generally more like passive content that can be processed and stored by code. A cryptographic key is both user data and functional. In Holochain, cryptographic keys mediate proof of ownership of data: where data is stored, who controls the data, who verifies the security and encryption of communication and storage, and the operation of the chain structure for progressive hashing and signing that establishes the order and integrity of data.”

The CAL provides the following obligation with respect to user data: “Throughout any period in which You exercise any of the permissions granted to You under this License, You must also provide to any Recipient to whom you provide services via the Work, a no-charge copy, provided in a commonly used electronic form, of the Recipient’s User Data in your possession, to the extent that such User Data is available to You for use in conjunction with the Work.”

The license also allows a delay in providing source code when addressing a security flaw, which is a new and welcome approach: “You may delay providing the Source Code corresponding to a particular modification of the Work for up to ninety (90) days (the ‘Embargo Period’) if: a) the modification is intended to address a newly-identified vulnerability or a security flaw in the Work, b) disclosure of the vulnerability or security flaw before the end of the Embargo Period would put the data, identity, or autonomy of one or more Recipients of the Work at significant risk, c) You are participating in a coordinated disclosure of the vulnerability or security flaw with one or more additional Licensees, and d) Access to the Source Code pertaining to the modification is provided to all Recipients at the end of the Embargo Period.”

The Linux Foundation has continued to work on open data issues through the JDF (Joint Development Foundation). Working with AWS, Genesys, and Salesforce, the JDF developed the Cloud Information Model, an open source data model that standardizes data interoperability across cloud applications.