Date   

Minutes from July 12 SPDX General Meeting

Philip Odence
 






Attendance: 7

Technical Team Report - Kate

  • 2.0 work
    • Still working through use cases
  • 1.1 work
    • Still under revision but near completion
  • LinuxCon
    • Looks like there will be strong participation from the Tech Team in the Face to Face meeting at LinuxCon (Tues, Aug 28, afternoon, San Diego)

Legal Team Report - Jilayne

  • There will be light attendance at LinuxCon, so not anticipating having formal Legal Team meeting per se.
  • License list
    • Discussion continues
    • Suprisingly after all the recent discussion on the General Meerting list about expanding the list, no one has submitted any more licenses.
    • There is now available a spreadsheet template for requesting multiple licenses to be added.
  • There's interest in outreach to various FOSS communities about incorporating licenses, but little resource to do so.

Business Team Report - Scott/Jack

  • Solicited feedback on SPDX Mission and Vision statements. Some feedback incorporated. Both now ready for publishing on new website.
  • Discussions are going on between FOSSology team and Univ of Nebraska about incorporating SPDX output capability into FOSSology.

Cross Functional Issues – Phil

  • Panel discussion has been accepted for LinuxCon.
  • Website Update - No update
  • The Linux Foundation is exploring the possibility of providing some program management support for SPDX.


Attendees

  • Phil Odence, Black Duck Software
  • Kate Stewart, Canonical
  • Michael Herzog, nexB
  • Scott Lamons, HP
  • Jilayne Lovejoy, OpenLogic
  • Gary O'Neall, SourceAuditor
  • Jason Buttura, Cisco


Today SPDX General Meeting Reminder

Philip Odence
 

Apologies, but I seem to have misplaced my notes from the last meeting and never posted the minutes. I'm truly baffled as I am generally pretty well organized along this dimension. 


Meeting Time: July 12, 8am PST / 10 am CST / 11am EST / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html

