Revisiting the SPDX license representation syntax

[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 [phone] | Fax [phone]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131022/a75174ed/attachment.html>

[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 at Alcatel-Lucent.com, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : spdx-legal-bounces at lists.spdx.org [mailto:spdx-legal-bounces at lists.spdx.org] De la part de Gisi, Mark
Envoy? : mardi 22 octobre 2013 18:02
? : SPDX-legal; spdx-tech at lists.spdx.org
Objet : Revisiting the SPDX license representation syntax

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 [phone] | Fax [phone]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131023/c4fa585b/attachment.html>

[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
tom.incorvia at microfocus.com<mailto:tom.incorvia at microfocus.com>
Direct: [phone]
M: [phone] [**NEW** as of Oct 2013]
From: spdx-legal-bounces at lists.spdx.org [mailto:spdx-legal-bounces at lists.spdx.org] On Behalf Of RUFFIN, MICHEL (MICHEL)
Sent: Wednesday, October 23, 2013 9:48 AM
To: Gisi, Mark; SPDX-legal; spdx-tech at lists.spdx.org
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 at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : spdx-legal-bounces at lists.spdx.org<mailto:spdx-legal-bounces at lists.spdx.org> [mailto:spdx-legal-bounces at lists.spdx.org] De la part de Gisi, Mark
Envoy? : mardi 22 octobre 2013 18:02
? : SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : Revisiting the SPDX license representation syntax

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 [phone] | Fax [phone]

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131023/df2e531f/attachment-0001.html>

[Gisi, Mark]

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 [phone] | Fax [phone]



From: Tom Incorvia [mailto:tom.incorvia at microfocus.com]
Sent: Wednesday, October 23, 2013 8:13 AM
To: RUFFIN, MICHEL (MICHEL); Gisi, Mark; SPDX-legal; spdx-tech at lists.spdx.org
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
tom.incorvia at microfocus.com<mailto:tom.incorvia at microfocus.com>
Direct: [phone]
M: [phone] [**NEW** as of Oct 2013]
From: spdx-legal-bounces at lists.spdx.org<mailto:spdx-legal-bounces at lists.spdx.org> [mailto:spdx-legal-bounces at lists.spdx.org] On Behalf Of RUFFIN, MICHEL (MICHEL)
Sent: Wednesday, October 23, 2013 9:48 AM
To: Gisi, Mark; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
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 at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : spdx-legal-bounces at lists.spdx.org<mailto:spdx-legal-bounces at lists.spdx.org> [mailto:spdx-legal-bounces at lists.spdx.org] De la part de Gisi, Mark
Envoy? : mardi 22 octobre 2013 18:02
? : SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : Revisiting the SPDX license representation syntax

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 [phone] | Fax [phone]

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131023/dae9235d/attachment-0001.html>

[RUFFIN, MICHEL (MICHEL)]

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 at Alcatel-Lucent.com, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : mercredi 23 octobre 2013 19:14
? : RUFFIN, MICHEL (MICHEL)
Cc : Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org
Objet : RE: Revisiting the SPDX license representation syntax

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 [phone] | Fax [phone]



From: Tom Incorvia [mailto:tom.incorvia at microfocus.com]
Sent: Wednesday, October 23, 2013 8:13 AM
To: RUFFIN, MICHEL (MICHEL); Gisi, Mark; SPDX-legal; spdx-tech at lists.spdx.org
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
tom.incorvia at microfocus.com<mailto:tom.incorvia at microfocus.com>
Direct: [phone]
M: [phone] [**NEW** as of Oct 2013]
From: spdx-legal-bounces at lists.spdx.org<mailto:spdx-legal-bounces at lists.spdx.org> [mailto:spdx-legal-bounces at lists.spdx.org] On Behalf Of RUFFIN, MICHEL (MICHEL)
Sent: Wednesday, October 23, 2013 9:48 AM
To: Gisi, Mark; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
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 at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : spdx-legal-bounces at lists.spdx.org<mailto:spdx-legal-bounces at lists.spdx.org> [mailto:spdx-legal-bounces at lists.spdx.org] De la part de Gisi, Mark
Envoy? : mardi 22 octobre 2013 18:02
? : SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : Revisiting the SPDX license representation syntax

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 [phone] | Fax [phone]

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131024/7cedafe4/attachment-0001.html>

[Gisi, Mark]

Michel,

You make some good points which I would like to build upon for the upcoming discussion.

Post by RUFFIN, MICHEL (MICHEL)
Note that it is quite frequent to find SW which is (GPL and LGPL): the standalone code is GPL while the libraries are LGPL

Package Licensing
---------------------------

Post by RUFFIN, MICHEL (MICHEL)
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.

Program & Library Licensing
------------------------------------------
Boolean expressions are very useful to describe the licensing of a program or library that is built by linking one or more other files (source and library files). Licensing of any new linked work is a function of the licensing of its parts (directly and indirectly linked). It is less natural (and more dangerous) to use a single Boolean expression (or a single license identifier) to describe the licensing of a collection of *unlinked* components. This is one of the core problems of package licensing today. I illustrate this by building on your example. Consider the following licensing:

? Source file SFile1 -> LGPL-2.1+

? Source file SFile2 -> GPL-2.0

? Library file LFile3 -> (MIT AND (LPGL-2.1 OR MPL-1.1))

? Library file LFile4 -> BSD-2-Clause

? Program file PFile5 is built (derived) by linking SFile1 and SFile2 -> (LGPL-2.1+ AND GPL-2.0)

? Program file PFile6 is built (derived) by linking SFile1 and LFile4 -> (LPGP-2.1+ AND BSD-2-Clause)

It makes perfect sense to determine the distribution obligations of program PFile5 based on one's legal interpretation of the conjunctive expression (SFile1 + SFile2):
(LGPL-2.1+ AND GPL-2.0)

Or the distribution obligations of program PFile6 based on one's legal interpretation of the conjunctive expression (SFile1 + LFile4):
(LPGP-2.1+ AND BSD-2-Clause)

It makes less sense to talk about the collective (group) licensing of files SFile2, LFile3 and PFile6 because they are unrelated (not linked). That is essentially what the package license attempts to achieve today. There are a number of historical reasons why the package license is still relied upon but that topic deserves its own dedicated discussion.

So to your point, if one was to distribute program PFile6, one must apply their legal analysis to the entire expression:
(LPGP-2.1+ AND BSD-2-Clause)

You can't tease it apart because it is a new work created via linking. However, as you have pointed out, one may want to independently use LFile4 subject to the BSD-2-Clause license which can be achieved. The package license is not relevant here.

All in all, Boolean expressions provide an effective way to describe licensing of programs, libraries and source files (linkable distributable components). Package licensing is an ill defined concept. Often a package can be viewed as a box containing a collection of components each *potentially* subject to different licensing terms. We will need to address these differences in the upcoming licensing breakout session.

Best,

Mark Gisi | Wind River | Senior Intellectual Property Manager
Tel [phone] | Fax [phone]



From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Thursday, October 24, 2013 5:53 AM
To: Gisi, Mark
Cc: Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org
Subject: RE: Revisiting the SPDX license representation syntax

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 at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : mercredi 23 octobre 2013 19:14
? : RUFFIN, MICHEL (MICHEL)
Cc : Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : RE: Revisiting the SPDX license representation syntax

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 [phone] | Fax [phone]



From: Tom Incorvia [mailto:tom.incorvia at microfocus.com]
Sent: Wednesday, October 23, 2013 8:13 AM
To: RUFFIN, MICHEL (MICHEL); Gisi, Mark; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
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
tom.incorvia at microfocus.com<mailto:tom.incorvia at microfocus.com>
Direct: [phone]
M: [phone] [**NEW** as of Oct 2013]
From: spdx-legal-bounces at lists.spdx.org<mailto:spdx-legal-bounces at lists.spdx.org> [mailto:spdx-legal-bounces at lists.spdx.org] On Behalf Of RUFFIN, MICHEL (MICHEL)
Sent: Wednesday, October 23, 2013 9:48 AM
To: Gisi, Mark; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
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 at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : spdx-legal-bounces at lists.spdx.org<mailto:spdx-legal-bounces at lists.spdx.org> [mailto:spdx-legal-bounces at lists.spdx.org] De la part de Gisi, Mark
Envoy? : mardi 22 octobre 2013 18:02
? : SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : Revisiting the SPDX license representation syntax

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 [phone] | Fax [phone]

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131028/aec6e068/attachment-0001.html>

[RUFFIN, MICHEL (MICHEL)]

Mark,
I do not criticize the boolean system
I just want to point out that we are mostly dealing with package level system
If I take the example of JBoss in our FOSS DB you get the following (see below)

So the concluded license is just LGPL-2.1 AND(+) a lot of dependencies

Note that "Dual" in our DB: means OR (we are perhaps not totally compliant to the SPDX standard but revision of our DB entries will take times)
The thing in blue correspond to links to other FOSS in our DB or Licenses
This demonstrates also some of the actual limit of the SPDX standard. When an open source dependency has no link it means that it has been codified with a different name in our DB (because the links are done automatically by the Database).

Food for thoughts
Michel


[cid:image002.jpg at 01CED4CD.DE7B9BB0]


Michel.Ruffin at Alcatel-Lucent.com, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : lundi 28 octobre 2013 23:23
? : RUFFIN, MICHEL (MICHEL)
Cc : Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org
Objet : RE: Revisiting the SPDX license representation syntax (Package vs. Program license)

Michel,

You make some good points which I would like to build upon for the upcoming discussion.

Post by RUFFIN, MICHEL (MICHEL)
Note that it is quite frequent to find SW which is (GPL and LGPL): the standalone code is GPL while the libraries are LGPL

Package Licensing
---------------------------

Post by RUFFIN, MICHEL (MICHEL)
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.

Program & Library Licensing
------------------------------------------
Boolean expressions are very useful to describe the licensing of a program or library that is built by linking one or more other files (source and library files). Licensing of any new linked work is a function of the licensing of its parts (directly and indirectly linked). It is less natural (and more dangerous) to use a single Boolean expression (or a single license identifier) to describe the licensing of a collection of *unlinked* components. This is one of the core problems of package licensing today. I illustrate this by building on your example. Consider the following licensing:

? Source file SFile1 -> LGPL-2.1+

? Source file SFile2 -> GPL-2.0

? Library file LFile3 -> (MIT AND (LPGL-2.1 OR MPL-1.1))

? Library file LFile4 -> BSD-2-Clause

? Program file PFile5 is built (derived) by linking SFile1 and SFile2 -> (LGPL-2.1+ AND GPL-2.0)

? Program file PFile6 is built (derived) by linking SFile1 and LFile4 -> (LPGP-2.1+ AND BSD-2-Clause)

It makes perfect sense to determine the distribution obligations of program PFile5 based on one's legal interpretation of the conjunctive expression (SFile1 + SFile2):
(LGPL-2.1+ AND GPL-2.0)

Or the distribution obligations of program PFile6 based on one's legal interpretation of the conjunctive expression (SFile1 + LFile4):
(LPGP-2.1+ AND BSD-2-Clause)

It makes less sense to talk about the collective (group) licensing of files SFile2, LFile3 and PFile6 because they are unrelated (not linked). That is essentially what the package license attempts to achieve today. There are a number of historical reasons why the package license is still relied upon but that topic deserves its own dedicated discussion.

So to your point, if one was to distribute program PFile6, one must apply their legal analysis to the entire expression:
(LPGP-2.1+ AND BSD-2-Clause)

You can't tease it apart because it is a new work created via linking. However, as you have pointed out, one may want to independently use LFile4 subject to the BSD-2-Clause license which can be achieved. The package license is not relevant here.

All in all, Boolean expressions provide an effective way to describe licensing of programs, libraries and source files (linkable distributable components). Package licensing is an ill defined concept. Often a package can be viewed as a box containing a collection of components each *potentially* subject to different licensing terms. We will need to address these differences in the upcoming licensing breakout session.

Best,

Mark Gisi | Wind River | Senior Intellectual Property Manager
Tel [phone] | Fax [phone]



From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Thursday, October 24, 2013 5:53 AM
To: Gisi, Mark
Cc: Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org
Subject: RE: Revisiting the SPDX license representation syntax

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 at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : mercredi 23 octobre 2013 19:14
? : RUFFIN, MICHEL (MICHEL)
Cc : Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : RE: Revisiting the SPDX license representation syntax

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 [phone] | Fax [phone]



From: Tom Incorvia [mailto:tom.incorvia at microfocus.com]
Sent: Wednesday, October 23, 2013 8:13 AM
To: RUFFIN, MICHEL (MICHEL); Gisi, Mark; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
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
tom.incorvia at microfocus.com<mailto:tom.incorvia at microfocus.com>
Direct: [phone]
M: [phone] [**NEW** as of Oct 2013]
From: spdx-legal-bounces at lists.spdx.org<mailto:spdx-legal-bounces at lists.spdx.org> [mailto:spdx-legal-bounces at lists.spdx.org] On Behalf Of RUFFIN, MICHEL (MICHEL)
Sent: Wednesday, October 23, 2013 9:48 AM
To: Gisi, Mark; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
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 at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : spdx-legal-bounces at lists.spdx.org<mailto:spdx-legal-bounces at lists.spdx.org> [mailto:spdx-legal-bounces at lists.spdx.org] De la part de Gisi, Mark
Envoy? : mardi 22 octobre 2013 18:02
? : SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : Revisiting the SPDX license representation syntax

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 [phone] | Fax [phone]

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131029/edf82fb5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 229737 bytes
Desc: image002.jpg
URL: <Loading Image...>

[Philippe Ombredanne]

On Tue, Oct 29, 2013 at 5:39 PM, RUFFIN, MICHEL (MICHEL)

Post by RUFFIN, MICHEL (MICHEL)
I just want to point out that we are mostly dealing with package level system
If I take the example of JBoss in our FOSS DB you get the following (see below)
So the concluded license is just LGPL-2.1 AND(+) a lot of dependencies

Michel:
My 2 cents, I would possibly express this either:
* as lplg-2.1+ {mit bsd-3-clause and a long list of licenses .... }
using my 'little language'

OR

* I would create a new license internally which I would call the
something like the JBossAS-4.2.1 license. This would be a 'composite'
of all the licenses contained in this large component, abstracting the
details. AFAIK, there is nothing in SPDX that would prohibit you from
creating your own licenses for this purpose.
You could even provide both the long list of SPDX ids AND the composite text.

Post by RUFFIN, MICHEL (MICHEL)

Post by Gisi, Mark
All in all, Boolean expressions provide an effective way to describe licensing of
programs, libraries and source files (linkable distributable components).
Package licensing is an ill defined concept. Often a package can be viewed
as a box containing a collection of components each *potentially* subject to
different licensing terms. We will need to address these differences in the
upcoming licensing breakout session.

Mark and Michel:
IMHO, you guys are coming from two different points of view but are
talking the same language.

As a Linux distro vendor (or a JBoss distro provider) I may want to
express the obligations of the packages I distribute (be they mine or
from upstream) at a finer level of granularity, which would be
possible unit of discrete consumption. This would then be helpful to
downstream consumers such they could make informed decisions when they
consume, use, build or link with components I provide in my distro.

As a component consumer, I may want to treat these upstream
obligations at a more coarse level, and treat larger things possibly
as big as a Linux distro or a JBoss as one aggregate component, and
may or may not care about finer-grained details passed to me from
upstream.

Because in the end, somehow, your product (that you may see as several
fine-grained components) may be one of the many components for my own
product or application and I may see as just one single component.

I think that SPDX does and should in spirit and letter support both approaches.

[Gisi, Mark]

Post by RUFFIN, MICHEL (MICHEL)

Post by Gisi, Mark

As a component consumer, I may want to treat these upstream obligations at a
more coarse level, and treat larger things possibly as big as a Linux distro
or a JBoss as one aggregate component, and may or may not care about finer-
grained details passed to me from upstream.

Coarse level compliance is an interesting term. It suggests a level of compliance quality where one chooses to comply with some applicable licenses but not others. For example, saying the Android platform is available under just the Apache-2.0 license, when in fact the GPL, LGPL, BSD and various other licenses are also relevant to an Android distributor creates a problem. Although I struggle with the suggestion that coarse level compliance is an acceptable approach, I do understand why this approach has been taken.

For years open source consumers have struggle to obtain high quality license information. For years many they have been force to pursue coarse level compliance because that was the only level achievable with reasonable efforts. Actually, this was not true in the *earliest of days* when the Big 4 (FSF, Apache Foundation, Eclipse, Kernel.org) supplied the lion share of open source software. The quality of license information for their respected packages was (and still is) very high. The Big 4 achieve this by exercising good discipline with respect to managing licensing information in their code base (e.g., including a license notice in every file). The problem stems from many other projects demonstrating considerable less discipline with respect to managing licensing info.

SPDX is fueling a paradigm shift with respect to the compliance quality level one can achieve with reasonable efforts. The current version, SPDX 1.2, does two important things: 1) delivers much higher quality license information (e.g., at the file level) and 2) sheds light on how good or poorly licensing information has been managed by a project or initiative. When better licensing information is available, coarse level compliance is not an approach I would recommend.

Post by RUFFIN, MICHEL (MICHEL)

Post by Gisi, Mark

IMHO, you guys are coming from two different points of view but
are talking the same language.

I agree. I chose a bottom up approach where Michel chose a more traditional top down approach. In the end I find Michel's position to be more than reasonable when faced with less than perfect information. I wanted to build on Michel's example to highlight how we can all do better than coarse level compliance. Many organizations actually want to do more. Before SPDX it was not feasible to achieve with reasonable efforts. The advent of SPDX has fundamentally changed this.

I will follow up next with a proposal on how SPDX data can be leveraged to solve the JBoss coarse level compliance problem.

- Mark

Mark Gisi | Wind River | Senior Intellectual Property Manager
Tel [phone] |?Fax?[phone]


-----Original Message-----
From: spdx-legal-bounces at lists.spdx.org [mailto:spdx-legal-bounces at lists.spdx.org] On Behalf Of Philippe Ombredanne
Sent: Tuesday, October 29, 2013 3:22 PM
Cc: spdx-tech at lists.spdx.org; SPDX-legal
Subject: Re: Revisiting the SPDX license representation syntax (Package vs. Program license)

Post by RUFFIN, MICHEL (MICHEL)
I just want to point out that we are mostly dealing with package level
system If I take the example of JBoss in our FOSS DB you get the
following (see below) So the concluded license is just LGPL-2.1 AND(+)
a lot of dependencies

Michel:
My 2 cents, I would possibly express this either:
* as lplg-2.1+ {mit bsd-3-clause and a long list of licenses .... } using my 'little language'

OR

* I would create a new license internally which I would call the something like the JBossAS-4.2.1 license. This would be a 'composite'
of all the licenses contained in this large component, abstracting the details. AFAIK, there is nothing in SPDX that would prohibit you from creating your own licenses for this purpose.
You could even provide both the long list of SPDX ids AND the composite text.

Post by RUFFIN, MICHEL (MICHEL)

Post by Gisi, Mark
All in all, Boolean expressions provide an effective way to describe
licensing of programs, libraries and source files (linkable distributable components).
Package licensing is an ill defined concept. Often a package can be
viewed as a box containing a collection of components each
*potentially* subject to different licensing terms. We will need to
address these differences in the upcoming licensing breakout session.

Mark and Michel:
IMHO, you guys are coming from two different points of view but are talking the same language.

As a Linux distro vendor (or a JBoss distro provider) I may want to express the obligations of the packages I distribute (be they mine or from upstream) at a finer level of granularity, which would be possible unit of discrete consumption. This would then be helpful to downstream consumers such they could make informed decisions when they consume, use, build or link with components I provide in my distro.

As a component consumer, I may want to treat these upstream obligations at a more coarse level, and treat larger things possibly as big as a Linux distro or a JBoss as one aggregate component, and may or may not care about finer-grained details passed to me from upstream.

Because in the end, somehow, your product (that you may see as several fine-grained components) may be one of the many components for my own product or application and I may see as just one single component.

I think that SPDX does and should in spirit and letter support both approaches.

--
Philippe Ombredanne

[phone] | pombredanne at nexB.com
DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com _______________________________________________
Spdx-legal mailing list
Spdx-legal at lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

[Gisi, Mark]

Michel,

Post by RUFFIN, MICHEL (MICHEL)
If I take the example of JBoss in our FOSS DB you get the following (see below)

It may be more helpful to view JBoss as a platform like Android or Linux rather than a utility like Busybox or GCC. JBoss, like Linux, does not represent one package, but instead a platform of packages. Therefore one would expect many dependencies (other packages). I would not recommend using a single monolithic SPDX file (let alone a single license identifier) to represent the licensing of an entire platform (e.g., Linux or Android). For instance, although many view Android to be distributed under the Apache-2.0 license, GPL-2.0 and various other licenses also apply.

Wind River currently delivers a large collection of SPDX files (800+) that represent the licensing of all the components of an entire Linux platform. I would recommend the same approach for JBoss. There are many packages in Linux that depend on other packages. Dependencies can be identified using the build system. I do not believe the problem here is an SPDX structural or technical deficiency; but rather simply the lack of SPDX data for JBoss packages. A build system + a repository of SPDX files = a compliance killer app.

I provided a more detailed technical discussion in the section below that describes how to use SPDX 1.2 together with a build system, to create the Boolean licensing expressions that represent the distribution obligations for the JBoss components that end up on a device.

Post by RUFFIN, MICHEL (MICHEL)
Food for thought

I think the points you are raising are excellent. They not only challenge the current way of thinking about the compliance problem, but also they provide opportunities to offer clarity to others on how SPDX can benefit them. I hope you can continue to provide food for thought that challenges the SPDX approach.

Regards,
- Mark


Technical Discussion: JBoss + SPDX
--------------------------------------------------------
SPDX data, if it exists, can be used together with a build system to obtain the correct level of licensing information. As I noted earlier, in the embedded space, platform packages are typically rummaged through, picked apart where often only a subset of files (or components) are actually used. Therefore a device vendor needs to only build the specific JBoss programs and libraries that will run on their device.
Let's assume:

* We have an SPDX file for each JBoss package or sub-package.

* The following components from various different JBoss packages have been selected to run on a device runtime:

- Source file SFile1 -> LGPL-2.1+

- Source file SFile2 -> GPL-2.0

- Library file LFile3 -> (MIT AND (LPGL-2.1 OR MPL-1.1))

- Library file LFile4 -> BSD-2-Clause

Programs that are built along the way include:

- Program file PFile5 is built (derived) by linking SFile1 and SFile2 -> (LGPL-2.1+ AND GPL-2.0)

- Program file PFile6 is built (derived) by linking SFile1 and LFile4 -> (LPGP-2.1+ AND BSD-2-Clause)

To generate the required licensing expressions for the distributed JBoss components one could:
1) load all SDPX files into a single central database (repository)
2) For each built program (e.g., PFile5 and PFile6), one could use the build system to find all file dependencies. We know that:
PFile5 is derived from SFile1 and SFile2; and
PFile6 is derived from SFile1 and LFile4
3) Query the SPDX repository to obtain the licensing for source files SFile1 and SFile2 and library LFile4 and then construct the license expressions for PFile5 and PFile6.
4) Constructing an SPDX file that covers the distributable JBoss components would be a straight forward task resulting in:

