Adding FOSS requirements to funding calls

robbie.morrison · 29 July 2026 14:55

Release 02 30 July 2027 WorkingDoc

Anecdote suggests that both science funders and non‑profit organizations who support software projects are increasingly insisting that the outputs be free and open‑source (FOSS).

It is straightforward to specify that a project should make any resulting code publicly available under an approved open‑source license.

However, it is more difficult to mandate that a grant recipient create a public repository that is suitable for community development and has some prospect of being maintained.

This is very different from the mere act of “throwing the code over the wall” — a term used in the FOSS world to describe making one’s source code public without the intention to create a viable development project. When a simple record is sufficient, this works. The code can be tarred and uploaded to an academic archive or pushed to a static public repository on GitHub or elsewhere.

This posting examines the other end of that spectrum. This material was inspired by a recent conversation on this same topic within an open source legal community that I participate in.

Most of the key issues revolve around project governance.

I have intentionally avoided questions of AI code generation and the wider use of AI for tasks such as documentation and user engagement. Nor have I covered matters related to data management generally and personally identifiable information (PII) more specifically.

FOSS project health metrics

It is useful to first talk about what might constitute a healthy project.

The Linux Foundation CHAOSS project (referenced below) provides some advice and metrics. The GitHub Minimum Viable Governance project (MVG) provides a git repo meant to instantiate sane defaults for projects or organizations wanting to get off the ground without the need to start from scratch. The REUSE project from the Free Software Foundation Europe (FSFE) offers guidance and an informal standard covering open licensing best practice.

Governance

As project governance is a broad and sometimes contentious topic, I will restrict myself to general observations.

Project should have a governance document that details how it nominates individuals to become core committers, reviewers, and serve other community roles, how it accepts patches from arbitrary submitters, and how it plans to resolve security issues. Transparency should be traversed as well, including how verifiable instances of governance processes are to be reported and archived.

FOSS projects that commence after November 2027 and offer their software for distribution within the European Union may need to comply with the EU Cyber Resilience Act (CRA). FOSS projects which lack commercial intent — essentially that accounting profitability is not sought — may well fall under statutory exemptions. That said, some exempt projects may elect to follow CRA statutory reporting in a voluntary capacity to assist their downstream userbase with conformance.

Matters for funders to traverse

In addition to the question of choice of license, a funding organization that would like to promote some groundwork leading to an ongoing viable open‑source project might ask applicants to provide the following:

For new projects:

an outline of proposed governance

For extant projects:

the existing governance documents
proof of due diligence regarding copyright holders and license compliance

For all projects:

a statement covering CRA compliance and any statutory exemptions that might apply

The funding organization might also consider making the following requirements mandatory:

REUSE compliance

REUSE compliance is a straightfoward process, especially for new projects. It is lean and well documented and very much helps the people working on the project make sure their project’s license(s) are documented in a standardised and verifiable way. Additional effort on projects is negligible - IMHO a no brainer.
CRA compliance: Very tricky and might evolve as the projects goal and uses change. Also not always something that the people working on the project control, as there might be others commercially offering the results of the project and thus appearing as manufacturers. Still a good idea. But I find wrapping my head around it and figuring out what applies and how everything else but trivial. Adding this is responsible, yes, but includes overhead and likely requires professional assistance, also given the implications that incorrect implementation can potentially have.
Governance: Needed if a sustainable FOSS project is desired and the intention of forming a community exists. I would argue that not all projects fulfill this criteria. A second aspect is that forming and maintaining a community does require ongoing effort and is something for the long game. I think the expectations should be made clear before a project is granted - community or no community - and the grant should reflect that appropriatley and support a long game if desired.

As someone who is currently involved in setting up a Governance for a certain organisation, I find it challenging to account for the very different aspects that go into setting up one. It is nowhere as trivial as picking a license for a project or deciding on a tech stack. Looking and working through various existing governance documents I have yet to find a blueprint that could be used or at least adopted. If a funder was to require a governance structure, I believe they should also make example or default governance structures available. Not only to make it simpler for the projects that they are funding, but also to avoid a) unnecessary repeated work from all projects they are funding, and b) governance hell, where we have custom governance models everywhere (it’s like licenses, but with people!)

robbie.morrison · 1 August 2026 23:41

Some news from the United States that relates to this thread, albeit at a somewhat larger scale.

The US National Science Foundation (NSF) is calling for proposals under its Pathways to Enable Secure Open-Source Ecosystems (PESOSE) program. Available funding is USD $40 million. Quoting from (emphasis added):

NSF (19 February 2026). Pathways to enable secure open-source ecosystems (PESOSE). US National Science Foundation (NSF). Alexandria, Virginia, USA.

The Pathways to Enable Secure Open-Source Ecosystems (PESOSE) program supports the translation of open-source science and engineering-focused research products into safe and sustainable ecosystems that address national and societal challenges. Open-source tools such as software, hardware, machine learning models, languages, and data platforms are designed to be shared as they are publicly-accessible and modifiable. These tools spark innovation in critical fields as varied as artificial intelligence (AI) and cloud computing, banking, healthcare, research, education, next-gen manufacturing, mobility, and National security (including cybersecurity).

PESOSE supports the creation of managing organizations for these ecosystems, ensuring strong governance, distributed development, and broad user communities across academia, industry, and government. PESOSE also supports enhancements to the safety, security, and privacy of Open-Source Ecosystems (OSE) by addressing significant vulnerabilities, both technical and socio-technical, to improve the resistance of the ecosystem against threats.

▢

Adding FOSS requirements to funding calls

FOSS project health metrics

Governance

Matters for funders to traverse

Further reading