[spdx-tech] Question on how to handle "None" and "NoAssertion"

[Gary O'Neall]

Hi Sean - and the larger SPDX tech community,

 

I would like to get your opinion on how we should handle the NoAssertion and
None object values for several SPDX properties.

 

The issues are documented in https://github.com/spdx/spdx-3-model/issues/76
and https://github.com/spdx/spdx-3-model/issues/71

 

There are two (or more) perspectives on this issue.

 

*   In RDF - we're using an Individual for None and NoAssertion and
including that in the Range for the properties.  This has caused some
issues, which may be due to using OWL rather than SHACL to describe the
restrictions.

 

*   In Object Oriented Programming, it is challenging to define
subclasses of Element and Licenses (and other types) that include None and
NoAssertions.

 

Feel free to update the issues or reply to all in the email.


Thanks,
Gary

 

-

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email:  <mailto:g...@sourceauditor.com> g...@sourceauditor.com

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is
intended only for the person(s) or entity to which it is addressed and may
contain confidential and/or privileged material. Any review,
re-transmission, dissemination or other use of, or taking of any action in
reliance upon this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please
contact the sender and destroy any copies of this information.

 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5080): https://lists.spdx.org/g/Spdx-tech/message/5080
Mute This Topic: https://lists.spdx.org/mt/98312141/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[Bug 1289] Any reason "NONE" and "NOASSERTION" are not valid licenses as per Appendix IV?

[bugzilla-daemon]

https://bugs.linuxfoundation.org/show_bug.cgi?id=1289

Kate Stewart  changed:

   What|Removed |Added

 CC||stew...@linux.com

--- Comment #3 from Kate Stewart  ---
>From discussion on 12/22 - we'd like to get the legal team weighing in on this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

[Bug 1289] Any reason NONE and NOASSERTION are not valid licenses as per Appendix IV?

[bugzilla-daemon]

https://bugs.linuxfoundation.org/show_bug.cgi?id=1289

--- Comment #2 from Joe Andrieu j...@andrieu.net 2015-06-16 19:56:58 UTC ---
Mark,

Thanks for the clarification.

In the case of Sections 3.12 and 3.13, it is easy to agree with your argument
that NONE and ASSERTION are a state of analysis.

However, for Section 3.14, Declared License, it didn't make sense at first. In
my first reading, I missed the clarifying language that supports your point:

===
This field lists the licenses that have been declared by the authors of the
package. Any license information that does not originate from the package
authors, e.g. license information from a third party repository, should not be
included in this field. 
===

In my use case (and that of NPM), the information is being provided directly by
the package author and no license is granted.

That is, the package author is explicitly stating that the attached code has NO
LICENSE. Presumably, depending on the situation, one could assume copyright or
other restrictions are still in place, but any such assumptions are dangerous
at best.

What is more clear to me now (thank you for the explanation), is that this use
case is not addressable by the current SPDX standard.

Perhaps more problematic, while NPM is considering allowing NONE as a valid
field, the semantics are a variation from the SPDX usage. Here's the language
from the 2.0 spec:

===
● NONE, if no license information is detected in any of the files.
● NOASSERTION, if the SPDX file creator has not examined the contents of the
package or if the SPDX file creator has intentionally provided no information
(no meaning should be implied by doing so).
===

But what I really want to say is that NO LICENSE is explicitly declared by
the package author.

Would it be better to propose a new valid license expression that captures that
intent? Perhaps All rights reserved or Copyright?

-- 
Configure bugmail: https://bugs.linuxfoundation.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

[Bug 1289] New: Any reason NONE and NOASSERTION are not valid licenses as per Appendix IV?

[bugzilla-daemon]

https://bugs.linuxfoundation.org/show_bug.cgi?id=1289

 Bug #: 1289
   Summary: Any reason NONE and NOASSERTION are not valid
licenses as per Appendix IV?
   Product: SPDX
   Version: 2.0
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Spec
AssignedTo: spdx-t...@fossbazaar.org
ReportedBy: j...@andrieu.net
Classification: Unclassified


In sections 3.12, 3.13, and 3.14, the terms NONE and NOASSERTION are
allowed but not valid as per Appendix IV.

This has led to a thread of issues in the node.js SPDX module and npm, e.g.,
https://github.com/kemitchell/spdx.js/issues/11

The issue is whether or not a test for a valid license should treat NONE and
NOASSERTION as valid. From the spec, it appears that they are allowed and
hence functionally valid, but not technically valid as per the appendix.

I apologize if this is a hornets nest that has been discussed ad infinitum, but
the ambiguity about validity of NONE and NOASSERTION is an odd edge case
that happens to now have a small, but real, impact on my regular use of node
and npm in development.

Is this something that might be worth fixing in a subsequent revision? Or maybe
explained in the FAQ?

-- 
Configure bugmail: https://bugs.linuxfoundation.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: none

[Philippe Ombredanne]

On Sun, Jun 16, 2013 at 7:47 PM, D M German d...@uvic.ca wrote:
 * Double braces {{}}
 One problem I have run into is that {{}} are widely used by wikis and
 other HTML systems to escape a template of some sort. Try for example
 editing the following page and changing {{}} to {{ and }}
 http://wiki.spdx.org/view/Technical_Team/Proposals/2013-6-13/License_Template
 I have added the example at the bottom of the page. You will see how it
 is rendered because the wiki software has special interpretation for
 these fields.
 I ran into the same problem at github and even my own website software.
 This will make our editing of the rules in the wiki more difficult that
 they need to be. My suggestion is to replace the double braces with
 double angle brackets 
 Again, this is simply stylistic and does not change anything.

Daniel:
I think the main reason why curly braces were selected is because they
are a de-facto convention for text template engines, which of course
includes things like wiki and several HTML and text templating systems
and libraries.
This is actually part of their appeal, not a drawback IMHO.
And yes this may mean that in cases we will have to escape the curly
braces properly or mark them such that they are not  recognized by a
template engine. And angle brackets would likely have the same issues
wrt to HTML/XML.

-- 
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: none

[Gary O'Neall]

Hi Philippe,

Good point and that was the motivation for proposing the double curly
braces.  

Originally, I was going to use Mustache
(http://mustache.github.io/mustache.5.html) to implement the template in the
SPDX tools.  However, the current proposal is not compatible with that
format.  I am now thinking we should choose a different set of characters so
that we could add Mustaches support for SPDX license templates in the
future.

I would support either proposal (double curly braces or double angle
brackets), but I am currently leaning towards double curly braces to allow
future Mustache support.

Gary

-Original Message-
From: Philippe Ombredanne [mailto:pombreda...@nexb.com] 
Sent: Monday, June 17, 2013 10:42 AM
To: spdx-tech@lists.spdx.org
Cc: Gary O'Neall; d...@uvic.ca; Jilayne Lovejoy
Subject: Re: none

On Sun, Jun 16, 2013 at 7:47 PM, D M German d...@uvic.ca wrote:
 * Double braces {{}}
 One problem I have run into is that {{}} are widely used by wikis and 
 other HTML systems to escape a template of some sort. Try for example 
 editing the following page and changing {{}} to {{ and }}
 http://wiki.spdx.org/view/Technical_Team/Proposals/2013-6-13/License_T
 emplate I have added the example at the bottom of the page. You will 
 see how it is rendered because the wiki software has special 
 interpretation for these fields.
 I ran into the same problem at github and even my own website software.
 This will make our editing of the rules in the wiki more difficult 
 that they need to be. My suggestion is to replace the double braces 
 with double angle brackets  Again, this is simply stylistic and 
 does not change anything.

Daniel:
I think the main reason why curly braces were selected is because they are a
de-facto convention for text template engines, which of course includes
things like wiki and several HTML and text templating systems and libraries.
This is actually part of their appeal, not a drawback IMHO.
And yes this may mean that in cases we will have to escape the curly braces
properly or mark them such that they are not  recognized by a template
engine. And angle brackets would likely have the same issues wrt to
HTML/XML.

--
Philippe Ombredanne

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