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
