project_license and SPDX

[hsitter]

I have a bit of a question regarding the SPDX usage for appstream.

The appstream documentation says about project_license:

It should be a string in SPDX format. Licenses may be combined using and and or logic.

That seems a bit ambiguous to me. "SPDX format" would be the SPDX license expression format as the identifiers themselves aren't actually following a specified rule from what I can see. That does however not seem to be what is actually expected by appstream here.

A SPDX license expression would be this: (LGPL­2.1+ AND (GPL­2.0+ WITH Bison­exception­2.2)) OR GPL­3.0

The example in the appstream documentation goes on to contract this with LGPL-3.0+ and GPL-3.0+

Which is an expression containing SPDX license identifiers but not a valid SPDX expression (SPDX expression requires upcased AND/OR), so I am guessing the intention is a custom combination syntax with SPDX license identifiers.

If so, I think the documentation ought to say

It should be a SPDX license identifier string. Licenses may be combined using and and or logic."

That being said, however. I would like to make a case that project_license should, in fact, be changed to SPDX expression syntax. The current format with and/or is deficient in that it doesn't define how to combine an exception with a license. i.e. you cannot define GPL­2.0+ WITH Bison­exception­2.2.
Now, one could add that but then you might as well just go implement the expression syntax as the only other difference is bracketing, which isn't too exciting but still has its uses.

Deferring to the SPDX license expression syntax would allow passing SPDX license information verbatim from other sources. Such as auto-generating appstream data from other metadata sources (which is what we do, for example, for Plasma applets as they already have different metadata). In addition to that it would fully standardize the license expressions. So, a common SPDX parser implementation could be used to parse appstream license info etc.

[ximion]

This really should say SPDX expression, because that's what we support. The parser is AFAIR reading both upper- and lowercase and/or, but that's an implementation thing that shouldn't be in the spec.

So yeah, the text should be clarified there.

[hsitter]

Awesome.

I've read a bit more and as it turns out one needs to support both upper case and lower case for SPDX anyway. Which seems to be the case from a quick look at as-spdx.c. So it's just a matter of tweaking the docs then, I'll prep a commit.