Hi Jilayne, It would be helpful to provide actual source code examples of where the proposed operator would be applicable. This was done for each operator included in the first release of the license expression language which was very productive: https://wiki.spdx.org/view/FileNoticeExamples The examples would facilitate a healthy discussion while providing creditability to the final decision. We need to avoid using theoretical examples that have led to confusion in past discussions around how a proposed operator might be applied.
- Mark From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy Sent: Wednesday, October 11, 2017 10:14 PM To: SPDX-legal Subject: only/or later and the goals of SPDX Hi all, I was reviewing the notes from our last call and discussion as to the “only/or later/unclear operators and GNU licenses and still have not posted them as it was hard to take notes that make sense to read later when there is that much discussion! I’ll try to get some kind of summary up soon. More importantly, I had to take a step back and think about why this had become so challenging, where we are, and how to move forward. I found it helpful to recap some key principles as well as some things that have become clear to me based on the various discussion we’ve had on the topic: 1) Back to first principles! The mission of SPDX overall is: Develop and promote adoption of a specification to enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance. The purpose of the SPDX License List is to enable easy and efficient identification of such licenses and exceptions in an SPDX document (or elsewhere). Also - SPDX does not make legal interpretations. 2) FSF ask: I believe the main issue is that the FSF does not like that “GPL-2.0” as a license identifier currently means GPLv2-only and would prefer something more explicit. We agreed that to moving to the use of "GPL-2.0-only" (or similar). I don’t think anyone has an issue with this part as it provides clarity for identifying when the “this version only” option is exercised. 3) The challenges we encountered: We ran into the issue of when it is not clear if the licensor meant “this version only” or “or any later version” (e.g. the Github scenario, as I call it) and how to deal with that, especially where just the license text is found, but no license notices. We also did an analysis of other licenses with “or later” or like options. 4) The proposal: As a result of those discussions, we came up with the proposal to add an “only” operator, as described here: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Proposed_Solution:_add_only_operator and where the bare license identifier would signify the license text itself. I believe everyone was on board with this as the best option available. We went back to the drawing board after I got a message that the FSF was not satisfied with this proposal and consequently we came up with a different proposal that included an “ambiguous/?” operator. But this missed a key part of the core goals of SPDX: Implicit in those above goals is that the SPDX License List (including the license short identifiers and the license expression language) aim to provide a “language” to identify what we know, what we find - not what we don’t know or find. Having some kind of “ambiguous” operator (however we might decide to express that) is incongruent with this and the goals of SPDX. The original proposal as we came up with allows for an accurate description of what is found, including in the case of finding only the text of a license. So, I’d like to bring everyone attention back to the original proposal (see link above) and if there are any further concerns about it, now is the time to raise them. Meanwhile, Kate and I will follow-up with John and Richard at the FSF to better understand their concerns as well. Finally, my apologies for not being a stronger leader here in keeping our ship upright with the goals of SPDX; I hope people don’t feel that we have wasted (too much) time as a result. Thanks, Jilayne SPDX Legal Team co-lead opensou...@jilayne.com<mailto:opensou...@jilayne.com>
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
