Blog

• 2026
• CISA 2026 SBOM Minimum Elements: What to Prepare and Which Tools Fill the Gaps
• What the US AI Executive Order (2026-06-02) Means for Enterprise Open Source Managers
• The EU Open Source Strategy: Institutionalizing Open Source for Tech Sovereignty
• AI-Generated Code: How Far Should Open-Source Scanning Go?
• EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — A Research Report for the 2026-09-11 Compliance Date
• Rockchip and FFmpeg: A License Dispute Case Study
• 2025
• The AVM Lawsuit: Revisiting LGPL-2.1 User Rights and the Obligation to Provide Installation Information
• 2024
• What the Oracle v. Rimini Street Case Tells Us About the Scope of GPL Derivative Works
• Key Points of the EU's Three Major Digital Regulations That Korean Software Companies Need to Know
• To Mine or Not To Mine: A German Court's Ruling on the Copyright Dilemma of the AI Era
• A Chinese Copyright Infringement Case: "Since GPL-Based Software Products Already Have an Obligation to Disclose Source Anyway, Isn't It Fine to Copy Them?"
• Elasticsearch Changes Its License Again: How Should Companies Respond?
• Introduction to SPDX 3.0 and Enterprise Adoption Strategy
• French Court Orders Major Telecom Orange to Pay Damages for GPL Violation
• 2023
• Checklist for Preparing an In-Person Meeting
• Effective Open Source Management Practices for Companies (2): OpenChain Korea Work Group
• Effective Corporate Open Source Management (1): The OpenChain Project for Global Collaboration
• Buy Anaconda If You Use It. If Not, Use conda-forge!
• 2022
• Akka Is No Longer Open Source.
• A Quick Look at the SFC v. Vizio Ruling
• Challenges and Effects of Adopting InnerSource
• Can I Use a Publicly Available Dataset to Build a Commercial AI Service?
• 2021
• Is Open Source Compliance Necessary Even When Providing a Service as SaaS?
• The Log4j 2 Security Vulnerability Incident (Log4Shell)
• NIPA Publishes Four Guides for Using Open Source Software
• China's First GPL Lawsuit Case: VirtualApp
• Does GPLv2 Also Require Installation Information?
• Distribution of Dockerfiles: Who Is Responsible for Compliance?
• What Is an OSPO?
• Elastic License 2.0 and the Evolution of Open Source Licensing
• Opensource license used by IT Companies
• OpenChain KWG News in 2020
• ISO Standard, OpenChain
• Kakao Training Material
• NCSOFT Training Material
• Open Source Compliance in the Enterprise
• News
• SK Telecom is the first Telecommunications Operator to adopt OpenChain ISO 5230
• Samsung Electronics Announces OpenChain ISO 5230 Conformance
• 오픈소스SW 관리 툴 ‘포스라이트’ 공개한 LG전자, “글로벌 표준 거듭나겠다”
• 한 달 걸리던 카카오톡 오픈소스 관리, 이틀이면 충분
• SK텔레콤, 개발자와 소통하는 커뮤니티 ‘DEVOCEAN’ 론칭

2026

CISA 2026 SBOM Minimum Elements: What to Prepare and Which Tools Fill the Gaps

Summary

On July 29, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) and 17 other agencies published a revised set of minimum elements for a Software Bill of Materials (SBOM)A2. The document states plainly that it replaces, rather than amends, the baseline established in 2021 by the National Telecommunications and Information Administration (NTIA).

The bar has risen noticeably. The data fields grew from 7 to 17, and six operational practices were specified alongside them. Ten of the elements are entirely new.

Three changes matter most in practice.

• Licensing entered the SBOM minimum baseline for the first time.
• Dependencies must now be recorded in full, down to transitive dependencies, with no depth limit.
• New fields were added to declare the origin and integrity of the SBOM document itself.

The document carries no effective date and no enforcement power. Preparation is still warranted, because national regulations increasingly require SBOMs without enumerating the fields those SBOMs must contain. The practical significance of this document is that it gives procurement contracts a multilateral consensus baseline to cite.

The nature of that preparation is easy to misjudge. Meeting the minimum elements is not a matter of picking a tool. Fewer than half of the 23 elements can be filled by a generation tool on its own. The rest are filled by the build pipeline, the signing infrastructure, and policies the organization decided on in advance.

I also checked how far an actual tool gets. BomLens is an SBOM generation and management tool that SK telecom developed for software supply chain security and released as open source. Assessing all 23 elements with it produced the following:

• The tool fills 11 of the 17 data fields directly with values.
• It inspects supplier-submitted SBOMs against all 23 elements, separating out the 4 that the organization must decide as items for human review.
• The remaining gaps exist not because the tool is deficient, but because those values must be determined by whoever runs it or by the build stage at which it runs.

The assessment screen can be viewed directly in the public demo, with nothing to install.

1. What Changed

1.1 The Structure of the Elements

The minimum elements fall into two categories. Seventeen data fields are the values actually carried in the SBOM document; six operational practices govern how an organization handles SBOMs.

Figure 1. The composition of the CISA 2026 SBOM minimum elements (source: 2026 Minimum Elements for a SBOM, 2026-07-29)

SBOM metadata is a category that did not exist in the 2021 edition. Where the earlier baseline asked for little more than an author and a timestamp, the document now requires the SBOM to declare for itself which tool produced it, when, at what stage, and who signed it.

1.2 Three Substantive Changes

Licensing became mandatory. The seven data fields of the 2021 edition did not include licensing, because that document was aimed at security and vulnerability management. The revision adds component licensing as a new element, requiring that it be conveyed in a machine-processable form such as an SPDX license identifier where possible, and that the presence of proprietary license terms be disclosed as well. Territory that belonged to the Open Source Program Office (OSPO) is now part of the SBOM minimum baseline.

The floor on dependency resolution is gone. The Depth element of the 2021 edition required only top-level dependencies. The revision replaces it with a Coverage element that requires all constituent components including transitive dependencies, and states explicitly that recording only to a certain depth is no longer sufficient. The document is candid about why. The 2021 baseline “reflected the capabilities of SBOM tooling at the time rather than the depth of information needed for informed security decisions,” and since tooling has advanced in the interim, the requirement has been raised.

Supplier Name became Component Producer. This is a change of definition, not merely of label. The document states that Supplier Name “proved ambiguous in practice, particularly in relation to software distributors.” The intent is to end the practice of naming redistributors and to point the field at the entity that originally created the software. Where the producer is unclear, as with open source projects, the document requires that the unknown provenance be stated explicitly.

Separately, Software Identification (SWID) tags were dropped from the list of accepted formats. Two remain: SPDX and CycloneDX.

2. What the OSPO Must Decide

The six operational practices are items an organization must answer, not a tool. The document says as much: organizations “should explicitly address these elements in all policies, contracts, and agreements that require or provide SBOMs.”

2.1 How Much to Include

The Coverage element requires all transitive dependencies while permitting the exclusion of non-code files. It adds that security-relevant files, such as configuration files, may be included. Where to draw the line on security relevance is for the organization to decide.

The vulnerability management test offered by the document is a useful criterion: an SBOM recipient should be able to conclude that a newly reported vulnerability does not affect them if the associated component is absent from the list. A scope definition that fails this test does not satisfy the Coverage requirement.

Linking each subcomponent to a separate SBOM is also permitted, but with a condition. The recipient must be able to access every linked SBOM. Providing links without access rights does not meet the requirement.

2.2 When to Regenerate

The Frequency element requires a corresponding SBOM for each software version or update. Every new build or release calls for a new SBOM, and that includes builds where only dependencies changed.

One more obligation attaches here. If errors are found in existing SBOM data, or new facts about a component come to light, a revised edition must be issued. This means an SBOM may need to be reissued without any accompanying release, which in turn requires a way to track where already-distributed SBOMs went.

2.3 How to Record What Is Not Known

Explicit identification of unknowns is a major update. The requirement is specific: when a value is absent, it must be clear whether the information is unknown to the author or whether the author is knowingly withholding it.

The distinction conveys different information to the recipient. Unknown means the supply chain trace broke off at that point; withheld means the supplier has the information and is not providing it. For the latter case, the document requires a process through which recipients can inquire, and adds that an SBOM withholding essential component data may be treated as incomplete.

In practice, the notation convention has to be settled first. Simply leaving a field empty makes the three cases indistinguishable: whether the value does not exist, was never confirmed, or was deliberately not disclosed.

2.4 Which Formats to Accept

The machine-readable data element names SPDX and CycloneDX while directing organizations to accept widely used, interoperable formats. One condition attaches: SBOMs for new software generated with deprecated versions should not be accepted.

That condition creates a second acceptance criterion. Format version matters as much as format name, and the new SBOM data format name and version elements provide the basis for that judgment.

2.5 What to Put in Contracts

Translated into contract language, the items above come out as follows.

• The required format and minimum version
• The coverage scope, including transitive dependencies
• The obligation to supply an SBOM with each release, and to supply a revision when errors are found
• Distinct notation for unknown versus withheld, and an inquiry process for withheld items

The three actions the document recommends to organizations point the same way: require SBOMs that satisfy the updated minimum elements, use tooling to generate, collect, and analyze SBOM data, and generate SBOMs that satisfy the minimum elements themselves.

3. Who Fills Each Element

Sorting the 23 elements by who fills them clarifies what preparation actually involves.

Figure 2. The four domains that fill the 23 minimum elements (source: compiled from the element definitions in the original document)

What a generation tool can handle alone sits on the component data side. The rest must be filled from outside the tool.

Generation context must be recorded inside the build pipeline to be accurate. An SBOM built from source corresponds to “pre-build” and one built from binary analysis to “post-build” — a value determined by when the scan runs, not by what it scans.

Component hashes require an executable artifact to compute. At source-scan time that artifact does not yet exist, making it inherently impossible, and the document itself prescribes an unknown marking for this case. Requiring hashes means generating or updating the SBOM at a post-build stage.

Author signatures presuppose key management. The document directs organizations to use existing software signing infrastructure and key management, which falls outside the scope of an SBOM tool.

SBOM Author is a value the tool cannot know. Since the definition is the entity operating the tool, whoever runs it has to supply it.

3.1 Which Formats Carry the New Elements

Formats differ in how far they carry the 10 new fields, which makes the choice of format itself a practical decisionC3.

Table 1. How each format can express the new elements (source: RunSafe Security field mapping analysis, 2026)

CycloneDX has the advantage on the new metadata. Generation context and signatures exist as native fields, and the lifecycle phase vocabulary the original document uses as an example maps across directly.

Conversely, SPDX offers the better mechanism for marking unknowns. Its standard NOASSERTION marker distinguishes “no value” from “not determined,” whereas CycloneDX has no marker at that level, requiring a separate convention using properties or annotations. And marking unknowns is precisely one of the requirements this revision strengthened.

The judgment at this point is as follows. The combination that carries the minimum elements most completely is CycloneDX 1.6, provided the organization establishes its own convention for marking unknowns. Organizations using SPDX as their primary format have no place in 2.3 for generation context or signatures, which makes this the moment to consider migrating to 3.0.

4. Relationship to Regulation

The minimum elements carry no legal force in themselves. The disclaimer states that the publication “is not intended as compliance, regulatory, or legal advice.”

Its real influence comes through citation. The European Union Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to provide an SBOM as part of the technical documentation, but does not enumerate the fields in its textA5. Germany’s BSI TR-03183-2 filled that gap with concrete technical requirements, and India’s CERT-In and Japan’s Ministry of Economy, Trade and Industry have issued guidance of their own. The minimum elements are the baseline these all reference in common.

One caution applies. Although the European Commission’s Directorate-General for Communications Networks, Content and Technology (DG CONNECT) contributed to the drafting, a footnote states that the document does not interpret European Union law, does not bind the Commission, and that not all of its elements reflect Union law. It cannot be used as-is to demonstrate Cyber Resilience Act compliance.

There is also a terminological trap. A footnote in the original explicitly warns against confusing the “producer” of Component Producer with the “manufacturer” of the Cyber Resilience Act. Every manufacturer is a producer, but not every producer is a manufacturer. Documents that address both regimes need to keep the terms distinct.

From Korea, two organizations participated as co-authors: the National Cyber Security Center under the National Intelligence Service, and the Korea Internet & Security Agency. That participation gives domestic procurement and internal policy a basis for citing this document. Because the international common baseline was updated immediately after the government’s joint Software Supply Chain Security Roadmap was announced in June 2026, domestic policy now has a reference to draw on when it comes to specifying required fields.

Organizations working with AI systems should note the ordering. The original document introduces no AI-specific elements, deferring them to the G7 joint guidanceA10. The two documents are hierarchical: fill this general software baseline first, then add the AI-specific elements.

5. How Far Do Actual Tools Get Today

Reading a baseline and confirming that a tool actually meets it are separate exercises. Even when a format has a place for a value, the field stays empty if the tool does not put one there.

I assessed all 23 elements using BomLens, the SBOM generation and management tool that SK telecom developed for software supply chain security and released as open source. The basis was actual scan output and source code rather than estimationD1.

5.1 What the Tool Fills with Values

The tool fills 11 of the 17 data fields directly.

• SBOM metadata: data format name and version, generation context, timestamp, tool name, SBOM version
• Component data: name, version, identifier, license, dependency relationships

Three of these are filled in ways that bear directly on the minimum element requirements.

• Generation context is determined automatically from the input type. Source scans are recorded as pre-build and container and binary scans as post-build, so the user never selects the value.
• Licensing is filled for 98.4% of components on the source path and 94.7% on the container path. The source side reads from package manifests, the container side from the operating system package database.
• The tool name records both BomLens itself and its underlying generators. The minimum elements ask for the tools that generated or modified the SBOM, so both are retained.

Among the six operational practices, it satisfies machine-readability and distribution and delivery. It emits CycloneDX 1.6 as its default format and supports conversion to SPDX 2.3, covering both formats the minimum elements designate.

5.2 What the Tool Cannot Fill

The remaining items are empty not because the tool falls short, but because of the structure described in section 3.

• SBOM author and author signature: the entity running the tool must supply the value. The author is passed via --sbom-author, and signing is a separate option that uses cosign.
• Component hash: at source-scan time no executable artifact exists to hash. On paths where an artifact does exist, such as containers and firmware, the scan target itself is hashed.
• Component producer: the package metadata must carry producer information for this to be filled. Coverage is 60.9% on the source path and 94.7% on the container path.

How the absence of a value is handled matters from the minimum elements perspective. When no author is specified, this tool does not write unknown; it leaves the field empty and adds a document-level declaration that empty fields were not determined by the author. Because the minimum elements define the author as the entity operating the tool, and that entity knows who it is, a tool writing unknown would not be marking an unknown but making a false statement. Hashes follow the same principle: no value is invented.

5.3 Assessing Received SBOMs Against the Minimum Elements

The tool can also inspect supplier-submitted SBOMs against all 23 elements. Results come out in three branches. The screen below comes from the public demo, where a single CycloneDX 1.6 document received from outside is inspected.

Figure 3. The conformance assessment screen in the public demo. All 23 elements are assessed, with the 4 the tool cannot judge separated out for human review (BomLens public demo, FlaskDataService 3.2.0)

• Present, 11 — six SBOM metadata fields (author, data format name and version, timestamp, tool name, SBOM version), four component data fields (name, version, hash algorithm, dependency relationship), and one operational practice (machine-processable data).
• Gap, 8 — author signature, generation context, tool version, component producer, component identifiers, component license, component hash value, and the explicit marking of unknown information.
• Human review, 4 — Coverage, Accommodation of Updates to SBOM Data, Distribution and Delivery, and Frequency. These are decided by the organization, so the tool passes them to a person rather than judging them.

Not treating what it cannot judge as a pass is what makes this useful in practice. The four items marked for human review are the same organizational decisions covered in section 2.

The same screen can be opened directly in the public demo. It runs in a browser with nothing to install, and each element carries a note on what is missing and how to fill it.

5.4 What Remains

Some gaps remain before the minimum elements are fully met.

• The tool version is recorded as an image tag rather than a release number. The minimum elements call for a value that identifies a specific delivery of code.
• The SBOM version stays fixed at 1 across regenerations and cannot express revision relationships. This connects directly to the accommodation of updates element, but a locally running tool cannot know where its previous output went, which makes user-specified versioning the realistic alternative.

6. Conclusion

What the revised minimum elements demand is not more fields but a different kind of preparation.

With licensing in the minimum baseline, the SBOM is no longer a document belonging to the security team alone. Filling in license identifiers in machine-processable form, disclosing the presence of proprietary terms, and stating plainly when something is not known — this is how an OSPO already works. What changed is that the result now has to leave the organization in a standard format.

Much of the preparation has to be finished before a tool is selected. Four items are for the organization to decide.

• How much to include
• When to regenerate
• How to mark what is not known
• Which formats and versions to accept

Adopt a tool without settling these, and whatever defaults the tool produces become the organization’s policy.

It is equally necessary to separate what can be demanded of a tool from what cannot. A source-scanning tool cannot be asked for the hash of an executable artifact, and no tool can decide an organization’s name on its behalf. Demand that unfillable values be filled and the tool will invent plausible ones, which is the direction the minimum elements prohibit.

Checking what your current tool fills and what it leaves empty is worth doing once. Format support and field satisfaction are different questions, and the gap between them only shows when you open the output yourself. If there is no obvious tool at hand to check, BomLens from section 5 is a starting point. It is open source and free to download, and it shows both how far a generated SBOM meets the 23 elements and whether a supplier-submitted SBOM meets the baseline, on the same screen.

References

A2. Cybersecurity and Infrastructure Security Agency and 17 other agencies (2026). 2026 Minimum Elements for a Software Bill of Materials (SBOM). v2.1, published July 29, 2026, TLP:CLEAR. https://www.cisa.gov/sites/default/files/2026-07/2026_cisa_sbom_minimum_elements_508c.pdf. ↩

A5. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal of the European Union, October 23, 2024. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402847. ↩

A10. G7 Cybersecurity Working Group / CISA et al. (2026). Software Bill of Materials for AI — Minimum Elements. Published May 12, 2026, TLP:CLEAR. https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements. ↩

A1. National Telecommunications and Information Administration (2021). The Minimum Elements For a Software Bill of Materials (SBOM). Published July 12, 2021. https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom.

A3. Federal Register (2025). Request for Comment on 2025 Minimum Elements for a Software Bill of Materials. Published August 22, 2025; comment period closed October 3, 2025. https://www.federalregister.gov/documents/2025/08/22/2025-16147/request-for-comment-on-2025-minimum-elements-for-a-software-bill-of-materials.

