Hi Kate,

the example of “LicenseRef-LGPL-3.0+” was a bad one. It should have been 
“LicenseRef-ArbitraryName+”. Writing out “+” as “plus” is one of the options 
I’m looking at.

In any case, will you take care of the inconsistencies in the sepec?

Thanks,
Sebastian


From: Kate Stewart [mailto:[email protected]]
Sent: Thursday, October 29, 2015 17:03
To: Gary O'Neall <[email protected]>
Cc: Schuberth, Sebastian <[email protected]>; Bill Schineller 
<[email protected]>; [email protected]
Subject: Re: Is "+" a valid character of a LicenseRef idstring?

Hi Sebastian,
     In the case of LicenseRef-LGPL-3.0+,  why are you not just using the short 
form identifier LGPL-3.0+?
If you need to preserve the extracted text, possibly look to name it 
LicenseRef-LGPL-3.0-plus?

Thanks, Kate


On Thu, Oct 29, 2015 at 10:21 AM, Gary O'Neall 
<[email protected]<mailto:[email protected]>> wrote:
Hi Sebastian,

I believe that would be the expected behavior in 2.0.  Unfortunately, it is
incompatible than the 1.2 spec where the + would have been allowed.  I don't
recall discussing this specific scenario when developing the 2.0 spec - so
others, feel free to comment if you disagree.

In the SPDX Tools, we have tried to maintain backwards compatibility for
reading the older versions.  If the spec version reads < 2.0, I would expect
the tool to allow this since it would be acceptable in the 1.2 spec. There
is probably a bug in the tool where it treats the LicenseRef's the same for
both 2.0 and pre-2.0 versions.  We could use the fix you have already
written with an additional conditional on the spec version.  It would
probably make the code a bit messier, but it would better support backwards
compatibility.

Gary

> -----Original Message-----
> From: Schuberth, Sebastian 
> [mailto:[email protected]<mailto:[email protected]>]
> Sent: Thursday, October 29, 2015 1:42 AM
> To: Gary O'Neall; 'Bill Schineller'
> Cc: [email protected]<mailto:[email protected]>
> Subject: RE: Is "+" a valid character of a LicenseRef idstring?
>
> 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]<mailto:[email protected]>]
> > Sent: Wednesday, October 28, 2015 18:19
> > To: Schuberth, Sebastian 
> > <[email protected]<mailto:[email protected]>>; 'Bill
> Schineller'
> > <[email protected]<mailto:[email protected]>>
> > Cc: [email protected]<mailto:[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:[email protected]> 
> > > [mailto:spdx-tech-<mailto:spdx-tech->
> > > [email protected]<mailto:[email protected]>] On Behalf Of 
> > > Schuberth, Sebastian
> > > Sent: Wednesday, October 28, 2015 4:59 AM
> > > To: Bill Schineller
> > > Cc: [email protected]<mailto:[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]<mailto:[email protected]>]
> > > > Sent: Wednesday, October 28, 2015 12:19
> > > > To: Schuberth, Sebastian 
> > > > <[email protected]<mailto:[email protected]>>
> > > > Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
> > > > > https://lists.spdx.org/mailman/listinfo/spdx-tech
> > > _______________________________________________
> > > Spdx-tech mailing list
> > > [email protected]<mailto:[email protected]>
> > > https://lists.spdx.org/mailman/listinfo/spdx-tech

_______________________________________________
Spdx-tech mailing list
[email protected]<mailto:[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