NONE is also used in a factual sense (I looked and found no data).

I would like to be able to say: “I am not making any assertion about the
value of this field.” Period. Without making any representation about what
analysis was or was not done. I don’t like being forced to assert whether
analysis was done or not.

I should have paid more attention to the definition of “AMBIGUOUS”.  I now see that that was intended to be used in any case where analysis was done and no determination was made - not only the cases where the value is ambiguous.
 
I would like to be able to say: “I am not making any assertion about the value of this field.” Period. Without making any representation about what analysis was or was not done. I don’t like being forced to assert whether analysis was done or not.
 
-- Scott
 
 

From: Kirsten Newcomer [mailto:knewcomer@...]
Sent: Monday, May 02, 2011 4:24 PM
To: Peterson, Scott K (HP Legal)
Cc: spdx-tech@...; spdx-legal@...
Subject: Re: Revisting proposed terminology definitions


Thanks very much for the comment, Scott.



You're correct that these terms fit into the categories you suggest:



Terms for "determined: include: AMBIGUOUS (I determined I was unable to determine a value) and NONE (I determined the correct value is NONE).

NONE is also used in a factual sense (I looked and found no data).

For "no attempt to determine": NOTANALYZED.



We think of analysis as any type of effort, whether visual review, tools analysis, or just asking the developer.



