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 <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] > On Jan 9, 2015, at 6:22 AM, RUFFIN, MICHEL (MICHEL) > <[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] > <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 > <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 > > > <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 > > <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 > <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
