Open Source | Haksung

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

Haksung Jang — Mon, 08 Jun 2026 00:00:00 +0000

This post was written using Claude Code, and the key facts cited were cross-checked against public sources.

Notice

This post reflects the author’s personal analysis and is not legal advice. The facts cited were verified against public sources, but specific matters should be reviewed by a lawyer or other qualified professional.

One point to clarify first

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

Snippet scanning and SCA are different things

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

Category	What it looks at	How it catches code that came in
Dependency-level SCA	Components declared through a package manager	Manifests such as`package.json`,`pom.xml`, and build artifacts
Snippet-level matching	Fragments within the source code body	Code fragments that entered via copy-paste or AI generation

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

How much legal risk actually exists

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

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

This carries facts that can be read in two directions.

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

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

When do license obligations arise

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

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

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

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

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

Do standards require snippet scanning

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

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

Under what conditions does it become more important

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

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

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

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

Looking at it by company condition

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

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

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

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

Embedded software is a different case

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

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

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

Filtering code before it comes in

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

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

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

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

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

Criteria for the decision

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

There are four points to examine when making this decision.

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

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

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

Security vulnerabilities are a separate matter

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

Tools handling security inspection fall broadly into two kinds.

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

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

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

Sources

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Research as of: 2026-06-08

]]>

EU Open Source Strategy: Institutionalizing Open Source for Technological Sovereignty

Haksung Jang — Fri, 05 Jun 2026 00:00:00 +0000

This article was written with Claude Code, and the key facts cited here were cross-checked against primary sources.

Summary
The Communication on European Tech Sovereignty (COM(2026) 503 final), published by the European Commission on June 3, 2026, comes with an attached EU Open Source Strategy. It is the first instance of placing open source at the center of EU digital policy. The strategy sets four goals — leveraging open source for sovereignty, strengthening the ecosystem, opening up public administration, and standards and international cooperation — and calls for the public and private sectors to mobilize approximately €2 billion for open-source-related measures over the next seven years. The aim is to reduce the EU’s dependency structure, under which it spends €264 billion annually on proprietary IT from the United States. Civil society (FSFE) and policy analysts welcomed the direction while pointing to limitations in funding adequacy, the relationship between open standards and open source, the neglect of open hardware, and the practitioner skills gap. For Korean public and corporate practitioners, the opening of EU procurement, open source steward regulation, and the open-source default for the EUDI Wallet are the points to watch directly.

1. Overview

The European Commission announced the technological sovereignty package in Brussels on June 3, 2026. A Communication is not binding legislation but a document that sets out the Commission’s policy direction and planned follow-up actions.A1·A2 The package consists of four interconnected initiatives: Chips Act 2.0 for semiconductors, the Cloud and AI Development Act (CADA), the Open Source Strategy, and a roadmap for energy sector digitalization and AI. The scope of this report is the Open Source Strategy (Chapter 4 of the COM document).A1

The problem the strategy seeks to address is clear. The Draghi Report noted that the EU depends on non-EU suppliers for more than 80% of its digital products and services, infrastructure, and intellectual property.A1 The Open Source Strategy chose open source as the means to reduce this dependency. Europe, the birthplace of Linux, has more than 3 million open source contributors, and nearly half of code commits come from small companies with fewer than 50 employees. The assets exist, but they face structural limitations in scaling and funding.A1

2. Key Content: Four Goals

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

Figure 1. The four goals of the Open Source Strategy and their representative measures(Source: COM(2026) 503 final, Chapter 4, 2026-06-03)

Leveraging open source for technological sovereignty (Goal i). The Commission is expanding the Open Internet Stack into a shared catalogue of European open source building blocks, and has mobilized €41.3 million through three calls under the Horizon Europe 2026–2027 work programme.A1 Making the EU digital identity ecosystem open source is a central pillar. The EU Digital Identity Regulation (EUDIR) sets a legal default requiring the EUDI Wallet application components to be open source; building on this, the reference implementations of the Identity Wallet (EUID) and the European Business Wallet (EBW) are being developed as open source, with their long-term stewardship transferred to the European Digital Public Infrastructure Foundation.A1 The Commission cooperates with member states through the European Digital Infrastructure Consortium (EDIC) on Digital Commons, and aims to reach 30 million active users of open source collaboration and productivity tools and secure email by 2030.A1

