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

Hi Michel,

Thanks for sharing your experiences.  I agree these are worthy topics. I have had a number of similar conversations with Wind River customers through the years. Although these topics can be discussed in parallel, I agree with Tom in that we can’t move much faster (or further) until we repair the foundation from which these concepts are built upon. Before we can begin discussing common agreed upon obligations (semantics), we need to first accurately represent the licensing terms of source files, libraries and programs (syntactically). For example, consider program X, having the following Boolean license expression:

         (GPL-2.0 AND BSD-3-Clause)

Program X was built (derived) by integrating a GPL-2.0 licensed file with a BSD-3-Clause licensed file. Some organizations may interpret this one way (e.g., only GPL-2.0 terms matters); while other organizations may interpret it another way (e.g., both GPL-2.0 and BSD-3-Clause terms need to be considered).  The elegance of the Boolean expression  approach is it allows one to represent the licensing terms based on the files it was derived from, *independent* of a given organization’s interpretation (i.e., semantics).  The irony of the situation is - I could work for one organization, which would require me to make one interpretation, and then a year later I go work for another organization, which would require me to make a different interpretation for the same expression.

One could argue – it is important to come together as a community to reach common interpretations of license obligations. My response would be – yes, I agree but let’s first start with a generally accepted “neutral” syntax as the foundation of that discussion. I do feel a sense of urgency to flush out a correct syntax so that we can move on to some of the topics you have highlighted. I do believe SPDX’s approach is close, it may just require a few adjustments and a formal write up. This will ultimately be determined by the collective thinking of the working group. I hope you can join the discussion.

Thanks,

- Mark

Mark Gisi | Wind River | Senior Intellectual Property Manager

Tel (510) 749-2016 | Fax (510) 749-4552

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

Direct: (512) 340-1336

M: (215) 500 8838 [**NEW** as of Oct 2013]

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

In the last SPDX Legal meeting we discussed whether the current SPDX license representation syntax is sufficient to represent the licensing terms of most files (e.g., source, library and binary programs). For example, is the combination of the SPDX license list + current binary operands (AND and OR) sufficient to describe the licensing of most programs derived from multiple source and library files, where each is potentially under a different license.

We decided to hold a break out session dedicated to discussing this topic in greater depth. Initially special consideration will be given to representing files that have licenses with special exceptions and programs derived from files licensed under multiple different licenses. Keep in mind, given the high degree to which sharing occurs in the community, composite licensing has become the norm rather than the expectation. This is a good thing – we just need to make sure SPDX can accommodate it.

I will be organizing the break session. If you are interested in participating send me i) your email, ii) a brief description of your interest, and iii) days/times that work best for you. I will try to select a meeting time to accommodate the most participants.

Best,

- Mark

Mark Gisi | Wind River | Senior Intellectual Property Manager

Tel (510) 749-2016 | Fax (510) 749-455

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

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