My JBoss Components SPDX 1.2 File (simplified)
=========================================
SFile1 Concluded License: LGPL-2.1+
SFile1 Concluded License: GPL-2.0
LFile4 Concluded License: BSD-2-Clause
PFile5 Concluded License: (LGPL-2.1+ AND GPL-2.0)
File Dependency: SFile1 <- new in SPDX 1.2
File Dependency: SFile2
PFile6 Concluded License: (LPGP-2.1+ AND BSD-2-Clause)
File Dependency: SFile1
File Dependency: LFile4

Library LFile3 was not included because it was not linked or include as one of the distributed components. The actual number of distributable components will likely be a small subset of all the components represented in the JBoss platform. SPDX 1.2 also allows one to include file dependency info. For example, in the case of program PFile5, because it is subjected to the GPL-2.0, it is useful to list the source files that must be given to the recipient of the PFile5 binary as a requirement of GPL-2.0.

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Tuesday, October 29, 2013 9:40 AM
To: Gisi, Mark
Cc: Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org
Subject: RE: Revisiting the SPDX license representation syntax (Package vs. Program license)

Mark,
I do not criticize the boolean system
I just want to point out that we are mostly dealing with package level system
If I take the example of JBoss in our FOSS DB you get the following (see below)

So the concluded license is just LGPL-2.1 AND(+) a lot of dependencies

