"Scope" of licenses to be covered by SPDX


Michael J Herzog <mjherzog@...>
 

Michel and Soeren,

The scope of SPDX is to convey information about any kind of software license: open source, "free proprietary" like Sun/Oracle BCL or Oracle OTN, and other proprietary/ commercial.  You cannot  provide a complete Bill of Materials for a software package or product without a way to report the license for every component (at some appropriate level of detail).

The scope of the License List is, however, necessarily a subset of  licenses for many reasons.  The current focus of the License List is to identify the most common Open Source licenses and to develop techniques for dealing with close variants of BSD, MIT, Apache and similar licenses (the latter techniques are referred to as "templatization" in the current Legal Team discussions).  I personally think that we should add the most common "free proprietary" licenses to the License List, but to the best of my knowledge that is an open item for future/continued discussion.

Regards, Michael
Michael J. Herzog

+1 650 380 0680 | mjherzog_at_nexB.com
DejaCode Enterprise http://www.dejacode.com
nexB Inc. at http://www.nexb.com

CONFIDENTIALITY NOTICE:  This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680.
On 6/22/2012 7:35 AM, Steve Cropper (stcroppe) wrote:

Feels like this should go to spdx-legal@... and the Subject line should change to indicate the change of subject ?

Steve

From: <RUFFIN>, "MICHEL (MICHEL)" <michel.ruffin@...>
Date: Friday, June 22, 2012 6:42 AM
To: "Soeren_Rabenstein@..." <Soeren_Rabenstein@...>, "jilayne.lovejoy@..." <jilayne.lovejoy@...>, "gary@..." <gary@...>, "peter.williams@..." <peter.williams@...>
Cc: "spdx-tech@..." <spdx-tech@...>, "spdx@..." <spdx@...>
Subject: RE: Import and export function of SPDX

Before answering this, we need to determine in which group/mailing list we need to discuss this subject, I do not want to bother people not interested by this. Can we continue with SPDX list should we create a different list? I would prefer this second option. Martin would it be possible to create a “FOSS governance process” mailing list in the framework of FOSSBazaar which I think would be the best solution

 

Now if you look at the ALU definition of FOSS your definition cover only a part of the i) definition, there are a lot of software coming with an open source like license which is not OSI compliant, for instance beerware license How do you cope with theses? The ii) (EULA licenses): Sun/oracle binary license, Oracle OTN licenses, google licenses, adobe licenses, … are a huge set of licenses. In a contractual context they need to be treated the same way. Please note we are not discussing here what is an open source (I know there are two major definitions, the FSF one with 4 freedoms and the OSI one with 10 criteria) but what we should put in contracts.

 

Michel

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Soeren_Rabenstein@... [mailto:Soeren_Rabenstein@...]
Envoyé : vendredi 22 juin 2012 15:03
À : RUFFIN, MICHEL (MICHEL); jilayne.lovejoy@...; gary@...; peter.williams@...
Cc : spdx-tech@...; spdx@...
Objet : AW: Import and export function of SPDX

 

Hello Michel and others

 

In our standard FOSS contract clauses (which I am willing to share too, once we determined that this (or ftf, or any other network) is the appropriate forum for it) the FOSS-definition is also rather broad, but exemplarily refers to the OSI approved licenses. The definition reads as follows:

 

“Free Open Source Software” or “FOSS” shall mean a copyrighted work that is licensed under any of the licenses listed under www.opensource.org/licenses or any similar open source, free software or community license  (“FOSS License”).

 

Btw: It seems I have been dropped from the list of persons allowed to post here (so not sure if this mail will even make it the mailing list). Can someone help on this?

 

 

Mit freundlichen Grüßen / Kind regards

 

Sören Rabenstein

 

____________________________________________________________

 

ASUS Computer GmbH

 

Sören Rabenstein, LL.M.
Legal Affairs Center
Harkortstr. 21-23, 40880 Ratingen
Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...
____________________________________________________________

 

 

 

Von: spdx-bounces@... [mailto:spdx-bounces@...] Im Auftrag von RUFFIN, MICHEL (MICHEL)
Gesendet: Freitag, 22. Juni 2012 13:23
An: Jilayne Lovejoy; Gary O'Neall; Peter Williams
Cc: spdx-tech@...; spdx@...
Betreff: RE: Import and export function of SPDX

 

For the definition of FOSS (free and/or open source software (free is for free of cost here)) that we provide it is of course in the context of a contract negotiation. It is everything that do not go through a procurement department, i.e. coming with an implicit license: a click to accept EULA, an OSI compliant license or similar, + shareware and of course public domain. This definition is now accepted without discussion by most of our suppliers because it is quite clear (we had a lot of revisions before coming to this definition). Note that we use this definition internally in ALU for our FOSS governance process.

 

A comment on licenses, what I find confusing in the SPDX standard is the numbering of BSD licenses for instance the BSD 4 clause is in fact the original BSD license and I would have call it BSD1. But that’s not very important. What is important is to stabilize this taxonomy because we cannot change every year the content of our FOSS database, our internal FOSs governance process documents (around 80 pages), our internal tutorials (170 slides), our requests to suppliers, an update of the knowledge of our FOSs experts, etc.

 

Michel.Ruffin@..., PhD

Software Coordination Manager, Bell Labs, Corporate CTO Dpt

Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94

Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620Nozay, France

 

 

-----Message d'origine-----
De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...]
Envoyé : vendredi 22 juin 2012 01:33
À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams
Cc : spdx-tech@...; spdx@...
Objet : Re: Import and export function of SPDX

 

(Apologies for falling off this exchange - had some other things come up

and am now getting caught up with various responses - lots of great

discussion, though!)

 

On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)"

<michel.ruffin@...> wrote:

 

>So far our FOSS clauses are not aligned on the SPDX standard (we are

>already happy when suppliers can comply to our requirements without too

>much discussion so we did not formalize things too much)

 

One thing I noticed immediately about your clauses is the definition of

FOSS - which is quite broad.  While I can understand why it might make

sense to use a broad definition for contracts, it includes some categories

of software (e.g. (ii) and (iii) in your definition) that other

people/parties might not consider "FOSS."  In terms of the SPDX License

List, for example, I believe (if memory serves) that we discussed to what

"kinds" of licenses should be included on the list and an argument against

including, what I would refer to as "freeware" licenses (usually under

some kind of click-through EULA that more resembles a more traditional,

restrictive IP license, than open source) should not be on the list.

I don't know if this definition's breadth would necessarily create a

conflict in practical reality or not, but thought I'd at least point it

out...

 

 

>What we request is the name of FOSS, the name of the license if it is OSI

>compliant, or a copy of the license if it is not, the nature of the FOSS:

>is it a library, a standalone software, an interpreter, ... in order to

>determine if there is some potential contamination as with GPL.

>Now we have already aligned our database on the SPDX taxonomy for naming

>licenses, we will soon ask our suppliers to align on this taxonomy. I

>have already prepared a document (in copy) to distribute to our suppliers

>and partners on SPDX.

 

Thanks for sharing this.  Really great to hear that you have adopted the

SPDX License List already.  I'm not sure if you or anyone from your team

is on the legal work group mailing list, but that may be helpful to stay

on top of issues/updates/discussion there.  (for example, a new version of

the license list was just uploaded this week :)

 

Jilayne

 

Jilayne Lovejoy |  Corporate Counsel

OpenLogic, Inc.

 

jlovejoy@...

<applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@...

>  |  720 240 4545

 

 

 

 

>-----Message d'origine-----

>De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...]

>Envoyé : mercredi 13 juin 2012 16:08

>À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams

>Cc : spdx-tech@...; spdx@...

>Objet : Re: Import and export function of SPDX

>Hi Michel,

>Thanks again for sharing your information.  In regards to your posting (to

>both this group and the FSF legal network) about the legal clauses, I have

>noticed this and apologize as well for not responding sooner (it's still

>in my inbox as a to-do item, sadly).  In any case, a couple thoughts.  It

>is my understanding from your previous email(s), that you'd like to see

>some kind of FOSS-related legal clause resource, is that correct?  At the

>moment, this is not within the scope of SPDX (albeit a great idea

>generally!).  This is probably something that could be discussed further

>in terms of something to consider tackling in the longer-term road map.

>More specifically, your "list of FOSS" clause (a)(ii), you require the

>name of the license, license text, and whether it is OSI certified or not.

> This is all information capture in the SPDX License List.  Do you have an

>internal list as well?  If so, it would be great to discuss aligning any

>licenses on your list for potential inclusion on the SPDX License List, if

>not already included there and otherwise coordinating.

>Cheers,

>Jilayne Lovejoy |  Corporate Counsel

>jlovejoy@...  |  720 240 4545

>Twitter @jilaynelovejoy

>OpenLogic, Inc.

>10910 W 120th Ave, Suite 450

>Broomfield, Colorado 80021

>www.openlogic.com

>Twitter @openlogic @cloudswing

>On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)"

><michel.ruffin@...> wrote:

>>Gary, I think in my previous mail I expressed our use case:

>>1) getting information from our suppliers on FOSS included in their

>>products in order to respect license obligations and to provide this to

>>our customers

>>2) automate the work of ALU for accepting this FOSS in our products

>>3) being able to provide the same information to our customers.

>> 

>>I think it is covered by actual use cases, if not I can do a new one.

>> 

>>Now I would like to attract your attention on a document that I sent few

>>months ago to this mailing list and also to the FSF legal network group.

>>Which are the clauses that we put in the contracts with our suppliers and

>>their rationnal. The goal is to standardize these clauses and I receive

>>no feedback from anybody on this.

>> 

>>This should illustrate the use case. And I understand that I should use

>>the FSF legal network to discuss this. But I am very surprised that there

