No disagreement here. Here’s a quick idea: we could send a list of approved licenses to the store. The set would differ per distribution (default) and would be user controlled. This way we could make it very strict or totally open and everything in between with one mechanism.
This is from the SPDX standard, section 6.1. I think @sparkiegeek refers to the provision in section 6.2: “Purpose: Provide a copy of the actual text of the license reference extracted from the package or file that is associated with the License Identifier to aid in future analysis.” and the format is “Data Format: free form text field that may span multiple lines.”, delimited by <text></text>. The presence of those delimiters allows some level of validation which our SPDX validators should be able to handle; i.e. it’s not just random junk content.
I take this to mean the license field could store the verbatim text of the license, so there’s no need to fiddle with the LicenseRef thing.
Snapcraft could, for instance, in the absence of a license: field in the snapcraft.yaml, look for meta/LICENSE and send that as the content to be stored per this provision.
The fact we can include a full license text inside an arbitrary file doesn’t help us in any way. We can as well include the full text inside a file that has no further syntax on it.
It does help the store.
We won’t have to have a separate field for storing something else (the custom license) and figure out how we distinguish between custom licenses and SPDX etc.
How is it easier to dig into an XML file to figure out which licenses are there and whether you should use it or not, instead of reading a pure text file with some text in it?
Okay, here is a proposal.
To support custom licenses, we can extend the basic syntax of SPDX with expressions that look like:
license: unusual/<id>
Those licenses must be carried by the snap under meta/license/<id>.txt, in pure text format. The ID must match “[a-zA-Z0-9-.]+”.
Here is some of the rationale behind the proposal:
- That representation allows multiple licenses to be conveyed, using richer SPDX expressions.
- Something unusual means not used often. If it was usual, SPDX should cover with a first class identifier.
- Something unusual tends to be an eye-opener.
- Publishers will naturally prefer not to label their license as unusual, if possible.
- At the same time, “unusual” is not “bad” either. It simply means it must be looked into.
- It blurs the line between proprietary and unknown open source licenses. This reflects reality: if the license has custom unknown terms that weren’t vetoed by a recognized entity, it may be a trap to account it as free software.
- It gives a choice for proprietary software to express their terms. People often consider “proprietary” as simply “not free software”, but both free software and proprietary software have variations in their licensing terms.
Then, taking this chance, we’ve agreed to label missing licenses as:
license: unknown
Per the plan described in the respective topic, at some point in the near future snaps not defining a license will stop being accepted by the store. Before that happens we’ll wait some time after the feature is fully implemented so everybody has a chance to amend their metadata.
1 Like
I’ve replaced the colon in the expression with a slash, to avoid the slight visual glitch of having the two colons (license: and unusual:).
Suggestion, allow dot in the name of the license. I suspect many licenses will be versioned, say “foo-2.1” and this seems reasonable to support.
1 Like
Sounds reasonable. Updated the expression.
1 Like
@roadmr It looks like people are still seeing the license as “proprietary” when it is actually “unknown” (because we really don’t know). Can we fix that soonish?
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.
1 Like
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”?).
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.
1 Like
Hi,
“unset” is fine on our side. Thanks!
2 Likes
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 
A snap’s license: field can currently contain one of:
- “Proprietary”. This is currently allowed but is potentially vague since it doesn’t convey the actual terms of the license.
- 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. - “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
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.
2 Likes
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).