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

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