“How can the open-source ecosystem respond to a rapidly changing global world and help shape the shared agendas that will guide it?” That was the question that brought together representatives from the Digital Public Goods Alliance Secretariat and the Open Source Initiative last month at the Open Source Congress in Halifax, Canada.

Across panel discussions, conversations and breakout sessions, participants explored the growing intersection of open collaboration with regulation, cybersecurity, privacy, AI governance and sustainability. The discussions reflected an important realisation: open source is increasingly recognised not only as a way to develop technology, but as critical digital infrastructure shaped by public policy, geopolitical dynamics and security requirements. The Open Source Congress was convened to deepen alignment among ecosystem leaders and extend dialogue to policymakers and industry.

A key takeaway was that standards are where the rubber hits the road. Principles such as openness, interoperability, transparency and “do no harm” matter but their practical force depends on how they are translated into requirements, norms, and evidence. Standards and definitions can help make principles concrete, while governance determines how they are applied, who is responsible and how they evolve.

Regulation and Responsibility

Regulation is now a defining part of the environment in which open source software and digital public goods are built, maintained and deployed. The Halifax conversations made clear that the challenge is not simply whether regulation should apply, but how it is designed and implemented: whether it protects people and systems, provides clarity to users and deployers and recognises the realities of open collaboration and distributed maintenance.

Cybersecurity illustrates the point. Open development can support inspection, collaboration and improvement, but openness alone can not guarantee that a system is secure. Security also depends on responsible maintenance, vulnerability handling, documentation, resourcing, deployment practices and clear accountability across the lifecycle. Regulation can help establish useful expectations, but poorly calibrated obligations can also create uncertainty or place disproportionate burdens on the communities and maintainers whose work sustains shared infrastructure. The open source ecosystem therefore needs to be part of regulatory conversations not only to explain how it works, but to help shape workable approaches.

The EU’s Cyber Resilience Act shows what sustained engagement can achieve. Open source communities actively participated in the European Commission’s consultations and the implementation guidance published in July 2026 provides helpful clarity on key questions for the ecosystem including when open source software is considered “placed on the market”, how maintainers differ from contributors and what is expected of open source software stewards. While some questions remain open and the guidance is non-binding, it represents meaningful progress and demonstrates that community input can help shape regulation that is more practical, balanced and workable for the open source ecosystem.

Privacy and safety raise similar questions. A digital solution that is intended for public benefit must consider how it handles sensitive information, how it may be misused, and who could be harmed by its deployment. This is why the DPG Standard’s “Do No Harm by Design” requirement is not a box to check after development or an afterthought. It calls for attention to risks throughout design and development, and for governance arrangements that are appropriate to the setting in which a system operates.

Standards help connect those expectations to practice. They can clarify which protections and disclosures matter, support consistent assessment and make it easier to identify where a project meets a baseline and where implementation still requires additional safeguards.

What Openness Means

The word “open” can signal important commitments, but it is not self-defining. Access to source code, a model file or a dataset does not necessarily mean people have the rights or information needed to use, study, modify and share a technology. Clear definitions help distinguish meaningful openness from more limited forms of access.

The Open Source Definition (OSD) has long provided this baseline for software. It makes clear that open source is more than source-code availability: its criteria ensure developers are able to use code without restriction and without having to ask the rights holder for permission. It specifically addresses redistribution, source-code access, the creation and sharing of modified versions, no discrimination against fields of endeavour and technology neutrality.

That clarity matters in everyday decisions. It helps developers and users understand their rights, supports reuse and adaptation, and gives governments, funders and institutions a more consistent basis for assessing whether a technology is open source. It also helps prevent the term “open source” from being stretched to cover offerings that do not preserve the software freedoms that this term is meant to convey.

In the current context of a multipolar world, a shared definition does not require uniform policy or identical implementation, but it does give stakeholders with different legal frameworks, priorities and capacities a common reference point and foundation. Clear baselines can make cooperation easier precisely because they help people understand where they agree and where meaningful differences may still remain.

What Openness Means for AI