Conf call dial-in:
Conference code:  7812589502
Toll-free dial-in number (U.S. and Canada):  (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of toll free numbers can be found: 
https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNumber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF

 
Administrative Agenda
Attendance

Technical Team Report - Kate
Legal Team Report - Jilayne
Business Team Report – Jack/Scott

Cross Functional Issues
Website Update



Re: "Scope" of licenses to be covered by SPDX

Jilayne Lovejoy <jilayne.lovejoy@...>
 

Great, Bradley. When I find someone who will *do* that work, we will
definitely ask for you input!

- Jilayne

On 6/28/12 12:02 PM, "Bradley M. Kuhn" <bkuhn@ebb.org> wrote:

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
_______________________________________________
Spdx mailing list
Spdx@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx


Re: "Scope" of licenses to be covered by SPDX

Peter A. Bigot
 

On Fri, Jun 29, 2012 at 10:19 AM, Peter Williams
<peter.williams@openlogic.com> wrote:
On Fri Jun 29 07:04:27 2012, Philip Odence wrote:

Polite request:
Could we shift this discussion off of the General Meeting list and
onto the Legal Team list only?
Is that really the best choice? This issue seems to be cross functional
issue in that it concerns both the license list and the technical details of
representing license data in SPDX files (and in the license list itself). I
think both the legal and tech teams need to collaborate to solve this
problem. Relegating it into any single functional area list will, i fear,
hinder progress to a solution quite significantly.
Agreed. In this general forum we've heard that the existing SPDX
license list approach does not meet the needs of Linux distributions
(in the case I raised, OpenEmbedded) because it does not have the
flexibility to succinctly and accurately represent the current
licenses of many GPL packages like gcc and its libraries.

Missing a "BMKL" is one thing. Missing GPL-2.0+-with-GCC-exception
and other GPL variants in common use, and/or requiring all such
variants to be listed explicitly in the spec or named arbitrarily at
the discretion of independent compilers of SPDX files, seems to be a
more fundamental weakness in the technical description of licenses.
Resolution of this is likely to require fairly wide familiarity with
what packages should have supported license descriptions in
combination with legal insight on how to express their licenses.

Adding spdx-tech (which I've just done, and joined) and dropping
general (which I have not done), might make sense, recognizing that
this sort of fragmentation does make it more likely that issues will
not be discovered and resolved in a timely fashion.

Peter


Re: "Scope" of licenses to be covered by SPDX

Peter Williams <peter.williams@...>
 

On Fri Jun 29 07:04:27 2012, Philip Odence wrote:
Polite request:
Could we shift this discussion off of the General Meeting list and
onto the Legal Team list only?
Is that really the best choice? This issue seems to be cross functional issue in that it concerns both the license list and the technical details of representing license data in SPDX files (and in the license list itself). I think both the legal and tech teams need to collaborate to solve this problem. Relegating it into any single functional area list will, i fear, hinder progress to a solution quite significantly.

Peter
openlogic.com


Re: "Scope" of licenses to be covered by SPDX

Philip Odence
 

Polite request:
Could we shift this discussion off of the General Meeting list and onto the Legal Team list only? TThis is GREAT discussion for the legal team.
This is not a big problem, but I want to respect the norms we established when we formed the Legal, Business and Tech teams. Part of splitting up the lists was to keep the traffic on the General Meeting list light so as not to burden folks who are only looking to monitor goings across the teams and at a high level. Real work (and this is real work) is supposed to be done on the team lists. 
So, if anyone responds to this (or other emails in the thread) please remove spdx@... from the CC.
Note: anyone not on the legal list and wanting to follow the discussion can sign up at http://lists.spdx.org/mailman/listinfo/spdx-legal
Thanks,
Phil

From: Tom Incorvia <tom.incorvia@...>
Date: Thu, 28 Jun 2012 14:14:32 -0500
To: Bob Gobeille <bob.gobeille@...>, "Bradley M. Kuhn" <bkuhn@...>
Cc: SPDX-legal <spdx-legal@...>, <spdx@...>
Subject: RE: "Scope" of licenses to be covered by SPDX

As long as the licenses are

 

-          Carefully named and vetted for exact license text

 

-          Somewhat broadly applicable (“somewhat broadly” is fuzzy, but we do want the list to grow starting with very common and moving to less common – it is a way to get more value with our limited bandwidth to vet the licenses)

 

Then more is better.

 

SPDX is looking for volunteers to submit additional licenses that meet the above criteria.

 

To nominate a license, provide this info: http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-added

 

Legal team: I can help with the reviews of proposed licenses, although I am not available until the end of July. 

 

Tom

 

Tom Incorvia

tom.incorvia@...

Direct: (512) 340-1336

 

 

-----Original Message-----
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Bob Gobeille
Sent: Thursday, June 28, 2012 1:50 PM
To: Bradley M. Kuhn
Cc: SPDX-legal; spdx@...
Subject: Re: "Scope" of licenses to be covered by SPDX

 

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@...

_______________________________________________

Spdx-legal mailing list

Spdx-legal@...

https://lists.spdx.org/mailman/listinfo/spdx-legal

 

This message has been scanned by MailController - portal1.mailcontroller.co.uk

This message has been scanned by MailController.

 

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


Re: "Scope" of licenses to be covered by SPDX

Philip Odence
 

Bradley,

See spec http://www.spdx.org/system/files/spdx-1.0.pdf on pages 23-24.

There's a section in an SPDX file called Other Licensing Information
Detected to handle licenses not on the standard list. The person creating
SPDX file creates an extension to the standard list that is local to the
particular SPDX file with similar short names. So, if you find the Bradley
Kuhn License you could designate it at BMKL-1.0, say, and then could use
that identifier throughout that SPDX file to reference that license. The
Other Licensing Information Detected section would map BMLK-1.0 to the
specific text of the license.

Hope that increases your comfort that the SPDX standard can handle-non
standard licenses. And, as others have pointed out, you could also submit
the BMKL to the SPDX legal team for future inclusion on the standard list.

Best,
Phil





Jilayne, I am not yet on the legal list, so please forward.

On 6/28/12 2:10 PM, "Bradley M. Kuhn" <bkuhn@ebb.org> wrote:

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
_______________________________________________
Spdx mailing list
Spdx@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx


Re: "Scope" of licenses to be covered by SPDX

Tom Incorvia
 

As long as the licenses are

 

-          Carefully named and vetted for exact license text

 

-          Somewhat broadly applicable (“somewhat broadly” is fuzzy, but we do want the list to grow starting with very common and moving to less common – it is a way to get more value with our limited bandwidth to vet the licenses)

 

Then more is better.

 

SPDX is looking for volunteers to submit additional licenses that meet the above criteria.

 

To nominate a license, provide this info: http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-added

 

Legal team: I can help with the reviews of proposed licenses, although I am not available until the end of July. 

 

Tom

 

Tom Incorvia

tom.incorvia@...

Direct: (512) 340-1336

 

 

-----Original Message-----
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Bob Gobeille
Sent: Thursday, June 28, 2012 1:50 PM
To: Bradley M. Kuhn
Cc: SPDX-legal; spdx@...
Subject: Re: "Scope" of licenses to be covered by SPDX

 

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@...

_______________________________________________

Spdx-legal mailing list

Spdx-legal@...

https://lists.spdx.org/mailman/listinfo/spdx-legal

 

This message has been scanned by MailController - portal1.mailcontroller.co.uk

This message has been scanned by MailController.

 


Re: "Scope" of licenses to be covered by SPDX

Kevin P. Fleming <kpfleming@...>
 

On 06/28/2012 01:10 PM, Bradley M. Kuhn wrote:
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
SPDX files don't require that the licenses they refer to be present in the "SPDX License List". The license that you find in a source file can be represented on its own in the SPDX file. The primary purpose of the license list is to provide consistent names for the commonly used licenses, provide standard texts and (eventually) provide a mechanism for automated matching of license text gathered from source files against these standard licenses.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org


Re: "Scope" of licenses to be covered by SPDX

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


Re: "Scope" of licenses to be covered by SPDX

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


Re: "Scope" of licenses to be covered by SPDX

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


Re: "Scope" of licenses to be covered by SPDX

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


Re: "Scope" of licenses to be covered by 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


Re: "Scope" of licenses to be covered by SPDX

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


Thursday SPDX General Meeting Reminder

Philip Odence
 

A few upfront items:
  • At the end of Thursday's meeting Ibrahim Haddad from the Linux Foundation will brief us on the recently announced Barcode Tracker and will explain how complementary it is with SPDX.
  • We have booked a room for the afternoon of Tuesday, Aug 28 for a Face to Face at LinuxCon (San Diego). Note that it is the day before the conference commences. Please let Scott Lamons (scott.lamons@...) know if you can make it.
  • The Business Team has done some great work refining the SPDX Mission Statements. http://spdx.org/wiki/spdx-vision-mission-statements-final-draft The drive behind this has been to support the Tech Team in prioritizing features for future releases. The next step for the Business Team will be to review and update the team's charter; stay tuned as we want to make sure we're all in synch on the focus of the various teams and how we interact.

Meeting Time: June 28, 8am PST / 10 am CST / 11am EST / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html

Conf call dial-in:
Conference code:  7812589502
Toll-free dial-in number (U.S. and Canada):  (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of toll free numbers can be found: 
https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNumber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF

 
Administrative Agenda
Attendance
Approve minutes: not yet posted.

Technical Team Report - Kate
Legal Team Report - Jilayne
Business Team Report – Jack/Scott

Cross Functional Issues
Website Update – Steve Cropper
FOSS Barcode Tracker Presentation- Ibrahim Haddad


FOSS term for contracts

RUFFIN MICHEL
 

"Possibly" is not a term you want to use in a contract because it means something and its contrary. For instance we had problems of defining the i) definition of FOSS-for-contracts (I put the definition at the end of the mail for convenience) on the term "but not limited to" because we wanted to included in i) some non OSI compliant open-source-like license: some SW coming in open source form but with specific constraints for instance beerware (you have to offer a beer to the copyright owner if you meet him/her). Note that beerware license might be OSI compliant it is just that nobody has made the request to OSI 8-). And we want that to be acceptable to companies in a legal framework. We cannot limit us on this i) to the 60 or 70 OSI compliant licenses.

