(responding via email so I can add spdx-legal
mailing list; not sure what mess this will make in Github, so
apologies in advance)
On 5/26/22 12:00 AM, Alexios Zavras
Quick couple of comments to @jlovejoy
Starting from the end, yes, the idea for these
private lists is that they cover licenses not in SPDX License
List. But I assume people might also want to use them for
licenses not currently in the SPDX License List.
that is my understanding too
On the publishing point (3), you are correct in
understanding the problem: given an identifier
there has to be an SPDX Document that uses the "other license
info detected" section to say "hey, for this
the corresponding text is this".
The two alternatives we have are:
a) people submit this document and we store it in a repo; or
b) people submit the location of this document and we
store (the location) in a repo.
There are obvious pros and cons to both approaches. But I think we
just need to be realistic that (a) may end up requiring some
"curation" of some kind if it's in an SPDX repo.
On that note, it appears that the current submission tool is really
In both cases, the SPDX project will not
be checking content like "someone using a license text that
matches a license already on the SPDX License List" or anything
like this. Yes, it would be "bad", but this can also happen
today: someone defining their own
while you are correct that this could happen today, I still think
that by not checking the content, we almost give greater license.
Look at Philippe's submission, for example, it links to the entire
database of licenses ScanCode has found, which presumably includes
all that are already on the SPDX License List. So already we are not
differentiating well b/w SPDX License List and the point of
LicenseRef (not on SPDX License List).
The SPDX project registers namespaces, not
what goes within them.
but what goes within them - which I take to mean the specific, full
LicenseRef with namespace and license, plus text of license has to
go somewhere (see above)
Related to checks during registration process (point
4), I believe everyone until now only talks about automated
checks, no human decision involved. Things like:
- checking whether the namespace is not already registered;
- checking whether the format of the namespace is correct;
- checking whether the URL is valid;
- checking whether the URL resolves to a document;
- checking whether the document is a syntactically correct
do we currently have all the tooling to do all these things? If not,
who is going to develop for the gaps?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message