Date   

Re: Today's Agenda Legal WorkStream

kate.stewart@...
 


Thanks Daniel,

    Will look into adding this after we can get the guidance from the lawyers as to what varients are equivalent.  ;)  

Kate


--- On Wed, 3/23/11, dmg <dmg@...> wrote:

From: dmg <dmg@...>
Subject: Re: Today's Agenda Legal WorkStream
To: "Esteban Rockett" <mgia3940@...>
Cc: spdx-legal@..., spdx@...
Date: Wednesday, March 23, 2011, 9:48 AM



On Wed, Mar 23, 2011 at 7:40 AM, Esteban Rockett <mgia3940@...> wrote:
Agenda Legal WorkStream

(4) Review and Discuss --- Guidelines for "Templatizing" licenses



I think it is going in the right direction. You should look at the way Ninka normalizes test  for in-file licenses (BSD, MIT, etc).
For the BSD and MIT variants the problems are not only spelling, but in some cases, variants in grammar: past vs present
tense, use of word "software", "product", "program", "library" in the same place.


SPDX: license equivalence rules

Peterson, Scott K (HP Legal) <scott.k.peterson@...>
 

Ths comment is NOT about what the normalization should be or what equivalences should be permitted. Rather, I suggest a different approach to how we represent the result of the agreed upon normalization/equivalence rules.

 

I suggest reconceiving "templatization" as defining "match rules".

 

Templatization seems to me to be a process of partially applying the match rules to take a step toward comparison. It is not apparent to me what the value is of giving that particular intermediate document special status.

 

I see a danger in two versions. Which contains the authoritative information? Whenever there are two, there is danger of them becoming misaligned.

 

There should be a single, canonical text. Applying the match rules against that canonical text and a candidate text would yield the authoritative answer to the question of whether the candidate text corresponds to the license represented by the canonical text.

 

Given the rules, anyone would be free to pre-process the canonical texts into whatever sorts of intermediate versions they thought would facilitate performance of their comparison tool. Choosing a particular intermediate version seems to add unnecessary complexity.

 

-- Scott

 


Re: Today's Agenda Legal WorkStream

Jilayne Lovejoy <jilayne.lovejoy@...>
 

I believe we already discussed this to some degree and decided that we would not enter the arena of word equivalents with the exception of spelling variations for known American-British English.  Although there are certainly plenty of words that seem “safe” to equate, that begins to feel like a slippery slope in terms of the potential for different meanings or the license author’s intent getting altered.  More specifically, many licenses have definitions for such words.  Past and present tense can also be tricky, both from deciding how and when it’s okay to use either tense.  All in all, I think it’s best to take a very conservative approach to what we will “replace” in terms of templatizing the licenses.  We can always expand, but it would be very hard to roll it back later on.  Just my two cents.

Certainly the BSD and Apache 1.1 licenses are problematic, because they are often verbatim with the exception of the author’s name in the third clause (BSD) and the third, fourth, and fifth clause (Apache 1.1) as well as the disclaimer sections for both.  We are working through how/where to capture this, as well as copyright notices in general, though.



Jilayne


On 3/23/11 10:11 AM, "Kate Stewart" <kate.stewart@...> wrote:


Thanks Daniel,

    Will look into adding this after we can get the guidance from the lawyers as to what varients are equivalent.  ;)   

Kate


--- On Wed, 3/23/11, dmg <dmg@...> wrote:

From: dmg <dmg@...>
Subject: Re: Today's Agenda Legal WorkStream
To: "Esteban Rockett" <mgia3940@...>
Cc: spdx-legal@..., spdx@...
Date: Wednesday, March 23, 2011, 9:48 AM



On Wed, Mar 23, 2011 at 7:40 AM, Esteban Rockett <mgia3940@... </mc/compose?to=mgia3940@...> > wrote:
Agenda Legal WorkStream

(4) Review and Discuss --- Guidelines for "Templatizing" licenses

Please goto:  http://spdx.org/wiki/guidelines-templatizing-licenses


I think it is going in the right direction. You should look at the way Ninka normalizes test  for in-file licenses (BSD, MIT, etc).
For the BSD and MIT variants the problems are not only spelling, but in some cases, variants in grammar: past vs present
tense, use of word "software", "product", "program", "library" in the same place.



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

Jilayne Lovejoy |  Corporate Counsel
jlovejoy@...

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

OpenLogic, Inc.
10910 W 120th Ave, Suite 450
Broomfield, Colorado 80021


Re: Today's Agenda Legal WorkStream

dmg
 



