FSFE: NHS England should not hide public code behind closed doors

England’s National Health Service (NHS England) is preparing to make most of its public source code repositories private by default, according to recent reports. The move appears to be based on concerns that public code repositories could be scanned by AI systems to identify vulnerabilities. The reported internal guidance, referred to as “SDLC-8”, would require public repositories to be made private unless an explicit exception is approved.

The Free Software Foundation Europe (FSFE) considers this a serious move in the wrong direction. Taking already public repositories offline does not prevent attackers from analysing deployed systems, dependencies, interfaces, or binaries. Depublishing does not make code unseen, nor does it remove existing copies, and it is not an effective security measure. Instead, it removes a fundamental pillar for security: the ability of independent experts, researchers, and other public bodies to inspect, reuse, and improve the code, and to report on security issues.

Releasing publicly funded software as Free Software is the core demand of the FSFE’s “Public Money? Public Code!” initiative. It is also the principle behind existing NHS and UK guidance: NHS England’s own Service Standard states that new source code for public services should be open and reusable because public services are built with public money. UK government guidance similarly requires new source code to be open and reusable, while allowing only narrowly defined exceptions.

Free Software enables independent audits, fosters local expertise, and allows public bodies to share and improve solutions together. In the health sector, where trust, resilience, and accountability are essential, these benefits are particularly important. Furthermore, “Public Money? Public Code!” fosters innovation and is one of the most effective tools to reduce lock-in, reducing public administrations’ dependency on proprietary vendors, and enabling digital sovereignty.

The FSFE therefore calls on NHS England to reverse any blanket private-by-default policy for publicly funded code, to publish the reported guidance, and to reaffirm that Free Software remains the default for publicly funded software.

Support FSFE

Victory after a decade preventing Radio Lockdown

The European Commission is choosing to protect user’s right to install any software on their radio devices by deciding to abandon the specific article in the EU Radio Equipment regulation that was harming software freedom.

From 2014 onwards an specific article on the EU regulation Radio Equipment Directive (RED) threatened to make it impossible to install custom software on most radio devices like WiFi routers, mobile phones, Bluetooth chips in computers, GPS receivers, and embedded devices. It would have required hardware manufacturers to prevent users from installing any software not certified by them.

After more than 10 years of persistent steady work by the FSFE and a broad coalition of organisations, the European Commission decided in January 2026 to abandon this provision: Free Software on radio devices remains protected!

This decision followed an impact assessment study commissioned by DG GROWEC’s DG GROW (Directorate-General for Internal Market, Industry, Entrepreneurship and SMEs), published in December 2025. The study evaluated five policy options and concluded that the risks associated with software reconfiguration of radio devices "remain theoretical and have not materialised in a systemic manner". It recommended a soft law approach based on voluntary guidance and best practices, rather than binding technical restrictions. Activating Article 3(3)(i) was found to severely harm Free Software, innovation, and user rights, while imposing prohibitive costs on small and medium-sized enterprises.

Notably, the impact assessment cited the legal study by Dr. Till Jaeger, commissioned by the FSFE, which demonstrated that Article 3(3)(i) is incompatible with widely used Free Software licences such as the GNU GPL. The FSFE and the concerns raised by the Free Software community were explicitly referenced as reasons against activation.

This outcome is the result of more than decade of sustained work with intense phases, but also phases of waiting for the right moment to get active again. Since 2015, the FSFE has been monitoring the regulatory process, contributing expertise to consultations, publishing analyses, and a broad coalition of organisations and individuals who raised their voices against Radio Lockdown. It demonstrates that persistent, evidence-based engagement with EU policy processes can make a real difference for software freedom.

This success would not have been possible without the many people and organisations who took action over the years. Thank you to everyone who contacted the European Commission and political representatives, who raised awareness about Radio Lockdown, who participated in public consultations, who signed the Joint Statement against Radio Lockdown, and all the FSFE supporters for their financial contributions enabling our work. Your engagement made a real difference.

However, the underlying idea of shifting compliance responsibility to manufacturers — and thereby restricting which software can run on devices — may resurface in other regulatory contexts.

So while the immediate threat of Article 3(3)(i) has been averted, the idea of restricting software on radio devices could resurface in other regulations.

Ensure that software freedom remains protected:

• Stay informed about EU policy developments affecting Free Software via the FSFE's news channels and newsletter.
• Support the FSFE's ongoing work for Device Neutrality, which safeguards users' rights to choose the software running on their devices.
• Help us continue our work by becoming a supporter of the FSFE. Sustained engagement with EU policy processes requires independent resources.

