So, the response I wrote to the European Open Digital Ecosystems call for evidence turned out to be about five times longer than the character limit for the feedback prompt. However, there was also an option to submit .odt and .pdf files, so I was able to submit my response in full.

The response took weeks to write, with many of the points thoroughly discussed and explored before being put into writing. I decided to post it here as well because it is an important topic to discuss. As with any exploration of a topic, some nuance is inevitably lost, despite my efforts to be precise while trying to encompass the entire digital chain.

I also had help from a co-writer to finish the response because I got the flu with three days left before the deadline and was basically bedridden until today. Also, if you haven’t shared your thoughts yet, you still have until midnight today.

---

There are great obstacles to widespread adoption of open source and its subsequent thriving in the EU and its market. Further details on these will be explained later in the key objectives section. But before we look at what we could or should do, let’s briefly look at the consumer’s place and options in a European open digital ecosystem. Because, in a sense, open source is already thriving in the EU, as well as the rest of the world. Every server, router, and cloud service does either in full, or in major part, run on open source software, protocols, and/or code. Because all the major players have realized that they all gain from sharing and contributing to it. Their finished product isn’t necessarily open source, but its foundation is built, or rests, on it. With the end consumer, the choices and options are often only surface level, and I’m using consumer here because not all who interact with software or services are “users”. We, the consumers, are often forced to interact with applications, services, and systems out of necessity rather than choice. Participation in digital society today is, in practice, compulsory rather than optional. This will, if it hasn’t already, lead to a process in which an individual must sequentially accept non-negotiable contractual constraints imposed by multiple independent corporations, often across jurisdictions. In order to perform a mandatory (or because the alternative would effectively “soft-lock” the individual out of the system) civic or economic function, each acceptance irreversibly alters the individual’s legal rights in practice. This creates what can be described as compelled rights violating dependency chain. While we have very strong and clear legislation, such as COUNCIL DIRECTIVE 93/13/EEC ¹, enacted to mitigate these types of EULAs within the EU , the risk is, however, still present for the individual consumer due to the resource disparity. Having citizens forced into accepting EULAs with entities outside of the EU in order to participate in our society, solely because the alternative is non-existent, creates this rights-violating dependency chain that perpetuates those same actors monopolistic standing, which in turn, hampers the EU’s security, sovereignty, resilience, and prosperity, as well as very competent internal players. If, at any point in the chain, consumers must consent to waiving their rights to their data and usage analytics in order to participate as functioning members of society, then such “consent” is fictional. Let me pose this simple question: What options does the average citizen have to partake in our digital society, and what services are they required to interact with to remain functioning members, or to access services to sustain them (medical, civic duties, social security, taxes, etc.)? Once identified, focus should be placed on ensuring viable European open source options, not reliant on external (ergo non-EU) services, are available for EU consumers and citizens. This will require implementing open source systems throughout our public sectors, all the way down to the consumer platforms. This would shore up our citizens digital rights, while ensuring robust cybersecurity audits are possible through all links in the chain. Re-tooling agencies with open source alternatives is not the largest hurdle to European digital sovereignty, resilience, and security. It’s a large hurdle, and challenges awaiting us in this space should not be underestimated. However, the largest and most important hurdle is consumer adoption of open source alternatives and EU-based alternatives. Because consumer adoption requires allure. The alternative supplied can’t just be the better option on paper. Plenty of failed products throughout history have been the objectively better options when viewed as a whole, but had too much friction for individual consumers to adopt. The friction that hinders adoption of an alternative or new product can be everything from price to ease of use, ecosystem, availability, compatibility, or even current adoption rate. All of these friction points can of course be mitigated with various means. But to effectively mitigate these frictions to adoption, they must be considered early and influence how and where we put our efforts. For us to be able to take full advantage of a European push for open source, Directive 2001/29/EC Article 6 needs to be revised, firstly to ensure digital sovereignty and avoid externally imposed artificial digital scarcity during European build-up and re-tooling. An advantageous economic side-effect of this would be domestic actors being able to take advantage of the new market opportunity created, offering open source EU alternatives for EU consumers seeking service, support, and software alternatives to devices they already own from external hardware suppliers. On 2022-05-05, Deutsche Welle reported that John Deere remotely disabled farm equipment stolen from Ukraine ². If the American-owned market leaders in farm equipment in Europe were to be pressured by their government to disable equipment owned by European farmers, it would be disastrous for us. It is imperative that we have secured the tools to counteract such a scenario, to avoid finding us in a situation where we are forced to reactively scramble to un-brick ~14 Billion EUR worth of combined harvesters. This is not to mention the massive security risk posed by extraterritorial legal exposure, namely the CLOUD Act.

POINTS FROM FEEDBACK INITIATIVE

