12

Are there proprietary elements of Snap server? Is it possible to run Snap-based distribution independently of Canonical?

I am quite disliking Snap for multiple reasons (one of things that I like most on Linux is that I can install/uninstall things with apt-get, snap does not have even decency to provide direct help on snap upgrade).

But the most worrying thing that I heard is that Snap has proprietary elements, making it fully Canonical-controlled.

See for example https://www.techrepublic.com/article/why-canonical-views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/

Martin Wimpress, engineering manager for Snapcraft at Canonical at that time:

Snap store is proprietary

https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/

the server end (the 'app store' bit of the equation) is closed source, and Canonical have been refusing to tell anyone how to run their own 'app store' (...) it is entirely controlled by Canonical

(and also describes how Canonical was lying about Snap)

But infoboxes in https://en.wikipedia.org/wiki/Snap_(package_manager) list open source licenses.

What is going on? Have they released Snap store as open source? Or is Wikipedia article incomplete/damaged by Canonical employees?

I am quite worried, especially given that Ubuntu started making basically impossible to avoid Snap on Ubuntu. On the other hand I would prefer to have good reasons to switch Linux distribution, not just based on outdated blog posts.

reducing activity
  • 1,095
  • 1
    Some of your detail is outdated (Martin Wimpress left Canonical some time ago & it's been blogged how you can download snaps & later install them locally (like you can wget a deb package then dpkg -i install it); the download & install however is not a Store. – guiverc Dec 24 '21 at 08:16
  • Canonical employees have said many things about snaps, but I cannot think of a single lie ... – matigo Dec 24 '21 at 08:19
  • @guiverc As I understand, at time of that article he was representing Canonical at that time (and could be treated as expert at that time). So, at least at that time, Canonical confirmed that it is proprietary and announced that it will stay this way. – reducing activity Dec 24 '21 at 08:19
  • @matigo https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ See "it's a pretty big mis-representation" part and "They certainly did not in any way inform Fedora that they were going to send out a press release strongly implying that Fedora, along with every other distro in the world, was now a happy traveler on the Snappy bandwagon."+"claim that Snappy enables "a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device" sounds lovely, doesn't it? Let's take a look at the truth" – reducing activity Dec 24 '21 at 08:20
  • @guiverc "you can download snaps & later install them locally" That seems covered by https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ "If you want to distribute your snaps, your choices are 1) publish it through the Canonical store, entirely under Canonical's control, 2) upload it as a file and tell people to use the CLI to install it, or 3) try to figure out how to reconfigure the snap client to use a different server by reading the source code, then write your own server end from scratch." – reducing activity Dec 24 '21 at 08:21
  • 3
    Meh. I care not one bit about the perceived politics around the thing. Drama is for high school, and I'm far too old to be a part of such silliness. If you do not want to use Snaps, don't. There are plenty of alternatives, including Ubuntu-based derivatives that have stripped out the Snap bits. Use what works for you. – matigo Dec 24 '21 at 08:22
  • I won't deny the Snap Store contains closed source software (ie. how Canonical run the server backend), all snap software that you & I run on our machines is open-source; it's the snaps we download ourselves that may not (but we control those) & Snap Store infrastructure (Canonical) our open-source front-ends on our machines (open source) deal with isn't. I would trust Adam Williamson understanding, though I'd personally use Alan Pope's (ie. ex-Canonical-er) blogs about the topic as a more trusted source (ie. someone that was inside to form opinions; though may be a little tongue-tied) – guiverc Dec 24 '21 at 08:22
  • @matigo "If you do not want to use Snaps, don't." - well, I am trying to figure out whether I want. If it is an attempt by Canonical to migrate from open source apt to something where crucial elements are controlled by Canonical then I will need to migrate myself.

    "There are plenty of alternatives, including Ubuntu-based derivatives that have stripped out the Snap bits. " - which ones? Is Debian also putting crucial parts of system into snap packages?

     – reducing activity Dec 24 '21 at 08:25
  • I have asked this as a new question. – B.Tanner Dec 24 '21 at 08:57

2 Answers2

12

The actual package management tools for Snaps - snapd and family - are open source. That's what makes the Snap package management system open source and Canonical is not lying about that.

It is true that snapd is hardcoded to use Canonical's servers for obtaining snaps and the metadata associated with them. And the source for the backend servers is not available as far as I know. Various other parts (e.g., the snapcraft.io website, the Snap store app itself, etc.) are open source. I mean, you could serve deb files from an IIS server, but that wouldn't make the apt package management system closed source, would it?

Can you make snapd work with another backend? Technically, you could read the snapd source, figure out the protocol (which shouldn't be difficult - I think the code is fairly readable), implement your own backend, and build a snapd with a patch to swap the backend URLs. However, nobody seems to have done that so far, and Canonical haven't published a reference implementation.

muru
  • 197,895
  • 55
  • 485
  • 740
  • 8
    I mean, you could serve deb files from an IIS server, but that wouldn't make the apt package management system closed source, would it?

    If it would be sole existing way to serve deb files - then yes, it would.

     – reducing activity Dec 24 '21 at 08:47
  • @reducingactivity not as long as there are alternate ways to get and use those deb files - which is indeed the case with snaps too, as you know. – muru Dec 24 '21 at 08:48
  • 8
    So "If you want to distribute your snaps, your choices are 1) publish it through the Canonical store, entirely under Canonical's control, 2) upload it as a file and tell people to use the CLI to install it, or 3) try to figure out how to reconfigure the snap client to use a different server by reading the source code, then write your own server end from scratch." from https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ is still up to date summary? – reducing activity Dec 24 '21 at 09:02
  • 8
    Also, in addition to "snapd is hardcoded" - proposal to make it configurable was WONTFIXed https://bugs.launchpad.net/snappy/+bug/1593151 – reducing activity Dec 24 '21 at 09:05
  • Yes, as far as I can tell that's still correct. – muru Dec 24 '21 at 09:07
  • Please read the comment there - you'll see that it's using environment variables specifically that was unwelcome. – muru Dec 24 '21 at 09:08
  • 1
    environment variables were rejected, config files were not even mentioned, issue was wontfixed. – reducing activity Dec 24 '21 at 09:10
  • "The best would probably be to add support for multiple simultaneous stores in snapd itself" ... which implies conifg files as an alternative. The issue was marked wontfix three years after no further activity followed - so presumably people who want this couldn't be arsed to work with Canonical to make it happen. – muru Dec 26 '21 at 03:21
  • Anyway, none of this changes my point that you could figure out the protocol and build your backend, and patch snapd to do use it, since snapd is, despite all the FUD, open source. But it seems nobody wants do all that, but instead people are just happy to post FUD. – muru Dec 26 '21 at 03:23
  • 3
    Well, I am perfectly fine with apt, I would be likely perfectly fine with flatpack. I see no good reason to spend months of my life (or years) on fixing system that I do not want, do not need and I am not forced to use. I would - at most - change operating system to one not forcing snap on me. Though proprietary Snap Store is likely enough for me to avoid it. – reducing activity Dec 26 '21 at 23:08
  • "That's what makes the Snap package management system open source" - if critical parts (server) is proprietary, than Snap as entire package management system is NOT open source. – reducing activity May 12 '23 at 08:24
  • @reducingactivity the protocol is right there, nobody's stopping you from making your own server, so it's not critical. – muru May 12 '23 at 08:39
  • Neither noone stops me from creating open-source OS that is capable of running all .exe files running on Windows 10. This does not make Windows 10 open source. – reducing activity May 12 '23 at 16:01
  • @reducingactivity but neither does that make an open source software that uses Windows APIs closed source. Or are you claiming that Ubuntu itself and everything in Ubuntu is closed source, because they can run on WSL 1 which is essentially a translation layer between Linux system calls and the Windows API? – muru May 12 '23 at 18:31
  • I am not claiming that. I am claiming that Snap in general is not open source, as it has critical components which are proprietary and its open source components included in Ubuntu are hardcoded to use proprietary server. – reducing activity Dec 19 '23 at 21:27
  • @reducingactivity and I am claiming that nothing is preventing anybody from replacing this oh-so-critical component with an open source one, so it is not that critical. – muru Dec 20 '23 at 00:03
  • Until replacement exists Snap packaging system is not open source. And this part is critical, as Snap cannot work without it. – reducing activity Dec 20 '23 at 00:08
  • @reducingactivity it is not critical, since one can build and distribute snaps without it, so snap can work without it. – muru Dec 20 '23 at 00:10
7

The Snap Store is run and controlled by Canonical and is not open source. The rest of Snap is open source, meaning the daemon and core software. How threatening this is depends on you POV and has been the subject of much discussion. E.G.

As a Linux newbie myself, I've just finished researching snap issues after finding the (LM) program manager doesn't list any snap packages. What I found was that adopting a firm line approach may sever dependency on the Snap Store but replaces it with another problem - in my case missing or receiving out of date packages installed using the Linux Mint package manager:

  • The (LM) PM installed a 10.x version of node instead of the current 16.3.1 LTS version,
  • The nodepad-plus-plus working snap package for Notepad++ (natively available under Windows) was simply not listed. A Linux version (notepadqq) can be installed - and I did - but is not a substitute for using the original.

This is where pragmatism and life expectancy comes into play: personally I enabled snaps to install notepad-plus-plus, with which I have decades of experience and consider a "must-have", but would search extensively before installing snaps simply because I can. FWIW I'm not sure if installing node from binaries by running the archive manager GUI as root was a good idea, but it got the job done.

TL;DR

Yes, the Snap store is controlled by Canonical. Whether that is sufficient reason to compel a move away from Ubuntu is a matter of personal opinion and beliefs, and heavily depends on how and why you select and use snap packages in general.

Pablo Bianchi
  • 15,657
traktor
  • 194
  • 2