Re: explanation for ensuring no duplicate identifiers

J Lovejoy

HI all,

I’ve updated this, including one of Trevor’s additional edit below for the first bullet (the other suggestion you had was the same as I had, but my strikethrough seemed to have gotten lost in your email!)

I also added the field for the FSF Free/Libre with a description of the intent there. Considering that that field is not entirely complete, I almost put a note as such (“under construction” or the like) but then figured I’d have to remember to remove it later, so I did not add that.


SPDX Legal Team co-lead

On Jul 5, 2018, at 11:41 PM, W. Trevor King <wking@...> wrote:

On Thu, Jul 05, 2018 at 06:16:56PM -0600, J Lovejoy wrote:
Back to the Short Identifier additions are: characters, given the
various feedback on this thread, here is an updated suggestion.

I'm fine with this proposal going out as you have it, but I've put a
few suggestions inline in case you want to pick them up.

• Short identifier to be used to identify a license or exception
 match to licenses or exceptions contained on the SPDX License List
 in the context of an SPDX file, in source file, or elsewhere

This matches what's currently live [1], but it could probably be
tightened up to something like:

 Short identifiers identify licenses and exceptions from the SPDX
 License List in the context of an SPDX file, a source file, or

• Short identifiers have no spaces in them consist of ASCII letters
 (A-Za-z), digits (0-9), full stops (.) and hyphen or minus signs

I think it is sufficient to list the allowed characters:

 Short identifiers consist of ASCII letters (A-Za-z), digits (0-9),
 full stops (.), and hyphen/minus signs (-).

And then, if you want to draw attention to spaces in particular, add a
second sentence to that list item:

 They do not contain spaces or other characters except those
 mentioned in the previous sentence.

• Where applicable, the abbreviation will be followed by a dash and
 then the version number, in X.Y format

This line is currently live [1], but do we need to keep it?  Not all
of our versions are X.Y.  For example, W3C-19980720 [2] is in YYYYMMDD
format.  Perhaps that falls under "where applicable", but why call out
one specific versioning approach?

• Short identifiers must not be duplicative and must be different
 from all pre-existing short identifiers.
• While short identifiers can be treated as case insensitive, it is
 encouraged to use the canonical short identifier casing.

These cover the two points I think need to get covered.  So while I
prefer my previously-suggested wording [3], I'm fine with this


[3]: Subject: Re: explanation for ensuring no duplicate identifiers
    Date: Mon, 18 Jun 2018 11:18:34 -0700
    Message-ID: <20180618181834.GD25466@valgrind>

This email may be signed or encrypted with GnuPG (
For more information, see

Join { to automatically receive all group messages.