Note that "Dual" in our DB: means OR (we are perhaps not totally compliant to the SPDX standard but revision of our DB entries will take times)
The thing in blue correspond to links to other FOSS in our DB or Licenses
This demonstrates also some of the actual limit of the SPDX standard. When an open source dependency has no link it means that it has been codified with a different name in our DB (because the links are done automatically by the Database).

Food for thoughts
Michel


[cid:image001.jpg at 01CED640.F25F35A0]


Michel.Ruffin at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131031/58dec274/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 229737 bytes
Desc: image001.jpg
URL: <Loading Image...>

[RUFFIN, MICHEL (MICHEL)]

Mark,
Yes and no is my answer
Yes Jboss can be considered as a platform
No: Now open sources are coming with an increasing set of dependencies
Look at spring, swan, perl (small snapshop of our foss DB on perl and there are a lot of web pages on perl), ...

Michel

[cid:image003.jpg at 01CED708.D5403C30]


Michel.Ruffin at Alcatel-Lucent.com, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : jeudi 31 octobre 2013 22:04
? : RUFFIN, MICHEL (MICHEL)
Cc : SPDX-legal; spdx-tech at lists.spdx.org
Objet : JBoss Compliance SPDX support

Michel,

Post by RUFFIN, MICHEL (MICHEL)
If I take the example of JBoss in our FOSS DB you get the following (see below)

