Well my idea in answering this email is to put general names on clauses, For instance there are liability clauses in MPL, CDDL, and Apache2 if I am not mistaking. The conditions of these clauses are quite different from one license to another. So the interpretation might be left behind. But knowing that there is an acknowledgement, that license must be propagated, that the license contains the copyright or not allow to do a kind of classification of licenses which is usefull.
For instance when the copyright is in the license, you know that you have to propagate each copy of the license. While when it is copyright agnostic such as GPL of Apache2, you know that you need to propagate only one copy of the license. This give you already some rules to package the FOSS distribution, without real interpretation of clauses. Now the interpretation would be what means "propagate". How do you implement this. This is to each organization to determine this. For the synonymous issues, this might allow to simplify the tooling of things by adding an indirection. For instance GPL-2 WITH Bison Exception will points on two elements "GPl-2.0" and "bison exception" GPL-2.0-with-bison-exception the same. So this will disconnect the syntax from the semantic. And this allow different license which have GPL2 or bison exception to point to the same elements For BSD-4-clause will point to the "New BSD license" and to the "acknowledgement" Then with additional decomposition such as "initial copyright" (the one from Berkeley) and "customized copyright", you can more or less express the 4 BSD licenses. And then over time you can change the name of licenses by adding additional string of character to your tool Decomposition of licenses should really simplify the tooling and automatization of things. Because I am a afraid that if we do not adopt some system, in SPDX version 10 the synonyms might be difficult to manage. As someone said (I think it is Leslie Lamport but I am not sure) there is no issue in computer science that you cannot solve by adding a new level of indirection. Michel Michel [email protected], PhD Software Coordination Manager, COO - Business transformation Distinguished Member of Technical Staff Tel +33 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceau - France De : J Lovejoy [mailto:[email protected]] Envoyé : samedi 10 janvier 2015 21:32 À : RUFFIN, MICHEL (MICHEL) Cc : Gary O'Neall; Daniel M. German; SPDX-legal Objet : decomposition Hi Michel, Thanks for sharing this, it is quite interesting. This is a bit different, I think. from what Daniel is suggesting, though. I think Daniel is suggesting "synonyms" for license identification, especially in light of the change from the "old" SPDX License List, which is somewhat static to use of the new License Expression Syntax with the release of version 2.0. What you describe below, I'd consider more about analysis of the license, ultimately for compliance purposes. SPDX has always held the goal that we will not make legal interpretation as to what the licenses mean, but the goal of the SPDX License List is to provide a way to reliably and consistently identify licenses (no small task in and of itself!!). I think you're comment that lawyers will be reluctant is completely right - it is a lawyer's duty to identify risk and provide legal advice for the client and based on the client's risk appetite. We cannot (as a matter of professional responsibility) simply take someone else's legal analysis and interpretation and apply it without tailored consideration. However, your statement about the value of such information for the purpose of developing a common vocabulary and understanding in the company for basic license terms for none experts is critical and a task that many of us probably undertake with a fair amount of redundant work across different organizations. As such, I'd recommend joining and bringing these ideas to the OpenChain initiative (https://wiki.linuxfoundation.org/openchain/start), which has a broader scope and endeavors to address some of such redundant work. Thanks Jilayne SPDX Legal Team co-lead [email protected]<mailto:[email protected]> On Jan 9, 2015, at 6:22 AM, RUFFIN, MICHEL (MICHEL) <[email protected]<mailto:[email protected]>> wrote: Well I think the proper way to do this would be standardize a decomposition of license conditions. For example "acknowledgement" means that there is some acknowledgement to put in the documentation "Run time acknowledgement" means that it should be at run-time "Source code available" means that you must provide the source code of the FOSS "indeminify copyright owner", means that if you provide liability to your customer, you should extend it to the copyright owners under some circumstances Etc. We have made a decomposition in ALU to explain the content of major licenses without using legal terms, so anybody can understand what are the rights and obligations of the major licenses. Major licenses decomposition are available on our intranet for any ALU people. So for instance for GPL-2 <image001.png> The color code determine the level of difficulties to complies. The summaries contains what should be done before selecting an open source and what need to be done for packaging the FOSS with our products In our document that explain how to package FOSS in an ALU product we have a table License License Propagation Acknowledgement Run-Time Acknowledgement Source Code Availability[1]<x-msg://54/#_ftn1> Advertise Changes Don't Endorse Derivative Distribute Changes MIT x BSD-4-Clause x x[2]<x-msg://54/#_ftn2> x BSD-3-Clause x x Apache-1.1 x x x Apache-2.0 x x[3]<x-msg://54/#_ftn3> x MPL-1.1 x x[4]<x-msg://54/#_ftn4> [5]<x-msg://54/#_ftn5> x x EPL-1.0 x w x x CPL-1.0 x w x x CDDL-1.0 x x[6]<x-msg://54/#_ftn6> w x x LGPL-2.0 x z y x x LGPL-2.1 x z y x x LGPL-3.0 x z y x x GPL-2.0 x z y x x GPL-3.0 x z y x x AGPL-3.0 x z y x x Artistic x s x x s With this system you can say more or less that BSD-4-clause = BSD-3-Clause + acknowledgement (Don't endorse derivative is done by properly copyrighting changes which should be done in any case) We are now on a project in order to have a tool that will generate automatically the documentation of FOSS for ALU products. For this our internal FOSS database that describes IPR issues related information has for instance a text field which is the acknowledgement of the licenses, so the toll will have just to pick up this text and put it in the documentation. The ALU decomposition is not perfect and is old (I think I did it in 2006), but is still sufficient for our needs. It does not include things like classpath exception or Bison exception. They are more sophisticated ones such as the one done in the Blackduck tool protex and probably its competitors, which allow to automate the detection of potential conflicts between licenses. Now, I know that legal people might be a bit reluctant to this because nothing replace the legal terms. But this allow to develop a common vocabulary and understanding in the company on basic license terms for none experts. If SPDX is interested to investigate in this direction, I can do a presentation to provide more details, but not before end of January (my planning is heavy). And to be clear, I do not want to standardize the ALU system which is a bit archaic and probably need some improvement but it could be good base to start discussions. Because it took me a lot of thinking before doing this decomposition. It is complex because there is a trade-off in what legal details we ignore and what is the minimum common to most licenses. Michel [email protected]<mailto:[email protected]>, PhD Software Coordination Manager, COO - Business transformation Distinguished Member of Technical Staff Tel +33 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceau - France -----Message d'origine----- De : [email protected]<mailto:[email protected]> [mailto:[email protected]] De la part de Gary O'Neall Envoyé : jeudi 8 janvier 2015 20:29 À : 'dmg'; 'J Lovejoy' Cc : 'SPDX-legal' Objet : RE: Call this Thursday!! I like the idea of having synonyms - it will help when we compare SPDX documents to determine that two licenses are really the same. I have a few questions and suggestions: - Would the range be any SPDX expression? - I would suggest a different term - maybe equivalent licenses. Synonyms imply two names for the same subject or object. I think this is more of a relationship between a license and an expression. - It would be great to have this be machine paresable so that the tooling could understand it. For this to work, we would need to introduce another term in the standard to hold the information. I would propose this would be a release 2.1 candidate feature. - Before the new term is implemented, we could record this information in the notes for a given license. - If we wanted to state that 2 SPDX 2.0 licenses are really the same, we could add other web pages for this licenses that refer to the correct SPDX license (e.g. http://spdx.org/licenses/preview/StandardML-NJ). Gary > -----Original Message----- > From: > [email protected]<mailto:[email protected]> > [mailto:spdx-legal- > [email protected]<mailto:[email protected]>] On Behalf Of dmg > Sent: Thursday, January 8, 2015 10:47 AM > To: J Lovejoy > Cc: SPDX-legal > Subject: Re: Call this Thursday!! > > The idea is that each license has a name. > > Then some licenses might have synonyms. > > The old GPLv2 WITH Bison Exception is now known as the GPL-2 WITH > Bison Exception. The old name was GPL-2.0-with-bison-exception which > is deprecated. > > What I am suggesting is that the name: > > GPL-2.0-with-bison-exception = GPL-2 WITH Bison Exception > > this way the old name is not deprecated, it is just a synonym of the > GPL-2 WITH Bison Exception. So people can continue to use > GPL-2.0-with- bison-exception > > synonyms could also have an approval process the same as licenses. > > On Tue, Jan 6, 2015 at 9:14 PM, J Lovejoy > <[email protected]<mailto:[email protected]>> > wrote: > > Hi all and Happy New Year!! > > > > We will have our first call of 2015 this Thursday, same Bat-time, > same > > Bat-channel. That is, 11am Mtn Time / 1pm Eastern Time at the > > following > > dial-in: > > +1-857-216-2871 > > User PIN: 38633 > > > > I just sent out an invite for this week only. Will get a recurring > > invite out soon. > > > > On the agenda will be: > > > > 1) quick update on Collab Summit > > > > 2) SPDX License List 2.0 - release candidate update!! > > > > 3) compound licenses (see various discussion on email list re: > Python, > > OpenSSL, etc. raised by Sam Ellis) > > > > Cheers, > > Jilayne & Paul > > SPDX Legal Team co-leads > > > > > > > > > > _______________________________________________ > > Spdx-legal mailing list > > [email protected]<mailto:[email protected]> > > https://lists.spdx.org/mailman/listinfo/spdx-legal > > > > > > -- > --dmg > > --- > Daniel M. German > http://turingmachine.org<http://turingmachine.org/> > _______________________________________________ > Spdx-legal mailing list > [email protected]<mailto:[email protected]> > https://lists.spdx.org/mailman/listinfo/spdx-legal _______________________________________________ Spdx-legal mailing list [email protected]<mailto:[email protected]> https://lists.spdx.org/mailman/listinfo/spdx-legal ________________________________ [1]<x-msg://54/#_ftnref1> Note that source code availability also includes source code and all makefiles, scripts, applicable binaries and instructions in order to be able to re-build the binary. [2]<x-msg://54/#_ftnref2> Note that the run-time software is an option in some licenses (BSD-4-Clause, Apache-1.1, and Apache-2.0) as a place where the Acknowledgement can be done. [3]<x-msg://54/#_ftnref3> Note that Apache-2.0 actually asked for the propagation of all Notices. In this table we are considering this as a form of Acknowledgement for simplicity sake. [4]<x-msg://54/#_ftnref4> Note that in MPL-1.1, acknowledgement is required in the case of modification. See section 3.3 of the license. Also section 3.5 of the license requires the notice in Exhibit A of the license be put in each source code file or in a relevant directory. [5]<x-msg://54/#_ftnref5> For MPL-1.1, source code availability is only required for modifications (which is known as the "Distribute Changes" obligation). [6]<x-msg://54/#_ftnref6> Note that in CDDL, acknowledgement is the act of not removing any attributions that are already in the code. See section 3.3 of the license.
_______________________________________________ Spdx-legal mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-legal