B1. SPDX. The System Package Data Exchange. https://spdx.dev/. ISO/IEC 5962:2021.

B2. CycloneDX. https://cyclonedx.org/. Ecma International, ECMA-424: CycloneDX Bill of Materials Specification, December 2025.

C3. RunSafe Security (2026). Mapping CISA’s 2026 SBOM Minimum Elements to CycloneDX and SPDX. https://runsafesecurity.com/blog/sbom-minimum-elements-cyclonedx-spdx/. — The basis for Table 1. The per-format field mapping is taken from this analysis and was not verified directly against the specifications. ↩

D1. BomLens. An SBOM generation and management tool developed and released by SK telecom for software supply chain security, Apache-2.0. https://github.com/sktelecom/bomlens. The coverage assessment in section 5 was determined from actual scan output and source code using version 1.10.3 of this tool. ↩

What the US AI Executive Order (2026-06-02) Means for Enterprise Open Source Managers

Summary

The executive order “Promoting Advanced Artificial Intelligence Innovation and Security,” signed on June 2, 2026, imposes no obligations on enterprises. Its substance is the Treasury Department-led AI Cybersecurity Clearinghouse (a relay body that pools, verifies, and distributes vulnerability information, to be established within 30 days) and a voluntary pre-disclosure framework for frontier models (to be designed within 60 days); mandatory licensing and pre-approval are explicitly excluded A1. No provision applies directly to enterprise open source managers either. Still, there is a reason to read this order: the context behind it. AI finding open source vulnerabilities faster than humans do has already become reality. Ahead of the executive order, an unreleased Anthropic model found 6,202 high- or critical-severity vulnerabilities in open source projects over two months, and patching has not kept pace A6·C1. What open source managers need to prepare is not compliance with the executive order, but a response system that can handle a check of patch-processing capacity, cleanup of end-of-life (EOL) components, and the EU Cyber Resilience Act reporting obligation taking effect September 11, 2026, all at once.

1. What the Executive Order Actually Establishes

The executive order consists of five sections, all premised on voluntary cooperation. Section 1 declares a stance of “refusing to stifle innovation through excessive regulation” along with an America First cybersecurity posture, and Section 5 contains standard general provisions. The substance is in the three sections in between A1.

Section 2 covers strengthening federal and private-sector cyber defense. Within 30 days, it prioritizes defense of national security systems, Department of War systems, and federal civilian systems, and within the same period the Treasury Secretary, in consultation with the National Cyber Director, the National Security Agency (NSA), and the Cybersecurity and Infrastructure Security Agency (CISA), establishes an AI cybersecurity clearinghouse. A clearinghouse originally referred to an interbank facility for exchanging and settling checks; here the term means a relay body that pools, verifies, and distributes information from multiple participants. In this order, it is tasked with coordinating software vulnerability scanning through voluntary cooperation with the AI industry and critical infrastructure operators to eliminate duplication, discovering and verifying vulnerabilities, and prioritizing patch development and deployment A1.

Section 3 covers the safe deployment of frontier models. Within 60 days, it establishes a classified benchmarking process to assess the cyber offensive capability of AI models, and based on the results, the NSA Director sets the threshold for which models qualify as a “covered frontier model.” Through a voluntary framework, developers consult with the government on whether their models meet the designated criteria, provide the government access to the model up to 30 days before the planned public release, and jointly select trusted partners who receive early access. Sec. 3(c) states explicitly that nothing in this section establishes mandatory licensing, pre-approval, or permitting requirements for the development, publication, disclosure, or deployment of new AI models A1.

Section 4 covers investigation and enforcement. The Attorney General prioritizes enforcement of existing federal criminal law, including 18 U.S.C. § 1030 (Computer Fraud and Abuse), against unauthorized computer access and damage carried out using AI and other crimes committed in the process A1.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 45}} }%%
flowchart TD
    A["<b>2023-10-30</b> &nbsp; Biden Executive Order 14110 — first comprehensive AI governance framework"]
    B["<b>2025-01</b> &nbsp; Inauguration Day (01-20): EO 14110 revoked; Executive Order 14179 signed (01-23)"]
    C["<b>2025-07-23</b> &nbsp; America's AI Action Plan released — includes a section encouraging open source and open weights"]
    D["<b>2026-04-07</b> &nbsp; Anthropic announces Mythos Preview and Project Glasswing"]
    E["<b>2026-06-02</b> &nbsp; This executive order signed; Glasswing expands to 150 organizations"]
    F["<b>2026-06-05</b> &nbsp; NSPM-11 — national security AI memorandum"]
    G["<b>2026-07-02</b> &nbsp; 30-day deadline — clearinghouse established, federal systems defended"]
    H["<b>2026-08-01</b> &nbsp; 60-day deadline — classified benchmarking and voluntary framework designed"]
    A --> B --> C --> D --> E --> F --> G --> H
    style E fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

Figure 1. Policy timeline around the executive order (source: official White House documents A1, A2, A3, A4, A5, Anthropic A6, Wiley’s deadline calculation B1. As of 2026-06-10)

The choice of lead agency has drawn comment as unexpected. Looking only at the function of vulnerability coordination, CISA or the Office of the National Cyber Director would seem the natural fit, yet the Treasury Department leads the clearinghouse. The Council on Foreign Relations (CFR) suggested this may be because Treasury is “one of the few agencies with institutional capacity left,” while the Atlantic Council flagged the risk of overlap with existing vulnerability coordination systems B4·B5. The threshold for the key term “covered frontier model” is also left undefined in the text. It will be set based on the classified benchmarking results, and WilmerHale expects defining this threshold to be the focus of agency rulemaking over the coming months B2.

2. Why Now

The direct background to the executive order is Claude Mythos Preview, announced by Anthropic on April 7, 2026. This unreleased model scored 83.1% on the vulnerability-reproduction benchmark CyberGym (up from 66.6% for the prior model), and instead of a general release, Anthropic chose Project Glasswing, opening access only to 12 partners including AWS, Apple, Google, and Microsoft A6. In under two months, participating organizations identified more than 10,000 high- or critical-severity vulnerabilities. Anthropic’s own scans alone turned up 23,019 issues across more than 1,000 open source projects, of which 6,202 were high or critical severity, and an independent security firm verified a sample of 1,752 and confirmed more than 90% were real vulnerabilities C1·C2. Notable examples include a remote crash flaw that lay dormant in OpenBSD for 27 years, a 16-year-old flaw in FFmpeg that had survived 5 million automated test runs, and a privilege escalation chain in the Linux kernel A6.

This process revealed a sharp mismatch between the speed of finding vulnerabilities and the speed of fixing them. Anthropic itself stated that “the bottleneck for fixing these bugs is human capacity to triage, report, and design and ship patches,” and once open source maintainers became the bottleneck, it began working with OpenSSF’s Alpha-Omega project C1·C2. Bruce Schneier assessed that, for now, “finding in order to fix” is easier than “finding in order to exploit,” giving defenders a favorable window, but that this window is temporary and that an era of automated zero-day discovery will arrive before we finish preparing for it. He added the caveat that this capability is not any one company’s exclusive property, noting that the security firm Aisle reproduced part of the results using an older public model C3.

The executive order is the US government’s response to this situation. The clearinghouse is a plan for the government to coordinate at a national level what private actors, such as Glasswing, had been doing individually: finding and verifying vulnerabilities with AI and coordinating patches A1·B5.

3. What This Means for Enterprise Open Source Managers

3.1 A Document That Never Says “Open Source”

The term “open source” appears nowhere in the executive order’s text or the White House fact sheet A1·A2. Read favorably, this means no regulatory burden. The order imposes no obligations on open source developers or open-weight model distributors, and because the licensing-ban provision in Sec. 3(c) covers “development, publication, disclosure, and deployment” of a model altogether, distribution by releasing weights also falls within its protection A1. The administration’s official stance remains what it stated in the July 2025 AI Action Plan: the choice between open and closed is entirely up to the developer, and the federal government will create an environment favorable to open models A5.

The open question is the threshold for a covered frontier model. Since it will be set by a classified benchmark, it is not yet possible to know what happens if an open-weight model crosses that threshold. The core mechanism of the voluntary framework, “government access 30 days before release,” is designed around closed models whose release timing can be controlled; it does not fit open models, whose weights, once released, cannot be recalled. CFR’s experts expect frontier-level vulnerability-reasoning capability to be reproduced in open-weight systems before long, and similar reproduction studies are already being cited B5. If this capability spreads to open models, the gap in a design built on voluntary pre-disclosure will become apparent, and further regulatory discussion could then target open models. Enterprises that use open-weight models internally, or fine-tune and deploy them, should watch how the benchmarking process due by August 1 and the rulemaking that follows treat open models.

Open source foundations have also stayed quiet so far. As of a search on 2026-06-10, no statement on this executive order could be confirmed from the Open Source Initiative (OSI), the Linux Foundation, or OpenSSF. With no obligations imposed, the incentive to respond immediately appears to have been weak. The closest thing to an official position is OSI’s response to the AI Action Plan comment request in March 2025 B7.

3.2 Where the Clearinghouse Meets Enterprise Vulnerability Management

The clearinghouse’s three functions — coordinating scans, discovering and verifying vulnerabilities, and prioritizing patches and coordinating deployment — overlap precisely with the vulnerability management systems that enterprise open source organizations (OSPOs or product security teams) already run A1.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 50, 'rankSpacing': 60}} }%%
flowchart TB
    GOV["<b>AI Cybersecurity Clearinghouse</b><br/>Treasury-led — in consultation with NSA, CISA, National Cyber Director<br/>(established by 2026-07-02)"]
    VOL["<b>Voluntary participants</b><br/>AI developers (vulnerability-discovery capability), critical infrastructure operators"]
    OSS["<b>Open source maintainers</b><br/>Receive vulnerability reports via coordinated disclosure"]
    ENT["<b>Enterprise open source managers</b><br/>Consume patches, SBOM, CVD"]
    GOV <-->|"Scan coordination, discovery and verification, patch prioritization"| VOL
    VOL --> OSS --> ENT
    GOV -.->|"Recommendations and deployment coordination (operating model undisclosed)"| ENT
    style ENT fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

Figure 2. The position of enterprise open source managers in the clearinghouse and vulnerability information flow (source: analysis based on Executive Order Sec. 2(d) A1. The dotted line marks an operating model not yet disclosed)

Most enterprises will encounter the clearinghouse as consumers of information. Once it is operating, information on the discovery, verification, and patch prioritization of open source component vulnerabilities will flow out through a new channel. This adds one more US-originated channel to a company’s vulnerability intelligence pipeline, and one more coordinating body influencing patch-priority decisions.

Whether to participate directly in the clearinghouse is a separate decision. Companies in critical infrastructure sectors (energy, finance, healthcare, telecommunications, and others) are explicitly named as participants A1. Participating means receiving vulnerability information earlier, having a voice in patch coordination, and gaining access to the government-supported security tools mentioned in Sec. 2(c)(iii). In exchange, a company takes on the legal review burden that comes with information sharing, and, as Crowell & Moring pointed out, inherits the uncertainty of liability protection for participants going unspecified and the consequences of non-participation going undefined B3. If, as WilmerHale forecasts, the voluntary provisions migrate into federal procurement standards, there is a scenario in which participation becomes a de facto prerequisite for companies doing business with the US government B2. There is no reason to rush a decision before the operating model is disclosed in early July.

3.3 The Most Direct Impact: A Surge in Patch Demand and EOL Risk

A change already underway independent of the executive order is being accelerated by it. Once AI-based discovery is institutionalized as a national system and backed with federal funding (Sec. 2(e)), the number of vulnerabilities reported in open source components can only increase. The Glasswing figures previewed the scale of this.

The first thing enterprises run into is throughput. As new CVEs increase for open source components included in a company’s products, triage (impact analysis), patch application, and customer communication all have to scale up together. Organizations relying on manual triage are the first to accumulate a backlog.

End-of-life (EOL) components pose a deeper problem. AI scans code indiscriminately, whether or not it is still maintained, but a patch only comes from a maintainer. As HeroDevs, a commercial long-term-support (LTS) vendor, has pointed out, the gap between discovery speed and fix speed opens widest in EOL software. If an inventory still holds components where discovery keeps accelerating but a fix will never arrive, that risk only grows over time C4. The 27-year-old OpenBSD flaw and the 16-year-old FFmpeg flaw show that the assumption “old and stable means safe” no longer holds A6.

The burden on the upstream side also eventually comes back around as enterprise risk. Anthropic itself has confirmed that open source maintainers are becoming a bottleneck under the flood of reports C2. When the maintainer of a core component a company depends on is buried in triage, it is the company that ends up absorbing the patch delay. Adding maintenance health (number of maintainers, security response history, foundation affiliation) as an evaluation criterion for core dependencies, and participating in upstream support such as Alpha-Omega where warranted, is a path to reducing that risk.

3.4 Contrast with the EU CRA: Handling Voluntary and Mandatory Regimes at Once

The problem the US clearinghouse addresses — the discovery and patching of software vulnerabilities — is the same territory the EU has made mandatory through the Cyber Resilience Act (CRA — Regulation (EU) 2024/2847).

Table 1. Comparing the US executive order and EU CRA vulnerability reporting regimes (source: the executive order text A1, Regulation (EU) 2024/2847 A7, a separate report D1. As of 2026-06-10)

For a Korean company shipping products into both markets, the priority is clear: the one with binding force, a deadline, and fines comes first. The CRA Article 14 reporting workflow must be operational by September 11, three months out, and there is a confirmed practical constraint that, since ENISA does not currently offer an API to integrate with the SRP, the process has to be designed for manual human submission A7·D1. The US clearinghouse comes after that. That said, both regimes run on the same underlying capabilities: a component inventory (SBOM), vulnerability triage, a coordinated vulnerability disclosure (CVD) intake channel, and a patch deployment process. Since the system built to prepare for the CRA becomes the foundation for voluntary participation on the US side, there is no need to build a separate system twice.

3.5 A Policy Divergence: US Voluntary Cooperation, EU Institutionalization

On June 3, the day after the executive order, the European Commission announced its tech sovereignty package, placing open source at the center of digital policy. Its substance is roughly €2 billion in public and private funding mobilized over seven years, a new Open Source Maintenance Instrument, and the opening up of public procurement A8·D2. Issued a day apart, the two documents show opposing institutional designs for the same technological environment. The US model excludes regulation and has the government coordinate voluntary private-sector capability; the EU model institutionalizes the open source ecosystem itself through public funding and legal obligation, including the CRA’s steward regime.

A global company’s open source management policy has to be built on this divergence. In the US market, it must decide whether to join a voluntary cooperation channel; in the EU market, it must meet the obligations of CRA compliance and the steward regime. Since the same team ends up running both modes within one company, a structure that layers market-specific modules on top of shared capability is more realistic than splitting policy documents and response organizations by market.

3.6 A Different Axis from Managing AI-Generated Code

A separate analysis on the inflow of AI-generated code into open source and snippet screening D3 and this issue both touch AI and open source management, but they sit on different axes. That analysis covered inflow management — the license and provenance problems that arise when AI coding tools bring undeclared code snippets into a codebase. This executive order points to operations — the response problem in an environment where AI makes vulnerabilities in already-present open source components surface faster and in greater numbers. AI now affects both the stage where code comes in and the stage where vulnerabilities surface, and the response systems for the two axes need to be checked separately.

4. Preparation

Since the executive order makes no direct demands of enterprises, preparation splits into what to do now and what to watch.

What to Do Now

The starting point is an inventory of your own AI exposure surface. Consolidate, in one place, the models developed or fine-tuned in-house (especially open-weight-based ones), the AI coding and security tools adopted, and the current state of AI-generated code that has entered the codebase. The point is to be able to judge immediately, once the covered-frontier-model threshold takes shape after August 1, whether your company falls near that line.

Also check your open source vulnerability response system. Confirm that SBOMs are up to date across all products, that new-CVE triage can absorb a two- to three-fold increase in volume, and that the CVD intake channel works. This check is the same work as preparing for CRA Article 14 (with its September 11 deadline), so there is no need to create a separate project — fold it into CRA preparation D1.

The most urgent item is cleaning up EOL components. Identify end-of-life components from the SBOM, set a schedule for those with an upgrade path, and for those that cannot be removed immediately, settle on a patch source such as commercial LTS or an in-house patch. Document items that can be shown not to be affected using Vulnerability Exploitability eXchange (VEX) to reduce the triage burden C4.

Finally, assess the health of core upstream dependencies. Check the maintainer base size and security response history of upstream components that revenue-critical products depend on, and for projects at risk of becoming a bottleneck, consider support measures such as sponsorship or contribution C2.

What to Watch

Table 2. Items to track and their timing (as of 2026-06-10)

5. Conclusion

This executive order imposes no new obligation on enterprise open source managers, but it signals that the premises of the working environment are shifting. An era in which AI finds open source vulnerabilities in bulk has been demonstrated, and the US government has decided to institutionalize that trend through coordination rather than regulation. Discovery is speeding up while patching still runs at human speed. In that gap, the only thing a company can control is its own inventory’s processing capacity. Since the EU CRA reporting obligation taking effect three months from now requires SBOM, triage, and CVD capability regardless, preparing for both markets under one system is the most efficient path. As for the executive order itself, it is enough to mark two dates on the calendar: July 2 (the clearinghouse) and August 1 (the benchmarking standard).

References

All URLs were checked for access and content match on 2026-06-10 (except where noted).

A. Primary Sources (Official Government Documents, Party Announcements)

A1. The White House (2026). Promoting Advanced Artificial Intelligence Innovation and Security (Executive Order). Signed 2026-06-02. https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/ (accessed 2026-06-10). — The primary source for this report. ↩

A2. The White House (2026). Fact Sheet: President Donald J. Trump Promotes Advanced Artificial Intelligence Innovation and Security. 2026-06-02. https://www.whitehouse.gov/fact-sheets/2026/06/fact-sheet-president-donald-j-trump-promotes-advanced-artificial-intelligence-innovation-and-security/ (accessed 2026-06-10). ↩

A3. The White House (2026). National Security Presidential Memorandum/NSPM-11 — Artificial Intelligence in the National Security Enterprise. 2026-06-05. https://www.whitehouse.gov/presidential-actions/2026/06/national-security-presidential-memorandum-nspm-11/ (accessed 2026-06-10). ↩

A4. The White House (2025). Removing Barriers to American Leadership in Artificial Intelligence (Executive Order 14179). 2025-01-23. https://www.whitehouse.gov/presidential-actions/2025/01/removing-barriers-to-american-leadership-in-artificial-intelligence/ (accessed 2026-06-10). ↩