On Wed, Mar 23, 2011 at 9:48 AM, Jilayne Lovejoy <Jlovejoy@...> wrote:
I believe we already discussed this to some degree and decided that we would not enter the arena of word equivalents with the exception of spelling variations for known American-British English.  Although there are certainly plenty of words that seem “safe” to equate, that begins to feel like a slippery slope in terms of the potential for different meanings or the license author’s intent getting altered.  More specifically, many licenses have definitions for such words.  Past and present tense can also be tricky, both from deciding how and when it’s okay to use either tense.  All in all, I think it’s best to take a very conservative approach to what we will “replace” in terms of templatizing the licenses.  We can always expand, but it would be very hard to roll it back later on.  Just my two cents.


I agree. I wonder if a solution is to allow the specification of "variant" of a license. Perhaps a way to say: the closest license is this one, with a text similarity metric of X, and where the differences are  such and such. Otherwise a lot of BSD and MIT licensed files will be listed as unknown/other.


--dmg
 
Certainly the BSD and Apache 1.1 licenses are problematic, because they are often verbatim with the exception of the author’s name in the third clause (BSD) and the third, fourth, and fifth clause (Apache 1.1) as well as the disclaimer sections for both.  We are working through how/where to capture this, as well as copyright notices in general, though.



--
--dmg

---
Daniel M. German
http://turingmachine.org


Re: SPDX: license equivalence rules

Kate Stewart <kate.stewart@...>
 

Hi Scott,

On Wed, 2011-03-23 at 16:33 +0000, Peterson, Scott K (HP Legal) wrote:
Ths comment is NOT about what the normalization should be or what
equivalences should be permitted. Rather, I suggest a different
approach to how we represent the result of the agreed upon
normalization/equivalence rules.



I suggest reconceiving "templatization" as defining "match rules".
The problem is that the today the various tools have nothing to check
against to make sure that they are applying the rules correctly.

The templatized version is intended as a tool checker, that the right
substitutions can be recognized rather than as an alternate human
readable reference. The golden reference should always be whats on the
official public web site of a license - which is human readable. The
official authoritative version will be copied onto the SPDX web site
verbatim. The proposal is to have the processed version there as well,
and marked as such, so that when there are disagreements between various
tools doing license recognition and asserting the short form, they have
a common comparison point.

Its intended more like an answer sheet for a teacher administering a
test to students to know what answers are ok, and which aren't.

For instance, I believe that Daniel German (Ninka tool) and Bob
Gobeille (FOSSology tool) get together from time to time (or intended to
last I talked to them about it, last year) to talk about why their tools
don't recognize same licenses. Having a templatized license text would
aid future tool creators (open source as well as commercial vendors) to
check that they are able to recognize a license accurately before
asserting the short form.

It is meant to illustrates what should happen when the match rules are
applied.


Templatization seems to me to be a process of partially applying the
match rules to take a step toward comparison. It is not apparent to me
what the value is of giving that particular intermediate document
special status.
As a check for the tools, and to build confidence that the match rules
the spdx-legal team is comfortable, are applied consistently.


I see a danger in two versions. Which contains the authoritative
information? Whenever there are two, there is danger of them becoming
misaligned.
The authoritative version is the version on the project's public web
site. In some cases the OSI site has a copy and is used as the
authoritative version though.

We copy that version onto the SPDX web page for convenience, as well as,
the link to the authoritative public site we get this from.

On the SPDX web page, we'll also be adding the "templatized" version as
a convenience, after the rules have been applied to the original
authorized version, so folks can see what the results of applying the
match rules yields ("the answer sheet" for the test to continue with my
earlier analogy).


There should be a single, canonical text. Applying the match rules
against that canonical text and a candidate text would yield the
authoritative answer to the question of whether the candidate text
corresponds to the license represented by the canonical text.
The single canonical text will be copied verbatim (spaces,
capitalization, etc. ) intact from the authorative web site for that
license.

The templatized version is just the result of applying the match rules
to the authorative version.

We should definitely take care to make this VERY clear on the web site.


Given the rules, anyone would be free to pre-process the canonical
texts into whatever sorts of intermediate versions they thought would
facilitate performance of their comparison tool. Choosing a particular
intermediate version seems to add unnecessary complexity.
see comments above.

Kate


Re: SPDX: license equivalence rules

Peter Williams <peter.williams@...>
 

I think having some examples of text with the normalization rules applied is a good idea.  However those examples should be in the spec. Having to go to the registry to see examples will make it harder to implement the normalization algorithm.

If the only use of the normalized text for standard licenses is for example purposes, I don't think we really need to do all the licenses. Not having the normalized text in the registry would make its design easier. (The versioning issues are particularly non-trivial.)

Peter
Openlogic.com

