|
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/SPDXTeamWe 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
|
|
|
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 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
|
|
|
Hi,
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!
Dennis Clark
nexB Inc.
-- 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
|
|
|
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
|
|
|
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
|
|
|
And just to confirm, does “OR” have the same 3 interpretation problem at the package level?
I think the use of sub references may be the best solution as trying to do a package level license expression with too much information seems to justify why
SPDX is a file-level mapping system.
Here’s another thought I had for real world practice. When a package takes in other sub packages, are they leaving the original licenses intact or converting
them to the project license (ignoring potentially compatibility issues)? I always assumed it’s the former but it’s not always clear to me if there’s an industry practice to fall back on.
Alan D. Tse
Copyright and Open Source Licensing Director
Western Digital Technologies, Inc.
3355 Michelson Dr., Suite 100, Irvine, CA 92612
T: 949-672-7759
F: 949-672-6604
toggle quoted message
Show quoted text
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...]
On Behalf Of J Lovejoy
Sent: Thursday, May 14, 2015 3:51 PM
To: Gary O'Neall
Cc: SPDX-legal
Subject: Re: call tomorrow, agenda
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!
On May 14, 2015, at 10:08 PM, Gary O'Neall <gary@...> wrote:
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.
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.
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
|
|
|
J Lovejoy wrote:
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 On Fri, May 15, 2015 at 12:57 AM, Alan Tse <Alan.Tse@...> wrote: And just to confirm, does "OR" have the same 3 interpretation problem at the
package level? IMHO yes. This is really left to the SPDX authors to provide the level of details they want to provide. More is better but not mandated. Here's another thought I had for real world practice. When a package takes
in other sub packages, are they leaving the original licenses intact or
converting them to the project license (ignoring potentially compatibility
issues)? I always assumed it's the former but it's not always clear to me
if there's an industry practice to fall back on. I have seen it done both ways. And quite often this is a combination of both. Taking Apache as an open source example, you see quite often an aggregated composite notice and license texts listing every licenses of non-Apache and Apache components embedded in a given package (Tomcat is a good example). You also see each individual original notice and licenses left as-is further down the tree. When translated to SPDX it would be likely redundant to repeat things ... But it is convenient to have things in one place summarized. In practice having a summary report produced from lower level could be a tool-provided solution IMHO. -- Cordially Philippe Ombredanne
|
|
|
