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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

Philip Odence wrote at 08:32 (EDT):

There's a section in an SPDX file called Other Licensing Information
Detected to handle licenses not on the standard list.

I'm aware of that. My point was that presumably for the most commonly
used programs, an SPDX file author wouldn't have to do this extra work.
Isn't it SPDX's intent to make it easy to write SPDX files for the
most common programs?

Has anyone written an SPDX file for GCC versions before the RTL
Exception 3.1? If so, for it to be accurate, I'm sure it must have pages
of extra licensing information, since it's now been shown that no accurate
GCC license is currently on the SPDX license list.

Bob Gobeille wrote at 14:50 (EDT) on Thursday:

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:

Great work, Bob and Camille!

Philip wrote:

Hope that increases your comfort that the SPDX standard can handle-non
standard licenses.

Is your argument that GCC's license isn't standard? Classpath's license
isn't either?

Again, I'm left wondering if SPDX expects upstream to do this work?
As mentioned in my previous email, that seems like a bad plan to me.

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.

That's great. I hope SPDX will in turn take submissions from Fossology, which
is able to find and catalog a lot of these licenses, to update SPDX's
license list. Again, I'm happy to help in cataloging the GCC licenses
if folks need assistance in understanding the patchwork of exceptions
pre RTL-Exception-3.1. I offer the same help for any Conservancy member
project, too.

Thanks again to Bob and HP, for setting the right trend by releasing a
scanning tool under a Free Software license. I hope others will follow
HP's lead in the area of software freedom.
--
-- bkuhn
_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal

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



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

