I can see your point, Gary.

Let me go one step back and tell you how I came across this issue: I had the 
following line in my tag-value file

LicenseInfoInFile: LicenseRef-LGPL-3.0+

As the spec requires to have a non-listed license declared, I also had

LicenseID: LicenseRef-LGPL-3.0+
ExtractedText: <text>Some text.</text>

However, the parser was choking on it as was looking for "LicenseID: 
LicenseRef-LGPL-3.0", without the plus. Is that the intended behavior?

Regards,
Sebastian


> -----Original Message-----
> From: Gary O'Neall [mailto:[email protected]]
> Sent: Wednesday, October 28, 2015 18:19
> To: Schuberth, Sebastian <[email protected]>; 'Bill Schineller'
> <[email protected]>
> Cc: [email protected]
> Subject: RE: Is "+" a valid character of a LicenseRef idstring?
> 
> After looking at the proposed code change, the "+" would not imply an or-
> later operator for non-listed license ID's (a.k.a. license-refs).
> 
> I can think of a use case that would not be satisfied if we make this change 
> to
> the parser:
> 
> Use Case - SPDX Document containing a non listed license that has both
> specific version and or later cases Actors - SPDX document creator, SPDX
> document consumer
> Steps:
> - Source code contains code under a non listed license
> - A license-ref is created to represent that code
> - Different code contains a reference to the non listed license with an "or
> later version" clause
> - A license expression is created with the license-ref and a "+" operator to
> represent the or-later
> 
> I agree with Bill that the bug is in the spec - when we discussed implementing
> the license expression language, we intended (or at least I
> intended) for the same expressions to be used for listed and non-listed
> licenses.
> 
> Gary
> 
> > -----Original Message-----
> > From: [email protected] [mailto:spdx-tech-
> > [email protected]] On Behalf Of Schuberth, Sebastian
> > Sent: Wednesday, October 28, 2015 4:59 AM
> > To: Bill Schineller
> > Cc: [email protected]
> > Subject: RE: Is "+" a valid character of a LicenseRef idstring?
> >
> > I was assuming something like that. However, technically there
> > shouldn't be a reason to make "+" a reserved operator for idstrings.
> > As idstrings (or license-refs) are no compound-expression as defined
> > in Appendix IV it should be safe to just skip parsing idstrings /
> > license- refs for "+".
> >
> > I've make a proposal how to implement that as part of [1].
> >
> > [1] https://github.com/spdx/tools/pull/66
> >
> > Regards,
> > Sebastian
> >
> >
> > > -----Original Message-----
> > > From: Bill Schineller [mailto:[email protected]]
> > > Sent: Wednesday, October 28, 2015 12:19
> > > To: Schuberth, Sebastian <[email protected]>
> > > Cc: [email protected]
> > > Subject: Re: Is "+" a valid character of a LicenseRef idstring?
> > >
> > > Methinks the current intention of spec writers is:
> > >
> > > + is now a reserved operator for the License Expression Syntax
> > >
> > > So therefore + should be illegal character in license idstring
> > >
> > > So inconsistency in this regard would seem to be a bug in the spec
> > >
> > > -Bill
> > >
> > > > On Oct 28, 2015, at 5:42 AM, Schuberth, Sebastian
> > > <[email protected]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > when debugging an issue in the spdx-tools verifier, I noticed the
> > > > SPDX 2.0
> > > specs seem to be inconsistent on whether "+" is a valid character in
> > a
> > > LicenseRef's idstring, like in LicenseRef-[idstring].
> > > >
> > > > Sections 3.13.4 and 4.6.4 also refer to LicenseRefs and say
> > > >
> > > >    [idstring]  is  a  unique  string  containing  letters,
> > numbers,  "."  or  "-"
> > > >
> > > > Yet section 5.1.4 explicitly says for the case of LicenseRef
> > > >
> > > >    [idstring]  is  a  unique  string  containing  letters,
> > numbers,  ".",  "-"  or  "+"
> > > >
> > > > Is there any consensus? I'd vote for "+" to be valid in order to
> > > > have
> > > LicenseRefs like "LicenseRef-LGPL-3.0+".
> > > >
> > > > BTW: There's similar inconsistencies regarding DocumentRef
> > > > idstrings, see
> > > sections 2.6.4 vs. 3.13.4 / 4.6.4 and other places that refer to an
> > SPDXID.
> > > >
> > > > Sebastian Schuberth
> > > > Lead Engineer
> > > > Open Source Governance, Chief Technology Office
> > > > Mobile: +49 151 551 551 40
> > > >
> > > > HERE Berlin
> > > > Invalidenstrasse 116
> > > > 10115 Berlin
> > > > 52° 31' 52" N. 13° 23' 5" E
> > > > HERE, a Nokia company
> > > >
> > > > Place of Business: HERE Deutschland GmbH, Invalidenstrasse 116,
> > > > 10115 Berlin, Germany - Commercial Register: Amtsgericht
> > > > Charlottenburg, HRB 106443B - USt-IdNr.: DE 812 845 193 - Managing
> > > > Directors: Michael
> > > Bültmann, Robertus A.J. Houben CONFIDENTIALITY NOTICE This e-mail
> > > and any attachments hereto may contain information that is
> > > privileged or confidential, and is intended for use only by the
> > > individual or
> > entity
> > > to which it is addressed. Any disclosure, copying or distribution of
> > > the information by anyone else is strictly prohibited. If you have
> > > received this document in error, please notify us promptly by
> > responding to this e-mail. Thank you.
> > > >
> > > > _______________________________________________
> > > > Spdx-tech mailing list
> > > > [email protected]
> > > > https://lists.spdx.org/mailman/listinfo/spdx-tech
> > _______________________________________________
> > Spdx-tech mailing list
> > [email protected]
> > https://lists.spdx.org/mailman/listinfo/spdx-tech

_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech

Reply via email to