We thought to a lot of things:

- "Downloadable software": does not work we have contract for proprietary software for which we pay and the software is downloadable however it is not entering in the FOSS-contract definition.
- "unpaid third party software": does not work. We have software part of the FOSS-contract definition which come with a paying license and OSI compliant licenses (for instance linux distribution form Linux distributors).
- "Software not coming through procurement". Same as above
- "Software without an explicit signature of a contract or license". Same as above
- "software for which we cannot negotiate conditions". That does not work with proprietary software coming for free (ii) we have sometimes negotiated special conditions.
- ...

Perhaps we should say "Free of cost Software and/or Open source-like software" and noted it F&|OSS (& is the logical "and" and "|" is the logical "or" symbols used in some programming languages and mathematic). Note that I am rather in favor of keeping the world "open source" in this name because it is the major aim for this definition even if it is broader.

Note I am happy in this discussion that we do not focus on the definition by itself. It seems that the definition is clear enough to everybody and the scope is clear.

Finally, I think that this current thread shows the need for standardizing this wording. Since 2007 that we put that clauses in our contracts, we discussed any world of these clauses with hundreds of companies each time implying lawyers, procurement, technical people in both companies, that's a huge effort but so far nobody challenged us really on the term "FOSS" 8-).

Michel

"Free and/or Open Source Software" or "FOSS" means (i) software provided to Licensor royalty-free in source code form, under a license including, but not limited to, one approved by the Open Source Initiative (OSI http://www.opensource.org/) or (ii) proprietary software provided to Licensor royalty-free in binary code form, under an end user license agreement that is accepted without a signature, or (iii) shareware provided to Licensor free of initial charge, such as on a trial basis, but where a fee may become due once the user decides to use the software beyond the trial period, or (iv) public domain software

Michel.Ruffin@Alcatel-Lucent.com, 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

-----Message d'origine-----
De : spdx-bounces@lists.spdx.org [mailto:spdx-bounces@lists.spdx.org] De la part de Philip Odence
Envoyé : lundi 25 juin 2012 13:19
À : koohgoli@protecode.com; spdx@lists.spdx.org
Objet : Re: Spdx Digest, Vol 22, Issue 33

Good one!

On 6/22/12 4:57 PM, "Mahshad Koohgoli" <koohgoli@protecode.com> wrote:

How about
"Possibly Licensed Unpaid Software" - PLUS ?!

Then we can have FOSSPLUS :)