A5. The White House (2025). Winning the Race: America’s AI Action Plan. 2025-07. https://www.whitehouse.gov/wp-content/uploads/2025/07/Americas-AI-Action-Plan.pdf (accessed 2026-06-10, the relevant passage was verified directly against the PDF original). ↩

A6. Anthropic (2026). Project Glasswing: Securing critical software for the AI era. Announced 2026-04-07 (updated since). https://www.anthropic.com/glasswing (accessed 2026-06-10). ↩

A7. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed 2026-05-12, verified during this workspace’s CRA report fact-check). ↩

A8. European Commission (2026). Communication on European Tech Sovereignty, accompanied by an EU Open Source Strategy. COM(2026) 503 final, 2026-06-03. https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy (accessed 2026-06-10). ↩

B. Legal and Policy Analysis

B1. Wiley Rein LLP (2026). New AI Executive Order Addresses Frontier Models and Cybersecurity Vulnerabilities. https://www.wiley.law/alert-New-AI-Executive-Order-Addresses-Frontier-Models-and-Cybersecurity-Vulnerabilities (accessed 2026-06-10). ↩

B2. WilmerHale (2026). New Executive Order Addressing Early Government Access to Frontier AI Models. 2026-06-02. https://www.wilmerhale.com/en/insights/client-alerts/20260602-new-executive-order-addressing-early-government-access-to-frontier-ai-models (accessed 2026-06-10). ↩

B3. Crowell & Moring LLP (2026). Executive Order Creates Voluntary Regulatory Regime of Frontier AI Models. https://www.crowell.com/en/insights/client-alerts/executive-order-creates-voluntary-regulatory-regime-of-frontier-ai-models (accessed 2026-06-10). ↩

B4. Atlantic Council (2026). Reading between the lines of Trump’s new executive order on AI. https://www.atlanticcouncil.org/dispatches/reading-between-the-lines-of-trumps-new-executive-order-on-ai/ (accessed 2026-06-10). ↩

B5. Council on Foreign Relations (2026). Assessing Trump’s Executive Order on AI Oversight. https://www.cfr.org/articles/assessing-trumps-executive-order-on-ai-oversight (accessed 2026-06-10). ↩

B6. CSO Online (2026). OpenAI responds to White House executive order on AI governance. https://www.csoonline.com/article/4181294/openai-responds-to-white-house-executive-order-on-ai-governance.html (accessed 2026-06-10).

B7. Open Source Initiative (2025). OSI and Apereo Foundation Respond to White House on AI Action Plan. https://opensource.org/blog/osi-and-apereo-foundation-respond-to-white-house-on-ai-action-plan (accessed 2026-06-10). ↩

C. Industry and Security Community

C1. CyberScoop (2026). Anthropic expanding access to Project Glasswing. 2026-06-02. https://cyberscoop.com/anthropic-project-glasswing-expansion-critical-infrastructure-claude-mythos/ (accessed 2026-06-10). ↩

C2. Help Net Security (2026). Anthropic: Claude Mythos identified 10,000+ software flaws. 2026-05-26. https://www.helpnetsecurity.com/2026/05/26/anthropic-project-glasswing-update/ (accessed 2026-06-10). ↩

C3. Schneier, Bruce (2026). On Anthropic’s Mythos Preview and Project Glasswing. Schneier on Security, 2026-04. https://www.schneier.com/blog/archives/2026/04/on-anthropics-mythos-preview-and-project-glasswing.html (accessed 2026-06-10). ↩

C4. HeroDevs (2026). AI Cybersecurity Executive Order 2026: What It Means for EOL Software. https://www.herodevs.com/blog-posts/ai-cybersecurity-executive-order-2026-what-it-means-for-eol-software (accessed 2026-06-10). — Cited with awareness that this is a commercial LTS vendor’s blog post. ↩

D. Related Analysis (This Blog)

D1. EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — An Investigative Report on Preparing for the 2026-09-11 Effective Date (updated 2026-06-09). ↩

D2. EU Open Source Strategy: Institutionalizing Open Source for Tech Sovereignty (2026-06-05). ↩

D3. AI-Generated Code: How Far Should Open Source Screening Go? (2026-06-08). ↩

The EU Open Source Strategy: Institutionalizing Open Source for Tech Sovereignty

Summary

The European Commission’s “Communication on European Tech Sovereignty” (COM(2026) 503 final), published on June 3, 2026, comes with an EU Open Source Strategy attached. It is the first time open source has been placed at the center of EU digital policy. The strategy sets four objectives — leveraging open source for sovereignty, strengthening the ecosystem, opening up public administration, and reinforcing standards and international cooperation — and calls for roughly EUR 2 billion in public and private funding to be mobilized for open-source-related measures over the next seven years. The aim is to reduce the EU’s dependence on US proprietary IT, on which it spends an estimated EUR 264 billion annually. Civil society (FSFE) and policy analysts have welcomed the direction while flagging limits: whether the funding is sufficient, how open standards relate to open source, the light treatment of open hardware, and the practitioner skills gap. For Korean public-sector and enterprise practitioners, the points worth watching directly are the opening of EU procurement, the open-source steward regulation, and the open-source default for the EUDI Wallet.

1. Overview

The Commission unveiled its technological sovereignty package in Brussels on June 3, 2026. A Communication is not binding legislation; it is a document setting out the Commission’s policy direction and planned follow-up actions.A1·A2 The package consists of four interlinked initiatives: the Chips Act 2.0 for semiconductors, the Cloud and AI Development Act (CADA), the Open Source Strategy, and a roadmap for digitalizing the energy sector and AI. This report covers only the Open Source Strategy, which forms Chapter 4 of the COM document.A1

The problem the strategy sets out to answer is clear. The Draghi Report found that the EU depends on non-EU suppliers for more than 80% of its digital products, services, infrastructure, and intellectual property.A1 The Open Source Strategy chose open source as the means to reduce that dependence. Europe, the birthplace of Linux, has more than three million open source contributors, and nearly half of all code commits come from companies with fewer than 50 employees. The asset base exists, but it faces structural limits in scaling and funding.A1

2. Core Content: Four Objectives

The strategy combines two tracks of action: supply-side measures that help EU communities and companies develop and maintain high-quality open source components, and demand-side measures that accelerate adoption across the private and public sectors. It pairs public funding with market- and demand-driven measures, and was built on more than 1,600 responses received through the Commission’s call for evidence.A1·B3

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 55}} }%%
flowchart TD
    ROOT["EU Open Source Strategy<br/>COM(2026) 503"]
    O1["Objective (i)<br/>Leveraging open source<br/>for sovereignty"]
    O2["Objective (ii)<br/>Strengthening and fostering<br/>a vibrant ecosystem"]
    O3["Objective (iii)<br/>Open and interoperable<br/>public administration"]
    O4["Objective (iv)<br/>Reinforcing standards and<br/>international cooperation"]
    ROOT --> O1 & O2 & O3 & O4
    O1 --> AC1["Open Internet Stack, open-sourcing<br/>EUID/EBW, 30M users by 2030"]
    O2 --> AC2["Business accelerators, stewardship<br/>toolkit, open source maintenance instrument"]
    O3 --> AC3["Public money, public code<br/>procurement reform, stronger OSPO network"]
    O4 --> AC4["Standardisation Regulation revision,<br/>Team Europe international cooperation"]
    style ROOT fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

Figure 1. The strategy’s four objectives and their headline measures (source: COM(2026) 503 final, Chapter 4, 2026-06-03)

Leveraging open source for sovereignty (Objective i). The Commission is expanding the Open Internet Stack into a shared catalogue of European open source building blocks, and has mobilized EUR 41.3 million across three calls under the Horizon Europe 2026–2027 work programme.A1 Open-sourcing the EU digital identity ecosystem is a core pillar. The EU Digital Identity Regulation (EUDIR) set a legal default requiring the application components of the EUDI Wallet to be open source; building on that, the Commission is developing open source reference implementations of the identity wallet (EUID) and the European Business Wallet (EBW), and transferring their long-term stewardship to the European Digital Public Infrastructure Foundation.A1 It will cooperate with member states through the European Digital Infrastructure Consortium (EDIC) on Digital Commons, with a target of reaching 30 million active users of open source collaboration, productivity, and secure email tools by 2030.A1

Strengthening the ecosystem (Objective ii). Open source building blocks are mostly maintained through foundations, and most of the funding for them comes from US and Chinese big tech.A1 The open source software steward concept introduced by the Cyber Resilience Act (CRA) is the regulatory backbone of this objective. The Commission is developing a stewardship toolkit to help establish foundations, and supporting the creation of a European Digital Public Infrastructure Stewards organization to govern EU-funded strategic assets from a single hub. To maintain and secure key components, it is also setting up an Open Source Maintenance Instrument to build European capacity to fork projects when necessary.A1

[!IMPORTANT] The “EUR 350 million for the Open Source Maintenance Instrument” figure often cited in outside analysis does not appear in the COM(2026) 503 text itself. It is the TechPolicy.Press authors’ own estimate of what the instrument would need; the original document attaches no figure.A1·E1 By contrast, “about EUR 500 million for RISC-V” does appear in Annex II, but it is recorded as a Chips Joint Undertaking investment and is separate from the Open Source Strategy’s EUR 2 billion budget.A1

Opening up public administration (Objective iii). The “public money, public code” principle has been explicitly written into the strategy.A1·B2 The Commission already runs the Matrix-based communication platform, the openDesk collaboration environment, and Drupal across more than 300 europa.eu sites.A1 On procurement, it is revising tendering guidelines so open source can compete with proprietary solutions, and strengthening the Open Source Programme Office (OSPO) and the EU Public Sector OSPO Network as a central hub.A1·B2

Standards and international cooperation (Objective iv). In its revision of the Standardisation Regulation, the Commission is improving cooperation between open source and standardization communities and creating conditions for certain standards to be implemented in open source. Through a Team Europe approach, it is deploying EU open source solutions to enlargement and partner countries.A1

Governance Structure

Rather than creating new bodies, the strategy weaves together existing governance assets. Three tracks come together.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 50}} }%%
flowchart TD
    EC["Commission OSPO<br/>(established 2020)"] --> NET["EU Public Sector OSPO Network<br/>(25 members, 11 countries)"]
    EDIC["Digital Commons EDIC<br/>(established 2025-10-29)"] --> FND["European Digital Public<br/>Infrastructure Foundation (in formation)"]
    NET --> FND
    FND --> ASSET["Long-term stewardship of strategic<br/>open source assets: EUID, EBW, etc."]
    style FND fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

Figure 2. How the strategy’s governance bodies connect (source: COM(2026) 503 final, Chapter 4 and Annex II, 2026-06-03; OSPO Network membership as of 2026-05)

The Commission OSPO (established 2020) and the EU Public Sector OSPO Network, with 25 members across 11 countries, cover the public-administration track, while the Digital Commons EDIC, established on October 29, 2025, covers the multi-country cooperation track.A1·A5 Both converge on the European Digital Public Infrastructure Foundation, now being established, which will take on long-term stewardship of strategic assets such as EUID and EBW.A1

3. Background and Context

The Open Source Strategy is not standalone regulation but a policy umbrella layered on several EU legal acts. The Interoperable Europe Act (Regulation (EU) 2024/903) defines “open source licence” and underpins public-sector reuse,A4 while the CRA (Regulation (EU) 2024/2847) provides the steward regulatory category and voluntary security attestation (Article 25).A3 The AI Act places proportionate obligations on free and open source models, and the EUDIR sets the open-source default for the EUDI Wallet.A1·C1

The watershed in this policy lineage is 2020. On October 21, 2020, the Commission adopted the “Open Source Software Strategy 2020–2023” (C(2020) 7149 final), introducing a “think open” culture, and its first action was to establish the Commission OSPO.A5 That was followed by code.europa.eu (4,500 users and 1,280 repositories as of May 2026) and the EU Open Source Solutions Catalogue (launched March 2025, 1,047 solutions).A1 The new strategy explicitly cites these as its foundation.

The “public money, public code” principle originated in a campaign the Free Software Foundation Europe (FSFE) launched in 2017. The strategy adopts the principle nine years after the campaign began.B4

4. Recent Developments and Timeline

Because the announcement is only days old, developments so far consist of the immediate reaction and the procedural steps ahead.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 35, 'rankSpacing': 45}} }%%
flowchart TD
    J["<b>2026-01-12</b> &nbsp; Call for evidence opens"]
    F["<b>2026-02-03</b> &nbsp; Call closes (1,600+ responses)"]
    P["<b>2026-06-03</b> &nbsp; COM(2026) 503 published"]
    D["<b>2026-12</b> &nbsp; National roadmaps revised"]
    S["<b>Later</b> &nbsp; Standardisation Regulation revision proposed"]
    J --> F --> P --> D --> S
    style P fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

Figure 3. Timeline of the EU Open Source Strategy (source: COM(2026) 503 final and Commission announcements, as of 2026-06-05)

On the day of the announcement, FSFE issued a cautious welcome. While welcoming the adoption of the “Public Money? Public Code!” principle, Johannes Näder said the Commission “still falls short on concrete goals, milestones, and secured funding,” and Lucas Lasota said “the question now is implementation, which requires secured long-term funding, meaningful civil society participation, and effective enforcement of the Digital Markets Act."B4

TechPolicy.Press’s policy analysis (Gates, Givropoulou, Karhu, 2026-06-03) called the strategy “Europe’s most significant open source advancement to date” while identifying four gaps.E1 The sequencing between open standards and open source remains unsettled, open hardware treatment is confined to RISC-V and EDA tools, the seven-year EUR 2 billion is modest against EUR 264 billion in annual dependence, and practitioner-level contribution, maintenance, and governance capacity-building remain weak. The law firm Covington also summarized the package’s investment scale and business impact on June 4, 2026.E3

The nature of the funding adds to the uncertainty. The EUR 2 billion is not a fixed budget allocation but a combined estimate of what public and private actors “should mobilize” over seven years.A1 The Open Source Maintenance Instrument, the European Digital Public Infrastructure Foundation, and the voluntary EU assessment framework are all at the stage of a commitment to “create,” with no concrete design or figures yet set.

On the timeline ahead, the package will feed into member states’ revision of their national Digital Decade strategy roadmaps in December 2026, and the proposed revision of the Standardisation Regulation together with the CADA and Chips Act 2.0 legislative processes will spell out open source requirements in more detail. The Commission will discuss progress annually in the Digital Decade Board and report to the European Parliament every three years.A1

5. Implications and Considerations

The strategy does not apply directly to Korean public institutions and companies, but there are several points worth watching in practice.

The opening of EU public procurement is the most concrete variable. If tender specifications come to include open standards and models and open source is allowed to compete with proprietary solutions, Korean software suppliers seeking to enter EU public markets will need open-source-friendly proposals and clear licensing to compete effectively.A1·B2 Conversely, this widens the opportunity for Korean companies whose business is built on open source to enter EU procurement.

The open source steward regulation is a point that companies bringing CRA-covered products to the EU market should watch. Security attestation for products relying on open source components (CRA Article 25) and the scope of steward responsibility are expected to be spelled out through the strategy’s voluntary EU assessment framework, so it is prudent to prepare a Software Bill of Materials (SBOM) and dependency management practices in advance.A1·A3 The fact that the EUDI Wallet and European Business Wallet default to open source reference implementations is something Korean fintech and identity verification providers considering EU digital identity integration should watch.A1

From the perspective of Korea’s public software policy, the institutionalization path for the “public money, public code” principle and the OSPO Network governance model are worth studying as reference models. That said, since the EU itself has left funding sufficiency and practitioner capacity as open questions, the gap between declaration and implementation is also worth watching.B4·E1

6. References

A. Primary Legal and Regulatory Texts

A1. European Commission (2026). Communication from the Commission on European Tech Sovereignty, accompanied by an EU Open Source Strategy. COM(2026) 503 final, Brussels, 3.6.2026 (main text and ANNEXES 1–2). The primary source for this report. sources/COM-2026-503-eu-tech-sovereignty.pdf and …-annexes.pdf. Download: https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy (accessed 2026-06-05). ↩

A2. European Commission (2026). Strengthening Europe’s tech sovereignty (press release). 2026-06-03. https://commission.europa.eu/news-and-media/news/strengthening-europes-tech-sovereignty-2026-06-03_en (accessed 2026-06-05). ↩

A3. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed 2026-06-05). ↩

A4. European Parliament and Council (2024). Regulation (EU) 2024/903 — Interoperable Europe Act. Official Journal, OJ L, 2024/903, 22.3.2024. https://eur-lex.europa.eu/eli/reg/2024/903/oj/eng (accessed 2026-06-05). ↩

A5. European Commission (2020). Open Source Software Strategy 2020–2023. C(2020) 7149 final, Brussels, 21.10.2020. https://commission.europa.eu/system/files/2023-02/en_ec_open_source_strategy_2020-2023.pdf (accessed 2026-06-05). ↩

B. Official Publications and Policy Pages from Issuing Bodies

B1. European Commission — Shaping Europe’s digital future (2026). The EU Open Source Strategy (policy page). Updated 2026-06-03. https://digital-strategy.ec.europa.eu/en/policies/open-source-strategy (accessed 2026-06-05).

B2. European Commission (2026). Commission boosts open and interoperable digital ecosystems for public administrations (press release). 2026-06-03. https://commission.europa.eu/news-and-media/news/commission-boosts-open-and-interoperable-digital-ecosystems-public-administrations-2026-06-03_en (accessed 2026-06-05). ↩

B3. European Commission — Shaping Europe’s digital future (2026). Commission opens call for evidence on Open-Source Digital Ecosystems. 2026-01-12 (closed 2026-02-03). https://digital-strategy.ec.europa.eu/en/news/commission-opens-call-evidence-open-source-digital-ecosystems (accessed 2026-06-05). ↩

B4. Free Software Foundation Europe (2026). EU Tech Sovereignty: A milestone for Public Code? Now implementation is key. 2026-06-03. https://fsfe.org/news/2026/news-20260603-01.en.html (accessed 2026-06-05). ↩

C. Standards and Frameworks

C1. European Commission (2024). Regulation (EU) 2024/1689 — Artificial Intelligence Act. Official Journal, OJ L, 2024/1689, 12.7.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng (accessed 2026-06-05). ↩

C2. European Parliament and Council (2023). Regulation (EU) 2023/2854 — Data Act. Official Journal, OJ L, 2023/2854, 22.12.2023. https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng (accessed 2026-06-05).

D. Academic and Policy Research

