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 originalA2. Of the 22 claims originally filed, two remain: open source license violation and breach of contractA2·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 codeC1. 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 contentB1·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 pausedA1. 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 arisesC3·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 codeC3. 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 sustainedA6. 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 scanningA6·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 shownB2·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) listsD1. 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 CopilotD2.

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

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 repositoryrockchip-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 calledmpp 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’slibavcodec. 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’slibavcodec/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’smpp/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 ofvpx_rac.c, Fiona Glaser, and ofvp9data.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.

FFmpeglibavcodec/vpx_rac.h:

staticav_always_inlineintvpx_rac_get_prob(VPXRangeCoder*c,uint8_tprob){unsignedintcode_word=vpx_rac_renorm(c);unsignedintlow=1+(((c->high-1)*prob)>>8);unsignedintlow_shift=low<<16;intbit=code_word>=low_shift;c->high=bit?c->high-low:low;c->code_word=bit?code_word-low_shift:code_word;returnbit;}

MPPmpp/codec/dec/vp9/vpx_rac.c (commit14667441, as of the time infringement was alleged):

rk_s32vpx_rac_get_prob(VpxRangeCoder*c,uint8_tprob){unsignedintcode_word=vpx_rac_renorm(c);unsignedintlow=1+(((c->high-1)*prob)>>8);unsignedintlow_shift=low<<16;intbit=code_word>=low_shift;c->high=bit?c->high-low:low;c->code_word=bit?code_word-low_shift:code_word;returnbit;}

The only changes are dropping the inline specifier and changing the return type fromint tork_s32. The function body is identical down to the whitespace, and theuint8_t parameter type andunsigned 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’svpx_rac.h. The second is a question the FFmpeg developer posed to themselves; the original refers tovp56_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’svp56.h declares the first field of its motion vector struct asDECLARE_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 theffmpeg-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 asff_vp9_,av_always_inline,AVCodecContext, andlibavcodec 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 filevp9data.h was not deleted; it was renamed tovp9d_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’shal_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: thenyanmisaka/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.

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 popularFritz!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 thecomplaint, 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 thecomplaint 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.

Introduction

Three major pieces of legislation the European Union (EU) has recently introduced carry very significant implications for Korean companies. TheProduct Liability Directive (PLD), theCyber Resilience Act (CRA), and theAI 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

TheProduct 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

TheCyber 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

TheAI 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 achatbot, 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 respectthe 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 anSBOM (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.

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 organizationLAION (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.

CommonCrawlmakes 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 tocreate 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 informationincludes:

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

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

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.0name:Example SPDX 3.0 Documentelements:-type:Packagename:ExamplePackageversion:1.0.0

3. RDF

   • Suitable for semantic web applications

   • Example:

     <rdf:RDFxmlns: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 thespdx_tools.spdx3.bump_from_spdx2.spdx_document module of the SPDX Python Library
   • Convert SPDX 2.x documents to 3.0 using thebump_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 theExternalReference 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.

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 theAGPL-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, particularlyAWS. 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 theOpenSearch 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 theOpen 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, Elasticannounced 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 traditionalGPL license in that it requires source code to be disclosed even for software used over a network.

Thekey 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 choseAGPL-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 expertsquestion whether this change can quickly restore the community’s trust. There is also analysissuggesting 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 continuousmonitoring, which makes it important to form a dedicated team and introduce a management system. A systematic process should be built throughopen 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 providetraining andguidelines 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 operatingcloud 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.

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 namedLasso. 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 (nowhttps://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. ^^

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

OpenChain Korea Work Group

TheOpenChain Korea Work Group (KWG) is a subgroup of the Linux Foundation’sOpenChain 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’smajor 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 firstOpenChain 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, anin-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 managersSeoyeon 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 theGlobal 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 aSelf-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, andmany 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 abrief 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 foundhere.

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

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 asession 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 wasopen-sourced in 2021 for anyone to use. Kyungae Kim of LG Electronics introduced the 2023FOSSLight 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 theSPDX format into an open source notice. Hyeonmin Han of Kakao introduced the new features recently added to onot. The presentation materials can be foundhere.

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!

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. Yetthere 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. TheLinux Foundation’sOpenChain 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’sOSRB 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 hasnumerous 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 forSelf-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 holdonline webinars on open source management.

Training Courses

Afree 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 asCAICT andCESI.

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 withOIN is also said to be restarting.

Japan

TheOpenChain 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 withTODO Group, OSPO events are also held every two weeks.

Korea Market: Challenges and Opportunities

Current Situation

TheOpenChain 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 theOpenChain 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. TheOpenChain 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.

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

https://www.anaconda.com/

But you need to buy Anaconda to use it.

InSeptember 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 theAnaconda 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 theAnaconda Repository, providing over 8,000 open source packages, and users can reliably install and manage these packages with theconda install PACKAGENAME command.

https://repo.anaconda.com/

TheTerms of Service for this veryAnaconda 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 managerconda as open source.conda itself is open source released under theBSD-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 theAnaconda 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 condawithout violating the Terms of Service described above.

Peter Wang, CEO of Anaconda Inc., hasstated 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 itneeded 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.

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 theActor 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 isBUSL-1.1 (Business Source License).
• It can be used for free for noncommercial purposes, but a license fee must be paid for commercial use.

Lightbendstated 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 isBUSL-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 fornon-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 asnon-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 mustpurchase a commercial license from Lightbend.

Change Date, Change License

Another characteristic of BUSL-1.1 is theChange Date andChange License. Once theChange Date passes after a version of the software under BUSL-1.1 is released, theChange 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.

ForAkka’s BUSL-1.1, theChange Date is 3 years after release, and theChange 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 thisChange 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 anAdditional 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, Lightbendpermitted the use of Akka when developing an application usingPlay 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

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

Free for startup-sized companies

First, looking atAkka’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 fornon-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.

Hello, this isHaksung Jang.

SFC (Software Freedom Conservancy) filed suit againstVizio, a US smart TV manufacturer, alleging violations of the GPL. On May 13, 2022, a US federal court issued aruling 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 providefeedback. ^^

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 filedsuit in state court against Vizio, alleging violations of the GPL and LGPL in connection withSmartCast 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 alsostated 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 thedomestic 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 anopinion from a legal expert. :)

Thank you.

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

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.

• UnderArticle 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.

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 titledOpen 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 usedWordPress, 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 onWordPress.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.

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

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.

Hello, this is Haksung Jang.

In September 2021, it was reported through aChinese 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 toJin-Young Choi, Center Director at the Korea Copyright Commission, for helping review this. ^^)

Summary

In April 2021, a first-instance civilruling 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 isJining 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 atthe 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 ultimatelyremoved 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 thata 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 theAugust 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 plaintiffRMB 20 million in economic damages.
3. Defendants Fujian Fengling Company and Beijing Fengling Company shall compensate the plaintiff for a reasonable fee ofRMB 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 courtruled 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 didnot 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 reportedlyclose 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. :)

Hello.

P. McCoy Smith, a well-known open source license attorney in the United States, recently published an article titledDoes 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 athaksung@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.

      “Atyrant 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 thingsno 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 notinstall orrun 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 ahardware 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 areaswhere 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 thesource 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 asan 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 theinformation 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 ofGPLv3 Discussion Committee B, he was an active participant in the debate over, and revision of, the ‘Installation Information’ requirement in that licence.

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 athaksung@sk.com
• I am deeply grateful toSean of Kakao for his help reviewing this translation. ^^

This paper was translated by Haksung Jang from the English version available at theDistribution of Dockerfiles. The original document is licensed underCC-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 aboutdistribution 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.