On Mar 23, 2011 10:21 AM, "Kate Stewart" <kate.stewart@...> wrote:
> Hi Scott,
>
> On Wed, 2011-03-23 at 16:33 +0000, Peterson, Scott K (HP Legal) wrote:
>> Ths comment is NOT about what the normalization should be or what
>> equivalences should be permitted. Rather, I suggest a different
>> approach to how we represent the result of the agreed upon
>> normalization/equivalence rules.
>>
>>
>>
>> I suggest reconceiving "templatization" as defining "match rules".
>>
>
> The problem is that the today the various tools have nothing to check
> against to make sure that they are applying the rules correctly.
>
> The templatized version is intended as a tool checker, that the right
> substitutions can be recognized rather than as an alternate human
> readable reference. The golden reference should always be whats on the
> official public web site of a license - which is human readable. The
> official authoritative version will be copied onto the SPDX web site
> verbatim. The proposal is to have the processed version there as well,
> and marked as such, so that when there are disagreements between various
> tools doing license recognition and asserting the short form, they have
> a common comparison point.
>
> Its intended more like an answer sheet for a teacher administering a
> test to students to know what answers are ok, and which aren't.
>
> For instance, I believe that Daniel German (Ninka tool) and Bob
> Gobeille (FOSSology tool) get together from time to time (or intended to
> last I talked to them about it, last year) to talk about why their tools
> don't recognize same licenses. Having a templatized license text would
> aid future tool creators (open source as well as commercial vendors) to
> check that they are able to recognize a license accurately before
> asserting the short form.
>
> It is meant to illustrates what should happen when the match rules are
> applied.
>
>>
>> Templatization seems to me to be a process of partially applying the
>> match rules to take a step toward comparison. It is not apparent to me
>> what the value is of giving that particular intermediate document
>> special status.
>>
>
> As a check for the tools, and to build confidence that the match rules
> the spdx-legal team is comfortable, are applied consistently.
>
>>
>> I see a danger in two versions. Which contains the authoritative
>> information? Whenever there are two, there is danger of them becoming
>> misaligned.
>>
> The authoritative version is the version on the project's public web
> site. In some cases the OSI site has a copy and is used as the
> authoritative version though.
>
> We copy that version onto the SPDX web page for convenience, as well as,
> the link to the authoritative public site we get this from.
>
> On the SPDX web page, we'll also be adding the "templatized" version as
> a convenience, after the rules have been applied to the original
> authorized version, so folks can see what the results of applying the
> match rules yields ("the answer sheet" for the test to continue with my
> earlier analogy).
>
>>
>> There should be a single, canonical text. Applying the match rules
>> against that canonical text and a candidate text would yield the
>> authoritative answer to the question of whether the candidate text
>> corresponds to the license represented by the canonical text.
>>
>
> The single canonical text will be copied verbatim (spaces,
> capitalization, etc. ) intact from the authorative web site for that
> license.
>
> The templatized version is just the result of applying the match rules
> to the authorative version.
>
> We should definitely take care to make this VERY clear on the web site.
>
>>
>> Given the rules, anyone would be free to pre-process the canonical
>> texts into whatever sorts of intermediate versions they thought would
>> facilitate performance of their comparison tool. Choosing a particular
>> intermediate version seems to add unnecessary complexity.
>>
>
> see comments above.
>
> Kate
>
>
>
>
> _______________________________________________
> Spdx-legal mailing list
> Spdx-legal@...
> https://fossbazaar.org/mailman/listinfo/spdx-legal


Re: Today's Agenda Legal WorkStream

Jilayne Lovejoy <jilayne.lovejoy@...>
 

These variant licenses would simply end up needing to be added as a “nonstandard” license, meaning the SPDX generator would not be able to use the standardized SPDX license list shortname for that license, but it wouldn’t (shouldn’t) be tagged as unknown in such a case.


On 3/23/11 10:54 AM, "dmg" <dmg@...> wrote:



On Wed, Mar 23, 2011 at 9:48 AM, Jilayne Lovejoy <Jlovejoy@...> wrote:
I believe we already discussed this to some degree and decided that we would not enter the arena of word equivalents with the exception of spelling variations for known American-British English.  Although there are certainly plenty of words that seem “safe” to equate, that begins to feel like a slippery slope in terms of the potential for different meanings or the license author’s intent getting altered.  More specifically, many licenses have definitions for such words.  Past and present tense can also be tricky, both from deciding how and when it’s okay to use either tense.  All in all, I think it’s best to take a very conservative approach to what we will “replace” in terms of templatizing the licenses.  We can always expand, but it would be very hard to roll it back later on.  Just my two cents.


I agree. I wonder if a solution is to allow the specification of "variant" of a license. Perhaps a way to say: the closest license is this one, with a text similarity metric of X, and where the differences are  such and such. Otherwise a lot of BSD and MIT licensed files will be listed as unknown/other.