Peter,
Yes it is. My point is to get it off the general list which is not for
working discussions. You are welcome to include the tech team list on the
discussion (which I can't do as I am not on the tech list).
Phil

On 6/29/12 11:19 AM, "Peter Williams" <peter.williams@...> 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.

Peter
openlogic.com

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

On Fri, Jun 29, 2012 at 10:19 AM, Peter Williams
<peter.williams@...> 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
_______________________________________________
Spdx-tech mailing list
Spdx-tech@...
https://lists.spdx.org/mailman/listinfo/spdx-tech

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

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

(I fully support Phil's previous response in terms of how to use the
various mailing lists; he has done a great job of moderating that. It is
GREAT to see all this interest and discussion, regardless of what list it
begins and ends on and those of us who have been long-involved with SPDX
are happy to see broader interest from new or newish people and companies.
But, it seems as though some basic misunderstandings are getting repeated
due to not fully understanding how the spec works, the purpose of the
license list, etc. So, one quick clarification to all lists, as the
previous explanations did not seem to make it through across the board.)


On 6/29/12 9:58 AM, "Peter Bigot" <bigotp@...> wrote:

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.

But it DOES have the flexibility to represent ANY license found
accurately. It just may not have the capability to do so succinctly, in
terms of using an SPDX License List short identifier.

Info on how to join the three workgroup mailing lists can be found here,
in case anyone missed that:
http://spdx.org/wiki/spdx/participation-guidelines



Jilayne Lovejoy, OpenLogic
(SPDX Legal Work Group co-lead)


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

On 6/29/12 8:50 AM, "Bradley M. Kuhn" <bkuhn@...> wrote:

Philip wrote:

Hope that increases your comfort that the SPDX standard can handle-non
standard licenses.

Is your argument that GCC's license isn't standard? Classpath's license
isn't either?

NO! That is not what Phil meant. There is no judgment implied by
"standard" or "non-standard" (but the fact that a judgement could be
implicated it is exactly why I lobbied early on to lose that terminology).


The SPDX License List is just that - a list of licenses. We started by
making sure we had all of the OSI licenses, then people involved suggested
other commonly found open source licenses. And while maybe the list
doesn't look like much to the first-time looker, to get to this point
(already at it's 16th version) meant: deciding upon fields to include and
how to define those fields; deciding on naming and short identifiers
protocols for consistency; finding urls for each license; finding the
actual text of the license; checking whether that license is (or was) OSI
approved; coordinating with OSI when they adopted the short identifiers,
so all links and short identifiers cross-checked; generating the HTML
pages for each license; making sure the license text was correct (and
didn't lose crucial formatting); otherwise catching human errors in the
various processes; etc., etc.... This is actually quite a bit of work and
has been done by a small number of people.

Do we need to expand the list? YES! Do we know we would like to
collaborate with other lists such that the SPDX License List lines up with
other such lists and vice versa? YES! I think we are all in agreement on
that last point.

The issue here isn't knowing what needs to be done, it is having the
people-power to get it done sooner rather than later. (yes, I know, I'm
beginning to sound like a broken record... and with that, I will put away
my soap box and hope to hear some new voices on the next legal call :)



Jilayne Lovejoy (SPDX Legal work group co-lead)
Corporate Counsel | OpenLogic, Inc.
jlovejoy@... | 720 240 4545



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

Jilayne Lovejoy wrote at 16:28 (EDT) on Friday:

But it DOES have the flexibility to represent ANY license found
accurately.

... and one can create a Gödel number or a Turing Machine tape that can
compute any function that's computable, but to create a non-trivial one
by hand takes months of work. In other words, the argument that a
system is *flexible* enough to cover an entire complexity space is only
an argument for its completeness, not its usability.

It just may not have the capability to do so succinctly,

It's not SPDX's intention to make it possible to represent licenses of
key GNU/Linux infrastructural programs succinctly?

Peter Bigot wrote at 11:58 (EDT) on Friday:

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.

+1.

Indeed, I thought that, by now, folks were already writing SPDX files.
I'd assume GCC would be one of the very first packages that you all
would want to write an SPDX file for.

Jilayne Lovejoy wrote:

This is actually quite a bit of work and has been done by a small
number of people.

Neither Peter nor I are denying that work done so far was time
consuming, detailed work. Most licensing and compliance work is so,
even for the most seemingly trivial matters.

I think the most interesting point coming out of this discussion is that
it seems pretty clear that no one has actually tried to use SPDX for a
real world example yet.

Frankly, I actually hope that's true. The more grim story I've
suspected since the Linux Collaboration Summit legal track last April is
that many so-called "compliance" companies are now using SPDX as an
internal standard for their proprietary products. If that suspicion is
true, SPDX will surely suffer the usual problem of a standard without
adequate Free Software tools: it will be useless to the Free Software
community because it's most extensive and complete use is by proprietary
products. TCP/IP would've probably failed if the best implementation of
it hadn't been Sam's and Kirk's Free Software implementation.

Peter Bigot wrote at 11:58 (EDT) on Friday:

Missing a "BMKL" is one thing.

Indeed, I've co-written enough licenses including the GCC RTL exception
and the Affero GPL. I'm thus unlikely to write the BMKL, and I'd call
it bkuhn-license if I did anyway. :)

Jilayne Lovejoy wrote at 15:23 (EDT) on Friday:

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

Please don't underestimate my offer. I'm not offering *merely* input;
I'm offering assistance to *do* work on the GCC licensing cataloging to
repair the existing flaws in SPDX's license list that Peter identified.
Perhaps you've conflated the fact that I didn't offer to *lead* such
work as an indication that I wasn't offering to *do* any actual work?

I have been making offers to help SPDX for some time, such as my offer
to help shepherd patches carrying SPDX files in upstream projects where
I might have enough influence to help get your SPDX patches accepted
(e.g., BusyBox). That's substantial work (and a significant spending of
political capital) that I've offered to SPDX as well.
--
-- bkuhn
_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal

... and one can create a Gödel number or a Turing Machine tape that can
compute any function that's computable, but to create a non-trivial one
by hand takes months of work.  In other words, the argument that a
system is *flexible* enough to cover an entire complexity space is only
an argument for its completeness, not its usability.

Come on Bradley. Please be realistic/serious or people will stop
responding to your emails labeling you as a troll (and perhaps even
remove you from this list--disclaimer I am just another participant).

By the way, Godel numbers do not represent functions, they represent
logic statements. By the way #2, a TM machine tape does not compute
anything, and I guarantee you, it will take you an infinite time and
resources
to build a Turing Machine tape for the SIMPLEST of TMs. (please....
read the description of a Turing Machine in this 100 Year of the
Birthday of Turing, you will find it enlightening ).

SPDX is not a system of logic not a computational model, so it makes
no sense at all to compare it against either Godel numbers of TMs.

Now back to SPDX.

You can extract and document, using SPDX, licensing information in a
way that is well defined.

This, in my opinion, is the great value of SPDX as it currently
stands. Currently it is a great wrapper format.

Agreeing on the names of the licenses will be difficult, and as
pointed out, some names in SPDX are not ideal (and perhaps wrong)
but at least I now have a method to document licensing info in a
project. Compare that to the way that Debian (as you pointed out
before) documents licensing.

This part, I see is agreeing on the actual contents of each of its fields.

In my opinion, the best way to deal with the complexities that you
have described before is using a compositional model for licenses
(which I have described in the past in this list).

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

dmg wrote at 13:17 (EDT) on Sunday:

Please be realistic/serious

I apologize if my analogy bothered you. I'm completely serious, and my
entire point here is to raise realistic scenarios (e.g., GCC) about
where SPDX might be used.

By the way, Godel numbers do not represent functions, they represent
logic statements.

See http://en.wikipedia.org/wiki/Computable_function for info on why I
used the word "function" in that context. I learned the concepts using that
terminology in graduate school in the 1990s; I know other terminology
is also widely used, but I'm happy to defer to you this since you have a PhD
and I only have a Master's degree. :)

But, you're right in that this part of the thread is now off-topic. I
only used that analogy to point out that the difficulty of representing
common licenses is a serious issue for SPDX. SPDX is complete, but very
difficult to use for real-world situations. That's why I thought my
analogy was appropriate. Again, I apologize if you find it
inappropriate.

You can extract and document, using SPDX, licensing information in a
way that is well defined.

Again, I agree that SPDX appears to be complete, in that it is, as you
say, ...

This, in my opinion, is the great value of SPDX as it currently
stands. Currently it is a great wrapper format.

... a wrapper format that can be used to represent any particular
licensing situation of a package.

Agreeing on the names of the licenses will be difficult, and as

It's more than just naming; it's an issue that it appears to be quite
difficult to represent some common licensing situations accurately for
common infrastructural pieces.

I've nevertheless offered my help and offer it again, to figure out how
to do this for GCC. It's probably a good test case.

Compare that to the way that Debian (as you pointed out before)
documents licensing.

At the risk of getting flamed again for making an analogy, I'll point out
that SPDX is a bit like the OSI model of network layering right now.
It's heavily structured and wasn't designed in conjunction with an
implementation. SPDX needs a good Free Software implementation.
Indeed, if someone were to go through and build a patchset for Debian to
switch its /usr/doc/*/copyright fields to use SPDX -- even for just for,
say, a Debian base installation you get with deboostrap -- that would be
a huge "real world" scenario to shake out issues with SPDX and give
something useful back to upstream.

Has anyone thought of inviting Stefano Zacchiroli to this list to discuss
that idea?
--
-- bkuhn
_______________________________________________
Spdx-legal mailing list
Spdx-legal@...
https://lists.spdx.org/mailman/listinfo/spdx-legal

Bradley:
this is an excellent offer and idea. Please go for it!