I was trying to think of the best way to approach responding because IMO there’s a lot of potential discussion points and ways you can take this; but in summary, my honest opinion is whilst I can agree with the changes making sense in principal, they likely don’t make sense in practise.
The only thing I think forcing people to fill that metadata to do is:
- They’ll guess it, often wrongly.
- They’ll just use “Proprietary” and avoid it entirely.
For example, when I think of Chromium as a project, I’m aware it’s pretty liberally licensed. Despite that, what actually is it?
I’d need a lawyer to tell me in specifics, and now I’d have to consult a lawyer to upload a snap, including anytime a license ever changes, which they do.
As a practical example, e.g.,:
One of my snaps, as uploaded to Flathub
One of my snaps by me
The second is correct. the license was changed from MIT to AGPL, and the other package hasn’t updated this in 2 years and misrepresents the status of the license.
And even this isn’t entirely right, because actually, it’s an Electron app, which means… it’s probably going to be similar to Chromium above! But the upstream says it’s AGPL 3.0 - which as I understand it, the influence of AGPL3.0 demands that all other terms must be compatible with it in principal, meaning that aside from extra commitments (like displaying notices), ultimately, the other licenses practically barely even matter. The only license that ultimately effects what you can do with it ends up being the (A)GPL by design.
I’m sure there’s no foul play, because the nature of the project and what’s going on, there’s nothing to be foul about. However, MIT is absolutely not AGPL. There’s no point in forcing people to submit metadata if they aren’t going to do what I think is your real concern, actually maintain the stuff they upload. But personally, I think it’s a much more reasonable position to let the app deal with licenses in its own menus and UI, than it is to ask people who aren’t lawyers to pretend to be.
For that same app, the Flathub package claims the upstream dev publishes it but is unverified. The snap package says I uploaded it as a complete randomer to the majority of the world. Whilst I’ve done some contributions upstream, fair to say 99.99999% isn’t me. And yet it’s also fair to say if I was claiming that one package as a salary, I’d be suddenly be able to afford a mortgage. Is it better to direct people to me or them? Or is the answer both?
Ultimately, that’s why verified uploaders exist. I’m in a situation with a lot of my packages where upstream is happy for someone to do the work (when it’s done well), but actually, I’m not sure they WOULD want their name on it, because then you can end up with e.g., this:
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/39
With all the software in the world, I don’t feel that even if the well intentioned, forcing license metadata is practical, and similarly so the conventions on how publisher names exist. For every person who might feel wronged their name isn’t shown, there’ll be someone happy that it isn’t because “Snap sucks and I don’t want to be associated with NIH”, like the entire Linux Mint project asking to remove their branding from the snap install pages cos they don’t like us and it’s as simple as that, they don’t want snap associated with their brand, not everyone will.
This isn’t me saying people shouldn’t up the quality of their uploads and metadata being part of that, they should, and I think all my snaps do have licenses attached for example because people should be trying to push the system as far as they can. But that we shouldn’t force people to use functionality for the sake of using it just to get the results wrong in my honest opinion. Better to say “We don’t know/no comment” than to say something completely wrong is a common legal opinion.
Edit: This is already lengthy, but I think another important consideration is, the license field for a container implies the entire container is a singular license, despite software not being in isolation ever. To get this to be legally reflective nearer reality, you’d need to break down the license for every single stage-package, which, technically should already be the case with the snap manifest for snaps that ship them. In order to make that metadata useful at all, there has to be an implicit assumption that “the license metadata isn’t talking about Python, actually”, but legally, I should be declaring it.