Key objectives include: - continuing development and ensuring appropriate visibility of EU high-quality and secure open-source solutions and demonstrating their added value;

EU should not try to reinvent the wheel. There are plenty of established open-source projects that could either in full or in major part be deployed as is. For consumer desktop platforms there are OS-distributions like Debian and Redhat that are not only the base for many variations Linux but also very matured and established. On the mobile platform the options are fewer and unfortunately only two end consumer viable options. Although Android OpenSource Project - AOSP might at first glance seem like the best option to fork and create a EU driven version of (there are some forks of AOSP already trying to realize this). The fact that we are missing a third viable option for end consumers hampers competition, agility, and consumer choice. The reasonable choice here would be to support a mobile mainline Linux distribution such as Sailfish OS, which today struggles with adoption due to lack of software availability within the ecosystem, and are forced to maintain a compatibility layer to offer end user functionality.

The same would hold true for public entities, and agency’s within EU, one way to ensure the same solutions aren’t invented by multiple independent actors, thereby not taking advantage of the cost savings, faster development, and interoperability that comes from utilising open-source software ^3, could be by setting up public sector domain interest groups. These public sector domain groups main purpose could be to evaluate and formulate requirement assessments and guide development for their interest group. They could also collaborate with each other on projects or questions that are relevant for multiple areas.

- addressing issues of deployment, usability, software supply chain security and governance, maintenance of code and project sustainability to ensure take-up and upscaling;

Complete adoption of open source within the public sector would, de facto, create favourable conditions to govern and ensure the security of the software supply chain, while at the same time enabling agile and stable maintenance of code. This is due to the intrinsic nature of open source; it can be forked, audited, and contributed to by anyone, thus mitigating the risk of software being suddenly abandoned or left unsupported because the corporation owning the software dropping support due to profitability concerns or going out of business. While in the short term the cost of migration might be higher than the current rolling costs of maintaining closed-source solutions, in the long term open-source solutions will be the cost-effective option, especially when these solutions can be reused and modified freely. Thus, the cost becomes balanced across the market rather than requiring the same entry toll for every purchaser of the same closed-source platform.

Vendor lock-ins are by far the largest hurdle for the public sector(goverment agencies) and European corporations.

- supporting emerging open-source business and sustainability models for open-source companies and foundations, including by developing public-private partnerships;

While this might be outside the scope of this feedback initiative, we within the EU need to collectively be able to assign certain EU-owned corporations, producers, manufacturers, or service providers as “strategic” and prohibit them from being sold off to investors or actors outside of the EU. The recent loss of Arduino as a strategic European corporation, after the Qualcomm purchase, is a perfect example of this. This left the EU without a key strategic internal integrated chip designer and manufacturer. This void needs to be filled for both civilian and, by extension, military sectors. One way EU could support open-source businesses could be a EU-driven co-op consisting of public entities from all member states that acts as a producer and/or customer of open source software solutions and open source hardware components. This co-op entity could also act as one part of the strategy to along side public sector domain interest groups to promote and support emerging businesses, companies, and foundations by extending grants, offering bounty programs, and purchasing solutions, products, and services from internal actors. Monopsony is not new to industries or sectors of our economies that are of strategic value, and while European open source development does not necessarily have to be fed by one entity, certain projects could very well require it, and we should not dismiss it as an option for strategic resources, be they microcontrollers, integrated systems, or management services. One other benefit of such a co-op would be the negotiating power it would wield when purchasing contracts for hardware solutions not available internally on behalf of the member states and their institutions, imposing EU-aligned values and policies on corporations by acting as the gatekeeper to a very substantial market. This co-op could also help different public sector domain interest groups balance costs by identifying aligned needs across the market or shared code base. Another option for a large-scale solution to to the public-private partnership development could consist of setting up alternative revenue models for new and emerging actors. By setting up tiered based on offerings scale, from simple-to-receive models with short-term proof of work and deliverables, to harder and more stringent approval procedures for large-scale projects with long time frames before results can be presented. Examples of this for simpler, lower-tier projects could be an agency hosting a Codeberg/Git repository for their custom implementation of Open HRMS ⁴ and asking for added functionality from outside contributors with a bounty, granting the bounty to the author of the pull request that gets committed. The previously mentioned public sector domain interest groups could also make use of this co-op entity’s market position to set up contracts, based on their requirement assessments, with internal actors for projects that require specialist competencies or integration normally outside of their scope.

- promoting best practice and encouraging the public sector, specialised business sectors and large customers to contribute to and adopt open source;

If the EU mandates that all internal government systems, as well as public-facing portals and platforms, are open source, it would create significant opportunities for existing and potential internal actors to support and maintain these systems. Cross-integration between sectors would also be greatly simplified, since the code would not be hidden behind a veil of secrecy and prohibition. One agency’s internal development work could be applied or modified by another. Both development and code audits would become essentially collectivized and distributed across all sectors and actors, lowering costs and simplifying integration and policy alignment, with the added benefit of creating a more accessible environment for future startups and the formation of new agencies, foundations, etc.