Strengthening the ecosystem (Goal ii). Open source building blocks are mostly maintained through foundations, and most of the funding comes from US and Chinese Big Tech.A1 The open source software steward concept introduced by the Cyber Resilience Act (CRA) is the regulatory pillar of this goal. The Commission is developing a stewardship toolkit to help establish foundations, and supports the establishment of a European Digital Public Infrastructure steward organization that governs EU-funded strategic assets from a single hub. To maintain and secure key components, it is creating a new Open Source Maintenance Instrument, building European capacity to fork projects when needed.A1

Important

The figure of “€350 million for the Open Source Maintenance Instrument,” frequently cited in outside analyses, does not appear in the original COM(2026) 503 text. It is the TechPolicy.Press authors’ own estimate of what the instrument would require, and the original document attaches no amount to it.A1·E1 By contrast, “approximately €500 million for RISC-V” is actually listed in Annex II, but it is recorded as a Chips Joint Undertaking investment and is a separate line item from the Open Source Strategy’s €2 billion budget.A1

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

Standards and international cooperation (Goal iv). In the revision of the EU Standardisation Regulation, the Commission is improving cooperation between open source and standardization communities, and providing conditions for specific standards to be implemented as open source. Through the Team Europe approach, EU open source solutions are being deployed to enlargement and partner countries.A1

Governance Structure

Rather than creating new bodies, the strategy weaves together existing governance assets. Three pillars interlock.

Figure 2. How the governance bodies of the Open Source Strategy connect(Source: COM(2026) 503 final, Chapter 4 and Annex II, 2026-06-03)

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

3. Background and Context

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

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

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

4. Recent Developments and Timeline

As the announcement was only days ago, developments center on the immediate reactions and the procedures scheduled ahead.

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

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

A policy analysis by TechPolicy.Press (Gates, Givropoulou, Karhu, 2026-06-03) assessed the strategy as “Europe’s most meaningful progress yet” while pointing to four gaps.E1 The precedence between open standards and open source remains unsettled, treatment of open hardware is limited to RISC-V and EDA tools, the €2 billion over seven years is insufficient against the €264 billion in annual dependency, and development of practitioner-level contribution, maintenance, and governance capacity remains weak. The law firm Covington also summarized the package’s investment scale and corporate impact on June 4, 2026.E3

The nature of the funding adds to the uncertainty. The €2 billion is not a firmly allocated budget but an aggregate estimate of what the public and private sectors “should mobilize” over seven years.A1 The Open Source Maintenance Instrument, the European Digital Public Infrastructure Foundation, and the voluntary EU assessment framework are all still at the stage of a “we will create” commitment, with no concrete design or amount yet determined.

On the schedule ahead, the package will be reflected in member states’ revisions of their national Digital Decade strategic roadmaps in December 2026, and the proposed revision of the Standardisation Regulation and the legislative processes for CADA and Chips Act 2.0 will flesh out the open source requirements. The Commission discusses progress annually at the Digital Decade Board and reports to the European Parliament every three years.A1

5. Implications and Considerations

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

The opening of EU public procurement is the most concrete variable. If tender specifications come to include open standards and models, and open source is put in a position to compete with proprietary solutions, Korean software vendors seeking to enter the EU public market will benefit from open-source-friendly proposals and clear licensing.A1·B2 Conversely, this opens up EU procurement opportunities for Korean companies with open-source-based businesses.

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

From the perspective of Korean public software policy, the institutionalization path of the “public money, public code” principle and the OSPO Network governance model offer a useful reference. However, since the EU itself has left funding adequacy and practitioner capacity as unresolved challenges, the gap between declaration and implementation also bears watching.B4·E1

6. References

]]>