-----Original Message-----
From: McGlade, Debra [mailto:dmcglade@qualcomm.com]
Sent: 22-June-12 4:50 PM
To: RUFFIN, MICHEL (MICHEL); koohgoli@protecode.com; spdx@lists.spdx.org
Subject: RE: Spdx Digest, Vol 22, Issue 33

How about:

"Possibly, Might-be free Software" (PMS)

:)

-Debbie

-----Original Message-----
From: spdx-bounces@lists.spdx.org [mailto:spdx-bounces@lists.spdx.org] On
Behalf Of RUFFIN, MICHEL (MICHEL)
Sent: Friday, June 22, 2012 1:05 PM
To: koohgoli@protecode.com; spdx@lists.spdx.org
Subject: RE: Spdx Digest, Vol 22, Issue 33

None of this expression is covering proprietary software delivered free of
cost but with an EULA, except the last one but it is not very accurate

Michel.Ruffin@Alcatel-Lucent.com, 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



-----Message d'origine-----
De : spdx-bounces@lists.spdx.org [mailto:spdx-bounces@lists.spdx.org] De
la
part de Mahshad Koohgoli Envoyé : vendredi 22 juin 2012 21:29 À :
spdx@lists.spdx.org Objet : RE: Spdx Digest, Vol 22, Issue 33

PDC- Public Domain Code?
PAS- Publicly Accessible Software
CAS- Community Accessible Software?
GAC- Generally Accessible Code?

-----Original Message-----
From: spdx-bounces@lists.spdx.org [mailto:spdx-bounces@lists.spdx.org] On
Behalf Of spdx-request@lists.spdx.org
Sent: 22-June-12 3:21 PM
To: spdx@lists.spdx.org
Subject: Spdx Digest, Vol 22, Issue 33

Send Spdx mailing list submissions to
spdx@lists.spdx.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.spdx.org/mailman/listinfo/spdx
or, via email, send a message with subject or body 'help' to
spdx-request@lists.spdx.org

You can reach the person managing the list at
spdx-owner@lists.spdx.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Spdx digest..."


Today's Topics:

1. RE: "Scope" of licenses to be covered by SPDX (Mike Milinkovich)


----------------------------------------------------------------------

Message: 1
Date: Fri, 22 Jun 2012 15:21:22 -0400
From: "Mike Milinkovich" <mike.milinkovich@eclipse.org>
To: "'RUFFIN, MICHEL \(MICHEL\)'" <michel.ruffin@alcatel-lucent.com>,
<Soeren_Rabenstein@asus.com>, <mjherzog@nexb.com>,
<spdx@lists.spdx.org>
Subject: RE: "Scope" of licenses to be covered by SPDX
Message-ID: <038e01cd50ac$35a4eb50$a0eec1f0$@eclipse.org>
Content-Type: text/plain; charset="iso-8859-1"

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@alcatel-lucent.com]
Sent: June-22-12 2:58 PM
To: mike.milinkovich@eclipse.org; Soeren_Rabenstein@asus.com;
mjherzog@nexb.com; spdx@lists.spdx.org
Subject: RE: "Scope" of licenses to be covered by SPDX