It may be more helpful to view JBoss as a platform like Android or Linux rather than a utility like Busybox or GCC. JBoss, like Linux, does not represent one package, but instead a platform of packages. Therefore one would expect many dependencies (other packages). I would not recommend using a single monolithic SPDX file (let alone a single license identifier) to represent the licensing of an entire platform (e.g., Linux or Android). For instance, although many view Android to be distributed under the Apache-2.0 license, GPL-2.0 and various other licenses also apply.

Wind River currently delivers a large collection of SPDX files (800+) that represent the licensing of all the components of an entire Linux platform. I would recommend the same approach for JBoss. There are many packages in Linux that depend on other packages. Dependencies can be identified using the build system. I do not believe the problem here is an SPDX structural or technical deficiency; but rather simply the lack of SPDX data for JBoss packages. A build system + a repository of SPDX files = a compliance killer app.

I provided a more detailed technical discussion in the section below that describes how to use SPDX 1.2 together with a build system, to create the Boolean licensing expressions that represent the distribution obligations for the JBoss components that end up on a device.

Post by RUFFIN, MICHEL (MICHEL)
Food for thought

I think the points you are raising are excellent. They not only challenge the current way of thinking about the compliance problem, but also they provide opportunities to offer clarity to others on how SPDX can benefit them. I hope you can continue to provide food for thought that challenges the SPDX approach.

