Re: Call this Thursday!!
RUFFIN, MICHEL (MICHEL) <michel.ruffin@...>
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
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
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
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.
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 : spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] 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).
> -----Original Message-----
> From: spdx-legal-bounces@... [mailto:spdx-legal-
> bounces@...] 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 <opensource@...>
> > Hi all and Happy New Year!!
> > We will have our first call of 2015 this Thursday, same Bat-time,
> > 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:
> > OpenSSL, etc. raised by Sam Ellis)
> > Cheers,
> > Jilayne & Paul
> > SPDX Legal Team co-leads
> > _______________________________________________
> > Spdx-legal mailing list
> > Spdx-legal@...
> > https://lists.spdx.org/mailman/listinfo/spdx-legal
> Daniel M. German
> Spdx-legal mailing list
Spdx-legal mailing list
 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.
 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.
 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.
 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.
 For MPL-1.1, source code availability is only required for modifications (which is known as the “Distribute Changes” obligation).
 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.