Date   

Re: new version of License List uploaded

Jilayne Lovejoy <Jlovejoy@...>
 

Thanks, Tom.  Do you (or anyone on the list) have any thoughts on the 3 items highlighted in yellow below?

 

Jilayne Lovejoy  |  Corporate Counsel

jlovejoy@...

 

720 240 4545  |  phone

720 240 4556  |  fax

1 888 OpenLogic  |  toll free

www.openlogic.com

 

OpenLogic, Inc.

Headquarters, Broomfield, Colorado 80021


From: Tom Incorvia [mailto:tom.incorvia@...]
Sent: Wednesday, January 26, 2011 11:04 AM
To: Kim Weins; Jilayne Lovejoy; SPDX
Subject: RE: new version of License List uploaded

 

Hi Jilayne,

 

On the legal call today I offered to do a last look at the Debian / SPDX license name differences.

 

I agree with Kim:

 

The exclusion of “.0” in cases where the license issuer does not use that makes sense

 

The Debian abbreviation of the GNU Free Documentation License is a far more common use that the FDL that we chose, so let’s use GFDL.

 

Tom

 

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850

 

From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Kim Weins
Sent: Monday, January 17, 2011 10:44 AM
To: Jilayne Lovejoy; SPDX
Subject: Re: new version of License List uploaded

 

Thanks Jilayne

After looking this over, we are pretty well aligned with two exceptions

  1. Debian excludes the “.0” on ends of versions (eg Apache-1 instead of Apache-1.0)
  2. Debian uses GFDL for GNU Free Documentation License and we use FDL.


I would be fine with changing out names to match Debian on both the items above.  That makes it easy and saves us from trying to negotiate changes.

Kim


On Fri 1/14/11 2:00 PM, "Jilayne Lovejoy" <Jlovejoy@...> wrote:

I just uploaded v1.5 of the License List spreadsheet and accompanying guidelines/notes document to the SPDX website here:
http://spdx.org/wiki/working-version-license-list
 
