Hi Richard,

Thanks for sending this! Kate and I were just talking about how we needed to create some kind of process to make sure that we add any new OSI approved licenses to the SPDX License List and coordinate on the short identifiers.

In any case, it would be great to use this opportunity to establish an outline of a process that will work for OSI and SPDX that we can use and reference going forward. I”m happy to put something up on a wiki page that we can all view and edit, if that’s helpful.

In the meantime, comments regarding the specific license in-line, and some other thoughts below:
SPDX Legal Team co-lead
opensource@...

On Nov 16, 2015, at 9:03 AM, Richard Fontana <fontana@...> wrote:

Greetings spdx-legal,

The OSI recently approved three licenses as Open Source:

1) eCos License version 2.0 (under the 'Legacy Approval' process)
Text of approved license contained within:
https://lists.opensource.org/pipermail/license-review/2014-August/000853.html

Note that the interesting part of this license is identical to
http://spdx.org/licenses/eCos-exception-2.0.html#licenseExceptionText

The short identifier is already defined for SPDX using the “with” operator and the exception identifier. It would be:

GPL-2.0+ WITH eCos-exception-2.0

Unless anyone thinks otherwise, I would think that license expression could be noted on the OSI site in the same way the other SPDX identifiers are??

This does raise for us the question as to whether we need to add an “OSI Approved” column to the exceptions list. To my knowledge, this is the only GPL exception that has been specifically approved by OSI, is that right?

2) Free Public License 1.0.0
Text of approved license contained within:
https://lists.opensource.org/pipermail/license-review/2015-August/001104.html

We have added as of v2.2 - http://spdx.org/licenses/0BSD.html - although it was submitted using a different name as suggested by the submitter (who I think said he authored the license… or at least seemed to know a lot about it’s origins and the suggested name, which we went with - see http://lists.spdx.org/pipermail/spdx-legal/2015-June/001443.html for that thread).

Would the OSI oppose the name we already went with??

3) OSET Foundation Public License version 2.1
We don't quite have a canonical license document here yet (the license
that was approved was a conceptually-typo-corrected version of a
redline document).

Great - we’ll need the license text - do you want to just let us know when you have the final version?

Anyway I would like to request the SPDX group consider creating
license names and identifiers for these. If this is a chicken-and-egg
problem (i.e. if the OSI needs to officially post these license texts
on its website before the SPDX group will consider such a request) let
me know.

I think the best order of things would be roughly what you have done: a heads up that the OSI is about to approve a new license before it’s posted, as this would give us a chance to come up with a full name and short identifier, which we are happy to have OSI input on. That way, when OSI posts it, you can include the SPDX short identifier (in brackets and in the URL, which I believe is what has been done). Since we are releasing a new license list on a quarterly basis and depending on how quick your web team is, it may be that the license appears on the OSI site first, vice versa, or it might happen that it’s around the same time frame on both sites - in any case, our on-going list of license to be added would reflect that a license will be added on the next release, so I don’t think any lag in either direction matters much. Let me know if you have other thoughts on that (or anyone else on the list here).


Thanks!
Jilayne