Just a comment, which seems to resonate with some of what you are saying and expresses something I've been struggling with for a while:
As (mostly) an intentionally-not-watching-too-closely bystander wrt SPDX, for some time I've realized that SPDX means at least two different things. There is SPDX as contemplated by those who have been most closely and actively involved in its development. This anticipates the creation of SPDX-conformant files and among other things defines an important distinction between "declared" and "concluded" licenses -- while expecting the use of an identical license expression language for both, which, as an aside, I think is conceptually very confusing. The other SPDX is the use of something that *superficially* looks like SPDX-conformant license expressions to describe licensing in a way that is, I guess, outside the intended scope of SPDX. Examples of this nonconformant use of SPDX license expressions include developers annotating the licensing of their own software as well as distributors annotating the licensing of things they distribute. It's the second use of SPDX that in recent years I see catching on in the real world of developers and vendors and users, and not the first. The first use of SPDX continues after many years to be relegated to an extremely small set of enthusiasts, and I think to the rest of the world seems impractical for various reasons. In particular I would assert that these two uses of SPDX are fundamentally in conflict. >From what I can see, the SPDX group counts the second development as a set of >signs of "adoption of SPDX". For example, when Fedora began to consider >"switching to SPDX" for RPM spec file license tags (which still is nowhere >near actual adoption and implementation, for reasons relating to this post), I >think the SPDX group saw that as a potential major victory. But that is not >really accurate at all. What's happening is that SPDX license expressions have >been hijacked to a non-contemplated use which is of much greater interest to >the community than the original contemplated use for SPDX. These seem to correspond directly to your two stakeholders, except the second stakeholder in my mind also includes non-developers who are looking for a simple, standardized way to adequately describe the licensing of things they distribute. Maybe that's a third stakeholder which sees value in the LEL that is similar to what the second stakeholder sees. Now speaking specifically of things Red Hat is involved with, we have essentially zero interest in the first use of SPDX. Basically no one we encounter (outside of some individuals on this list) wants to create or see conformant SPDX files - not projects, not us as a company, not our customers. But we see a growing interest in the second use of SPDX from developers of Red Hat-maintained projects, in certain internal engineering efforts, and with a small number of customers, and an accompanying growing dissatisfaction with other conventions for describing licensing of software components. And one of the big challenges in this second use of SPDX is developing a set of conventions that hides sufficient complexity in license description, which I think is philosophically completely at odds with the basic direction of official SPDX. The conflict is such that I wonder whether there really shouldn't be a separate official effort around the second use of SPDX. Richard ----- Original Message ----- From: "Mark Gisi" <mark.g...@windriver.com> To: "SPDX-legal" <spdx-legal@lists.spdx.org> Sent: Wednesday, September 13, 2017 1:13:51 AM Subject: Package licensing part I - the approach - was Github example How to move forward: It appears we have not collectively agreed on what the problem is. I believe this is because there are at least two different stakeholders expressing two different sets of requirements for the License Expression Language (LEL). Stakeholder 1 (Traditional): Linux License Compliance people who use SPDX to deliver accurate and complete licensing information for Linux packages - many of which they did not author but may have patched. Accurate and complete licensing means from the package level down to each file level (using reasonable efforts). Stakeholder 2 (New): Developers who want to use license expressions i) in their code in place of the more tradition license notices and ii) for package level licensing designations. There are three steps I would like to suggest we achieve before developing updates to the LEL. 1) Describe the background on how the LEL was designed to date and the process used. The hope is that we can continue using the same process. 2) Define the requirements for the two different stakeholders and perhaps identify other stakeholders or correct the ones that are identified above. 3) Use the requirements to come up with a more precise problem description. Before we proceed - any feedback on the above? - Mark _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