This version reflects adds a column for comparison to the Debian short name protocols and list (http://dep.debian.net/deps/dep5/) and some comments where there were differences in license long names.  Notes/observations/questions re: these additions below (this is also listed on the Word doc associated with the license):
 

  • Column added for comparison to Debian license list short names:
    • If left blank, then license not on Debian list
    • If short name is the same, then “same” entered in this column
    • If short name is different, then Debian variation entered here
      • Debian uses Expat license instead of MIT; Expat is not on SPDX list ??
      • Debian identifies GPL font and SSL exception which were not on SPDX list; font exception was added to SPDX list
        • Should we add the SSL exception? It looks like a suggestion more than a standard exception based on the info contained in a link.  I’ve never seen this one before – anyone have any thoughts on this?
      • SPDX list had exceptions not on Debian list, but short names using Debian short names rules listed in this column
      • Debian lists Perl as a license, but this is really a disjunctive licensing situation with either GPL or Artistic; it doesn’t seem like “Perl” should be listed as a separate license in this case as there are other scenarios like this
      • Added other GFDL v1.1 and v1.3 to license list, as they were missing
        • Debian lists GNU Free Documentation License with no invariant sections à did not add this… ??


 
Jilayne Lovejoy |  Corporate Counsel
jlovejoy@...
 
720 240 4545  |  phone
720 240 4556  |  fax
1 888 OpenLogic  |  toll free
www.openlogic.com <http://www.openlogic.com>
 
OpenLogic, Inc.
Headquarters, Broomfield, Colorado 80021
 


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

 

Click here to report this email as spam.

This message has been scanned for viruses by MailController.


Re: new version of License List uploaded

Tom Incorvia
 

-          Regarding the MIT license.  This is a VERY well-established license, #4 on the Black Duck site, is listed in expected form the OSI site, etc.  I have not seen variants other than the copyright year and copyright holders template holders.  I strongly recommend that we maintain the MIT license without associating it with Expat.   No opinion on whether to list Expat or not – I have not used it, but am in the commercial world

 

-          Regarding Perl – since there is not a Perl license or Perl license stack (like Python), I suggest that we not list Perl as a license.

 

-          I am not familiar with the general use of the OpenSSL exception, but it is certainly distinct from any exceptions that we currently have listed.  Here is a reference from Debian Legal on this exception.  Does anyone have experience with this exception and know if the text is consistent?

 

-          Anyone else familiar with GPL Font – not me? 

 

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850

 

From: Jilayne Lovejoy [mailto:Jlovejoy@...]
Sent: Wednesday, January 26, 2011 1:34 PM
To: Tom Incorvia; Kim Weins; SPDX
Subject: RE: new version of License List uploaded

 

Thanks, Tom.  Do you (or anyone on the list) have any thoughts on the 3 items highlighted in yellow below?

 

Jilayne Lovejoy  |  Corporate Counsel

jlovejoy@...

 

720 240 4545  |  phone

720 240 4556  |  fax

1 888 OpenLogic  |  toll free

www.openlogic.com

 

OpenLogic, Inc.

Headquarters, Broomfield, Colorado 80021


From: Tom Incorvia [mailto:tom.incorvia@...]
Sent: Wednesday, January 26, 2011 11:04 AM
To: Kim Weins; Jilayne Lovejoy; SPDX
Subject: RE: new version of License List uploaded

 

Hi Jilayne,

 

On the legal call today I offered to do a last look at the Debian / SPDX license name differences.

 

I agree with Kim:

 

The exclusion of “.0” in cases where the license issuer does not use that makes sense

 

The Debian abbreviation of the GNU Free Documentation License is a far more common use that the FDL that we chose, so let’s use GFDL.

 

Tom

 

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850

 

From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Kim Weins
Sent: Monday, January 17, 2011 10:44 AM
To: Jilayne Lovejoy; SPDX
Subject: Re: new version of License List uploaded

 

Thanks Jilayne

After looking this over, we are pretty well aligned with two exceptions

  1. Debian excludes the “.0” on ends of versions (eg Apache-1 instead of Apache-1.0)
  2. Debian uses GFDL for GNU Free Documentation License and we use FDL.


I would be fine with changing out names to match Debian on both the items above.  That makes it easy and saves us from trying to negotiate changes.

Kim


On Fri 1/14/11 2:00 PM, "Jilayne Lovejoy" <Jlovejoy@...> wrote:

I just uploaded v1.5 of the License List spreadsheet and accompanying guidelines/notes document to the SPDX website here:
http://spdx.org/wiki/working-version-license-list
 
This version reflects adds a column for comparison to the Debian short name protocols and list (http://dep.debian.net/deps/dep5/) and some comments where there were differences in license long names.  Notes/observations/questions re: these additions below (this is also listed on the Word doc associated with the license):
 

  • Column added for comparison to Debian license list short names:
    • If left blank, then license not on Debian list
    • If short name is the same, then “same” entered in this column
    • If short name is different, then Debian variation entered here
      • Debian uses Expat license instead of MIT; Expat is not on SPDX list ??
      • Debian identifies GPL font and SSL exception which were not on SPDX list; font exception was added to SPDX list
        • Should we add the SSL exception? It looks like a suggestion more than a standard exception based on the info contained in a link.  I’ve never seen this one before – anyone have any thoughts on this?
      • SPDX list had exceptions not on Debian list, but short names using Debian short names rules listed in this column
      • Debian lists Perl as a license, but this is really a disjunctive licensing situation with either GPL or Artistic; it doesn’t seem like “Perl” should be listed as a separate license in this case as there are other scenarios like this
      • Added other GFDL v1.1 and v1.3 to license list, as they were missing
        • Debian lists GNU Free Documentation License with no invariant sections à did not add this… ??


 
Jilayne Lovejoy |  Corporate Counsel
jlovejoy@...
 
720 240 4545  |  phone
720 240 4556  |  fax
1 888 OpenLogic  |  toll free
www.openlogic.com <http://www.openlogic.com>
 
OpenLogic, Inc.
Headquarters, Broomfield, Colorado 80021
 


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

 

Click here to report this email as spam.

This message has been scanned for viruses by MailController.


Re: new version of License List uploaded

Richard Fontana
 

Delurking ...

On Wed, Jan 26, 2011 at 12:07:02PM -0800, Tom Incorvia wrote:
- Regarding the MIT license.  This is a VERY well-established license,
#4 on the Black Duck site, is listed in expected form the OSI site, etc.  I
have not seen variants other than the copyright year and copyright holders
template holders.  I strongly recommend that we maintain the MIT license
without associating it with Expat.   No opinion on whether to list Expat or not
– I have not used it, but am in the commercial world
This is rather contrary to our experiences at Red Hat. We've
encountered fascinatingly numerous language variants on the
MIT/X11/Expat license family in the wild (though you might want to
argue that these shouldn't be treated as one family). I once started
to make an effort to catalogue all the different variants you find in
just one project (Kerberos) and gave up (maybe out of boredom, but
still...). Tom Callaway has probably made the most careful attempt to
collect the various licenses that seem to often be labelled "MIT". (No
question that the direction is towards standardization on the version
that OSI happens to list as a template, or something close to that.)
Some of the variants one finds in this license family are arguably
legally significant. For what it's worth, Red Hat and Fedora use the
"MIT" label to describe all of the various licenses in this family in
package metadata.

I would assume that Black Duck listing the MIT license as #4 involves
to at least some degree collecting a bunch of variants.

- Regarding Perl – since there is not a Perl license or Perl license
stack (like Python), I suggest that we not list Perl as a license.
I wonder if the value in doing so lies in the fact that Perl modules
are commonly licensed as "under the same terms as Perl itself", which
most often probably means (Artistic 1.0 or GPL) but is sometimes
unclear.

- I am not familiar with the general use of the OpenSSL exception, but
it is certainly distinct from any exceptions that we currently have listed. 
Here is a reference from Debian Legal on this exception.  Does anyone have
experience with this exception and know if the text is consistent?
We have experience with it. Not sure there is one canonical version
but I think the one in that debian-legal posting is the one that the
FSF recommended at one time. I believe that there is a different
version that was updated for GPLv3, but I may be misremembering. I
seem to remember writing my own version (while at Red Hat) at one
point.

Conceptually, the OpenSSL exception is one of a class of GPL linking
exceptions.

- Anyone else familiar with GPL Font – not me? 
The GPL font exception, which originates with the FSF, is pretty well
known. We've used and encountered it in certain forms at Red Hat. It
is possible the FSF has an updated version for GPLv3, or will someday.

- Richard


Re: new version of License List uploaded

Tom Incorvia
 

Perhaps we stick with the version of MIT that is listed at http://www.opensource.org/licenses/mit-license.php as a way to include this license in the standard list -- it is too commonly used to exclude. To work with the variations, we treat it like the BSD variants where there must be an exact match other than Copyright (c) <year> <copyright holders>. Tom

Tom Incorvia
tom.incorvia@...
Direct:  (512) 340-1336
Mobile: (408) 499 6850

-----Original Message-----
From: Richard Fontana [mailto:rfontana@...]
Sent: Wednesday, January 26, 2011 2:29 PM
To: Tom Incorvia
Cc: Jilayne Lovejoy; Kim Weins; SPDX
Subject: Re: new version of License List uploaded

Delurking ...

On Wed, Jan 26, 2011 at 12:07:02PM -0800, Tom Incorvia wrote:
- Regarding the MIT license.  This is a VERY well-established license,
#4 on the Black Duck site, is listed in expected form the OSI site, etc.  I
have not seen variants other than the copyright year and copyright holders
template holders.  I strongly recommend that we maintain the MIT license
without associating it with Expat.   No opinion on whether to list Expat or not
– I have not used it, but am in the commercial world
This is rather contrary to our experiences at Red Hat. We've
encountered fascinatingly numerous language variants on the
MIT/X11/Expat license family in the wild (though you might want to
argue that these shouldn't be treated as one family). I once started
to make an effort to catalogue all the different variants you find in
just one project (Kerberos) and gave up (maybe out of boredom, but
still...). Tom Callaway has probably made the most careful attempt to
collect the various licenses that seem to often be labelled "MIT". (No
question that the direction is towards standardization on the version
that OSI happens to list as a template, or something close to that.)
Some of the variants one finds in this license family are arguably
legally significant. For what it's worth, Red Hat and Fedora use the
"MIT" label to describe all of the various licenses in this family in
package metadata.

I would assume that Black Duck listing the MIT license as #4 involves
to at least some degree collecting a bunch of variants.

- Regarding Perl – since there is not a Perl license or Perl license
stack (like Python), I suggest that we not list Perl as a license.
I wonder if the value in doing so lies in the fact that Perl modules
are commonly licensed as "under the same terms as Perl itself", which
most often probably means (Artistic 1.0 or GPL) but is sometimes
unclear.

- I am not familiar with the general use of the OpenSSL exception, but
it is certainly distinct from any exceptions that we currently have listed. 
Here is a reference from Debian Legal on this exception.  Does anyone have
experience with this exception and know if the text is consistent?
We have experience with it. Not sure there is one canonical version
but I think the one in that debian-legal posting is the one that the
FSF recommended at one time. I believe that there is a different
version that was updated for GPLv3, but I may be misremembering. I
seem to remember writing my own version (while at Red Hat) at one
point.

Conceptually, the OpenSSL exception is one of a class of GPL linking
exceptions.

- Anyone else familiar with GPL Font – not me? 
The GPL font exception, which originates with the FSF, is pretty well
known. We've used and encountered it in certain forms at Red Hat. It
is possible the FSF has an updated version for GPLv3, or will someday.

- Richard


This message has been scanned for viruses by MailController - www.MailController.altohiway.com


Agenda for Thursday's SPDX General Meeting

Philip Odence
 

Meeting Time: January 27, 8am PDT / 10 am CDT / 11am EDT / 16: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

Web:
I've been including this only for attendance purposes, but the size of the calls has been such that we can do it the ol' fashioned way.
 
Administrative Agenda
Attendance

Technical Team Report - Kate

Business Team Report - Kim/JohnE
Beta program update

Legal Team Report - Rockett/Karen
File license fields
DEP5 license names

Cross Functional Issues - Phil


Action Items

Most of the action items belong with the Teams. So, in addition to statusing, we will dispatch them to the respective teams and will not continue to track in this meeting. Action items for this meeting will be cross functional.
• Kate/Kim- Draft example for LF Member Counsel; include XML and spreadsheet. PENDING
• MichaelH/Rockett- Write up and share postion on "reporting" vs. "interpreting. PENDING
• MartinM- Report back on # of people on respective mailing lists. DONE, BUT LET'S KEEP UPDATING
• Jilayne- Add column to license list showing Deb5 short names for comparison.




L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502


FYI: Invitation: SPDX Beta Orientation Call

Kim Weins
 

Hi everyone!
 
I sent the following invite to all of the people that have expressed an interest in being a Beta site.  All SPDX members are welcome to attend as well.  This orientation will be held during the normal business call time slot on Feb 3rd.

If you know of other potential beta sites, please let me know and feel free to invite them to this meeting.  Let me know if you have any more questions.

Kim



------ Forwarded Message
From: Kim Weins <kim.weins@...>
Date: Thu, 27 Jan 2011 08:41:21 -0700
To: <scott.lamons@...>, <Mark.Gisi@...>, <brad_dixon@...>, <mgia3940@...>, <tcallawa@...>, <Soeren_Rabenstein@...>, <guillaume.rousseau@...>
Conversation: Invitation: SPDX Beta Orientation Call
Subject: Invitation: SPDX Beta Orientation Call

Hello to all of our SPDX Beta Sites!

You are invited to attend a SPDX Beta Orientation call on Thursday Feb 3rd, 11am ET/8am PT.
 
The call and web meeting (details below) will cover an overview of SPDX and the details of the Beta Program, including:
 
-What we ask of Beta participants
-What support you will receive from SPDX
-Tools
-Schedules and Timing
 
If you are planning to participate in the Beta Program, we would encourage you to invite any other colleagues from your company that would be involved in the Beta testing -- including technical and/or legal resources.  If you know which trading partner (supplier or customer) you will be working with for the Beta program, please invite them to this meeting as well.
 
Please RSVP to Kim Weins, Beta Program Manager.  Kim.weins@....  If you are not able to make this time, please let me know and we can arrange another time for your orientation.
 
Regards
Kim Weins and the SPDX Team
 
 
Call Details
ID: 2404502
 
Dial in:
US 866-740-1260
Find Int’l numbers at  http://www.readytalk.com/support/international-numbers.php
 
Web meeting
www.readytalk.com <http://www.readytalk.com>
ID: 2404502

------ End of Forwarded Message


interesting variant of the GPL

dmg
 

Armijn called my attention to the following license (part of Amarok):
Notice how the "upgrade" option allows for licenses other than the FSF
approved,

hence this file is not GPLv2+ only, but GPLv2+(according to FSF and KDE)


* This program is free software; you can redistribute it and/or modify it under *
* the terms of the GNU General Public License as published by the Free Software *
* Foundation; either version 2 of the License, or (at your option) version 3 or *
* any later version accepted by the membership of KDE e.V. (or its successor approved *
* by the membership of KDE e.V.), which shall act as a proxy defined in Section 14 of *
* version 3 of the license. *





--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .


Re: interesting variant of the GPL

Kim Weins
 

Interesting. This would get handled as a "non-standard" license for now.

Kim

On Fri 1/28/11 5:43 AM, "D M German" <dmg@...> wrote:



Armijn called my attention to the following license (part of Amarok):
Notice how the "upgrade" option allows for licenses other than the FSF
approved,

hence this file is not GPLv2+ only, but GPLv2+(according to FSF and KDE)


* This program is free software; you can redistribute it and/or modify it
under *
* the terms of the GNU General Public License as published by the Free
Software *
* Foundation; either version 2 of the License, or (at your option) version 3
or *
* any later version accepted by the membership of KDE e.V. (or its successor
approved *
* by the membership of KDE e.V.), which shall act as a proxy defined in
Section 14 of *
* version 3 of the license.
*





--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


Re: interesting variant of the GPL

Armijn Hemel <armijn@...>
 

On 01/28/2011 03:38 PM, Kim Weins wrote:
Interesting. This would get handled as a "non-standard" license for now.
Right now it is:

"GPLv2 or GPLv3, but we might add more licenses if the members of KDE e.V. choose to do so".

For those of you who don't know: KDE e.V. is the German non-profit that handles all the administrative and legal things for KDE. KDE developers can apply for a membership. Existing members have to vote before new developers get accepted as members.

KDE is an interesting project and they have taken good care of their legal stuff, except for the occasional slip (it went unnoticed for a year that there are GPLv3+ files in Amarok, which is advertised as GPLv2+, I caught it with Ninka).

armijn

--
------------------------------------------------------------------------
armijn@... || http://www.gpl-violations.org/
------------------------------------------------------------------------


reminder, spdx-tech weekly meeting today 2/1/11

Bill Schineller
 

Just a reminder that the spdx-tech group meets on
Tuesdays at 16:00 GMT (8:00AM Pacific Time, 11:00 AM Eastern Time). 
Toll-free dial-in number (U.S. and Canada): (877) 435-0230;
International dial-in number: (253) 336-6732;
Conference code: 7833942033. 
URL: http://blackducksoftware.na6.acrobat.com/spdxrdf/

All are welcome.

We generally review what's been going around in our mailing list
https://fossbazaar.org/pipermail/spdx-tech/

with an eye towards formalizing proposals
http://spdx.org/wiki/proposals

Requested Agenda Items for 2/1/11:

A- scrubbing/prioritizing the bug list
B- the files property[1] and the owl ontology[2] proposals:
[1]: http://bugs.linux-foundation.org/show_bug.cgi?id=628
[2]: http://bugs.linux-foundation.org/show_bug.cgi?id=633





Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com


License List v1.6 - uploaded

Jilayne Lovejoy <Jlovejoy@...>
 

Hi All,

 

I’ve just uploaded v1.6 of the License List.  This reflects the following changes:

-          License Identifiers (short names) updated to be consistent with Debian short names

-          No changes in our full names

-          Deleted the “Recognized Exceptions” column – this wasn’t being used anyway

 

Other differences that were not changed:

-          we use “MIT” – Debian uses “Expat” as license name

-          Debian calls “IBM Common Public License” what SPDX calls “IBM Public License” and a separate “Common Public License” – left as is; my observation/understanding is that IPL and CPL are different (yet similar)

 

One remaining thing that Debian caught here (http://wiki.debian.org/Proposals/CopyrightFormat)

à SPDX has a LGPL+ which is to denote where LGPL is listed as the applicable license, with no version whatsoever indicated.  We do not have the equivalent for GPL – should we add the former or get rid of the latter?  

Seems to me this scenario would essentially be the same as the oldest LGPL/GPL “or later.”  In this situation, the SPDX file creator could choose to take the extra step of determining the earliest copyright notice and then apply that logic to determine which version of GPL/LGPL could applied at the earliest, record this as the “Concluded License,” and comment accordingly in the “License Comment” section.  Anyone want to concur or contradict, so I can make the change and re-upload again?

 

Cheers,

 

Jilayne Lovejoy  |  Corporate Counsel

jlovejoy@...

 

720 240 4545  |  phone

720 240 4556  |  fax

1 888 OpenLogic  |  toll free

www.openlogic.com

 

OpenLogic, Inc.

Headquarters, Broomfield, Colorado 80021

 


Re: License List v1.6 - uploaded

Philippe Ombredanne
 

On 2011-02-02 21:21, Jilayne Lovejoy wrote:
Hi All,
I’ve just uploaded v1.6 of the License List. This reflects the following
changes:
Thanks!
One remaining thing that Debian caught here
(http://wiki.debian.org/Proposals/CopyrightFormat)

à SPDX has a LGPL+ which is to denote where LGPL is listed as the
applicable license, with no version whatsoever indicated. We do not have
the equivalent for GPL – should we add the former or get rid of the latter?
imho we should have support for both GPL and LGPL there.
Note that I think that the + there is misleading. its means "or later" elsewhere and here it means "any version". I would rather go with GPL and LGPL than GPL+ and LGPL+
See comment below.


Seems to me this scenario would essentially be the same as the oldest
LGPL/GPL “or later.”
In this situation, the SPDX file creator could
choose to take the extra step of determining the earliest copyright
notice and then apply that logic to determine which version of GPL/LGPL
could applied at the earliest, record this as the “Concluded License,”
and comment accordingly in the “License Comment” section. Anyone want to
concur or contradict, so I can make the change and re-upload again?
I would disagree. The GPL and LGPL are very clear there:

In the GPL 2.0 for instance:
"9. [...] If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation."

There is no determination of facts that can be done. There is a choice. The earliest copyright would not be a relevant fact but rather your interpretation.



Cheers,

**Jilayne Lovejoy** | Corporate Counsel

jlovejoy@... <mailto:jlovejoy@...>

720 240 4545 | phone

720 240 4556 | fax

1 888 OpenLogic | toll free

www.openlogic.com <http://www.openlogic.com>

OpenLogic, Inc.

Headquarters, Broomfield, Colorado 80021



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

--
Cordially
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com


Re: License List v1.6 - uploaded

Jilayne Lovejoy <Jlovejoy@...>
 

Ah! Great point, Philippe, I forgot about that important detail in Sec. 9 of the GPL. In which case, my first scenario - that the oldest GPL/LGPL "or later" license on our list - would apply where no version is indicated. In this case, it seems that our LGPL+ should be taken off the list as its superfluous, agreed? I can't think of a scenario where having this listed separately is of any use, but I could be missing something...

Jilayne Lovejoy | Corporate Counsel
jlovejoy@...

720 240 4545 | phone
720 240 4556 | fax
1 888 OpenLogic | toll free
www.openlogic.com

OpenLogic, Inc.
Headquarters, Broomfield, Colorado 80021

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Philippe Ombredanne
Sent: Wednesday, February 02, 2011 2:21 PM
To: spdx@...
Subject: Re: License List v1.6 - uploaded

On 2011-02-02 21:21, Jilayne Lovejoy wrote:
Hi All,
I've just uploaded v1.6 of the License List. This reflects the following
changes:
Thanks!
One remaining thing that Debian caught here
(http://wiki.debian.org/Proposals/CopyrightFormat)

à SPDX has a LGPL+ which is to denote where LGPL is listed as the
applicable license, with no version whatsoever indicated. We do not have
the equivalent for GPL - should we add the former or get rid of the latter?
imho we should have support for both GPL and LGPL there.
Note that I think that the + there is misleading. its means "or later"
elsewhere and here it means "any version". I would rather go with GPL
and LGPL than GPL+ and LGPL+
See comment below.


Seems to me this scenario would essentially be the same as the oldest
LGPL/GPL "or later."
In this situation, the SPDX file creator could
choose to take the extra step of determining the earliest copyright
notice and then apply that logic to determine which version of GPL/LGPL
could applied at the earliest, record this as the "Concluded License,"
and comment accordingly in the "License Comment" section. Anyone want to
concur or contradict, so I can make the change and re-upload again?
I would disagree. The GPL and LGPL are very clear there:

In the GPL 2.0 for instance:
"9. [...] If the Program does not specify a version number of this
License, you may choose any version ever published by the Free Software
Foundation."

There is no determination of facts that can be done. There is a choice.
The earliest copyright would not be a relevant fact but rather your
interpretation.



Cheers,

**Jilayne Lovejoy** | Corporate Counsel

jlovejoy@... <mailto:jlovejoy@...>

720 240 4545 | phone

720 240 4556 | fax

1 888 OpenLogic | toll free

www.openlogic.com <http://www.openlogic.com>

OpenLogic, Inc.

Headquarters, Broomfield, Colorado 80021



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

--
Cordially
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


a way to specify the license of the SPDX file?

dmg
 

is there a way to specify the license of an SPDX file? In other words,
if I create a SPDX file, and I want to attach a license to it (for
example, that the file cannot be further distributed) how do I do it
_inside_ the own SPDX file?

thanks!

--dmg

--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .


Re: a way to specify the license of the SPDX file?

kate.stewart@...
 

There's a proposed field that the legal team has requested, and will be added into the first section, that lets you specify the license the author is willing to have their name associated with the data. (tricky wording deliberate ;) - you can't license facts it appears )

Field will be either a license short form, or reference to text included in the non-standard license section - that the author wants to assert, if its not going to be made available under one of the standard licenses.

Legal team was looking into recommending/creating a default license to be used, to make it easy to do the right thing in terms of sharing.

HTH, Kate

--- On Thu, 2/3/11, D M German <dmg@...> wrote:

From: D M German <dmg@...>
Subject: a way to specify the license of the SPDX file?
To: spdx@...
Date: Thursday, February 3, 2011, 12:53 AM

is there a way to specify the license of an SPDX file? In
other words,
if I create a SPDX file, and I want to attach a license to
it (for
example, that the file cannot be further distributed) how
do I do it
_inside_ the own SPDX file?

thanks!

--dmg

--
--
Daniel M. German           
     
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


Re: a way to specify the license of the SPDX file?

Philip Odence
 

Daniel,
That work is in process; the Legal Team is working on it. You may want to get on their distribution list. 
The rough plan is to add a field to the spec which is the license for the data in the file. There will be a default license, probably an standard open source license, but the author of the file will have the ability to specify a different one.
Phil


L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502

On Feb 3, 2011, at 1:53 AM, D M German wrote:


is there a way to specify the license of an SPDX file? In other words,
if I create a SPDX file, and I want to attach a license to it (for
example, that the file cannot be further distributed) how do I do it
_inside_ the own SPDX file?

thanks!

--dmg

--
--
Daniel M. German                  
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


Re: a way to specify the license of the SPDX file?

Philip Odence
 

Whoops, I've got to learn to read ahead.



On Feb 3, 2011, at 2:32 AM, <kate.stewart@...> <kate.stewart@...> wrote:

There's a proposed field that the legal team has requested, and will be added into the first section, that lets you specify the license the author is willing to have their name associated with the data. (tricky wording deliberate ;) - you can't license facts it appears )

Field will be either a license short form, or reference to text included in the non-standard license section - that the author wants to assert, if its not going to be made available under one of the standard licenses.

Legal team was looking into recommending/creating a default license to be used, to make it easy to do the right thing in terms of sharing.

HTH,  Kate

--- On Thu, 2/3/11, D M German <dmg@...> wrote:

From: D M German <dmg@...>
Subject: a way to specify the license of the SPDX file?
To: spdx@...
Date: Thursday, February 3, 2011, 12:53 AM

is there a way to specify the license of an SPDX file? In
other words,
if I create a SPDX file, and I want to attach a license to
it (for
example, that the file cannot be further distributed) how
do I do it
_inside_ the own SPDX file?

thanks!

--dmg

--
--
Daniel M. German           
     
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx

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


Re: Purpose of licensing info

Esteban Rockett <mgia3940@...>
 

SPDX Legal Workstream Members:

Below please find the revised Section 5.3 text discussed during our last meeting, for your comment.

I will post the same to Bugzilla later today.

Many thanks,

Rockett

***

Proposal: Section 5.3 (License(s)) of the SPDX Specification will become 3 fields:


5.3a Concluded License(s)

5.3a.1 Purpose: This field contains the license the reviewer has concluded as governing the file, if it can be determined. The options to populate this field are limited to: (a) the SPDX standardized license short form identifier; this should be used when the concluded license is on the SPDX standardized license short list; (b) a verbatim copy of the concluded license when the concluded license is not on the SPDX standardized license short list (“non-standard license”); (c) “UNDETERMINED”; this should be used (i) if the reviewer has attempted to but cannot reach a reasonable objective determination of the concluded license, or (ii) if the reviewer is uncomfortable concluding a license, despite some license information being available; or (d) left blank; this should be used if the reviewer has made no attempt to arrive at a concluded license. With respect to “a” and “b” above, if there is more than one concluded license, all should be recited. If the recipient has a choice of multiple licenses, then each of the choices should be recited as a "disjunctive" license. With respect to “c”, a written explanation must be provided in the License Comments field below. Lastly, if the Conclude License(s) conflicts with the License Information in File, a written explanation must be provided in the License Comments field below.

5.3a.2 Intent: Here, the intent is to have the reviewer analyze the License Information in File and other objective information, e.g., “COPYING FILE”, etc., together with the results from any scanning tools, to arrive at a reasonably objective conclusion as to what license is governing the file.

5.3a.3 Cardinality: Mandatory, one or many.

5.3a.4 Tag: "LicenseConcluded:"

5.3a.5 RDF: TBD (include Disjunctive form here)

5.3a.6 Data Format: <short form identifier in Appendix I> | "FullLicense"-N | UNDETERMINED | (left blank)

5.3a.7 Example:

LicenseConcluded: GPL-2.0



5.3b License Information in File

5.3b.1 Purpose: This field contains the license information actually recited in the file, if any. Any license information not actually in the file, e.g., “COPYING FILE”, etc., should not be reflected in this field. This information is most commonly found in the header of the file, although it may be in other areas of the actual file. The options to populate this field are limited to: (a) the SPDX standardized license short form identifier; this should be used when the license is on the SPDX standardized license short list and has no ambiguous or superfluous text; (b) a verbatim copy of the license information the file when the license information in the file is not on the SPDX standardized license short list (“non-standard license”); (c) “NONE”; this should be used if the actual file contains no license information; or (d) left blank; this should be used if the reviewer has not examined the contents of the actual files. With respect to “a” and “b” above, if license information for more than one license is recited in the file, all should be reflected in this field. If the license information offers the recipient a choice of licenses, then each of the choices should be recited as a "disjunctive" licenses.

5.ba.2 Intent: Here, the intent is to provide the reader with the license information actually in the file, as compared to the Concluded License field.

5.3b.3 Cardinality: Mandatory, one or many.

5.3b.4 Tag: "LicenseInformation:"

5.3b.5 RDF: TBD (not including disjunctive form, if multiple many should be specified )

5.3b.6 Data Format: <short form identifier in Appendix I> | "FullLicenseInformation"-N | NONE | (left blank)

5.3b.7 Example:

LicenseInformation: GPL-2.0

LicenseInformation: FullLicenseInformation



5.3c License Comments

5.3c.1 Purpose: This field is a detailed description of the analysis and any relevent background references that went in to arriving at the Concluded License(s) for a file. If the Concluded License(s) does not match the License Information in File, such rationale must be recited by the reviewer in this field. This field is also where an explanation must be recited if the reviewer placed “UNDETERMINED” as the Conclude License(s).

5.3c.2 Intent: Here, the intent is to provide the reader with a detailed explanation of how the Concluded License(s) was determined if it does not match the License Information in File, is marked “UNDETERMINED”, or other helpful information for the reader relevant to determining the license of the file.

5.3c.3 Cardinality: Optional, single instance

5.3c.4 Tag: "LicenseComments:"

5.3c.5 RDF: TBD

5.3c.6 Data Format: free form text than can span multiple lines, preceded with <text> and ending with </text>.

5.3c.7 Example: LicenseComments: <text> The Concluded License(s) was taken from the package level that the file was included in. This information was found in the COPYING.txt file in the xyz directory. </text>

***


Re: Purpose of licensing info

kate.stewart@...
 

Hi Rockett,
Thanks for pulling this all together, and summarizing. :) Sorry I couldn't be on the last call. In reading through the summary couple of thoughts occurred.

Can I suggest LicenseSeen rather than LicenseInformation, as the name for that field? Information could get us back into those ambiguous name discussions for someone seeing this for the first time - using Seen might make it a bit more explicit that this is what was seen in the file for those not doing a detailed reading of the spec. ;)

In the case when there is a fragement or some non-standardized license, the references in the non-standard-license should be made with the same syntax, specifically "LICENSE"-N, Introducing new varients of keywords in the Non Standard License section, will cause complications I think, and lead to redundancy - ie. do I use "FullLicense-1" and "FullLicenseInformation-1" to refer to same license or not, are there multiple entries, etc.

Thanks, Kate

--- On Mon, 2/7/11, Esteban Rockett <mgia3940@...> wrote:

From: Esteban Rockett <mgia3940@...>
Subject: Re: Purpose of licensing info
To: spdx@...
Date: Monday, February 7, 2011, 11:31 AM
SPDX Legal Workstream Members:

Below please find the revised Section 5.3 text discussed
during our last meeting, for your comment.

I will post the same to Bugzilla later today.

Many thanks,

Rockett

***

Proposal:  Section 5.3 (License(s)) of the SPDX
Specification will become 3 fields:


5.3a Concluded License(s)

5.3a.1 Purpose:  This field contains the license the
reviewer has concluded as governing the file, if it can be
determined.  The options to populate this field are
limited to: (a) the SPDX standardized license short form
identifier; this should be used when the concluded license
is on the SPDX standardized license short list; (b) a
verbatim copy of the concluded license when the concluded
license is not on the SPDX standardized license short list
(“non-standard license”); (c) “UNDETERMINED”; this
should be used (i) if the reviewer has attempted to but
cannot reach a reasonable objective determination of the
concluded license, or (ii) if the reviewer is uncomfortable
concluding a license, despite some license information being
available; or (d) left blank; this should be used if the
reviewer has made no attempt to arrive at a concluded
license.  With respect to “a” and “b” above, if
there is more than one concluded license, all should be
recited.  If the recipient has a choice of multiple
licenses, then each of the choices should be recited as a
"disjunctive" license.  With respect to “c”, a
written explanation must be provided in the License Comments
field below.  Lastly, if the Conclude License(s)
conflicts with the License Information in File, a written
explanation must be provided in the License Comments field
below.

5.3a.2 Intent:  Here, the intent is to have the
reviewer analyze the License Information in File and other
objective information, e.g., “COPYING FILE”, etc.,
together with the results from any scanning tools, to arrive
at a reasonably objective conclusion as to what license is
governing the file.

5.3a.3 Cardinality:  Mandatory, one or many.

5.3a.4 Tag: "LicenseConcluded:"

5.3a.5 RDF: TBD  (include Disjunctive form here)

5.3a.6 Data Format: <short form identifier in Appendix
I> | "FullLicense"-N | UNDETERMINED | (left blank)

5.3a.7 Example:

LicenseConcluded: GPL-2.0



5.3b License Information in File

5.3b.1 Purpose: This field contains the license information
actually recited in the file, if any.  Any license
information not actually in the file, e.g., “COPYING
FILE”, etc., should not be reflected in this field. 
This information is most commonly found in the header of the
file, although it may be in other areas of the actual
file.  The options to populate this field are limited
to: (a) the SPDX standardized license short form identifier;
this should be used when the license is on the SPDX
standardized license short list and has no ambiguous or
superfluous text; (b) a verbatim copy of the license
information the file when the license information in the
file is not on the SPDX standardized license short list
(“non-standard license”); (c) “NONE”; this should be
used if the actual file contains no license information; or
(d) left blank; this should be used if the reviewer has not
examined the contents of the actual files.  With
respect to “a” and “b” above, if license information
for more than one license is recited in the file, all should
be reflected in this field.  If the license information
offers the recipient a choice of licenses, then each of the
choices should be recited as a "disjunctive" licenses.

5.ba.2 Intent:  Here, the intent is to provide the
reader with the license information actually in the file, as
compared to the Concluded License field.

5.3b.3 Cardinality:  Mandatory, one or many.

5.3b.4 Tag: "LicenseInformation:"

5.3b.5 RDF: TBD (not including disjunctive form, if
multiple many should be specified )

5.3b.6 Data Format: <short form identifier in Appendix
I> | "FullLicenseInformation"-N | NONE | (left blank)

5.3b.7 Example:

LicenseInformation: GPL-2.0

LicenseInformation: FullLicenseInformation



5.3c License Comments

5.3c.1 Purpose: This field is a detailed description of the
analysis and any relevent background references that went in
to arriving at the Concluded License(s) for a file.  If
the Concluded License(s) does not match the License
Information in File, such rationale must be recited by the
reviewer in this field.  This field is also where an
explanation must be recited if the reviewer placed
“UNDETERMINED” as the Conclude License(s).

5.3c.2 Intent:  Here, the intent is to provide the
reader with a detailed explanation of how the Concluded
License(s) was determined if it does not match the License
Information in File, is marked “UNDETERMINED”, or other
helpful information for the reader relevant to determining
the license of the file.

5.3c.3 Cardinality: Optional, single instance

5.3c.4 Tag: "LicenseComments:"

5.3c.5 RDF: TBD

5.3c.6 Data Format: free form text than can span multiple
lines, preceded with <text> and ending with
</text>.

5.3c.7 Example: LicenseComments: <text> The Concluded
License(s) was taken from the package level that the file
was included in.  This information was found in the
COPYING.txt file in the xyz directory. </text>

***


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


Re: Purpose of licensing info

Peter Williams <peter.williams@...>
 

On Mon, Feb 7, 2011 at 10:31 AM, Esteban Rockett <mgia3940@...> wrote:

Below please find the revised Section 5.3 text discussed during our
last meeting, for your comment.
I think Package should have an optional concluded licensing field also.

5.3a.4 Tag: "LicenseConcluded:"
Given that the value of this property is potentially a disjunctive set
of licenses (or license sets) would "Licensing" be better than
"License" in the name?

Also, -- and this one is just a matter of curiosity -- why was that
word order chosen? "ConcludedLicense" seems like a more idiomatic
formulation.

Peter

PS: I missed the last call so i apologize if these issues where covered there.

301 - 320 of 1598