Re: call tomorrow, agenda

Sam Ellis


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.

From: Dennis Clark <dmclark@...>
Date: Thursday, 14 May 2015 20:12
To: J Lovejoy <opensource@...>
Cc: "spdx-legal@..." <spdx-legal@...>
Subject: Re: call tomorrow, agenda

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!
Dennis Clark
nexB Inc.

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

We will be discussing the Standard Header field.  Please review the
following info ahead of the call:
- for a description of the issue
- - 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
) 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)

Jilayne & Paul
SPDX Legal co-leads
Spdx-legal mailing list

-- 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

Join { to automatically receive all group messages.