Regards,
- Mark


Technical Discussion: JBoss + SPDX
--------------------------------------------------------
SPDX data, if it exists, can be used together with a build system to obtain the correct level of licensing information. As I noted earlier, in the embedded space, platform packages are typically rummaged through, picked apart where often only a subset of files (or components) are actually used. Therefore a device vendor needs to only build the specific JBoss programs and libraries that will run on their device.
Let's assume:

? We have an SPDX file for each JBoss package or sub-package.

? The following components from various different JBoss packages have been selected to run on a device runtime:

- Source file SFile1 -> LGPL-2.1+

- Source file SFile2 -> GPL-2.0

- Library file LFile3 -> (MIT AND (LPGL-2.1 OR MPL-1.1))

- Library file LFile4 -> BSD-2-Clause

Programs that are built along the way include:

- Program file PFile5 is built (derived) by linking SFile1 and SFile2 -> (LGPL-2.1+ AND GPL-2.0)

- Program file PFile6 is built (derived) by linking SFile1 and LFile4 -> (LPGP-2.1+ AND BSD-2-Clause)

To generate the required licensing expressions for the distributed JBoss components one could:
1) load all SDPX files into a single central database (repository)
2) For each built program (e.g., PFile5 and PFile6), one could use the build system to find all file dependencies. We know that:
PFile5 is derived from SFile1 and SFile2; and
PFile6 is derived from SFile1 and LFile4
3) Query the SPDX repository to obtain the licensing for source files SFile1 and SFile2 and library LFile4 and then construct the license expressions for PFile5 and PFile6.
4) Constructing an SPDX file that covers the distributable JBoss components would be a straight forward task resulting in:

My JBoss Components SPDX 1.2 File (simplified)
=========================================
SFile1 Concluded License: LGPL-2.1+
SFile1 Concluded License: GPL-2.0
LFile4 Concluded License: BSD-2-Clause
PFile5 Concluded License: (LGPL-2.1+ AND GPL-2.0)
File Dependency: SFile1 <- new in SPDX 1.2
File Dependency: SFile2
PFile6 Concluded License: (LPGP-2.1+ AND BSD-2-Clause)
File Dependency: SFile1
File Dependency: LFile4

Library LFile3 was not included because it was not linked or include as one of the distributed components. The actual number of distributable components will likely be a small subset of all the components represented in the JBoss platform. SPDX 1.2 also allows one to include file dependency info. For example, in the case of program PFile5, because it is subjected to the GPL-2.0, it is useful to list the source files that must be given to the recipient of the PFile5 binary as a requirement of GPL-2.0.

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Tuesday, October 29, 2013 9:40 AM
To: Gisi, Mark
Cc: Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org
Subject: RE: Revisiting the SPDX license representation syntax (Package vs. Program license)

Mark,
I do not criticize the boolean system
I just want to point out that we are mostly dealing with package level system
If I take the example of JBoss in our FOSS DB you get the following (see below)

So the concluded license is just LGPL-2.1 AND(+) a lot of dependencies

Note that "Dual" in our DB: means OR (we are perhaps not totally compliant to the SPDX standard but revision of our DB entries will take times)
The thing in blue correspond to links to other FOSS in our DB or Licenses
This demonstrates also some of the actual limit of the SPDX standard. When an open source dependency has no link it means that it has been codified with a different name in our DB (because the links are done automatically by the Database).

Food for thoughts
Michel


[cid:image004.jpg at 01CED708.D5403C30]


Michel.Ruffin at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131101/2628022e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 172593 bytes
Desc: image003.jpg
URL: <Loading Image...>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 229737 bytes
Desc: image004.jpg
URL: <Loading Image...>

[Gisi, Mark]

Michel,

Post by RUFFIN, MICHEL (MICHEL)
No: Now open sources are coming with an increasing set of dependencies

I agree. Can you select one example and send me the package to work through? It could serve as a useful SPDX tutorial.

Thanks,
- Mark


From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Friday, November 01, 2013 5:47 AM
To: Gisi, Mark
Cc: SPDX-legal; spdx-tech at lists.spdx.org
Subject: RE: JBoss Compliance SPDX support

Mark,
Yes and no is my answer
Yes Jboss can be considered as a platform
No: Now open sources are coming with an increasing set of dependencies
Look at spring, swan, perl (small snapshop of our foss DB on perl and there are a lot of web pages on perl), ...

Michel

[cid:image001.jpg at 01CED6CE.37825B20]


Michel.Ruffin at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : jeudi 31 octobre 2013 22:04
? : RUFFIN, MICHEL (MICHEL)
Cc : SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : JBoss Compliance SPDX support

Michel,

Post by RUFFIN, MICHEL (MICHEL)
If I take the example of JBoss in our FOSS DB you get the following (see below)

It may be more helpful to view JBoss as a platform like Android or Linux rather than a utility like Busybox or GCC. JBoss, like Linux, does not represent one package, but instead a platform of packages. Therefore one would expect many dependencies (other packages). I would not recommend using a single monolithic SPDX file (let alone a single license identifier) to represent the licensing of an entire platform (e.g., Linux or Android). For instance, although many view Android to be distributed under the Apache-2.0 license, GPL-2.0 and various other licenses also apply.

Wind River currently delivers a large collection of SPDX files (800+) that represent the licensing of all the components of an entire Linux platform. I would recommend the same approach for JBoss. There are many packages in Linux that depend on other packages. Dependencies can be identified using the build system. I do not believe the problem here is an SPDX structural or technical deficiency; but rather simply the lack of SPDX data for JBoss packages. A build system + a repository of SPDX files = a compliance killer app.

I provided a more detailed technical discussion in the section below that describes how to use SPDX 1.2 together with a build system, to create the Boolean licensing expressions that represent the distribution obligations for the JBoss components that end up on a device.

Post by RUFFIN, MICHEL (MICHEL)
Food for thought

I think the points you are raising are excellent. They not only challenge the current way of thinking about the compliance problem, but also they provide opportunities to offer clarity to others on how SPDX can benefit them. I hope you can continue to provide food for thought that challenges the SPDX approach.

Regards,
- Mark


