Hello.

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

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

1. Overview of the Incident

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

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

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

Timeline

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

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

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

2. What Was Copied

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

Copyright Header Replacement

The header from FFmpeg’slibavcodec/vpx_rac.h:

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

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

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

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

Matching Function Bodies

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

FFmpeglibavcodec/vpx_rac.h:

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

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

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

The only changes are dropping the inline specifier and changing the return type fromint tork_s32. The function body is identical down to the whitespace, and theuint8_t parameter type andunsigned int in the body remain exactly as written in FFmpeg.

Traces Left in the Code

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

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

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

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

/** * vp56 specific range coder implementation */

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

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

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

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

The Probability Tables Are a Somewhat Different Matter

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

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

libvpx:

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

FFmpeg:

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

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

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

3. Why It Took 22 Months

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

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

Rockchip later revealed the reason for the delay.

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

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

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

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

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

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

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

4. Rockchip’s Response and Remaining Issues

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

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

Still, a few things remain.

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

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

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

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

5. Why License Laundering Is Dangerous

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

Mapping each violation to the relevant clause looks like this.

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

What the Correct Structure Looks Like

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

Figure 2. Comparison of hardware acceleration integration structures

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

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

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

6. The Allwinner Case, Ten Years Earlier

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

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

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

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

7. What Companies Should Check

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

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

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

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

Summary

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

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

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

References

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

Revised on July 23, 2026 to reflect subsequent developments.

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

1. Case Overview

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

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

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

Disclaimer:

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

2. Background and Progress of the Lawsuit

Background

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

Legal Basis of the Lawsuit

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

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

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

Progress of the Lawsuit

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

The Plaintiff’s Claims

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

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

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

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

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

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

[Note] An excerpt from thecomplaint disclosed by SFC:

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

3. Summary of the Ruling

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

4. Implications and Various Interpretations

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

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

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

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

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

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

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

Introduction

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

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

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

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

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

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

1. Product Liability Directive (PLD)

1.1 Overview

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

1.2 Key Changes

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

1.3 Scope of Application

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

1.4 Key Obligations

1.5 Implementation Timeline

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

1.6 Impact on Companies

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

2. Cyber Resilience Act (CRA)

2.1 Overview

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

2.2 Scope of Application

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

2.3 Key Requirements

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

2.4 Implementation Timeline

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

2.5 Impact on Companies

2.6 Company Response Measures

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

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

3. AI Act

3.1 Overview

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

3.2 Classification of AI Systems

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

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

3.3 Key Requirements

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

3.4 Implementation Timeline

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

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

3.5 Impact on Companies

3.6 Company Response Measures to Prepare for Implementation

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

3.7 Key Features and Significance of the AI Act

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

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

4. Interrelationship Among the Three Laws

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

4.1 Common Regulatory Purposes

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

4.2 Overlapping Scope of Application

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

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

4.3 The Need for an Integrated Approach

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

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

5. Recommendations for Korean Companies

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

5.1 Form a Regulatory Compliance Task Force

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

5.2 Review the Product and Service Portfolio

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

5.3 Strengthen Documentation and Transparency

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

5.4 Strengthen the Risk Management Framework

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

5.5 Build Human Capacity

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

5.6 Reassess R&D and Innovation Strategy

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

5.7 Adjust the Business Model and Strategy

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

5.8 Strengthen Stakeholder Communication

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

6. Conclusion

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

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

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

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

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

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

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

Background

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

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

CommonCrawl

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

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

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

LAION’s Data Processing

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

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

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

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

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

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

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

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

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

The Start of the Lawsuit

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

Legal Issues

The core issues of this lawsuit are as follows:

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

The Impact of the EU Copyright Directive

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

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

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

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

The Ruling

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

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

Significance of the Ruling

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

Future Outlook

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

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

Implications for Domestic AI Companies

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

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

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

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

Parties to the Lawsuit

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

Overview of the Case

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

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

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

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

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

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

Progress of the Lawsuit

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

The Defendants’ Arguments

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

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

The Court’s Ruling

First-Instance Judgment

The Suzhou Intermediate People’s Court ruled as follows:

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

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

The Supreme People’s Court’s Ruling

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

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

Significance of the Ruling

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

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

Similarity to the WordPress Theme Case

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

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

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

Implications for Corporate Open Source Management

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

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

Conclusion

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

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

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

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

References

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

1. Introduction to SPDX 3.0

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

