From their GitHub:
cpak installs applications from OCI images while keeping package metadata in a Git repository. It provides native desktop integration, shared content-addressed layers, atomic updates and a rootless Linux sandbox from one Go binary.
It seems interesting. I’ve never heard of it before, but apparently Bottles packages with cpak along with flatpak. The main reason I use flatpaks are its sandboxing capabilities, so it would be cool if cpak brings new stuff to the table while matching or overpassing the sandboxing capabilities.
IIRC, it’s another brain child of Mirko Brombin; the prolific designer that’s also prominently involved with Bottles, Singularity Desktop/OS and Vanilla OS.
I wish it the best. Especially since Flatpak’s sandboxing didn’t have any competition up till now. At least, AFAIK*.
I just read the license of cpak and I can’t say I’m a fan.
Why? It’s a fair license but with corporate restrictions
This license provides full access to the source code, encourages public auditing and community collaboration, and imposes copyleft rules. However, because it includes a restriction on replicating the core purpose of the Product, it does not meet the Open Source Definition (OSD) by the Open Source Initiative (OSI), anyway, the point 6b ensures the license will eventually convert to an OSI-approved license.
FPAL is best described as a source-available, copyleft, and business-protective license.
Honestly, if any distro included this, it would be an instant red flag.
The restriction pretty much aims at companies like Amazon that rehost an open source project. That sounds pretty fair to me
What about this? This basically forbids you to fork the software if you want to - e.g. because they’re maybe going closed source in a few years?
You may not use the Software, in whole or in part, to create, distribute, or operate any product, system, or service whose primary function directly overlaps with or replicates the core business purpose of the Product, unless explicitly authorized in writing by fabricators.
The way I read that is they don’t want forks fixing specific issues/making improvements when those changes could all be in the one implementation.
Yup, that’s simply a deal breaker. [For me].
If it’s for you, too, you could maybe even mark the post with [SOLVED] or “Update:…”. If you wish. No obligation.