D1. Blind, K. et al. (2021). The impact of Open Source Software and Hardware on technological independence, competitiveness and innovation in the EU economy. European Commission. https://digital-strategy.ec.europa.eu/en/library/study-about-impact-open-source-software-and-hardware-technological-independence-competitiveness-and (accessed 2026-06-05).

E. Industry, Law Firm, and Media Analysis (Supplementary)

E1. Gates, N., Givropoulou, A., Karhu, J. (2026). How the EU’s Tech Sovereignty Package Finally Puts Open Source to the Test. TechPolicy.Press, 2026-06-03. https://www.techpolicy.press/how-the-eus-tech-sovereignty-package-finally-puts-open-source-to-the-test/ (accessed 2026-06-05). ↩

E2. TechPolicy.Press (2026). EU Unveils Sweeping Tech Sovereignty Push, Balancing Autonomy with Openness. 2026-06-03. https://www.techpolicy.press/eu-unveils-sweeping-tech-sovereignty-push-balancing-autonomy-with-openness/ (accessed 2026-06-05).

E3. Covington & Burling (2026). EU Tech Sovereignty Package. Global Policy Watch, 2026-06-04. https://www.globalpolicywatch.com/2026/06/eu-tech-sovereignty-package/ (accessed 2026-06-05). ↩

E4. Agence Europe (2026). European Commission seeks to harness open source in its tech sovereignty strategy and develop European alternatives. 2026-06. https://agenceurope.eu/en/bulletin/article/13877/4/european-commission-seeks-to-harness-open-source-in-its-tech-sovereignty-strategy-and-develop-european-alternatives (accessed 2026-06-05).

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

First, one thing to get straight

There is no quick yes-or-no answer to this question, because the deciding factor is not AI itself — as we will see. AI coding raises the rate at which code fragments enter a codebase without being declared as packages, but it does not change the conditions under which a license obligation arises. So instead of asking “does scanning still matter in the AI era,” it helps to ask “under what conditions does snippet-level scanning matter more, and under what conditions less.”

Snippet scanning and SCA are different things

First, separate the terms so the discussion does not get tangled.

Software Composition Analysis (SCA) refers broadly to identifying the open source that has entered your code and managing its vulnerabilities and licenses. Most SCA looks at declared dependencies, as in the first row of the table. Snippet-level matching is a separate capability that only some commercial tools have: it compares the source code itself against a vast number of open-source projects to find the origin of fragments that were never declared as packages. What this article addresses is not SCA as a whole, but this snippet matching.

How real is the legal risk?

Let us start with cases where AI code snippets led to license-violation disputes.

The best-known case is the Copilot class action filed in November 2022 by open-source developers against GitHub, Microsoft, and OpenAI. In May 2023 the copyright-infringement claim was dismissed for lack of specific examples of copying, and in July 2024 the claim under Section 1202(b) of the Digital Millennium Copyright Act (DMCA) was also dismissed. That provision prohibits removing the copyright management information attached to an original work; the court did not accept the claim, reasoning that Copilot’s output was not sufficiently identical to the original A2. Of the original 22 claims, only two remain: breach of an open-source license and breach of contract A2·A3.

There are facts here that can be read two ways.

On one hand, the defendants in these disputes have all been the vendors who built the AI tools, and there is no publicly reported case of a company being sued merely for using AI-generated code C1. Microsoft also announced, in September 2023, the Copilot Copyright Commitment, under which it will cover defense costs and damages if a paid commercial customer is sued by a third party over the output. This comes with conditions: the customer must not disable the product’s built-in filters and must not deliberately try to generate infringing material B1·C5.

On the other hand, the legal position is not settled. The DMCA issue above has gone to the Ninth Circuit Court of Appeals as an interlocutory appeal — where a specific issue is argued before the appellate court ahead of the trial-court judgment — and as of June 2026 no ruling has issued while the trial-court proceedings are stayed A1. The absence of a reported precedent does not mean there is no risk.

When does a license obligation arise?

One distinction matters here. Being sued and having an obligation to comply with a license are different things. Even if no one sues, the obligation to comply with an open-source license remains. And the moment when that obligation is triggered is what matters.

Copyleft obligations in the GPL family, which require disclosing source, arise when you distribute the software. Merely running it internally is “use,” not “distribution,” so no obligation arises C3·C4. Pure SaaS, which hands code to no one, is likewise outside GPL obligations for the same reason. Two caveats apply.

• AGPL is a stricter license that treats even providing a network service as distribution. If you use an AGPL-licensed component, an obligation to disclose source arises even when you only offer it as a service without handing over the code C3. Such components can be managed by excluding them through internal policy.
• “Internal” must mean used only by your own employees; if distribution later happens through an acquisition or open-sourcing, the problem arises at that point.

The copyrightability of short code is another factor. A few lines of functional code may involve too small an amount of copying to be actionable (de minimis), or may fall outside protection because there is essentially only one way to express the idea (merger doctrine) A4·A5. That said, this is a case-by-case judgment, and since long, creative blocks of code are protected, it is hard to assume every snippet is free.

In practice, small fragments often arrive carrying obligations. Code from Stack Overflow, which developers frequently reuse, is under the CC BY-SA license, which requires attribution and share-alike. Yet one study found that at most 1.8% of GitHub projects used such code in a way compliant with the license C6. Even a small fragment can carry a license obligation, and that obligation is widely unmet.

Does the standard require snippet scanning?

OpenChain ISO/IEC 5230, the international standard for open-source license compliance, focuses on where to place compliance processes, how to assign roles and responsibilities, and how to keep the process sustainable A6. It is a non-prescriptive standard that defines what to achieve while leaving the specific methods to the organization, so it does not mandate any particular technique such as snippet scanning A6·A7. What the standard requires is to identify third-party components and to maintain a Software Bill of Materials (SBOM), the list of those components. What matters for meeting the standard is understanding which components have entered the code; it does not require analyzing the origin of every single fragment. In fact, many widely used SCA tools operate only at the dependency level, without snippet matching.

This reads two ways. It means you can meet the standard without snippet scanning, and at the same time it means there is an area the standard does not cover. Dependency-level scanning cannot see fragments that were copied in or generated by AI without being declared as packages. Snippet matching fills exactly that gap, and some organizations perform it for more thorough intellectual-property management.

When does it matter more?

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

First, whether you hand code or binaries directly to customers. When code leaves the company — as with on-premises installed products, mobile apps, SDKs, or embedded device firmware — it counts as distribution, and copyleft obligations can be triggered. Pure SaaS, which hands over no code, carries less of this burden.

Second, whether you undergo external verification. Situations such as M&A due diligence, a large customer’s security audit, regulatory requirements, or an SBOM request that goes down to the snippet level — where someone outside the company actually examines the origin of the code.

The more these two overlap, the more likely a latent obligation turns into a real cost. If you hand over code but there is no occasion for verification, the risk stays latent; if you hand over no code, the obligation rarely arises in the first place. Both conditions are independent of whether AI is used. AI coding increases the inflow when the conditions hold, but it does not create the conditions.

Looking at it by company type

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 licenses used, and the company’s risk tolerance.

Embedded is a different story

Everything so far assumed software built with a package manager. Software that runs as embedded or firmware — routers, set-top boxes, IoT devices, automotive controllers — is different. It is mostly written in C/C++, and open source is often copied directly into the project as source, without a manifest. When that happens, dependency-level SCA has no manifest to read and sees almost none of the open source.

One thing to distinguish: large components used wholesale, such as the Linux kernel or BusyBox, are usually known to the company. That is not a detection problem but a question of meeting the obligation to disclose source. Snippet scanning is needed in a different case: the small fragments pulled in piecemeal from various open-source projects that no one put on a list. Finding these fragments, which dependency-level SCA cannot see, is the job of snippet scanning.

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

Filtering before code comes in

Apart from after-the-fact scanning, there is also a way to block problematic code before it comes in. GitHub Copilot has a setting that blocks suggestions matching public code: it does not show suggestions that match public code at or above a certain length (about 150 characters on average) B2·C2. GitHub has stated that verbatim copying of more than 150 characters happens about 1% of the time, while independent studies report higher rates depending on context. Either way it is not zero, but turning the setting on reduces the inflow of fragments of unclear origin. It costs almost nothing, and it is also a precondition for the vendor indemnity mentioned earlier.

This setting overlaps in purpose with after-the-fact snippet scanning. One finds code after it is in; the other blocks it before it gets in. Which one to use, and how much, is something to decide together with the conditions and costs above.

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. The only practical way to find code fragments that were copied in, or generated by AI, without being declared as packages is snippet matching. Neither dependency-level SCA nor a filter applied at generation time catches all of those fragments. So there is a small but real part that only snippet matching covers. At the same time, in many companies that small part rarely turns into an actual loss, and snippet scanning carries tool costs and review effort. In the end, it is about deciding whether the cost is worth it to close a small but real risk.

Four things to consider:

• Do you send code outside — the more you do, the greater the chance a copyleft obligation actually arises.
• Do you undergo external verification — M&A due diligence or a customer audit can surface an obligation that had been buried.
• How much license risk are you willing to accept — there is no reported lawsuit precedent, but the legal position is not settled either. How you take this uncertainty is a matter of company policy.
• What other checks do you already have — if you already run dependency-level SCA, an AI-tool setting that blocks suggestions matching public code, and a policy of excluding AGPL components, the part snippet scanning would additionally catch shrinks accordingly.

One more point. Snippet scanning is not an all-or-nothing choice. The occasions when someone outside actually examines the origin of code are fairly predictable — M&A due diligence or a large customer’s audit. So one option is to run only dependency scanning and the blocking setting day to day, and have a snippet scan done when such an occasion is expected.

Applying these four factors and this operating approach to your own situation, the answer to how much weight to give snippet scanning will come out differently for each 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 so far has been about licenses. Security vulnerabilities are a different axis, and you should not apply the conditional conclusion above to them. If vulnerable open source is in your code, it is dangerous whether or not you distribute, and whether or not you are audited — because it is exposed to attack even in internal-only software or a pure-SaaS backend. So vulnerability checking is broadly necessary for almost every company.

There are two main tools for security checking.

• Dependency-level SCA — looks at the name and version of declared open-source libraries and checks them against lists of known vulnerabilities (CVEs) D1. Known vulnerabilities in the libraries 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. The main security risk in AI code is here. In one study, about 40% of 1,689 programs generated by Copilot contained vulnerabilities D2.

Whether code was copied in or generated by AI, security checking is no different from any other code. SAST handles risky patterns in the code itself, and dependency-level SCA handles known vulnerabilities in the libraries you brought in. Snippet scanning is a feature for finding license origin, not a tool for security checking.

One exception worth noting: a rare case where vulnerable code with a known vulnerability is copied in verbatim, escaping both SAST’s patterns and the dependency list. Catching this requires not the license-oriented snippet feature but a separate check that compares your code directly against signatures of vulnerable code built from CVE patches — vulnerable code clone detection D3. Academic tools and some commercial tools provide this.

Sources

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

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 (license breach, breach of contract) remain. ↩

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). — Overall picture of the dismissed claims and the surviving claims. ↩

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 of 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, under which trivial copying is not actionable. ↩

A6. OpenChain Project. OpenChain ISO/IEC 5230 — License Compliance. https://openchainproject.org/license-compliance (accessed 2026-06-08). — The standard defines processes and roles but does not mandate any 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 record of the standard. ↩

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). — IP indemnity for paid commercial customers, conditioned on keeping the built-in filters on. ↩

B2. GitHub. GitHub Copilot (product page). https://github.com/features/copilot (accessed 2026-06-08). — Existence and behavior of the public-code matching filter. ↩

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). — Indication that defendants are concentrated among vendors and that no adopter company has been reported as 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 of the public-code matching filter and the ~1% copying 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). — Copyleft’s distribution trigger, the non-applicability to internal and SaaS use, and the AGPL §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). — Supporting detail 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). — Supporting detail on the scope and conditions of the indemnity. ↩

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). — Empirical study finding that at most 1.8% of GitHub projects used Stack Overflow code (CC BY-SA) in a license-compliant way. ↩

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 matching 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). — About 40% of 1,689 generated programs across 89 scenarios contained vulnerabilities. ↩

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). — How vulnerabilities propagate through copied code and remain unpatched after the upstream fix, and how to detect them. ↩

EU Cyber Resilience Act (CRA) Vulnerability Reporting Obligations — A Research Report for the 2026-09-11 Compliance Date

Summary

The EU Cyber Resilience Act (Cyber Resilience Act, CRA — Regulation (EU) 2024/2847) is the EU’s first comprehensive product security regulation, imposing horizontal cybersecurity obligations on every “product with digital elements” (PDE) placed on the EU market. The regulation entered into force on December 10, 2024, and applies in phases. From September 11, 2026, the Article 14 reporting obligations take effect, requiring manufacturers, importers, and distributors to notify ENISA (the European Union Agency for Cybersecurity) and Member State CSIRTs of actively exploited vulnerabilities and severe incidents within a staged 24-hour, 72-hour, and 14-day window. Companies that have not stood up a reporting workflow by this date face fines of up to €15 million or 2.5% of worldwide annual turnover, and Korean companies that place products on the EU market are subject to the obligation immediately. A1, B1, E1

1. Why 2026-09-11 Matters to Korean Companies

September 11, 2026, is the first application date for the CRA’s Article 14 reporting obligations. ENISA’s Single Reporting Platform (SRP) also goes live on this date. A1, B4 The CRA’s remaining essential obligations — CE marking and conformity assessment among them — are not due until December 11, 2027, but the reporting workflow has to be in place 15 months ahead of that.

For Korean companies, the weight of this date comes from the CRA’s legal character. The CRA is not a Directive that Member States transpose into national law; it is a Regulation with direct effect, applying the moment a product enters the EU market, with no national implementing legislation required. A1 A company headquartered in Korea with no EU legal entity, exporting directly, is not exempt. Legacy products — those already placed on the EU market — are covered as well, a point that also warrants attention. E1

As of June 2026, roughly three months remain before the reporting obligation takes effect. ENISA has said it will run a testing period but has not yet announced an official schedule, and has signaled that an operational manual will be available sometime in June 2026. ENISA has also stated explicitly that it does not currently offer an API for SRP integration. B4 Companies that assumed automated integration will need to redesign their reporting process around manual submission to the platform.

2. The Structure of the CRA

2.1 Legislative Background and Timeline

The CRA’s formal title is Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements. First signaled in Commission President Ursula von der Leyen’s State of the Union address in September 2021, the European Commission proposed the legislation on September 15, 2022. The European Parliament adopted it in plenary on March 12, 2024, by a vote of 517 to 12, the Council gave its final adoption on October 10 of the same year, it was signed on October 23, and it was published in the Official Journal of the EU on November 20. It entered into force on December 10, 2024. A1, B1

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 45}} }%%
flowchart TD
    A["<b>2021-09</b> &nbsp; President von der Leyen<br/>signals the CRA in her State of the Union"]
    B["<b>2022-09-15</b> &nbsp; European Commission<br/>proposes legislation (COM(2022)454)"]
    C["<b>2023-11-30</b> &nbsp; Provisional political agreement reached"]
    D["<b>2024-03-12</b> &nbsp; European Parliament plenary adoption<br/>(517 for, 12 against)"]
    E["<b>2024-10-10</b> &nbsp; Council final adoption"]
    F["<b>2024-12-10</b> &nbsp; Entry into force"]
    G["<b>2026-09-11</b> &nbsp; Article 14 reporting obligations<br/>take effect, SRP goes live"]
    H["<b>2027-12-11</b> &nbsp; CRA full application"]
    A --> B --> C --> D --> E --> F --> G --> H
    style G fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

Figure 1. CRA legislative and implementation timeline (source: Regulation (EU) 2024/2847, EC Legislative Train) A1, B1

The open source community’s public positioning during the legislative process was notable. During the 2022-2023 draft stages, the Eclipse Foundation, the Open Source Initiative (OSI), and The Document Foundation, among others, warned that an unclear definition of “commercial activity” could push compliance burdens onto volunteer developers. The provisional agreement of December 2023 introduced the concept of an “open-source steward” along with exemptions, easing some of that concern, but the scope of application to small-scale redistributors remains contested. D1

2.2 Scope of Application (Art. 2-3)

The CRA applies to “products with digital elements” (PDE). This covers hardware and software capable of logical or physical data connection to a device or network, and includes software components placed on the market independently. B3

Some products fall outside the scope. The main exclusions are free and open source software supplied without commercial activity, and products already subject to stricter sector-specific cybersecurity regulation, such as medical devices or automotive systems. Even where existing sector-specific cybersecurity rules apply, the CRA may still apply “complementarily,” so a sector-by-sector judgment is needed. A1, E2

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50}} }%%
flowchart TD
    A["Is the product placed on the EU market?"] -->|No| Z["Out of scope"]
    A -->|Yes| B["Is it a product with digital elements?"]
    B -->|No| Z
    B -->|Yes| C["Is there commercial activity?<br/>(includes commercial FOSS)"]
    C -->|No| Z2["Out of scope (non-commercial FOSS)"]
    C -->|Yes| D["Does a stricter sector-specific<br/>cybersecurity law already apply?<br/>(e.g., MDR for medical devices)"]
    D -->|Yes| Z3["Out of scope"]
    D -->|No| E["Subject to the CRA"]
    E --> F["Classification:<br/>default / important Class I /<br/>important Class II / critical"]

    style E fill:#fce4ec,stroke:#c2185b
    style F fill:#fce4ec,stroke:#c2185b

Figure 2. CRA applicability decision flow (source: CRA Art. 2-3, Implementing Regulation (EU) 2025/2392) A1, A3

2.3 Phased Implementation

The CRA does not enter into full application at a single point in time.

A1, B3

What has to be in place by September 11, 2026, is not product certification but a vulnerability and incident reporting workflow. CE marking and conformity assessment are due 15 months later, on December 11, 2027.

3. Manufacturer Obligations (Art. 13)

3.1 Annex I Essential Requirements

Article 13 requires manufacturers to meet the essential cybersecurity requirements set out in CRA Annex I. The requirements fall into two groups. A1, B3

Part I — Product security requirements: shipping with no known exploitable vulnerabilities, no default passwords, provision of security updates, application of least-privilege principles, data protection, minimization of the attack surface, resilience by design, and provision of records of access to and modification of personal data.

Part II — Vulnerability handling requirements: identifying and documenting vulnerabilities, maintaining an SBOM, providing patches promptly and free of charge, a Coordinated Vulnerability Disclosure (CVD) policy, reporting exploited vulnerabilities and incidents (Art. 14), and monitoring vulnerabilities across the product’s lifecycle.

