In T596#10989, @jonas.smedegaard wrote:

Such change(s) would be encouraging those resources.
Since those resources are external to us, we cannot ensure our users that they fit our constraints e.g. regarding software freedoms - and even if they happen to currently align with out constraints we have no way of intervening if that change later on, after our users have installed our system onto their systems.
PureOS is the subset of Debian which is "Free" both by Debian definitions and by Free Software Foundation definitions. Encouraging inclusion of Debian resources would - in the eyes of FSF - be encouraging non-free stuff, and we would loose the endorsement from FSF as being a Free system by their standards.

While I'm familiar with these concerns, as well as the standards of the FSF v. Debian, do we know this to be the case for certain? Not running our own addons store for PureBrowser also introduces this issue.

I really think it's unwise to try to replicate everything in-house, as the Free Software opposite of Microsoft's NIH lock-in strategy.

As we reach more users and customers in the digital freedom space, we're going to have to at least provide Tor and Tor-powered solutions like TBB, and it's a *very* bad idea to host our own versions unless we have a direct partnership with the Tor Project where their devs and packagers provide the updates. In my view, a Tor Browser installer script that grabs directly from the project is no different than an entry for APT.

We'll have to cross this bridge in general with Electron desktop apps like Signal, Riot, and Wire. I don't see why providing those repos as turned-off-by-default should be an issue, but I'd like to chat with the FSF about it if so.

I can tell you this is an extreme limiting factor in reaching people who care about privacy and security. If PureOS can't be used at a cryptoparty or as part of a digital self-defense curriculum, then I think there's a problem.

A comparison to the mobile space: If F-Droid can provide the Guardian Project repos as turned-off-by-default, repos that contain apps with SDKs that would run afoul of FSF guidelines, why can't we do something similar?

Not sure what you mean by "replicate everything in-house".

PureOS is essentially the subset of Debian that comply with FSF. I find it unwise to replicate Debian, but I do find it unwise to bypass Debian.

As we reach more users, I find it wise that we invest more in getting Debian to cover the areas we need.

Our users are free to turn their PureOS installation into a Frankenstein system by adding a Debian suite or install packages by oher means (be that .deb or npm or whatever). I don't see how PureOS can offer support for such things by their nature outside of our control, however.

Would be lovely if we could - I would like that very much.

Regarding what we can and cannot do according to FSF guidelines: Are you asking what the guidelines says, or are you asking how much we can bend the rules before our relations with them snap?

You're quite right that the GNU FSDG is very clear on this issue:

A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so. The system should have no repositories for nonfree software and no specific recipes for installation of particular nonfree programs. Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow. Programs in the system should not suggest installing nonfree plugins, documentation, and so on.

However, I would consider the Tor Project repo "committed to only including free software". Same goes for Debian main repo. We can't offer those as commented-out, and with the appropriate caveats for users who install software from them?

My goal is not to bring up a sore subject, but to make sure we maximize the potential use-cases (and expand the user base) for PureOS... especially with privacy and security-conscious people, who will be our best ambassadors.

I don't suggest bending of rules to do that, but we may also be limiting our options in ways that are not necessary to meet FSF guidelines.

I'll add really quickly - if Debian main is still considered problematic, I understand, but I don't think that precludes making some of the Electron-based clients for E2EE messaging available through their repos (though not marked by default).

I don't mean to kill the conversation here. Just want to keep separate concrete issues from "meta issues". I will take the liberty of relabeling this one to perhaps better fit what we are discussing here...

Thanks @jonas.smedegaard ! Potentially this is a bad forum for this discussion but I appreciate the title change.

Having conducted lots of privacy/security workshops with people across the user spectrum, I think PureOS can be the drop-in distro for those kinds of events. Right now, the unfortunate reality (at least the one I see) is that privacy-conscious users are choosing Apple. I truly think we can replace Macbooks and iPhones for these users.

Obviously, we've earned the honor of the FSF's blessing as a free distribution, and I would never want to ruin that.

A bit of some history...

Last fall, soon after I was hired to Purism and my interest in nitpicking and policy making became clear, I was tasked with tracking "Freedom issues" - i.e. make sure PureOS would comply with FSF FSDG.
Instead of simply "obey the gospel of FSF", I tried make sense of their rules and find the logic that make sense to me that PureOS follows - which happens to fit FSF rules but makes sense on its own as well.
The rule I have followed - which FSF does not dictate but in my interpretation fits their concretely written rules - is that PureOS must be responsible towards our users in what we offer them.
My guess is that FSF has peculiarly odd phrases like "Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow" is that they don't trust other organisations (e.g. Debian) to stay on the rght path, but they do want other organisations to trust them (e.g. use their list of Mozilla-compatible addons).

What I believe is a strong message for our users - be that freedom fighters golding cryptoparties, or big businesses that Purism wants to sell laptops for with a preinstalled OS on - is a system that is trustworthy in being _self-contained_.

Debian is a good starting point for that, but Debian is many things at once and from a trust perspective some parts of Debian is weak.