We were concerned that NOTDETERMINED could be interpreted as a conclusion (I looked, but couldn't figure it out). We thought it was important to have a term that conveys that no attempt to find info or make a determination was made.



Thoughts?



Kirsten
 

On May 2, 2011, at 4:04 PM, Peterson, Scott K (HP Legal) wrote:


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
 

But the following simpler definition might be adequate:

"The preparer of the SPDX document is not making any assertion regarding the
value of this field."

Once it is clear that the value is unrelated to whether analysis was or was
not done, NOTANALYZED becomes misleading. I don't have any great suggestions
for replacement. The best I can think of are NOVALUE or BLANK.

Bill --
 
I very much appreciate the attention that you and others are willing to pay to this point.
 
Personally, for me, two values would be enough:
- I have determined that there isn't any value for this field
- I am not making any statement about the value of this field
 
If others believe that there is utility in having a value that means:
- I tried to determine a value and gave up,
then I would not object to including such a third value.
 
As to this definition:
"Indicates that the preparer of the SPDX document made no attempt to determine the value of this field or that the preparer of the SPDX document is not making any assertion regarding the value of this field."
 
The beginning of the sentence leads one's expectations astray: "Indicates that the preparer of the SPDX document made no attempt to determine" is negated by the end of the sentence, which points out that this value, in fact, does not provide that information.
 
The following would correct the mis-set expectation:
"Whether or not the preparer of the SPDX document made any attempt to determine the value of this field, the preparer of the SPDX document is not making any assertion regarding the value of this field."
 
But the following simpler definition might be adequate:
"The preparer of the SPDX document is not making any assertion regarding the value of this field."
 
Once it is clear that the value is unrelated to whether analysis was or was not done, NOTANALYZED becomes misleading. I don't have any great suggestions for replacement. The best I can think of are NOVALUE or BLANK.
 
Finally, the only point about which I have a strong opinion is that I think it very important to have a value that means "I am not making any assertion about the value of this field." Period. With no additional baggage. No other implications about what was or was not done. Simply, "I'm not saying." It's what would typically be expressed by leaving something blank. Perhaps "BLANK" expresses it most clearly. BLANK is saying, "No, I didn't forget to fill this in. I explicitly want to leave it blank."
 
------
 
It is interesting to see how much nuance there can be in 'none'. Perhaps this is somehow related to the importance of the concept of zero -- a concept that is widely underappreciated.
 
-- Scott
 

From: Bill Schineller [mailto:bschineller@...]
Sent: Tuesday, May 03, 2011 3:15 PM
To: Peterson, Scott K (HP Legal); Kirsten Newcomer
Cc: spdx-tech@...; spdx-legal@...
Subject: Re: Revisting proposed terminology definitions

Hi Scott,
  On Tech team call today, we discussed your feedback.  
  Our collective reading is that you were agreeing that 3 (three) distinct terms for no-value values are still appropriate.
  But that your primary issue is with the name and definition of the third term which we had proposed as NOTANALYZED.  

  Does your issue with the term ‘NOTANALYZED’ stem from reading ‘analyzed’ as implying use of a tool? We didn’t mean to imply that.  
 
  An assumption is that it is preferred for SPDX documents to explicitly state (by using one of AMBIGUOUS | NONE | NOTANALYZED) when concluded or declared license fields have no value (rather than by omitting the field).

  That said, we did not come up with a term to replace NOTANALYZED ,but we did expand on the definition.  
  Would you endorse the revised proposal below?  If not, can you please reply with counter-proposal?


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 or that the preparer of the SPDX document is not making any
assertion regarding the value of this field.    



On 5/2/11 5:35 PM, "Peterson, Scott K (HP Legal)" <scott.k.peterson@...> wrote:
I should have paid more attention to the definition of “AMBIGUOUS”.  I now see that that was intended to be used in any case where analysis was done and no determination was made - not only the cases where the value is ambiguous.
 
I would like to be able to say: “I am not making any assertion about the value of this field.” Period. Without making any representation about what analysis was or was not done. I don’t like being forced to assert whether analysis was done or not.
 
-- Scott
 
 

From: Kirsten Newcomer [mailto:knewcomer@...]
Sent: Monday, May 02, 2011 4:24 PM
To: Peterson, Scott K (HP Legal)
Cc: spdx-tech@...; spdx-legal@...
Subject: Re: Revisting proposed terminology definitions


Thanks very much for the comment, Scott.



You're correct that these terms fit into the categories you suggest:



Terms for "determined: include: AMBIGUOUS (I determined I was unable to determine a value) and NONE (I determined the correct value is NONE).



NONE is also used in a factual sense (I looked and found no data).



For "no attempt to determine": NOTANALYZED.



We think of analysis as any type of effort, whether visual review, tools analysis, or just asking the developer.



We were concerned that NOTDETERMINED could be interpreted as a conclusion (I looked, but couldn't figure it out). We thought it was important to have a term that conveys that no attempt to find info or make a determination was made.



Thoughts?



Kirsten
 

On May 2, 2011, at 4:04 PM, Peterson, Scott K (HP Legal) wrote:


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
 

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

---

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

Hi All,

I uploaded a new version (1.10) of the License List to the SPDX site.
I have added the new terms, NONE and NOASSERTION with the definitions
Kirsten circulated entered into the "notes" column of the spreadsheet.

I also added a generic PUBLIC DOMAIN option. I did not make short
identifiers for these. (I started to, using "NONE," "PD," and when I
got to shortening NOASSERTION, well, I got a bit stuck... Which made
me wonder if these need short identifiers since they aren't actually
licenses?)

As a result of the public domain question coming up on the call
yesterday, I think I stated that the CC Zero license was on the list,
but discovered it was not, so I added that as well. This then made me
realize that there are a couple common public domain
dedictions/notices (I'm trying not to call these licenses!) for
commonly used projects that I've seen come up often in audits -
namely, ANTLR (versions prior to 3.0) and SAX. So, I added these
too. Considering our time frame at this point and Gary needing an
updated list, I realize I made a unilateral decision here (!), but
figured it would be easier to delete on the fly than add. In any
case, all the changes/additions on the list are in red text so if you
all want to take a look, it will be easy to find them. Thoughts?

Regarding the commented and updated .pdf that Kirsten's sent I think
the description of the fields that we changes the options for probably
needs to be updated as well (I had a hard time seeing the text with
the comments, so maybe I'm wrong on this). I will try to tackle that
later today, as needed, and send another email.

On Thu, 2011-05-12 at 09:35 -0600, Jilayne Lovejoy wrote:

Hi All,

I uploaded a new version (1.10) of the License List to the SPDX site.
I have added the new terms, NONE and NOASSERTION with the definitions
Kirsten circulated entered into the "notes" column of the spreadsheet.

Sounds good. Thanks

I also added a generic PUBLIC DOMAIN option. I did not make short
identifiers for these. (I started to, using "NONE," "PD," and when I
got to shortening NOASSERTION, well, I got a bit stuck... Which made
me wonder if these need short identifiers since they aren't actually
licenses?)

Can we use PUBLICDOMAIN? It would follow the naming pattern of
NOASSERTION and be pretty clear what it means at a glance.

As a result of the public domain question coming up on the call
yesterday, I think I stated that the CC Zero license was on the list,
but discovered it was not, so I added that as well. This then made me
realize that there are a couple common public domain
dedictions/notices (I'm trying not to call these licenses!) for
commonly used projects that I've seen come up often in audits -
namely, ANTLR (versions prior to 3.0) and SAX. So, I added these
too. Considering our time frame at this point and Gary needing an
updated list, I realize I made a unilateral decision here (!), but
figured it would be easier to delete on the fly than add. In any
case, all the changes/additions on the list are in red text so if you
all want to take a look, it will be easy to find them. Thoughts?

Seems like a reasonable plan to me. As you say, we can delete easier
than add after this point. Can discussion of these go on the agenda for
the next legal call?

Regarding the commented and updated .pdf that Kirsten's sent I think
the description of the fields that we changes the options for probably
needs to be updated as well (I had a hard time seeing the text with
the comments, so maybe I'm wrong on this). I will try to tackle that
later today, as needed, and send another email.

Sounds good.

Kate

Should 'PUBLICDOMAIN' be a license in the repo or a special value? 

I don't think public domain is, technically, a license.  It does not have matchable text or notices.  That is going to make its license page rather empty and perhaps not very useful.

On the other hand it does work rather like a license from the users perspective.

Peter
Openlogic.com

Should 'PUBLICDOMAIN' be a license in the repo or a special value?

I don't think public domain is, technically, a license. It does not
have matchable text or notices. That is going to make its license
page rather empty and perhaps not very useful.

On the other hand it does work rather like a license from the users
perspective.

Peter
Openlogic.com

On May 12, 2011 10:53 PM, "Jilayne Lovejoy"
<jilayne.lovejoy@...> wrote:

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

On Fri, 2011-05-13 at 11:12 -0600, Peter Williams wrote:

Should 'PUBLICDOMAIN' be a license in the repo or a special value?

My vote is to leave it in the license list for now.
Its directly analagous to the other keyword values in the list.

It will simplify things in terms of handling - and while it doesn't have
text, it does have specific meaning to the legal community impacting
usage of the code under copyright - just like licenses do.