--dmg
 
Certainly the BSD and Apache 1.1 licenses are problematic, because they are often verbatim with the exception of the author’s name in the third clause (BSD) and the third, fourth, and fifth clause (Apache 1.1) as well as the disclaimer sections for both.  We are working through how/where to capture this, as well as copyright notices in general, though.



Jilayne Lovejoy |  Corporate Counsel
jlovejoy@...

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

OpenLogic, Inc.
10910 W 120th Ave, Suite 450
Broomfield, Colorado 80021


Re: Today's Agenda Legal WorkStream

Philip Odence
 

Yes, and let's not forget this same point when we are talking about the process of adding new license to the standard list. The discussion is never whether the license can be included in an SPDX file—it always can be—the only issue from the SPDX file creator's perspective is whether it matches a license on the standard list with a predefined short name, or whether they have to go the one extra step of including the license text in Section 4. Licensing Info and create their own local short name.

From: Jilayne Lovejoy <jilayne.lovejoy@...>
Date: Thu, 24 Mar 2011 17:26:20 -0400
To: dmg <dmg@...>, Jilayne Lovejoy <Jlovejoy@...>
Cc: Kate Stewart <kate.stewart@...>, "spdx-legal@..." <spdx-legal@...>, "spdx@..." <spdx@...>, Esteban Rockett <mgia3940@...>
Subject: Re: Today's Agenda Legal WorkStream

These variant licenses would simply end up needing to be added as a “nonstandard” license, meaning the SPDX generator would not be able to use the standardized SPDX license list shortname for that license, but it wouldn’t (shouldn’t) be tagged as unknown in such a case.


On 3/23/11 10:54 AM, "dmg" <dmg@...> wrote:



On Wed, Mar 23, 2011 at 9:48 AM, Jilayne Lovejoy <Jlovejoy@...> wrote:
I believe we already discussed this to some degree and decided that we would not enter the arena of word equivalents with the exception of spelling variations for known American-British English.  Although there are certainly plenty of words that seem “safe” to equate, that begins to feel like a slippery slope in terms of the potential for different meanings or the license author’s intent getting altered.  More specifically, many licenses have definitions for such words.  Past and present tense can also be tricky, both from deciding how and when it’s okay to use either tense.  All in all, I think it’s best to take a very conservative approach to what we will “replace” in terms of templatizing the licenses.  We can always expand, but it would be very hard to roll it back later on.  Just my two cents.


I agree. I wonder if a solution is to allow the specification of "variant" of a license. Perhaps a way to say: the closest license is this one, with a text similarity metric of X, and where the differences are  such and such. Otherwise a lot of BSD and MIT licensed files will be listed as unknown/other.


--dmg
 
Certainly the BSD and Apache 1.1 licenses are problematic, because they are often verbatim with the exception of the author’s name in the third clause (BSD) and the third, fourth, and fifth clause (Apache 1.1) as well as the disclaimer sections for both.  We are working through how/where to capture this, as well as copyright notices in general, though.



Jilayne Lovejoy |  Corporate Counsel
jlovejoy@...

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

OpenLogic, Inc.
10910 W 120th Ave, Suite 450
Broomfield, Colorado 80021


Re: Today's Agenda Legal WorkStream

dmg
 

Philip Odence twisted the bytes to say:


Philip> Yes, and let's not forget this same point when we are talking about the process of adding new license to the standard list. The discussion is never
Philip> whether the license can be included in an SPDX file—it always can be—the only issue from the SPDX file creator's perspective is whether it matches a
Philip> license on the standard list with a predefined short name, or whether they have to go the one extra step of including the license text in Section 4.
Philip> Licensing Info and create their own local short name.

One interesting aspect of licenses that are "almost" a match is that, if
they are only listed as "unknown", the knowledge/analysis performed by
the SPDX-file's author might be lost (why is such license unknown).

Perhaps a "comment" field attached to any attribute (file, package, etc)
that can have a license would be very useful to include a rational.

--dmg


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


License List v1.7 uploaded to wiki (finally)

Jilayne Lovejoy <jilayne.lovejoy@...>
 

With a  few minor changes and the ‘.0’ put back in the short names.  This should be (close to?) the final first version...  
Find it here:  http://spdx.org/wiki/working-version-license-list

I also uploaded a new “guidelines” document that has links to the template issues and British-American word substitution pages on the wiki.  Once all this information gets finalized, it would be good to turn this into a page unto itself, perhaps?

Jilayne Lovejoy |  Corporate Counsel
jlovejoy@...

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

OpenLogic, Inc.
10910 W 120th Ave, Suite 450
Broomfield, Colorado 80021


license html files for the license repository

Gary O'Neall
 

Hi Martin,

 

