Hi Jilayne:
On Sat, Mar 9, 2019 at 6:40 PM J Lovejoy <opensource@...> wrote:

Hi Philippe,
I’m a bit lost on what the goal of this is. Can you provide a bit more context.

I looked at a couple entries and noticed, for example, this one:
https://github.com/nexB/spdx-license-namespaces-registry/blob/master/scancode/licenseref-scancode-bsd-innosys.spdx

which then points to this: https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/bsd-innosys.yml

which notes that this is common in the Linux kernel.

Weren’t we going to add to the SPDX License List some of the other common licenses you all were finding in the kernel?

and https://github.com/nexB/spdx-license-namespaces-registry/pull/1

I sent it quickly during the legal team call on Thursday and sorry for
not providing much background then.
Here it is:

There has been a recent discussion initiated by Mark Atwood to create
stable, yet private SDPX identifiers.
And there is a similar need for ScanCode licenses too (See
https://github.com/nexB/scancode-toolkit/issues/532 and has been
requested by several users too.

Through the discussions, Kate and Gary suggested that we could reuse
LicenseRef and create an SPDX document for each license. The example
repository and example pull request that I linked above are to provide
an example of what this would look like if we were to have such a
system where there could be two level of registrations: simple
namespace and namespace + licenses ... all using LicenseRef
The benefit is that there would be no change to the spec required at
all and could be used today.
Now, the actual content of the repo I linked is based on a completely
random subset of non-SPDX-listed licenses that exists in ScanCode, so
their actual content is not relevant here.

I reckon that I still owe you to submit all the licenses that we found
in the kernel that are not yet in SPDX.... I am terribly late on that
part.

The two are not directly related... yet I could see the submission of
namespaced licenses as being a funnel for actual additions to the SPDX
list proper. Some may be worthy of that addition while some may not
make the cut.

--
Cordially
Philippe Ombredanne