>>is no reaction/interest in this. It has been a huge ALU effort to shape

>>these conditions in order to reach acceptance to these conditions by most

>>companies.

>> 

>>Michel.Ruffin@..., PhD

>>Software Coordination Manager, Bell Labs, Corporate CTO Dpt

>>Distinguished Member of Technical Staff

>>Tel +33 (0) 6 75 25 21 94

>>Alcatel-Lucent International, Centre de Villarceaux

>>Route De Villejust, 91620Nozay, France

>> 

>> 

>>-----Message d'origine-----

>>De : Gary O'Neall [mailto:gary@...]

>>Envoyé : mardi 12 juin 2012 19:29

>>À : 'Peter Williams'; RUFFIN, MICHEL (MICHEL)

>>Cc : spdx-tech@...; spdx@...

>>Objet : RE: Import and export function of SPDX

>> 

>>I believe the current SPDX tools will treat both RDF and Tag/Value in the

>>same manner - the documents will be readable by the tools but it will

>>fail a

>>validation (missing required field).  For the command line tools, the

>>conversions or pretty printing will still work but you will get warning.

>> 

>>In terms of making the fields optional - I can see this as a valuable

>>change

>>for some of the use cases where that information is not available.  There

>>is

>>need to make sure the components described in the SPDX file match the

>>actual

>>file artifacts, but that need can be filled by the per-file information.

>> 

>>Michel - Which use case best describes your use of SPDX

>>(http://spdx.org/wiki/spdx-20-use-cases).  If there isn't a good

>>representation of your use case(s), could you provide a brief

>>description?

>>I want to make sure we cover this when working on SPDX 2.0.

>> 

>>Thanks,

>>Gary

>> 

>>-----Original Message-----

>>From:spdx-tech-bounces@...

>>[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams

>>Sent: Tuesday, June 12, 2012 9:27 AM

>>To: RUFFIN, MICHEL (MICHEL)

>>Cc: spdx-tech@...; spdx@...

>>Subject: Re: Import and export function of SPDX

>> 

>>On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote:

>>> We have an issue with 2 fields that do not exist in our database.: the

>>> name of the archive file and the checksum. In the SPDX standard they

>>> are mandatory and I do not see why would it be possibly to make them

>>> optional?

>> 

>>I think making those fields optional would be advantageous. Would you

>>mind

>>filing a bug[1] so that we don't forget to look into the issue for the

>>next

>>version.

>> 

>>As for your immediate issues of not having data for those fields, if you

>>are

>>using RDF i'd just skip them altogether in the SPDX file. While your file

>>will technically be invalid all reasonable SPDX consumers will not have a

>>problem with that information being absent unless they need it to

>>accomplish

>>their goal. (In which case they cannot use your SPDX files, anyway.) If

>>you

>>are using the tag-value format skipping the fields altogether will, i

>>think,

>>prove problematic due to that format's stricter syntactic constraints.

>>(Kate

>>or Gary, can you confirm this?)

>> 

>>[1]:

>>https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spe

>>c

>> 

>>Peter

>> 

>>PS: I am cc-ing the technical working group because it's participants are

>>best suited to answer these sorts of issues.

>> 

>>_______________________________________________

>>Spdx-tech mailing list

>>Spdx-tech@...

>>https://lists.spdx.org/mailman/listinfo/spdx-tech

>> 

>> 

 

 



_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx



RUFFIN MICHEL
 

Michael, for me it is not a subject of discussion

 

I am discussing with third party companies since 10 years on the subject and if you ignore open-source like license or “free proprietary” license, the discussion is void. OSI compliant licenses are a part of the pb and they are not too much a pb because we understand them other licenses are much more problems.

 

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Michael J Herzog [mailto:mjherzog@...]
Envoyé : vendredi 22 juin 2012 18:02
À : spdx@...; RUFFIN, MICHEL (MICHEL); Soeren Rabenstein
Objet : "Scope" of licenses to be covered by SPDX

 

Michel and Soeren,

The scope of SPDX is to convey information about any kind of software license: open source, "free proprietary" like Sun/Oracle BCL or Oracle OTN, and other proprietary/ commercial.  You cannot  provide a complete Bill of Materials for a software package or product without a way to report the license for every component (at some appropriate level of detail).

The scope of the License List is, however, necessarily a subset of  licenses for many reasons.  The current focus of the License List is to identify the most common Open Source licenses and to develop techniques for dealing with close variants of BSD, MIT, Apache and similar licenses (the latter techniques are referred to as "templatization" in the current Legal Team discussions).  I personally think that we should add the most common "free proprietary" licenses to the License List, but to the best of my knowledge that is an open item for future/continued discussion.

Regards, Michael

Michael J. Herzog
 
+1 650 380 0680 | mjherzog_at_nexB.com
DejaCode Enterprise http://www.dejacode.com
nexB Inc. at http://www.nexb.com
 
CONFIDENTIALITY NOTICE:  This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680.

On 6/22/2012 7:35 AM, Steve Cropper (stcroppe) wrote:

Feels like this should go to spdx-legal@... and the Subject line should change to indicate the change of subject ?

 

Steve

 

From: <RUFFIN>, "MICHEL (MICHEL)" <michel.ruffin@...>
Date: Friday, June 22, 2012 6:42 AM
To: "Soeren_Rabenstein@..." <Soeren_Rabenstein@...>, "jilayne.lovejoy@..." <jilayne.lovejoy@...>, "gary@..." <gary@...>, "peter.williams@..." <peter.williams@...>
Cc: "spdx-tech@..." <spdx-tech@...>, "spdx@..." <spdx@...>
Subject: RE: Import and export function of SPDX

 

Before answering this, we need to determine in which group/mailing list we need to discuss this subject, I do not want to bother people not interested by this. Can we continue with SPDX list should we create a different list? I would prefer this second option. Martin would it be possible to create a “FOSS governance process” mailing list in the framework of FOSSBazaar which I think would be the best solution

 

Now if you look at the ALU definition of FOSS your definition cover only a part of the i) definition, there are a lot of software coming with an open source like license which is not OSI compliant, for instance beerware license How do you cope with theses? The ii) (EULA licenses): Sun/oracle binary license, Oracle OTN licenses, google licenses, adobe licenses, … are a huge set of licenses. In a contractual context they need to be treated the same way. Please note we are not discussing here what is an open source (I know there are two major definitions, the FSF one with 4 freedoms and the OSI one with 10 criteria) but what we should put in contracts.

 

Michel

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Soeren_Rabenstein@... [mailto:Soeren_Rabenstein@...]
Envoyé : vendredi 22 juin 2012 15:03
À : RUFFIN, MICHEL (MICHEL); jilayne.lovejoy@...; gary@...; peter.williams@...
Cc : spdx-tech@...; spdx@...
Objet : AW: Import and export function of SPDX

 

Hello Michel and others

 

In our standard FOSS contract clauses (which I am willing to share too, once we determined that this (or ftf, or any other network) is the appropriate forum for it) the FOSS-definition is also rather broad, but exemplarily refers to the OSI approved licenses. The definition reads as follows:

 

“Free Open Source Software” or “FOSS” shall mean a copyrighted work that is licensed under any of the licenses listed under www.opensource.org/licenses or any similar open source, free software or community license  (“FOSS License”).

 

Btw: It seems I have been dropped from the list of persons allowed to post here (so not sure if this mail will even make it the mailing list). Can someone help on this?

 

 

Mit freundlichen Grüßen / Kind regards

 

Sören Rabenstein

 

____________________________________________________________

 

ASUS Computer GmbH

 

Sören Rabenstein, LL.M.
Legal Affairs Center
Harkortstr. 21-23, 40880 Ratingen
Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...
____________________________________________________________

 

 

 

Von: spdx-bounces@... [mailto:spdx-bounces@...] Im Auftrag von RUFFIN, MICHEL (MICHEL)
Gesendet: Freitag, 22. Juni 2012 13:23
An: Jilayne Lovejoy; Gary O'Neall; Peter Williams
Cc: spdx-tech@...; spdx@...
Betreff: RE: Import and export function of SPDX

 

For the definition of FOSS (free and/or open source software (free is for free of cost here)) that we provide it is of course in the context of a contract negotiation. It is everything that do not go through a procurement department, i.e. coming with an implicit license: a click to accept EULA, an OSI compliant license or similar, + shareware and of course public domain. This definition is now accepted without discussion by most of our suppliers because it is quite clear (we had a lot of revisions before coming to this definition). Note that we use this definition internally in ALU for our FOSS governance process.

 

A comment on licenses, what I find confusing in the SPDX standard is the numbering of BSD licenses for instance the BSD 4 clause is in fact the original BSD license and I would have call it BSD1. But that’s not very important. What is important is to stabilize this taxonomy because we cannot change every year the content of our FOSS database, our internal FOSs governance process documents (around 80 pages), our internal tutorials (170 slides), our requests to suppliers, an update of the knowledge of our FOSs experts, etc.

 

Michel.Ruffin@..., PhD

Software Coordination Manager, Bell Labs, Corporate CTO Dpt

Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94

Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620Nozay, France

 

 

-----Message d'origine-----
De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...]
Envoyé : vendredi 22 juin 2012 01:33
À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams
Cc : spdx-tech@...; spdx@...
Objet : Re: Import and export function of SPDX

 

(Apologies for falling off this exchange - had some other things come up

and am now getting caught up with various responses - lots of great

discussion, though!)

 

On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)"

<michel.ruffin@...> wrote:

 

>So far our FOSS clauses are not aligned on the SPDX standard (we are

>already happy when suppliers can comply to our requirements without too

>much discussion so we did not formalize things too much)

 

One thing I noticed immediately about your clauses is the definition of

FOSS - which is quite broad.  While I can understand why it might make