It often takes a long breath, patience, the expertise to spot the right time for action, and the resources to then actually act. With your help the FSFE will continue to defend the right of users to install or remove any software on any of their devices.

Become a supporter today!

Support FSFE

LLW 2026: opening legal conversations at the heart of Berlin

Berlin hosted the Free Software Legal & Licensing Workshop 2026, bringing together over 100 legal and compliance professionals, technologists, and policy experts from all over the globe. LLW continued to explore the evolving legal landscapes impacting Free Software, with many discussions focusing on how software licensing is impacted by the advent of large language models and AI

The FSFE's Free Software Legal & Licensing Workshop (LLW) is an annual conference for members of the Legal Network community to meet face-to-face and share legal expertise. In 2026, the event moved to Berlin's Kreuzberg district, hosted at bUm, a venue dedicated to offering affordable coworking, networking, and event space for civil society organisations. True to its spirit, the LLW once again fostered the kind of collaborative environment where professionals can share insights, debate complex issues, build a cohesive understanding of the legal landscape affecting Free Software, and to grow a sense of community of those “who can hear tomorrow coming”, to borrow the words of David Bowie, who was referenced many times during the conference by his Legal Network fans.

The schedule this year reflected a field in motion. Artificial intelligence has firmly moved to the centre of Free Software legal debate, while the workshop also tackled a dense agenda of regulatory and compliance topics shaping the European legislative landscape, including the Cyber Resilience Act, the Digital Markets Act, and the EU Digital Omnibus Regulation Proposal. Long-standing fundamentals of Free Software law and tooling were equally present across the talks, panels, and workshops. The LLW also continued its well-received mentorship programme, pairing newcomers to the Legal Network with experienced members over an informal breakfast ahead of the official programme.

Bowie, who made Berlin his creative home in the late 1970s, also offered what might work well as one of the mottos of the LLW community: "If you feel safe in the area you're working in, you're not working in the right area. Always go a little further into the water than you feel you're capable of being in – and when you don't feel that your feet are quite touching the bottom, you're just about in the right place to do something exciting." It is a sentiment that sits naturally with a community of legal professionals navigating some of the most unsettled and consequential terrain in technology law.

The FSFE extends its gratitude to all participants and sponsors whose support made LLW 2026 possible: our Diamond sponsors Mercedes and Red Hat; the Sapphire sponsors Amazon (AWS), Microsoft, and Siemens; Topaz sponsors Bosch, Ericsson, and Google; and our Ruby sponsors Bird & Bird, Eclipse Foundation, and Liferay.

The Legal Network

Licensing and legal decisions should be based on facts, rather than fear, uncertainty, and doubt. Free Software contributors should be able to focus on contributing to society without constantly worrying about legal issues. That is why it is important to have a space for experts to learned and discussed about these topics, not only yearly at LLW but also thanks to the Legal Network.

The Legal Network is a neutral, non-partisan group of experts in different fields involved in Free Software legal issues, currently counting over 400 participants from diverse legal systems, academic backgrounds, and affiliations.

Admission to the Legal Network is restricted, and the discussions held there are confidential. The Chatham House Rule applies to all discussions on the Legal Network mailing list and at Legal Network events, which enables members to use the information received, but not to reveal the identity nor the affiliation of the speaker or any of the participants involved in the discussion.

Support FSFE

Apple keeps challenging its interoperability obligations under the DMA

A new FSFE report exposes how 56 interoperability requests under the Digital Markets Act have produced no concrete solutions by Apple, and how their declines contradict their own official documentation, leaving third-party developers locked out of iOS and iPadOS, despite European Commission’s latest specification decision.

The Free Software Foundation Europe (FSFE)’s report “The challenges of regulating interoperability. Analysing Apple’s request-based approach under the Digital Markets Act” sheds lights on how Apple has been implementing the interoperability obligations under the Digital Markets Act (DMA). Under the European Commission (EC)'s latest rules, third-party developers can formally request access to Apple's platform. This report looks at how Apple has handled those requests in practice. The evidence of the report is based on public data from Apple’s public tracker, implemented as a requirement of the regulatory framework.

Despite the EC's clear requirements under the Digital Markets Act, the FSFE's report finds that, as of 22 March 2026, not one of 56 formal interoperability requests has resulted in a solution. Developers requesting access to Just-in-Time compilation, NFC protocols, and Bluetooth Low Energy Audio, for example, have seen their requests denied often because the features in question “fall outside of the scope of the law”. Despite the company's own technical documentation, which points in the opposite direction. The report elaborates on the shortcomings of Apple's request-based approach in relation to effective interoperability: Apple’s model requires developers to navigate account creation, fees, detailed requests, internal review, and potentially long implementation timelines, fearing sudden and unreasoned closure of their developer accounts during the whole process.

