EU OS: A European Proposal for a Public Sector Linux Desktop (The New Stack) [LWN.net]

SUSE

Posted Apr 18, 2025 18:06 UTC (Fri) by swilmet (subscriber, #98424) [Link] (24 responses)

From the article:

some observers note that future iterations may consider European-backed distributions like openSUSE for deeper alignment with EU values.

openSUSE has already made its voice heard: Freedom Does Not Come From One Vendor, explaining that using a single OS for all EU administrations is a risk in case something goes wrong. So for security reasons, it makes sense to diversify: KDE/GNOME/Xfce, SUSE/Red Hat/Debian families of distributions.

SUSE

Posted Apr 18, 2025 19:15 UTC (Fri) by danieldk (subscriber, #27876) [Link] (18 responses)

> openSUSE has already made its voice heard: Freedom Does Not Come From One Vendor, explaining that using a single OS for all EU administrations is a risk in case something goes wrong.

I don't think that is really a strong point. Standardizing on one Linux distribution + desktop simplifies things a lot - the same training materials, certification, etc. can be used. And what can go wrong? As long as they choose a FLOSS distribution as a base, worst case they could just fork it and maintain it themselves. The EU + member countries have deep pockets, the cost of maintaining a distribution is barely a blip on the budget. Not saying that they should fork it initially, but the possibility is a safe backup.

SUSE

Posted Apr 18, 2025 19:51 UTC (Fri) by npws (subscriber, #168248) [Link] (4 responses)

Quoting: "Why? Security. Different distributions and desktops reduce the risk of a single point of failure. If vulnerabilities emerge, they won’t simultaneously impact every system."

That seems like a rather weak argument. Assuming they settle on 4 different distributions and only one distribution or 25% of the systems are vulnerable to some bug and do indeed get hacked. Different agencies work together, have interconnectivity, share data, trust each other etc. It is hard to imagine that an entry point like that wouldn't lead to compromise of the remaining systems as well.

That's ignoring the fact that usually most distributions are affected by the same bugs, coming from some external software package they all carry.

SUSE

Posted Apr 19, 2025 5:02 UTC (Sat) by epa (subscriber, #39769) [Link]

Yes, it seems like a pretty idiotic point. But not depending on a single *vendor* is sound business sense for a large project. The good thing with free software is that you can have the same software supported by multiple firms.

SUSE

Posted Apr 20, 2025 21:44 UTC (Sun) by kazer (subscriber, #134462) [Link] (1 responses)

You are right in that having multiple slightly different systems makes it harder (more work required) for humans to detect when they don't have equal level of security. If there are different vendors there also needs to be solid standard of doing things so that people don't need to learn multiple ways of doing things (and getting them wrong by mistake).

Instead improving code review methods, automated vulnerability testing and most of all: standardizing on highest security instead of falling back to weaker compatibility methods. For example, DNSSEC has been around for a while but it isn't thoroughly deployed due to compatibility problems and bugs and therefore isn't providing the security it could. These kinds of things are more important to fix as soon as possible.

SUSE

Posted Apr 20, 2025 21:52 UTC (Sun) by kazer (subscriber, #134462) [Link]

One more part: I would hope that Linux Standards Base was revitilized particularly considering governmental use. That would ensure that different vendors and distributions really work together and that would reduce need for re-training and such.

SUSE

Posted Apr 22, 2025 8:03 UTC (Tue) by simlo (guest, #10866) [Link]

You can say that porting from say apt to rpm have been done up front then, which makes it a lot easier to ax one in a hurry. But there are many such varieties between Linux distributions, it is impossible and very expensive to be redundant on everything anyway. Should they also include a BSD to get a redundant kernel then?

SUSE

Posted Apr 19, 2025 14:53 UTC (Sat) by hailfinger (subscriber, #76962) [Link]

Forking a distribution is inferior in pretty much all aspects compared to being able to switch to a distribution fitting the current goals. Suddenly, you need people skilled in all aspects of creating a distribution (not only technical ability, but also social and managerial aspects). I posit that most of those people are already employed or contributing elsewhere with a task fitting their skill set. Even if there is enough money to fork a distribution, you still need skilled and willing individuals for all roles.

And the drama related to forking will probably be intense. I do remember (and still occasionally read) the angry comments about Canonical "freeloading" or "leeching" off of Debian. Any "EU OS" will face that from the beginning, and even more so if there is an implied threat of forking the base distribution in case the base distribution dares disagree with the downstream "EU OS".

Diversity?

Posted Apr 19, 2025 16:26 UTC (Sat) by ceplm (subscriber, #41334) [Link] (11 responses)

(Disclaimer: I am a SUSE employee, but not talking in the name of the company, not knowing our internal position on this, just talking out of my behind)

1. (not that important, but obvious) I don’t think making European distribution based on the distro controlled by the US company is the smartest idea, considering the initiative is fuelled in part by the paranoia against the control of the current US administration.

2. I don’t think making the initiative multi-DE is wise, it seems like just a waste of resources. I don’t use Gnome myself, but I think using Gnome as the most widespread, common, and boring DE is the thing to do. This is not about DE, this is about applications running on the top of it.

3. Yes, there maybe multiple versions of the distro based on different base distributions, but there shouldn’t be a fork in my opinion. More like what the openSUSE post suggests: spin on the top of Aeon with applications useful for the government use is probably the way to go.

4. And I agree with the post that some container/Flatpak based distribution like MicroOS/Aeon (or Fedora SilverBlue or if there is something like that exists for Debian) is probably the way to go: you don’t need flexibility but stability and ease of administration (see https://youtu.be/HfaXrp4w648 and https://youtu.be/zcGAJAdJFfo).

SUSE regular release desktop options

Posted Apr 20, 2025 5:07 UTC (Sun) by DemiMarie (subscriber, #164188) [Link] (2 responses)

Is openSUSE Leap a reasonable option? My understanding is that it is not in great shape. Aeon, Kalpa, and Tumbleweed are rolling releases.

SUSE regular release desktop options

Posted Apr 20, 2025 19:48 UTC (Sun) by ceplm (subscriber, #41334) [Link]

Yes, they are, but we are big fans of using safe rolling distros for production uses (note: Tumbleweed is really something fundamentally else than for example Fedora/Rawhide … there are staging processes, openQA running on it, etc.; there are numerous production servers using for years Tumblweed or MicroOS with Tumbleweed packages).

Moreover, with separation of concerns (Aeon/MicroOS) it is really not that important how often you update relatively small and unchanging base systems, but how often you upgrade Flatpaks or distros inside of your Distorbox containers.

SUSE regular release desktop options

Posted Apr 20, 2025 19:50 UTC (Sun) by ceplm (subscriber, #41334) [Link]

And of course, Leap is still alive and doing fine, it uses SUSE Enterprise Linux as its foundation, so I don’t think it is going away anytime soon.

GNOME would not be my choice for this

Posted Apr 20, 2025 5:12 UTC (Sun) by DemiMarie (subscriber, #164188) [Link] (6 responses)

GNOME had two significant problems here. First, it is very different from Windows, making training more difficult. Second, it is significantly less customizable and lacks stable extension points.

Generally, I would only go with GNOME if I was fairly confident that vanilla GNOME would be sufficient. I don’t know if that is the case here. KDE is not perfect, but it is much more customizable in a way that is likely to keep working in the future.

GNOME would not be my choice for this

Posted Apr 20, 2025 7:08 UTC (Sun) by mgb (guest, #3226) [Link]

TDE is a fork of KDE 3, originally by Timothy Pearson, and now developed and maintained mostly by Europeans.

In my experience it is the easiest Linux desktop for Windows users to transition to.

https://www.trinitydesktop.org/

Disclaimer: I run one of the TDE mirrors but I do not speak for the developers.

GNOME would not be my choice for this

Posted Apr 22, 2025 13:33 UTC (Tue) by eru (subscriber, #2753) [Link] (2 responses)

Exacly. When your user population has used Windows previously, it is either KDE or XFCE of the major desktops. (Maybe also Mate or Cinnamon, but they are less widely used, so may have less certain support going forward).

GNOME would not be my choice for this

Posted Apr 24, 2025 10:59 UTC (Thu) by NRArnot (subscriber, #3033) [Link]

Cinnamon is what the Windows XP UI should have become, before Microsoft first pissed in the pot with 7 and then flushed it altogether with 10. (Trouble is that there's now a dumbed-down generation who don't know how to have more than one "app" open at once).

GNOME would not be my choice for this

Posted Apr 24, 2025 16:29 UTC (Thu) by paulj (subscriber, #341) [Link]

MATE is very nice, and hews to widely understood desktop window system mechanisms.

GNOME 3 is confusing to at least some non-techy users. Core aspects of how you use it have very poor discoverability (the desktop equivalent of Vi really). It doesn't seem to have been designed with much HID testing to guide it - unlike GNOME 2.0 (which MATE continues from), which was informed by extensive HID testing sessions carried out by Sun Microsystems.

GNOME would not be my choice for this

Posted Apr 24, 2025 14:09 UTC (Thu) by ceplm (subscriber, #41334) [Link] (1 responses)

I think the particular desktop environment is largely irrelevant here. Most desktop environments (lead by Gnome) completely lost their game and lost to web browsers in the same manner Microsoft lost in much bigger game Windows API game [1]: by constant changes, unstable and poorly documented APIs, mostly anybody outside of the Gnome team itself, abandoned any efforts to develop Linux desktop software unless they have to (or they are Mozilla, LibreOffice or somebody else large enough they can invest in constant changes in API). Now (following the trend in the rest of the computer world) mostly everybody uses their Linux desktop machine in the same way people use their Windows or Mac machines: starting Firefox/Chrome and forgetting there is anything else.

Yes, I run Sway (actually I maintain my own tiny micro-distro https://sr.ht/~mcepl/moldavite/), but it is mostly irrelevant, because I use mostly Firefox and terminal (foot in this moment) and not much else these days. I was suggesting Gnome because it is the most common one, but it is just Firefox/Chrome launcher anyway, so it really doesn’t matter that much which DE is selected.

[1] https://www.joelonsoftware.com/2004/06/13/how-microsoft-l...

GNOME would not be my choice for this

Posted Apr 24, 2025 14:59 UTC (Thu) by pizza (subscriber, #46) [Link]

> I think the particular desktop environment is largely irrelevant here. Most desktop environments (lead by Gnome) completely lost their game and lost to web browsers in the same manner Microsoft lost in much bigger game Windows API game [1]

Uh... that link dates from *2004*, when Gnome2 and Windows XP (ie supposedly "peak UI" for both) reigned supreme.

> by constant changes, unstable and poorly documented APIs

The other problem wth your argument is that web API churn is *vastly worse* than anything done to/with native Linux or Windows APIs.

> I was suggesting Gnome because it is the most common one, but it is just Firefox/Chrome launcher anyway, so it really doesn’t matter that much which DE is selected.

That's pretty much true of everything now -- What effectively ended *all* (general purpose) desktop environment interest was the rise of smartphones and the "cloud-first" mentality, to the point where nearly all new-ish "native" applications are now just thin wrappers around a full browser engine running a web application.

Diversity?

Posted Apr 20, 2025 7:19 UTC (Sun) by marcH (subscriber, #57642) [Link]

> I don’t use Gnome myself, but I think using Gnome as the most widespread, common, and boring DE is the thing to do.

If you tried to use it, you would know it looks like nothing else. I can't say much because I probably missed the point and was not interested in learning something new in this area but I know for sure it's everything but "boring".

It seems to be the most common default but most distros make it very easy to switch so I really wonder how actually popular it is.

SUSE

Posted Apr 18, 2025 19:53 UTC (Fri) by leromarinvit (subscriber, #56850) [Link] (1 responses)

Security is an argument against a monoculture I'll agree with, but that mostly rests on different software being used, not just different distributions of the same stuff (barring configuration issues). OTOH, pooling resources makes a ton of sense for a bunch of governments with likely very similar requirements. Given the scale of the EU, they could afford to audit and improve the critical projects they rely on.

Also: A single vendor whose code is open for others (including yourself) to maintain, should that vendor stop for some reason, is infinitely better than a single vendor whose code you'll most likely never see, much less would be able to (legally) continue maintaining.

Yet, by and large, most governments today are happily committing themselves to that vendor.

SUSE

Posted Apr 20, 2025 7:26 UTC (Sun) by marcH (subscriber, #57642) [Link]

> Security is an argument against a monoculture I'll agree with, but that mostly rests on different software being used, not just different distributions of the same stuff

This.

There are big differences across distros, but I bet CVEs are mostly the same for similarly "paced" distros.

SUSE

Posted Apr 19, 2025 16:52 UTC (Sat) by adam820 (subscriber, #101353) [Link]

This really reads like a blog of annoyed grievance that openSUSE technologies were not picked.

> Let’s not get lost in the flags, logos or headlines. [...] The future of tech [...] needs to be open.

Bold thing to say for a blog post advocating to not use one product, but instead use technologies derived from it's own products. Last I checked, Fedora and KDE were still open, as is Ubuntu. The idea that KDE is too technical despite it's more traditional desktop layout, and should use GNOME instead, which I would agree is simpler, but vanilla GNOME is a radical departure from the normal office PC paradigm.

This article doesn't seem to know what it wants, and is making *an* argument, but I don't think it's a good one. openSUSE makes a fine product, but it's not making a great case here for why they should switch.

SUSE

Posted Apr 23, 2025 12:21 UTC (Wed) by khagaroth (guest, #109895) [Link] (1 responses)

Why embrace and endorse the biggest roadblock to linux desktop usage.

SUSE

Posted Apr 24, 2025 3:07 UTC (Thu) by neilbrown (subscriber, #359) [Link]

> Why embrace and endorse the biggest roadblock to linux desktop usage.

Because it is our superpower.

bootc

Posted Apr 18, 2025 22:10 UTC (Fri) by champtar (subscriber, #128673) [Link]

The article doesn't mention it, but their website does (https://eu-os.gitlab.io/), they want to use bootc, explaining the Fedora choice. bootc aim to be distro/packager agnostic so they could switch away from Fedora in the future.

Needs to be based on a 'European' distribution

Posted Apr 19, 2025 8:12 UTC (Sat) by tdz (subscriber, #58733) [Link] (3 responses)

Picking Fedora over any of the Europe-based distributions makes no sense for the state goal of sovereignty. Assembling packages is the easy part, but who's going to support this afterwards? Is the EU public sector supposed to buy support from Redhat? With something based on openSUSE or Ubuntu, there would be support available from European companies with proven expertise.

(Full disclosure: I work for SUSE on SUSE-based distributions. The opinion is mine, I don't speak for my employer.)

Needs to be based on a 'European' distribution

Posted Apr 19, 2025 8:47 UTC (Sat) by zdzichu (subscriber, #17118) [Link] (1 responses)

Well, European engineers could support it. I'm sure building skilled support structures is part of the effort.

In the past I've worked in two similar companies. One built the skillset in-house, the other yielded to consultants with most issues. Quality of work and comfort of job was much better in first one.

Needs to be based on a 'European' distribution

Posted Apr 19, 2025 10:53 UTC (Sat) by tdz (subscriber, #58733) [Link]

I'd be one of those European engineers and we already do have a these support structures at SUSE. With our Multi-Limux Support, at SUSE we even offer support for CentOS and RHEL. It's all there. Yet it makes no sense to build upon a non-European base if the goal is sovereignty from outside parties.

Needs to be based on a 'European' distribution

Posted Apr 19, 2025 14:35 UTC (Sat) by champtar (subscriber, #128673) [Link]

They want to use bootc, because assembling your custom OS, then layering some extra software for some use cases, distributing and upgrading it for years is not that easy.

They want an immutable desktop OS, and Fedora is leading in that space. I don't know Aeon but it says release candidate at the top of the first page https://aeondesktop.github.io/

How long would the support cycles be?

Posted Apr 19, 2025 10:40 UTC (Sat) by aragilar (subscriber, #122569) [Link] (4 responses)

I'm somewhat surprised Fedora would be chosen, I though the support cycle for a single release was quite short?

How long would the support cycles be?

Posted Apr 19, 2025 12:22 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

> I'm somewhat surprised Fedora would be chosen, I though the support cycle for a single release was quite short?

It is roughly six months release cycle but the release continues to get updates for a month after the next release, so every release gets updates for roughly 13 months. However with an image based deployment, it is easy to build out custom layers or revert back. From a support perspective, that's nice to have. IIRC, Red Hat itself uses Fedora as their internal desktop OS (moving from RHEL) and other large organizations including Meta are using Fedora as their internal desktop OS too. So it seems feasible but these are tech savvy organizations. Not sure how well that maps to typical government desktop use.

How long would the support cycles be?

Posted Apr 20, 2025 14:13 UTC (Sun) by gdt (subscriber, #6284) [Link] (2 responses)

Fedora has a release cycle but no support cycle. There is no support in the 'enterprise' sense of the word.

Fedora broke Bluetooth headsets for the best part of a year. There have been bugs which have left Fedora computers dead in the water, which if the distribution was more widely used would have an impact akin to the CloudStrike incident. Which is fine. Fedora is meant to be the operating system which sorts out changes which can't be tested against the necessarily small ranges of devices available to a developer or lab.

But as a base distribution for a desktop used across many countries personal computers it is a poor choice as the distribution's goals are incompatible with that usage. And again, there's nothing wrong with that.

My view is: Debian exists. It's the obvious choice considering compatibility of aims. It needs work, but there's plenty of scope to use the funds no longer going to US technology corporations to make that work happen in Europe. SuSE would be one of the companies best positioned to contract for that work.

However at this stage I don't see any proposal from the Council of Europe. Rather the opposite: the Strategic Technologies for Europe Platform and the associated Horizon Europe funds have been redirected towards defending Europe from Russia's military aggression. This "EU OS" is merely an independent proposal which is using the "EU" name.

I expect the Council and Parliament to develop a more comprehensive programme to ensure European sovereignty, which would include software platforms, but at present the immediate work of defending Ukraine is clearly taking precedence in budget allocations.

How long would the support cycles be?

Posted Apr 22, 2025 6:44 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

> Fedora broke Bluetooth headsets for the best part of a year.

News to me…I've been using mine just fine for the past 4 or 5 years. There's some weirdness with browsers getting confused if I connect or disconnect after they enumerate devices, but I chalk that up to crappy web APIs more than anything else. There's also weirdness when I switch devices via the headset switch, but that is probably a headset thing as it happens even between other devices, not just the laptop.

Are these more GNOME (or KDE) things because the base technologies have been solid for me (I use XMonad and cobbled-together services to do my "desktop").

How long would the support cycles be?

Posted Apr 22, 2025 12:01 UTC (Tue) by pizza (subscriber, #46) [Link]

> > Fedora broke Bluetooth headsets for the best part of a year.
> News to me…I've been using mine just fine for the past 4 or 5 years.

Ditto; another daily headset user with Fedora/Gnome, for at least a couple of years.

The desktop is not the difficult problem

Posted Apr 19, 2025 10:44 UTC (Sat) by storner (subscriber, #119) [Link] (5 responses)

Whenever the public sector lock-in to proprietary solutions comes up, someone proposes to build a Linux desktop. There are so many Linux desktop distributions. Picking and modifying one to work as an office desktop is easy.

The real problem is application- and service-integration, management of large fleets of systems, identity and access management solutions integrated with the various end-user applications etc. Proprietary systems offer a "one-stop" solution to these problems. If you want to build something similar on a pure Linux/OSS platform, you are in for some serious integration work.

NextCloud can do a lot of what MS 365 does. But how do you integrate the NextCloud document sharing with the systems handling applications for social welfare services? Permits for building new houses? Which system can be used to hold forensic evidence in a way so it can be used in trials? With all of the GDPR requirements fulfilled?

Desktops are easy. We should spend more effort building the backend services that these desktops will work with - so far we have mostly done infrastructure and middleware. If we truly want to eliminate our need for US-based software, then we must move to the applications and services part of the software chain.

The desktop is not the difficult problem

Posted Apr 19, 2025 11:44 UTC (Sat) by pizza (subscriber, #46) [Link] (2 responses)

> Desktops are easy. We should spend more effort building the backend services that these desktops will work with - so far we have mostly done infrastructure and middleware. If we truly want to eliminate our need for US-based software, then we must move to the applications and services part of the software chain.

In other words, you're not looking to "write software", you're looking to *provide services*. That is _very_ different.

Software is pure NRE, one-and-done. But services cost money, on an ongoing (and per-user/per-request) to provide. Especially when it's at scale, has high uptime/reliability requirements, and there are very strict legal requirements one has to follow.

The desktop is not the difficult problem

Posted Apr 22, 2025 8:59 UTC (Tue) by jepsis (subscriber, #130218) [Link] (1 responses)

With modern security and regulatory demands, software now incurs ongoing maintenance costs — it's no longer one-and-done, it's a lifecycle commitment.

The desktop is not the difficult problem

Posted Apr 22, 2025 12:09 UTC (Tue) by pizza (subscriber, #46) [Link]

> With modern security and regulatory demands, software now incurs ongoing maintenance costs — it's no longer one-and-done, it's a lifecycle commitment.

Point being, "writing" or "maintaining" software is pure NRE. You have to only do it once for any given feature or bugfix, no matter how many folks actually use that software. (ie "effectively zero margin for additional copies")

On the other hand, providing a *service* costs you incrementally more for every actual user, plus several large step functions along the way as you cross certain user-count thresholds that trigger additional engineering (ie "operate at scale"), support, and regulatory requirements.

The desktop is not the difficult problem

Posted Apr 19, 2025 12:56 UTC (Sat) by npws (subscriber, #168248) [Link] (1 responses)

> The real problem is application- and service-integration, management of large fleets of systems, identity and access management solutions integrated with the various end-user applications etc. Proprietary systems offer a "one-stop" solution to these problems.

At least here in Europe, nobody runs "one-stop" solutions, but an incredible mess of incompatible systems, often different ones across county and state boundaries. The most common denominator is probably Windows 95.

The desktop is not the difficult problem

Posted Apr 19, 2025 16:04 UTC (Sat) by notriddle (subscriber, #130608) [Link]

So you want an image-based Linux distribution with solid Wine integration?

Maybe they should base off SteamOS instead?</s>

The software has been chosen, now the task needs to be adapted to the software

Posted Apr 19, 2025 15:25 UTC (Sat) by hailfinger (subscriber, #76962) [Link] (2 responses)

Quoting from the EU OS FAQ:
> Considering the advice received, Robert decided to advance the Proof-Of-Concept with Fedora. For a production deployment after the Proof-of-Concept, any Fedora-based Linux distribution with longer release cycles could be used. Also, a switch to any other bootc-supported Linux distribution is still possible.

1. Hard requirement of bootc
2. Production with a Fedora-based distribution
3. Switching to a non-Fedora-based distribution will not be possible later ("still possible" implies that there will be a point of no return)

Let me tell you a little-known secret about public sector procurement. Most of the time, you ask the person with decision-making power which software they want. After all, you want that person to approve of the procurement. Then you try to make that software work in your environment. If it is not a total disaster, you create feature lists of the most common software products for that specific task (email client, parking permits, ...). Then you focus on the differences. That also helps if someone asks whether you looked at other software at all. If the previously chosen product has the features "yellow error messages" and "yelling frobnicator" which no other product has, you create a requirements list with many features, featuring the yellow error messages and the yelling frobnicator as mandatory requirements. Then you publish a "vendor-neutral" call for public tender. Miraculously, only one product qualifies.

The EU OS FAQ has a striking similarity to that school of thought.

The software has been chosen, now the task needs to be adapted to the software

Posted Apr 19, 2025 16:54 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

I think it's worth linking the whole FAQ: https://eu-os.gitlab.io/faq

This doesn't sound at all like a public sector procurement process; there was no requirements list or tendering or communicating with vendors at all. And it's not public sector: "Right now, EU OS is not a project of the European Union. Instead, EU OS is a community-led Proof-of-Concept. This means it is lead by a community of volunteers and enthusisasts. The project goal is to become a project of the European Commission in the future"

It sounds like this is (currently) a single guy's project, and he just chose a distro that he thought would work well for a few reasons, which is the standard decision-making process in pretty much every small project. Distro choice will always be contentious and there's rarely an objectively correct answer, which is why the distro wars have been ongoing since last century; so whoever's doing the work gets to pick one they like.

The software has been chosen, now the task needs to be adapted to the software

Posted Apr 20, 2025 7:24 UTC (Sun) by marcH (subscriber, #57642) [Link]

> It sounds like this is (currently) a single guy's project,

Darn, so LWN has become social media too :-(

Don't reinvent the wheel

Posted Apr 20, 2025 4:55 UTC (Sun) by pabs (subscriber, #43278) [Link]

Might be best to join one of the existing distros than reinvent the wheel. Debian is quite heavily European, or there is openSUSE in the RPM camp, or perhaps a more modern distro like Guix/Nix.

A possible reason for Fedora

Posted Apr 20, 2025 5:05 UTC (Sun) by DemiMarie (subscriber, #164188) [Link] (31 responses)

Fedora is the only major reasonably fast-moving desktop distro I know of that is not a rolling release. Slower-moving distros very often lag so far behind upstream that when there is a problem, getting help from upstream is nigh impossible.

A possible reason for Fedora

Posted Apr 20, 2025 14:28 UTC (Sun) by hailfinger (subscriber, #76962) [Link] (30 responses)

Hm. Do you know about Ubuntu? It seems to fit the criteria for "major reasonably fast-moving desktop distro".
Major distro? Sure.
Reasonably fast-moving? Sure, even with identical release cadence.
Desktop? Sure.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 20, 2025 15:30 UTC (Sun) by DemiMarie (subscriber, #164188) [Link] (28 responses)

I had forgotten about non-LTS Ubuntu, but my understanding is that its binary packages aren’t freely redistributable, and there is no interest in an immutable base system.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 20, 2025 15:36 UTC (Sun) by DemiMarie (subscriber, #164188) [Link]

To elaborate: In the areas where I had been looking for a distro, the licensing constraints meant that Ubuntu wasn’t an option, so I didn’t even consider it. For instance, there’s no pre-built Ubuntu Qubes template, and Ubuntu isn’t an option for the base for Qubes OS’s dom0.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 20, 2025 16:38 UTC (Sun) by ballombe (subscriber, #9523) [Link] (25 responses)

> my understanding is that its binary packages aren’t freely redistributable

You need to substantiate that statement because
https://archive.ubuntu.com/ubuntu/
exist and that would be a GNU GPL violation for a lot of packages.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 20, 2025 22:26 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (24 responses)

I think they may be specifically referring to binary packages in restricted and multiverse.

Of course, you can just say that "multiverse is unsupported by Canonical, so we don't support it either," but restricted may contain things that you don't necessarily have an easy replacement for. Moreover, using Canonical's support as an arbitrary dividing line suggests that you will end up taking a de facto business dependency on Canonical, whether you currently intend that or not.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 21, 2025 3:33 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (23 responses)

No, Canonical has repeatedly asserted that they hold copyright over binary packages that's independent of the source contained (Mark Shuttleworth told me that he believed that choice of compiler options alone provided sufficient creative input that the build process wasn't mere mechanical transformation of the source code) and has demanded license payments from Ubuntu derivatives that simply imported Canonical binary packages rather than rebuilding them. This is obviously complicated when it comes to GPLed material (you can have an argument about whether the package changelog and other packaging metadata is a derived work or mere aggregation, and as such it could arguably be under a different license), but there's enough non-GPLed stuff that well whatever.

Canonical has also never made a public statement about what would need to be stripped from source packages before a full rebuild would no longer be a trademark violation. This is in marked contrast to Fedora, where there's a published document telling you which packages to remove, and also dummy packages that provide generic artwork to compensate.

The entire thing is clearly absolute bullshit, but also last time I was talking to Mark about this I was halfway through a sentence when he turned and started talking to someone else, so.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 21, 2025 7:00 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

> Mark Shuttleworth told me that he believed that choice of compiler options alone provided sufficient creative input that the build process wasn't mere mechanical transformation of the source code

That strikes me as a highly questionable position for them to take. Are their engineers manually examining the compiler output with a hex editor, and tweaking the options until they get exactly the codegen they want to see?

(Benchmarking does not count. Copyright is about the creative or non-functional aspects of the work, since protection of functionality is reserved for patents. Benchmarks are a purely functional measurement and cannot reasonably qualify as exercise of creative control.)

> This is obviously complicated when it comes to GPLed material (you can have an argument about whether the package changelog and other packaging metadata is a derived work or mere aggregation, and as such it could arguably be under a different license),

The binary is a derivative work of the source, so if the source is under GPL, the binary must be under GPL as well, and at most they can enforce attribution to Canonical (if we accept this bizarre premise of binaries having separate copyright just from the compiler options).

But the package metadata is a more complicated story. In the US, I think they have a case, but certain obiter dicta in Feist v. Rural would make it rather messy to litigate in practice. In Europe, where this story actually takes place, they are probably in the right, because Europe (specifically, the EU+UK) recognizes sui generis database rights, and it is hard to argue that the packaging metadata would not fall under such a right (at least in aggregate - it's more complicated if you're just pulling a few individual packages, but anything derived from the distro as a whole will have a problem here).

I don’t believe Ubuntu binaries are redistributable

Posted Apr 21, 2025 9:49 UTC (Mon) by ballombe (subscriber, #9523) [Link] (20 responses)

Do you have a link to share ?

I don’t believe Ubuntu binaries are redistributable

Posted Apr 21, 2025 17:33 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (19 responses)

https://ubuntu.com/legal/intellectual-property-policy

I don’t believe Ubuntu binaries are redistributable

Posted Apr 21, 2025 21:45 UTC (Mon) by dskoll (subscriber, #1630) [Link] (15 responses)

But what happens if you recompile the source code and end up with a bit-for-bit identical binary? (Isn't reproducible building a goal for some systems?) How can you prove to Canonical that it's your binary and not theirs?

I don’t believe Ubuntu binaries are redistributable

Posted Apr 21, 2025 21:55 UTC (Mon) by pizza (subscriber, #46) [Link] (13 responses)

> But what happens if you recompile the source code and end up with a bit-for-bit identical binary? (Isn't reproducible building a goal for some systems?) How can you prove to Canonical that it's your binary and not theirs?

If you are building a *binary package* then for it to be bit-for-bit identical it will necessarily include Canonical's trademarked term "ubuntu" in the metadata, and that's one of the things they take issue with.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 21, 2025 23:20 UTC (Mon) by dskoll (subscriber, #1630) [Link] (12 responses)

Oh, I see. So it's the package itself, not the binary, that's the issue.

That's no big deal, then. It's standard operating procedure to restrict the use of trademarks.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 21, 2025 23:54 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (11 responses)

Really? I don't think Debian has ever had issues with people redistributing packages that contain "debian.org" in the changelog. I don't think Canonical would have much of a leg to stand on in that specific respect given the number of actual Debian packages that contain changelog entries from Canonical employees using their project addresses, but when asked there's never been any clarity on just what level of trademark removal is desired here.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 22, 2025 0:52 UTC (Tue) by dskoll (subscriber, #1630) [Link] (10 responses)

Yeah, I don't know. I don't think it would be reasonable to consider developer@ubuntu.org in a Changelog to be a violation of the "Ubuntu" trademark... it's just an email address that's used to record a historical fact.

I think you're right that Canonical is asking for a lot more than it's really entitled to... which may be typical of corporations and less typical of non-profits like Debian.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 22, 2025 20:09 UTC (Tue) by Wol (subscriber, #4433) [Link] (8 responses)

> I think you're right that Canonical is asking for a lot more than it's really entitled to... which may be typical of corporations and less typical of non-profits like Debian.

And if what you're distributing *IS* a bit-for-bit copy of an Ubuntu binary, I think they would get slapped down HARD by a Judge "But this is the *intended* *use* of trademarks!". People don't seem to understand Intellectual Property, be it copyrights (copying is illegal without permission), trademarks (proof this is an exact copy), patents (inventive or design), etc etc.

Cheers,
Wol

I don’t believe Ubuntu binaries are redistributable

Posted Apr 23, 2025 3:01 UTC (Wed) by dskoll (subscriber, #1630) [Link] (7 responses)

What is an "Ubuntu binary", though? And what if no Canonical trademarks appear in that binary, and the source to the binary is GPL'd?

If you happen to build an executable from the GPL'd source that happens to match the executable Ubuntu built, then how can Ubuntu stop you from distributing that?

I think it's pretty clear you can't redistribute Ubuntu binary packages that contain Canonical trademarks, including things like artwork, themes, etc. But saying you can't download some random .deb that's part of Ubuntu but doesn't contain any Canonical trademarks and then redistribute it seems pretty far-fetched to me.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 23, 2025 3:19 UTC (Wed) by pizza (subscriber, #46) [Link] (6 responses)

> But saying you can't download some random .deb that's part of Ubuntu but doesn't contain any Canonical trademarks and then redistribute it seems pretty far-fetched to me.

Any "random .deb that's part of Ubuntu" contains Canonical trademarks -- At minimum, it's part of the version string that unambiguously identifies said .deb as originating from Canonical.

> If you happen to build an executable from the GPL'd source that happens to match the executable Ubuntu built, then how can Ubuntu stop you from distributing that?

*executable* != *package*

tl;dr: They can't, unless said executable contains Canonical trademarks that make it appear that it originated from Ubuntu.
(The GPL explicitly permits this sort of restriction)

I don’t believe Ubuntu binaries are redistributable

Posted Apr 23, 2025 15:26 UTC (Wed) by dskoll (subscriber, #1630) [Link] (5 responses)

They can't, unless said executable contains Canonical trademarks that make it appear that it originated from Ubuntu. (The GPL explicitly permits this sort of restriction)

OK, so I wrote a piece of software that is licensed under GPLv2 and is shipped by Canonical as part of Ubuntu Universe. Section 3 of GPLv2 says: "You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:" [provide source code...]

The GPLv2 explicitly says you're allowed to distribute the program or a work based on it in object code or executable form. There's nothing in the GPLv2 about trademarks. And a binary .deb is surely a "work based on" my program.

GPLv3 mentions trademarks, so yes... for GPLv3-licensed work, Ubuntu is probably within its rights to require removal of trademarks as a condition of redistribution.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 23, 2025 15:29 UTC (Wed) by pizza (subscriber, #46) [Link]

> And a binary .deb is surely a "work based on" my program. \

It's a "combined work" that contains more than just your program.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 23, 2025 16:02 UTC (Wed) by Wol (subscriber, #4433) [Link] (3 responses)

> The GPLv2 explicitly says you're allowed to distribute the program or a work based on it in object code or executable form. There's nothing in the GPLv2 about trademarks. And a binary .deb is surely a "work based on" my program.

If it's purely your work, the GPL doesn't apply.

And if you downloaded your work - from Ubuntu - in an Ubuntu package then they will apparently have added trademarks so it is no longer your work - it is a combined work.

And then if you distribute the Ubuntu package UNmodified that's perfectly okay from a trademark point of view.

The problem is if you take the Ubuntu version of your work, modify it again, then distribute it with Ubuntu trademarks intact. The GPL (*any* version) does not give you permission to ignore trademark law, and you're then guilty of "passing off", otherwise known as trade deception or fraud.

Oh - and from section 7 of the GPLv2

> It is not the purpose of this section to induce you to infringe any
> patents or other property right claims or to contest validity of any
> such claims; this section has the sole purpose of protecting the
> integrity of the free software distribution system, which is
> implemented by public license practices.

Which presumably includes trade marks? The *code* may be GPL, but the trademarks aren't ...

Cheers,
Wol

I don’t believe Ubuntu binaries are redistributable

Posted Apr 23, 2025 16:13 UTC (Wed) by Wol (subscriber, #4433) [Link]

> The problem is if you take the Ubuntu version of your work, modify it again, then distribute it with Ubuntu trademarks intact. The GPL (*any* version) does not give you permission to ignore trademark law, and you're then guilty of "passing off", otherwise known as trade deception or fraud.

It's like the "This is all my own work" you're expected to sign off on on your University Dissertation. If your thesis properly attributes all the stuff you "nicked" from random places on the internet, then it's fine. If, however, you DON'T attribute stuff (even worse, *hide* the fact you nicked it), you're likely to get "sent down".

Trademarks are a "this is all my own work" declaration, and will land you in serious hot water if mis-used.

Cheers,
Wol

I don’t believe Ubuntu binaries are redistributable

Posted Apr 23, 2025 16:22 UTC (Wed) by dskoll (subscriber, #1630) [Link] (1 responses)

And then if you distribute the Ubuntu package UNmodified that's perfectly okay from a trademark point of view.

Yes, I agree... but does Canonical?

The problem is if you take the Ubuntu version of your work, modify it again, then distribute it with Ubuntu trademarks intact.

I agree again, but this isn't a problem. If you're going to modify the work, then it's easy enough to strip out the trademarks. However, I think it would be very problematic if Canonical attempted to prevent you from redistributing an unmodified .deb that you simply downloaded from Ubuntu's servers (which is how I read the start of this thread.)

I don’t believe Ubuntu binaries are redistributable

Posted Apr 23, 2025 16:58 UTC (Wed) by Wol (subscriber, #4433) [Link]

> > And then if you distribute the Ubuntu package UNmodified that's perfectly okay from a trademark point of view.

> Yes, I agree... but does Canonical?

More to the point, would a High Court Judge? And would a barrister be prepared to even take the case? I know in America, barristers are expected to argue any case however stupid, but that doesn't apply over here. Highly unlikely, but if the victim files a "summary motion for dismissal" and the Judge responds "of course", then there's nothing stopping that coming with sanctions for the legal team as well ...

> I agree again, but this isn't a problem. If you're going to modify the work, then it's easy enough to strip out the trademarks. However, I think it would be very problematic if Canonical attempted to prevent you from redistributing an unmodified .deb that you simply downloaded from Ubuntu's servers (which is how I read the start of this thread.)

I wouldn't want to bother the FSFE, but they'd probably be interested. And I know you rarely get all your costs back, but I suspect Canonical would rapidly find themselves staring down the barrel of a "bad faith" gun. So long as the victim has a bit of money in their pocket, I suspect Canonical would find themselves learning a very expensive legal lesson - "Don't fly stupid theories past a High Court Judge".

Cheers,
Wol

I don’t believe Ubuntu binaries are redistributable

Posted Apr 23, 2025 17:20 UTC (Wed) by ballombe (subscriber, #9523) [Link]

The policy is conflating Canonical the company with Ubuntu the supposedly community-supported distribution.
It presents Canonical as appropriating the full Ubuntu IP to itself and does not acknowledge upstream projects and Debian IP. This does not encourage to contribute to Ubuntu.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 22, 2025 6:58 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

It's not a technical issue, it's legal. Color of the bits matters.
It's very tiring when people on LWN start discussing law matters and apply their specific logic to incompatible domain.

According to Ubuntu, only TRADEMARK is protected

Posted Apr 22, 2025 4:07 UTC (Tue) by jjs (guest, #10315) [Link] (2 responses)

From the link:
"Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to _associate it with the Trademarks_. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries. This does not affect your rights under any open source licence applicable to any of the components of Ubuntu. If you need us to approve, certify or provide modified versions for redistribution you will require a licence agreement from Canonical, for which you may be required to pay. For further information, please contact us (as set out below)." (my emphasis on the last of the 1st sentence).

Trademark is covered by 15 USC 22 (https://www.law.cornell.edu/uscode/text/15/chapter-22), as supplemented by the CFR (https://www.law.cornell.edu/cfr/text/37). Here is Congress' write-up/guidance - https://www.congress.gov/crs_external_products/IF/PDF/IF1.... It covers very narrow category of IP, definitely NOT copyright. Only to the extent the material somehow identifies/represents Ubuntu could they (note: IANAL) have a claim to being able to restrict modification and redistribution of F/LOSS software, to include GPL'd, BSD'd, MPL'd, etc.

Normally, that would be things like the name "Ubuntu", any graphics they've registered for trademark, etc. I don't see how compiler options could trigger trademark claims, but again, IANAL.

According to Ubuntu, only TRADEMARK is protected

Posted Apr 22, 2025 4:13 UTC (Tue) by jjs (guest, #10315) [Link]

And to add to this, you actually can use Trademarks - most people do when they reference a product. That's part of the reason for trademark. My saying "This is a bottle of Coca-Cola" does NOT violate Coca-Cola's trademark. A supermarket selling Coca-Cola (or other products) and using that name in advertising doesn't violate trademark.

From that (IANAL), my saying "we recompiled Ubuntu" would likely not violate trademark - I'm not claiming it's mine. Now if I use an image from Canonical and claim it's mine, that's a different story.

According to Ubuntu, only TRADEMARK is protected

Posted Apr 22, 2025 9:01 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

OK. So the issue is trademark and if one does not use a trademark owned by Canonical, it's not a problem.

Are there any specific guidelines for the requirements? What would be required to be removed to avoid using those trademarks? Is there any example of an Ubuntu-derived distribution that does this?

I don’t believe Ubuntu binaries are redistributable

Posted Apr 21, 2025 11:53 UTC (Mon) by pizza (subscriber, #46) [Link]

> No, Canonical has repeatedly asserted that they hold copyright over binary packages that's independent of the source contained [...]
> Canonical has also never made a public statement about what would need to be stripped from source packages before a full rebuild would no longer be a trademark violation. This is in marked contrast to Fedora, where there's a published document telling you which packages to remove, and also dummy packages that provide generic artwork to compensate.

Yet somehow, Ubuntu seems to get a total pass on this, while Red Hat is constantly painted as a horrible anti-FOSS villain.

I don’t believe Ubuntu binaries are redistributable

Posted Apr 22, 2025 1:05 UTC (Tue) by HenrikH (subscriber, #31152) [Link]

While true, that is something that one or two €100M investment from the EU would change in a heartbeat ;)

A possible reason for Fedora

Posted Apr 20, 2025 17:56 UTC (Sun) by zdzichu (subscriber, #17118) [Link]

Ubuntu is not a standalone distribution, but is siphoning packages from Debian testing variant. Fedora is self-standing and has a stable releases (each with ~13 months of support).

Odd choice, in my opinion

Posted Apr 21, 2025 15:06 UTC (Mon) by chexo4 (subscriber, #169500) [Link] (1 responses)

I use Fedora Kinoite daily on my desktop, but I would be worried as someone trying to implement it at scale that the KDE Plasma desktop it uses would be overly taxing on some machines. That said, I do think Plasma is very polished and a decent choice.

Other than that I'm mainly just slightly skeptical because of my own issues I've had with Kinoite, but those are mostly my own issues, that may not necessarily apply to the EU's case.

Package layering *is* one concern I do have. The public sector is not just one thing, and different agencies/offices/roles will have different needs for applications, many of which may not play well with Flatpak. So you'll end up package layering things and that is... not the most reliable sometimes. I've had issues with it at least for my use case (Steam + Nvidia kmods).

I do hope they're looking into rolling their own solution. At their scale that really makes more sense.

Odd choice, in my opinion

Posted Apr 22, 2025 10:39 UTC (Tue) by abo (subscriber, #77288) [Link]

Layering can be done by building custom images, rather than client side rpm-ostree manipulation. That's much more reliable and I'm sure that's what would be recommended for organisations.

Not the first time

Posted Apr 24, 2025 5:22 UTC (Thu) by carlosrodfern (subscriber, #166486) [Link]

The EU has been talking about utilizing Linux as OS for the government desktop to achieve technology independence from the USA for almost two decades. Being there, never comes to fruition. I hope it is for reals this time.