Ok now we have an understanding, any suggestion ?



Michel.Ruffin@Alcatel-Lucent.com, 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@eclipse.org]
Envoy? : vendredi 22 juin 2012 20:43
? : RUFFIN, MICHEL (MICHEL); Soeren_Rabenstein@asus.com;
mjherzog@nexb.com;
spdx@lists.spdx.org 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@alcatel-lucent.com]
Sent: June-22-12 1:55 PM
To: mike.milinkovich@eclipse.org; Soeren_Rabenstein@asus.com;
mjherzog@nexb.com; spdx@lists.spdx.org
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@Alcatel-Lucent.com, 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@eclipse.org]
<mailto:%5bmailto:mike.milinkovich@eclipse.org%5d>
Envoy? : vendredi 22 juin 2012 19:25
? : Soeren_Rabenstein@asus.com; RUFFIN, MICHEL (MICHEL);
mjherzog@nexb.com;
spdx@lists.spdx.org 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@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?.



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.spdx.org/pipermail/spdx/attachments/20120622/7d7b16b7/attach
me
nt.html>

------------------------------

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


End of Spdx Digest, Vol 22, Issue 33
************************************

_______________________________________________
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
_______________________________________________
Spdx mailing list
Spdx@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx


Re: Spdx Digest, Vol 22, Issue 33

Philip Odence
 

Good one!

On 6/22/12 4:57 PM, "Mahshad Koohgoli" <koohgoli@protecode.com> wrote:

How about
"Possibly Licensed Unpaid Software" - PLUS ?!

Then we can have FOSSPLUS :)

-----Original Message-----
From: McGlade, Debra [mailto:dmcglade@qualcomm.com]
Sent: 22-June-12 4:50 PM
To: RUFFIN, MICHEL (MICHEL); koohgoli@protecode.com; spdx@lists.spdx.org
Subject: RE: Spdx Digest, Vol 22, Issue 33

How about:

"Possibly, Might-be free Software" (PMS)

:)

-Debbie

-----Original Message-----
From: spdx-bounces@lists.spdx.org [mailto:spdx-bounces@lists.spdx.org] On
Behalf Of RUFFIN, MICHEL (MICHEL)
Sent: Friday, June 22, 2012 1:05 PM
To: koohgoli@protecode.com; spdx@lists.spdx.org
Subject: RE: Spdx Digest, Vol 22, Issue 33

None of this expression is covering proprietary software delivered free of
cost but with an EULA, except the last one but it is not very accurate

Michel.Ruffin@Alcatel-Lucent.com, 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



-----Message d'origine-----
De : spdx-bounces@lists.spdx.org [mailto:spdx-bounces@lists.spdx.org] De
la
part de Mahshad Koohgoli Envoyé : vendredi 22 juin 2012 21:29 À :
spdx@lists.spdx.org Objet : RE: Spdx Digest, Vol 22, Issue 33

PDC- Public Domain Code?
PAS- Publicly Accessible Software
CAS- Community Accessible Software?
GAC- Generally Accessible Code?

-----Original Message-----
From: spdx-bounces@lists.spdx.org [mailto:spdx-bounces@lists.spdx.org] On
Behalf Of spdx-request@lists.spdx.org
Sent: 22-June-12 3:21 PM
To: spdx@lists.spdx.org
Subject: Spdx Digest, Vol 22, Issue 33

Send Spdx mailing list submissions to
spdx@lists.spdx.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.spdx.org/mailman/listinfo/spdx
or, via email, send a message with subject or body 'help' to
spdx-request@lists.spdx.org

You can reach the person managing the list at
spdx-owner@lists.spdx.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Spdx digest..."


Today's Topics:

1. RE: "Scope" of licenses to be covered by SPDX (Mike Milinkovich)


----------------------------------------------------------------------

