I disagree about it being editable via the UI, because doing so increases the amount of work we need to do, not only for the snapd core team, but also for the snappy store team, and for our colleagues at canonical and our friends in the community working on integrating snapd into graphical software centres, with no benefit to our users beyond a (imho minor) convenience to our developers.
This is based on my understanding that once a user has accepted (implicitly or explicitly) a license for a software they have installed, changing that license should require they accept it again.
On the snapd side, if a license can change together with a revision, we need to add work to block refreshes that see license changes, and to notify users that this has happened so they can manually approve (implicitly or explicitly) that license change. This of course depends on warnings, and both it and them will result in more work for software centres, but it’s doable (and as I see it most of the client-side work is part of warnings, not part of this use of them).
If a license can change at any moment, and not tied to a revision, however, we need to be able to … deactivate the software until the user approves? We now have put software on their devices with a license they have not had a change to review (even if we were to remove it, which seems heavy handed, what we’re saying is that there will always be a window when the software on their device will have the new license). I think this would be bad. We need to alert the user of this, which means that the software centres need to have a way to alert the user of something that happened just now, which is a whole new workflow different from everything else these software centres are doing.
On the store side, having it editable via the web UI implies that all revisions will have the same license, as AFAIK the store doesn’t support otherwise. As I suspect this is not what we want, there’d be more work for the store here (how much I don’t know, but my understanding is that per-revision user-editable data would require significant rework).
Another reason (or maybe another way at looking at the same reason) this making them dynamic makes me uncomfortable is that if what we’re saying is that yes, licenses are per snap and not per revision, that means publishers can retroactively change the license of a snap. I can think of no example where this is reasonable and valid, and yet we’re taking on a bunch of work to make it doable.