Re: "Scope" of licenses to be covered by SPDX

Ciaran Farrell

On Wed, 2012-06-27 at 20:05 +0000, Jilayne Lovejoy wrote:

In any case, anyone can suggest adding a license via this process:
-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?
No, of course not. There are simply too many licenses which almost
exactly correspond to existing, known licenses. It is the 'almost
exactly' that raises the issue. If all of these were to be included in a
list, the list would be very long indeed.

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

The left column is the SPDX shortname (with a proprietary SUSE- before
it if the license is not on the SPDX list).

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.
If we are referring only to the shortnames (typically, this - or a
combination of these - would be what would be included in the spec file)
then we would not get far if we limited ourselves only to packages with
licenses on the spdx list. Our current workaround, as stated above, is
to use a proprietary SUSE- prefix and to come up with a SPDX-like


- Jilayne

Join to automatically receive all group messages.