APSL license version prior to 2.0 inconsistent OSI approved information

[goneall]

APSL-1.0, APSL-1.1 and APSL-1.2 are marked as OSI approved, however, the OSI website only lists APSL-2.0 on their website.

[goneall]

I can create a PR to fix if there is agreement the OSI Approved attribute should be set to false for these licenses.

[swinslow]

Interesting... I don't know the history on this, but from a web search I came across a related discussion from 2012, it looks like:

https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2012-May/017777.html

That appears to reference (but not clearly link to) archival evidence that at least -1.2 was OSI-approved at some point in time.

I haven't had a chance to read that thread deeper, but it at least appears to suggest that some of the APSL pre-2.0 versions were approved...

[goneall]

Thanks @swinslow - very useful history!

My reading of the thread is that they are very likely OSI approved, so we probably should not change the SPDX license list OSI approved for any of these licenses.

Ideally, OSI would make the OSI approved status for these earlier versions of APSL clear on their website, but based on OpenSourceOrg/licenses#66 discussions, this may not happen in the near term.

I'm thinking we keep this open to track the inconsistency. Once OSI has the licenses Github repo fully up to date with their current website, we can revisit.

[pchestek]

If the license is under "superseded," it was previously approved but there is a newer version of the license. But the "superseded" version remains approved, to the extent it is still used by anyone.

[jlovejoy]

(getting back to this a bit late...) thanks @pchestek
@goneall - this question was raised way for ASPL-1.0 and ASPL-1.1 way back when SPDX was ensuring that all licenses ever approved by OSI were included on the SPDX License List (was a lengthy process...) the thread on ASPL can be see herehttps://lists.spdx.org/g/Spdx-legal/topic/22080295#484

I think we can close this as resolved back then.

[goneall]

@jlovejoy Let's leave this open for now - there is still an inconsistency between the OSI website, OSI GitHub metadata and the SPDX license list.

Although the description makes sense, anyone trying to automate sync'ing the metadata between OSI and SPDX will find it a challenge to interpret the superseded in a reliable manner.

I'm tempted to give up on the challenge of automating this - the manual approach seems to work OK and it is very slow and challenging to get the OSI website, SPDX license list and OSI Github sites in sync.

Could we queue this up for an SPDX legal call to see if there is value in the effort?

[jlovejoy]

marking with (new) OSI-related label to note dependency