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

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com

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?

Thanks,
Jilayne

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

The word "registry" always gives me flashbacks. Shared
namespaces offer a unique kind of value, but always come
with carrying costs, scaling stepwise with popularity.

For example, the statutory process of copyright-based
takedown requests, the DMCA, doesn't cover trademark-based
claims. There is no special safe harbor from trademark
infringement for service providers, just generally
applicable rules of secondary liability.

How will you handle name disputes? How will you deal with
complaints (to SPDX/LF) about the identifiers being used by
private parties under their assigned namespaces?

Prior art: https://www.npmjs.com/policies/disputes

The npm public registry was originally one, flat namespace
for packages. `jquery` is a package name. In time, the
registry expanded to support scoped packages, with a
separate namespace for scopes, and another for each scope,
for packages within it. `@blueoak/list` is a scoped package
name. Some scopes exist on the public registry, and some
exist only in private registries.

--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933

Kyle:
On Wed, Mar 13, 2019 at 6:54 PM Kyle Mitchell <kyle@...> wrote:

How will you handle name disputes? How will you deal with
complaints (to SPDX/LF) about the identifiers being used by
private parties under their assigned namespaces?

Prior art: https://www.npmjs.com/policies/disputes

Thankyou: that's all valuable things to consider indeed and hard
earned from the leftpad issues.
Though I doubt mere licenses will ever be as successful as npm!
--
Cordially
Philippe Ombredanne

just a quick note on this: the leftpad issue had some very specific and extenuating circumstances that led to the mess it created which are really not applicable here. So while the legal team will consider our scenario, leftpad is not instructive.