Date
1 - 5 of 5
Exclusion of NONE and NOASSERTION from ABNF
Terin Stock <terinjokes@...>
The ABNF in Appendix IV of the 2.0 version of the specification allows for short form identifiers, LicenseRef values or combinations to form a license-expression. However the values "NONE" and "NOASSERTION" are not valid in a license expression, despite their useful and defined meaning in the specification.
There are tools that validate their license fields using a license-expression (two such tools being the package managers npm and composer, in JavaScript and PHP, respectfully), making the values "NONE" and "NOASSERTION" invalid.
Are these two values excluded from the ABNF on purpose?
--
Terin Stock
Terin Stock
Kate Stewart
Hi Terin,
On Thu, Jun 11, 2015 at 10:52 AM, Terin Stock <terinjokes@...> wrote:
The ABNF in Appendix IV of the 2.0 version of the specification allows for short form identifiers, LicenseRef values or combinations to form a license-expression. However the values "NONE" and "NOASSERTION" are not valid in a license expression, despite their useful and defined meaning in the specification.There are tools that validate their license fields using a license-expression (two such tools being the package managers npm and composer, in JavaScript and PHP, respectfully), making the values "NONE" and "NOASSERTION" invalid.Are these two values excluded from the ABNF on purpose?
Can you give us a real life use case where either "NONE" or "NOASSERTION" should be used in combination with other licenses?
If there's a compelling use case as to why it should be allowed, that can't be expressed another way, we can certainly revisit adding it to the specification if the folk on the legal team agree.
Thanks, Kate
Terin Stock <terinjokes@...>
Kate:
I'm unsure of any use case where you would want to mix NONE or
NOASSERTION with either simple-expression or compound-expression in
the same package. You may however want to use these strings when
packaging code that has no license or where you are unsure of the
license.
In ABNF speak was thinking more along the lines of
license-expression = 1*1(simple-expression / compound-expression /
"NONE" / "NOASSERTION")
--
#Terin Stock
On Thu, Jun 11, 2015 at 9:07 AM, Kate Stewart
<kstewart@...> wrote:
I'm unsure of any use case where you would want to mix NONE or
NOASSERTION with either simple-expression or compound-expression in
the same package. You may however want to use these strings when
packaging code that has no license or where you are unsure of the
license.
In ABNF speak was thinking more along the lines of
license-expression = 1*1(simple-expression / compound-expression /
"NONE" / "NOASSERTION")
--
#Terin Stock
On Thu, Jun 11, 2015 at 9:07 AM, Kate Stewart
<kstewart@...> wrote:
Hi Terin,
On Thu, Jun 11, 2015 at 10:52 AM, Terin Stock <terinjokes@...> wrote:
The ABNF in Appendix IV of the 2.0 version of the specification allows for
short form identifiers, LicenseRef values or combinations to form a
license-expression. However the values "NONE" and "NOASSERTION" are not
valid in a license expression, despite their useful and defined meaning in
the specification.
There are tools that validate their license fields using a
license-expression (two such tools being the package managers npm and
composer, in JavaScript and PHP, respectfully), making the values "NONE" and
"NOASSERTION" invalid.
Are these two values excluded from the ABNF on purpose?
Can you give us a real life use case where either "NONE" or "NOASSERTION"
should be used in combination with other licenses?
If there's a compelling use case as to why it should be allowed, that can't
be expressed another way, we can certainly revisit adding it to the
specification if the folk on the legal team agree.
Thanks, Kate
Kate Stewart
Hi Terin
On Thu, Jun 11, 2015 at 11:20 AM, Terin Stock <terinjokes@...> wrote:
Kate:
I'm unsure of any use case where you would want to mix NONE or
NOASSERTION with either simple-expression or compound-expression in
the same package.
Neither could we. :-)
You may however want to use these strings when
packaging code that has no license or where you are unsure of the
license.
In ABNF speak was thinking more along the lines of
license-expression = 1*1(simple-expression / compound-expression /
"NONE" / "NOASSERTION")
Ah yes, that should be considered.
Right now when NONE or NOASSERTION are permitted, they are associated
with the actual fields in the specification (ie. LicenseConcluded, etc.) , but this
may be a more elegant way to express it. Will need to take a pass through all
the other fields using them and see if there are any snags.
The next tech call on the 16th is a joint call with the legal team where we
plan on talking about the NONE/NOASSERTION language. It probably makes
sense to consider this, as well at that time. Please feel free to join in to the
call if you'd like.
Thanks for raising this.
Kate
--
#Terin Stock
On Thu, Jun 11, 2015 at 9:07 AM, Kate Stewart
<kstewart@...> wrote:
> Hi Terin,
>
> On Thu, Jun 11, 2015 at 10:52 AM, Terin Stock <terinjokes@...> wrote:
>>
>> The ABNF in Appendix IV of the 2.0 version of the specification allows for
>> short form identifiers, LicenseRef values or combinations to form a
>> license-expression. However the values "NONE" and "NOASSERTION" are not
>> valid in a license expression, despite their useful and defined meaning in
>> the specification.
>>
>> There are tools that validate their license fields using a
>> license-expression (two such tools being the package managers npm and
>> composer, in JavaScript and PHP, respectfully), making the values "NONE" and
>> "NOASSERTION" invalid.
>>
>> Are these two values excluded from the ABNF on purpose?
>
>
> Can you give us a real life use case where either "NONE" or "NOASSERTION"
> should be used in combination with other licenses?
>
> If there's a compelling use case as to why it should be allowed, that can't
> be expressed another way, we can certainly revisit adding it to the
> specification if the folk on the legal team agree.
>
> Thanks, Kate
>
Mark Gisi
Hi Terin,
On the surface the following appears to be syntactically convenient:
license-expression = 1*1(simple-expression / compound-expression / "NONE" / "NOASSERTION")
but semantically incorrect. Let me try to explain using a database data field analogy.
NONE and NOASSERTION are defined at the SPDX document field level and even have different semantic values with respect to different fields. SPDX fields can have several different types assigned which is analogous to a database field. For example, a database field may contain values of *type* Character, Integer, Float, Boolean, Date and so forth. A database field can also contain the special value NULL, which does not belong to a specific data type, but instead represents a special field value (NULL = missing unknown data). NONE and NOASSERTION are analogous to NULL, where a license expression is analogous to a type such as Character, Integer, Float, Boolean, Date and so forth.
A license expression represents the licensing terms of a piece of software (source or binary). In less precise terms, it represents the distribution obligations for a software component. NONE and NOASSERTION do not semantically represent that. To include NONE and NOASSERTION as validate license expressions is analogous to adding NULL to a database type which would be semantically awkward.
In summary, on the surface the following appear syntactically convenient:
license-expression = 1*1(simple-expression / compound-expression / "NONE" / "NOASSERTION")
But semantically it is not correct, and therefore, NONE or NOASSERTION should not be included in the ABNF definition for a license expression.
At least that is one perspective.
Best,
- Mark
Mark Gisi | Wind River | Director, IP & Open Source
Tel (510) 749-2016 | Fax (510) 749-4552
toggle quoted message
Show quoted text
On the surface the following appears to be syntactically convenient:
license-expression = 1*1(simple-expression / compound-expression / "NONE" / "NOASSERTION")
but semantically incorrect. Let me try to explain using a database data field analogy.
NONE and NOASSERTION are defined at the SPDX document field level and even have different semantic values with respect to different fields. SPDX fields can have several different types assigned which is analogous to a database field. For example, a database field may contain values of *type* Character, Integer, Float, Boolean, Date and so forth. A database field can also contain the special value NULL, which does not belong to a specific data type, but instead represents a special field value (NULL = missing unknown data). NONE and NOASSERTION are analogous to NULL, where a license expression is analogous to a type such as Character, Integer, Float, Boolean, Date and so forth.
A license expression represents the licensing terms of a piece of software (source or binary). In less precise terms, it represents the distribution obligations for a software component. NONE and NOASSERTION do not semantically represent that. To include NONE and NOASSERTION as validate license expressions is analogous to adding NULL to a database type which would be semantically awkward.
In summary, on the surface the following appear syntactically convenient:
license-expression = 1*1(simple-expression / compound-expression / "NONE" / "NOASSERTION")
But semantically it is not correct, and therefore, NONE or NOASSERTION should not be included in the ABNF definition for a license expression.
At least that is one perspective.
Best,
- Mark
Mark Gisi | Wind River | Director, IP & Open Source
Tel (510) 749-2016 | Fax (510) 749-4552
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Terin Stock
Sent: Thursday, June 11, 2015 9:21 AM
To: Kate Stewart
Cc: spdx@...
Subject: Re: Exclusion of NONE and NOASSERTION from ABNF
Kate:
I'm unsure of any use case where you would want to mix NONE or NOASSERTION with either simple-expression or compound-expression in the same package. You may however want to use these strings when packaging code that has no license or where you are unsure of the license.
In ABNF speak was thinking more along the lines of
license-expression = 1*1(simple-expression / compound-expression / "NONE" / "NOASSERTION")
--
#Terin Stock
On Thu, Jun 11, 2015 at 9:07 AM, Kate Stewart <kstewart@...> wrote:
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Terin Stock
Sent: Thursday, June 11, 2015 9:21 AM
To: Kate Stewart
Cc: spdx@...
Subject: Re: Exclusion of NONE and NOASSERTION from ABNF
Kate:
I'm unsure of any use case where you would want to mix NONE or NOASSERTION with either simple-expression or compound-expression in the same package. You may however want to use these strings when packaging code that has no license or where you are unsure of the license.
In ABNF speak was thinking more along the lines of
license-expression = 1*1(simple-expression / compound-expression / "NONE" / "NOASSERTION")
--
#Terin Stock
On Thu, Jun 11, 2015 at 9:07 AM, Kate Stewart <kstewart@...> wrote:
Hi Terin,_______________________________________________
On Thu, Jun 11, 2015 at 10:52 AM, Terin Stock <terinjokes@...> wrote:
The ABNF in Appendix IV of the 2.0 version of the specification
allows for short form identifiers, LicenseRef values or combinations
to form a license-expression. However the values "NONE" and
"NOASSERTION" are not valid in a license expression, despite their
useful and defined meaning in the specification.
There are tools that validate their license fields using a
license-expression (two such tools being the package managers npm and
composer, in JavaScript and PHP, respectfully), making the values
"NONE" and "NOASSERTION" invalid.
Are these two values excluded from the ABNF on purpose?
Can you give us a real life use case where either "NONE" or "NOASSERTION"
should be used in combination with other licenses?
If there's a compelling use case as to why it should be allowed, that
can't be expressed another way, we can certainly revisit adding it to
the specification if the folk on the legal team agree.
Thanks, Kate
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx