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 | Advertise Changes | Don't Endorse Derivative | Distribute Changes |
MIT | x | | | | | | |
BSD-4-Clause | x | x | | | | x | |
BSD-3-Clause | x | | | | | x | |
Apache-1.1 | x | x | | | | x | |
Apache-2.0 | x | x | | | x | | |
MPL-1.1 | x | x | |
| x | | x |
EPL-1.0 | x | | | w | x | | x |
CPL-1.0 | x | | | w | x | | x |
CDDL-1.0 | x | x | | 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
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
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.
Gary
> -----Original Message-----
> 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.
>
> 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
> >
>
>
>
> --
> --dmg
>
> ---
> Daniel M. German
> _______________________________________________
> Spdx-legal mailing list
_______________________________________________
Spdx-legal mailing list