sense to use a broad definition for contracts, it includes some categories

of software (e.g. (ii) and (iii) in your definition) that other

people/parties might not consider "FOSS."  In terms of the SPDX License

List, for example, I believe (if memory serves) that we discussed to what

"kinds" of licenses should be included on the list and an argument against

including, what I would refer to as "freeware" licenses (usually under

some kind of click-through EULA that more resembles a more traditional,

restrictive IP license, than open source) should not be on the list.

I don't know if this definition's breadth would necessarily create a

conflict in practical reality or not, but thought I'd at least point it

out...

 

 

>What we request is the name of FOSS, the name of the license if it is OSI

>compliant, or a copy of the license if it is not, the nature of the FOSS:

>is it a library, a standalone software, an interpreter, ... in order to

>determine if there is some potential contamination as with GPL.

>Now we have already aligned our database on the SPDX taxonomy for naming

>licenses, we will soon ask our suppliers to align on this taxonomy. I

>have already prepared a document (in copy) to distribute to our suppliers

>and partners on SPDX.

 

Thanks for sharing this.  Really great to hear that you have adopted the

SPDX License List already.  I'm not sure if you or anyone from your team

is on the legal work group mailing list, but that may be helpful to stay

on top of issues/updates/discussion there.  (for example, a new version of

the license list was just uploaded this week :)

 

Jilayne

 

Jilayne Lovejoy |  Corporate Counsel

OpenLogic, Inc.

 

jlovejoy@...

<applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@...

>  |  720 240 4545

 

 

 

 

>-----Message d'origine-----

>De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...]

>Envoyé : mercredi 13 juin 2012 16:08

>À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams

>Cc : spdx-tech@...; spdx@...

>Objet : Re: Import and export function of SPDX

>Hi Michel,

>Thanks again for sharing your information.  In regards to your posting (to

>both this group and the FSF legal network) about the legal clauses, I have

>noticed this and apologize as well for not responding sooner (it's still

>in my inbox as a to-do item, sadly).  In any case, a couple thoughts.  It

>is my understanding from your previous email(s), that you'd like to see

>some kind of FOSS-related legal clause resource, is that correct?  At the

>moment, this is not within the scope of SPDX (albeit a great idea

>generally!).  This is probably something that could be discussed further

>in terms of something to consider tackling in the longer-term road map.

>More specifically, your "list of FOSS" clause (a)(ii), you require the

>name of the license, license text, and whether it is OSI certified or not.

> This is all information capture in the SPDX License List.  Do you have an

>internal list as well?  If so, it would be great to discuss aligning any

>licenses on your list for potential inclusion on the SPDX License List, if

>not already included there and otherwise coordinating.

>Cheers,

>Jilayne Lovejoy |  Corporate Counsel

>jlovejoy@...  |  720 240 4545

>Twitter @jilaynelovejoy

>OpenLogic, Inc.

>10910 W 120th Ave, Suite 450

>Broomfield, Colorado 80021

>www.openlogic.com

>Twitter @openlogic @cloudswing

>On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)"

><michel.ruffin@...> wrote:

>>Gary, I think in my previous mail I expressed our use case:

>>1) getting information from our suppliers on FOSS included in their

>>products in order to respect license obligations and to provide this to

>>our customers

>>2) automate the work of ALU for accepting this FOSS in our products

>>3) being able to provide the same information to our customers.

>> 

>>I think it is covered by actual use cases, if not I can do a new one.

>> 

>>Now I would like to attract your attention on a document that I sent few

>>months ago to this mailing list and also to the FSF legal network group.

>>Which are the clauses that we put in the contracts with our suppliers and

>>their rationnal. The goal is to standardize these clauses and I receive

>>no feedback from anybody on this.

>> 

>>This should illustrate the use case. And I understand that I should use

>>the FSF legal network to discuss this. But I am very surprised that there

>>is no reaction/interest in this. It has been a huge ALU effort to shape

>>these conditions in order to reach acceptance to these conditions by most

>>companies.

>> 

>>Michel.Ruffin@..., PhD

>>Software Coordination Manager, Bell Labs, Corporate CTO Dpt

>>Distinguished Member of Technical Staff

>>Tel +33 (0) 6 75 25 21 94

>>Alcatel-Lucent International, Centre de Villarceaux

>>Route De Villejust, 91620Nozay, France

>> 

>> 

>>-----Message d'origine-----

>>De : Gary O'Neall [mailto:gary@...]

>>Envoyé : mardi 12 juin 2012 19:29

>>À : 'Peter Williams'; RUFFIN, MICHEL (MICHEL)

>>Cc : spdx-tech@...; spdx@...

>>Objet : RE: Import and export function of SPDX

>> 

>>I believe the current SPDX tools will treat both RDF and Tag/Value in the

>>same manner - the documents will be readable by the tools but it will

>>fail a

>>validation (missing required field).  For the command line tools, the

>>conversions or pretty printing will still work but you will get warning.

>> 

>>In terms of making the fields optional - I can see this as a valuable

>>change

>>for some of the use cases where that information is not available.  There

>>is

>>need to make sure the components described in the SPDX file match the

>>actual

>>file artifacts, but that need can be filled by the per-file information.

>> 

>>Michel - Which use case best describes your use of SPDX

>>(http://spdx.org/wiki/spdx-20-use-cases).  If there isn't a good

>>representation of your use case(s), could you provide a brief

>>description?

>>I want to make sure we cover this when working on SPDX 2.0.

>> 

>>Thanks,

>>Gary

>> 

>>-----Original Message-----

>>From:spdx-tech-bounces@...

>>[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams

>>Sent: Tuesday, June 12, 2012 9:27 AM

>>To: RUFFIN, MICHEL (MICHEL)

>>Cc: spdx-tech@...; spdx@...

>>Subject: Re: Import and export function of SPDX

>> 

>>On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote:

>>> We have an issue with 2 fields that do not exist in our database.: the

>>> name of the archive file and the checksum. In the SPDX standard they

>>> are mandatory and I do not see why would it be possibly to make them

>>> optional?

>> 

>>I think making those fields optional would be advantageous. Would you

>>mind

>>filing a bug[1] so that we don't forget to look into the issue for the

>>next

>>version.

>> 

>>As for your immediate issues of not having data for those fields, if you

>>are

>>using RDF i'd just skip them altogether in the SPDX file. While your file

>>will technically be invalid all reasonable SPDX consumers will not have a

>>problem with that information being absent unless they need it to

>>accomplish

>>their goal. (In which case they cannot use your SPDX files, anyway.) If

>>you

>>are using the tag-value format skipping the fields altogether will, i

>>think,

>>prove problematic due to that format's stricter syntactic constraints.

>>(Kate

>>or Gary, can you confirm this?)

>> 

>>[1]:

>>https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spe

>>c

>> 

>>Peter

>> 

>>PS: I am cc-ing the technical working group because it's participants are

>>best suited to answer these sorts of issues.

>> 

>>_______________________________________________

>>Spdx-tech mailing list

>>Spdx-tech@...

>>https://lists.spdx.org/mailman/listinfo/spdx-tech

>> 

>> 

 

 




_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx

 


Soeren_Rabenstein@...
 

Dear Michael

 

The topic we are having here (but will probably move to another forum, potentially the LF Open compliance Program) is to create industry wide accepted common contract clauses for supply contracts that involve FOSS. The purpose of such clauses are, amongst others, to clearly separate the proprietary licenses (which are often included in such supply contracts) from the FOSS licenses, have suppliers take responsibility for their own FOSS license compliance, and generally raise awareness for FOSS license compliance.

Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.

 

Cheers

Sören

 

 

Von: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Gesendet: Freitag, 22. Juni 2012 18:14
An: mjherzog@...; spdx@...; Soeren Rabenstein (ACG)
Betreff: RE: "Scope" of licenses to be covered by SPDX

 

Michael, for me it is not a subject of discussion

 

I am discussing with third party companies since 10 years on the subject and if you ignore open-source like license or “free proprietary” license, the discussion is void. OSI compliant licenses are a part of the pb and they are not too much a pb because we understand them other licenses are much more problems.

 

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Michael J Herzog [mailto:mjherzog@...]
Envoyé : vendredi 22 juin 2012 18:02
À : spdx@...; RUFFIN, MICHEL (MICHEL); Soeren Rabenstein
Objet : "Scope" of licenses to be covered by SPDX

 

Michel and Soeren,

The scope of SPDX is to convey information about any kind of software license: open source, "free proprietary" like Sun/Oracle BCL or Oracle OTN, and other proprietary/ commercial.  You cannot  provide a complete Bill of Materials for a software package or product without a way to report the license for every component (at some appropriate level of detail).

The scope of the License List is, however, necessarily a subset of  licenses for many reasons.  The current focus of the License List is to identify the most common Open Source licenses and to develop techniques for dealing with close variants of BSD, MIT, Apache and similar licenses (the latter techniques are referred to as "templatization" in the current Legal Team discussions).  I personally think that we should add the most common "free proprietary" licenses to the License List, but to the best of my knowledge that is an open item for future/continued discussion.

Regards, Michael

Michael J. Herzog
 
+1 650 380 0680 | mjherzog_at_nexB.com
DejaCode Enterprise http://www.dejacode.com
nexB Inc. at http://www.nexb.com
 
CONFIDENTIALITY NOTICE:  This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680.

On 6/22/2012 7:35 AM, Steve Cropper (stcroppe) wrote:

Feels like this should go to spdx-legal@... and the Subject line should change to indicate the change of subject ?

 

Steve

 

From: <RUFFIN>, "MICHEL (MICHEL)" <michel.ruffin@...>
Date: Friday, June 22, 2012 6:42 AM
To: "Soeren_Rabenstein@..." <Soeren_Rabenstein@...>, "jilayne.lovejoy@..." <jilayne.lovejoy@...>, "gary@..." <gary@...>, "peter.williams@..." <peter.williams@...>
Cc: "spdx-tech@..." <spdx-tech@...>, "spdx@..." <spdx@...>
Subject: RE: Import and export function of SPDX

 

Before answering this, we need to determine in which group/mailing list we need to discuss this subject, I do not want to bother people not interested by this. Can we continue with SPDX list should we create a different list? I would prefer this second option. Martin would it be possible to create a “FOSS governance process” mailing list in the framework of FOSSBazaar which I think would be the best solution

 

Now if you look at the ALU definition of FOSS your definition cover only a part of the i) definition, there are a lot of software coming with an open source like license which is not OSI compliant, for instance beerware license How do you cope with theses? The ii) (EULA licenses): Sun/oracle binary license, Oracle OTN licenses, google licenses, adobe licenses, … are a huge set of licenses. In a contractual context they need to be treated the same way. Please note we are not discussing here what is an open source (I know there are two major definitions, the FSF one with 4 freedoms and the OSI one with 10 criteria) but what we should put in contracts.

 

