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
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Sam Ellis
Sent: Thursday, May 14, 2015 12:44 PM
To: Dennis Clark; J Lovejoy
Cc: spdx-legal@...
Subject: Re: call tomorrow, agenda I thought this was a very thought provoking discussion too. 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! On Wed, May 13, 2015 at 7:38 AM, <opensource@...> wrote: 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
|