Message: 1
Date: Fri, 22 Jun 2012 15:21:22 -0400
From: "Mike Milinkovich" <mike.milinkovich@eclipse.org>
To: "'RUFFIN, MICHEL \(MICHEL\)'" <michel.ruffin@alcatel-lucent.com>,
<Soeren_Rabenstein@asus.com>, <mjherzog@nexb.com>,
<spdx@lists.spdx.org>
Subject: RE: "Scope" of licenses to be covered by SPDX
Message-ID: <038e01cd50ac$35a4eb50$a0eec1f0$@eclipse.org>
Content-Type: text/plain; charset="iso-8859-1"

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@alcatel-lucent.com]
Sent: June-22-12 2:58 PM
To: mike.milinkovich@eclipse.org; Soeren_Rabenstein@asus.com;
mjherzog@nexb.com; spdx@lists.spdx.org
Subject: RE: "Scope" of licenses to be covered by SPDX



Ok now we have an understanding, any suggestion ?



Michel.Ruffin@Alcatel-Lucent.com, 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@eclipse.org]
Envoy? : vendredi 22 juin 2012 20:43
? : RUFFIN, MICHEL (MICHEL); Soeren_Rabenstein@asus.com;
mjherzog@nexb.com;
spdx@lists.spdx.org 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@alcatel-lucent.com]
Sent: June-22-12 1:55 PM
To: mike.milinkovich@eclipse.org; Soeren_Rabenstein@asus.com;
mjherzog@nexb.com; spdx@lists.spdx.org
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@Alcatel-Lucent.com, 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@eclipse.org]
<mailto:%5bmailto:mike.milinkovich@eclipse.org%5d>
Envoy? : vendredi 22 juin 2012 19:25
? : Soeren_Rabenstein@asus.com; RUFFIN, MICHEL (MICHEL);
mjherzog@nexb.com;
spdx@lists.spdx.org 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@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?.



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.spdx.org/pipermail/spdx/attachments/20120622/7d7b16b7/attach
me
nt.html>

------------------------------

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


End of Spdx Digest, Vol 22, Issue 33
************************************

_______________________________________________
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


Re: "Scope" of licenses to be covered by SPDX

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


Re: FOSS clauses for contracts & fora for discussing it (was Re: Clarification regarding "FSF legal network")

Ibrahim Haddad <ibrahim@...>
 

Hi Everyone,

I just got back from europe. Please give me a couple days to catch up on my email and I will reply early next week.

Ibrahim


On Wed, Jun 20, 2012 at 8:55 AM, Philip Odence <podence@...> wrote:
Michel,
Your idea about standard FOSS clauses might fit into the charter of the
Linux Foundation Open Compliance Program.
http://www.linuxfoundation.org/programs/legal/compliance  (To head off the
question, the program is for open source compliance in general, not
limited to Linux.)
I am cc'ing Ibrahim who coordinates that for the LF with hopes that he
will weigh in. (I believe, he's out of the office this week, so he may not
respond immediately.)
Phil

On 6/18/12 9:30 AM, "RUFFIN, MICHEL (MICHEL)"
<michel.ruffin@...> wrote:

