Thanks for the input all. I would agree with Sam and Gary’s assessment.
Just to clarify - the operator “AND” is defined in Appendix IV of the spec as "If required to simultaneously comply with two or more licenses, use the conjunctive binary "AND" operator to construct a new license expression , where both the left and right operands are a valid license expression values.”
This makes no determination as to whether such licenses are compatible. Such a determination (usually) involves some amount of legal interpretation, which is beyond the scope of SPDX.
The issue identified on the call today (and Mark will correct me if I’ve misstated) is that when AND is used at the file level (Section 4), it’s clear that both licenses apply to the given file. However, when AND is used at the package level (Section 3), it could mean, for example: 1) both licenses apply to some files 2) both licenses apply to all the files 3) one license applies to some files and the other license applies to other files
I don’t think any of this is incorrect, it is a function of a package being (usually) made up of multiple files. To determine the exact situation, one would then need to look at the file-level information. Adding an operator would help identify the situation of #3 particularly at the package level, but it may also not be necessary given the other options v2.0 offers.
In any case, we will certainly discuss more, I’m sure!
Cheers, Jilayne
On May 14, 2015, at 10:08 PM, Gary O'Neall < gary@...> wrote:
Greetings all, Sounds like I missed another good discussion - my apologies if I duplicate any discussion already made on the call. I just wanted to add my agreement to Sam's approach. One of the primary use cases behind the relationship_type (previously called usage_type) was to describe how a particular package (or sub-package) was being used, specifically to solve this problem. Questions like is it deployed? , is it statically linked? dynamically linked? can all be answered with the relationships and sub-packages. As Sam suggests, it seems like a solution to the problem could be creating sub-packages with the proper relationship. I fear that extending the license syntax would overlap with these other mechanisms and add more complexity not to mention possible confusion if the license syntax contradicts a sub-package relationship type. Gary I thought this was a very thought provoking discussion too. From my perspective (perhaps not having been so intimately involved in the definition of the license syntax) I had always considered AND to mean simply that multiple licenses apply to this work, and conveying nothing around license compatibility. License compatibility to me was always a separate dimension, very much depending on the specific use case and crucially on the interpretation of the licenses in question. To start describing license compatibility opens up a whole new field of work around what exactly is meant by that (linking, patents, commercial…) and who is making that claim; a very worthy endeavour indeed but not necessarily an easy problem to solve. Some of the discussion was around the desire to be able to describe the licenses for a sub-set of a package. For example, where a combined work is created from multiple libraries under different licenses, then we have license info for all the source files, plus license info for the entire package, and what is suggested is that it would be nice to describe license info at the library level. Whilst I have not explored this aspect of the SPDX 2.0 spec in great detail, it seemed to me that this is already possible through the ability to reference SPDX files from one another. In such a case, I wonder if it would be sufficient to represent, say, each library as a single package in an SPDX file, and then have a separate SPDX file that represents the combined work, providing references to the library SPDX files. This means of referencing SPDX files from one another allows for an unlimited amount of licensing hierarchy to be represented without needing any additional syntax. Furthermore, I wonder if the relationship information (CONTAINS, STATIC_LINK etc) can form the basis of capturing a good level of use case information that any person or tool interested in license compatibility can use this as a basis to determine an answer. Hi Legal Team, The topic that Mark Gisi brought up in the extra time we had in our meeting this morning, the use of "AND" in a license expression, made we wish we had more time to pursue it, and I hope that we make it a priority topic for our next legal group meeting. Although my initial reaction to the issue was that we already cover it quite well, the subsequent discussion made it very clear that we have a problem. "AND" should have a reasonably precise definition: 1. AND means that two or more licenses apply to a software object. A typical case is a file with various bits of code from multiple open source origins, where all of them still apply. Another one is an executable that links together code under different licenses. An implication, although not guaranteed, of the use of AND is that the licenses are compatible.
2. AND is sometimes, arguably incorrectly, used to identify an assortment of licenses that can be found in various subcomponents of a package, often referring to software objects that are deployed independently in actual practice. Using AND in this case is misleading, as Mark pointed out, since a package can contain components under different licenses that are actually not compatible, although not really a problem depending on how they are ultimately deployed. We need to upgrade our license expression syntax to address this, and should do it soon, because the current version does not encourage accuracy, and there could be upgrade issues in the future if we decide to correct the situation. Mark mentioned the possibility of using a comma (as currently done by Debian and others) or a semicolon. I'm fine with using a comma, although I am inclined to think that something more explanatory would be better: how about a "CONTAINS" license expression keyword? Example: CONTAINS (GPL-2.0, LGPL-2.1, GFDL-1.2). Whatever the solution, we really need to define a way to express the second case described above. Thanks to everyone for an interesting meeting! Hi all,
Just a reminder that we have our bi-weekly SPDX Legal Team call
tomorrow, Thursday, 13 May at 18:00 GMT (10:00AM PT, 11:00 MT, 12:00 CT,
1:00PM ET)
Call this number: (United States): +1-857-216-2871
User PIN: 38633
International: visit the URL at http://uberconference.com/SPDXTeam
We will be discussing the Standard Header field. Please review the
following info ahead of the call:
-
http://wiki.spdx.org/view/Legal_Team/Current_Projects_and_Issues#Standard_Headers
- for a description of the issue
- http://spdx.org/spdx-license-list/license-list-overview - see F at
bottom of page for the description of the Standard Header field
- you might also want to download the SPDX License List spreadsheet from
Git
(http://git.spdx.org/?p=license-list.git;a=tree;hb=64ec66a5460b9da2a836b2c28cac5e31535eedf9
) as then you can easily see all the licenses that have a Standard
Header at one time.
There are 54 licenses on the SPDX License List with a Standard Header.
There seems to be 3 categories of issues:
1) multiple or variable options (e.g., Apache-2.0 and APL-1.0. GFDL-*)
2) variable text w/in header (that is not copyright notice)- do we need
to created a template with markup? (see, e.g., CPAL-1.0, OCLC-2.0,
RPSL-1.0, MPL-*, etc.
3) presence or absence of "or later" in Standard Header making a
difference as to license identification (e.g., L/GPL)
Thanks,
Jilayne & Paul
SPDX Legal co-leads
_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
|
