1. Topics
  2. CC NC/ND licenses and "general attributes of an 'open source' license"?

CC NC/ND licenses and "general attributes of an 'open source' license"?

Mike Linksvayer
 

https://github.com/spdx/license-list-XML/issues/689#issuecomment-423262092 (about a non-open-source BSD variant):

discussed on Sept 20 call: as per the license inclusion guidelines at https://spdx.org/spdx-license-list/license-list-overview : "...any license that is a candidate for inclusion on the SPDX License List must have the general attributes of an "open source" license."
So, we won't add this. But note that you can still adopt SPDX! (and we think it's great that you want to!) - in this case, I'd recommend using the LicenseRef option (see section 6 here: https://spdx.org/sites/cpstandard/files/pages/files/spdxversion2.1.pdf

I did not know license list candidates must have the general attributes of an "open source" license, but I'm glad to learn of the requirement.

I wonder how the CC NC and ND licenses made it through (I searched the list archives a bit and didn't come up with anything, probably due to my own lack of search savvy or persistence), and whether those identifiers should be deprecated?

Mostly this is idle curiosity on my part, please ignore if annoying. I can live with incongruity. :)

Mike
Kyle Mitchell
 

This interests me also.

It's my impression, from both the license-list explanation
and the actual list, that SPDX casts a broader net than
either OSI or FSF. Substantial compliance is sufficient.

I also note:

The SPDX Legal Team endeavors to explain its reasoning,
analysis, and conclusions with respect to a candidate
license as a means of developing precedent.

Compare and contrast a very recent conversation on OSI's
license-review, starting here:

http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-September/003535.html

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

Mike:
On Sat, Sep 29, 2018 at 9:45 PM Mike Linksvayer <ml@...> wrote:
I did not know license list candidates must have the general attributes of an "open source" license, but I'm glad to learn of the requirement.
I wonder how the CC NC and ND licenses made it through (I searched the list archives a bit and didn't come up with anything, probably due to my own lack of search savvy or persistence), and whether those identifiers should be deprecated?
Mostly this is idle curiosity on my part, please ignore if annoying. I can live with incongruity. :)
If I recall correctly: when we started we did add wholesale all the CC
licenses without much discrimination.
That's an incongruity that I can live with alright.

--
Cordially
Philippe Ombredanne
J Lovejoy
 

On Sep 30, 2018, at 8:18 AM, Philippe Ombredanne <pombredanne@...> wrote:

Mike:
On Sat, Sep 29, 2018 at 9:45 PM Mike Linksvayer <ml@...> wrote:
I did not know license list candidates must have the general attributes of an "open source" license, but I'm glad to learn of the requirement.
I wonder how the CC NC and ND licenses made it through (I searched the list archives a bit and didn't come up with anything, probably due to my own lack of search savvy or persistence), and whether those identifiers should be deprecated?
Mostly this is idle curiosity on my part, please ignore if annoying. I can live with incongruity. :)
If I recall correctly: when we started we did add wholesale all the CC
licenses without much discrimination.
That's an incongruity that I can live with alright.
Philippe is correct. We didn’t have written guidelines (aka, the “inclusion principles) for the first few iterations of the license list. If memory serves, all the CC licenses were recommended to be added and so we did. Remember, the SPDX License List began around 2009-2010 - that’s a long time ago now ;)

Later we realized other people might want to suggest licenses (“other people” meaning - other than the original people who came up with the original list) and we ought to have some guidelines. This probably also may have been precipitated by the question of whether to add other clearly non-open source licenses to the list - while the SPDX spec can be used with any software license, it was decided (multiple times) SPDX License List was to remain for open source licenses and use the OSD as a guiding principle, but without strict adherence (that’s what the OSI is for). And so here we are.

Mike - if you really wanted to know the when of it all, I suppose I could try to figure that out, but I’m not sure it matters at this point (nor am I sure it’s worth my time, versus dealing with the log of issues in the current queue!) If there is some historical background to this end we could add somewhere - either on the overview page or some other place, do let me know if you think that would be helpful.

Cheers,
Jilayne
J Lovejoy
 



On Sep 29, 2018, at 4:00 PM, Kyle Mitchell <kyle@...> wrote:

This interests me also.

It's my impression, from both the license-list explanation
and the actual list, that SPDX casts a broader net than
either OSI or FSF.  Substantial compliance is sufficient.

correct. SPDX’s goal is to create a common language with which to communicate information about (open source) software. The SPDX License List was born out of the recognition for efficiency in referring to some of the same licenses over and over. I still have a vague recollection of someone suggesting we needed “a list of licenses with short names/identifiers” and Kim Weins (my co-worker at the time) saying, “Jilayne, why don’t you put that together” (because that should be easy…) and here we are almost a decade later!   The value of a common and reliable way to refer to licenses has obviously a much broader use-case, which was pretty clear right away. And the reality of the open source licenses in the wild versus those that are submitted to and OSI-approved was part of the need/use-case for a list to begin with. So, yes a broader net.


I also note:

 The SPDX Legal Team endeavors to explain its reasoning,
 analysis, and conclusions with respect to a candidate
 license as a means of developing precedent.

Compare and contrast a very recent conversation on OSI's
license-review, starting here:

http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-September/003535.html

ah well, like many things in life, it’s hard to leave a good enough “paper trail” for those who come new to the table. But, that is the beauty of simply asking the question, as Mike has. It is such asking that has led us to record key things or improve upon documentation, etc. But there is always likely to be still some stories and history that lives on in our memories. :) 

Jilayne
1 - 5 of 5