The report argues that while the regulatory framework issued by the EC on interoperability represents a progress, requiring transparency and due process obligations from Apple, governance issues, as pointed out, will arise in the future. Therefore, the report calls for open standards, transparent procedures, and stronger regulatory enforcement so that Free Software developers can participate on fairer terms within the mobile ecosystem.

You can read the full report here. What follows is a summary of the main findings.

I want to donate for Device Neutrality!

Recap on DMA interoperability

Apple is one of the largest tech companies in the world. Due to its market power, it is designated in Europe as a gatekeeper under the DMA, a law designed to regulate digital competition and open closed platforms. Under this legislation, Apple must provide free-of-charge interoperability for the features and functionalities controlled by its mobile operating systems, iOS and iPadOS. This should allow users to install and remove apps freely, use alternative app stores, and enable developers to connect their apps to key software and hardware features without being blocked.

Making Article 6(7) of the DMA Free-Software-developer friendly is crucial for Device Neutrality: it obliges gatekeepers to provide effective and free of charge interoperability with, and access to, the software and hardware features of designated operating systems such as iOS and iPadOS. In practical terms, this means that developers must be able to access the same operating-system-controlled features that the gatekeeper’s own services use, instead of being kept on the outside looking in.

The DMA represents an opportunity for Free Software developers to compete on equal terms with gatekeeper services. Free Software developers deserve the right to build genuine alternatives to closed ecosystems like iOS and iPadOS, while users gain access to alternative app stores, payment systems, and unfettered software installation in mobile devices as well.

Apple DMA interoperability compliance in practice

When the DMA took effect, it expected gatekeepers like Apple to deliver interoperability by default: publishing APIs, clear documentation, and technical access matching that are equivalent to those used for their own services. Instead, Apple created a request-based system where each developer must seek permission for specific features, waiting for Apple to decide if they are ”in scope”. This led the European Commission to launch a specification case (DMA.100204), requiring a fairer process with timelines and a public tracker (for access to which an Apple account is required).

How a developer must request interoperability to Apple

Rather than opening its platform by publishing APIs and documentation from the outset, Apple built a request-based system in which every developer must apply for access to each feature they need.

The process starts with an Apple developer account, which costs at least 99 USD (in Spring 2026), then developers need to fill a detailed request describing the feature, the use case, the technical need, and possible alternatives to the feature or functionality they are asking access for. Apple then performs an initial eligibility check within 20 working days, after which it may proceed, reject the request, or say that an existing solution already covers it.

If Apple rejects the request, developers can seek internal review and, in some cases, conciliation. Even when a request is accepted, Apple can still take up to 24 months to implement the result, depending on its own assessment of technical complexity. That means the process can stretch across months or years before developers see any practical benefit, even though the underlying right to interoperability is already supposed to exist.

The EC’s intervention gave the process a regulatory framework. As of March 22, 2026, Apple has received 56 interoperability requests under Article 6(7) of the DMA since May 2025, of which 43 have been closed, but 27 of those closures are fully confidential. Of the 16 publicly disclosed closures, none resulted in Apple developing a new interoperability solution: 10 were denied on “technical grounds”, 2 were dismissed by Apple citing “existing solutions”, and 3 were rejected as “out of scope or invalid”.

What Apple tracker reveals: four examples of rejected requests

Several individual cases illustrate how the process works in practice. A Free Software terminal-like app requested access to Just-In-Time (JIT) compilation. JIT is already used by Apple’s Safari browser to run downloaded code securely in a sandbox. But Apple rejected the request from the developer and said JIT for non-browser apps was not a feature controlled by iOS.

Another developer sought access to FIDO tokens in wallet passes and the VAS NFC protocol used by Apple Wallet. Apple again denied that these were OS-controlled features, despite its own documentation requiring a special entitlement for NFC access.

A third case involved Bluetooth LE Audio for specialised research hardware. Apple said the feature was not available to or used by Apple’s own hardware or services, even though Bluetooth Low Energy is part of iOS and comparable functionality exists on competing platforms. Two further requests sought alternatives to Apple’s Push Notification Service, including decentralised or user-controlled notification servers. But both were rejected on the grounds that APNS is already open and persistent connections are simply an OS function.

These examples show the same pattern: Apple defines the scope narrowly enough to preserve its own product design choices, then treats those same choices as evidence that interoperability is unnecessary.

