Support for custom license text


I don’t think SPDX expressions allow for an “unknown” identifier, so we’d have to add that, but it’s not different from “Proprietary” which is also not SPDX-expressable IIRC. Sure, let’s talk about this and decide how it would look!


@roadmr We just had a different meeting and we quickly mentioned this issue (we still need to talk) and we agreed to change the designation to “unspecified” instead of “unknown”, as it more clearly indicates what the case is. We’ll need to change that in snapd as well.

For the same reason, that’s not in SPDX indeed, in that this is lack of information. We shouldn’t accept that as an actual expression.


to be extra-super-clear, when the license is unset, in the store we currently say “Proprietary”, and in snapd we say “unknown”, but in both cases we should say “unspecified” (or “Unspecified”?).

Blender snap

Yes, and I would say “unspecified”, lowercase, so it looks more clearly like a token instead of an actual license (there are very weird license names :).


Actually, “unset” sounds a lot better than “unspecified” and seems to have the same meaning. Let me counter check that with Mark, as he proposed the new term.


And we have agreement between us at least (Mark, myself): “unset” it is. This is also a good pattern for us to use in similar cases, and in fact we already have code in snapd proper that uses it exactly with the same meaning (revisions). So, nice pattern to keep.

@roadmr @chipaca Please let me know if that works on your ends as well.



“unset” is fine on our side. Thanks!


Hi folks! The title of this thread is “Support for custom license text”. I would like to restart/refocus the discussion on that topic only so we can come to an agreement or at least lay the existing ideas on the table so we can decide on one.

I’d like to avoid discussing the following aspects, which have their own threads as noted below:

  • To get a stray topic out of the way, incoming snaps now have their license set to “unset”; no more “Proprietary is the default”.

  • A new topic was started to ensure we’re all in agreement as to where the license is represented in snap.yaml/snapcraft.yaml.

  • Another topic talks about which license will be presented to the user when querying the store.

  • 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.

With that in mind, this thread should be very narrow in scope and hopefully we can solve this :slight_smile:

A snap’s license: field can currently contain one of:

  1. “Proprietary”. This is currently allowed but is potentially vague since it doesn’t convey the actual terms of the license.
  2. An SPDX expression. This is also currently allowed, though in its existing form it can only represent well-known open-source and free licenses. I think none of the SPDX parsers we have understands the LicenseRef-<id> syntax or the “full license text” provisions of SPDX.
  3. “Other Open Source”, also currently allowed.

I think we wanted two things:

a. A way to represent custom licenses, be they proprietary or free/open-source. Obviously a license can meet the FOSS criteria and not be covered by SPDX.
b. A way to identify whether a license is free. Per the above, an SPDX-representable license is always “free”, while for custom licenses we would need to rely on something else, ideally provided by the publisher.

For a, as we discussed earlier, a shortcoming of SPDX is that it can’t express a custom license in a compact and satisfactory way. @sparkiegeek and I argued that SPDX has provisions to both provide an ID to reference custom license text “somewhere” and include a full copy of the license text as part of the SPDX expression. Gustavo replied that the first option is ambiguous (particularly LicenseRef-<id> doesn’t make sense outside the context of a full SPDX XML file because it references nothing.) and the second is unwieldy and results in enormous expressions which will be horrible to work with in snap.yaml.

Gustavo then proposed a custom SPDX identifier unusual/<id> which would point to a file under meta/license/<id>.txt in the snap. @sparkiegeek thought that would complicate matters for the store since that license text may need to be stored there somewhere, and the SPDX parser needs to be extended to accommodate that, as well as possibly needing to revamp the store’s processing of snap uploads to identify, extract and store license text from files.

One thing that’s not clear to me is whether that unusual/<id> identifier would be part of the SPDX expression. Example:

LGPL-2.1 AND unusual/my-nice-license

Or whether it’s “either an SPDX expression or an unusual license identifier”. The latter could potentially still cover a case like the above because my-nice-license.txt can say “this portion of the software is covered by LGPL, and this other is covered by this license text blah blah”.

So I think those are the two main choices we have.

In principle I’d like to leverage the standard we have chosen (SPDX) if it can accommodate this use case, rather than inventing extensions. If SPDX is complex or unwieldy maybe we can provide a simplified syntax for the publisher to use in snapcraft.yaml and have snapcraft process that into a longer license expression or XML or … something. This should be predicated on the SPDX tools we have being able to do most of the work for us. That said, I’ll defer to others who have read and understood the SPDX specification and can give a more informed assessment on this. If it’s a horror to do, then perhaps a simpler extension is the way to go.

Next, it’d be interesting for the publisher to be able to indicate whether their license is free or not. A naive idea is a “license-free:” boolean field next to “license” in snapcraft.yaml, but that’s horrible. Better ideas are welcome :slight_smile:

Down the line, I think with the combination of a richer license: field and a way of denoting freeness of the license, the “Proprietary” and “Other Open Source” license options can go away (we can plan for that on another thread!).

  • Daniel

Edit: I added some new rationale about why LicenseRef-<id> is not ideal for this case, based on part of the thread’s discussion. Thanks to Gustavo for pointing that out.

Updates to snap licenses
Snap license metadata

Is there a way to specify that an author refuses to accept copyright law and instead releases the code into public domain? Specifying it as a license doesn’t really sends a message about relation to copyright.


You can put your political statement the description of the application and leave the license field “unset”. There’s no hard and fast requirement to explicitly specify a license. We recommend it, because it makes it clear for prospective users what to expect, but it’s up to the developer to fill that in (or not).


you could also use the Unlicense.


Note that a plan to disallow this (i.e. enforce a license to always be set) has been floated, so this solution may or may not work long-term.

The Unlicense as suggested by @chipaca looks like a good compromise.

  • Daniel


The problem with license field is that it is the thing from copyright law, and once you’re in, it is really hard to escape it. Unlicense, CC0, WTFPL - are the tools that are designed to do that, but they don’t work in many jurisdictions. SPDX doesn’t include public domain for that reason, and snapcraft says that only SPDX specifiers are supported.

When public domain is treated as a political statement, it becomes impossible to see how many people are supporting alternative source code sharing consensus.


You don’t get to “opt in” to the law. If you don’t specify a license that would grant more rights to users, the default position is that it’s all-rights-reserved.

IANAL etc etc etc, but if you really want to do something about it, leaving this thing blank is probably your worst option.