Possible to add Permissions, Limitations, and Conditions to XML data?

[stevespringett]

Would it be possible to add a list of permissions, limitations, and conditions, similar to what choosealicense.com does? GitHub uses these when presenting the license for a project and it's really useful.

The project has some of this data already available
https://github.com/github/choosealicense.com/tree/gh-pages/_licenses

It would be really useful to have this data in a centralized data format provided by SPDX.

[reversi-fun]

How do you(choosealicense.com) classify the license terms?
By what means do you identify the license name?

License names are not based on the similarity of the license terms.
For example,

• spdx/AFL-3.0(Academic Free License 3.0) and spdx/OSL-3.0(OSI/Open Software License 3.0) are almost similer license terms.
  (See attached figure)
• spdx/NPOSL-3.0(Non-Profit Open Software License 3.0) and OSI/UCL-1.0(Upstream Compatibility License v1.0) are not similer license terms.
  but OSI/UCL-1.0 not included in SPDX license lsit.
• spdx/zlib is called OSI/libpng, but
  It has different license terms from spdx/Libpng(libpng License) and spdx/libpng-2.0(PNG Reference Library version 2).

I suggested adding some license names to the spdx license list, which were found using the automatic classification tool to the similarity of license terms, but they were rejected.

Please see the graph of similarity of license terms classified by my tool.
Hopefully this figure helps to recognize the importance of not cluttering license name chaos.

https://github.com/reversi-fun/license_doc_similality1/blob/master/data/lic_graph.fdp.svg

[mlinksva]

How do you classify the license terms?

You read the licenses. Easy to skim results: https://choosealicense.com/appendix/

For choosealicense.com "you" is primarily me though I welcome corrections...and would not mind outsourcing the whole classification process if SPDX wanted to take it on!

I'm not at all certain that choosealicense.com classifications are at the optimal granularity though, mostly because I'm not sure what that would be if SPDX were to take on classification. FWIW a more granular approach for comparison: https://www.osadl.org/Single-View.111+M5e603e465cf.0.html

[mlinksva]

Another promising project is the Joinup Licensing Assistant mentioned by @P-E-SCHMITZ at https://lists.spdx.org/g/Spdx-legal/topic/32099229#2628 (more info there).

[reversi-fun]

@mlinksva ,I'm sorry.
I misunderstood that you (choosealicense.com) supplied a list of thousands of license names.
And I was expecting you (choosealicense.com or github) to map thousands of license-names and hundreds of spdxIDs.
I suggested, prior to license classification, to know a lot of license aliases thats license-text is same.

However, you(choosealicense.com) seem to be collecting only a few dozen license-names.
So, my previous question was a stupid question.

More productive request is there

[jlovejoy]

One of the core tenets of the SPDX project (overall, including the license list) is to stick to the facts and avoid legal interpretations. Trying to describe what the license allows or does not allow would be straying away from the "just the facts" tenets.

As a personal opinion, I don't think just describing what is allowed or not allowed for a particular license is all that helpful. How you are using the code/product/material that the license covers is a critical element in determining what conditions of the license apply to a given use case. You might find this format helpful: https://github.com/finos-osr/OSLC-handbook
:)

[stevespringett]

Thanks @jlovejoy Very useful info. The two major use-cases I envision for this data is:

• Using the license conditions, restrictions, etc to be used in the evaluation process when selecting libraries to be used in a piece of software
• Using the license conditions, restrictions, etc to identify potential cases of non-compliance when used in a piece of software

[jlovejoy]

in both of your use-cases, the use-case for how you will be using the s/w are a key element for the analysis (not to use the word "use" too many times in one sentence... and hopefully it still makes sense!)

[swinslow]

I agree with @jlovejoy -- from the SPDX project's perspective, the focus is on cataloguing specific license texts so that others can clearly communicate and understand which license is which.

SPDX intentionally does not seek to make legal interpretations. I think that any sort of categorizing of specific clauses of licenses into types of rights, restrictions, obligations, etc. is necessarily going to involve making that kind of judgment. Different people have different views and opinions on how best to do so.

It can certainly be a worthwhile and useful goal, and one that could be good for communities to undertake. As others noted in this thread, there are several existing communities and resources that are solving pieces of the problem you describe. At the SPDX level, though, I think the license list's purpose is just to curate and catalogue the license texts to enable others to better make those kinds of determinations.

(And hopefully, they will use SPDX identifiers when they do so, so that we can all know that we're talking about the same licenses!)

[stevespringett]

Thanks for the clarification on where the project stands on interpretations as well as the additional info for further research. I'm going to close this ticket