In the SPDX tech face to face meeting we discussed adding the license information to the spdx website at spdx.org/licenses.  Attached is the output of a tool that converts the license spreadsheet to a set of html files. 

 

This uses the latest version 1.7 of the spreadsheet which I believe is final for Beta.

 

The file index.html contains a table.  We would like to add this to the website.  If you want to modify the look and feel of any of the pages, feel free to change – if you email me back an example of the index html file and one of the license files and any modified .css files, I’ll update the tool to produce that style (I’m hoping you just need to change the .css files ;)

 

Note: I did need to modify the format of the spreadsheet slightly to make it through the tool.  I change the name of sheet1 to “Licenses” and removed the leading space from cell A1 “ Full name of License”.  Attached is an updated spreadsheet (version 1.7g).

 

I also noticed that there are 4 licenses which do not have any text:

Adaptive Public License

Apple Public Source License 1.2

Creative Commons Attribution Non Commercial No Derivatives 1.0

PHP License v3.0

Python Software Foundation License v2

 

Let me know if  you have any questions.

 

Thanks,
Gary


Re: license html files for the license repository

Jilayne Lovejoy <jilayne.lovejoy@...>
 

Hi Gary and everyone,

I could not open the spreadsheet you said, as I got a corrupted message, but in any case, I made the changes/additions you mentioned below and re-uploaded a “v1.8” to the SPDX site at http://spdx.org/wiki/working-version-license-list (in both Excel and OpenOffice formats – finally... :)

I don’t know what happened to those license texts – one of them I had a “not found” note, yet I found it this time looking.  In any case, the license text for the license you list below has been added to this newest version.  

As for your html files – looks great!  My only feedback is that where it lists the url it just shows “www” as the hot link.  Is there anyway for that to show the actual url address?

