This is why I prefer when people use libre to classify software that doesn’t contain any close source elements, it’s so much easier to understand, and you don’t have the issue with the word being used the “wrong way”.
Most people don’t automatically assume that free if the FSF definition of free, it has other meanings. To many people, it just means you can freely use the software, you don’t need to pay for a license, and you can freely copy it.
It seems this discussion mixes two very different things making some replies unclear: FSF-endorsement (which you can reasonably call “ideological pureness”) and the free code license (the Wikipedia/community definition). The former is not achievable for Qubes, because of its security goals (as @adw explained quite well in the updated FAQ), whereas the latter applies to Qubes code, except the binary firmware necessary to use it on most hardware. There is no ideology in the latter definition. It’s just based on the type of license. You shouldn’t call a mix of free and non-free software “free software”, because it’s simply misleading and wrong, even if you have good intentions. Yes, it’s an amazing and costly achievement that Qubes is almost fully free software, and the Community, including me, values it very much. It’s why I am using and supporting it and spreading the word. But stretching definitions is not how you gain community respect. Debian rightfully call themselves “free operating system” on the main website. This is about the practical, license-based definition. Qubes currently is using “Debian non-official” without telling anyone. Fedora is not a free OS as a whole, and Wikipedia correctly doesn’t call it “free software”. Official Fedora website doesn’t call Fedora “free software” either:
Fedora creates an innovative, free, and open source platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.
I fail to see how my personal opinion matters here. I remind that we are talking about absolutely unnecessary and potentially untrustworthy software in the official Qubes template, without clearly explaining it to the users.
Wikipedia is not a source. It’s a list of (reliable and verifiable) sources, which reflects the accepted point of view in the society. It’s not a reflection of a large number of edits, unless the article is unfinished, or has edit wars. I think in this case the definition of free/open source software is pretty much settled, which is precisely reflected there.
I was talking about the licenses, not FSF-endorsement.
I’m sorry that I was unclear. There was no personal attack here. I am not talking about you but about the text in the FAQ, which you are seemingly trying to defend:
Qubes is free and open-source software (FOSS).
See above why I think that it’s dishonest.
The articles you quoted don’t have word “proprietary” at all. What do you understand by “proprietary devices” anyway if not devices running and requiring proprietary software? Moreover, the context of this discussion is free software and how its freedoms help users. I’m sorry if I was unclear somewhere.
The articles do not mention how the lack of user rights leads to their powerlessness, they just say that the companies doing bad things are bad.
What do you think about saying something along the following lines?
Qubes OS is a free OS, except the microcode, which is necessary to achieve security in modern hardware. The operating systems running inside Qubes OS by default (Fedora and Debian*) contain proprietary firmware required by most hardware today.
In other words, I suggest to remove the Fedora and Debian from the definition of Qubes OS. I guess I’m still running Qubes OS even if I replaced all templates with Trisquel. Am I right that nothing proprietary except the microcode exists in dom0?
*Having said that, I would like to repeat that I see no reason whatsoever to include proprietary firmware into Debian in the default Qubes configuration. Even if you believe that FLOSS doesn’t improve security (I’ll try to find some evidence otherwise), any unnecessary software increases the attack surface. It also breaks the expectations of regular Debian users who come to Qubes (like me) and goes against the Qubes FAQ about changing the distros. Manually changing the template for sys-net is an advanced feature, so I expect that such users should know how to add non-free repositories; and I am ready to help them do it, too. Choosing Debian as main template at install should give a warning that non-free repositories will be switched on to get the firmware, if needed.
+1
If I understand correctly, you’re saying that it’s accurate to call something released under a free code license “free software.” Here’s what we currently have on the Software license | Qubes OS page:
Qubes OS is a compilation of software packages, each under its own license. The compilation is made available under the GNU General Public License version 2 (GPLv2).
The source code of Qubes OS is contained in repositories under the @QubesOS account on GitHub. This source code is made available under GPLv2, unless there is a
LICENSEfile in the root of the containing repository that specifies a different license.The full text of the GPLv2 license can be found here.
If this page is accurate, and if GPLv2 is a free code license, then it seems to follow that it’s accurate to call Qubes OS “free software.” If this page is not accurate, then of course we should correct it, but I don’t recall anyone objecting to this page so far.
So, this says that Fedora “creates a free platform” (whatever that means). Compare:
Qubes OS is a free and open-source, security-oriented operating system for single-user desktop computing.
This says that Qubes OS “is a free operating system.”
You’ve stated that the former is acceptable to you, while the latter is not. Is that because of the verb “creates” rather than “is,” or the noun “platform” rather than “operating system,” or something else?
Sure it is. It’s just not always a suitable one.
They’re not always reliable and verified. People make mistakes. Sometimes edits are malicious and aren’t instantly caught.
If you think that Wikipedia editors are truly a representative sample of society at large and aren’t a self-selected group, then I don’t know what to tell you.
You’re putting words in my mouth. Please read the statement again.
Sounds fine, except this is still too much detail for the short <200-character description of Qubes OS that we need for the website meta description and character-limited descriptions in various places around the web, so we still need a solution for that. Remember that the entire description can’t just be about software freedom. People also need to know what the thing actually is, what it does, and why they should care. Those are actually the most important parts. (While software freedom might be the most important thing to you and some others in this thread, it’s not the most important consideration for everyone, and most regular folks have never even thought about it.)
I don’t really know anything about the Debian template situation except what I’ve seen folks say in this thread (and have hitherto avoided discussing it for that reason). Let’s ask @marmarek:
There are few points here:
Also, take a look at this issue: https://github.com/QubesOS/qubes-issues/issues/5123
Running an x86 system without microcode updates is foolish. Projects like Libreboot and Trisquel that support x86 but do not include the needed microcode updates are fundamentally insecure and misguided. x86 is a fundamentally closed platform and will always require non-free microcode at a minimum. If you want to run Qubes OS on a fully-free system, the best way to get that is to help with the port of Xen to POWER, as POWER can be secure without non-free firmware.
Most of this thread is not actually about microcode, but firmware for various auxiliary devices (wifi etc). Those are totally independent of CPU architecture you use.
You can attempt to build your system with devices running only open-source firmware. If you want to achieve it in full, you’ll indeed probably need POWER CPU (disclaimer: I haven’t checked microcode situation there, but it is possible it’s better than on Intel/AMD). But it is very easy to get into a trap of old (proprietary or not) firmware. If you get a device that appears to work fine without loading any firmware blob, it simply runs a firmware stored on the device itself. It could be an open source firmware, sure, but in fact, you have very little ways of verifying that claim (you’d need a trustworthy way of extracting the firmware, and a reproducible build to compare against). In some cases this embedded firmware can in fact be updated (devices with writable firmware flash), but has its own set of issues (you loose reliable way to reset device to a “clean” state).
Ideally you want auxiliary devices without mutable internal storage and all the firmware must be loaded when device is initialized. And that firmware you want to be free and open source and can be built by anyone.
In practice, many attempts at “blob-free” devices in fact fall into some of those categories:
Note FSF recommends option 1 (if no free firmware is available), which is actively harmful for users overall security, but also their freedom (no way to replace proprietary firmware with free alternative, when one become available).
I don’t really know anything about the Debian template situation except what I’ve seen folks say in this thread (and have hitherto avoided discussing it for that reason). Let’s ask @marmarek:
I’ve already dealt with these more than a week ago.
Yes, we do.
We do it for security, and to make the experience easier for a wide
range of users on install. (I specifically added a wider range of
firmware packages to the Debian template to match those available on Fedora)
It’s not an exception to our policy. It’s a standard application of it.
“We try to respect each distro’s culture, where possible”
That description is inaccurate and should be changed.
The software is free. The OS is not.
(This has nothing to do with Debian in particular.)
" All the software produced by Qubes is free.
Because we are a security distribution we include non-free firmware to
address known vulnerabilities.
Because we want to make installation easier for a wide range of users
across many devices we include some non-free firmware and drivers in our
standard templates."
As Qubes is libre, it’s open to anyone to produce a version of the OS that is
fully free. I don’t know what the point would be, but they could. It just
would not be a security distribution - perhaps “Libre Qubes - a
definitely insecure Operating System”
I’ve previously offered a Trisquel template, and will undoubtedly do so again.
I wish that a quarter of the energy expended on this thread was put in to
improving Qubes.
That is the YubiKey situation. They do have a decent security policy, and will replace devices found to have security flaws.
Yes.
Is the non-free firmware included in this “compilation”? AFAIK yes. If yes, you can’t reasonably say the following
You can’t distribute proprietary software under GPLv2. (Some) users are mislead into thinking that Qubes .iso contains no proprietary software.
I think it’s pretty clear what that means. Fedora create free software, but distribute it together with non-free software (firmware) which they do not create. It’s a very careful and correct wording, unlike with Qubes OS.
Fedora do not try to call their software compilation (i.e. .iso files) “free software”, which it isn’t. It’s a compilation of free and non-free software, just like Qubes. It’s a fact based on the licenses of the software, not purity. This is indeed unfortunately unavoidable today, but clearly explaining it to the users is nevertheless important.
I guess if you wrote “Qubes project creates free software”, it would be at least technically correct. But the operating system as a whole is not free software. Alternatively, as I also suggested above, one could say that Qubes OS is free software, except the CPU microcode and default operating system(s) running inside in VMs (is this short enough?).
Agree. I’m just trying to point out technical/naming inconsistencies in the description, which mislead the users.
I believe FSF will not go against replacing the proprietary firmware with free software, if the latter becomes available. Freeing software is actually the only good reason to use non-free software, according to the FSF.
Not everyone has an ability to do so. Also, fixing incorrect description of the project is improving Qubes.
My arguments about Debian were ignored for some reason. Why can’t Qubes ship actual, official Debian in the default configuration? How does it improve security? How does it improve user experience? It doesn’t. It goes against the expectations of Debian users. The docs don’t even tell how to achieve the official Debian configuration. I was mislead by this.
Imagine that there is some Xen vulnerability, which requires a carefully written exploit that is easy to spot. You set up some scanner to watch for it (defense in depth). Maybe you can even watch from outside the qube? Proprietary firmware can easily hide such exploit and regularly ship updates to it, so any tiny malicious code in the qube can use it and escape.
I already replied to this above:
I don’t think anybody disputed this.
I understand for functionality … but could you clarify the security argument?
Here is the non-free software in a clean debian template:
$ vrms
Non-free packages installed on debian-11-vrms
amd64-microcode Processor microcode firmware for AMD CPUs
firmware-amd-graphics Binary firmware for AMD/ATI graphics chips
firmware-linux Binary firmware for various drivers in the Linux kerne
firmware-linux-nonfree Binary firmware for various drivers in the Linux kerne
firmware-misc-nonfree Binary firmware for various drivers in the Linux kerne
intel-microcode Processor microcode firmware for Intel CPUs
Contrib packages installed on debian-11-vrms
iucode-tool Intel processor microcode tool
6 non-free packages, 0.5% of 1322 installed packages.
1 contrib packages, 0.1% of 1322 installed packages.
I don’t see a security argument, but do see a functionality argument, for some firmware. (Is a VM even allowed to load microcode into the CPU? Do gpu firmware provide any functionality? If you are somehow getting GPU passthrough working, I think it is not too much to ask to apt-get the GPU firmware).
But the exclusion of this software is why some users chose debian in the first place!
where possible, not where convenient.
It is possible to have both debian template without non-free, and working wifi etc… (even if it requires non-free firmware): just use fedora for sys-*. That is the default set up by the qubes installer when a user selects both fedora and debian templates in the system installer - the service VMs default to fedora-based.
I agree removing non-free from debian is a major inconvenience for people who deliberately have no fedora template at all (by deselecting the fedora template during installation). But the kind of person who wants a debian-template-only system is more likely to have strong opinions about free software, more accepting of breakage caused by their choices, and more likely have hardware specifically chosen to work with debian, than the average qubes user.
I’ve opened a PR that attempts to address some of the matters discussed here. Feedback is welcome:
In particular, it adds a sentence to the license page that attempts to address the matter of non-free firmware being included in the compilation of software that is Qubes OS, but I don’t know to what extent it is helpful or makes sense (see my comment here).
The bulk of the PR is a new description for the “What is Qubes OS?” entry and a new entry titled “Is Qubes OS free and open-source software?”
(While writing this, it occurred to me that the debate over whether Qubes can be called “free” may also apply to whether Qubes can be called “open-source,” i.e., whether the inclusion of some non-open-source software disqualifies it from being called “an open-source operating system.”)
Also added this change:
In general, we try to respect each distro’s culture, but we reserve the right to make modifications that we deem appropriate.
Some folks started to get very legalistic about parsing the precise language of “where possible” as opposed to “where convenient,” etc., which seems entirely misplaced, as that language was never in the context of a binding contract, legal license, or similar document. Rather, it was in the context of an informal FAQ entry, and was therefore not written with that degree of precision in mind. Moreover, “where possible” is usually (as it is here) a figurative turn of phrase used to mean something like “to the extent feasible” or “as a high priority (but not necessarily the highest and still as just one priority among others),” similar to saying that I will do something “as much as I can,” which usually does not literally mean until I physically collapse from exhaustion, malnutrition, organ failure, etc.
adw, I just read your latest commit and I think it’s excellent. I personally like that much better than the previous phrasing before your modification today, as I think it is far clearer for people who care to know more exactly what they might be using (such as myself). Like many of us, I imagine, I knew what what Qubes was fairly well and valued its work and existence without the explicit definition when I first downloaded it, but I do see the value of, and indeed I respect, that level of clarity in the modern software landscape.
One suggestion: I think it would make a lot of sense to hyperlink or cite the free/libre words you have there to the FSF definition page and perhaps cite any other terms or definitions that might be contentious? That way everyone would be very clear and the definition concerns would then be relegated to the FSF or other defining-organization.
Doesn’t this weaken the statement to the point that it is vacuous?
Just in everyday language, there is a difference between the two.
If this is with reference to the specific case of removing non-free firmware from debian, a still fully-functional default (with fedora-based sys-net) is not that high a price to pay.
I just thought of another thing I’d really like to see added to the documentation aside from my citation suggestion above: Can we compile the list of binary firmware or microcode or any other closed source material and link from your statement on the non-free components to that page? On the non-free manifest, we could include exactly what files are involved and exactly what they do and why they are there, as well as which Templates or VMs they are contained in, a bit like an ingredient list on one of the more enironmentally-responsible cleaning products that I have started to see recently! I would value that and I bet some other out there would as well.
Before you decide to weaken this policy, I think it is worth looking into the motivation for the policy. Maybe someone can chime in with the actual historical reasons for this policy, but here is why I think a template respecting a distro’s culture is a good idea, especially in regards to software inclusion:
Sure, done. I didn’t really see any other contentious terms or definitions, but let me know if you do.
No. It still communicates exactly what it says. We get a lot of people asking us to make tons of changes (basically, “build me my wish-list Linux distro as a template”). Being able to point them to this FAQ entry is handy. It discourages people from asking us for every conceivable Fedora and Debian change that would be nice to have (in their mind). It also has other benefits, as explained in the entry itself.
Also, giving the devs more latitude to do what’s best for users and the project is a boon. Weakening the statement is a feature, not a bug.
Did you actually read the whole thing? The answer is already right there in the entry. Here’s the entire entry, as it stands right now:
What is Qubes’ attitude toward changing guest distros?
We try to respect each distro’s culture, where possible. See the discussion on issue #1014 for an example.
The policy is there mostly to ease maintenance, on several levels:
- Less modifications means easier migration to new upstream distribution releases.
- The upstream documentation matches the distribution running in the Qubes VM.
- We’re less likely to introduce Qubes-specific issues.
- Each officially supported distribution (ideally) should offer the same set of Qubes-specific features - a change in one supported distribution should be followed also in others, including new future distributions.
Notice the bolded portion. The main motivation is to ease maintenance. In other words: convenience! So it makes no sense to criticize the interpretation of “where possible” as “where convenient,” since that is already part of the explanation to begin with.
Now I’m guessing you’ll say, “Yeah, but convenience for maintainers isn’t the same thing as convenience for users!”
You’re missing the point. All that means is that nobody has gotten around to adding stuff about convenience for users to this FAQ entry yet. This is not a binding legal document! Not even close! You are trying to turn it into something it’s not. It’s here to explain our rationale for why we operate the way we do, not to bind us to operating in a specific way.
I think I’d like to try to create that in documentation, as suggested in the PR page you link, adw. I haven’t ever used the github system before to contribute something so it may take a bit of time to get familiar for me, but the big obstacle for this addition is that I am not yet linux-savvy enough (working on it) to know how to find out what binaries or other proprietary code might be included in each template or Qubes base. Can anyone point me to how I might determine that?