Why does this matter for Free Software developers?

The burden of requesting and eventually getting access to interoperability rights falls almost entirely on developers. Under Apple’s model, they must prove case by case that a feature is “used by Apple” before they can gain access, while Apple remains free to reject the request based on its own interpretation of the scope. The EC’s framework imposes on Apple transparency obligations. For Free Software projects, this means technical work becomes entangled with legal argument, procedural deadlines, and repeated submissions.

The mandatory developer fee adds to the problem. Article 6(7) requires interoperability to be free of charge, yet Apple still requires a paid developer account to submit a request, which creates a financial hurdle at the very point where the law is supposed to lower barriers. For volunteers, small teams, and independent projects, that is not a minor inconvenience; it is a structural filter on who can participate from the beginning.

What effective interoperability needs

In the short term, effective and free interoperability access is essential to a developer-friendly enforcement of the DMA. Equal and fair access for all developers cannot depend solely on discretionary control of gatekeepers.

Looking further ahead, shared governance is essential. Regulators alone cannot ensure that interoperability serves the public interest; developers, users, and civil society must have a genuine voice in how it is designed, monitored, and enforced. The Free Software tradition, built on open standards and community oversight, demonstrates that interoperability can be democratically governed as a digital common, rather than shaped by bilateral deals between gatekeepers and their largest competitors. That is the standard the DMA should be held to.

Call to action

The FSFE is still collecting first-hand accounts from developers who have engaged with Apple’s interoperability process under Article 6(7), or who were discouraged before they even began. Those experiences help document how the process works in practice and provide concrete evidence for regulators and enforcement actions.

If you are a developer who has requested access to software or hardware features under Article 6(7) of the DMA, or if you have considered doing so but were discouraged by the process, the FSFE wants to hear from you. Your experience can help document how interoperability works in practice and support better enforcement.

Share your experience:

Support our work

Monitoring gatekeepers, analysing regulatory processes, and defending software freedom takes independent resources. Your support helps the FSFE continue this work, bring evidence to regulators, and push for interoperability by design.

Please consider making a donation to support the FSFE’s work for Free Software, Device Neutrality, and user choice.

Support FSFE

SFP#50: Policy and EU: How NGI wants to save the Internet and what's next?

We reached our 50th episode of the Software Freedom Podcast! Thank you! Without the support of our listeners we would not have made it this far <3. In this episode Bonnie talks with Gabriel Ku Wei Bin, from the FSFE's legal team about how the European Next Generation Internet initiative works to move us in the right direction towards a human-centric web.

The Next Generation Internet (NGI) initiative aims to build a more resilient, trustworthy and open Internet. Through the NGI umbrella, the European Union provides financial support to Free Software projects covering all layers of the Internet, to improve user experience of the Internet. The FSFE team provides support to NGI0 grantee projects on legal and licensing issues, as well as helping them to become REUSE compliant.

In 2024 a funding cut amounting to almost €26 million was announced, which marked the end of the NGI initiative by 2027. The loss of this funding affects the Free Software ecosystem and its ability to steadily build important foundational technologies from the ground up. The Free Software Foundation Europe stepped up, with the support of hundreds of people, to try to safeguard this funding, and managed together with our consortium partners to find a new funding umbrella to continue the work that was done under the NGI Initiative. But why is funding like this needed in the first place? And what will be happening next?

In this episode, Gabriel and Bonnie talk about the reasons behind NGI and how important it is more than ever to step up against the monopolisation of the Internet as we know it.

The FSFE's policy work is an important part of our aim to safeguard Software Freedom. You can support our work by donating today!

Show notes

• Support our work for Free Software
• Interoperability regulation in the EU: Opening iOS and Android for Free Software
• SFP#26: Policy and EU: the need of long-term funding and the NGI case
• EU consultation confirms demand: long-term funding for Free Software is needed
• Next Generation Internet Zero (FSFE's activity)
• Next Generation Internet Zero (official webpage)
• NLnet Foundation
• The FSFE is helping to build an “Internet of Humans”
• EC Public consultation: Digital economy and society
• Evgeny Morozov, "The Net Delusion: the Dark Side of Internet Freedom"
• The Matrix (movie) Wikipedia
• Fred Rogers Wikipedia
• Stay up-to-date and join our Newsletter

We are happy to receive your feedback on the Software Freedom Podcast and especially on the transcript of the episode. Please, email us to: podcast@fsfe.org. If you liked this episode and want to support our continuous work for software freedom, please help us with a donation.

Support FSFE