Call fo r evidence „ European Open Digital Ecosystem Strategy ” ToC 1. What are the strengths and weaknesses of the EU open - source sector? What are the main barriers that hamper (i) adoption and maintenance of high - quality and secure open source; and (ii) sustainable contributions to open - source communities? ..................... 3 1. Diagnosis: Strengths and Weaknesses of the EU Open Source Sector ................... 3 2. Main Barriers to Adoption and Maintenance (i) ................................ ..................... 7 3. Main Barriers to Sustainable Contribution (ii) ................................ ....................... 8 2. What is the added value of open source for the public and private sectors? Please provide concrete examples, including the factors (such as cost, risk, lock - in, security, innovation, among others) that are most important to assess the added value. ............. 9 Cost Savings and Economic Efficiency ................................ ................................ ... 9 Freedom from Vendor Lock - in ................................ ................................ .............. 10 Security and Transparency ................................ ................................ ................... 10 Innovation and Interoperability ................................ ................................ ............ 11 Risk Mitigation ................................ ................................ ................................ .... 11 Concrete Implementation Examples ................................ ................................ .... 11 Assessment Framework ................................ ................................ ...................... 12 3. What concrete measures and actions may be taken at EU level to support the development and growth of the EU open - source sector and contribute to the EU’s technological sovereignty and cybersecurity agenda? ................................ ............... 12 Solutions to the weaknesses described in Chapter 1 ................................ ............. 15 Cross - Cutting Implementation Principles ................................ ............................. 26 4. What technology areas should be prioritised and why? for europe to be sovereing? 27 Tier 1: Quick Wins – High Feasibility, Immediate Impact ................................ ......... 27 Tier 2: High Strategic Priority – Moderate Feasibility, Critical for Sovereignty ............ 28 Artificial Intelligence Infrastructure and Models ................................ .................... 29 Open source alternative landscape: ................................ ................................ ..... 30 Cybersecurity Tooling and Supply Chain Security ................................ .................. 31 Tier 3: Strategic Long - Term – High Complexity, Transformative Potential .................. 32 Edge Computing and Industrial IoT ................................ ................................ .... 32 Digital Payments Infrastructure (Digital Euro) ................................ ..................... 33 Cross - Cutting Enablers ................................ ................................ .................... 34 5. In what sectors could an increased use of open source lead to increased competitiveness and cyber resilience? ................................ ................................ .... 34 1. Automotive: Software - Defined Vehicles (SDV) ................................ ................... 35 Competitiveness Benefits ................................ ................................ ................ 35 Cyber Resilience Benefits ................................ ................................ ................ 36 EU Policy Support ................................ ................................ ............................ 36 Recommended actions: ................................ ................................ ................... 36 2. Public Administration and Digital Government Services ................................ ..... 37 Competitiveness Benefits ................................ ................................ ................ 37 Cyber Resilience Benefits ................................ ................................ ................ 37 Strategic Implementation Framework ................................ ............................... 38 Recommended actions: ................................ ................................ ................... 38 3. Healthcare: Electronic Health Records and Medical Interoperability ................... 38 Competitiveness Benefits ................................ ................................ ................ 39 Cyber Resilience Benefits ................................ ................................ ................ 39 Recommended actions: ................................ ................................ ................... 40 4. Financial Services: Open Banking and Financial Infrastructure ........................... 40 Competitiveness Benefits ................................ ................................ ................ 40 Cyber Resilience Benefits ................................ ................................ ................ 41 Recommended actions: ................................ ................................ ................... 42 5. Energy: Smart Grid and Critical Infrastructure ................................ .................... 42 Competitiveness Benefits ................................ ................................ ................ 42 Cyber Resilience Benefits ................................ ................................ ................ 43 Recommended actions: ................................ ................................ ................... 44 6. Telecommunications: 5G Open RAN and Network Infrastructure ........................ 44 Competitiveness Benefits ................................ ................................ ................ 44 Cyber Resilience Benefits ................................ ................................ ................ 45 Recommended actions: ................................ ................................ ................... 46 Cross - Sectoral Priorities ................................ ................................ ...................... 46 1. What are the strengths and weaknesses of the EU open - source sector? What are the main barriers that hamper (i) adoption and maintenance of high - quality and secure open source; and (ii) sustainable contributions to open - source communities? 1. Diagnosis: Strengths and Weaknesses of the EU Open Source Sector A. Strengths • High - Calibre Talent Pool & Developer Community: The EU is home to one of the world's largest, most active, and highly skilled communities of open source contributors. European developers are disproportionately represented in core infrastructure projects (e.g., Linux kernel, embedded systems). European organizations recognize open source as essential for digital sovereignty, with 69% believing OSS adoption increases productivity and creates opportunities for advancing AI projects and reducing vendor dependency. • Technical excellence in strategic domains : European open - source projects have achieved strong positions in critical areas including high - performance computing, edge computing, cloud infrastructure, and cybersecurity. EU - funded initiatives like Next Generation Internet, FIWARE, and the Digital Commons European Digital Infrastructure Consortium demonstrate proven capability to develop world - class open technologies • Regulatory & Value Alignment: The inherent transparency and auditability of OSS align perfectly with European values and regulatory frameworks, specifically GDPR, the AI Act, and the Cyber Resilience Act (CRA). OSS is the only viable mechanism to guarantee the "security by design" and digital sovereignty that EU policy mandates. • Strong Research & Industrial Base: Through programs like Horizon Europe, the EU excels at funding early - stage innovation. Furthermore, Europe leads in industrial engineering (automotive, manufacturing, robotics). This creates a natural "home turf" advantage for OSS in Industrial IoT, Edge Computing, and open hardware (e.g., RISC - V). • Emerging Political Will: Initiatives like the NGI (Next Generation Internet) and the recognition of Digital Commons as a strategic asset demonstrate a shifting political mindset towards supporting open infrastructure. B. Weaknesses • The "Valley of Death" in Commercialization: While Europe is excellent at funding research (creating code), it fails at funding commercialization (building products). There is a chronic lack of growth capital for OSS scale - ups compared to the US, leading to European innovations being acquired or monetized by non - EU tech giants. • Lack of strategic maturity : t he Linux Foundation Europe's 2025 research revealed that 66% of European organizations lack a formal open - source strategy and 78% have not implemented an open - source program office (OSPO). This strategic immaturity hampers coordination, investment decision s, and systematic contribution to open - source ecosystems. • Institutional Vacuum and Lack of Policy Coordination (The OSPO Gap) : There is a critical absence of Open Source Program Offices (OSPOs) at the national and regional levels across many Member States. While some pioneers exist, there is no pan - European network to harmonize OSS policies. Impact: This leads to a "fragmented sovereignty" where each country reinvents the wheel. Without a central mandate or coordinated strategy at the EU level, best practices for OSS governance, licensing, and security remain siloed, preventing the emergence of a uni fied European digital market. • Absence of a "Public Money, Public Code" Mandate : There is currently no legal obligation for the public sector to publish software developed with taxpayer funds into public repositories. Impact: Vast amounts of high - quality code developed for local or national administrations remain "dark" (proprietary or hidden). This lack of transparency prevents other Member States from reusing existing solutions, leading to massive financial waste and missed opportunities for cross - border interoperability. • Fragmented Collaboration: The "Snowdrop" Syndrome : Cooperation between countries on shared codebases is the exception, not the rule. While there are promising "snowdrops" (early signs of spring) such as the Architecture Reference Framework (ARF) for the EUDI Wallet or the EDIC for Digital Commons , these remain isolated projects rather than a standard operational model. Impact: Instead of building a "European Tech Stack," Member States continue to procure 27 different versions of similar systems, failing to achieve the economies of scale that would allow EU solutions to compete with global tech giants. • Procurement Bias and Systemic Exclusion (The "Brand Name" Trap) : Public procurement often features explicit or implicit bias toward proprietary vendors. As highlighted in the 2025 Instrat Foundation report , it is a common (and detrimental) practice — for example, in Poland — to specify brand names like Microsoft or Google in Terms of Reference (SWIZ/SIWZ) for cloud services or office suites. Impact: This creates an uneven playing field where OSS is effectively excluded from the start. It cements dependency on non - EU vendors and prevents local OSS - based companies from competing for public contracts, even when their solutions are more cost - effective an d secure. • Educational Dependency: The "Classroom - to - Cloud" Pipeline : Open source literacy is missing from school curricula. Instead of teaching students vendor - neutral computational logic, many Member States subsidize the adoption of Microsoft 365 or Google Workspace in schools. Impact: This creates early - age "vendor lock - in," training the next generation of workers to be proficient only in specific proprietary tools. It stifles the development of a culture of "openness" and prevents students from understanding the underlying mechanics o f the technology they use. • Chronic Underfunding of the "Human Infrastructure" (Volunteers) : There are no dedicated EU - wide funds to support the individual maintainers and volunteer communities who uphold critical digital infrastructure. Impact: Since critical libraries are often maintained by unpaid developers in their spare time, the ecosystem is fragile. Without financial support for these "human foundations," Europe risks burn - out among its top talent and increased security vulnerabilities in its supply chain. • Lack of IT Spending Transparency and Procurement Inventory : Most Member States lack a centralized, transparent inventory of IT assets, software licenses, and digital procurement spending. There is no unified "IT budget line" at the national level, meaning that even top government officials often do not know the tot al expenditure on proprietary software versus open solutions. Case Study & Impact: In Poland, it was only in 2025 that the SIST (System Inwentaryzacji Systemów Teleinformatycznych) gained proper legal standing to track and report IT systems and procurement. Previously, neither the Prime Minister nor the Ministry of Finance could accurately state the total national spend on IT • Lack of Scale - up Funding and Competitive Challenges (The AI Gap) : The EU lacks aggressive, open - competition funding models for scaling high - potential projects. Unlike India’s "Bhashini" or other sovereign AI initiatives, Europe does not yet have enough large - scale, open challenges to build and scale foundational models (like LLMs) or core infrastructure. Impact: European OSS projects stay "small" or "academic." Without "winner - takes - most" style support for the best open - source projects, the EU will continue to lose the race in emerging fields like Generative AI to heavily subsidized or venture - backed foreign enti ties. • The "Silo" Problem: This lack of inventory extends to State - Owned Enterprises (SOEs) and local governments, where each entity procures hardware and software in isolation. This leads to: o Duplication of costs: Paying for the same license multiple times across different departments. o Inability to aggregate demand: Without a clear inventory, countries cannot use their "buyer power" to negotiate better terms or mandate Open Source alternatives. o Strategic Blindness: It is impossible to manage a transition to technological sovereignty when the "as - is" state of dependency is not even measured. • Fragmentation of the Ecosystem: The EU OSS landscape is characterized by small, scattered SMEs and individual contributors. It lacks the large "anchor tenants" , a massive technology companies that, in the US or China ( big tech) , provide the funding, infrastructure, and full - time personnel to maintain critical open source projects. • Infrastructure Dependency: European OSS development largely relies on non - EU infrastructure (e.g., GitHub/Microsoft, AWS, GitLab ). This creates a paradox where the code is open, but the platforms hosting, building, and distributing it are controlled by external jurisdictions, posing a risk to sovereignty. • Value capture outside Europe : A fundamental weakness is that much of the economic value generated by European open - source communities flows outside the EU, often benefiting large technology companies headquartered elsewhere. While European developers contribute substantially to the glo bal digital commons (which underpins 70 - 90% of all code in the digital economy), commercialization and ecosystem monetization predominantly occur beyond EU borders. 2. Main Barriers to Adoption and Maintenance (i) The following barriers hinder the widespread adoption of high - quality, secure OSS, particularly in the public sector and critical industries: • Procurement Inertia and Vendor Lock - in: o Public procurement processes are historically designed for proprietary licensing models ("buying a box") rather than service - based models ("funding development/support"). o Legacy vendor lock - in creates high switching costs. Many public administrators perceive "nobody gets fired for buying [Dominant Proprietary Vendor]" as a safer route, despite the long - term strategic risk. • The "Productization Gap" (Code vs. Product): o There is a distinction between excellent code and an enterprise - ready product Many EU OSS projects lack professional documentation, defined Service Level Agreements (SLAs), user - friendly interfaces, and legal indemnity. o Without a business entity to provide liability guarantees (crucial under the new Cyber Resilience Act), risk - averse organizations hesitate to adopt community - run projects. • The "Tragedy of the Commons" in Security Maintenance: o Critical OSS infrastructure is often maintained by unpaid volunteers. There is a systemic lack of funding for maintenance (bug fixes, security patches, refactoring) as opposed to new features o This underfunding creates security vulnerabilities (e.g., Log4j scenario) which damages the reputation of OSS regarding safety and reliability. 3. Main Barriers to Sustainable Contribution (ii) For the ecosystem to thrive, consumption must be balanced with contribution. Currently, the following barriers prevent this cycle: • The "Free - Rider" Problem: o Large commercial entities often consume OSS components to build proprietary products without contributing back to the upstream projects (neither code nor funding). This extractive model exhausts maintainers and threatens project longevity. • Lack of Organizational Maturity (OSPOs): o Few European public bodies or traditional industries have established Open Source Program Offices (OSPOs) . Without these dedicated units, organizations lack the legal policies, technical workflows, and cultural mandate to allow their employees to contribute code back to the community. • Legal and Bureaucratic Uncertainty: o In the public sector, contributing code developed with public funds is often hindered by unclear intellectual property (IP) regulations or fears of "state aid." There is a lack of a clear "Public Money, Public Code" default mechanism that legally mandates and simplifies the release of government - funded software. • Misaligned Incentives in Funding: o Grant systems often prioritize "novelty" over "sustainability." It is easier to get EU funding to write a new framework than to maintain and secure an existing widely - used library, discouraging long - term stewardship. 2. Main Barriers to Adoption and Maintenance (i) • Procurement Inertia and Vendor Lock - in: o Public procurement processes are historically designed for proprietary licensing models ("buying a box") rather than service - based models ("funding development/support"). o Legacy vendor lock - in creates high switching costs. Many public administrators perceive "nobody gets fired for buying Dominant Proprietary Vendor " as a safer route, despite the long - term strategic risk. • The "Productization Gap" (Code vs. Product): o There is a distinction between excellent code and an enterprise - ready product Many EU OSS projects lack professional documentation, defined Service Level Agreements (SLAs), user - friendly interfaces, and legal indemnity. o Without a business entity to provide liability guarantees (crucial under the new Cyber Resilience Act), risk - averse organizations hesitate to adopt community - run projects. • The "Tragedy of the Commons" in Security Maintenance: o Critical OSS infrastructure is often maintained by unpaid volunteers. There is a systemic lack of funding for maintenance (bug fixes, security patches, refactoring) as opposed to new features o This underfunding creates security vulnerabilities (e.g., Log4j scenario) which damages the reputation of OSS regarding safety and reliability. 3 Main Barriers to Sustainable Contribution (ii) For the ecosystem to thrive, consumption must be balanced with contribution. Currently, the following barriers prevent this cycle: • The "Free - Rider" Problem: o Large commercial entities often consume OSS components to build proprietary products without contributing back to the upstream projects (neither code nor funding). This extractive model exhausts maintainers and threatens project longevity. • Lack of Organizational Maturity (OSPOs): o Few European public bodies or traditional industries have established Open Source Program Offices (OSPOs) . Without these dedicated units, organizations lack the legal policies, technical workflows, and cultural mandate to allow their employees to contribute code back to the community. • Legal and Bureaucratic Uncertainty: o In the public sector, contributing code developed with public funds is often hindered by unclear intellectual property (IP) regulations or fears of "state aid." There is a lack of a clear "Public Money, Public Code" default mechanism that legally mandates and simplifies the release of government - funded software. • Misaligned Incentives in Funding: o Grant systems often prioritize "novelty" over "sustainability." It is easier to get EU funding to write a new framework than to maintain and secure an existing widely - used library, discouraging long - term stewardship. 2. What is the added value of open source for the public and private sectors? Please provide concrete examples, including the factors (such as cost, risk, lock - in, security, innovation, among others) that are most important to assess the added value Open source software delivers substantial added value across both public and private sectors through multiple interconnected dimensions: cost efficiency, strategic autonomy, security transparency, innovation acceleration, and risk reduction. The value prop osition varies by context but consistently outweighs proprietary alternatives when assessed holistically. Cost Savings and Economic Efficiency • Direct license cost reduction : Open source eliminates recurring license fees that can consume 20 - 40% of public sector IT budgets. The City of Barcelona's migration to open source technologies aimed to redirect 70% of its software budget toward open source solutions by 2019, enabling rei nvestment in local IT talent and custom development rather than vendor payments. Research shows that cost savings and faster development are the top benefits companies report from open source adoption. • Avoided duplication and reuse efficiency : When public administrations share open source code, they eliminate redundant development efforts. A single solution can be deployed across multiple jurisdictions with customization, rather than each entity procuring bespoke systems. Studies on open data (a related concept) demonstrate that making research outputs openly available can save up to 9% of project costs by preventing unnecessary data collection and facilitating efficient reuse. Labour cost savings from data sharing and curation range from two to over twenty times the operational costs of maintaining shared repositories. • Increased GDP and startup formation : Economic modeling indicates that a 10% increase in open source contributions could raise EU GDP by 0.4 - 0.6% and generate over 600 new startups, demonstrating macroeconomic value beyond individual project savings. Freedom from Vendor Lock - in • Reduced strategic dependency : Proprietary software creates dependency through data formats, APIs, and integration ecosystems that make switching costly or technically infeasible. Open source provides access to source code, enabling organizations to maintain, modify, and migrate systems independently. Organizations can self - host critical components or switch service providers without losing functionality, whereas proprietary solutions typically bind customers to single vendors through technical and contractual restrictions. • Portability and multi - cloud flexibility : Open source technologies like Kubernetes enable workloads to run across different cloud providers with minimal changes, supporting multi - cloud and hybrid strategies that prevent single - provider dependency. The World Bank notes that governments can "fast - tr ack the delivery of services" using core open source systems as public goods, with value - added services developed independently by government or third parties since specifications and code are public. • Concrete example: EUDI Wallet : The EU Digital Identity Wallet's Architecture Reference Framework (ARF) is developed as open source specifically to ensure interoperability, security, and privacy across all 27 Member States. This prevents any single vendor from controlling the European di gital identity infrastructure and enables each country to implement solutions compatible with the shared framework while maintaining sovereignty over their systems. Security and Transparency • Supply chain visibility : Open source enables transparency in the software supply chain, allowing organizations to identify dependencies, audit code, and verify security properties. The EU's FOSSA (Free and Open Source Software Auditing) initiative has conducted security audits of open source projects used in EU technology infrastructure, identifying and correcting vulnerabilities that strengthen cybersecurity across Europ e. • Rapid vulnerability response : When security issues are discovered in open source software, the entire community can contribute to fixes, and patches can be deployed without waiting for vendor release cycles. Organizations are not dependent on proprietary vendors' priorities or timeline s for addressing critical vulnerabilities. • Compliance with emerging regulation : The Cyber Resilience Act, AI Act, and Interoperable Europe Act emphasize openness, standards, and transparency — requirements naturally aligned with open source approaches. Open source facilitates compliance with Software Bill of Materials (SBOM) requirement s and security baseline standards mandated by these frameworks. Innovation and Interoperability • Accelerated development cycles : Companies report faster development as a primary benefit of open source because they can build on existing, tested components rather than developing from scratch. Investment in open source through programs like Horizon 2020 has stimulated innovation in key areas including artificial intelligence, cybersecurity, and cloud computing. • Enhanced interoperability : Open source adoption has improved interoperability between systems across EU public administration, facilitating collaboration and data exchange between Member States. Open standards and open APIs reduce integration friction and enable ecosystem - wide compa tibility that proprietary solutions typically obstruct through deliberate incompatibility. • Community - driven improvement : The collaborative development model means that improvements and innovations contributed by any user benefit the entire ecosystem. Public sector organizations can pool resources to enhance shared solutions rather than each paying vendors separately for simi lar feature requests. Risk Mitigation • Business continuity assurance : With access to source code, organizations are protected against vendor bankruptcy, acquisition, product discontinuation, or strategic pivots. If a commercial open source provider becomes unavailable, organizations can maintain systems independently or cont ract alternative service providers. • Reduced procurement risk : Traditional procurement often goes over budget and over time. Open source solutions available as public goods reduce procurement complexity and provide replicability, allowing governments to avoid "reinventing the wheel" and reduce consultant procurement c osts. • Geopolitical resilience : Europe's reliance on external proprietary technology creates geopolitical vulnerabilities, as demonstrated when GitHub blocked developers in sanctioned countries from accessing repositories. European - funded open source components provide strategic autonomy and reduce exposure to externally imposed standards or access restrictions. Concrete Implementation Examples • Germany's Sovereign Tech Fund : s ince 2022, Germany's Sovereign Tech Fund has allocated over €24.6 million to support more than 60 open source projects globally, focusing on maintenance, security, and resilience of open digital base technologies. This model demonstrates public sector investment in critical infrastructure that benefits the entire ecosyst em while maintaining security and transparency requirements. • Estonia's X - Road : Estonia uses X - Road, an open source data exchange layer connecting public and private services across institutions. In 2024, Estonia released all state - developed software under open licenses, exemplifying "public money, public code" principles and enabling reuse by other nations. • MOSIP Digital Identity : The Modular Open Source Identity Platform, developed in India and adopted in Morocco, the Philippines, and Ethiopia, demonstrates how fully open source platforms can be modular, adaptable, and deployed across diverse contexts without vendor lock - in. • SIST (in P oland) - Implementing systems like SIST (2025) allows the state to inventory its IT assets. Using OSS for such inventories prevents the state from paying for redundant proprietary licenses across different ministries. • • B arcelona's Digital Sovereignty Initiative Barcelona's comprehensive migration to open source aimed to help local IT talent by outsourcing to local SMEs and hiring 65 developers for custom needs, demonstrating how open source supports local economic development while reducing vendor dependency. The city joined the European "Public Money, Public Code" campaign, becoming a flagship municipal example. Assessment Framework When evaluating open source value, the most important factors are: • Total cost of ownership (not just initial licensing but long - term maintenance, exit costs, and opportunity costs of lock - in) • Strategic autonomy (ability to control roadmap, maintain systems independently, and avoid dependency) • Security and auditability (transparency of supply chain, speed of vulnerability response, compliance capability) • Innovation velocity (speed of development, access to ecosystem improvements, interoperability enabling composition) • Risk exposure (vendor continuity risk, geopolitical risk, procurement risk, technical debt from proprietary formats) 3 What concrete measures and actions may be taken at EU level to support the development and growth of the EU open - source sector and contribute to the EU’s technological sovereignty and cybersecurity agenda? 1. Legislative and Policy Actions • "Open Source First" in Public Procurement: Mandate that all EU - funded software projects (at the Commission and Member State level) default to Open Source. Any choice of proprietary software must require a "Sovereignty Impact Assessment" explaining why an open alternative was not viable. Amend EU public procurement directives (2014/24/EU and 2014/25/EU) to establish an explicit "Open Source First" principle, requiring procurement authorities to default to open source solutions unless a suitable alternative is demonstrably unavailable with transparent justification. This aligns with the European Interoperability Framework's emphasis on open standards and interoperability as mandatory criteria. Procurement specifications must prohibit brand - name requirements and compatibility criteria that create de facto vendor lock - in. Instead, tenders should specify functional requirements, adherence to open standards (as defined by EIF), and interoperability obligations that enable multi - vendor competition. • Mandatory Software Bill of Materials (SBOM): Leverage the Cyber Resilience Act (CRA) to require all software vendors selling to the EU public sector to provide a machine - readable SBOM. This increases transparency and rewards OSS projects that already follow high security standards. • Establishment of a European OSPO Network (EN - OSPO): Create a formal coordination body for Open Source Program Offices across Member States. This network would harmonize licensing, security audits, and contribution policies, ensuring that a developer in Poland and a developer in France can easily collaborate on a "European Tech Stack." Strengthen and formalize the EU OSPO Network, which currently connects 13 organizations across 8 Member States to share best practices on open source strategy and implementation. Each Member State should establish a national - level Open Source Programme Off ice with dedicated staff, budget, and ministerial - level reporting to coordinate policy, procurement, and capacity building. The Commission's OSPO, established in November 2020, should serve as the coordination hub providing: standardized governance frameworks and templates; training and certification programs for public sector open source managers; shared legal and licensing gu idance; and regular policy alignment conveying among national OSPOs. This network should explicitly support the transition from isolated pilots to shared, scalable infrastructure. • Mandate "Public Money, Public Code" Across EU Institutions - Establish EU - wide regulation requiring that software developed with public funding be released under open source licenses by default, with narrow and transparent exceptions. This should apply to: all EU - funded research and innovation projects; software commissioned by national, regional, and local administrations; and digital public services and platforms. Estonia's 2024 policy to release all state - developed software under open licenses provides a concrete model. Member States should be required to publish code in accessible public repositories (ideally on European - hosted infrastructure) with appropriate doc umentation, rather than simply making code "available on request" • Address Legal Uncertainty and Licensing Concerns - Provide clear guidance on intellectual property, licensing, and liability frameworks for public sector open source participation, addressing the concerns that 31% of organizations cite legal issues and 24% fear IP leakage as barriers to contribution. Estab lish safe harbors for public employees contributing to open source projects within their official duties, clarifying that such contributions do not create personal liability or unauthorized transfer of government IP. • Expand the EU - FOSSA (Free and Open Source Software Auditing ) framework and bug bounty programs, which currently operate under a four - year €7.7 million contract with YesWeHack. The scope should cover all open source components identified as critical dependencies for EU institutions and Member State infrastructure, no t just Commission - deployed software. Establish a continuous security assessment pipeline with dedicated resources for prompt remediation, recognizing that identifying vulnerabilities without funding fixes creates technical debt. 2. Financial and Structural Support • Establish a "European Sovereign Tech Fund" (ESTF): Modelled after Germany’s successful Sovereign Tech Fund, the EU should provide direct, long - term funding for the maintenance of critical OSS libraries. This is not for "innovation" but for "digital roadworks" — fixing bugs, improving security, and ensuring the stability of the infrastructure that the EU economy relies on. Create a dedicated EU Sovereign Tech Fund with a minimum budget of €350 million over seven years, modeled on Germany's successful Sovereign Tech Fund which has allocated €24.6 million to over 60 critical open source projects. Unlike traditional research fu nding, this fund should prioritize maintenance, security hardening, and ecosystem resilience rather than innovation prototypes. The fund should support infrastructure - layer technologies that are difficult to monetize commercially but provide essential unde rpinning for digital services across public and private sectors. • Open Source "Scale - up" Vouchers: Create a dedicated funding stream within the EIC (European Innovation Council) specifically for OSS startups to "productize" their code (e.g., funding for documentation, UI/UX, legal compliance, and marketing) to cross the "valley of death." • Incentivizing Private Contribution: Provide tax incentives or R&D credits for EU companies that allow their employees to contribute back to upstream OSS projects during working hours. This addresses the "free - rider" problem and strengthens the "human infrastructure." • Expand and Reorient Horizon Europe and Digital Europe Programme : Redirect significant portions of Horizon Europe and Digital Europe Programme funding from early - stage prototypes toward "valley of death" bridging — industrialization, certification readiness, market integration support, and long - term maintenance of successf ul projects. The Next Generation Internet (NGI) initiative has successfully funded grassroots open source across all Internet layers from hardware to applications, but needs enhanced pathways to scale proven solutions into production deployment. Create dedicated funding lines for: security audits and vulnerability remediation; SBOM generation and supply chain tooling; interoperability testing and certification support; community governance capacity building; and documentation and localization to s upport cross - border adoption. 3. Infrastructure and Capacity Building • Sovereign Hosting & Development Infrastructure: Invest in a European Federated Code Repository (a sovereign alternative to GitHub). This platform should be hosted on Gaia - X compliant infrastructure within the EU to ensure that European code, CI/CD pipelines, and developer data are protected from extra - territorial jurisdictions. • "Grand Challenges" for Open AI and Hardware: Launch massive, mission - oriented competitions for open - source foundational models (LLMs) and open hardware (RISC - V). Like India’s "Bhashini" initiative, the EU should fund the creation of datasets and models that are released as Digital Commons • Leverage the Digital Commons EDIC as Implementation Vehicle - The Digital Commons European Digital Infrastructure Consortium (DC EDIC), launched in December 2025 with France, Germany, the Netherlands, and Italy as founding members, provides the legal and governance framework to pool resources across Member States for strategic open source components. The Commission should position DC EDIC as the primary vehicle for: multi - country co - investment in shared digital building blocks; long - term governance and maintenance of common platforms; provision of technical and legal expertise as "one - stop shop"; and creating clear pathways from research projects (like Digital Europe Programme outputs) to European - wide deployment. Additional Member States (Luxembourg, Slovenia) are joining, with Poland and Belgium as observers, demonstrating momentum that should be accelerated through dedicated Commission support and co - funding. • Facilitate Multi - Country Code Collaboration Mechanisms - Build on pioneer initiatives like the EUDI Wallet Architecture Reference Framework (ARF) and Digital Commons EDIC to create systematic frameworks for cross - border code collaboration. Establish: templates for multi - country governance and intellectual proper ty sharing; co - funding mechanisms allowing Member States to pool resources on shared components; and technical infrastructure for collaborative development with appropriate access control and accountability. 4. Education and Talent • Erasmus for OSS Contributors: Establish a fellowship program for young European developers to work full - time on critical OSS projects for 6 - 12 months, fostering a new generation of "Sovereignty Engineers." • Educational Reform: Integrate "Open Source Literacy" into the European Digital Competence Framework (DigComp) . Move away from vendor - specific certifications in schools toward neu