We can talk about the FSF versus Debian disagreement, that's fine with me. I am a strong believer of Debian (if you hadn't guessed that by now) but think I can stay calm in the presence of people with different belief :-)

Regarding Electron-based applications: I *do* strongly believe that it is a problem to pull in from external sources. If it is harmless, then why is it not in Debian? Typically when Free things are not being in Debian it is because they are too fast moving. In other words, *not* *stable*.
Yeah, I get it - users want shiny esciting things. I am a user too, and I want shiny exciting things. And then it breaks, and I loose data or worse. If it broke and it was delivered to me from my system distribution, then I treat that as a flaw in that system distribution!
I cannot imagine how I, as developer of PureOS, can ensure that things external to PureOS does not explode in the face of our users - and they then shouldn't blame us for that.

Please help me there...

In T596#11018, @jonas.smedegaard wrote:

A bit of some history...
Last fall, soon after I was hired to Purism and my interest in nitpicking and policy making became clear, I was tasked with tracking "Freedom issues" - i.e. make sure PureOS would comply with FSF FSDG.
Instead of simply "obey the gospel of FSF", I tried make sense of their rules and find the logic that make sense to me that PureOS follows - which happens to fit FSF rules but makes sense on its own as well.
The rule I have followed - which FSF does not dictate but in my interpretation fits their concretely written rules - is that PureOS must be responsible towards our users in what we offer them.
My guess is that FSF has peculiarly odd phrases like "Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow" is that they don't trust other organisations (e.g. Debian) to stay on the rght path, but they do want other organisations to trust them (e.g. use their list of Mozilla-compatible addons).

Those phrases are rms all-the-way, or at least written in his trademark style :)

What I believe is a strong message for our users - be that freedom fighters golding cryptoparties, or big businesses that Purism wants to sell laptops for with a preinstalled OS on - is a system that is trustworthy in being _self-contained_.
Debian is a good starting point for that, but Debian is many things at once and from a trust perspective some parts of Debian is weak.

Yes, some parts of Debian are weak. Giving users a clear understanding of the potential pitfalls is enough, in my opinion, as long as they actively make the choice and there are no license issues.

Where the "self-contained" aspect is concerned, this is exactly what I worry about, and what I alluded to with the NIH comment previously. I think it's better to continue that conversation in another medium.

We can talk about the FSF versus Debian disagreement, that's fine with me. I am a strong believer of Debian (if you hadn't guessed that by now) but think I can stay calm in the presence of people with different belief :-)
Regarding Electron-based applications: I *do* strongly believe that it is a problem to pull in from external sources. If it is harmless, then why is it not in Debian? Typically when Free things are not being in Debian it is because they are too fast moving. In other words, *not* *stable*.

There's no reason to believe that Signal is not stable, though there are sensible concerns about Electron as a wrapper for E2EE applications. Again, we have to let users make these choices, in my opinion, if we're to lead in the privacy and security space. Signal is specifically not in Debian or any other repo because of m0xie's security/design philosophy, which is also why there are no clones besides Noise in F-Droid, and why Noise only allowed to use WebSockets to connect to Signal's servers. In the past I've taken issue with this OWS approach, but it's also quite clear that OWS will not change that.

Beyond that, Signal and Tor are incredibly popular, and therefore constantly targeted, and the projects behind them can respond quickly to vuln disclosures and 0-days (especially because they'll be the first notified).

If there's no licensing/FSDG issue, I do think it's important to make them available with a few clicks. Shipping them by default is another story.

Yeah, I get it - users want shiny esciting things. I am a user too, and I want shiny exciting things. And then it breaks, and I loose data or worse. If it broke and it was delivered to me from my system distribution, then I treat that as a flaw in that system distribution!
I cannot imagine how I, as developer of PureOS, can ensure that things external to PureOS does not explode in the face of our users - and they then shouldn't blame us for that.
Please help me there...

Strengthening ties / creating partnerships with the upstream projects is something I think we need to pursue. For example, having TP recommend us as a preferred , trustworthy GNU/Linux distro to run Tor on (besides of course TAILS on a LiveUSB) would go a long way.

As far as things break/blowing up - we can have a good, sensible response about these other repos, as well as warnings when they are first activated. Perhaps some guidance and documentation for users who install these apps outside of PureOS repos.

The reward of having Tor Browser back on PureOS, installed easily, is worth it in my opinion. Signal would be another boost. The others merit more discussion.

Others than me in Purism/PureOS are happy about Flatpack - doesn't that provide the needed sidechannel for injecting these popular tools?

In T596#11020, @jonas.smedegaard wrote:

Others than me in Purism/PureOS are happy about Flatpack - doesn't that provide the needed sidechannel for injecting these popular tools?

I've been rather convinced by the examples at https://flatkill.org , which is why the sidechannel injection metaphor is not lost on me. Even were it not so, I would suggest sticking with APT and upstream repos wherever possible.

...but the very issue you are raising here, if I understand you correctly, is that things like Electron apps and Tor Browser are - in your opinion - reasons to relax that "whenever possible" part. Right?