This thread is a bit tangled, I’ll try to summarize what’s been discussed so far and scope the thread to have a clearer picture. For reference, an index of the threads discussing licensing topics is at the top of this post on another thread. I apologize if there’s a proliferation of threads on licensing: it’s a complex topic that involves several components and encompasses several user stories and I think by discussing each more narrowly we stand a better chance of designing this in a way that will satisfy everyone’s needs. That said, if anyone feels we should consolidate some of these threads, please let me know.
General proposal for license handling
Gustavo and John made a proposal contained in 2 earlier posts on this thread:
-
snaps will have a license field - the field name is discussed in Accept license field in snapcraft.yaml - #3 by niemeyer. Is there another thread regarding the required changes in snapcraft and click-reviewer-tools? If not, I would suggest a separate thread which can talk about aspects mentioned here, such as validation with a tool provided by snap itself and other related things.
-
Implement the described logic in the store - I think we can scope this thread to this point. This kicks in once a snap with a license has been uploaded and validated by the click-reviewer-tools.
-
Support custom licenses is discussed on Support for custom license text - #28 by roadmr
-
Change snapcraft to warn about missing licenses - Probably bears separate discussion as well, it might be good to postpone this until the previous steps are done, because if we don’t have a usable “this happens when you set a license in your snap” story, publishers will be confused. In any case this is much more clear-cut.
-
Change the store to reject new snaps without licenses after a grace period is also pretty clear-cut and as Gustavo mentioned, it can only happen once snaps with licenses are flowing nicely into the store.
Specifics on how to store and present the license in the context of a single snap
For item 2, the common aspects are:
- Incoming snap uploads should have a license: field.
- The store stores the license data per revision.
Then we have two different proposals for where to get the license for the snap (the difficulty to solve here is that several revisions for the same snap may have differing licenses).
John and Gustavo propose the snap’s licensing data, as contained in each uploaded revision, as the sole authoritative source. There would be a store-side heuristic (to be refined), which when asked about the license for the snap, will give the license for the most stable channel for which there is something released for this snap. Thus, if there’s something in latest/stable , the license for that revision will be shown. If not, but there’s something in latest/edge, then that’s what’s shown. Difficulties pointed out with this approach:
- The heuristic adds complexity to both documentation and code.
- Because of channel map constraints (arch, validation, epochs, etc), the snap could expose a (dynamically calculated) different license. The heuristic may need to take this into account so the results are consistent, and designing this behavior is a given if we decide to go the heuristic way.
Bret suggested using the existing metadata workflow to modify the license. That is:
- a snap-level “license” database item would exist in the store and be updated with the contents of the
license: field in the .yaml every time a snap is pushed.
- The usual metadata rules for conflict resolution and forcing updates via snapcraft would apply.
- In principle this allows keeping the existing web UI for updating the license (with conflict handling per the above), mainly for consistency with other metadata.
- This is the license presented to the user when asking about the license for the snap.
Shortcomings with this approach:
- “makes people think that just having a license set in the store is enough to give their snaps a license. It’s not.” This was put quite clearly by Gustavo so I quoted him
- Two places to set the license, which may be a problem even with the conflict resolution properties of metadata, given the nature of licensing data.
- “the license is tightly bound to the snap content”. A compelling reason for not allowing editing of the license out-of-band.
So in order to move this now narrower topic forward, I think we could focus on discussing and choosing one of these two approaches, or maybe design another one which takes these concerns and desirable properties into account. Even if this is only a starting point for a discussion to be had later.
Other things
We’ve already mentioned that the license presented for an installed snap is that of the installed revision, which is unique and non-ambiguous.
Another aspect that was discussed in this thread is what happens when the license changes and how to notify the user which spills into the general topic of responsibility for presenting the license and gathering acceptance from the user. As mentioned in Support for custom license text - #28 by roadmr, “Deciding when and where we show the license to the user for acceptance. It sounds like we’ve discussed that before but I didn’t find any relevant topics. If there are none, I would prefer starting a new one. This has implications as to whether the store needs to keep a copy of the custom license, or just needs to indicate that there is a custom license and that it’s contained in the snap, but those can be discussed in the other topic.” Other related implications raised in this thread include the need to keep a time/date of last license modification, and whether by not notifying the user we expose them to being in violation of a non-accepted license.