>Thank you very much for your quick answer and suggestions.
>
>My goal is not only to standardize the legal text of our FOSS clauses. It
>is also to
>1) raise awareness about being able to provide the list of FOSS in a
>proprietary product or in a big FOSS distribution (Linux, Open BSD,
>Eclipse, Swing, ...)
>2) Big companies are reluctant to provide you a FOSS list. They are more
>or less in compliance but some of them provide you a URL on their web
>site on which you find the list of their products and for each of them a
>several megabyte ASCII File with the list of all licenses of FOSS on
>their products. That's not usable at all. If one of their customer want
>to resale their product in one of its products it has to read everything
>and identify every action to comply "Ha yes this is apache1.1 so I have
>to put some acknowledgement in my documentation!".
>3) Liability clause/money damage. Big companies are not always accepting
>it. I have been told by some of their lawyers: how can we guarantee that
>we are not doing mistakes this is a too complex world. If you take a
>Linux distribution with 6000 package and you look at packages, you can
>find hundreds of various licenses in one package. Small companies accept
>more easily these conditions, but they have not too much money. How do
>you value the fact that you have to stop to distribute your product or
>the potential issue to have to disclose your source code while it was not
>planned and it is not your fault.
>4) .... a lot of other issues
>
>I would challenge the SPDX members to take a Linux standard distribution
>and to provide me the SPDX file at file level (not at package level). Yes
>open source is great but it is also really a Bazard 8-) and with maven
>and cloud computing it will become worse.
>
>So the effort is tremendous and cannot be done by one company, it should
>be shared. And it is time to start.
>
>So I will study the short terms options you propose. But for the long
>term, I would to start to create a new mailing list of people who are
>intereted in discussing FOSS governance standardization issues (to start:
>FOSS clause in contracts, having a common Database under a king of
>Wikipedia contribution system describing FOSS IP, having public tutorial
>on FOSS issues, and perhaps things like lobbying to reduce the number of
>FOSS licenses, ...); Martin, can we use the FOSS Bazaar infrastructure to
>create the mailing list?
>
>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
>
>
>-----Message d'origine-----
>De : Bradley M. Kuhn [mailto:bkuhn@...]
>Envoyé : vendredi 15 juin 2012 19:49
>À : RUFFIN, MICHEL (MICHEL)
>Cc : spdx@...
>Objet : FOSS clauses for contracts & fora for discussing it (was Re:
>Clarification regarding "FSF legal network")
>
>Michel,
>
>I went back and read your previous posts from February on this topic,
>(as I mentioned earlier in this thread, I don't follow SPDX closely.  I
>mostly joined this thread (Kibo-like) when the term "FSF" came up).
>
>However, having gotten fully caught up on your posts, I think your idea
>is a useful one.  In my work doing GPL compliance, I have often had
>situations where a downstream company has violated and they never
>actually had clear clauses in their contract with upstream about what
>would happen if a FLOSS license was violated.  This has caused mass
>confusion and made it more difficult to get the company into compliance.
>
>In a few cases, there *were* clearly developed clauses like the ones you
>mention, and it did indeed facilitate more easy work getting to compliance
>on the product.
>
>So, I'm thus supportive of your effort to
>promulgate these standardized clauses regarding use of FLOSS in
>upstream/downstream contracts.  Meanwhile, I wish I had a better
>suggestion for you of where to talk about the idea....
>
>RUFFIN, MICHEL (MICHEL) wrote at 08:14 (EDT):
>>what is your suggestion for me to try to standardize these FOSS
>>clauses. What organization? I have tried SPDX, I have been advised to
>>go to FSFE legal network.
>
>... as others have suggested, FOSS Bazaar might be a good place.
>
>> I have join the FSFE legal network and I tried to get a reaction
>>without success except "that's interesting"
>
>It sounds like in addition to my objections to ftf-legal, that there
>were other issues: your description seems to indicate ftf-legal wasn't
>that interested in this giving useful feedback and collaboration on the
>issue!
>
>> Any suggestion of organization that would have a look?
>
>There was once a forum called "open-bar", which is at:
>https://www.open-bar.org/discussion.html but it's mostly defunct AFAICT.
>The mailing lists disappeared a while back.  The last email from I have
>in my archives for <discuss-general@...> was Tuesday 18 Mar
>2008.
>
>Meanwhile, as part of the FOSDEM 2012 Legal and Policy track I
>coordinated along with Tom Marble, Richard Fontana, and Karen Sandler,
>we had some very brief discussions about creating a forum for discussion
>that was open and available to all about these issues (like open bar
>was).  However, it's unclear if, as a community, we're at a "build it
>and they would come" moment, so none of us from the FOSDEM 2012 track
>have put effort in.
>
>Thus, at the moment, I think FOSS Bazaar is probably the best place to
>host this sort of discussion venue, so I think if you want an immediate
>discussion about your specific topic, that's probably the place to
>start.
>
>Also, as a medium-term suggestion, I strongly recommend you propose a
>talk for (a) the FOSDEM 2013 Legal & Policy track, or (b) LinuxCon
>(sadly, North America CFP just closed), or (c) at the 2013 Linux
>Collaboration Summit Legal Track (which Richard Fontana & I will
>co-chair) about the topic.  Speaking about the topic at conferences is a
>great way to get interest and feedback.
>
>Long term, as a community, it'd be good to solve this general issue: the
>fora that exist for Legal, Licensing and Policy issues in Free Software
>are scattered across many different places, and some of the primary ones
>are closed clubs.  I've been witnessing the problem for years and I
>don't have a good solution to propose to solve it.
>--
>   -- bkuhn
>_______________________________________________
>Spdx mailing list
>Spdx@...
>https://lists.spdx.org/mailman/listinfo/spdx




--
Ibrahim Haddad, Ph.D.
The Linux Foundation 
Cell:  +1 (408) 893-1122


741 - 760 of 1456