Technical Discussion: JBoss + SPDX
--------------------------------------------------------
SPDX data, if it exists, can be used together with a build system to obtain the correct level of licensing information. As I noted earlier, in the embedded space, platform packages are typically rummaged through, picked apart where often only a subset of files (or components) are actually used. Therefore a device vendor needs to only build the specific JBoss programs and libraries that will run on their device.
Let's assume:

? We have an SPDX file for each JBoss package or sub-package.

? The following components from various different JBoss packages have been selected to run on a device runtime:

- Source file SFile1 -> LGPL-2.1+

- Source file SFile2 -> GPL-2.0

- Library file LFile3 -> (MIT AND (LPGL-2.1 OR MPL-1.1))

- Library file LFile4 -> BSD-2-Clause

Programs that are built along the way include:

- Program file PFile5 is built (derived) by linking SFile1 and SFile2 -> (LGPL-2.1+ AND GPL-2.0)

- Program file PFile6 is built (derived) by linking SFile1 and LFile4 -> (LPGP-2.1+ AND BSD-2-Clause)

To generate the required licensing expressions for the distributed JBoss components one could:
1) load all SDPX files into a single central database (repository)
2) For each built program (e.g., PFile5 and PFile6), one could use the build system to find all file dependencies. We know that:
PFile5 is derived from SFile1 and SFile2; and
PFile6 is derived from SFile1 and LFile4
3) Query the SPDX repository to obtain the licensing for source files SFile1 and SFile2 and library LFile4 and then construct the license expressions for PFile5 and PFile6.
4) Constructing an SPDX file that covers the distributable JBoss components would be a straight forward task resulting in:

My JBoss Components SPDX 1.2 File (simplified)
=========================================
SFile1 Concluded License: LGPL-2.1+
SFile1 Concluded License: GPL-2.0
LFile4 Concluded License: BSD-2-Clause
PFile5 Concluded License: (LGPL-2.1+ AND GPL-2.0)
File Dependency: SFile1 <- new in SPDX 1.2
File Dependency: SFile2
PFile6 Concluded License: (LPGP-2.1+ AND BSD-2-Clause)
File Dependency: SFile1
File Dependency: LFile4

Library LFile3 was not included because it was not linked or include as one of the distributed components. The actual number of distributable components will likely be a small subset of all the components represented in the JBoss platform. SPDX 1.2 also allows one to include file dependency info. For example, in the case of program PFile5, because it is subjected to the GPL-2.0, it is useful to list the source files that must be given to the recipient of the PFile5 binary as a requirement of GPL-2.0.

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Tuesday, October 29, 2013 9:40 AM
To: Gisi, Mark
Cc: Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Subject: RE: Revisiting the SPDX license representation syntax (Package vs. Program license)

Mark,
I do not criticize the boolean system
I just want to point out that we are mostly dealing with package level system
If I take the example of JBoss in our FOSS DB you get the following (see below)

So the concluded license is just LGPL-2.1 AND(+) a lot of dependencies

Note that "Dual" in our DB: means OR (we are perhaps not totally compliant to the SPDX standard but revision of our DB entries will take times)
The thing in blue correspond to links to other FOSS in our DB or Licenses
This demonstrates also some of the actual limit of the SPDX standard. When an open source dependency has no link it means that it has been codified with a different name in our DB (because the links are done automatically by the Database).

Food for thoughts
Michel


[cid:image002.jpg at 01CED6CE.37825B20]


Michel.Ruffin at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131104/bb5acced/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 172593 bytes
Desc: image001.jpg
URL: <Loading Image...>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 229737 bytes
Desc: image002.jpg
URL: <Loading Image...>

[RUFFIN, MICHEL (MICHEL)]

I am not sure what is your request about, I already sent you the Jboss example which is a good one
Here is Jboss 5.0.0
[cid:image001.jpg at 01CEDEE3.2AE49910]


Michel.Ruffin at Alcatel-Lucent.com, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : lundi 4 novembre 2013 18:04
? : RUFFIN, MICHEL (MICHEL)
Cc : SPDX-legal; spdx-tech at lists.spdx.org
Objet : RE: JBoss Compliance SPDX support

Michel,

Post by RUFFIN, MICHEL (MICHEL)
No: Now open sources are coming with an increasing set of dependencies

I agree. Can you select one example and send me the package to work through? It could serve as a useful SPDX tutorial.

Thanks,
- Mark


From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Friday, November 01, 2013 5:47 AM
To: Gisi, Mark
Cc: SPDX-legal; spdx-tech at lists.spdx.org
Subject: RE: JBoss Compliance SPDX support

Mark,
Yes and no is my answer
Yes Jboss can be considered as a platform
No: Now open sources are coming with an increasing set of dependencies
Look at spring, swan, perl (small snapshop of our foss DB on perl and there are a lot of web pages on perl), ...

Michel

[cid:image001.jpg at 01CED6CE.37825B20]


Michel.Ruffin at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : jeudi 31 octobre 2013 22:04
? : RUFFIN, MICHEL (MICHEL)
Cc : SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : JBoss Compliance SPDX support

Michel,

Post by RUFFIN, MICHEL (MICHEL)
If I take the example of JBoss in our FOSS DB you get the following (see below)

It may be more helpful to view JBoss as a platform like Android or Linux rather than a utility like Busybox or GCC. JBoss, like Linux, does not represent one package, but instead a platform of packages. Therefore one would expect many dependencies (other packages). I would not recommend using a single monolithic SPDX file (let alone a single license identifier) to represent the licensing of an entire platform (e.g., Linux or Android). For instance, although many view Android to be distributed under the Apache-2.0 license, GPL-2.0 and various other licenses also apply.

Wind River currently delivers a large collection of SPDX files (800+) that represent the licensing of all the components of an entire Linux platform. I would recommend the same approach for JBoss. There are many packages in Linux that depend on other packages. Dependencies can be identified using the build system. I do not believe the problem here is an SPDX structural or technical deficiency; but rather simply the lack of SPDX data for JBoss packages. A build system + a repository of SPDX files = a compliance killer app.

I provided a more detailed technical discussion in the section below that describes how to use SPDX 1.2 together with a build system, to create the Boolean licensing expressions that represent the distribution obligations for the JBoss components that end up on a device.

Post by RUFFIN, MICHEL (MICHEL)
Food for thought

I think the points you are raising are excellent. They not only challenge the current way of thinking about the compliance problem, but also they provide opportunities to offer clarity to others on how SPDX can benefit them. I hope you can continue to provide food for thought that challenges the SPDX approach.

Regards,
- Mark


Technical Discussion: JBoss + SPDX
--------------------------------------------------------
SPDX data, if it exists, can be used together with a build system to obtain the correct level of licensing information. As I noted earlier, in the embedded space, platform packages are typically rummaged through, picked apart where often only a subset of files (or components) are actually used. Therefore a device vendor needs to only build the specific JBoss programs and libraries that will run on their device.
Let's assume:

