EMBAG and open source in the Swiss federal administration
What the EMBAG requires on open-source software in the Swiss federal administration, what it does not, and what it means for running the software.
Since 1 January 2024, Switzerland has had a federal law that says something specific about open-source software. The Federal Act on the Use of Electronic Means for the Fulfilment of Official Tasks, known in German as the EMBAG (SR 172.019), sets rules for how the federal administration uses digital tools. One article in it is short and has been widely quoted, and also widely misread. The official text is published in German, French and Italian; there is no official English version, so the summaries below are ours.
This post sets out what the law requires, what it does not, and why the harder question for most administrations is not publishing code but operating software over many years.
What the EMBAG requires on open source
The relevant provision is Article 9. In summary, federal authorities covered by the law must disclose the source code of software they develop, or have developed for them, to carry out their tasks. In practice, that means publication under an open-source licence. There are exceptions: where the rights of third parties or security reasons exclude or restrict disclosure.
Article 9 also allows the administration, under conditions, to provide services around that published software to other bodies, such as integration, maintenance or support, where this serves the public interest.
That is the core. The default has flipped. Before, a federal office that commissioned software could publish the code if it chose to. Now it must publish, unless an exception applies and it can say which one.
Other parts of the EMBAG point in the same direction. Article 10 makes open government data the default for data the federal administration holds, again with exceptions. Taken together, the law expresses a clear preference: public money, public code, public data.
What the EMBAG does not require
The article is often summarised as “the Swiss administration must use open source”. It does not say that. Being precise here matters, because procurement decisions get justified on the basis of the law.
- It does not mandate using open-source products. Article 9 is about disclosing code the administration develops or commissions. It does not forbid buying proprietary software or require replacing it.
- It does not cover off-the-shelf products. A licence for an existing commercial product is not software the administration developed. The obligation bites on custom development.
- It does not bind cantons and communes directly. The EMBAG is federal law for federal authorities. Cantons and communes set their own rules, and several have policies or debates of their own on open source and digital sovereignty. The federal law is an influential reference, not a cantonal obligation.
- It does not say how the software is operated. Publishing code is one thing. Who runs the software, where it runs and how it is kept up to date is a separate question the law leaves to the administration.
So the EMBAG is narrower than its reputation. It is also more significant than a narrow reading suggests, because of what it signals about direction.
Why the direction matters more than the letter
Public bodies do not only build software. Most of their daily tools are bought: collaboration, file sharing, identity, forms, chat, analytics. The EMBAG does not touch those purchases directly. But the reasoning behind Article 9 applies to them just as well.
Code the public can read can be audited. Software with an open licence can be run by more than one supplier, which lowers the cost of changing supplier. Data stored in an open format, in a database the administration controls, can be exported without asking a vendor’s permission. These are the same arguments made under the heading of digital sovereignty, and they apply to a collaboration suite as much as to a custom-built application.
This is why open-source and source-available products, operated on infrastructure the administration controls, keep appearing in public-sector plans. Tools such as Nextcloud for files, Keycloak for identity and Mattermost for messaging are mature, and their code is public. For the wider argument, see our guide to data sovereignty.
The part the law leaves open: operations
Here is the uncomfortable truth about open source in public administration. The licence is free. Running the software is not.
An open-source app still needs somebody to install it, connect it to the directory, back it up, watch it at three in the morning and apply security updates without breaking it. Proprietary SaaS bundles that work into the subscription and hides it. Moving to open source brings it back into view, and an administration that underestimates it ends up with an unpatched server that everyone is afraid to touch.
This is where many open-source projects in the public sector struggle. The decision to adopt is made at policy level. The consequences land on a small IT team that already has a full week. Three questions decide whether it works:
Who applies updates, and how? Open-source projects release security fixes often. Someone has to read them, decide which apply, test them and roll them out in a maintenance window, with a way back if something goes wrong.
Where do backups go, and has anyone restored one? A backup that has never been restored is not evidence of anything. See why restore tests matter.
Who is on call? Monitoring that sends alerts to an inbox nobody reads at night is not monitoring.
None of this is specific to open source. But it is the real cost, and it deserves the same attention as the licence decision.
What this means for procurement
For a federal office, a canton or a commune weighing open-source tools, a few practical points follow.
Separate the software from the operator. With open source, you can choose who runs the software, and change that choice later without changing the software. Write that separation into the tender. The data, the configuration and the backups should belong to you in a form another operator can take over.
Ask where the software runs, not only where the data is stored. Hosting in Switzerland matters, and so does who has administrative access and which law that party answers to. The strongest answer is architecture: apps on your own infrastructure, backups encrypted with keys you hold. See CLOUD Act and your data location.
Ask for an exit plan on day one. A good operator tells you how you would leave it. See our exit plan offer for what that document contains.
Check the licence of each app. “Open source” covers a range. Some apps use permissive licences, some use copyleft licences such as the AGPL, and some are source-available with limits on commercial hosting. Each of our app pages names the licence as the project spells it.
How Pilae fits
Pilae operates open-source and source-available apps for organisations that want them run properly. We deploy on premises, in Pilae Cloud on dedicated machines in Switzerland and the EU, or both.
The Pilae Agent plans each update, waits for your approval, applies it in your maintenance window and records it. Every app is backed up daily, encrypted and stored offsite in the country you choose, and on the Enterprise plan restore tests run every month with the result recorded in the console. Apps answer only on a private network, behind one hardened gate. Monitoring probes every service every 60 seconds, and alerts reach Pilae engineers around the clock.
Because the apps are open source or source-available, and the data sits in their own databases on machines you control, you are not locked into us. If you want to take operations back in house, or hand them to another supplier, the software stays the same.
For public bodies specifically, see public sector. To talk through a project, contact us.
This post summarises the law for general information. It is not legal advice. For how the EMBAG applies to a specific project, check the text in the Federal Law Collection and your legal service.