Michel

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Soeren_Rabenstein@... [mailto:Soeren_Rabenstein@...]
Envoyé : vendredi 22 juin 2012 15:03
À : RUFFIN, MICHEL (MICHEL); jilayne.lovejoy@...; gary@...; peter.williams@...
Cc : spdx-tech@...;
spdx@...
Objet : AW: Import and export function of SPDX

 

Hello Michel and others

 

In our standard FOSS contract clauses (which I am willing to share too, once we determined that this (or ftf, or any other network) is the appropriate forum for it) the FOSS-definition is also rather broad, but exemplarily refers to the OSI approved licenses. The definition reads as follows:

 

“Free Open Source Software” or “FOSS” shall mean a copyrighted work that is licensed under any of the licenses listed under www.opensource.org/licenses or any similar open source, free software or community license  (“FOSS License”).

 

Btw: It seems I have been dropped from the list of persons allowed to post here (so not sure if this mail will even make it the mailing list). Can someone help on this?

 

 

Mit freundlichen Grüßen / Kind regards

 

Sören Rabenstein

 

____________________________________________________________

 

ASUS Computer GmbH

 

Sören Rabenstein, LL.M.
Legal Affairs Center
Harkortstr. 21-23, 40880
Ratingen
Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...
____________________________________________________________

 

 

 

Von: spdx-bounces@... [mailto:spdx-bounces@...] Im Auftrag von RUFFIN, MICHEL (MICHEL)
Gesendet: Freitag, 22. Juni 2012 13:23
An: Jilayne Lovejoy; Gary O'Neall; Peter Williams
Cc: spdx-tech@...;
spdx@...
Betreff: RE: Import and export function of SPDX

 

For the definition of FOSS (free and/or open source software (free is for free of cost here)) that we provide it is of course in the context of a contract negotiation. It is everything that do not go through a procurement department, i.e. coming with an implicit license: a click to accept EULA, an OSI compliant license or similar, + shareware and of course public domain. This definition is now accepted without discussion by most of our suppliers because it is quite clear (we had a lot of revisions before coming to this definition). Note that we use this definition internally in ALU for our FOSS governance process.

 

A comment on licenses, what I find confusing in the SPDX standard is the numbering of BSD licenses for instance the BSD 4 clause is in fact the original BSD license and I would have call it BSD1. But that’s not very important. What is important is to stabilize this taxonomy because we cannot change every year the content of our FOSS database, our internal FOSs governance process documents (around 80 pages), our internal tutorials (170 slides), our requests to suppliers, an update of the knowledge of our FOSs experts, etc.

 

Michel.Ruffin@..., PhD

Software Coordination Manager, Bell Labs, Corporate CTO Dpt

Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94

Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620Nozay, France

 

 

-----Message d'origine-----
De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...]
Envoyé : vendredi 22 juin 2012 01:33
À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams
Cc : spdx-tech@...; spdx@...
Objet : Re: Import and export function of SPDX

 

(Apologies for falling off this exchange - had some other things come up

and am now getting caught up with various responses - lots of great

discussion, though!)

 

On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)"

<michel.ruffin@...> wrote:

 

>So far our FOSS clauses are not aligned on the SPDX standard (we are

>already happy when suppliers can comply to our requirements without too

>much discussion so we did not formalize things too much)

 

One thing I noticed immediately about your clauses is the definition of

FOSS - which is quite broad.  While I can understand why it might make

sense to use a broad definition for contracts, it includes some categories

of software (e.g. (ii) and (iii) in your definition) that other

people/parties might not consider "FOSS."  In terms of the SPDX License

List, for example, I believe (if memory serves) that we discussed to what

"kinds" of licenses should be included on the list and an argument against

including, what I would refer to as "freeware" licenses (usually under

some kind of click-through EULA that more resembles a more traditional,

restrictive IP license, than open source) should not be on the list.

I don't know if this definition's breadth would necessarily create a

conflict in practical reality or not, but thought I'd at least point it

out...

 

 

>What we request is the name of FOSS, the name of the license if it is OSI

>compliant, or a copy of the license if it is not, the nature of the FOSS:

>is it a library, a standalone software, an interpreter, ... in order to

>determine if there is some potential contamination as with GPL.

>Now we have already aligned our database on the SPDX taxonomy for naming

>licenses, we will soon ask our suppliers to align on this taxonomy. I

>have already prepared a document (in copy) to distribute to our suppliers

>and partners on SPDX.

 

Thanks for sharing this.  Really great to hear that you have adopted the

SPDX License List already.  I'm not sure if you or anyone from your team

is on the legal work group mailing list, but that may be helpful to stay

on top of issues/updates/discussion there.  (for example, a new version of

the license list was just uploaded this week :)

 

Jilayne

 

Jilayne Lovejoy |  Corporate Counsel

OpenLogic, Inc.

 

jlovejoy@...

<applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@...

>  |  720 240 4545

 

 

 

 

>-----Message d'origine-----

>De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...]

>Envoyé : mercredi 13 juin 2012 16:08

>À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams

>Cc : spdx-tech@...; spdx@...

>Objet : Re: Import and export function of SPDX

>Hi Michel,

>Thanks again for sharing your information.  In regards to your posting (to

>both this group and the FSF legal network) about the legal clauses, I have

>noticed this and apologize as well for not responding sooner (it's still

>in my inbox as a to-do item, sadly).  In any case, a couple thoughts.  It

>is my understanding from your previous email(s), that you'd like to see

>some kind of FOSS-related legal clause resource, is that correct?  At the

>moment, this is not within the scope of SPDX (albeit a great idea

>generally!).  This is probably something that could be discussed further

>in terms of something to consider tackling in the longer-term road map.

>More specifically, your "list of FOSS" clause (a)(ii), you require the

>name of the license, license text, and whether it is OSI certified or not.

> This is all information capture in the SPDX License List.  Do you have an

>internal list as well?  If so, it would be great to discuss aligning any

>licenses on your list for potential inclusion on the SPDX License List, if

>not already included there and otherwise coordinating.

>Cheers,

>Jilayne Lovejoy |  Corporate Counsel

>jlovejoy@...  |  720 240 4545

>Twitter @jilaynelovejoy

>OpenLogic, Inc.

>10910 W 120th Ave, Suite 450

>Broomfield, Colorado 80021

>www.openlogic.com

>Twitter @openlogic @cloudswing

>On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)"

><michel.ruffin@...> wrote:

>>Gary, I think in my previous mail I expressed our use case:

>>1) getting information from our suppliers on FOSS included in their

>>products in order to respect license obligations and to provide this to

>>our customers

>>2) automate the work of ALU for accepting this FOSS in our products

>>3) being able to provide the same information to our customers.

>> 

>>I think it is covered by actual use cases, if not I can do a new one.

>> 

>>Now I would like to attract your attention on a document that I sent few

>>months ago to this mailing list and also to the FSF legal network group.

>>Which are the clauses that we put in the contracts with our suppliers and

>>their rationnal. The goal is to standardize these clauses and I receive

>>no feedback from anybody on this.

>> 

>>This should illustrate the use case. And I understand that I should use

>>the FSF legal network to discuss this. But I am very surprised that there

>>is no reaction/interest in this. It has been a huge ALU effort to shape

>>these conditions in order to reach acceptance to these conditions by most

>>companies.

>> 

>>Michel.Ruffin@..., PhD

>>Software Coordination Manager, Bell Labs, Corporate CTO Dpt

>>Distinguished Member of Technical Staff

>>Tel +33 (0) 6 75 25 21 94

>>Alcatel-Lucent International, Centre de Villarceaux

>>Route De Villejust, 91620Nozay, France

>> 

>> 

>>-----Message d'origine-----

>>De : Gary O'Neall [mailto:gary@...]

>>Envoyé : mardi 12 juin 2012 19:29

>>À : 'Peter Williams'; RUFFIN, MICHEL (MICHEL)

>>Cc : spdx-tech@...; spdx@...

>>Objet : RE: Import and export function of SPDX

>> 

>>I believe the current SPDX tools will treat both RDF and Tag/Value in the

>>same manner - the documents will be readable by the tools but it will

>>fail a

>>validation (missing required field).  For the command line tools, the

>>conversions or pretty printing will still work but you will get warning.

>> 

>>In terms of making the fields optional - I can see this as a valuable

>>change

>>for some of the use cases where that information is not available.  There

>>is

>>need to make sure the components described in the SPDX file match the

>>actual

>>file artifacts, but that need can be filled by the per-file information.

>> 

>>Michel - Which use case best describes your use of SPDX