No harmonized standards for these requirements have yet been finalized, so companies must implement directly against the CRA’s functional text in the meantime. The CRA Requirements Standards Mapping (2024), jointly published by ENISA and the JRC, maps the requirements to existing standards, with ISO/IEC 30111 (vulnerability handling), ISO/IEC 29147 (vulnerability disclosure), and NIST SP 800-218 (SSDF) serving as the main reference points. B5, C1, C2, C6

3.2 Support Period

Manufacturers must provide security support for the expected product lifetime after market placement, and for at least 5 years in any case. Products with an expected lifetime shorter than 5 years may use that shorter period as the support period. The support period must be clearly indicated on the product, and vulnerability handling and security updates are mandatory throughout it. A1, B3

3.3 SBOM Requirements

CRA Annex I Part II mandates a Software Bill of Materials (SBOM). Manufacturers must generate an SBOM for each release version and keep it in a machine-readable format so it can be produced on request from a Market Surveillance Authority. There is no obligation to disclose the SBOM to third parties, but it must be submitted to the Market Surveillance Authority when requested. A1

SPDX and CycloneDX have become the de facto standard formats. SPDX was standardized as ISO/IEC 5962:2021 (based on SPDX v2.2.1; the current specification is v3.0), C3, C4 and CycloneDX, a specification maintained by OWASP, published ECMA-424 2nd Edition (based on v1.7) on December 10, 2025. C5 As of June 2026, no CRA-level implementing act has established an official SBOM schema. Germany’s Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) published TR-03183-2 v2.1.0 in August 2025, which is the most practical reference point available today for mapping SBOM fields to CRA alignment. G1

4. Reporting Obligations (Art. 14) — In Effect from 2026-09-11

4.1 Notification Triggers

Article 14 defines two categories of event that trigger a manufacturer’s notification duty. A1, B2

The first is an actively exploited vulnerability. The trigger is not the mere theoretical existence of a vulnerability, but confirmation that an attacker has actually exploited it. The second is a severe incident — an event that has a significant impact on product security by causing, or being liable to cause, serious operational disruption, loss, or damage.

Importers and distributors, too, must notify the manufacturer when they discover non-compliance or become aware of an incident.

4.2 The Three-Tier Deadline (24h/72h/14d)

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50}} }%%
flowchart TD
    T0["Point of awareness<br/>(actively exploited vuln.<br/>or severe incident)"]
    T1["Within 24 hours — Early Warning"]
    T2["Within 72 hours — Notification"]
    T3["Within 14 days of mitigation<br/>becoming available — final report (vulnerability)"]
    T4["Within 1 month of notification<br/>— final report (incident)"]

    T0 --> T1 --> T2
    T2 --> T3
    T2 --> T4

    style T1 fill:#ffebee,stroke:#c62828
    style T2 fill:#fff3e0,stroke:#ef6c00
    style T3 fill:#e8f5e9,stroke:#2e7d32
    style T4 fill:#e8f5e9,stroke:#2e7d32

Figure 3. CRA Article 14 reporting deadlines (source: CRA Art. 14, EC “CRA — Reporting obligations”) A1, B2

The content required differs at each stage. A1, B2

The CRA text is explicit that the 24-hour deadline does not require the vulnerability to be classified or resolved by then; its purpose is to signal existence as an early warning. Micro and small enterprises may be exempted from fines for missing the 24-hour deadline. A1

4.3 The Single Reporting Platform (Art. 16)

All Article 14 notifications go through the Single Reporting Platform (SRP). Operated by ENISA, a single submission by the manufacturer is automatically routed to the coordinator CSIRT (Computer Security Incident Response Team) of the Member State where the manufacturer’s main establishment is located, and to ENISA. B4, A1

In procuring the SRP, ENISA required a forward-looking architecture capable of integrating with the incident and vulnerability reporting systems under NIS2 and DORA. The design goal is a platform that can interoperate with adjacent regulatory regimes, not just serve the CRA obligation on its own.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 55}} }%%
flowchart TD
    ID["Importer /<br/>Distributor"]
    M["Manufacturer"]
    SRP["ENISA SRP<br/>(Single Reporting Platform)"]
    CSIRT["Member State<br/>Coordinator CSIRT"]
    ENISA["ENISA"]
    OTHER_CSIRT["Other Member State<br/>CSIRTs"]
    MSA["Market Surveillance<br/>Authority (MSA)"]

    ID -->|"Notify on discovering non-compliance"| M
    M -->|"Art.14 24h/72h/14d"| SRP
    SRP --> CSIRT
    SRP --> ENISA
    CSIRT -->|"Dissemination<br/>(delay conditions apply)"| OTHER_CSIRT
    ENISA --> MSA
    MSA -->|"Corrective or recall order"| M

    style M fill:#e3f2fd,stroke:#1565c0
    style SRP fill:#fff3e0,stroke:#ef6c00
    style ENISA fill:#fff3e0,stroke:#ef6c00
    style CSIRT fill:#fff3e0,stroke:#ef6c00

Figure 4. Stakeholder interaction in the CRA reporting framework (source: CRA Art. 13-16, Delegated Regulation (EU) 2026/881) A1, A2

4.4 Conditions for Delaying Inter-CSIRT Dissemination (Delegated Regulation 2026/881)

Delegated Regulation (EU) 2026/881, adopted December 11, 2025 (published in the Official Journal April 20, 2026), sets out the conditions under which a Member State CSIRT may withhold immediate dissemination of a notification received via the Single Reporting Platform to other CSIRTs. A2 Delay is permitted where an assessment of the notified information’s nature justifies it, where the receiving CSIRT cannot guarantee the confidentiality of the information, or where the Single Reporting Platform itself has been compromised or is temporarily unable to operate. Beyond this, delay is allowed only for the period “strictly necessary,” and only when tools such as the Traffic Light Protocol (TLP) or the Permissible Actions Protocol (PAP) cannot mitigate the risk.

The 24-hour deadline for manufacturers reporting to a CSIRT is unaffected by this Delegated Regulation. What it addresses is the further dissemination step between CSIRTs, adding a security-based safety valve there.

4.5 Concurrent Application with GDPR and NIS2

CRA reporting obligations can arise alongside those of other regulations at the same time. When a vulnerability or incident compromises data that includes personal data, CRA notification does not replace the 72-hour supervisory authority notification obligation under Article 33 of the GDPR (General Data Protection Regulation). A5 The two notifications must go through separate channels and separate recipients — the data protection authority on one side, CSIRTs and ENISA on the other.

The same holds for operators of essential and important services subject to the NIS2 Directive (Directive (EU) 2022/2555) that become aware of a vulnerability or incident in their own products. Both CRA reporting and NIS2 reporting may be required simultaneously. The Digital Omnibus package’s “report once, share many” model is under discussion as a way to consolidate the two reporting obligations, but it has not yet been enacted into law. A4, E2

5. Conformity Assessment and CE Marking (2027-12-11)

Conformity assessment is due December 11, 2027, with the pathway determined by classification. Default-category products may self-assess, issue an EU Declaration of Conformity, and affix CE marking. Important Class I products may self-assess using EU harmonized standards, or opt for third-party evaluation by a Conformity Assessment Body (CAB). Important Class II and critical products require mandatory enhanced review by a CAB. A1, B3

In February 2025, ENISA published CRA Implementation via EUCC and its Applicable Technical Elements, analyzing how EU Common Criteria (EUCC) certification can be used as a pathway for CRA conformity assessment. B6

From June 11, 2026, the provisions on notification of conformity assessment bodies take effect. By this date, each Member State must designate a notifying authority, and the accreditation process for notified bodies to handle third-party conformity assessment must begin so that sufficient capacity is in place by December 11, 2026. B3

Penalties for non-compliance vary by violation type. The most serious violations — failure to meet essential requirements, and breach of the reporting obligations — can draw fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is greater, along with the possibility of an order to withdraw the product from the EU market. A1, E1

6. Mapping to Standards and Frameworks

The CRA specifies only essential requirements and delegates technical detail to harmonized standards. CEN/CENELEC JTC 13 WG 9 is developing European harmonized standards (EN) for the CRA, targeting publication of horizontal standards by August 30, 2026, and vertical standards by October 30, 2026. The horizontal standards take the form of the prEN 40000-1 series: vocabulary (prEN 40000-1-1), principles (prEN 40000-1-2), vulnerability handling (prEN 40000-1-3), and general security requirements (prEN 40000-1-4). The final list of cited standards has not yet been settled, so the table below can be used as a candidate mapping for now. B5

C1, C2, C3, C4, C5, C6, G1, C7

The European Vulnerability Database (EUVD) went live on May 13, 2025, operated by ENISA in implementation of Article 12 of the NIS2 Directive. F1 The EUVD can serve as a primary monitoring source under the CRA’s “vulnerability monitoring” requirement. It uses its own identifier scheme (EUVD-YYYY-NNNNNN) alongside CVE IDs and CVSS scores. It is a separate system from the SRP: the SRP is the channel through which manufacturers notify authorities, while the EUVD is a public database. B4, F2

7. Recent Developments (2025-2026)

Since entering into force in December 2024, the regulatory landscape has taken shape through delegated acts, implementing acts, and guidance documents.

Implementing Regulation (EU) 2025/2392 was adopted November 28, 2025, and entered into force December 21. It finalizes the technical definitions that sort the “important” and “critical” products referenced in CRA Annexes III and IV into 28 categories, distributed across Class I, Class II, and critical. This is the primary legal basis manufacturers use to determine their product’s conformity assessment pathway. A3

Delegated Regulation (EU) 2026/881 was adopted December 11, 2025, and published in the Official Journal on April 20, 2026. It codifies the conditions under which inter-CSIRT dissemination of notifications may be delayed (see §4.4). A2

Guidance has arrived in two stages. The Commission’s first official FAQ was issued December 3, 2025 (updated December 19), setting out — non-bindingly, but for the first time — the scope and recurrence of risk assessment and the concept of “intended purpose.” That was followed by the first draft guidance under CRA Article 26, published March 3, 2026. Roughly a quarter of its 75 pages is devoted to defining open-source stewards, and it also covers remote data processing solutions, free and open source software, the support period, and the interplay between the CRA and other regulations such as NIS2 and DORA. The comment period closed March 31, but as of June 2026 no final version had been published. E3

The open source community’s collective response became visible on April 2, 2024, when seven foundations — the Apache Software Foundation, the Blender Foundation, the Eclipse Foundation, OpenSSL, the PHP Foundation, the Python Software Foundation, and the Rust Foundation — announced they would jointly develop common standards for secure software development. The effort was led by the Eclipse Foundation AISBL in Brussels and grew, on September 24 of the same year, into the Open Regulatory Compliance Working Group (ORC WG), which published a white paper setting out the scope of a steward’s obligations. OpenSSF published its direction for aligning SBOM standards on October 22, 2025. F3, D1

The most persistent point of contention is whether the 24-hour notification requirement actually works. Security researchers, including HackerOne, have repeatedly argued since 2024 that notifying authorities of a vulnerability’s existence before a patch is ready risks exposing an unmitigated vulnerability. E4 Delegated Regulation (EU) 2026/881 only introduced conditions for delaying dissemination between CSIRTs; it left the manufacturer-to-CSIRT 24-hour deadline itself untouched.

8. A Korean Company’s Perspective — What to Do in the Next Three Months

8.1 Determining Applicability

The first step is confirming whether the reporting obligation due September 11, 2026, applies to your company at all. Work through the questions in order: is the product placed on the EU market, is it a product with digital elements, and is a stricter sector-specific cybersecurity law already in force for it? “Placed on the EU market” covers direct sales, resale, and OEM supply alike, and applies even without an EU legal entity if a Korean headquarters exports directly. Any software or hardware capable of data connection to a network or device qualifies as a product with digital elements. If a stricter regime already applies — medical device or automotive safety regulation, for example — the CRA may not apply.

Legacy products are covered too. Many companies overlook that products already placed on the EU market also become subject to the reporting obligation from September 11. E1

8.2 Preparation Steps

No certificate is required by September 11. What is required is a reporting workflow. There must be a human structure and technical connection in place to issue an early warning within 24 hours of becoming aware of a vulnerability or incident, with an on-call rotation, decision-making authority, and a designated external communications contact set up in advance.

A pipeline that automatically generates and retains an SBOM in SPDX or CycloneDX format for every release version is also needed by September 11. BSI TR-03183-2 v2.1.0’s field mapping can serve as a practical reference point. G1

ENISA has stated that it does not currently offer an API for SRP integration (as of June 2026). An operational manual has been promised for release sometime in June, so companies should build a process for manual submission to the platform rather than assuming automated integration, and watch for ENISA’s manual and testing-period announcements.

A process for monitoring the EUVD (https://euvd.enisa.europa.eu) against your company’s own product components is also needed, with the ability to handle both the CVE ID and EUVD-YYYY-NNNNNN identifier schemes.

By December 11, 2027, another step is required: CE marking, conformity assessment, selection of a CAB matching the product’s classification (for Class I and above), and a declaration of conformity once the harmonized standards are published. Companies should track the publication of CEN/CENELEC’s horizontal standards (targeted for 2026-08-30) and vertical standards (targeted for 2026-10-30).

8.3 Comparison with Other Jurisdictions

C6, E2

The CRA’s most distinctive feature is its horizontal application across IoT, software, and embedded systems, combined with direct effect. Korea’s Software Supply Chain Security Guideline 1.0, built on the NIST SSDF, recommends 30 checklist items and an SBOM procedure; because the CRA’s essential requirements align functionally with the SSDF, a system built to the domestic guideline is a reasonable starting point for CRA readiness. That said, the Korean guideline is advisory while the CRA is a legal obligation backed by a fine regime, and the CRA layers a separate reporting obligation on top of it.

9. Conclusions and Recommendations

September 11, 2026, is the date the CRA first imposes a substantive compliance obligation on manufacturers. CE marking and conformity assessment are not due until December 11, 2027, but the reporting workflow has to be complete before then.

For a Korean company, the first priority is confirming whether its products fall under the CRA, and if so, determining which classification — default, important, or critical — applies, using Implementing Regulation (EU) 2025/2392 as the basis. Classification determines the 2027 conformity assessment pathway and how much lead time it requires.

Building the reporting infrastructure and internal playbook comes next. The SRP operational manual has not yet been published, but the human structure and internal procedures can be designed now regardless. Since ENISA has said it will not provide an integration API, companies should set up a manual submission process for the platform and watch for the manual and testing-period announcements.

SBOM pipeline automation needs to be finished by September 11. Without an SBOM automatically generated and retained in SPDX or CycloneDX format for every release version, the software composition information the reporting obligation requires simply will not exist. A1, B2, E2, E4

References

A. Legislative and Regulatory Text (Primary)

A1. European Parliament and Council (2024). Regulation (EU) 2024/2847 of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed: 2026-05-12). ↩

A2. European Commission (2025). Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 supplementing Regulation (EU) 2024/2847 with regard to the conditions for delaying dissemination of notifications of actively exploited vulnerabilities and severe incidents. Published 20 April 2026. https://eur-lex.europa.eu/eli/reg_del/2026/881/oj (accessed: 2026-05-12). ↩

A3. European Commission (2025). Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 laying down technical descriptions of categories of important and critical products with digital elements. OJ L, 2025/2392. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202502392 (accessed: 2026-05-12). ↩

A4. European Parliament and Council (2022). Directive (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2 Directive). OJ L 333, 27.12.2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng (accessed: 2026-05-12). ↩

A5. European Parliament and Council (2016). Regulation (EU) 2016/679 — General Data Protection Regulation (GDPR). OJ L 119, 4.5.2016. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 (accessed: 2026-05-12). ↩

B. Official Documents from Issuing Bodies

B1. European Commission, DG CNECT (2026). Cyber Resilience Act — Shaping Europe’s digital future. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (accessed: 2026-05-12). ↩

B2. European Commission, DG CNECT (2026). Cyber Resilience Act — Reporting obligations. https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (accessed: 2026-05-12). ↩

B3. European Commission, DG CNECT (2024). The Cyber Resilience Act — Summary of the legislative text. https://digital-strategy.ec.europa.eu/en/policies/cra-summary (accessed: 2026-05-12). ↩

B4. ENISA (2026). Single Reporting Platform (SRP). https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp (accessed: 2026-05-12). ↩

B5. ENISA & Joint Research Centre (2024). Cyber Resilience Act Requirements Standards Mapping — Joint Analysis. April 2024. https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping (accessed: 2026-05-12). ↩

B6. ENISA (2025). Cyber Resilience Act implementation via EUCC and its applicable technical elements. 26 February 2025. https://certification.enisa.europa.eu/publications/cyber-resilience-act-implementation-eucc-and-its-applicable-technical-elements_en (accessed: 2026-05-12). ↩

C. Standards and Frameworks

C1. ISO/IEC (2019). ISO/IEC 30111:2019 — Information technology — Security techniques — Vulnerability handling processes. Edition 2. https://www.iso.org/standard/69725.html (accessed: 2026-05-12). ↩

C2. ISO/IEC (2018). ISO/IEC 29147:2018 — Information technology — Security techniques — Vulnerability disclosure. Edition 2. https://www.iso.org/standard/72311.html (accessed: 2026-05-12). ↩

C3. ISO/IEC (2021). ISO/IEC 5962:2021 — Information technology — SPDX® Specification V2.2.1. https://www.iso.org/standard/81870.html (accessed: 2026-05-12). ↩

C4. The Linux Foundation / SPDX Project (2024). SPDX Specifications (current: v3.0). https://spdx.dev/specifications/ (accessed: 2026-05-12). ↩

C5. OWASP Foundation / Ecma International (2025). CycloneDX Specification v1.7 / ECMA-424, 2nd Edition. ECMA-424 published 2025-12-10. https://cyclonedx.org/specification/overview/ (accessed: 2026-05-12). ↩

