In any case, anyone can suggest adding a license via this process:

http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be
-added We are largely "under-staffed" and "under-paid," so I would
encourage anyone who wants to see the list expanded to get involved.

To chime in on this, at openSUSE we have exactly the problem described
above - we'd like to adopt SPDX, but the license list does not provide
anywhere need the coverage that we need. What we've done in the interim
is create a spreadsheet on Google Docs where we add those licenses we
need to track with a SUSE- prefix. We'd hope to push these (or
substitutes for those) upstream to the SPDX license list.

Do you expect the SPDX License List to cover every license you find? Does
any list?
It would be great to align your list with the SPDX List (and make sure the
short identifiers are consistent, as the intent it to not changes those,
once they are published on the list) - please see the link above as to how
to add a license or join a legal call so we can figure out how best to
proceed.

In response to another idea on this list, I also think it makes sense to
use operators like + and - instead of basic strings for license
shortnames. It is certainly not consistent that the list contains e.g.
GPL-2.0-with-openssl-exception but not GPL-2.0+-with-openssl-exception.
Rather than coming up with n- strings for all those licenses out there,
surely using an operator would make more sense.

Just posted a response to the original response on this.

In summary, the SPDX format (well, for us as a linux distribution, the
SPDX shortnames) looks like it could help provide considerable
consistency, but (and this is a huge but) it is currently unusable for
linux distributions.

What makes it "unusable" - I'm not sure I completely understand.

- Jilayne