Definition and Purpose of SPDX

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

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

Key Changes in SPDX 3.0

SPDX 3.0 brings significant changes compared to previous versions:

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

Significance of SPDX 3.0

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

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

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

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

2. Key Features of SPDX 3.0

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

Modular Structure

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

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

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

Improved Extensibility

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

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

Support for Various Use Cases

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

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

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

Enhanced Data Model

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

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

Compliance with International Standards

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

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

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

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

3. SPDX 3.0 Profiles

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

Core Profile

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

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

Software Profile

The Software Profile provides detailed information related to software packages.

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

Security Profile

The Security Profile covers security-related information about software.

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

License Profile

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

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

Build Profile

The Build Profile provides information about the software build process.

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

AI/ML Profile

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

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

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

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

4. SPDX 3.0 Data Model

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

Key Entities and Relationships

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

Identifier Scheme

SPDX 3.0 introduces a more robust and flexible identifier scheme:

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

Metadata Management

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

Extensibility Mechanisms

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

Data Types

SPDX 3.0 supports various data types:

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

Serialization Formats

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

• JSON-LD
• YAML
• RDF
• XML

This support for multiple formats facilitates integration with other systems.

Profile Support

The data model is designed to support various profiles:

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

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

5. SPDX 3.0 Implementation Guide

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

Tools and Libraries

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

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

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

File Formats (JSON, YAML, RDF)

SPDX 3.0 supports various file formats:

1. JSON-LD

   • The most recommended format

   • Example:

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

2. YAML

   • A human-readable format

   • Example:

     ---$schema:<https://spdx.org/spdx-3.0-schema.json>spdxVersion:SPDX-3.0name:Example SPDX 3.0 Documentelements:-type:Packagename:ExamplePackageversion:1.0.0

3. RDF

   • Suitable for semantic web applications

   • Example:

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

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

Migrating from Existing SPDX 2.x

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

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

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

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

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

6. SBOM and SPDX 3.0

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

SBOM Generation and Management

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

Improving SBOMs with SPDX 3.0

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

Meeting NTIA Minimum Requirements

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

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

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

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

7. Security and Vulnerability Management

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

CVE Information Integration

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

1. How to reference CVEs

   • SPDX 3.0 uses theExternalReference class to reference CVE information.

   • Example:

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

2. Inclusion of detailed CVE information

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

3. Automatic CVE updates

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

4. Linking CVE information to components

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

Vulnerability Tracking and Reporting

SPDX 3.0 provides features for effectively tracking and reporting vulnerabilities.

1. Vulnerability lifecycle management

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

   • Example:

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

2. Vulnerability severity assessment

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

   • Example:

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

3. Vulnerability report generation

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

4. Vulnerability trend analysis

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

Utilizing the Security Profile

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

1. Security Profile structure

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

2. Example use of the Security Profile

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

3. Ways to utilize the Security Profile

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

4. Security metric tracking

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

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

8. License Compliance

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

License Information Management

1. License identifiers

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

2. Inclusion of license text

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

   • Example:

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

3. Custom licenses

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

4. License expressions

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

5. File- and package-level licenses

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

License Compatibility Checking

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

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

Compliance Report Generation

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

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

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

9. SPDX 3.0 Use Cases

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

Software Supply Chain Security

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

Open Source Management

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

Regulatory Compliance

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

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

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

10. SPDX 3.0 Adoption Strategy

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

Phased Implementation Plan

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

Training and Awareness Within the Organization

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

Tips for Successful Adoption

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

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

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

11. Future Outlook and Direction

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

SPDX Community Participation

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

Future Updates and Improvements

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

Global Standardization Trends

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

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

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

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

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

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

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

Introduction: The Background of the Elasticsearch License

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

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

1. History of Elasticsearch License Changes

1.1 The Shift from Apache 2.0 to Elastic License 2.0

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

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

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

1.2 Elastic License 2.0 Is Not an Open Source License

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

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

2.1 Key Characteristics of AGPL-3.0

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

Thekey characteristics of AGPL-3.0 are as follows:

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

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

2.2 Why Elastic Returned to AGPL-3.0

The reasons Elastic choseAGPL-3.0 are as follows:

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

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

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

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

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

3.1 Monitoring License Changes

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

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

3.2 Providing Training and Internal Guidelines

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

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

3.3 Responding to AGPL-3.0 in Cloud Environments

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

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

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

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

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

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

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