? We have an SPDX file for each JBoss package or sub-package.

? The following components from various different JBoss packages have been selected to run on a device runtime:

- Source file SFile1 -> LGPL-2.1+

- Source file SFile2 -> GPL-2.0

- Library file LFile3 -> (MIT AND (LPGL-2.1 OR MPL-1.1))

- Library file LFile4 -> BSD-2-Clause

Programs that are built along the way include:

- Program file PFile5 is built (derived) by linking SFile1 and SFile2 -> (LGPL-2.1+ AND GPL-2.0)

- Program file PFile6 is built (derived) by linking SFile1 and LFile4 -> (LPGP-2.1+ AND BSD-2-Clause)

To generate the required licensing expressions for the distributed JBoss components one could:
1) load all SDPX files into a single central database (repository)
2) For each built program (e.g., PFile5 and PFile6), one could use the build system to find all file dependencies. We know that:
PFile5 is derived from SFile1 and SFile2; and
PFile6 is derived from SFile1 and LFile4
3) Query the SPDX repository to obtain the licensing for source files SFile1 and SFile2 and library LFile4 and then construct the license expressions for PFile5 and PFile6.
4) Constructing an SPDX file that covers the distributable JBoss components would be a straight forward task resulting in:

My JBoss Components SPDX 1.2 File (simplified)
=========================================
SFile1 Concluded License: LGPL-2.1+
SFile1 Concluded License: GPL-2.0
LFile4 Concluded License: BSD-2-Clause
PFile5 Concluded License: (LGPL-2.1+ AND GPL-2.0)
File Dependency: SFile1 <- new in SPDX 1.2
File Dependency: SFile2
PFile6 Concluded License: (LPGP-2.1+ AND BSD-2-Clause)
File Dependency: SFile1
File Dependency: LFile4

Library LFile3 was not included because it was not linked or include as one of the distributed components. The actual number of distributable components will likely be a small subset of all the components represented in the JBoss platform. SPDX 1.2 also allows one to include file dependency info. For example, in the case of program PFile5, because it is subjected to the GPL-2.0, it is useful to list the source files that must be given to the recipient of the PFile5 binary as a requirement of GPL-2.0.

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Tuesday, October 29, 2013 9:40 AM
To: Gisi, Mark
Cc: Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Subject: RE: Revisiting the SPDX license representation syntax (Package vs. Program license)

Mark,
I do not criticize the boolean system
I just want to point out that we are mostly dealing with package level system
If I take the example of JBoss in our FOSS DB you get the following (see below)

So the concluded license is just LGPL-2.1 AND(+) a lot of dependencies

Note that "Dual" in our DB: means OR (we are perhaps not totally compliant to the SPDX standard but revision of our DB entries will take times)
The thing in blue correspond to links to other FOSS in our DB or Licenses
This demonstrates also some of the actual limit of the SPDX standard. When an open source dependency has no link it means that it has been codified with a different name in our DB (because the links are done automatically by the Database).

Food for thoughts
Michel


[cid:image002.jpg at 01CED6CE.37825B20]


Michel.Ruffin at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131111/1c516878/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 230087 bytes
Desc: image001.jpg
URL: <Loading Image...>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 172593 bytes
Desc: image002.jpg
URL: <Loading Image...>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 229737 bytes
Desc: image003.jpg
URL: <Loading Image...>

[Gisi, Mark]

I already sent you the Jboss example which is a good one Here is Jboss 5.0.0

Merely providing a screen shot of an internal application doesn't describe the problem. What would be helpful to have, as we work on the next version of SPDX, would be:
1) a detailed description of the problem you are trying to highlight and
2) a link to an example software package.

Regards,
Mark


From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Monday, November 11, 2013 4:38 AM
To: Gisi, Mark
Cc: SPDX-legal; spdx-tech at lists.spdx.org
Subject: RE: JBoss Compliance SPDX support

I am not sure what is your request about, I already sent you the Jboss example which is a good one
Here is Jboss 5.0.0
[cid:image001.jpg at 01CEDF27.FAC16520]


Michel.Ruffin at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : lundi 4 novembre 2013 18:04
? : RUFFIN, MICHEL (MICHEL)
Cc : SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : RE: JBoss Compliance SPDX support

Michel,

Post by RUFFIN, MICHEL (MICHEL)
No: Now open sources are coming with an increasing set of dependencies

I agree. Can you select one example and send me the package to work through? It could serve as a useful SPDX tutorial.

Thanks,
- Mark


From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Friday, November 01, 2013 5:47 AM
To: Gisi, Mark
Cc: SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Subject: RE: JBoss Compliance SPDX support

Mark,
Yes and no is my answer
Yes Jboss can be considered as a platform
No: Now open sources are coming with an increasing set of dependencies
Look at spring, swan, perl (small snapshop of our foss DB on perl and there are a lot of web pages on perl), ...

Michel

[cid:image001.jpg at 01CED6CE.37825B20]


Michel.Ruffin at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

________________________________
De : Gisi, Mark [mailto:Mark.Gisi at windriver.com]
Envoy? : jeudi 31 octobre 2013 22:04
? : RUFFIN, MICHEL (MICHEL)
Cc : SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Objet : JBoss Compliance SPDX support

Michel,

Post by RUFFIN, MICHEL (MICHEL)
If I take the example of JBoss in our FOSS DB you get the following (see below)

It may be more helpful to view JBoss as a platform like Android or Linux rather than a utility like Busybox or GCC. JBoss, like Linux, does not represent one package, but instead a platform of packages. Therefore one would expect many dependencies (other packages). I would not recommend using a single monolithic SPDX file (let alone a single license identifier) to represent the licensing of an entire platform (e.g., Linux or Android). For instance, although many view Android to be distributed under the Apache-2.0 license, GPL-2.0 and various other licenses also apply.

Wind River currently delivers a large collection of SPDX files (800+) that represent the licensing of all the components of an entire Linux platform. I would recommend the same approach for JBoss. There are many packages in Linux that depend on other packages. Dependencies can be identified using the build system. I do not believe the problem here is an SPDX structural or technical deficiency; but rather simply the lack of SPDX data for JBoss packages. A build system + a repository of SPDX files = a compliance killer app.

I provided a more detailed technical discussion in the section below that describes how to use SPDX 1.2 together with a build system, to create the Boolean licensing expressions that represent the distribution obligations for the JBoss components that end up on a device.

Post by RUFFIN, MICHEL (MICHEL)
Food for thought

I think the points you are raising are excellent. They not only challenge the current way of thinking about the compliance problem, but also they provide opportunities to offer clarity to others on how SPDX can benefit them. I hope you can continue to provide food for thought that challenges the SPDX approach.