These questions become especially consequential in the context of AI. A model’s public availability or downloadable weights do not, on their own, show whether the system can be studied, modified or shared in a meaningful way. The training data, code and terms of use all affect whether those freedoms can be exercised.

The Open Source AI Definition (OSAID) applies all four of the open source freedoms to AI: the freedom to use a system for any purpose, study how it works and inspect its components, modify it and share it with or without changes. It also identifies the preferred form for making machine learning systems modifiable: data information (sufficiently detailed information about the training data for a skilled person to build a substantially equivalent system), the complete code used to train and run the system, and model parameters such as weights.

The OSAID strives to bring a shared understanding of how open source applies to AI, so that when someone labels a model or system as open source, we trust that the four freedoms can be exercised. This guarantee is not just a “nice to have” but an imperative, especially for governments, nonprofits, and other organisations working with limited resources and complex political environments.

Key to the OSAID conversation is that AI openness is not the end goal, but an enabling factor to meet critical public interest needs e.g., transparency, innovation, local control. etc.

The DPG Standard Connects the Dots

The DPG Standard draws on the OSD and the OSAID but sets its own bar. For AI systems, it goes further by requiring that training data itself be openly licensed, not only documented. Beyond openness, it assesses whether digital solutions meet a broader set of public interest requirements. Its nine indicators cover relevance to the Sustainable Development Goals; use of approved open licences; clear ownership; platform independence; documentation; mechanisms for extracting data; adherence to privacy and applicable laws; adherence to standards and best practices; and “Do No Harm by Design”, which addresses data privacy and security, inappropriate and illegal content, and protection from harassment.

This is relevant to the Open Source Congress discussions because it brings together several issues that can otherwise be treated separately. A solution may be openly licensed, yet still needs stronger documentation, clearer ownership or better consideration of privacy and security.

Conversely, governance and safety requirements should not be used as vague substitutes for openness or as reasons to impose unnecessary restrictions. For example, restricting access to model weights in the name of safety can also limit independent auditing and research, which are themselves safeguards. Clear criteria make it easier to see how these concerns actually fit together.

The DPG Standard is itself an open standard and maintained by the DPGA Secretariat, governed by the DPG Standard Council, and shaped by contributions from a global community. Its open, iterative approach reflects the principle that standards should be usable and open to improvement. It also has a defined scope: the DPG Standard assesses the design and development of the core solution and not every local deployment. Responsible implementation still requires context-specific risk assessment, safeguards and accountability.

For creators and maintainers, the DPG Standard offers a way to make relevant properties of a solution more legible. For funders and public institutions, it provides a shared reference for assessment. For implementers, it helps identify both what has been addressed in a solution’s design and what must still be considered in a particular context.

Practical Standards to Meet Changing Global Dynamics

The Congress showed the value of bringing open source foundations and public interest digital initiatives into the same conversation. Open source software and DPGs are closely connected, but they are not interchangeable concepts: open source describes important freedoms and licensing conditions, while DPGs bring additional public interest expectations into view and expand beyond software to other categories of digital artefacts. Working across these perspectives can help the ecosystem develop a more coherent response to questions of regulation, security, privacy and AI.

In one session, participants debated how open source can support local adaptation and digital sovereignty without leading to fragmented, incompatible systems. A policymaker on Stakeholder Day asked, “How do we distinguish between healthy localisation and destructive fragmentation?”, which exposed the need for shared foundations that preserve interoperability, security and reuse while still enabling local capacity and context-specific deployment. The DPG Standard offers one such bridge: it sets common expectations for openness, governance, security and privacy, while allowing countries and communities to adapt, maintain and build on digital public goods in ways that reflect their own needs.

That is the practical promise of standards. They do not settle every policy debate, eliminate local contextual differences or guarantee responsible outcomes, but they can help make commitments more actionable by clarifying what openness means, what information supports evaluations, what safeguards must be considered and where governance and deployment choices make a real impact. Standards and definitions provide consistency for open technology decisions when other factors are unsettled or changing. They help align principles and practical expectations so that cooperation across regions, institutions and communities can flourish.