I’m so jealous … but I’m also so mad with the snap-store. Because those 50 snaps don’t have a link to the projects where the wrapping of the snaps takes place nor the source code where the original code is, neither of those should be optional. I get it… it is hard to prove the veracity of that information.
Just take the URL from source of the snap. Oh you can’t because it is a binary under ftp or whatever? OK, this started an our ago or so when I tried to get Glade from the store, it’s a snap published by the contributor mentioned above but there is no repository for this snap.
What ever is in that snap is in the cloud and there is no way I can confirm what code I’m getting from the source. This is just one example, there are plenty of different scenarios so let’s get started to improve the standardization of this practice.
Community? Well … yes. No! My point is this:
The software is usually accompanied by a license. If it hasn’t one then it has implied a different type of license. Some snaps have license description and some others don’t.
There is no obligation to make your software free, unless it is not yours. I mean, unless there is a license you have to honor.
It’s like suddenly Canonical has completely forgotten the types of licenses out there.
Not provide this information (original developer and/or contributors, access to source code, or any information that can lead to that) when it comes to GPL licenses is a violation to the agreement.
So that means that Canonical, and the community could see the Snaps initiative frustrated (maybe not soon, and maybe this is an exaggeration but I think it needs discussion). One could argue that the platform is not responsible for what the publishers do but I don’t think this is how Canonical is handling this ecosystem
“You represent that the Snaps you publish to the Snap Store do not infringe any intellectual property right of any third party or any applicable law or regulation.”
This should pretty much cover all licensing issues … packagers are responsible to ship the correct licenses (there is an optional “license” field you can use in snapcraft.yaml and via the web UI), generally neither is required though. what is required that your snaps ship the licenses alongside inside the snap where the licenses do require it …
That is half valid. I have to download the snap to see what’s in there.
But yea, it’s a valid argument given that some packages from repositories not always have a link to the source code. You still can download the sources though.
And at the of the day it depends on me whether to download a snap or not.
And I understand that putting the responsibility of verify the correctness of the licenses on Snaptcraft could lead to inefficiency in other required areas or tasks in the processes. Such as approving permissions for auto-plug (and maybe change a snap from channel too? I can’t remember).
I guess it will do. If the snap gets popularity then the publisher risks to confront legal issues and honor the license. And if not, then nothing happen. But that doesn’t mean it is not important…
That could generate a lot garbage for software applications with a graphic interface so I think it makes sense that there is certain control from a centralized entity that register, approve and distribute those snaps.