C6. Souppaya, M., Scarfone, K., Dodson, D. — NIST (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST SP 800-218. DOI: 10.6028/NIST.SP.800-218. https://csrc.nist.gov/publications/detail/sp/800-218/final (accessed: 2026-05-12). ↩

C7. OpenSSF Global Cyber Policy Working Group (2026). CRA Standards Map. https://policy.openssf.org/CRA/standards.html (accessed: 2026-06-09). — Used to confirm the numbering and progress of CEN/CENELEC JTC 13 WG 9’s prEN 40000-1 series (horizontal harmonized standards). ↩

D. Academic and Policy Research

D1. OpenSSF Best Practices WG / Global Cyber Policy WG (2025). Cyber Resilience Act (CRA) Brief Guide for Open Source Software (OSS) Developers. Lead author: David A. Wheeler. https://best.openssf.org/CRA-Brief-Guide-for-OSS-Developers.html (accessed: 2026-05-12). ↩

E. Industry and Law Firm Analysis

E1. Bird & Bird LLP (2026). CRA’s phased entry into application starts in September 2026. Bird & Bird Insights. https://www.twobirds.com/en/insights/2026/cra%E2%80%99s-phased-entry-into-application-starts-in-september-2026 (accessed: 2026-05-12). ↩

E2. DLA Piper — Blum, L. & Moylan Burke, L. (2026). Cyber Resilience Act: What you need to know and what you need to be doing. 19 February 2026. https://www.dlapiper.com/en/insights/publications/2026/02/cyber-resilience-act-what-you-need-to-know-and-what-you-need-to-be-doing (accessed: 2026-05-12). ↩

E3. DLA Piper (2026). Cyber Resilience Act: Commission unveils draft implementation guidance. Law in Tech. https://www.dlapiper.com/en-us/insights/publications/law-in-tech/2026/cyber-resilience-act (accessed: 2026-05-12). ↩

E4. HackerOne — Eldering, B. (2026). EU Cyber Resilience Act: Preparing Your VDP for 2026 Reporting Requirements. https://www.hackerone.com/blog/cyber-resilience-act-vdp-2026-reporting-readiness (accessed: 2026-05-12). ↩

F. Press and Official Announcements (Supplementary)

F1. ENISA (2025). Consult the European Vulnerability Database to enhance your digital security! News release, 13 May 2025. https://www.enisa.europa.eu/news/consult-the-european-vulnerability-database-to-enhance-your-digital-security (accessed: 2026-05-12). ↩

F2. European Commission (2025). EU launches a European vulnerability database to boost its digital security. https://digital-strategy.ec.europa.eu/en/news/eu-launches-european-vulnerability-database-boost-its-digital-security (accessed: 2026-05-12). ↩

F3. Eclipse Foundation (2024). The Open Source Community is Building Cybersecurity Processes for CRA Compliance. Life at Eclipse, 2 April 2024. https://eclipse-foundation.blog/2024/04/02/open-source-community-cra-compliance/ (accessed: 2026-05-29). ↩

G. Member State Agency Technical Guides

G1. Bundesamt für Sicherheit in der Informationstechnik (BSI) (2025). Technical Guideline TR-03183-2 v2.1.0 — Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials (SBOM). August 2025. Summarized in: Sbomify, EU Cyber Resilience Act (CRA) SBOM Requirements. https://sbomify.com/compliance/eu-cra/ (accessed: 2026-05-12). ↩

Rockchip and FFmpeg: A License Dispute Case Study

Hello.

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

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

1. Overview of the Incident

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

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

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

Timeline

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

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

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

2. What Was Copied

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

Copyright Header Replacement

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

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

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

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

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

Matching Function Bodies

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

FFmpeg libavcodec/vpx_rac.h:

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

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

    return bit;
}

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

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

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

    return bit;
}

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

Traces Left in the Code

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

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

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

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

/**
 * vp56 specific range coder implementation
 */

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

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

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

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

The Probability Tables Are a Somewhat Different Matter

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

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

libvpx:

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

FFmpeg:

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

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

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

3. Why It Took 22 Months

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

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

Rockchip later revealed the reason for the delay.

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

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

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

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

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

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

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

4. Rockchip’s Response and Remaining Issues

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

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

Still, a few things remain.

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

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

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

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

5. Why License Laundering Is Dangerous

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

Mapping each violation to the relevant clause looks like this.

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

What the Correct Structure Looks Like

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

Figure 2. Comparison of hardware acceleration integration structures

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

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

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

6. The Allwinner Case, Ten Years Earlier

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

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

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

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

7. What Companies Should Check

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

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

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

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

Summary

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

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

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

References

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

Revised on July 23, 2026 to reflect subsequent developments.

2025

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

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

1. Case Overview

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

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

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

Disclaimer:

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

2. Background and Progress of the Lawsuit

Background

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

Legal Basis of the Lawsuit

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

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

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

Progress of the Lawsuit

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

The Plaintiff’s Claims

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

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

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

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

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

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

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

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

3. Summary of the Ruling

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

4. Implications and Various Interpretations

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

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

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

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

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

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

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

2024

What the Oracle v. Rimini Street Case Tells Us About the Scope of GPL Derivative Works

Introduction

In disputes over software intellectual property infringement, the concept of “derivative works” is critically important. This concept becomes a central issue especially when dealing with open source licenses such as the GNU General Public License (GPL). The recent litigation between Oracle and Rimini Street has drawn renewed attention to the legal interpretation of what counts as a derivative work. This article looks at the background of the case, the key rulings, and the implications for open source licensing.

Background of the Case

PeopleSoft and Rimini Street

PeopleSoft is an ERP (Enterprise Resource Planning) software product from Oracle that supports functions such as human resources management, financial management, and supply chain operations for businesses. PeopleSoft receives regular updates, and Oracle provides these updates to customers as part of its maintenance services.

Rimini Street is a company that provides third-party maintenance services to Oracle customers. Rimini operated by generating PeopleSoft updates on behalf of customers, then modifying or distributing them for deployment to customer systems. In the course of this, Oracle alleged that Rimini had violated its copyrights and license terms, and filed suit.

The Legal Battle

Initial Ruling: Problems with Process 1.0

In 2015, the court ruled that the initial operating method Rimini Street used (Process 1.0) infringed Oracle’s copyrights. The main problems were as follows:

1. Cross-use: Distributing an update generated in one customer’s environment to another customer.
2. Use of Oracle PeopleTools: Generating updates using Oracle’s own software tools.
3. Copying and distribution: Copying and modifying PeopleSoft files and providing them to multiple customers.

The court found that this approach violated Oracle’s license terms and constituted copyright infringement.

The Introduction of Process 2.0 and New Disputes

Starting in 2018, Rimini Street discontinued its previous approach and introduced a new process, Process 2.0. Process 2.0 has the following characteristics:

• Work within the customer’s environment: All update generation and testing is performed within each customer’s own PeopleSoft environment.
• Limited use of automation tools: Automation tools used previously were minimized or removed.
• Preventing cross-use: Data and work product are kept separate between customers to prevent cross-use issues.

Oracle nonetheless argued that copyright infringement continued to occur under Process 2.0. The main issues were that Rimini performed some work on its own servers and that updates generated in one customer’s environment were passed on to another customer.

The 2023 Ruling by the Federal District Court of Nevada

In July 2023, the Federal District Court of Nevada found that Rimini Street continued to infringe Oracle’s copyrights even under Process 2.0. The court identified the following problems with Rimini’s approach:

1. Some work was still performed on Rimini’s own servers.
2. Cross-use occurred during the distribution of updates.
3. The automation tools Rimini developed were closely tied to Oracle’s software.

Accordingly, the court issued a permanent injunction against Rimini.

The 2024 Appellate Ruling

In December 2024, the Ninth Circuit Court of Appeals reversed part of the Nevada district court’s decision and set out a new legal standard:

1. Narrowing the definition of a derivative work:
   • For a work to be a derivative work, Oracle’s work must be substantially incorporated into it, either literally or nonliterally.
   • Merely interacting with or being compatible with PeopleSoft is not, by itself, sufficient to establish a derivative work.
2. Reconsidering the cross-use question:
   • The court remanded the question of whether transferring an update generated in one customer’s environment to another customer violated the license terms, for the district court to reconsider.
3. Possible viability of a §117(a) defense:
   • The appellate court found that Rimini may have the right, under §117(a), to make copies on behalf of Oracle customers, and ordered this to be reconsidered as well.

GPL and Derivative Works

How the GPL Interprets Derivative Works

The GNU General Public License (GPL) defines derivative works broadly. It has a “viral” characteristic in that any work combined with GPL-licensed software must also follow the terms of the GPL. According to the GPL FAQ, a work may be considered a derivative work in the following cases:

1. Modifying code: Directly modifying the source code of GPL-licensed software
2. Incorporating code: Including part of the code of GPL-licensed software in one’s own program
3. Linking: Statically or dynamically linking against a GPL-licensed library
4. Plugins or extensions: Developing a plugin or extension for GPL-licensed software

Contrast with the Oracle v. Rimini Ruling

In this ruling, the appellate court offered a narrower interpretation of what counts as a derivative work:

1. Mere interaction or compatibility does not, by itself, establish a derivative work.
2. A work is recognized as a derivative work only when the code or expression of the original software is “substantially incorporated.”

This could spark legal debate over the scope of GPL applicability, and could have a significant effect on where the line is drawn between open source and commercial software.

Positive Aspects and Remaining Challenges

This ruling could have the following positive effects:

1. Clarifying the definition of a derivative work, reducing unnecessary legal disputes.
2. Giving third-party maintenance service providers greater latitude.

Even so, challenges remain to be resolved:

• Static/dynamic linking: Whether a program statically or dynamically linked against a C library is a derivative work of that library remains unclear. This may depend on how “substantial” the content of the library’s header files is.
• Clarifying the rules governing interaction between open source projects and commercial software.

Closing

In Oracle v. Rimini, the court’s narrower reading of the concept of a “derivative work” gave developers greater freedom, but it also opened the possibility of weakening the reach of open source licenses.

This ruling is a reason for developers to examine the license terms they use more carefully, and it is important to adopt independent design approaches to reduce the risk of legal disputes. Open source is a powerful tool for innovation and collaboration, but it also comes with rules that must be followed.

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

Introduction

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

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

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

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

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

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

1. Product Liability Directive (PLD)

1.1 Overview

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

1.2 Key Changes

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

1.3 Scope of Application

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

1.4 Key Obligations

1.5 Implementation Timeline

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

1.6 Impact on Companies

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

2. Cyber Resilience Act (CRA)

2.1 Overview

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

2.2 Scope of Application

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

2.3 Key Requirements

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

2.4 Implementation Timeline

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

2.5 Impact on Companies

2.6 Company Response Measures

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

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

3. AI Act

3.1 Overview

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

3.2 Classification of AI Systems

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

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

3.3 Key Requirements

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

3.4 Implementation Timeline

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

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

3.5 Impact on Companies

3.6 Company Response Measures to Prepare for Implementation

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

3.7 Key Features and Significance of the AI Act

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

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

4. Interrelationship Among the Three Laws

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

4.1 Common Regulatory Purposes

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

4.2 Overlapping Scope of Application

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

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

4.3 The Need for an Integrated Approach

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

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

5. Recommendations for Korean Companies

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

5.1 Form a Regulatory Compliance Task Force

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

5.2 Review the Product and Service Portfolio

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

5.3 Strengthen Documentation and Transparency

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

5.4 Strengthen the Risk Management Framework

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

5.5 Build Human Capacity

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

5.6 Reassess R&D and Innovation Strategy

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

5.7 Adjust the Business Model and Strategy

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

5.8 Strengthen Stakeholder Communication

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

6. Conclusion

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

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

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

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

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

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

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

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

Background

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

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

CommonCrawl

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

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

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

LAION’s Data Processing

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

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

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

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

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

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

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

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

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

The Start of the Lawsuit

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

Legal Issues

The core issues of this lawsuit are as follows:

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

The Impact of the EU Copyright Directive

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

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

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

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

The Ruling

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

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

Significance of the Ruling

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

Future Outlook

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

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

Implications for Domestic AI Companies

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

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

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

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

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

Parties to the Lawsuit

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

Overview of the Case

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

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

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

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

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

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

Progress of the Lawsuit

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

The Defendants’ Arguments

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

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

The Court’s Ruling

First-Instance Judgment

The Suzhou Intermediate People’s Court ruled as follows:

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

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

The Supreme People’s Court’s Ruling

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

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

Significance of the Ruling

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

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

Similarity to the WordPress Theme Case

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

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

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

Implications for Corporate Open Source Management

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

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

Conclusion

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

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

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

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

References

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

Elasticsearch Changes Its License Again: How Should Companies Respond?

Introduction: The Background of the Elasticsearch License

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

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

1. History of Elasticsearch License Changes

1.1 The Shift from Apache 2.0 to Elastic License 2.0

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

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

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

1.2 Elastic License 2.0 Is Not an Open Source License

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

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

2.1 Key Characteristics of AGPL-3.0

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

The key characteristics of AGPL-3.0 are as follows:

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

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

2.2 Why Elastic Returned to AGPL-3.0

The reasons Elastic chose AGPL-3.0 are as follows:

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

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

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

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

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

3.1 Monitoring License Changes

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

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

3.2 Providing Training and Internal Guidelines

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

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

3.3 Responding to AGPL-3.0 in Cloud Environments

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

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

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

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

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

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

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

Introduction to SPDX 3.0 and Enterprise Adoption Strategy

1. Introduction to SPDX 3.0

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

Definition and Purpose of SPDX

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

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

Key Changes in SPDX 3.0

SPDX 3.0 brings significant changes compared to previous versions:

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

Significance of SPDX 3.0

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

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

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

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

2. Key Features of SPDX 3.0

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

Modular Structure

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

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

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

Improved Extensibility

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

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

Support for Various Use Cases

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

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

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

Enhanced Data Model

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

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

Compliance with International Standards

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

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

These key features of SPDX 3.0 greatly improve the transparency, security, and compliance of the software supply chain, and meet modern software development and management requirements.

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

3. SPDX 3.0 Profiles

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

Core Profile

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

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

Software Profile

The Software Profile provides detailed information related to software packages.

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

Security Profile

The Security Profile covers security-related information about software.

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

License Profile

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

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

Build Profile

The Build Profile provides information about the software build process.

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

AI/ML Profile

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

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

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

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

4. SPDX 3.0 Data Model

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

Key Entities and Relationships

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

Identifier Scheme

SPDX 3.0 introduces a more robust and flexible identifier scheme:

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

Metadata Management

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

Extensibility Mechanisms

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

Data Types

SPDX 3.0 supports various data types:

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

Serialization Formats

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

• JSON-LD
• YAML
• RDF
• XML

This support for multiple formats facilitates integration with other systems.

Profile Support

The data model is designed to support various profiles:

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

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

5. SPDX 3.0 Implementation Guide

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

Tools and Libraries

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

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

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

File Formats (JSON, YAML, RDF)

SPDX 3.0 supports various file formats:

1. JSON-LD

   • The most recommended format

   • Example:

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

2. YAML

   • A human-readable format

   • Example:

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

3. RDF

   • Suitable for semantic web applications

   • Example:

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

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

Migrating from Existing SPDX 2.x

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

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

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

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

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

6. SBOM and SPDX 3.0

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

SBOM Generation and Management

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

Improving SBOMs with SPDX 3.0

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

Meeting NTIA Minimum Requirements

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

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

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

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

7. Security and Vulnerability Management

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

CVE Information Integration

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

1. How to reference CVEs

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

   • Example:

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

2. Inclusion of detailed CVE information

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

3. Automatic CVE updates

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

4. Linking CVE information to components

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

Vulnerability Tracking and Reporting

SPDX 3.0 provides features for effectively tracking and reporting vulnerabilities.

1. Vulnerability lifecycle management

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

   • Example:

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

2. Vulnerability severity assessment

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

   • Example:

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

3. Vulnerability report generation

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

4. Vulnerability trend analysis

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

Utilizing the Security Profile

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

1. Security Profile structure

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

2. Example use of the Security Profile

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

3. Ways to utilize the Security Profile

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

4. Security metric tracking

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

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

8. License Compliance

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

License Information Management

1. License identifiers

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

2. Inclusion of license text

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

   • Example:

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

3. Custom licenses

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

4. License expressions

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

5. File- and package-level licenses

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

License Compatibility Checking

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

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

Compliance Report Generation

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

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

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

9. SPDX 3.0 Use Cases

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

Software Supply Chain Security

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

Open Source Management

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

Regulatory Compliance

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

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

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

10. SPDX 3.0 Adoption Strategy

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

Phased Implementation Plan

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

Training and Awareness Within the Organization

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

Tips for Successful Adoption

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

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

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

11. Future Outlook and Direction

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

SPDX Community Participation

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

Future Updates and Improvements

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

Global Standardization Trends

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

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

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

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

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

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

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

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

Hello.

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

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

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

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

What Is GPL?

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

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

Plaintiff: Entr’Ouvert

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

Lasso is currently offered under two licenses.

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

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

https://lasso.entrouvert.org/

Defendant: Orange

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

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

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

The Ruling

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

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

Takeaways

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

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

References

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

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

I’ll update it right away. ^^

2023

Checklist for Preparing an In-Person Meeting

Hello. Last March 28 was a time everyone will remember. It was our first in-person meeting in three years, since before COVID. Having gone so long without one, I learned that hosting a venue takes more miscellaneous preparation than I expected.

We’ll hold another in-person meeting like this at some point, so drawing on this experience, I put together a checklist for preparing one. (The next host might end up being me again… oops, better not jinx it!)

Before the Meeting

A list of tasks worth doing before the meeting. It includes work the Planning Sub-group should handle.

• Set the date and time of the meeting
• Recruit speakers
• Collect advance registrations — a Google Form is recommended (to gauge how large a venue you’ll need and to collect information needed for building access)
• Check the visitor access procedure and pre-register visitors if required
• Check visitor parking arrangements
• Check whether visitors may bring electronic devices
• Check what wireless internet is available to visitors
• Prepare name badges for attendees (so names and affiliations are easy to recognize)
• Prepare venue guidance slides
• Send a guidance email about visiting the venue
• Check the venue and confirm equipment (desks, chairs, speaker laptop, microphone, sound system, projector, laser pointer, etc.)
• Prepare a budget for refreshments and giveaways if needed

Day of the Meeting

A list of tasks to complete on the day of the meeting, before it starts.

• Put up event signage (to guide other employees nearby)
• Check the microphone, sound system, and projector setup and connections
• Prepare the presentation laptop
• Set up the venue, adding chairs if needed
• Post Wi-Fi instructions (print them out and place them in the venue)
• Set up a table for handing out name badges
• Prepare refreshments if needed
• Have company introduction materials on hand if needed
• Guide attendees in and direct them to their seats

After the Event

A list of tasks to complete after the event ends.

• Guide attendees out (returning visitor badges, settling parking)
• Take down event signage
• Tidy up the venue

That covers the memorable points I’ve drawn on to put together this checklist. I hope it helps with preparing future events. If I learn anything new from a future event, I’ll update the list again.

Thank you.

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

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

OpenChain Korea Work Group

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

OpenChain KWG Regular Meetings

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

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

17th Meeting (In-Person)

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

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

Part 1: Session Presentations

OpenChain Global Update (Linux Foundation, Shane Coughlan)

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

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

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

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

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

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

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

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

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