Two other license list related things – is there anyway to change the link for the License List that is on Specification page (here: http://spdx.org/node/2456 ) to the link above?  
Also, the license list page has ALL the uploads of each version – this seems a bit messy and potentiall confusing.  Would it be better to delete the older versions, so only the current one is listed?  Or do we want to keep all the prior versions for transparency/archival purposes?

Cheers,
Jilayne


On 4/8/11 11:06 AM, "Gary O'Neall" <gary@...> wrote:

Hi Martin,
 
In the SPDX tech face to face meeting we discussed adding the license information to the spdx website at spdx.org/licenses.  Attached is the output of a tool that converts the license spreadsheet to a set of html files.  
 
This uses the latest version 1.7 of the spreadsheet which I believe is final for Beta.
 
The file index.html contains a table.  We would like to add this to the website.  If you want to modify the look and feel of any of the pages, feel free to change – if you email me back an example of the index html file and one of the license files and any modified .css files, I’ll update the tool to produce that style (I’m hoping you just need to change the .css files ;)
 
Note: I did need to modify the format of the spreadsheet slightly to make it through the tool.  I change the name of sheet1 to “Licenses” and removed the leading space from cell A1 “ Full name of License”.  Attached is an updated spreadsheet (version 1.7g).
 
I also noticed that there are 4 licenses which do not have any text:
Adaptive Public License
Apple Public Source License 1.2
Creative Commons Attribution Non Commercial No Derivatives 1.0
PHP License v3.0
Python Software Foundation License v2

Let me know if  you have any questions.
 
Thanks,
Gary


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

Jilayne Lovejoy |  Corporate Counsel
jlovejoy@...

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

OpenLogic, Inc.
10910 W 120th Ave, Suite 450
Broomfield, Colorado 80021


Re: license html files for the license repository

Gary O'Neall
 

Thanks Jilayne for the updates and review.  I just downloaded the 1.8 version of the spreadsheet and I can not open it in excel (the open office version worked fine).  It turns out that the application, however, does not have any problems with it.

 

I removed the license text referenced below and I was able to convert.  Other than that, the new license spreadsheet works fine.

 

I fixed the bug with the bad name for the external license links – they are now the entire URL.

 

I’ll leave the site link questions to Martin.

 

Attached is an updated set of HTML pages.


Gary

 

From: Jilayne Lovejoy [mailto:jilayne.lovejoy@...]
Sent: Monday, April 11, 2011 1:48 PM
To: Gary O'Neall; Martin Michlmayr
Cc: spdx-tech@...; spdx-legal@...; spdx-biz@...
Subject: Re: license html files for the license repository

 

Hi Gary and everyone,

I could not open the spreadsheet you said, as I got a corrupted message, but in any case, I made the changes/additions you mentioned below and re-uploaded a “v1.8” to the SPDX site at http://spdx.org/wiki/working-version-license-list (in both Excel and OpenOffice formats – finally... :)

I don’t know what happened to those license texts – one of them I had a “not found” note, yet I found it this time looking.  In any case, the license text for the license you list below has been added to this newest version.  

As for your html files – looks great!  My only feedback is that where it lists the url it just shows “www” as the hot link.  Is there anyway for that to show the actual url address?

Two other license list related things – is there anyway to change the link for the License List that is on Specification page (here: http://spdx.org/node/2456 ) to the link above?  
Also, the license list page has ALL the uploads of each version – this seems a bit messy and potentiall confusing.  Would it be better to delete the older versions, so only the current one is listed?  Or do we want to keep all the prior versions for transparency/archival purposes?

Cheers,
Jilayne


On 4/8/11 11:06 AM, "Gary O'Neall" <gary@...> wrote:

Hi Martin,
 
In the SPDX tech face to face meeting we discussed adding the license information to the spdx website at spdx.org/licenses.  Attached is the output of a tool that converts the license spreadsheet to a set of html files.  
 
This uses the latest version 1.7 of the spreadsheet which I believe is final for Beta.
 
The file index.html contains a table.  We would like to add this to the website.  If you want to modify the look and feel of any of the pages, feel free to change – if you email me back an example of the index html file and one of the license files and any modified .css files, I’ll update the tool to produce that style (I’m hoping you just need to change the .css files ;)
 
Note: I did need to modify the format of the spreadsheet slightly to make it through the tool.  I change the name of sheet1 to “Licenses” and removed the leading space from cell A1 “ Full name of License”.  Attached is an updated spreadsheet (version 1.7g).
 
I also noticed that there are 4 licenses which do not have any text:
Adaptive Public License
Apple Public Source License 1.2
Creative Commons Attribution Non Commercial No Derivatives 1.0
PHP License v3.0
Python Software Foundation License v2

Let me know if  you have any questions.
 
Thanks,
Gary


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


Jilayne Lovejoy |  Corporate Counsel
jlovejoy@...

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

OpenLogic, Inc.
10910 W 120th Ave, Suite 450
Broomfield, Colorado 80021


Open Data License

Esteban Rockett <mgia3940@...>
 

All:

As discussed during yesterday's call, below please find links for your review.

Many thanks,

Rockett


---------- Forwarded message ----------
From: Copenhaver, Karen <kcopenhaver@...>
Date: Wed, Apr 13, 2011 at 8:33 AM
Subject: Open Data License
To: "E. A. Rockett (rockett@...)" <rockett@...>


 
And because I think we have decided that we do not want to require any attribution, I was focused on this:
 
 
If the SPDX does not have any identifying information, this may be appropriate. 
 
If the SPDX does have identifying information, then this may appear to be inconsistent with a company providing for confidentiality (although see 2.2) and may cause concern.  But if the SPDX that is covered by this "license" is entirely anonymous, I think there is a lot of work here and it would be great is we could leverage it. 
 
For some context:
 




SPDX and Support

Esteban Rockett <mgia3940@...>
 

FYI all ... 

Begin forwarded message:

From: "Copenhaver, Karen" <kcopenhaver@...>
Date: April 14, 2011 6:32:19 AM PDT
To: "E. A. Rockett (rockett@...)" <rockett@...>
Subject: FW: SPDX and Support

More information to distribute to the group.  Dan is one of the original Samba team.  


-----Original Message-----
From: Dan Shearer [mailto:dan@...]
Sent: Thursday, April 14, 2011 7:36 AM
To: Copenhaver, Karen
Subject: SPDX and Support

Karen,

Eben makes a powerful point about SPDX and solving compliance problems with embedded devices, but there is another angle. Compliance is at best a neutral and often negative point; the contribution SPDX could make to support operations is very positive.

A lot of wasted time and financial overhead on both ends of a support desk call relates to finding SPDX information, or information one logical hop away from SPDX data. So if an SPDX or collection of them can be supplied in the initial query:

1. The respondant has a good idea of what the alleged fault relates to, including having a list of known issues.

2. Much support relates to *interactions* of software rather than a piece of software in isolation. So having SPDXs for the software that is in the same environment as the software in question could be very useful. Of course SPDX says nothing about how software is configured or used, but still, it is valuable information that is often incomplete, wrong or missing in support requests.

3. It opens up the idea of another automated step in the support process, a conversation around exchanging lists of SPDX records.

4. As far as I am aware SPDX is commonly thought of as a here-and-now facility. But in the context of support requests it would be extremely helpful to know the history over time.

5. Depending (techies always say that :) the SPDX(es) could be used to create a virtual machine containing all the software at issue in the initial support request ready for the technician to use as required.
And, in the case of (4) above, multiple virtual machines to help determine when a problem may have been introduced.

--
Dan Shearer
dan@...

Confidentiality Statement:

This Message is transmitted to you by the law firm of Choate, Hall & Stewart LLP.  The substance of this message, along with any attachments, may be confidential and legally privileged.  If you are not the designated recipient of this message, please destroy it and notify the sender of the error by return e-mail or by calling 1-800-520-2427.

Under regulations of the Treasury Department, we are required to include the following statement in this message: Any advice contained herein (or in any attachment hereto) regarding federal tax matters was not intended or written by the sender to be used, and it cannot be used by any taxpayer, for the purpose of avoiding penalties that may be imposed on the taxpayer.

For more information about Choate, Hall & Stewart LLP, please visit us at choate.com



Agenda for today's meeting ...

Esteban Rockett <mgia3940@...>
 

All:

For today's meeting I propose we:

(1) focus on the "meta-data confidentiality/licensing" issue, and any feedback/reaction from your independent review of Open Data Commons PDDL 1.0 (http://www.opendatacommons.org/licenses/pddl/1.0/); AND

(2) focus on how to handle the "confidential" marking field.

If we can conquer and conclude the above today, that will be fantastic.

Many thanks,

Rockett


Re: Open Data License

Benjamin Jean <mjeanb@...>
 

Hi all,

Concerning the license, did you discuss about the ODbL (which can be use
without requiring any attribution)?

It should be a good license too, but I don't know if it fits the needs:
* it's a copyleft database dedicated license -- for instance used
for OSM (I also recommended its use for the Open Data in
Paris) ;
* a more permissive license might facilitate the SPDX adoption --
but do we focus on the users or the project?

http://www.opendatacommons.org/licenses/odbl/

Best,

Benjamin

Le jeudi 14 avril 2011 à 06:48 -0700, Esteban Rockett a écrit :
All:

As discussed during yesterday's call, below please find links for your
review.

Many thanks,

Rockett


---------- Forwarded message ----------
From: Copenhaver, Karen <kcopenhaver@...>
Date: Wed, Apr 13, 2011 at 8:33 AM
Subject: Open Data License
To: "E. A. Rockett (rockett@...)" <rockett@...>


http://www.opendatacommons.org/

And because I think we have decided that we do not want to require any
attribution, I was focused on this:

http://www.opendatacommons.org/licenses/pddl/1.0/

If the SPDX does not have any identifying information, this may be
appropriate.

If the SPDX does have identifying information, then this may appear to
be inconsistent with a company providing for confidentiality (although
see 2.2) and may cause concern. But if the SPDX that is covered by
this "license" is entirely anonymous, I think there is a lot of work
here and it would be great is we could leverage it.

For some context:

http://www.jordanhatcher.com/open-data/

______________________________________________________________________



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


Re: Open Data License

Benjamin Jean <mjeanb@...>
 

Hi all,

Concerning the license, did you discuss about the ODbL (which can be use
without requiring any attribution)?

It should be a good license too, but I don't know if it fits the needs:
* it's a copyleft database dedicated license -- for instance used
for OSM (I also recommended its use for the Open Data in
Paris) ;
* a more permissive license might facilitate the SPDX adoption --
but do we focus on the users or the project?

http://www.opendatacommons.org/licenses/odbl/

Best,

Benjamin

Le jeudi 14 avril 2011 à 06:48 -0700, Esteban Rockett a écrit :
All:

As discussed during yesterday's call, below please find links for your
review.

Many thanks,

Rockett


---------- Forwarded message ----------
From: Copenhaver, Karen <kcopenhaver@...>
Date: Wed, Apr 13, 2011 at 8:33 AM
Subject: Open Data License
To: "E. A. Rockett (rockett@...)" <rockett@...>


http://www.opendatacommons.org/

And because I think we have decided that we do not want to require any
attribution, I was focused on this:

http://www.opendatacommons.org/licenses/pddl/1.0/

If the SPDX does not have any identifying information, this may be
appropriate.

If the SPDX does have identifying information, then this may appear to
be inconsistent with a company providing for confidentiality (although
see 2.2) and may cause concern. But if the SPDX that is covered by
this "license" is entirely anonymous, I think there is a lot of work
here and it would be great is we could leverage it.

For some context:

http://www.jordanhatcher.com/open-data/

______________________________________________________________________



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


Revisting proposed terminology definitions

Kirsten Newcomer <knewcomer@...>
 

Hi all, 

In reviewing the SPDX Specification at the Linux Collab Summit face-to-face, the team noticed that there was some inconsistency regarding the use of the terms UNKNOWN, UNDETERMINED, NONE, etc. After a detailed review of the occurrences of these terms, and much discussion, the SPDX Technical group has proposed the following replacement terminology. 

We'd like to get sign-off from the Legal team before we finalize. Bill Schineller has volunteered to attend the Legal team meeting this week to review the proposal and collect feedback. Note that we need to finalize the terms we plan to use for beta.

Definitions:

AMBIGUOUS 
Indicates that the preparer of the SPDX document was not able to
settle on a value for the field.  Some attempt to determine the value
must have been made before using this value.

NONE
Indicates that the preparer of the SDPX document has determined that
this field has no value.  This determination must be based on some
evidence.

NOTANALYZED
Indicates that the preparer of the SPDX document made no attempt to
determine the value of this field.


Occurrences/Use:


licenseDeclared or licenseInfoInFile fields can have one of 4 possible values: 
<short-form-identifier>
LicenseRef-N 
NONE 
NOTANALYZED
(Note: these fields do not use the AMBIGUOUS value; AMBIGUOUS is reserved for Concluded fields.)

licenseConcluded fields can have one of 5 possible values:
<short-form-identifier> 
LicenseRef-N 
NONE 
NOTANALYZED 
AMBIGUOUS

licenseInfoFromFiles field can have one or more entries each of which has 4 possible values:
<short-form-identifier>
LicenseRef-N 
NONE 
NOTANALYZED 

In addition, the fields packageDownloadLocation and artifactOfProjectHomePage can have one of 2 values:
<URL>
NONE

And the fields copyrightText, fileCopyrightText can have the value: 
<multiple lines of text>
NONE

Thanks!

Kirsten

Kirsten Newcomer
Senior Product Manager
Black Duck Software, Inc.

knewcomer@...
Office: +1.781.810.1839   Mobile: +1.781-710-2184


Re: Revisting proposed terminology definitions

Peterson, Scott K (HP Legal) <scott.k.peterson@...>
 

Unfortunately, I will not be able to attend the legal meeting this week.

 

But, I would like to offer a comment on the proposed 3 no-value values:

 

I see terms for:

- determined

- no attempt to determine

 

What value does someone use if, after analysis, they concluded that they were unable to determine the value for this parameter?

 

I don’t think it is important whether something was subjected to analysis or not. What is important is whether a determination was made.

 

Thus, I suggest that the description for the third value might be better described as follows:

 

“Indicates that the preparer of the SPDX document did not determine the value of this field.”

 

Since ‘analysis’ isn’t key, the name for the value might be changed to something like:

NOTDETERMINED

 

-- Scott

 

 

From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Kirsten Newcomer
Sent: Monday, May 02, 2011 3:34 PM
To: spdx-legal@...
Cc: spdx-tech@...
Subject: Fwd: Revisting proposed terminology definitions

 

Hi all, 

 

In reviewing the SPDX Specification at the Linux Collab Summit face-to-face, the team noticed that there was some inconsistency regarding the use of the terms UNKNOWN, UNDETERMINED, NONE, etc. After a detailed review of the occurrences of these terms, and much discussion, the SPDX Technical group has proposed the following replacement terminology. 

 

We'd like to get sign-off from the Legal team before we finalize. Bill Schineller has volunteered to attend the Legal team meeting this week to review the proposal and collect feedback. Note that we need to finalize the terms we plan to use for beta.

 

Definitions:

 

AMBIGUOUS 
Indicates that the preparer of the SPDX document was not able to
settle on a value for the field.  Some attempt to determine the value
must have been made before using this value.

NONE
Indicates that the preparer of the SDPX document has determined that
this field has no value.  This determination must be based on some
evidence.

NOTANALYZED
Indicates that the preparer of the SPDX document made no attempt to
determine the value of this field.

 

 

Occurrences/Use:

 

 

licenseDeclared or licenseInfoInFile fields can have one of 4 possible values: 

            <short-form-identifier>

            LicenseRef-N 

            NONE 

            NOTANALYZED

            (Note: these fields do not use the AMBIGUOUS value; AMBIGUOUS is reserved for Concluded fields.)

 

licenseConcluded fields can have one of 5 possible values:

            <short-form-identifier> 

            LicenseRef-N 

            NONE 

            NOTANALYZED 

            AMBIGUOUS

 

licenseInfoFromFiles field can have one or more entries each of which has 4 possible values:

            <short-form-identifier>

            LicenseRef-N 

            NONE 

            NOTANALYZED 

 

In addition, the fields packageDownloadLocation and artifactOfProjectHomePage can have one of 2 values:

            <URL>

            NONE

 

And the fields copyrightText, fileCopyrightText can have the value: 

            <multiple lines of text>

            NONE

 

Thanks!

 

Kirsten

 

Kirsten Newcomer
Senior Product Manager
Black Duck Software, Inc.

knewcomer@...
Office: +1.781.810.1839   Mobile: +1.781-710-2184