Support new SPDX licenses
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snap Store Server |
Confirmed
|
Medium
|
Unassigned |
Bug Description
I was trying to set the following custom SPDX expression for the chromium package:
(BSD-3-Clause AND MIT AND LGPL-2.0-only AND LGPL-2.1-only AND MS-PL
AND (MPL-1.1 OR GPL-2.0+ OR LGPL-2.1+) AND Apache-2.0)
And got an unhelpful "Error: Invalid syntax" message.
Celso provided some insight:
« I've dig a bit into the code and the problem seems to be the new '-only' license identifiers, which we do not support in the Store (FWIW, nor the '-later'). These changes were introduced in the SPDX spec >=3.0 and the code was not updated, See 'Deprecated Licenses' in https:/
And he suggested trying the following variant:
(BSD-3-Clause AND MIT AND LGPL-2.0 AND LGPL-2.1 AND MS-PL AND (MPL-1.1 OR GPL-2.0+ OR LGPL-2.1+) AND Apache-2.0)
which was accepted indeed.
So this is a request to support licenses in the SPDX spec >= 3.0.
Changed in snapstore: | |
status: | Triaged → In Progress |
assignee: | nobody → Daniel Manrique (roadmr) |
Changed in snapstore: | |
importance: | High → Medium |
SPDX licensing info spec is evolving, so this changed from the time we implemented this.
As it stands right now, I think we should replace our static lists LICENSES and LICENSE_EXCEPTIONS with the ones from here:
https:/ /github. com/spdx/ license- list-data/ tree/master/ json
There's a json file for licenses and another for exceptions, containing nice structured data, and they even have old licenses like LGPL-2.0 (which is equivalent to the new LGPL-2.0-only) and they are correctly marked as deprecated.
So: omething the data in those lists to produce LICENSES and LICENSE_EXCEPTIONS dicts that look like the ones we have now
- Find a way to sync copy of those two json files into our project tree (complication: this lives in github and we prefer not to pull files from random locations when building our project).
- json.somethings
- Profit
The license validation logic should be generic enough that a test for the given expression should not be needed. We can add it of course, but then it becomes a matter of chasing the spec around.