Part 2: Mini Summit - Open Source Management Automation Tools

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

Dependency Analysis Methods by Tool (Kakao, Hyunji Lim)

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

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

OSORI (LG Electronics, Soim Kim)

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

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

FOSSLight Roadmap (LG Electronics, Kyungae Kim)

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

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

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

OLIVE Platform is an open source license verification service developed by Kakao, which anyone can use for free with just a Kakao account, or a GitHub, Google, or Facebook account.

Eunkyung Hwang of Kakao introduced the key features of the OLIVE Platform.

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

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

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

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

Closing

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

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

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

Until then, happy days to everyone!

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

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

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

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

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

OpenChain Project Global Community

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

Platinum Members

Community Structure

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

OpenChain Standard

ISO/IEC 5230:2020, ISO/IEC 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 18974 is the de facto standard for open source security assurance compliance, and is scheduled to be formally registered as an ISO standard in the second half of 2023.

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

Self-Certification

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

Adoption of OpenChain ISO/IEC 5230:2020

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

Other Interesting Items

Online Webinar

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

Training Courses

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

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

Update on China and Japan

China

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

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

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

Japan

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

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

Korea Market: Challenges and Opportunities

Current Situation

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

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

Opportunities

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

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

Closing

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

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

Thank you.

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

Hello.

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

https://www.anaconda.com/

But you need to buy Anaconda to use it.

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

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

https://www.anaconda.com/pricing

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

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

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

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

https://repo.anaconda.com/

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

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

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

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

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

There is an alternative: ‘conda-forge’

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

https://github.com/conda/conda

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

https://conda-forge.org/

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

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

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

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

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

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

conda config --remove channels defaults

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

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

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

Miniforge adds conda-forge to the channel at installation.

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

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

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

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

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.

2022

Akka Is No Longer Open Source.

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

What is Akka?

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

The License Change

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

The main points of the license change are as follows.

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

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

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

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

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

• MariaDB
• CockroachDB
• Sentry
• materialize

Business Source License

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

Grants the right to use only for non-production use

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

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

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

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

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

Change Date, Change License

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

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

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

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

Additional Use Grant

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

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

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

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

Akka License FAQ

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

Free for startup-sized companies

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

Can I keep using older versions of Akka?

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

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

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

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

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

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

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

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

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

Closing

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

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

Thank you.

A Quick Look at the SFC v. Vizio Ruling

Hello, this is Haksung Jang.

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

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

References

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

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

1. Background

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

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

1-1 Copyright Law and Contract Law

Copyright Law

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

Contract Law

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

Examples

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

1-2 US Federal Courts and State Courts

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

2. History of the SFC v. Vizio Lawsuit

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

2021-10-19

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

2021-11-29

Vizio responded to this as follows.

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

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

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

In Response,

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

2022-05-13

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

3. Points Worth Noting

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

3-1. Breach of Contract and Specific Performance

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

3-2. Claim Brought in State Court

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

3-3. No Author as Plaintiff

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

3-4. Declaratory Relief

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

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

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

4-1. The Central Question

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

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

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

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

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

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

4-4. Whether Vizio’s Argument Is Valid

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

4-5 Ruling

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

5. Implications

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

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

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

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

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

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

Thank you.

Challenges and Effects of Adopting InnerSource

Hello, this is Haksung Jang.

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

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

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

1. Key Open Source Practices

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

(1) Cross-Team Collaboration

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

(2) Documentation

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

(3) Continuous Test

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

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

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

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

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

2. Effects of Adopting InnerSource

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

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

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

3. Challenges to Adopting InnerSource

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

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

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

4. Why Should Developers Participate in InnerSource Projects?

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

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

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

Thank you.

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

Hello, I’m Haksung Jang.

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

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

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

1. Intro

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

GitHub Copilot

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

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

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

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

2. Background

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

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

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

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

3. Approach

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

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

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

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

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

4. Case Study Details

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

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

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

5. THREATS TO VALIDITY

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

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

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

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

Thank you.

2021

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

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

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

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

1. Consider the software distributed to the client side.

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

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

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

How should notice content be provided?

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

LGPL-2.1

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

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

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

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

MIT also requires the following.

MIT

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

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

Is minified JavaScript an appropriate way to disclose source code?

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

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

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

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

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

GPL-2.0

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

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

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

2. Watch out for network copyleft licenses.

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

AGPL-3.0

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

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

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

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

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

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

Google’s AGPL Policy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Log4j 2 Security Vulnerability Incident (Log4Shell)

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

Log4j

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

Timeline

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

Press Coverage (Korea)

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

Response Measures

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

Response Examples (Reference)

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

Scope of Impact

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

• Regarding Spring Boot

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

Known Vulnerability Scanners

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

• Huntress Log4Shell Testing Application

• Labrador Log4Shell test

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

Attack Method

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

Government Considers Surveying Open Source Usage

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

(excerpted from this article)

NIPA Publishes Four Guides for Using Open Source Software

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

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

Open Source Software License Guide (Revised Edition)

Download the Open Source Software License Guide

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

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

Public Sector Open Source Software Governance Guide

Download the Public Sector Open Source Software Governance Guide

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

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

Corporate Open Source Software Governance Guide

Download the Corporate Open Source Software Governance Guide

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

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

Open OS Adoption Guide

Download the Open OS Adoption Guide

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

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

China's First GPL Lawsuit Case: VirtualApp

Hello, this is Haksung Jang.

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

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

Summary

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

Parties to the Dispute

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

Plaintiff

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

Defendants

There are three defendant companies in total.

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

Software at Issue

1. VirtualApp (plaintiff’s software)

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

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

Let’s take a closer look at the history.

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

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

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

2. Dim Sum Desktop (defendant’s software)

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

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

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

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

Relief Sought

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

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

Court Ruling

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

Issue 1. Whether GPL-3.0 has legal effect

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

Tort liability for violation of GPL-3.0

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

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

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

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

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

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

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

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

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

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

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

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

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

Closing Thoughts

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

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

Does GPLv2 Also Require Installation Information?

Hello.

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

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

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

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

Thank you. :)

Abstract

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

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

1. Introduction

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

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

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

2. GPLv3’s ‘Installation Information’ Requirement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. GPLv2’s Source Code Disclosure Obligation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Backporting the Installation Information Requirement to GPLv2

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

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

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

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

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

8. GPLv2’s Textual and Historical Revisionism

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

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

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

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

9. Conclusion

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

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

About the author

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

Distribution of Dockerfiles: Who Is Responsible for Compliance?

Hello!

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

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

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

1. Introduction and the Problem

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

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

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

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

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

2. Technical Background of Docker

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

Docker image

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

Dockerfile

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

The Docker Engine

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

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

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

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

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

4. Distribution of Dockerfiles - Analysis

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

4.1 Is Distribution Only the Physical Distribution of Program Code?

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

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

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

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

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

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

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

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

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

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

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

4.2 Patches

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

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

4.3 System Requirements and the Base Image

System Requirements

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

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

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

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

Base image

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

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

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

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

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

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

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

4.4 Program Libraries

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

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

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

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

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

4.5 Updates

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

4.6 When License Obligations Must Be Fulfilled

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

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

5. Conclusion

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

What Is an OSPO?

Hello!

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

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

Definition of an OSPO

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

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

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

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

Legal Risk Mitigation

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

For legal risk management, the OSPO holds the following responsibilities.

• Overseeing open source license compliance management
• Running a review process for the use of inbound code_{note: code obtained from external sources such as open source}
• Ensuring effective contribution to open source projects

Improving Engineers’ Practices

The OSPO improves engineering functions by providing guides and policies for code management in an open source environment. Companies with many software engineers tend to focus their OSPO on engineering policy and practices.

The OSPO’s responsibilities in this area are as follows.

• Clearly communicating the company’s open source strategy both inside and outside the company
• Fostering an open source culture within the organization
• Ensuring that high-quality code is released to open source communities frequently

Enabling Financial Benefits

Some companies focus on the financial benefits related to open source. They use the OSPO to establish a strategy for whether to use commercial vendors or open source vendors. Meanwhile, some technology companies leverage their own OSPO (and open source projects) to drive customers toward purchasing their commercial products.

The OSPO’s responsibilities in this area are as follows.

• Ownership and oversight of strategy execution
• Promoting the effective use of open source in commercial products and services
• Collaborating with the developer community to encourage adoption of strategic open source projects

In this way, each OSPO is structured to fit the company’s business, products, and goals.

OSPO Guides

TODO Group provides guides for companies to establish and operate an OSPO.

• How to Create an Open Source Program⁶
• Measuring Your Open Source Program⁷
• Tools for Managing Your Open Source Program⁸

OSPO Examples

TODO Group has compiled and published case studies of how companies that make effective use of open source, such as Microsoft, Facebook, and Uber, run their OSPOs.

• Autodesk⁹
• Capital One¹⁰
• Comcast¹¹
• Facebook¹²
• Microsoft¹³
• Red Hat¹⁴
• Salesforce¹⁵
• SAP¹⁶
• Uber¹⁷
• Yahoo/Verizon Media¹⁸

I close this article by introducing SK telecom’s OSPO: SK telecom OSPO¹⁹

Thank you.

Elastic License 2.0 and the Evolution of Open Source Licensing

Hello.

This article is based on a white paper about the Elastic License published on March 11, 2021 by Heather Meeker, a U.S. attorney specializing in open source law. Most of it is a translation of the original article, and I have added my own opinions as blockquotes.

For reference, while Heather Meeker presented this white paper as her personal view, she also disclosed that it received some funding from Elastic. Perhaps for that reason, the original article takes a favorable stance toward the Elastic License.

(A bit of digging turned up that Heather Meeker wrote Elastic License 2.0 herself.)

In any case, as the times change and software distribution methods shift, commercial open source companies have had to think about which licensing model to adopt in order to pursue both development and business at once, and I think this article helps in understanding one aspect of the background behind the Elastic License. If you find any errors in this article, please feel free to contact me at any time. :-)

• My deep thanks to Sean and Robin of Kakao, and Kyoungae Kim of LG Electronics, for their help reviewing this article.

Recently, in February 2021, Elastic introduced a new license called Elastic License 2.0 for its software products. This licensing model was applied to major software products such as Elasticsearch and Kibana. Let’s look at the purpose of this change and what it means.

Elastic License 2.0 is a representative licensing best practice available to companies doing business under an Open Development Model. Elastic License 2.0 is not an open source license, but it aims to set the minimum restrictions necessary to maintain a fair balance between the freedom to use, share, and modify software and the prevention of behavior that harms the community.

Unix, Linux, Free Software, and Open Source

To understand the trend toward new licenses like Elastic License 2.0, it helps to look at how the open source licensing movement grew.

The open source and Free Software movements began out of developers’ concerns about the privatization of software. The spark for these concerns was Unix, the most popular operating system of the time. AT&T Bell Labs, the developer of Unix, was barred by a 1956 consent decree from profiting from research projects that included Unix and the C programming language,¹ and as a result it distributed Unix for many years under very permissive license terms. Academics, researchers, and developers began modifying, improving, and sharing Unix, and it soon became the leading operating system. However, when the consent decree was lifted in 1983, AT&T applied terms to Unix that no longer allowed the sharing of modifications. As a result, each vendor used its own modified version of the operating system, Unix splintered into many incompatible variants, and users could no longer collaborate.

As Unix became privatized, the Free Software movement arose, followed by the open source movement, both seeking to prevent infrastructure software from being closed off again in this way. This movement centered on Linux, the free software that replaced Unix, and it soon grew into a larger movement based on the philosophy that all software should be “free” (free as in freedom of speech, not free as in free beer). One element of this movement was the right to access source code and to make and share improvements and changes. These principles were embodied in the GNU General Public License (GPL), under which distributors of binaries must share the corresponding source code.

As time passed, buoyed by the internet boom of the early 2000s, open source licenses grew even more popular. Some licenses, such as the GPL, raised complex legal concerns, but they also laid the groundwork for companies to collaborate. Since 2000, open source, and the collaboration it made possible, has been adopted across every technology sector. Today, open source is a core technology for e-commerce, and companies continue to collaborate on software infrastructure.

The Advent of the Cloud and AGPL

Licenses such as the GPL require that changes be shared. They impose a condition of sharing source code for binary distribution. Making and using a “private copy,” on the other hand, does not require sharing changes. This condition was effective at compelling sharing at the time, because most software was deployed on-premise. However, starting in the early 2000s, software began moving to the public cloud, and it was no longer necessary to distribute software at all. Customers could use software without ever obtaining a local copy.

As the cloud services business grew, this paradigm shift created tension between the expectations of the open source community and cloud service providers such as AWS (Amazon Web Services). Cloud service providers were free of any legal obligation to share their improvements. Because Google was well known for relying on Linux to power its search service, this was also called the “Google Loophole.” In response, the Free Software community created the Affero GPL (AGPL), a partially modified version of the GPL. AGPL 3.0 is nearly identical to GPL 3.0, but it includes the following Remote Network Interaction clause.

[I]f you modify the Program, your modified version must prominently offer 
all users interacting with it remotely through a computer network … 
an opportunity to receive the Corresponding Source of your version by 
providing access to the Corresponding Source from a network server at no 
charge, through some standard or customary means of facilitating copying 
of software….

This new license was intended to compel cloud service providers to share their source code improvements, just as the GPL had done for Linux distributions.

AGPL and Dual Licensing

The AGPL was controversial from its very first release. In 2007, as the drafting of GPL 3.0 was nearing completion, some of its authors wanted to change the GPL into a network copyleft model. However, the community decided to leave the “loophole” in GPL 3.0 as it was, and a few months later offered the AGPL as an alternative. Even so, the AGPL was not widely adopted. MongoDB, a highly popular distributed database product, is the AGPL’s one and only “killer app.” Companies initially found the AGPL difficult to understand and accept, but because most users neither modified the software nor offered it as a service, they were able to reasonably decide to use software under the AGPL.

The Remote Network Interaction clause of AGPL 3.0 only requires you to make the source code of your changes available to remote users over a computer network if you have modified the program. In other words, if you do not modify it, no obligation to disclose source code arises.

MongoDB used the AGPL under a “dual licensing” business model. It gave licensees a choice between the AGPL and a commercial software license. Users who did not want to comply with the AGPL’s requirements, or did not even want to be involved in the legal review needed to comply with them, chose the commercial license. This dual licensing business model was originally developed around a choice between the GPL and a commercial license, but over time the AGPL, with its broader copyleft scope, came to be used in place of the GPL. This licensing model was quite successful for MongoDB. Because the AGPL was the strongest copyleft license, it was useful to MongoDB in driving commercial negotiations. At the same time, the creators of the AGPL criticized the way it was used as a business tool by MongoDB, calling it a “toxic shakedown.” In any case, even the AGPL’s source-sharing condition, powerful as it was considered to be, proved insufficient to stop cloud providers from making large-scale commercial use of open source software while giving nothing back to developers or the community.

Strip-mining

Just as cloud adoption had “broken” the GPL model, the AGPL dual licensing model also began to come under pressure as cloud computing advanced through the 2010s. This time, the problem was different. The scope of the GPL or AGPL extends only to a single program executable. This “feature” was intentionally designed into the GPL, based on the theory that a copyright license can only specify usage terms for a single work. In other words, the GPL imposes a source-sharing requirement for a derivative work, but not for a collective work. The legal boundary between the two is fairly unclear, but as the GPL grew popular, it became common practice to define a single program as a single executable process. The Free Software Foundation has long asserted this principle in its GPL FAQ.

However, two things happened as cloud services advanced. First, software engineering became more focused on cloud implementation. Whereas cloud providers had once needed to improve or modify software to run it in a cloud environment, as software engineering advanced, cloud providers were able to use existing open source software in a “plug and play” fashion. This allowed cloud providers to shift the locus of innovation away from the primary executable. They developed additional software to manage, monitor, and deploy their software, and this innovation is what let them grow their cloud services. The AGPL did nothing to compel cloud providers to share these kinds of improvements.

In this way, commercial open source companies came to look like a shop the large cloud providers could raid for free. The problem was especially severe for “platform software,” or middleware (software that sits between the top-level applications and the operating system in the computing stack). Software in this category is essential to modern computing and extremely useful for cloud implementations.

This gave rise to criticism in the business world of how cloud providers used open source software. In 2018, Salil Deshpande of Bain Capital said, “It is clearly not illegal. But we think it is wrong, and does not do right by the open-source community.” Another expert said, “AWS is exploiting open source’s Achilles heel: taking someone else’s creation for free and building a business by renting out access to it.” The problem is that none of the major open source licenses prevent software from being used this way.

When the major open source licenses were drafted, there was no such thing as an AWS-style “program as a service,” so their terms could not have accounted for it.

Commercial open source companies developed open source programs and ran their business on a dual licensing model (GPL or commercial), while cloud providers simply took those open source programs, offered them as cloud services, and generated no profit for the companies in return. It’s easy to imagine this had a negative effect on both the business and development sides.

A representative example would be cloud providers offering MongoDB as Amazon DocumentDB or Azure Cosmos DB to win over customers.

Commercial open source companies and their investors were troubled by these limitations of the open source model. No license, whether GPL, AGPL, or otherwise, could use copyright law to compel cloud providers to share their changes. In addition, cloud providers with a large customer base, such as AWS, Azure, or Google Cloud, maintained “sticky” relationships with customers by making it easy to add software with the click of a button. Some open source vendors offered their own cloud services, but found it too difficult to compete with large cloud providers using their software for free. Even when an open source vendor’s service was superior, customers turned away because using a new service, unlike simply “checking a box” to add a software product within an existing cloud account, carried a transaction cost.

SSPL and Source-Available Licensing

In 2018, the industry found a breakthrough. As AWS continued to gain popularity by hosting open source platform software, open source vendors began to take action. They changed their licenses.

Open source vendors responded to the strip-mining problem through two different paths.

1. An ultra-strong network copyleft license
2. Source-available licensing with restrictions

Both of these categories were previously undefined. Both were intended to support a dual licensing model, as with MySQL and MongoDB.

SSPL

MongoDB, which created the SSPL (Server Side Public License) in 2018, attempted the ultra-strong copyleft approach.

1.  Offering the Program as a Service.

If you make the functionality of the Program or a modified version 
available to third parties as a service, you must make the Service 
Source Code available via network download to everyone at no charge, 
under the terms of this License. Making the functionality of the 
Program or modified version available to third parties as a service 
includes, without limitation, enabling third parties to interact 
with the functionality of the Program or modified version remotely 
through a computer network, offering a service the value of which 
entirely or primarily derives from the value of the Program or 
modified version, or offering a service that accomplishes for users 
the primary purpose of the Program or modified version.

