This is a years old quote from [0], but it doesn't feel like anything changed since.
> 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, and tell your users to do that.
[0] https://www.happyassassin.net/posts/2016/06/16/on-snappy-and...
You also need to
1) compile and distribute your own version of snapd, since it hardcodes the Canonical snap store.
2) Set the appropriate env variable to prevent snapd from auto-updating itself back to a Canonical version.
I'm with you on the "it's not explicitly-for-profit" point at the moment, but it is set up in a way that it could change at any point. Whether it's set up that way deliberately or not, we can only guess.
Anyway, Ubuntu derivatives are approaching the topic with this in mind. Linux Mint forbids snapd from being installed via apt (https://www.theregister.com/2020/06/02/linux_mint_team_snap/), and elementary OS goes a step further and is working on making its entire app ecosystem flatpak-exclusive (https://blog.elementary.io/elementary-appcenter-flatpak/).
Can you clarify "explicitly for-profit"? I don't think that's true: https://en.wikipedia.org/wiki/Snap_(package_manager)
Snap is practically the opposite of that. It's a package manager that is almost entirely out of the hands of Canonical, which was one of the criticisms of apt.
If you mean to criticize that some of Snap is proprietary, that is legitimate, but that doesn't seem to be the aim here.