>>(http://spdx.org/wiki/spdx-20-use-cases).  If there isn't a good

>>representation of your use case(s), could you provide a brief

>>description?

>>I want to make sure we cover this when working on SPDX 2.0.

>> 

>>Thanks,

>>Gary

>> 

>>-----Original Message-----

>>From:spdx-tech-bounces@...

>>[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams

>>Sent: Tuesday, June 12, 2012 9:27 AM

>>To: RUFFIN, MICHEL (MICHEL)

>>Cc: spdx-tech@...; spdx@...

>>Subject: Re: Import and export function of SPDX

>> 

>>On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote:

>>> We have an issue with 2 fields that do not exist in our database.: the

>>> name of the archive file and the checksum. In the SPDX standard they

>>> are mandatory and I do not see why would it be possibly to make them

>>> optional?

>> 

>>I think making those fields optional would be advantageous. Would you

>>mind

>>filing a bug[1] so that we don't forget to look into the issue for the

>>next

>>version.

>> 

>>As for your immediate issues of not having data for those fields, if you

>>are

>>using RDF i'd just skip them altogether in the SPDX file. While your file

>>will technically be invalid all reasonable SPDX consumers will not have a

>>problem with that information being absent unless they need it to

>>accomplish

>>their goal. (In which case they cannot use your SPDX files, anyway.) If

>>you

>>are using the tag-value format skipping the fields altogether will, i

>>think,

>>prove problematic due to that format's stricter syntactic constraints.

>>(Kate

>>or Gary, can you confirm this?)

>> 

>>[1]:

>>https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spe

>>c

>> 

>>Peter

>> 

>>PS: I am cc-ing the technical working group because it's participants are

>>best suited to answer these sorts of issues.

>> 

>>_______________________________________________

>>Spdx-tech mailing list

>>Spdx-tech@...

>>https://lists.spdx.org/mailman/listinfo/spdx-tech

>> 

>> 

 

 





_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx

 


Mike Milinkovich
 

Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "

 

The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.

 

FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].

 

I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.

 

In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.

 

[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd

 

 

Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@...

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov

 

 

 

Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.

 


Philip Odence
 

I sometimes skirt the issue by broadly referring "software that is freely available on the web." 

When one is talking about new projects, picking licenses, and the like, it makes sense to steer/limit to OSI approved licenses. When, on the other hand, the use case is documenting all the "junk" that may be found in a package and associated licenses (as with SPDX), it makes sense to be expansive in order to be able to represent software under licenses outside the OSI definition. 

So, the SPDX license list goes beyond the OSI list. Our goal has been to handle the bulk of license one might run into in a software package. And, the spec provides a mechanism for handling licenses not on the list, by essentially including the text of the license. One of the benefits of the License List is that it keeps the size of the SPDX file down by not requiring the text to be included.

I don’t think we've come to grips with where we draw the line on the size of the license list. With the 150 or so license on there now, we certainly handle the vast majority of components, but for user convenience, more is better. I think when we get comfortable with our understanding of the effort involved in maintaining the list and adding new licenses, we'll be in a better position to say how big we want the list to be.

From: Mike Milinkovich <mike.milinkovich@...>
Organization: Eclipse Foundation
Reply-To: Mike Milinkovich <mike.milinkovich@...>
Date: Fri, 22 Jun 2012 13:24:42 -0400
To: <Soeren_Rabenstein@...>, Michel Ruffin <Michel.Ruffin@...>, Michael Herzog <mjherzog@...>, <spdx@...>
Subject: RE: "Scope" of licenses to be covered by SPDX

Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "

 

The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.

 

FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].

 

I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.

 

In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.

 

[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd

 

 

Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@...

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov

 

 

 

Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.

 

_______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx


RUFFIN MICHEL
 

We do not discuss or put into question the FSF and OSI definitions of FOSS (I know them by heart, I understand the philosophy behind them and respect them). We try to make a definition of what should be the scope of software subject to the clause that we put in the contracts and it is broader than  open source traditional definition.  So perhaps the term “FOSS” is chocking you for that. But this is why we need to discuss and standardize. For me FOSS is not “Free and Open source Software” it is “Free and/or Open source software”; Now should we select another term in this context? I am totally open minded on this. Call it NPS (non-purchased software) or whatever, but even this wording will not fit with shareware for instance.

 

Michel

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Mike Milinkovich [mailto:mike.milinkovich@...]
Envoyé : vendredi 22 juin 2012 19:25
À : Soeren_Rabenstein@...; RUFFIN, MICHEL (MICHEL); mjherzog@...; spdx@...
Objet : RE: "Scope" of licenses to be covered by SPDX

 

Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "

 

The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.

 

FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].

 

I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.

 

In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.

 

[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd

 

 

Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@...

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov

 

 

 

Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.

 


Peter A. Bigot
 

With respect to the license list, an issue I happened to notice this
morning is that items on it appear to reflect a very flat concept of a
license when there are options, e.g. GPL-2.0-with-GCC-exception and
GPL-2.0+. The problem is that this approach limits the succinct
representation of licenses. For example, if a package (e.g., libgcc)
is GPL 2.0 or later version with runtime exception, there is no
GPL-2.0+-with-GCC-exception. If a package also incorporates the GPL
classpath exception, that isn't listed either. It's not obvious that
this can be fixed by disjunction or conjunction of the listed licenses
(wouldn't GPL-2.0+ AND GPL-2.0-with-GCC-exception be simple GPL-2.0?)

In a future revision, perhaps the concept of a base license with a set
of options (GPL-2.0, option for later revision, exception for runtime
library, exception for classpath) would be more expressive. It could
also cut down on the size of the list.

Peter

On Fri, Jun 22, 2012 at 12:48 PM, Philip Odence
<podence@blackducksoftware.com> wrote:
I sometimes skirt the issue by broadly referring "software that is freely
available on the web."

When one is talking about new projects, picking licenses, and the like, it
makes sense to steer/limit to OSI approved licenses. When, on the other
hand, the use case is documenting all the "junk" that may be found in a
package and associated licenses (as with SPDX), it makes sense to be
expansive in order to be able to represent software under licenses outside
the OSI definition.

So, the SPDX license list goes beyond the OSI list. Our goal has been to
handle the bulk of license one might run into in a software package. And,
the spec provides a mechanism for handling licenses not on the list, by
essentially including the text of the license. One of the benefits of the
License List is that it keeps the size of the SPDX file down by not
requiring the text to be included.

I don’t think we've come to grips with where we draw the line on the size of
the license list. With the 150 or so license on there now, we certainly
handle the vast majority of components, but for user convenience, more is
better. I think when we get comfortable with our understanding of the effort
involved in maintaining the list and adding new licenses, we'll be in a
better position to say how big we want the list to be.

From: Mike Milinkovich <mike.milinkovich@eclipse.org>
Organization: Eclipse Foundation
Reply-To: Mike Milinkovich <mike.milinkovich@eclipse.org>
Date: Fri, 22 Jun 2012 13:24:42 -0400
To: <Soeren_Rabenstein@asus.com>, Michel Ruffin
<Michel.Ruffin@alcatel-lucent.com>, Michael Herzog <mjherzog@nexb.com>,
<spdx@lists.spdx.org>
Subject: RE: "Scope" of licenses to be covered by SPDX

Re: " Out of this topic we just discussed (in my understanding) what could
be a proper definition of “FOSS”. "



The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are
the two organizations which, in my opinion, define what FOSS is. Any attempt
to define FOSS which do not take into account the collective wisdom and
process that went into their respective license lists [1][2] would be a big
mistake.



FOSS = Free and Open Source Software, which is the union of software which
meets the definition of Free Software[3] and Open Source Software[4].



I have seen attempts in the past to expand the definition of FOSS beyond
licensing to include other parameters such as open development processes and
the like. They've all been spectacularly unsuccessful. There be dragons.



In the interest of full disclosure, in addition to by day job at the Eclipse
Foundation, I am also a Director of the OSI.



[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd





Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@eclipse.org

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov







Out of this topic we just discussed (in my understanding) what could be a
proper definition of “FOSS”.



_______________________________________________ Spdx mailing list
Spdx@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx

_______________________________________________
Spdx mailing list
Spdx@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx


RUFFIN MICHEL
 

Well I have not really through how this extend to the SPDX standard. But if you look at Blackduck protext tool there is probably 1500 to 2000 licenses described, Palamida is around 1500 (if I am not mistaking). The SPDX standard must cope with all these licenses, it should not limit itself to the 60 to 70 OSI certified licenses. It would be useless. Now if you have not a standard name for these licenses it is not a big issue but in fact they exist “Sun binary license”, “ Sun entitlement license”, “Oracle binary licence”, “ Oracle OTN license” (might also be “Oracle technology network” license) , “Alcatel-Lucent public license” …

 

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Philip Odence [mailto:podence@...]
Envoyé : vendredi 22 juin 2012 19:49
À : Mike Milinkovich; Soeren_Rabenstein@...; RUFFIN, MICHEL (MICHEL); Michael Herzog; spdx@...
Objet : Re: "Scope" of licenses to be covered by SPDX

 

I sometimes skirt the issue by broadly referring "software that is freely available on the web." 

 

When one is talking about new projects, picking licenses, and the like, it makes sense to steer/limit to OSI approved licenses. When, on the other hand, the use case is documenting all the "junk" that may be found in a package and associated licenses (as with SPDX), it makes sense to be expansive in order to be able to represent software under licenses outside the OSI definition. 

 

So, the SPDX license list goes beyond the OSI list. Our goal has been to handle the bulk of license one might run into in a software package. And, the spec provides a mechanism for handling licenses not on the list, by essentially including the text of the license. One of the benefits of the License List is that it keeps the size of the SPDX file down by not requiring the text to be included.

 

I don’t think we've come to grips with where we draw the line on the size of the license list. With the 150 or so license on there now, we certainly handle the vast majority of components, but for user convenience, more is better. I think when we get comfortable with our understanding of the effort involved in maintaining the list and adding new licenses, we'll be in a better position to say how big we want the list to be.

 

From: Mike Milinkovich <mike.milinkovich@...>
Organization: Eclipse Foundation
Reply-To: Mike Milinkovich <mike.milinkovich@...>
Date: Fri, 22 Jun 2012 13:24:42 -0400
To: <Soeren_Rabenstein@...>, Michel Ruffin <Michel.Ruffin@...>, Michael Herzog <mjherzog@...>, <spdx@...>
Subject: RE: "Scope" of licenses to be covered by SPDX

 

Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "

 

The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.

 

FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].

 

I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.

 

In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.

 

[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd

 

 

Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@...

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov

 

 

 

Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.

 

_______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx


Mike Milinkovich
 

Re: "“Free and Open source Software” it is “Free and/or Open source software”; "

 

I understand that. Which is why I said it is the union, rather than the intersection.

 

In my highly simplified view, the FSF defines what free software is, and the OSI defines what open source software is. If you're going to include a bunch of other stuff that does not meet either of those definitions, then please (pretty please!) do not refer to your definition as FOSS or FLOSS. Find some other name, because that one's taken.

 

 

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Sent: June-22-12 1:55 PM
To: mike.milinkovich@...; Soeren_Rabenstein@...; mjherzog@...; spdx@...
Subject: RE: "Scope" of licenses to be covered by SPDX

 

We do not discuss or put into question the FSF and OSI definitions of FOSS (I know them by heart, I understand the philosophy behind them and respect them). We try to make a definition of what should be the scope of software subject to the clause that we put in the contracts and it is broader than  open source traditional definition.  So perhaps the term “FOSS” is chocking you for that. But this is why we need to discuss and standardize. For me FOSS is not “Free and Open source Software” it is “Free and/or Open source software”; Now should we select another term in this context? I am totally open minded on this. Call it NPS (non-purchased software) or whatever, but even this wording will not fit with shareware for instance.

 

Michel

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Mike Milinkovich [mailto:mike.milinkovich@...]
Envoyé : vendredi 22 juin 2012 19:25
À : Soeren_Rabenstein@...; RUFFIN, MICHEL (MICHEL); mjherzog@...; spdx@...
Objet : RE: "Scope" of licenses to be covered by SPDX

 

Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "

 

The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.

 

FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].

 

I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.

 

In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.

 

[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd

 

 

Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@...

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov

 

 

 

Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.

 


RUFFIN MICHEL
 

Ok now we have an understanding, any suggestion ?

 

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Mike Milinkovich [mailto:mike.milinkovich@...]
Envoyé : vendredi 22 juin 2012 20:43
À : RUFFIN, MICHEL (MICHEL); Soeren_Rabenstein@...; mjherzog@...; spdx@...
Objet : RE: "Scope" of licenses to be covered by SPDX

 

Re: "“Free and Open source Software” it is “Free and/or Open source software”; "

 

I understand that. Which is why I said it is the union, rather than the intersection.

 

In my highly simplified view, the FSF defines what free software is, and the OSI defines what open source software is. If you're going to include a bunch of other stuff that does not meet either of those definitions, then please (pretty please!) do not refer to your definition as FOSS or FLOSS. Find some other name, because that one's taken.

 

 

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Sent: June-22-12 1:55 PM
To: mike.milinkovich@...; Soeren_Rabenstein@...; mjherzog@...; spdx@...
Subject: RE: "Scope" of licenses to be covered by SPDX

 

We do not discuss or put into question the FSF and OSI definitions of FOSS (I know them by heart, I understand the philosophy behind them and respect them). We try to make a definition of what should be the scope of software subject to the clause that we put in the contracts and it is broader than  open source traditional definition.  So perhaps the term “FOSS” is chocking you for that. But this is why we need to discuss and standardize. For me FOSS is not “Free and Open source Software” it is “Free and/or Open source software”; Now should we select another term in this context? I am totally open minded on this. Call it NPS (non-purchased software) or whatever, but even this wording will not fit with shareware for instance.

 

Michel

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Mike Milinkovich [mailto:mike.milinkovich@...]
Envoyé : vendredi 22 juin 2012 19:25
À : Soeren_Rabenstein@...; RUFFIN, MICHEL (MICHEL); mjherzog@...; spdx@...
Objet : RE: "Scope" of licenses to be covered by SPDX

 

Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "

 

The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.

 

FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].

 

I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.

 

In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.

 

[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd

 

 

Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@...

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov

 

 

 

Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.

 


Mike Milinkovich
 

RMS - "Random May-be-free Stuff"?

 

Wait. That acronym's also taken. Darn!

 

<<Sorry, I just couldn't resist :) >>

 

More seriously: my apologies, but no good name or acronym immediately comes to mind.

 

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Sent: June-22-12 2:58 PM
To: mike.milinkovich@...; Soeren_Rabenstein@...; mjherzog@...; spdx@...
Subject: RE: "Scope" of licenses to be covered by SPDX

 

Ok now we have an understanding, any suggestion ?

 

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Mike Milinkovich [mailto:mike.milinkovich@...]
Envoyé : vendredi 22 juin 2012 20:43
À : RUFFIN, MICHEL (MICHEL); Soeren_Rabenstein@...; mjherzog@...; spdx@...
Objet : RE: "Scope" of licenses to be covered by SPDX

 

Re: "“Free and Open source Software” it is “Free and/or Open source software”; "

 

I understand that. Which is why I said it is the union, rather than the intersection.

 

In my highly simplified view, the FSF defines what free software is, and the OSI defines what open source software is. If you're going to include a bunch of other stuff that does not meet either of those definitions, then please (pretty please!) do not refer to your definition as FOSS or FLOSS. Find some other name, because that one's taken.

 

 

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Sent: June-22-12 1:55 PM
To: mike.milinkovich@...; Soeren_Rabenstein@...; mjherzog@...; spdx@...
Subject: RE: "Scope" of licenses to be covered by SPDX

 

We do not discuss or put into question the FSF and OSI definitions of FOSS (I know them by heart, I understand the philosophy behind them and respect them). We try to make a definition of what should be the scope of software subject to the clause that we put in the contracts and it is broader than  open source traditional definition.  So perhaps the term “FOSS” is chocking you for that. But this is why we need to discuss and standardize. For me FOSS is not “Free and Open source Software” it is “Free and/or Open source software”; Now should we select another term in this context? I am totally open minded on this. Call it NPS (non-purchased software) or whatever, but even this wording will not fit with shareware for instance.

 

Michel

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Mike Milinkovich [mailto:mike.milinkovich@...]
Envoyé : vendredi 22 juin 2012 19:25
À : Soeren_Rabenstein@...; RUFFIN, MICHEL (MICHEL); mjherzog@...; spdx@...
Objet : RE: "Scope" of licenses to be covered by SPDX

 

Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "

 

The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.

 

FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].

 

I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.

 

In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.

 

[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd

 

 

Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@...

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov

 

 

 

Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.

 


Jilayne Lovejoy <jilayne.lovejoy@...>
 

In so far as Phil and Michael's previous comment regarding the SPDX License List – it is correct to say that we have endeavored to include the most common open source licenses (not freeware, shareware, various abominations of the above, proprietary, or what have you) as stated in the license list description at the top of the page found here: http://spdx.org/wiki/spdx-license-list The goal is not to try to capture every license you might find, as that would be impossible, but the most commonly found.  There are currently 168 licenses on the SPDX License List.  We have been discussing coordinating with a few of the community groups to add licenses they may have, that SPDX doesn't (e.g. Gentoo, Fedora, Debian), but haven't had enough people-power to get this task completed (yet).  

When I responded earlier, I did not mention this as I could not remember accurately if we discussed the idea of adding other "free" (but not necessary source-code-is-provided licenses).   In any case, it's certainly something we could discuss, but I think there are some good reasons not to expand too far (which I will raise if and when we have that discussion, instead of rattling on unnecessarily here)  That being said, there are probably other licenses that are not "open source" per se, but commonly found and lumped into that broader category (the Sun/Oracle license come to mind) that perhaps should be added.  

In any case, anyone can suggest adding a license via this process:  http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-added  We are largely "under-staffed" and "under-paid," so I would encourage anyone who wants to see the list expanded to get involved.

In regards to Michel's definition of "FOSS" for the purposes of contract negotiations and standardizing clauses – I don't have so much a problem with this name, per se.  I understand the reaction; "FOSS" has ideological underpinnings and is not thought of to include the second and third categories, so this is a bit uncomfortable.  But, I guess when looking at it through my attorney glasses, which is the lens for which these clauses are intended, I can compartmentalize and apply the definition as however it is presented for that particular contract.  That is, after all, how contract definitions work.  I have certainly seen contract terms and definitions come across my desk, where I've thought, "well, that's not what I would have called that," but so long as I understand what that word means in the context of that agreement, it really doesn't matter if it's called "Supercalifragilisticexpialidocious."  Just my two cents.

Jilayne

Jilayne Lovejoy |  Corporate Counsel
OpenLogic, Inc.
jlovejoy@...   720 240 4545

From: <RUFFIN>, "MICHEL (MICHEL)" <michel.ruffin@...>
Date: Friday, June 22, 2012 12:57 PM
To: "mike.milinkovich@..." <mike.milinkovich@...>, Soeren Rabenstein <Soeren_Rabenstein@...>, "mjherzog@..." <mjherzog@...>, SPDX-general <spdx@...>
Subject: RE: "Scope" of licenses to be covered by SPDX

Ok now we have an understanding, any suggestion ?

 

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Mike Milinkovich [mailto:mike.milinkovich@...]
Envoyé : vendredi 22 juin 2012 20:43
À : RUFFIN, MICHEL (MICHEL); Soeren_Rabenstein@...; mjherzog@...; spdx@...
Objet : RE: "Scope" of licenses to be covered by SPDX

 

Re: "“Free and Open source Software” it is “Free and/or Open source software”; "

 

I understand that. Which is why I said it is the union, rather than the intersection.

 

In my highly simplified view, the FSF defines what free software is, and the OSI defines what open source software is. If you're going to include a bunch of other stuff that does not meet either of those definitions, then please (pretty please!) do not refer to your definition as FOSS or FLOSS. Find some other name, because that one's taken.

 

 

From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Sent: June-22-12 1:55 PM
To: mike.milinkovich@...; Soeren_Rabenstein@...; mjherzog@...; spdx@...
Subject: RE: "Scope" of licenses to be covered by SPDX

 

We do not discuss or put into question the FSF and OSI definitions of FOSS (I know them by heart, I understand the philosophy behind them and respect them). We try to make a definition of what should be the scope of software subject to the clause that we put in the contracts and it is broader than  open source traditional definition.  So perhaps the term “FOSS” is chocking you for that. But this is why we need to discuss and standardize. For me FOSS is not “Free and Open source Software” it is “Free and/or Open source software”; Now should we select another term in this context? I am totally open minded on this. Call it NPS (non-purchased software) or whatever, but even this wording will not fit with shareware for instance.

 

Michel

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff

Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Mike Milinkovich [mailto:mike.milinkovich@...]
Envoyé : vendredi 22 juin 2012 19:25
À : Soeren_Rabenstein@...; RUFFIN, MICHEL (MICHEL); mjherzog@...; spdx@...
Objet : RE: "Scope" of licenses to be covered by SPDX

 

Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”."

 

The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.

 

FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].

 

I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.

 

In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.

 

[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd

 

 

Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@...

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov

 

 

 

Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.

 


Ciaran Farrell
 

On Sat, 2012-06-23 at 00:23 +0000, Jilayne Lovejoy wrote:
In so far as Phil and Michael's previous comment regarding the SPDX
License List – it is correct to say that we have endeavored to include
the most common open source licenses (not freeware, shareware, various
abominations of the above, proprietary, or what have you) as stated in
the license list description at the top of the page found
here: http://spdx.org/wiki/spdx-license-list The goal is not to try to
capture every license you might find, as that would be impossible, but
the most commonly found. There are currently 168 licenses on the SPDX
License List. We have been discussing coordinating with a few of the
community groups to add licenses they may have, that SPDX doesn't
(e.g. Gentoo, Fedora, Debian), but haven't had enough people-power to
get this task completed (yet).


When I responded earlier, I did not mention this as I could not
remember accurately if we discussed the idea of adding other
"free" (but not necessary source-code-is-provided licenses). In any
case, it's certainly something we could discuss, but I think there are
some good reasons not to expand too far (which I will raise if and
when we have that discussion, instead of rattling on unnecessarily
here) That being said, there are probably other licenses that are not
"open source" per se, but commonly found and lumped into that broader
category (the Sun/Oracle license come to mind) that perhaps should be
added.


In any case, anyone can suggest adding a license via this process:
http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-added We are largely "under-staffed" and "under-paid," so I would encourage anyone who wants to see the list expanded to get involved.
To chime in on this, at openSUSE we have exactly the problem described
above - we'd like to adopt SPDX, but the license list does not provide
anywhere need the coverage that we need. What we've done in the interim
is create a spreadsheet on Google Docs where we add those licenses we
need to track with a SUSE- prefix. We'd hope to push these (or
substitutes for those) upstream to the SPDX license list.

In response to another idea on this list, I also think it makes sense to
use operators like + and - instead of basic strings for license
shortnames. It is certainly not consistent that the list contains e.g.
GPL-2.0-with-openssl-exception but not GPL-2.0+-with-openssl-exception.
Rather than coming up with n- strings for all those licenses out there,
surely using an operator would make more sense.

In summary, the SPDX format (well, for us as a linux distribution, the
SPDX shortnames) looks like it could help provide considerable
consistency, but (and this is a huge but) it is currently unusable for
linux distributions.

Ciaran


Bradley M. Kuhn <bkuhn@...>
 

Ciaran Farrell wrote at 15:45 (EDT) on Saturday:

at openSUSE .... we'd like to adopt SPDX, but the license list does
not provide anywhere need the coverage that we need.
This is interesting; I'd suspect this might be the case for other
distributions, too. Debian, for example, basically has always kept a
full text file (.../doc/copyright) to describe the exact licensing
situation of its packages.

Peter Bigot wrote on Friday:
With respect to the license list, an issue I happened to notice this
morning is that items on it appear to reflect a very flat concept of
a license when there are options, e.g. GPL-2.0-with-GCC-exception and
GPL-2.0+. The problem is that this approach limits the succinct
representation of licenses. For example, if a package (e.g., libgcc)
is GPL 2.0 or later version with runtime exception, there is no
GPL-2.0+-with-GCC-exception
Indeed. I don't even *know* of any package in the world that's licensed
under "GPLv2-only along with any given 'GCC exception'". There is
actually *no such thing* as a single "GPL-2.0-with-GCC-exception". The
GPLv2'd versions of GCC actually have a patchwork of *different*
exceptions that are all worded slightly differently and appear
throughout various directories in the sources. When I helped lead the
process of drafting the GPLv3 RTL exception, one of our primary goals
was to encompass and rectify the differences in the various GPLv2
exceptions for GCC.

Meanwhile, one of my proposals during the GPLv3 RTL exception drafting
process -- which FSF now does -- is that all exceptions should be
versioned. SPDX's license list doesn't account for this at all. SPDX
will have to completely rework its monikers and details when new
versions of exceptions are released [0].

Meanwhile, I note the obvious additional issue that Peter hinted at but
didn't raise explicitly: I'm not aware of any program in the world
that's GPLv3-only plus the GCC RTL exception 3.1. GCC itself is
currently under "GPLv3-or-later with the GCC Runtime Library Exception
3.1". But even *that* isn't fully accurate as a generalization, because
*parts* of GCC are under that license I just stated, but the majority of
the code is straight GPLv3-or-later.

Having not looked closely at the SPDX license list before, a first
analysis shows that it's completely inadequate for representing even the
most common licensing situations on some of the most widely used of
programs. Indeed, it seems as SPDX's license list stands now, I
basically couldn't represent the license of *any* version of GCC except
versions from the very early 1990s, and even for those, I'd need to add
a license exception or two.

(Note, BTW -- and I bet this issue will be of particular interest to the
Free Software licensing historians among us -- that the proto-GPL
license such as the Emacs Public License, the GCC Public License, and
the Nethack Public License aren't on SPDX's license list at all. To the
extent that anyone wants to use SPDX's license list as a tool to
represent historical versions of software, that's completely impossible,
too. Notwithstanding that the Nethack Public License is actually still
in active use AFAIK.)


[0] Also, note there is, in fact, an RTL exception v3.0, although,
I suspect it's not used by any package. It was only the default
version "in the wild" for about 6 weeks, which is of course longer
than GFDL 1.0's 4 day lifespan as the current version. (Those of you
who, like me, were doing Free Software licensing work back in 2000
will remember that widespread confusion in early March 2000; I'm
still apologizing for my role in that and various confusions about
the GFDL. :)
--
-- bkuhn


Jilayne Lovejoy <jilayne.lovejoy@...>
 

(I have included the legal list on this response)

This has been discussed a couple times and part of this issue is listed as
a "to-do" on the legal page
(http://spdx.org/wiki/legal-team-current-issues-last-updated-june-27),
namely making sure the license list has capture all the common exceptions
to begin with.

The concept of having a base license with additive options was discussed
(I can't seem to find it in the meeting minutes, but I only looked briefly
at this year and it may even have been before that or touched upon
tangentially) If memory serves, it wasn't a matter of consensus that this
was a bad idea, but there has yet to be a fully thought-out proposal
submitted for thorough consideration. So, if you have an idea as to how
to implement this idea, while keeping in mind the overall goal of the
LIcense List, etc. - that would be great!!

Maybe someone else from the legal team can also weigh in here regarding
the previous discussions on this topic.

- Jilayne

On 6/22/12 12:10 PM, "Peter Bigot" <bigotp@acm.org> wrote:

With respect to the license list, an issue I happened to notice this
morning is that items on it appear to reflect a very flat concept of a
license when there are options, e.g. GPL-2.0-with-GCC-exception and
GPL-2.0+. The problem is that this approach limits the succinct
representation of licenses. For example, if a package (e.g., libgcc)
is GPL 2.0 or later version with runtime exception, there is no
GPL-2.0+-with-GCC-exception. If a package also incorporates the GPL
classpath exception, that isn't listed either. It's not obvious that
this can be fixed by disjunction or conjunction of the listed licenses
(wouldn't GPL-2.0+ AND GPL-2.0-with-GCC-exception be simple GPL-2.0?)

In a future revision, perhaps the concept of a base license with a set
of options (GPL-2.0, option for later revision, exception for runtime
library, exception for classpath) would be more expressive. It could
also cut down on the size of the list.

Peter

On Fri, Jun 22, 2012 at 12:48 PM, Philip Odence
<podence@blackducksoftware.com> wrote:
I sometimes skirt the issue by broadly referring "software that is
freely
available on the web."

When one is talking about new projects, picking licenses, and the like,
it
makes sense to steer/limit to OSI approved licenses. When, on the other
hand, the use case is documenting all the "junk" that may be found in a
package and associated licenses (as with SPDX), it makes sense to be
expansive in order to be able to represent software under licenses
outside
the OSI definition.

So, the SPDX license list goes beyond the OSI list. Our goal has been to
handle the bulk of license one might run into in a software package.
And,
the spec provides a mechanism for handling licenses not on the list, by
essentially including the text of the license. One of the benefits of
the
License List is that it keeps the size of the SPDX file down by not
requiring the text to be included.

I don¹t think we've come to grips with where we draw the line on the
size of
the license list. With the 150 or so license on there now, we certainly
handle the vast majority of components, but for user convenience, more
is
better. I think when we get comfortable with our understanding of the
effort
involved in maintaining the list and adding new licenses, we'll be in a
better position to say how big we want the list to be.

From: Mike Milinkovich <mike.milinkovich@eclipse.org>
Organization: Eclipse Foundation
Reply-To: Mike Milinkovich <mike.milinkovich@eclipse.org>
Date: Fri, 22 Jun 2012 13:24:42 -0400
To: <Soeren_Rabenstein@asus.com>, Michel Ruffin
<Michel.Ruffin@alcatel-lucent.com>, Michael Herzog <mjherzog@nexb.com>,
<spdx@lists.spdx.org>
Subject: RE: "Scope" of licenses to be covered by SPDX

Re: " Out of this topic we just discussed (in my understanding) what
could
be a proper definition of ³FOSS². "



The Free Software Foundation (FSF) and the Open Source Initiative (OSI)
are
the two organizations which, in my opinion, define what FOSS is. Any
attempt
to define FOSS which do not take into account the collective wisdom and
process that went into their respective license lists [1][2] would be a
big
mistake.



FOSS = Free and Open Source Software, which is the union of software
which
meets the definition of Free Software[3] and Open Source Software[4].



I have seen attempts in the past to expand the definition of FOSS beyond
licensing to include other parameters such as open development
processes and
the like. They've all been spectacularly unsuccessful. There be dragons.



In the interest of full disclosure, in addition to by day job at the
Eclipse
Foundation, I am also a Director of the OSI.



[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[2] http://opensource.org/licenses/alphabetical

[3] http://www.gnu.org/philosophy/free-sw.html

[4] http://opensource.org/docs/osd





Mike Milinkovich

Executive Director

Eclipse Foundation, Inc.

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@eclipse.org

blog: http://dev.eclipse.org/blogs/mike/

twitter: @mmilinkov







Out of this topic we just discussed (in my understanding) what could be
a
proper definition of ³FOSS².



_______________________________________________ Spdx mailing list
Spdx@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx

_______________________________________________
Spdx mailing list
Spdx@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx
_______________________________________________
Spdx mailing list
Spdx@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx


Jilayne Lovejoy <jilayne.lovejoy@...>
 



In any case, anyone can suggest adding a license via this process:

http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be
-added We are largely "under-staffed" and "under-paid," so I would
encourage anyone who wants to see the list expanded to get involved.
To chime in on this, at openSUSE we have exactly the problem described
above - we'd like to adopt SPDX, but the license list does not provide
anywhere need the coverage that we need. What we've done in the interim
is create a spreadsheet on Google Docs where we add those licenses we
need to track with a SUSE- prefix. We'd hope to push these (or
substitutes for those) upstream to the SPDX license list.
Do you expect the SPDX License List to cover every license you find? Does
any list?
It would be great to align your list with the SPDX List (and make sure the
short identifiers are consistent, as the intent it to not changes those,
once they are published on the list) - please see the link above as to how
to add a license or join a legal call so we can figure out how best to
proceed.


In response to another idea on this list, I also think it makes sense to
use operators like + and - instead of basic strings for license
shortnames. It is certainly not consistent that the list contains e.g.
GPL-2.0-with-openssl-exception but not GPL-2.0+-with-openssl-exception.
Rather than coming up with n- strings for all those licenses out there,
surely using an operator would make more sense.
Just posted a response to the original response on this.

In summary, the SPDX format (well, for us as a linux distribution, the
SPDX shortnames) looks like it could help provide considerable
consistency, but (and this is a huge but) it is currently unusable for
linux distributions.
What makes it "unusable" - I'm not sure I completely understand.

- Jilayne


Ciaran Farrell
 

On Wed, 2012-06-27 at 20:05 +0000, Jilayne Lovejoy wrote:


In any case, anyone can suggest adding a license via this process:

http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be
-added We are largely "under-staffed" and "under-paid," so I would
encourage anyone who wants to see the list expanded to get involved.
To chime in on this, at openSUSE we have exactly the problem described
above - we'd like to adopt SPDX, but the license list does not provide
anywhere need the coverage that we need. What we've done in the interim
is create a spreadsheet on Google Docs where we add those licenses we
need to track with a SUSE- prefix. We'd hope to push these (or
substitutes for those) upstream to the SPDX license list.
Do you expect the SPDX License List to cover every license you find? Does
any list?
No, of course not. There are simply too many licenses which almost
exactly correspond to existing, known licenses. It is the 'almost
exactly' that raises the issue. If all of these were to be included in a
list, the list would be very long indeed.

It would be great to align your list with the SPDX List (and make sure the
short identifiers are consistent, as the intent it to not changes those,
once they are published on the list) - please see the link above as to how
to add a license or join a legal call so we can figure out how best to
proceed.
https://docs.google.com/spreadsheet/pub?key=0AqPp4y2wyQsbdGQ1V3pRRDg5NEpGVWpubzdRZ0tjUWc

The left column is the SPDX shortname (with a proprietary SUSE- before
it if the license is not on the SPDX list).


In response to another idea on this list, I also think it makes sense to
use operators like + and - instead of basic strings for license
shortnames. It is certainly not consistent that the list contains e.g.
GPL-2.0-with-openssl-exception but not GPL-2.0+-with-openssl-exception.
Rather than coming up with n- strings for all those licenses out there,
surely using an operator would make more sense.
Just posted a response to the original response on this.

In summary, the SPDX format (well, for us as a linux distribution, the
SPDX shortnames) looks like it could help provide considerable
consistency, but (and this is a huge but) it is currently unusable for
linux distributions.
What makes it "unusable" - I'm not sure I completely understand.
If we are referring only to the shortnames (typically, this - or a
combination of these - would be what would be included in the spec file)
then we would not get far if we limited ourselves only to packages with
licenses on the spdx list. Our current workaround, as stated above, is
to use a proprietary SUSE- prefix and to come up with a SPDX-like
shortname.

Ciaran


- Jilayne


Bradley M. Kuhn <bkuhn@...>
 

Jilayne Lovejoy wrote at 16:02 (EDT) on Wednesday:
So, if you have an idea as to how to implement this idea, while
keeping in mind the overall goal of the LIcense List, etc. - that
would be great!!
IMO, "implementing" is trivial. The tough part is careful cataloging to
know *what* to add to the list. For example, obviously, no one did the
work of cataloging the exceptions in GCC, which is why the license of
GCC can't be represented by SPDX for any version of GCC (See my other
post about that:
http://lists.spdx.org/pipermail/spdx/2012-June/000704.html )

If someone wants to do the work of cataloging the exceptions in GCC, I'd
be happy to advise, since I was involved with Brett Smith when he did
the work during the 3.1 RTL exception drafting process. Cc me on any
email threads that are working on this and I'll try to allocate time to
help.

But, note that exceptions are all over the place, in things like
Classpath, autoconf, and plenty of other places. I wonder: has anyone
taken a Fossology (the best scanning tool available as Free Software)
run of Debian distribution and just made sure every license it finds has
a moniker in SPDX? If not, why not? Seems like a necessary first step
for SPDX to have any chance of being complete.
--
-- bkuhn


Bradley M. Kuhn <bkuhn@...>
 

Jilayne Lovejoy wrote at 16:05 (EDT) on Wednesday:
Do you expect the SPDX License List to cover every license you find?
I'm not clear on what the value of SPDX's license list unless it's
comprehensive. Can you explain how SPDX is still useful if the licenses
for widely distributed and used central-infrastructure programs can't
be listed with SPDX?

Does any list?
Other license lists aren't designed to allow for cataloging the details
of a Free Software release, nor are they meant to be grokked by
programs, so they don't need to be perfectly comprehensive. If a
license is missing from SPDX's list, I can't write an accurate SPDX file
for that package, right? Seems like a really big bug in SPDX to me.

This is why I keep renewing my encouragement for the SPDX group to
actually *write* some SPDX files and carry them upstream. Your problems
with SPDX will start to shake out a lot faster if you do that.

Indeed, my offer that I've been making for a year remains open: when
I see that SPDX patch come across the BusyBox mailing list, I'll endorse
it and encourage Denys to put it upstream.... but I still haven't seen
the patch arrive, and when I suggest this to SPDX folks, they tell me
"upstream should be responsible for doing this work". I get worried any
time a bunch of proprietary software companies get together and start
suggesting unfunded mandates for upstream Free Software projects.
--
-- bkuhn


Bob Gobeille
 

On Jun 28, 2012, at 12:02 PM, Bradley M. Kuhn wrote:

But, note that exceptions are all over the place, in things like
Classpath, autoconf, and plenty of other places. I wonder: has anyone
taken a Fossology (the best scanning tool available as Free Software)
run of Debian distribution and just made sure every license it finds has
a moniker in SPDX? If not, why not? Seems like a necessary first step
for SPDX to have any chance of being complete.
FWIW, one of our FOSSology contributors (thank you Camille) put together a spreadsheet (HarmonisationLicenseIDs.ods) highlighting the differences between the fossology license list and the SPDX license list:

http://www.fossology.org/projects/fossology/wiki/MatchSPDXLicenceIDs

We plan on using this to update fossology with the SPDX license short names and insure we have license signatures for all the SPDX licenses.

Bob Gobeille
bobg@fossology.org