"Service Source Code" means the Corresponding Source for the Program 
or the modified version, and the Corresponding Source for all programs 
that you use to make the Program or modified version available as a 
service, including, without limitation, management software, user 
interfaces, application program interfaces, automation software, 
monitoring software, backup software, storage software and hosting 
software, all such that a user could run an instance of the service 
using the Service Source Code you make available. [emphasis added].

This license was written to create an open source solution to the strip-mining problem. Its source-sharing requirement is far broader than that of the AGPL. The scope of this requirement was designed to work like the GPL’s requirement even for distributed software. MongoDB applied a dual licensing model under which its software could be used under either the SSPL or a commercial license.

MongoDB submitted the SSPL to the OSI (Open Source Initiative) for approval. After months of debate it was not approved, but MongoDB continues to use the SSPL as the open source option in its dual licensing model. The discussion of why this license does not fit the Open Source Definition was complicated, and meeting that definition was not the only criterion at issue. In short, it was not clear whether a license with such a broad source-sharing requirement would “ensure software freedom.”

Source-Available Licenses with Restrictions

Others followed a different path. Some companies adopted the Commons Clause, led by Salil Deshpande, while others created their own licenses, such as Redis, Confluent, and CockroachDB, just as Elastic created Elastic License 1.0. Unlike the SSPL, these licenses were not intended to satisfy the Open Source Definition. Instead, they carry restrictions specifically targeting strip-mining.

Why did these two paths diverge? It has to do with Freedom Zero, “the freedom to run the program as you wish, for any purpose.”²

A key feature of open source or Free Software licenses is that they carry no licensing constraints or restrictions.³ Compare this to a typical commercial software license. An End User License Agreement, the kind you click to accept for personal use, only permits you to use the software; you cannot modify or distribute it. An enterprise license sets limits on the number of users, servers, or physical locations where the software can be used, and requires the company to monitor that usage. Open source licenses have no such restrictions. Therefore, even if the source code is provided for free, a license that carries a restriction such as no commercial use is, by definition, not open source.

In other words, any licensing restriction at all takes a license outside the open source category.

Nearly all of the licenses released as part of the wave of license changes since 2018 carry similar restrictions. Each has its own specific terms, but they all focus on letting users use the software for free while prohibiting its use to offer a competing hosted service.

Elastic License 2.0

In early 2021, Elasticsearch blazed a path that follows both of these tracks at once. It made its software suite available under two free options: the SSPL and a new Elastic License 2.0 (ELv2).

The new Elastic License 2.0 is short (just one page), written in plain language, and grants nearly all of the freedoms of an open source license. Recipients of the software are free to use, modify, and redistribute it. Even if you have never read a software license before, this one is worth reading.

It has two main restrictions.

You may not provide the software to third parties as a hosted or 
managed service, where the service provides users with access to 
any substantial set of the features or functionality of the software.

You may not move, change, disable, or circumvent the license key 
functionality in the software, and you may not remove or obscure 
any functionality in the software that is protected by the license key.

The first restriction is focused on addressing the strip-mining problem. As a result, using the software in violation of this restriction infringes the rights granted for the software.

The second restriction is meant to prohibit hacking the software’s license key. This kind of restriction has long been common in software licenses, but it has only just begun to appear in source-available licenses. This clause allows developers to have a paid service interact with software under ELv2, or to protect part of a software component for a paid feature.

The license’s other provisions are very straightforward and will be familiar to anyone who has read an open source license.

Why Use Dual Licensing?

Elasticsearch took the unusual path of letting users choose between the SSPL and the Elastic License. Many companies today use an “open core” model, and in fact Elasticsearch itself used this model before. The distinction between the two can be described as subtle. An open core model offers the core software under an open source license (usually a permissive one, such as Apache 2.0). It then offers additional functionality, usually features useful for enterprise-scale deployment, under a restricted license or only as a service. Elasticsearch, however, stuck with a dual licensing model in which the same software can be used under two different licenses. This dual licensing model was pioneered by MySQL, and it typically uses a copyleft license, such as the GPL, AGPL, or SSPL, as the free licensing option. In recent years, though, this model has fallen out of favor because of the conflict between open source licenses and cloud services.

Elastic’s choice was even more unusual in that it offered two free licensing options, the SSPL and Elastic License 2.0. Dual licensing typically offers only one free option. Through this unusual approach, Elasticsearch emphasized the flexibility to let nearly every user use the software for free.

Elastic License 2.0 appears to reflect a resolve to prevent just one thing: cloud service providers offering Elasticsearch as their own cloud service.

In the end, AWS forked Elasticsearch to keep offering its Elasticsearch service, naming it Open Distro for Elasticsearch, applying the Apache License 2.0, and setting out to grow its own community.

Who, then, is actually contributing to the sustainability and advancement of open source?

Elastic License 2.0 and Modern Licensing Techniques

Elasticsearch moved to a new licensing model in order to remain as open as possible while maintaining a business model that is fair and sustainable for both users and developers. In doing so, it reflected the goals and aspirations of other participants in the source-available movement when drafting the license.

As summarized in the FAQ on the license change, Elastic’s license change is not expected to affect the number of customers or community users. Most users build applications on top of Elastic’s software, which is not a business of “providing [the software] to third parties as a hosted or managed service.”

Building a Better License

In addition, by devoting resources to drafting Elastic License 2.0, Elastic pursued an advance in the craft of license drafting itself. In a sense, source-available licensing is as old as software itself. In fact, binary-only licensing was a product of PC/Mac platform standardization in the 1980s. Before that, nearly all software was licensed in source code form. Over time, however, the form and method of license distribution changed considerably.

Elastic License 2.0 is the culmination of this trend. In form, it adopts the simple, intuitive drafting style and template most popular among open source licenses. It also, through its license key preservation clause, makes it easy for vendors to license software with both free and paid features.

Much like the many incompatible proprietary versions that split off from Unix decades ago, proprietary licenses are a patchwork stitched together from all manner of separate terms and conditions. Even a simple end user license for an ordinary consumer software product is typically so long and obscure that most users cannot understand it. Many say that nobody reads them at all. Yet most of this complexity is unnecessary. Open source licenses, particularly permissive ones, have taken this lesson to heart. A simple set of rules should be enough, and the easier a license is to understand, the more likely users are to respect it.

Not only is Elastic License 2.0 short, simple, and easy to understand, but people can also use it as a template. Since the debate over preventing strip-mining began, demand has grown for licenses that are frictionless, carry reasonable restrictions, and are simple and understandable. However, most small software companies lack the resources to draft their own license. It is no surprise that many software startups are looking to licenses like Elastic License 2.0 and the Confluent Community License as models they can adopt.

This space has been popularized by Fair Code, which has established a standard for it. Fair Code states the following.

Fair-code is not a software license. 
It describes a software model where software:

* is generally free to use and can be distributed by anybody
* has its source code openly available
* can be extended by anybody in public and private communities
* is commercially restricted by its authors

This initiative is still in its early stages, but it clearly shows that the industry is beginning to recognize the need for a paradigm that is fair to both users and developers, and that it is enabling commercial open source companies to strike that balance in a more flexible way than the open source model alone. One expert has even called this recent evolution in licensing the “post-open-source era.” In practice, however, these source-available licenses are typically used alongside open source licenses as business and licensing models continue to evolve. The two models are therefore not strict substitutes but complements.

There is also another standardized licensing option. In 2020, a group of attorneys launched the PolyForm Project to draft a collection of source-available license templates. These licenses were peer reviewed by attorneys experienced in both open source and proprietary licensing. Much like Creative Commons for open content licensing, it offers a menu of options, including non-commercial, evaluation-only, and anti-competition licenses. Like Elastic License 2.0, all of them provide free access to source code and grant the necessary patent license. PolyForm Perimeter and PolyForm Shield resemble their forebear, the Confluent Community License, and Elastic License 2.0 has advanced the options available along this same trend.

If you have questions or would like to learn more, refer to the following resources.

“The rise of open source IPOs” https://coss.media/rise-of-the-open-source-ipo/. This article tracks some of the spectacular business successes of open source companies.

“The After Open Source Era Has Started” https://monetize.substack.com/p/open-source-eras . This article discusses the sea change represented by companies moving to source available licenses.

US House of Representatives Committee on the Judiciary’s report on investigation into competition in digital markets, spearheaded by the Subcommittee on Antitrust, Commercial and Administrative Law. https://www.documentcloud.org/documents/7222836-Investigation-of-Competition-in-Digital-Markets.html. Note the mention of Elasticsearch on page 326.

Opensource license used by IT Companies

EPAM, Github Activity Ranking and License Status by Enterprise in 2020 (OSCI)

EPAM, which develops and consults Enterprise Software, provides a ranking service called OSCI (Open Source Contributor Index) that measures Github usage.

Measures the contributions of members of a commercial organization using publicly available Github Committed event data. Contributions from universities, research institutes and free email providers were not included. The target is contributors who have performed more than 10 commits, and the activity score is measured by an algorithm they have studied. The algorithm is published in OSCI Github.

OSCI (Open Source Contributor Index)

https://solutionshub.epam.com/osci

According to the analysis score, Google is at the forefront, with Microsoft and Red Hat coming next. Samsung is ranked 29th for Korean companies and LG Electronics is ranked 71st.

License Status used by Major Companies

The Open Source License Usage Survey, drawn from data collected through OSCI, is also worth a look. Measurement was already possible with tools like Google BigQuery, but the results were unreliable because abuse and other invalid data weren’t filtered out. Building OSCI made it possible to compile statistics over a set of meaningful GitHub repositories, which makes this data more useful.

The study examined the license choices of new public repositories created on GitHub from early 2018 through mid-2020, and also studied a year of data from GitLab to compare patterns across popular open source hosting platforms.

The Sharp Rise in New GitHub Repositories

It shows that the number of repositories created on GitHub has grown sharply over the past two and a half years. This growth in open source is a trend that deserves particular attention.

License Usage Trends Since 2018

Looking at repositories created from early 2018, several trends stand out.

• 34% of repositories do not include a license file, which puts their open source status in question.
• 21% of repositories are not recognized by GitHub as a standard license type. This is usually because the license file contains custom license text, often just a minor edit of standard license text. Finally, and most importantly, Apache 2.0 and MIT are the two most widely used license types, together accounting for more than 35% of all repositories.

Excluding repositories without a license file, more than half use the Apache 2.0 or MIT license. A third of repositories use some form of custom license text, and the remaining 13% cover a range of licenses, most commonly variants of BSD and the GNU Public License.

Repositories continue to be created without a license file despite GitHub’s guidance. The data suggests that many individual contributors do not understand the importance of including a license file in an open source project.

License Usage at the Top 5 OSCI-Ranked Companies

The chart for commercial organizations looks different from the one covering all repositories analyzed on GitHub. Apache 2.0 is by far the most widely used license, followed by custom license text. The MIT license is the only other standard license to gain significant adoption. Copyleft licenses are barely used. Finally, a non-trivial number of repositories still have no license file; a manual review of a sample found that most of these are not code repositories at all, but examples or documentation.

Looking at each of the top 5 companies individually, the results are interesting, and preferences differ from company to company.

Apache is the most preferred license at Google, IBM, and Red Hat. At Microsoft, most licenses are custom text, with MIT as the next most preferred standard license type. A manual review of some of that custom license text found that it was often actually MIT (for code repositories) or Creative Commons (for documentation).

Intel, by contrast, appears to use a much wider variety of license types, with Apache the most preferred, followed by custom license text and 3-Clause BSD. A manual study of the custom license text in Intel’s repositories shows it to be a mix based on Apache 2.0, 3-Clause BSD, and other standard license types.

GitLab Analysis

Over the 12 months from Q2 2019 through the end of Q1 2020, a pattern emerged that is very different from the GitHub results. In particular, 77.7% of public repositories created in this period have no license file. This again suggests that developers are not aware of the need for, or value of, choosing an open source license. It may also reflect some difference between the users who create open source projects on GitLab and on GitHub, with more individual use relative to commercial use.

Excluding repositories without a license file, the image below shows MIT as the most popular at 37%, followed by custom license text at 21%, GPL 3.0 at 17%, and Apache 2.0 at 10%. In summary, permissive license types are again the most widely used on GitLab, but MIT leads, and Apache 2.0 usage is much lower than on GitHub. Copyleft licenses hold a similarly small share on both GitLab and GitHub.

Conclusion

This study surfaces a number of interesting findings.

• Apache 2.0 and MIT are the clear leaders, and the trend toward permissive license types is growing. Copyleft license types see only modest use.
• The number of repositories created without a license is growing, which suggests that individual developers in particular may not understand the legal aspects of open source.
• Custom license types are especially widespread among commercial organizations, and in most cases appear to be based on standard license types.

OpenChain KWG News in 2020

ISO Standard, OpenChain

On December 15, 2020, OpenChain Specification 2.1 was officially published as an international standard ISO/IEC 5230:2020.

For more information on this, please refer to the following article. : https://world.einnews.com/pr_news/532725924/iso-iec-5230-2020-is-the-international-standard-for-open-source-compliance

Kakao Training Material

The open source technology part of Kakao has released open source educational materials for in-house developers so that anyone can read it.

Download

Training materials can be downloaded from the following page.

• http://t1.kakaocdn.net/olive/assets/opensource_guide_kakao.pdf

NCSOFT Training Material

NCSOFT has released lecture slides and scripts, which are open source educational materials in-house, on GitHub based on the spirit of sharing open source so that anyone can use them.

Companies that develop/distribute software can use this slide as it is or extract/modify necessary parts when preparing for in-house open source training.

Anyone can participate in modifying and supplementing these materials through GitHub.

Download

These materials can be downloaded from the following page.

• https://github.com/ncsoft/oss-basic-training/tree/master/source

Maintainer

License

• CC-BY 4.0

Open Source Compliance in the Enterprise

Introducing the Open Source Compliance in the Enterprise book

This book was written by Ibrahim Haddad and published by the Linux Foundation.

It explains in detail what to consider when building an open source compliance program in a business, and anyone can download it from the following link : Download

Korean summary

NCSOFT summarized the main contents of this book in Korean, and after getting permission from the author, Ibrahim, they released it so that open source people of Korean companies can refer to it.

In particular, NCSOFT shared this on GitHub so that anyone can refer to it, improve it, and continue to develop it.

• GitHub : https://github.com/ncsoft/osc-enterprise-ko/
• License : CC BY 4.0
• Slide : OSC-Enterprise-ko_Openchain_KWG_20200317_FN.pdf

Contributors

News

SK Telecom is the first Telecommunications Operator to adopt OpenChain ISO 5230

SK Telecom, South Korea’s largest wireless carrier, is the first telecommunications operator to adopt OpenChain ISO 5230. This leap forward in governance builds on their long-term mission to lead in technological capabilities in 5G, AI, big data analysis, IoT and quantum cryptography communications as a global ICT leader.

“SK Telecom is preparing for its transition to an AI company, and is strategically using open source to develop advanced technologies in AI, 5G, and cloud technology”, says Kim Yoon, CTO, SK Telecom. “Open source, essential for the early introduction of new technologies and rapid technological change, forms a key part of our strategy. We adopted OpenChain ISO 5230, the International Standard for open source compliance, to ensure effective process management in this space. We are also spreading our know-how around complying with open source international standards to SK affiliates and software supply chains to drive further expansion of open source ecosystems and to deliver even greater social value.”

See the original article for more details. : https://www.openchainproject.org/featured/2021/09/08/sk-telecom

Samsung Electronics Announces OpenChain ISO 5230 Conformance

Samsung Electronics announces adoption of OpenChain ISO 5230, the International Standard for open source compliance. They join a growing community of companies in the consumer electronics, automotive, cloud computing and telecommunications field in using this standard to manage supply chains.

“Samsung Electronics has been consistently striving to build an open source compliance process. Our adoption of OpenChain ISO 5230 reflects our ongoing commitment to excellence in our field,” says Daniel Park, Head of Open Source Group. “OpenChain has greatly helped improve the efficiency and confidence of the process. We are pleased to be a part of OpenChain and sincerely look forward to further developing this standard with our peers and suppliers.”

See the original article for more details. : https://www.openchainproject.org/featured/2021/07/07/samsung-electronics-announces-openchain-iso-5230-conformance

오픈소스SW 관리 툴 ‘포스라이트’ 공개한 LG전자, “글로벌 표준 거듭나겠다”

최근 LG전자가 자체 개발해 2014년부터 운영해오고 있는 오픈소스 SW관리 도구인 ‘포스라이트(FOSSLight ; Free and Open Source Software Light)’를 공개해 주목을 받고 있다. 포스라이트는 개발자의 SW를 분석해 오픈소스를 사용했는지, 오픈소스 사용 조건이나 의무사항을 준수했는지 등을 검증해 주는 툴이다.

‘포스라이트’라는 이름으로 외부에 공개하면서 안정성과 기능을 확대하는 한편 글로벌 인지도를 높일 수 있게 할 계획이다. 포스라이트에는 ‘세상에 빛을 밝혀줄 오픈소스’라는 의미가 담겼다.

자세한 내용은 기사 원문에서 확인하세요. : https://n.news.naver.com/article/138/0002105818

한 달 걸리던 카카오톡 오픈소스 관리, 이틀이면 충분

“한 달이 걸리던 카카오톡 오픈소스 관리 작업을 올리브를 사용하면 하루 이틀이면 충분할 것이다.”

카카오의 황은경 오픈소스기술파트장은 오픈소스 관리 서비스 ‘올리브’의 정식 버전에 대해 소개하며 위와 같이 말했다.

올리브는 복잡한 오픈소스 라이선스 관리를 자동화하는 개발 지원 도구다. 자동으로 소프트웨어를 분석해 오픈소스를 사용했는지, 오픈소스 사용 조건이나 의무사항 등을 목록별로 정리해 제공한다.

자세한 내용은 기사 원문에서 확인하세요. : https://zdnet.co.kr/view/?no=20210628143239

SK텔레콤, 개발자와 소통하는 커뮤니티 ‘DEVOCEAN’ 론칭

SK텔레콤이 스타트업·대학 등 외부 개발자들과 소통하는 오픈 커뮤니티를 론칭하며 SK의 ICT 역량을 적극 공유에 나선다.

‘데보션’은 개발자들을 위한 영감의 바다(Developer’s Ocean)라는 뜻으로, 개발자들이 지식과 경허을 공유하는 커뮤니티를 ‘바다’에 비유했다.

자세한 내용은 기사 원문에서 확인하세요. : https://www.fntimes.com/html/view.php?ud=202106140855478693645ffc9771_18