DevRoom organisers welcome all to the Legal & Policy Issues DevRoom
Legal and licensing issues are a vital part of the Free Software ecosystem. While many Free Software developers may have a good idea of the legal and licensing requirements that turn their project into Free Software, there are many more attending FOSDEM who may lack the knowledge or have misconceptions about the legal issues in Free Software.
This session hopes to provide an introduction and background to the legal concepts that underpin the freedoms in Free Software, and how the law is an important tool in ensuring our digital freedoms, so that participants can better appreciate the legal and licensing issues to be discussed by speakers in the Legal and Policy Devroom.
Open protocols underpin much of Europe’s digital infrastructure, yet they remain a blind spot in European digital policy. This talk highlights why supporting open protocol governance is crucial for Europe’s digital sovereignty, interoperability, and innovation. It explores how policymakers and developers can together address this gap by recognising protocols as foundational infrastructure and shaping policies that enable resilient, interoperable, and decentralised systems.
In 2020 the Dutch government adopted the 'open, unless' principle, promoting the use and procurement of open source software, unless impossible. But what happens after such a policy is published? This isn’t as straightforward as we’d think. Within government projects, we still regularly need to answer practical questions such as “are we allowed to build or buy this? Are we allowed or required to publish our code? What do we need security wise? What do our procurement policies say? Where do we put the code? Does code need to be archived like documents? How do we collaborate with other government tenants? And how do we support the open source communities whose code we use?” The ‘open, unless’ principle is clear on paper, but applying it turns out to be more complex.
In this talk, we will look at how the Dutch are putting 'open, unless' into practice inside the Ministry of the Interior (BZK), through the daily work of our Open Source Program Office (OSPO). Instead of focusing on just policy, the focus is on the operational side. Once the choice for open source is made, what challenges arise then? This will be illustrated with concrete project examples. The first is MijnBureau, a sovereign open source workspace for the government, that has been built openly from the start. The second example is the Dutch Government Codeplatform, a shared development environment, based on Forgejo. A third example is OpenKat, a collectively built open source vulnerability scanner. Together we’ll explore how 'open, unless' is applied in a consistent way (spoiler alert: it’s not).
These examples show what “from policy to practice” actually looks like for the public-sector. For instance, many open source projects start bottom-up. How do we ensure proper top-down alignment with national strategies, adequate funding and sponsorship? When a project is done, who is going to manage and maintain it? How do we make sure we don’t take advantage of open source communities?
This talk is aimed at anyone interested in public-sector open source, OSPOs, procurement and policy implementation, or in understanding why “just publish code” is rarely as easy as it sounds, and what we can do to make it easier.
Open source initiatives usually bubble up from the grassroots community, and while governments have been paying more attention recently, policy is often subject to the whims of election cycles. This means long-term continuity is never guaranteed.
Even when policies are in place, their implementation can be hampered by two significant factors: civil servants' open-source literacy and existing legal/regulatory bottlenecks. Sure, enshrining open source into law would make it mandatory and sustainable, but let’s be real—the legislative process is painfully slow.
The Open Culture Foundation (OCF) has been deeply embedded in Taiwan’s open source scene for over a decade. Some of our members have been tracking the government’s on-again, off-again open-source journey for nearly 30 years, since the early community days. Others have even moved from leading government open-source policy to eventually return to the non-profit sector. Throughout this journey, OCF has continually adapted how we collaborate with and support the government, seeking the best communication strategies and case studies—all while managing the inevitable cycles of disappointment and excitement.
Most recently, we saw Audrey Tang depart from the Ministry of Digital Affairs (MODA), and the government's visible focus on open source has noticeably dialed down. However, we also found like-minded partners in the Taipei City Government's Department of Information Technology (DOIT). We are now working with them to ensure that open source software continues to be adopted and deployed within the government.
In this 30-minute session, we’ll be sharing the different collaboration models we’ve developed with the government and the tangible deliverables we’ve produced. Crucially, we’ll also discuss how we keep the momentum going and move forward even when we face headwinds.
In this Q&A session we will address all the questions our audience might have on the CRA in relation to Free Software. We will kick of the session with a short introduction focussing on current challenges around the implementation of the CRA with a specific focus on Open Source Stewards and Attestation programs and how and where financial support is needed in order to make the CRA work.
Software Freedom Conservancy (SFC) sued Vizio in October 2021 because Vizio did not provide the required source code for the GPL and LGPL works that Vizio chose to use in its TVs, preventing SFC from making privacy and security enhancing changes, among other improvements that the GPL and LGPL require that companies allow in devices they sell. SFC brought the case as a third-party beneficiary of these copyleft agreements, to demonstrate how users of copylefted software can directly enforce the agreements if a company fails to comply.
The trial in this case was to finish last week, but a last-minute delay by the court means the trial will happen later this year instead. In the meantime, we'll discuss the case so far, including notable technical points about what Vizio did and didn't provide, what arguments have been made, and what we're likely to see at trial. We look forward to your questions and discussion around this historic case for user rights!
A number of countries are introducing "online safety" laws, which generally impact providers of online services. An example of these is the UK's Online Safety Act 2023.
It purports to have extra-territorial effect, applying to anyone, anywhere in the world, who provides a service to people in the UK, if certain criteria are met.
While the ostensible aim of these acts is to address concerns relating to the largest social media providers, they are not always well drafted, or else are drafted intentionally broadly, and catch all number of services which are used commonly by FOSS projects, including self-hosted projects.
For instance:
I have spent far too much pro bono time this year working with FOSS projects to help them with the Online Safety Act 2023, working out whether it poses a realistic risk to them, and what, if anything, they might want to do about it.
I've also produced onlinesafetyact.co.uk, as a free, CC-licensed, resource, which has been well used as far as I can tell.
This talk will:
This panel will bring together policy/legal experts and enforcement officers from the European Commission to discuss how the Digital Markets Act (DMA) applies to Apple’s iOS/iPadOS and Google’s Android from the perspective of interoperability.
In particular, the panel will deal with the European Commission's recent decisions in regulating hardware and software interoperability for Apple’s OSes. The audience will learn what interoperability under the DMA means for Free Software developers, and how they can expect the interoperability solutions to be provided by gatekeeper companies like Apple and Google.
More importantly, the discussion will address relevant questions for the effective implementation of the interoperability obligations in the DMA, including:
The panel will be composed by:
Panel moderation: Lucas Lasota, Legal Researcher and Lecturer at the Halle-Wittenberg University.
The language will be English.
We had a canceled session: a wonderful opportunity to crowd source a topic! What would you like to hear about? What is the hot topic you don't already see on the schedule?
Let us know what you think by filling out this form, or by writing your suggestion on a piece of paper and handing it to one of the Legal & Policy Devroom organizers.
https://sfc.ngo/idea
FOSS communities have historically developed governance models that include within them biases and other problems, often belatedly recognized. For example, there is now general agreement that no dictator can be benevolent. Common alternatives to the "benevolent" dictator— the "meritocracy", "do-acracy", and the self-perpetuating committee — also have serious problems. Often the alternative offered to these kinds of governance systems is for some kind of elected governance body.
Democratic governance institutions are messy, however. We'll consider some historical examples of problems that have occurred in various democratic FOSS initiatives and organizations, and will focus particularly on the Open Source Initiative (OSI) board of directors elections of 2025. We'll consider the question: how can we design elected governance bodies for FOSS that truly represent the views of our community and are held properly accountable to their constituencies?
Joe 'Zonker' Brockmeier will moderate this panel, and additional individuals have been invited and will be added once they are confirmed.
Clean-room design is a method of recreating and relicensing software without infringing any of the copyrights. So what happens when we use LLM's to recreate thousands of open source projects in seconds, and relicense them all to more permissive licenses?
We first started looking at this when in 2025 MongoDB used an AI agent to take thousands of lines of code from a copyleft project, and used Cursor to recreate and relicense it all under apache. The prompts used to do this were left in the repository.
What does it mean for the open source ecosystem that 90% of our open source supply chain can currently be recreated in seconds with today's AI agents?
In this talk we will be demonstrating the process of large scale clean rooming, and explore what it means for open source, and what it means for community.
What happens when your project grows up faster than you do?
The dynamics of the FOSS world allow for young and passionate developers to make real, lasting contributions; sometimes in places where they would otherwise never be taken seriously. As The Register put it, Rhino Linux was started by a "teen dream team". We had a bold, fast-paced start that threw us headfirst into the world of Linux maintainership. But while we shared the common goal of 'growing and improving' the distribution, our individual visions often diverged.
Being taken seriously has its burdens, too. It's easy to get in over your head - to lose direction, burn out, or stop communicating altogether - especially when there are no adults in the room to offer guidance. We banded together by chance, and had to discover our own limits through trial and error. Saying 'no' isn't easy, especially under the internal pressure to keep delivering at a steady pace, when everyone is deeply passionate about the project.
FOSS is no stranger to ever-shifting team dynamics, or to developers biting off more than they can chew; challenges that are only accentuated when all involved are still growing up. It's easy to lose sight of when to step back, and when to recognize the need to scale. As we have come to learn, if you want to be a systems maintainer, you need to maintain your own systems, too.
Join us as we retrace the human side of Rhino Linux - how we learned to build a team as young developers, what this project taught us about maturity, communication, and sustainability, and the lessons we hope others like us can take from our journey.
The four essential freedoms defined by the Free Software Foundation — freedom 0: the freedom to run the software; freedom 1: the freedom to study and change it; freedom 2: the freedom to redistribute; freedom 3: the freedom to distribute modified versions — are widely cited as the foundation of free software. https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
But what does “freedom” mean when people with disabilities cannot meaningfully use, extend, and share software? Digital sovereignty is hollow unless the tools and communities respect accessibility. If a user interface or workflow excludes a segment of users, then the right to “run” or “modify” the software is in practice restricted.
This talk argues that accessibility (in code, UI, documentation, communities) is not an optional add-on — it is essential for the exercise of the four freedoms, and thus for true digital sovereignty. We will explore how CMS projects can embed accessibility into their governance, workflows and contributions so that every user can exercise the freedoms of use, study, share and collaborate.
It is great to see GitHub making significant efforts to improve their accessibility, and that of the tools that they give to the community. https://accessibility.github.com/
https://github.blog/open-source/social-impact/our-pledge-to-help-improve-the-accessibility-of-open-source-software-at-scale/
We will cover: • How exclusion of users with disabilities limits freedom of software use and modification. • The link between accessibility and community inclusivity: if you cannot participate fully, you cannot help shape the software. • Practical steps for CMS ecosystems (Drupal, WordPress, etc) to make accessibility a governance norm rather than a compliance afterthought. • A call to action: build tools, policies and default workflows so that accessibility becomes part of the infrastructure of freedom.
Open source communities thrive when every contributors can participate fully and safely. Neurodivergent contributors bring unique strengths such as pattern detection, hyperfocus, creativity, and non-linear problem-solving. But they also face invisible barriers that can limit their access and growth. This talk explores practical scenarios for fostering neuroinclusive communities from onboarding and mentorship to culture-building and leadership. Attendees will leave with lessons they can apply in their teams, projects, and meetups and welcome every mind within their communities.
In the last several years, a number of open source companies have attracted significant attention after announcing license changes. Not surprisingly, these shifts sparked backlash from open source enthusiasts, prompting some to create community-driven forks under open source foundations.
Now there is growing skepticism toward (single) company backed open source projects, with many arguing that open source projects should be run by neutral foundations to prevent future bait-and-switch tactics. But is foundation backing really the answer?
Drawing on over a decade of experience in both open source foundations and companies, Fatih and Ray will compare foundation-backed and company-backed projects across key areas such as governance, roadmap planning, community, and funding. They’ll explore real-world examples of successful—and not-so-successful—projects in both models.
Finally, Fatih and Ray will discuss why funding models should be just one of several factors in assessing the long-term viability of open source projects. They’ll offer a holistic approach for evaluating open source projects, helping developers and decision-makers make informed choices about which projects to adopt, support, or contribute to.
Ten years, 1,600 release votes, and a clear lesson: open collaboration works. Discover how Apache Incubator projects turned release reviews from rule-checking into mentoring, and what this decade of data reveals about building healthier open source communities. Description: What can we learn from a decade of release votes in open source communities? From 2015 to 2025, over 1,600 Apache Incubator release vote threads showed how project collaboration and growth have changed. In this talk, I’ll share practical lessons from analysing votes across more than 160 projects. You’ll see how better documentation, mentoring, and automation changed a stressful compliance process into a positive learning experience. You’ll learn about the changes: fewer rejections, quicker reviews, and a shift from a strict to a more collaborative tone. I’ll also discuss how release cadence reflects community health and what early warning signs to watch for before a project slows down. Whether you’re a maintainer, mentor, or contributor, you’ll come away with ideas to improve release workflows and help build stronger, more confident communities.
As open source became mainstream, companies started to allow or even encourage their employees to get involved upstream and even started to open source their projects. Having more people being paid to work on open source software sounds great at first. However, when people don’t get the education and support to integrate upstream work and mindset into their daily work the open source projects, and eventually the boarder ecosystem, suffer.
This phenomenon affects everyone from single-vendor projects to diverse communities, and from small projects to large communities, and eventually contributes to maintainer shortage and burnout. Addressing this is the responsibility of both individuals and corporations. So, where should they start?
This presentation will outline the different ways how corporate mindset and priorities harm open source projects today, including tasks and responsibilities in open source projects that fall short and obstacles that maintainers face on a daily basis. Attendees will learn what individuals can do to improve their own and their communities’ experience. Last, but not least, the talk will provide tools to educate employers about why and how maintaining key open source dependencies is strategic for a successful business strategy.
Many open source contributors, maintainers, and communities are anxious about the Cyber Resilience Act (CRA) and its potential impact on open source. It’s easy to feel that these obligations aimed at commercial vendors will somehow end up falling on volunteer maintainers, community projects, and the broader open source ecosystem. But that's not the whole story.
Thanks to strong, coordinated advocacy from the community, the European Commission actually understands the open source ecosystem far better than many believe. The CRA not only clarifies where responsibility lies—squarely on the vendors who profit from open-source components, as it should—but also introduces meaningful tools to improve sustainability, including the new attestation program, which has real potential to channel support back into the ecosystem.
A well-designed law, however, doesn’t mean there will be no impact.
Drawing on direct involvement in the CRA implementation process through the ORC WG and the CRA Expert Group, Tobie will walk through how these changes will affect open source communities in practice, why the underlying structure of the CRA makes sense, and how the open source communities can position themselves to benefit from it if they so wish to deliver more secure software more sustainably.
AI-assisted contributors can now produce patches that appear senior at first glance: fast, polished, and surprisingly complex. But many of these contributions arrive without the context, intent, or architectural understanding that maintainers rely on during review. This emerging pattern — the rise of the “Synthetic Senior” — is reshaping expectations around mentorship, review culture, and long-term project sustainability.
Maintainers face a growing dilemma: welcoming new contributors while navigating an influx of high-volume, low-context PRs that demand deep review time. Traditional mentorship doesn't scale to this volume, and without new guardrails, it’s a recipe for burnout. While platforms, including GitHub, iterate on systemic solutions to filter this noise, communities need immediate, practical strategies to protect their maintainers today.
Drawing on discussions with seasoned maintainers and data from AI tooling pilots across open source foundations, this talk offers community-centered strategies for adapting to the AI era without losing what makes FOSS resilient. We’ll explore:
This session isn’t about banning AI. It is about building the guardrails that protect human mentorship and keep free software communities healthy.
Security tools don’t always fail to catch on because the tech is flawed. They more likely fail because the human connection is missing. When developers are treated like compliance checkers instead of collaborators, the result is frustration, pushback, and ultimately, insecure software.
This talk invites security folks to move from gatekeeping to enablement, and makes the case that the missing ingredient isn’t better code, it’s better relationships.
Developer Relations can be the spark that turns security tools from roadblocks into superpowers. By meeting developers where they are, offering context instead of noise, and partnering rather than policing, DevRel brings security into the conversation early and often, raising adoption rates and strengthening security across the open source ecosystem.
Has the once vibrant and much-loved cloud-native community lost its spark? What was once an ecosystem fueled by collaboration and curiosity now feels increasingly defined by Slack channels, swag drops, and conference booths.
Despite an explosion of meetups, and events, audiences are thinning. Community fatigue is real and vendor influence often overshadows genuine grassroots participation.
Contribution activity has slowed, and several once-thriving open-source projects are experiencing a contributor drought. End-user organizations and sponsors that once championed community contributions are now scaling back, leaving critical projects struggling to sustain.
This talk takes a candid look at the past, present, and possible future of the open source community. Through data and insights from a few popular OSS projects we’ll explore the patterns behind this shift and what it means for the sustainability of open collaboration in the years ahead.
Headscale began as a learning project to work out “what was needed” to re-implement a Tailscale control server and unexpectedly exploded in popularity in the self-hosted and open source community as a home-labbers alternative to Tailscale.
Headscale has a vibrant community, about 6000 members in our Discord community and our Github repo has more stars than Tailscale’s open source client, but who's counting.
Three years ago I was hired as a member of technical staff at Tailscale, spending half of my time contributing and driving Headscale, ensuring the future of the project.
Headscale is a clone of Tailscale’s closed-source SaaS control plane, and it would be easy to consider it a competitor. Tailscale supporting Headscale this way is an unusual arrangement and sometimes raises eyebrows with "the internet".
It turns out that letting Headscale be autonomous and trusting it to run its own community complements Tailscale in a variety of ways. It helps people stay in the ecosystem. Homelabbers and self-hosted will use it at home, but bring Tailscale to work. Sometimes it even solves problems Tailscale can not.
Of course, it has not only been smooth sailing, and being a paid contributor has caused a lot of skepticism with some users fearing an “embrace, extend, extinguish” strategy, fueling conspiracy theories about our roadmap.
In this talk, I will share how the projects exist in symbiosis, the challenges of being a paid contributor, and how the stability of a corporate payroll has enabled Headscale to reach its current scale.
Before April 2014, OpenSSL was a backwater open source project with fewer than 10 regular contributors and 1 1/2 maintainers. Meanwhile its code had become a pillar of secure communication and data privacy in the industry. This was an unstable situation that was exposed when the Heartbleed bug became global news.
The way the OpenSSL project responded to this crisis was informed by the principles of open source. Jon Ericson, the Community Manager for the OpenSSL Foundation, explains how a security bug ignited community growth and how the open source community provides ongoing stability to the OpenSSL project.
Nearly every tech event has a Code of Conduct these days, but too often it’s treated as boilerplate, or as a box to tick. But what happens when someone breaks it? Like incident response, success depends on rehearsal, not documentation.
In this talk we’ll share practical lessons from over a decade of experience running events like DevOpsDays, Cloud Native Days and PostgreSQL conferences. How to set the stage for a safe event, talk through potential incidents, and what conversations will need to be had with different stakeholders.
Most importantly, it’s hard to build trust, but easy to lose trust. We will cover how to openly and iteratively develop your community’s Code of Conduct.
All Contributors is a project which helps us recognise all the types of contributions that build our open source communities and make them flourish. It defines a specification for acknowledging community members' work, whatever they contribute, as well as tools for easy management and presentation of this information. All Contributors is used by a wide range of communities, particularly those where key contributors are not well recognised by metrics more easily extracted from version control history.
Recently these communities noticed signs of poor health in All Contributors. When the website went offline, a group of users were catalysed in to action. Coordinated by Leah Wasser (pyOpenSci Executive Director & Founder, PSF Fellow) they committed to adopting the project and forming a new, sustainable team of maintainers.
With the context of All Contributors, I will tell a story of the decline and rise of an open source project. There will be a scattering of challenges maintainers face such as, burnout, technical debt, and lottery factor. However, it is also a hopeful story about how open source software can play critical roles, cultivate deep affection from its users, and, with community support, rise again.
Open source is suffering from its own success. Our community solved problems with minimal attention from the rest of the world for almost 30 years, slowly becoming the foundation of nearly every piece of software critical to everyday life. Now with increasing regulation around the world, evolving cybersecurity requirements, and changing corporate participation and funding, how do we ensure the ecosystem's continued success? The things that have worked for the first decades will not be the things that keep us going. We will look at sustainability not only as a funding problem, but also from the perspectives of global policy movement, security, and other intertwined issues that face open source in the coming years.
I'm a psychology researcher that has been moved by the extent of burnout in Open Source, and I've written what I believe to be the most comprehensive report to date on burnout among OSS developers. I reviewed the academic literature, conducted a qualitative analysis of online discussion in the OSS community, and interviewed OSS developers. I identified 6 factors that contribute to developer burnout: difficulty getting paid, workload and time commitment, maintenance work as unrewarding, toxic community behaviour, hyper-responsibility and pressure to prove oneself. I recommend 4 structural changes to address developer burnout: pay OSS developers, foster a culture of recognition and respect, grow the community and advocate for maintainers.
Open source communities depend on a steady influx of newcomers who ask questions, seek help, and build relationships. Future heroes have to start somewhere as newbies. But across the ecosystem, those early engagement signals are dropping—sometimes sharply. Generative AI is changing how people learn, troubleshoot, and participate.
This talk synthesizes new research and real-world data to explore how AI is reshaping contributor pipelines—and what open source projects can do to adapt before downstream participation suffers.