- supporting market integration, especially with legacy systems and policy alignment

With a Fund or Fork methodology, meaning that the EU could support open-source projects both internal and external that we deem useful or strategic, with the added benefit of being able to have influence on these same projects policy alignments, by financially secure development. While still maintaining control over governance by having the option to fork, if the project deviates or strays to far from EU policies and values.

Another area were we the EU should put effort is our digital civilian defence, with alternative network stacks such as reticulum ⁵ to ensure functional communication and continued civil operation during emergencies affecting our infrastructure.

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;

Vendor lock-in for the largest service providers. Both public institutions and private companies are stuck in ecosystems provided by a few vendors. This relates to both operating systems for desktops and mobile devices with the accompanying software, but mainly through the interconnectedness of cloud services provided by these vendors. Much of the digital infrastructure of European companies is run on hardware provided by a handful of non EU-providers. These vendors provide whole, interconnected ecosystems with everything from identity providers, “serverless”, catalog-services for authorization, virtual networking, storage, security, secrets management. Although these services are provided by multiple vendors it is not trivial to move between them, unless the infrastructure was specifically designed for to be multi cloud. Even then multi-cloud setups mainly focus on switching between a few of these vendors. Since these vendors provide specific interfaces, terminology and technology, experience with one vendor does not directly translate between them, further increasing the risk for vendor lock in. There are many open source alternatives to the specific services that are provided by these vendors, however none provide a full, realistic alternative with the full range of services, technology, and flexibility of these vendors. While there are mature open source cloud solutions, there needs to be services that can provide this capability the same type of robustness, support and ease of use as the non- EU Competitors. Further more EU needs to support projects to be able to migrate the infrastructure that has already been built for other cloud vendors. These kinds of projects could focus on converting IaC (infrastructure as code, for example OpenTofu now that Terraform is no longer open source) from vendor specific to Open Source Cloud services. While it is possible to use LLM- based text generators for this, a robust, well tested, trustworthy solution is needed, as well as a European one. Besides the conversion of the infrastructure specification, projects that aide in migration of blob-, and secret-storage. By encouraging these European cloud providers to use open source cloud infrastructure, it will also ease the adoption of private cloud and hybrid cloud solutions as these will use the same technology.

(ii) and sustainable contributions to open-source communities?

EU could identify critical or important open source projects and support them by either providing funding directly, or by committing developer time.

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.

Having much of EU’s private and public infrastructure hosted and controlled in potentia by non EU vendors is that in the event of geopolitical conflict, that infrastructure is made unavailable, temporarily or permanently, resulting in capital loss, loss of revenue, and loss of vital services for parts or most of the European market. While this scenario may seem unlikely due to the negative consequences it would have for the global market, including the potential adversary, the parable of the frog and the scorpion comes to mind with increasing frequency since 2016, and as such it might be advisable to avoid it be possible in the first place.

Encouraging organisations in the European public sector to not only use open source, but also to actively publish internally developed tools as open source would provide an opportunity for other organisations, on EU, national, and regional to benefit from that work and to contribute to it. Many of EU’s institutions are engaged in similar tasks in their respective domains, and most of their needs will be identical, while not all. Therefore encouraging these projects to adopt modular architectures, designed for such cooperation, with for example a common core functionality and organisational specific modules, would ease the adoption and development of effective tools, while harnessing the competence that is found across the continent.

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?

Support the creation of EU based full stack, open source cloud service providers that can realistically compete with the non-EU competitors.

Encourage public organisations to cooperate with each other within their domains to produce the tools they need based on a common core, and to open source the tools they have already created.

Support and fund security research into public open source projects and security mitigation projects. Identify critical open source projects, such as those underpinning other infrastructure, basic functionalities, or those with very large market share and fund security research and security mitigation projects to support those projects.

4. What technology areas should be prioritised and why?

Cloud Infrastructure, Operating systems for consumer devices and governmental services.

5. In what sectors could an increased use of open source lead to increased competitiveness and cyber resilience?

Supporting interoperability between different cloud technologies to ease movement between vendors, even open source European ones, will create incentives for those EU vendors to compete on quality of service rather than another lock-in, and fostering healthy competition in the market.

1: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A01993L0013-20111212

2: https://www.dw.com/en/ukraine-how-farm-vehicles-stolen-by-russia-were-remotely-disabled/a-61691839

3: https://www.linuxfoundation.org/research/measuring-economic-value-of-os

4: https://github.com/CybroOdoo/OpenHRMS

5: https://github.com/markqvist/Reticulum