Thanks for the update, Elmar.
toggle quoted messageShow quoted text
So, the “old” versions that you’ve created along the way for the OSI approval process are not being used in the wild, is that right? It seems like the versioning is more about the different updates you’ve made in response to the OSI process?
On Jan 14, 2019, at 3:14 AM, Elmar Stellnberger <estellnb@...> wrote:
Dear J. Lovejoy,
On 11.01.19 23:31, J Lovejoy wrote:
Hi Elmar,Yes that should work since newer versions can always be auto-applied. Concerning version 1.3 it was not used in practice though I have forgotten to mark it as Draft until the OSI board would approve it (Version 1.3 is at least not linked on my homepage). I am planning to realease an update to 1.3 called 1.4 which overcomes a few problems of 1.3 (shipping patches proactively, incorporating a work under C-FSL into a bigger one).
It appears that you are still in the OSI review/approval process and as a result the license has evolved a bit. We are tracking it for submission to SPDX here - https://github.com/spdx/license-list-XML/issues/692 - but as the license seems to be evolving, we are inclined to wait for your OSI process result and then review it for SPDX at that point.
Can you confirm that the versioning (1.1 v. current 1.3) is merely iterations generated via the OSI process, and are not different versions being used in the wild? It’d be good to know that for future review, as SPDX usually takes the view point of adding all versions of a license, if it has older versions, for completeness.
If/when the license looks like it’s going to be approved by the OSI, we’ll want to ensure that an SPDX identifier is determined by the SPDX team (and you) and that the OSI is informed as to that decision. So there’s a bit of coordinating on that aspect we’ll need to keep in mind.
Thanks and feel free to post any updates to the issue in Github.
SPDX legal team