Revisiting the SPDX license representation syntax
|
Mark Gisi
In the last SPDX Legal meeting we discussed whether the current SPDX license representation syntax is sufficient to represent the licensing terms of most files (e.g., source, library and binary programs). For example, is the combination of the SPDX license list + current binary operands (AND and OR) sufficient to describe the licensing of most programs derived from multiple source and library files, where each is potentially under a different license.
We decided to hold a break out session dedicated to discussing this topic in greater depth. Initially special consideration will be given to representing files that have licenses with special exceptions and programs derived from files licensed under multiple different licenses. Keep in mind, given the high degree to which sharing occurs in the community, composite licensing has become the norm rather than the expectation. This is a good thing – we just need to make sure SPDX can accommodate it.
I will be organizing the break session. If you are interested in participating send me i) your email, ii) a brief description of your interest, and iii) days/times that work best for you. I will try to select a meeting time to accommodate the most participants.
Best, - Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-455 |
|
|
|
RUFFIN, MICHEL (MICHEL) <michel.ruffin@...>
Mark,
I think that we should go further (moving from syntax to semantic). We should decomposed FOSS license in terms of right and obligations (Blackduck call that attributes in its protex tool).
We have a system in Alcatel-Lucent to do that since years for instance we have attributes to say that there is need to - have or not acknowledgement of authors in our documentation - have run-time acknowledgement - have source code available or not - have the obligation of copyright indemnification in case of IP issues - have the necessity to propagate the licences - ….
This decomposition is very usefull to explain licenses rights and obligations to our R&D teams (with our decomposition we cover most of the major OSI certified licenses) . It is not perfect, and need some more work.
Blackduck is doing a more formal decomposition of licenses for instance there is attribute is “does the license request that the source code MUST be available” or “does the license request that the source code MAY be available”; With that system they are allowed to define if two FOSS licenses are compatible or not. But their decomposition is not perfect because it can create conflict that do not really exists.
The creative commons licenses are doing such kind of decomposition also so you do not pick up a license but a set of rights and obligations and create your license.
I think there is a ground here to raise a standard.
Michel Michel.Ruffin@..., PhD De : spdx-legal-bounces@...
[mailto:spdx-legal-bounces@...] De la part de Gisi, Mark
In the last SPDX Legal meeting we discussed whether the current SPDX license representation syntax is sufficient to represent the licensing terms of most files (e.g., source, library and binary programs). For example, is the combination of the SPDX license list + current binary operands (AND and OR) sufficient to describe the licensing of most programs derived from multiple source and library files, where each is potentially under a different license.
We decided to hold a break out session dedicated to discussing this topic in greater depth. Initially special consideration will be given to representing files that have licenses with special exceptions and programs derived from files licensed under multiple different licenses. Keep in mind, given the high degree to which sharing occurs in the community, composite licensing has become the norm rather than the expectation. This is a good thing – we just need to make sure SPDX can accommodate it.
I will be organizing the break session. If you are interested in participating send me i) your email, ii) a brief description of your interest, and iii) days/times that work best for you. I will try to select a meeting time to accommodate the most participants.
Best, - Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-455 |
|
|
|
Tom Incorvia
Hi Michael,
I am an early contributor to SPDX, but have been quiet lately.
I would recommend that we delay moving into rights and obligations until our foundation in the descriptions is more solid.
I did some looking into this in the early days, and found approximately 70 discrete license obligations / grants / conditions that potentially differed based on 40 different use cases (e.g., binary / source, modified / unmodified, stand-alone / combined, in-line/static-link/dynamic-link/command-line, distributed/hosted, etc.).
There were 2,680 combinations per license.
Despite the large number of combinations, many of the conditions required interpretation (for instance, many licenses are silent on some of the conditions; sometimes silence means something (implicit warranties, etc.), sometimes it means nothing.
In the end, the SPDX team at the time decided to stick with descriptions and keep away from what could be construed to be interpretations.
Our progress has been slow and tedious even on the description side.
I am thinking that we get the description phase more solid before expanding to this new (and valuable level).
Thanks,
Tom
Tom Incorvia Direct: (512) 340-1336 M: (215) 500 8838 [**NEW** as of Oct 2013] From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...]
On Behalf Of RUFFIN, MICHEL (MICHEL)
Sent: Wednesday, October 23, 2013 9:48 AM To: Gisi, Mark; SPDX-legal; spdx-tech@... Subject: RE: Revisiting the SPDX license representation syntax
Mark,
I think that we should go further (moving from syntax to semantic). We should decomposed FOSS license in terms of right and obligations (Blackduck call that attributes in its protex tool).
We have a system in Alcatel-Lucent to do that since years for instance we have attributes to say that there is need to - have or not acknowledgement of authors in our documentation - have run-time acknowledgement - have source code available or not - have the obligation of copyright indemnification in case of IP issues - have the necessity to propagate the licences - ….
This decomposition is very usefull to explain licenses rights and obligations to our R&D teams (with our decomposition we cover most of the major OSI certified licenses) . It is not perfect, and need some more work.
Blackduck is doing a more formal decomposition of licenses for instance there is attribute is “does the license request that the source code MUST be available” or “does the license request that the source code MAY be available”; With that system they are allowed to define if two FOSS licenses are compatible or not. But their decomposition is not perfect because it can create conflict that do not really exists.
The creative commons licenses are doing such kind of decomposition also so you do not pick up a license but a set of rights and obligations and create your license.
I think there is a ground here to raise a standard.
Michel Michel.Ruffin@..., PhD De :
spdx-legal-bounces@... [mailto:spdx-legal-bounces@...]
De la part de Gisi, Mark
In the last SPDX Legal meeting we discussed whether the current SPDX license representation syntax is sufficient to represent the licensing terms of most files (e.g., source, library and binary programs). For example, is the combination of the SPDX license list + current binary operands (AND and OR) sufficient to describe the licensing of most programs derived from multiple source and library files, where each is potentially under a different license.
We decided to hold a break out session dedicated to discussing this topic in greater depth. Initially special consideration will be given to representing files that have licenses with special exceptions and programs derived from files licensed under multiple different licenses. Keep in mind, given the high degree to which sharing occurs in the community, composite licensing has become the norm rather than the expectation. This is a good thing – we just need to make sure SPDX can accommodate it.
I will be organizing the break session. If you are interested in participating send me i) your email, ii) a brief description of your interest, and iii) days/times that work best for you. I will try to select a meeting time to accommodate the most participants.
Best, - Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-455
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ |
|
|
|
Mark Gisi
Hi Michel,
Thanks for sharing your experiences. I agree these are worthy topics. I have had a number of similar conversations with Wind River customers through the years. Although these topics can be discussed in parallel, I agree with Tom in that we can’t move much faster (or further) until we repair the foundation from which these concepts are built upon. Before we can begin discussing common agreed upon obligations (semantics), we need to first accurately represent the licensing terms of source files, libraries and programs (syntactically). For example, consider program X, having the following Boolean license expression:
(GPL-2.0 AND BSD-3-Clause)
Program X was built (derived) by integrating a GPL-2.0 licensed file with a BSD-3-Clause licensed file. Some organizations may interpret this one way (e.g., only GPL-2.0 terms matters); while other organizations may interpret it another way (e.g., both GPL-2.0 and BSD-3-Clause terms need to be considered). The elegance of the Boolean expression approach is it allows one to represent the licensing terms based on the files it was derived from, *independent* of a given organization’s interpretation (i.e., semantics). The irony of the situation is - I could work for one organization, which would require me to make one interpretation, and then a year later I go work for another organization, which would require me to make a different interpretation for the same expression.
One could argue – it is important to come together as a community to reach common interpretations of license obligations. My response would be – yes, I agree but let’s first start with a generally accepted “neutral” syntax as the foundation of that discussion. I do feel a sense of urgency to flush out a correct syntax so that we can move on to some of the topics you have highlighted. I do believe SPDX’s approach is close, it may just require a few adjustments and a formal write up. This will ultimately be determined by the collective thinking of the working group. I hope you can join the discussion.
Thanks, - Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-4552
From: Tom Incorvia [mailto:tom.incorvia@...]
Sent: Wednesday, October 23, 2013 8:13 AM To: RUFFIN, MICHEL (MICHEL); Gisi, Mark; SPDX-legal; spdx-tech@... Subject: RE: Revisiting the SPDX license representation syntax
Hi Michael,
I am an early contributor to SPDX, but have been quiet lately.
I would recommend that we delay moving into rights and obligations until our foundation in the descriptions is more solid.
I did some looking into this in the early days, and found approximately 70 discrete license obligations / grants / conditions that potentially differed based on 40 different use cases (e.g., binary / source, modified / unmodified, stand-alone / combined, in-line/static-link/dynamic-link/command-line, distributed/hosted, etc.).
There were 2,680 combinations per license.
Despite the large number of combinations, many of the conditions required interpretation (for instance, many licenses are silent on some of the conditions; sometimes silence means something (implicit warranties, etc.), sometimes it means nothing.
In the end, the SPDX team at the time decided to stick with descriptions and keep away from what could be construed to be interpretations.
Our progress has been slow and tedious even on the description side.
I am thinking that we get the description phase more solid before expanding to this new (and valuable level).
Thanks,
Tom
Tom Incorvia Direct: (512) 340-1336 M: (215) 500 8838 [**NEW** as of Oct 2013] From:
spdx-legal-bounces@... [mailto:spdx-legal-bounces@...]
On Behalf Of RUFFIN, MICHEL (MICHEL)
Mark,
I think that we should go further (moving from syntax to semantic). We should decomposed FOSS license in terms of right and obligations (Blackduck call that attributes in its protex tool).
We have a system in Alcatel-Lucent to do that since years for instance we have attributes to say that there is need to - have or not acknowledgement of authors in our documentation - have run-time acknowledgement - have source code available or not - have the obligation of copyright indemnification in case of IP issues - have the necessity to propagate the licences - ….
This decomposition is very usefull to explain licenses rights and obligations to our R&D teams (with our decomposition we cover most of the major OSI certified licenses) . It is not perfect, and need some more work.
Blackduck is doing a more formal decomposition of licenses for instance there is attribute is “does the license request that the source code MUST be available” or “does the license request that the source code MAY be available”; With that system they are allowed to define if two FOSS licenses are compatible or not. But their decomposition is not perfect because it can create conflict that do not really exists.
The creative commons licenses are doing such kind of decomposition also so you do not pick up a license but a set of rights and obligations and create your license.
I think there is a ground here to raise a standard.
Michel Michel.Ruffin@..., PhD De :
spdx-legal-bounces@... [mailto:spdx-legal-bounces@...]
De la part de Gisi, Mark
In the last SPDX Legal meeting we discussed whether the current SPDX license representation syntax is sufficient to represent the licensing terms of most files (e.g., source, library and binary programs). For example, is the combination of the SPDX license list + current binary operands (AND and OR) sufficient to describe the licensing of most programs derived from multiple source and library files, where each is potentially under a different license.
We decided to hold a break out session dedicated to discussing this topic in greater depth. Initially special consideration will be given to representing files that have licenses with special exceptions and programs derived from files licensed under multiple different licenses. Keep in mind, given the high degree to which sharing occurs in the community, composite licensing has become the norm rather than the expectation. This is a good thing – we just need to make sure SPDX can accommodate it.
I will be organizing the break session. If you are interested in participating send me i) your email, ii) a brief description of your interest, and iii) days/times that work best for you. I will try to select a meeting time to accommodate the most participants.
Best, - Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-455
|
|
|
|
Philippe Ombredanne
On Tue, Oct 22, 2013 at 6:01 PM, Gisi, Mark <Mark.Gisi@...> wrote:
In the last SPDX Legal meeting we discussed whether the current SPDX licenseLet me bring my 2 cents to the discussion. A while back I wrote down this little language to compose licenses. The point was to : - make this easy enough for humans and machines to read, write and understand. - have a terse yet expressive way to represent actual licensing in one statement, eventually expressing the complex licenses composition of whole packages. - support factual licenses statements as well as interpretations such as selection from a choice, the fact that some license may apply that were not asserted originally, etc. PS: For most of it there is nothing new there, SPDX does it alright. PPS: Some of this may not mesh entirely well with the current SPDX licenses list state (such as expressing "or later versions" generically or how we deal with exceptions). Here are the basic examples updated to SPDX: * lgpl-2.0 : a single license applies. * apache-2.0 lgpl-2.0 : All the licenses listed apply, space-separated list. (AND is implied as the default operator, CONJUNCTION) * mit & lgpl-2.0 : All licenses listed apply, ampersand-separated list. (explicit AND, CONJUNCTION) * mit | gpl-2.0 : a license choice: either one of the licenses can apply, the choice does not have to be made and can be passed downstream. (CHOICE, OR) * mit ? gpl-2.0 : a disjunctive license choice of mit or gpl-2.0. A choice must be made. (CHOICE, EXCLUSIVE OR, DISJUNCTION) * gpl-2.0 ^ classpath : a license exception or supplemental terms: here, the classpath exception to the gpl-2.0. nb: here we have a slight change with the SPDX license list, where the exception would be just the exception and not the whole gpl-and-classpath taken together as one license.(EXTRA TERMS, EXCEPTION) * gpl-1.0 + : this license version or a later version applies: i.e. gpl-1.0 or later. nb: here the plus sign is not part of the license id, but part of the syntax which is also different from SPDX (OR LATER version) * (apache-1.1 mit gpl-2.0) : a grouping of licenses. This is useful for explicit grouping in complex statements, rather than relying only on eventual operators precedence (GROUP) * ftl [ftl ? gpl-2.0]: a license selection expressed with brackets: here I picked ftl from the disjunctive choice of ftl or gpl. (SELECTION using brackets) * apache-2.0 {mit bsd-3-clause lgpl-3.0} : I think that the primary license is overall apache-2.0 and that other secondary license apply. This is handy to express composite licenses at a package level. (PRIMARY and SECONDARY using braces) * gpl-2.0 < mit: I think that the license that applies here is gpl-2.0, despite being asserted originally as MIT-licensed (possibly because of linking, dependencies, code reuse or else). (INTERPRETATION, INTERACTION) * gpl-2.0 ! commercial : I think that the gpl applies and that the commercial the license id CANNOT apply. Negations are usually aberrations with conflicting terms but I see vendors releasing dual GPL/proprietary making this type of interpretation in supplemental terms often enough. Some proprietary licenses state the opposite explicitly too: this is commercial and cannot be gpl. This rarely of a practical use but may be needed for completeness (NOT, NEGATION) And more complex examples: * apache-1.1 ( mit | gpl-2.0) : apache AND mit or gpl using a grouping of licenses choice. * mpl-1.1 [gpl-2.0 | lgpl-2.1 | mpl-1.1 ]: I picked mpl-1.1 from the choice of mpl, lgpl or gpl. * gpl-2.0 < (mpl-1.1 [gpl-2.0 ? lgpl-2.1 ? mpl-1.1 ]): I think gpl-2.0 applies here despite a selection of mpl-1.1 from a disjunctive choice. * apache 1.1 & bsd-3-clause & (openssl ^ gpl-exception) : apache AND bsd AND (openssl with a gpl-exception taken together) apply. * gpl-2.0 [gpl-2.0 ^ gpl-2.0-with-classpath-exception | cddl-1.0] : I picked gpl-2.0 from a choice of gpl with classpath exception or cddl. * proprietary & {mit bsd-3-clause apache-2.0 gpl-2.0-with-bison-exception}: My primary license is proprietary with MIT, BSD, GPL with bison exception and Apache-licensed code as secondary * lgpl-2.0 [lgpl +] : I picked the v2 of the lgpl out of a choice of any LGPL versions. * gpl-2.0 < (gpl-2.0 | mpl-1.1): I think that the license that applies here is only gpl-2.0, despite being asserted originally as choice of gpl or mpl may be because this code is running in kernel space. I hope this helps fueling the discussion. Cheers -- Philippe Ombredanne +1 650 799 0949 | pombredanne@... DejaCode Enterprise at http://www.dejacode.com | What's in your software? (sm) nexB Inc. at http://www.nexb.com |
|
|
|
RUFFIN, MICHEL (MICHEL) <michel.ruffin@...>
I agree that license decomposition is a hard topic but as a first step perhaps a full decomposition in 70 attributes as Tom suggestion is perhaps too much effort. If you look at the OSI licenses there are a reduce set of attributes (source code availability, document or run-time acknowledgement, license propagations, …)
In your example, I do not see how you can solve the interpretation issue.
At file level it is clear that everything should be licensed under GPL but imagine that a part of the software is GPL and another part is BSD but the BSD part is not linked to the GPL part so is not necessary subject to GPL. A company that wants to sublicense the BSD part would like to know that some of the code is BSD, while a company that do not want to sublicense the BSD part can simplify things by distributing all under GPL.
So first you need to know the relationship between the various components and then apply the company policy
Note that it is quite frequent to find SW which is (GPL and LGPL): the standalone code is GPL while the libraries are LGPL
Michel Michel.Ruffin@..., PhD De : Gisi, Mark [mailto:Mark.Gisi@...]
Hi Michel,
Thanks for sharing your experiences. I agree these are worthy topics. I have had a number of similar conversations with Wind River customers through the years. Although these topics can be discussed in parallel, I agree with Tom in that we can’t move much faster (or further) until we repair the foundation from which these concepts are built upon. Before we can begin discussing common agreed upon obligations (semantics), we need to first accurately represent the licensing terms of source files, libraries and programs (syntactically). For example, consider program X, having the following Boolean license expression:
(GPL-2.0 AND BSD-3-Clause)
Program X was built (derived) by integrating a GPL-2.0 licensed file with a BSD-3-Clause licensed file. Some organizations may interpret this one way (e.g., only GPL-2.0 terms matters); while other organizations may interpret it another way (e.g., both GPL-2.0 and BSD-3-Clause terms need to be considered). The elegance of the Boolean expression approach is it allows one to represent the licensing terms based on the files it was derived from, *independent* of a given organization’s interpretation (i.e., semantics). The irony of the situation is - I could work for one organization, which would require me to make one interpretation, and then a year later I go work for another organization, which would require me to make a different interpretation for the same expression.
One could argue – it is important to come together as a community to reach common interpretations of license obligations. My response would be – yes, I agree but let’s first start with a generally accepted “neutral” syntax as the foundation of that discussion. I do feel a sense of urgency to flush out a correct syntax so that we can move on to some of the topics you have highlighted. I do believe SPDX’s approach is close, it may just require a few adjustments and a formal write up. This will ultimately be determined by the collective thinking of the working group. I hope you can join the discussion.
Thanks, - Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-4552
From: Tom Incorvia
[mailto:tom.incorvia@...]
Sent: Wednesday, October 23, 2013 8:13 AM To: RUFFIN, MICHEL (MICHEL); Gisi, Mark; SPDX-legal; spdx-tech@... Subject: RE: Revisiting the SPDX license representation syntax
Hi Michael,
I am an early contributor to SPDX, but have been quiet lately.
I would recommend that we delay moving into rights and obligations until our foundation in the descriptions is more solid.
I did some looking into this in the early days, and found approximately 70 discrete license obligations / grants / conditions that potentially differed based on 40 different use cases (e.g., binary / source, modified / unmodified, stand-alone / combined, in-line/static-link/dynamic-link/command-line, distributed/hosted, etc.).
There were 2,680 combinations per license.
Despite the large number of combinations, many of the conditions required interpretation (for instance, many licenses are silent on some of the conditions; sometimes silence means something (implicit warranties, etc.), sometimes it means nothing.
In the end, the SPDX team at the time decided to stick with descriptions and keep away from what could be construed to be interpretations.
Our progress has been slow and tedious even on the description side.
I am thinking that we get the description phase more solid before expanding to this new (and valuable level).
Thanks,
Tom
Tom Incorvia Direct: (512) 340-1336 M: (215) 500 8838 [**NEW** as of Oct 2013] From:
spdx-legal-bounces@... [mailto:spdx-legal-bounces@...]
On Behalf Of RUFFIN, MICHEL (MICHEL)
Mark,
I think that we should go further (moving from syntax to semantic). We should decomposed FOSS license in terms of right and obligations (Blackduck call that attributes in its protex tool).
We have a system in Alcatel-Lucent to do that since years for instance we have attributes to say that there is need to - have or not acknowledgement of authors in our documentation - have run-time acknowledgement - have source code available or not - have the obligation of copyright indemnification in case of IP issues - have the necessity to propagate the licences - ….
This decomposition is very usefull to explain licenses rights and obligations to our R&D teams (with our decomposition we cover most of the major OSI certified licenses) . It is not perfect, and need some more work.
Blackduck is doing a more formal decomposition of licenses for instance there is attribute is “does the license request that the source code MUST be available” or “does the license request that the source code MAY be available”; With that system they are allowed to define if two FOSS licenses are compatible or not. But their decomposition is not perfect because it can create conflict that do not really exists.
The creative commons licenses are doing such kind of decomposition also so you do not pick up a license but a set of rights and obligations and create your license.
I think there is a ground here to raise a standard.
Michel Michel.Ruffin@..., PhD De :
spdx-legal-bounces@... [mailto:spdx-legal-bounces@...]
De la part de Gisi, Mark
In the last SPDX Legal meeting we discussed whether the current SPDX license representation syntax is sufficient to represent the licensing terms of most files (e.g., source, library and binary programs). For example, is the combination of the SPDX license list + current binary operands (AND and OR) sufficient to describe the licensing of most programs derived from multiple source and library files, where each is potentially under a different license.
We decided to hold a break out session dedicated to discussing this topic in greater depth. Initially special consideration will be given to representing files that have licenses with special exceptions and programs derived from files licensed under multiple different licenses. Keep in mind, given the high degree to which sharing occurs in the community, composite licensing has become the norm rather than the expectation. This is a good thing – we just need to make sure SPDX can accommodate it.
I will be organizing the break session. If you are interested in participating send me i) your email, ii) a brief description of your interest, and iii) days/times that work best for you. I will try to select a meeting time to accommodate the most participants.
Best, - Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-455
|
|
|
|
Mark Gisi
Hi Philippe,
This is the main thesis that is driving this breakout discussion.PPS: Some of this may not mesh entirely well with the current SPDX licenses list state Thank you for the extensive list of examples and proposals. They represent the types of scenarios we need to test the solution we are seeking to determine how well we have done.I hope this helps fueling the discussion. One basic observation - We need to consider how far one can go in constructing an expression that implies some level of legal interpretation. For instance, in one of your examples you noted: One objective might be: To support the construction of license expressions that represent licensing terms of the pieces that go into building a distributable component (e.g., program) yet allow different organizations the ability to apply their legal interpretation. I do realize this is easier said than done. I see a fair amount of differences among organization in their interpretation of licensing, especially when multiple licenses are present (as you have illustrated below).* gpl-2.0 < mit: I think that the license that applies here is gpl-2.0, despite I hope we can encourage others to present situations they believe the current SPDX licensing mechanism does not easily support. Best, Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-4552 -----Original Message----- From: Philippe Ombredanne [mailto:pombredanne@...] Sent: Thursday, October 24, 2013 3:39 AM To: Gisi, Mark Cc: SPDX-legal; spdx-tech@... Subject: Re: Revisiting the SPDX license representation syntax On Tue, Oct 22, 2013 at 6:01 PM, Gisi, Mark <Mark.Gisi@...> wrote: In the last SPDX Legal meeting we discussed whether the current SPDXLet me bring my 2 cents to the discussion. A while back I wrote down this little language to compose licenses. The point was to : - make this easy enough for humans and machines to read, write and understand. - have a terse yet expressive way to represent actual licensing in one statement, eventually expressing the complex licenses composition of whole packages. - support factual licenses statements as well as interpretations such as selection from a choice, the fact that some license may apply that were not asserted originally, etc. PS: For most of it there is nothing new there, SPDX does it alright. PPS: Some of this may not mesh entirely well with the current SPDX licenses list state (such as expressing "or later versions" generically or how we deal with exceptions). Here are the basic examples updated to SPDX: * lgpl-2.0 : a single license applies. * apache-2.0 lgpl-2.0 : All the licenses listed apply, space-separated list. (AND is implied as the default operator, CONJUNCTION) * mit & lgpl-2.0 : All licenses listed apply, ampersand-separated list. (explicit AND, CONJUNCTION) * mit | gpl-2.0 : a license choice: either one of the licenses can apply, the choice does not have to be made and can be passed downstream. (CHOICE, OR) * mit ? gpl-2.0 : a disjunctive license choice of mit or gpl-2.0. A choice must be made. (CHOICE, EXCLUSIVE OR, DISJUNCTION) * gpl-2.0 ^ classpath : a license exception or supplemental terms: here, the classpath exception to the gpl-2.0. nb: here we have a slight change with the SPDX license list, where the exception would be just the exception and not the whole gpl-and-classpath taken together as one license.(EXTRA TERMS, EXCEPTION) * gpl-1.0 + : this license version or a later version applies: i.e. gpl-1.0 or later. nb: here the plus sign is not part of the license id, but part of the syntax which is also different from SPDX (OR LATER version) * (apache-1.1 mit gpl-2.0) : a grouping of licenses. This is useful for explicit grouping in complex statements, rather than relying only on eventual operators precedence (GROUP) * ftl [ftl ? gpl-2.0]: a license selection expressed with brackets: here I picked ftl from the disjunctive choice of ftl or gpl. (SELECTION using brackets) * apache-2.0 {mit bsd-3-clause lgpl-3.0} : I think that the primary license is overall apache-2.0 and that other secondary license apply. This is handy to express composite licenses at a package level. (PRIMARY and SECONDARY using braces) * gpl-2.0 < mit: I think that the license that applies here is gpl-2.0, despite being asserted originally as MIT-licensed (possibly because of linking, dependencies, code reuse or else). (INTERPRETATION, INTERACTION) * gpl-2.0 ! commercial : I think that the gpl applies and that the commercial the license id CANNOT apply. Negations are usually aberrations with conflicting terms but I see vendors releasing dual GPL/proprietary making this type of interpretation in supplemental terms often enough. Some proprietary licenses state the opposite explicitly too: this is commercial and cannot be gpl. This rarely of a practical use but may be needed for completeness (NOT, NEGATION) And more complex examples: * apache-1.1 ( mit | gpl-2.0) : apache AND mit or gpl using a grouping of licenses choice. * mpl-1.1 [gpl-2.0 | lgpl-2.1 | mpl-1.1 ]: I picked mpl-1.1 from the choice of mpl, lgpl or gpl. * gpl-2.0 < (mpl-1.1 [gpl-2.0 ? lgpl-2.1 ? mpl-1.1 ]): I think gpl-2.0 applies here despite a selection of mpl-1.1 from a disjunctive choice. * apache 1.1 & bsd-3-clause & (openssl ^ gpl-exception) : apache AND bsd AND (openssl with a gpl-exception taken together) apply. * gpl-2.0 [gpl-2.0 ^ gpl-2.0-with-classpath-exception | cddl-1.0] : I picked gpl-2.0 from a choice of gpl with classpath exception or cddl. * proprietary & {mit bsd-3-clause apache-2.0 gpl-2.0-with-bison-exception}: My primary license is proprietary with MIT, BSD, GPL with bison exception and Apache-licensed code as secondary * lgpl-2.0 [lgpl +] : I picked the v2 of the lgpl out of a choice of any LGPL versions. * gpl-2.0 < (gpl-2.0 | mpl-1.1): I think that the license that applies here is only gpl-2.0, despite being asserted originally as choice of gpl or mpl may be because this code is running in kernel space. I hope this helps fueling the discussion. Cheers -- Philippe Ombredanne +1 650 799 0949 | pombredanne@... DejaCode Enterprise at http://www.dejacode.com | What's in your software? (sm) nexB Inc. at http://www.nexb.com |
|
|
|
Wolfgang Denk
Dear Philippe Ombredanne,
In message <CAOFm3uEDjBvgyWLTsp0xMXe1vRefoMaAPEnzKhekdx6+-xVohg@...> you wrote: Thanks - I mostly like this, but I would like to suggest a few inor changes to make life easier especially to developers who are used to standard operators in programming languages: * mit ? gpl-2.0 : a disjunctive license choice of mit or gpl-2.0.In C and some other programming languages, the EXCLUSIVE OR operator is '^', so please make this "mit ^ gpl-2.0". * gpl-2.0 ^ classpath : a license exception or supplemental terms:Please use a different operator t mark an exception, as '^' is kind of reserved for XOR. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@... "Summit meetings tend to be like panda matings. The expectations are always high, and the results usually disappointing." - Robert Orben |
|
|
|
Philippe Ombredanne
On Tue, Oct 29, 2013 at 7:26 AM, Wolfgang Denk <wd@...> wrote:
In message <CAOFm3uEDjBvgyWLTsp0xMXe1vRefoMaAPEnzKhekdx6+-xVohg@...> you wrote:Guten Tag Wolfgang!Here are the basic examples updated to SPDX:Thanks - I mostly like this, but I would like to suggest a few minor and thanks for your feedback. You are absolutely right there and being a programmer I had hesitated* mit ? gpl-2.0 : a disjunctive license choice of mit or gpl-2.0.In C and some other programming languages, the EXCLUSIVE OR operator a little about the implications then, and thought that it would be OK to forego programming conventions. Expressing disjunctions with a caret ^ makes perfect sense. In this case, and this would be a good simplification the explicit ampersand & or the implicit space AND separator could be used for a license exception or supplemental terms which is really all that is needed. For instance: gpl-2.0 + & classpath: I am licensed under the GPL 2.0 or any later version with the Classpath expection which could rephrased also as something more or less equivalent for such as this, because the classpath exception states that it can be removed: (gpl-2.0 + & classpath) ^ gpl-2.0 + : you must select the GPL 2.0 or 3.0 with or without the Classpath exception Note that FWIW this little language of mine was buried in notes I wrote down four years ago, and has never been in use practically.... I just adapted it in this email thread to use SPDX license keys. -- Philippe Ombredanne +1 650 799 0949 | pombredanne@... DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com |
|
|
|
Philippe Ombredanne
On Mon, Oct 28, 2013 at 10:57 PM, Gisi, Mark <Mark.Gisi@...> wrote:
One basic observation - We need to consider how far one can go in constructing an expression that implies some level of legal interpretation. For instance, in one of your examples you noted:Exactly!One objective might be: To support the construction of license expressions that* gpl-2.0 < mit: I think that the license that applies here is gpl-2.0, despite The intent when I wrote down an example starting with "I think" is to show where such a syntax could capture eventual interpretations that a user/adopter of SDPX would want to express. I am NOT saying that SPDX should provide such interpretation, but that the system should not prohibit someone else to make these interpretations and should support capturing these in a straightforward way. I see a fair amount of differences among organization in their interpretationSame, and leaving aside whacko interpretations such as "GPL cannot be used commercially", there are many grey areas where different organizations and different counsels may look at things slightly differently and come to different conclusions based on the same original materials. I hope we can encourage others to present situations they believe the current SPDX licensing mechanism does not easily support.+1! -- Philippe Ombredanne +1 650 799 0949 | pombredanne@... DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com CONFIDENTIALITY NOTICE: This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 799 0949. |
|
|