Regards,
- Mark


Technical Discussion: JBoss + SPDX
--------------------------------------------------------
SPDX data, if it exists, can be used together with a build system to obtain the correct level of licensing information. As I noted earlier, in the embedded space, platform packages are typically rummaged through, picked apart where often only a subset of files (or components) are actually used. Therefore a device vendor needs to only build the specific JBoss programs and libraries that will run on their device.
Let's assume:

? We have an SPDX file for each JBoss package or sub-package.

? The following components from various different JBoss packages have been selected to run on a device runtime:

- Source file SFile1 -> LGPL-2.1+

- Source file SFile2 -> GPL-2.0

- Library file LFile3 -> (MIT AND (LPGL-2.1 OR MPL-1.1))

- Library file LFile4 -> BSD-2-Clause

Programs that are built along the way include:

- Program file PFile5 is built (derived) by linking SFile1 and SFile2 -> (LGPL-2.1+ AND GPL-2.0)

- Program file PFile6 is built (derived) by linking SFile1 and LFile4 -> (LPGP-2.1+ AND BSD-2-Clause)

To generate the required licensing expressions for the distributed JBoss components one could:
1) load all SDPX files into a single central database (repository)
2) For each built program (e.g., PFile5 and PFile6), one could use the build system to find all file dependencies. We know that:
PFile5 is derived from SFile1 and SFile2; and
PFile6 is derived from SFile1 and LFile4
3) Query the SPDX repository to obtain the licensing for source files SFile1 and SFile2 and library LFile4 and then construct the license expressions for PFile5 and PFile6.
4) Constructing an SPDX file that covers the distributable JBoss components would be a straight forward task resulting in:

My JBoss Components SPDX 1.2 File (simplified)
=========================================
SFile1 Concluded License: LGPL-2.1+
SFile1 Concluded License: GPL-2.0
LFile4 Concluded License: BSD-2-Clause
PFile5 Concluded License: (LGPL-2.1+ AND GPL-2.0)
File Dependency: SFile1 <- new in SPDX 1.2
File Dependency: SFile2
PFile6 Concluded License: (LPGP-2.1+ AND BSD-2-Clause)
File Dependency: SFile1
File Dependency: LFile4

Library LFile3 was not included because it was not linked or include as one of the distributed components. The actual number of distributable components will likely be a small subset of all the components represented in the JBoss platform. SPDX 1.2 also allows one to include file dependency info. For example, in the case of program PFile5, because it is subjected to the GPL-2.0, it is useful to list the source files that must be given to the recipient of the PFile5 binary as a requirement of GPL-2.0.

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin at alcatel-lucent.com]
Sent: Tuesday, October 29, 2013 9:40 AM
To: Gisi, Mark
Cc: Tom Incorvia; SPDX-legal; spdx-tech at lists.spdx.org<mailto:spdx-tech at lists.spdx.org>
Subject: RE: Revisiting the SPDX license representation syntax (Package vs. Program license)

Mark,
I do not criticize the boolean system
I just want to point out that we are mostly dealing with package level system
If I take the example of JBoss in our FOSS DB you get the following (see below)

So the concluded license is just LGPL-2.1 AND(+) a lot of dependencies

Note that "Dual" in our DB: means OR (we are perhaps not totally compliant to the SPDX standard but revision of our DB entries will take times)
The thing in blue correspond to links to other FOSS in our DB or Licenses
This demonstrates also some of the actual limit of the SPDX standard. When an open source dependency has no link it means that it has been codified with a different name in our DB (because the links are done automatically by the Database).

Food for thoughts
Michel


[cid:image002.jpg at 01CED6CE.37825B20]


Michel.Ruffin at Alcatel-Lucent.com<mailto:Michel.Ruffin at Alcatel-Lucent.com>, PhD
Software Coordination Manager, N&P IS/IT
Distinguished Member of Technical Staff
Tel [phone]
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spdx.org/pipermail/spdx-legal/attachments/20131112/034793e3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 230087 bytes
Desc: image001.jpg
URL: <Loading Image...>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 172593 bytes
Desc: image002.jpg
URL: <Loading Image...>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 229737 bytes
Desc: image003.jpg
URL: <Loading Image...>

[Philippe Ombredanne]

Post by 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.

Let 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

[Gisi, Mark]

Hi Philippe,

Post by Gisi, Mark

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

This is the main thesis that is driving this breakout discussion.

Post by Gisi, Mark

I hope this helps fueling the discussion.

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.

Post by Gisi, Mark

* 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).

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

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 [phone] |?Fax?[phone]





-----Original Message-----
From: Philippe Ombredanne [mailto:pombredanne at nexb.com]
Sent: Thursday, October 24, 2013 3:39 AM
To: Gisi, Mark
Cc: SPDX-legal; spdx-tech at lists.spdx.org
Subject: Re: Revisiting the SPDX license representation syntax

Post by 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.

Let 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

[phone] | pombredanne at nexB.com
DejaCode Enterprise at http://www.dejacode.com | What's in your software? (sm) nexB Inc. at http://www.nexb.com

[Philippe Ombredanne]

Post by Gisi, Mark

* 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).

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.

Exactly!
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.

Post by Gisi, Mark
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).

Same, 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.

Post by Gisi, Mark
I hope we can encourage others to present situations they believe the current SPDX licensing mechanism does not easily support.

+1!
--
Philippe Ombredanne

[phone] | pombredanne at nexB.com
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 [phone].

[Wolfgang Denk]

Dear Philippe Ombredanne,

Post by Philippe Ombredanne
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).

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

Post by Philippe Ombredanne
* mit ? gpl-2.0 : a disjunctive license choice of mit or gpl-2.0.
A choice must be made. (CHOICE, EXCLUSIVE OR, DISJUNCTION)

In C and some other programming languages, the EXCLUSIVE OR operator
is '^', so please make this "mit ^ gpl-2.0".

Post by Philippe Ombredanne
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)

Please use a different operator t mark an exception, as '^' is kind of
reserved for XOR.

Thanks.

Best regards,

Wolfgang Denk

[Philippe Ombredanne]

Thanks - I mostly like this, but I would like to suggest a few minor
changes to make life easier especially to developers who are used to

Guten Tag Wolfgang!
and thanks for your feedback.

Post by Philippe Ombredanne
* mit ? gpl-2.0 : a disjunctive license choice of mit or gpl-2.0.
A choice must be made. (CHOICE, EXCLUSIVE OR, DISJUNCTION)

In C and some other programming languages, the EXCLUSIVE OR operator
is '^', so please make this "mit ^ gpl-2.0".

Post by Philippe Ombredanne
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)

Please use a different operator t mark an exception, as '^' is kind of
reserved for XOR.

You are absolutely right there and being a programmer I had hesitated
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.