RE: Spec recommendation for paren encapsulation?

2017-10-12 Thread Gary O'Neall
Trevor and David - all good points. I'm just providing the historical information on the current spec. I was involved in this discussion as the original proposal could not be reliably parsed due to the previously described ambiguity. We discussed several different proposals at length

Re: Spec recommendation for paren encapsulation?

2017-10-12 Thread W. Trevor King
On Thu, Oct 12, 2017 at 08:33:18PM +, Wheeler, David A wrote: > Gary O'Neall [mailto:g...@sourceauditor.com]: > > If we have more than one line for a compound set of licenses, it > > would be ambiguous if the text following the first line of a > > compound license is part of the license

RE: Spec recommendation for paren encapsulation? (was: signifigance of nested parenthesis with only ORs?)

2017-10-12 Thread Wheeler, David A
Gary O'Neall [mailto:g...@sourceauditor.com]: > If we have more than one line for a compound set of licenses, it would be > ambiguous if the text following the first line of a compound license is part > of the license expression or just some other text. To solve this ambiguity, > we introduced

Re: Spec recommendation for paren encapsulation?

2017-10-12 Thread W. Trevor King
On Thu, Oct 12, 2017 at 01:08:28PM -0700, Gary O'Neall wrote: > The current definition for a file license expression allows for more than one > line: > "... The SPDX License Identifier syntax may consist of a single > license (represented by a short identifier from the SPDX license > list) or a

RE: Spec recommendation for paren encapsulation? (was: signifigance of nested parenthesis with only ORs?)

2017-10-12 Thread Gary O'Neall
> -Original Message- > From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal- > boun...@lists.spdx.org] On Behalf Of Wheeler, David A > Sent: Thursday, October 12, 2017 12:07 PM > To: W. Trevor King > Cc: SPDX-legal > Subject: RE: Spec recommendation for paren encapsulation? (was: >

RE: Spec recommendation for paren encapsulation? (was: signifigance of nested parenthesis with only ORs?)

2017-10-12 Thread Wheeler, David A
W. Trevor King [mailto:wk...@tremily.us]: > The Appendix V wording for that is: > > Representing Multiple Licenses > > Multiple licenses can be represented using a SPDX license expression > as defined in Appendix IV. A set of licenses must be enclosed in > parentheses (this is a

RE: signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

2017-10-12 Thread Wheeler, David A
Bradley M. Kuhn: > So you can confirm there is *absolutely* no semantic licensing difference > between a series of OR expressions with or without parenthetical > groupings? I don't speak for SPDX :-). But I can read, and hopefully that's something :-). I don't see anything in the SPDX

Spec recommendation for paren encapsulation? (was: signifigance of nested parenthesis with only ORs?)

2017-10-12 Thread W. Trevor King
On Thu, Oct 12, 2017 at 06:21:05PM +, Wheeler, David A wrote: > The section you want to consult is SPDX specification version 2.1, > Appendix IV ("SPDX License Expressions"): > https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60 > > Subsection "Composite License Expressions"

Re: signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

2017-10-12 Thread Bradley M. Kuhn
David, So you can confirm there is *absolutely* no semantic licensing difference between a series of OR expressions with or without parenthetical groupings? Folks on the call today seemed to indicate there might be a semantic difference that the Eclipse Foundation had asked for. -- Bradley M.

Re: signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

2017-10-12 Thread Wayne Beaton
I realise that I'm using the parentheses incorrectly or at least needlessly according to the specification. I understand that they add no machine-readable meaning. I believe that I stated as much earlier on this thread. My abuse of the parentheses was an attempt to express something that SPDX

RE: signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

2017-10-12 Thread Wheeler, David A
Bradley M. Kuhn: > Could you explain a bit further why the extra parenthesis grouping is > needed when only ORs are involved? As you guessed, the parentheses are not *needed*. The SPDX spec says that parentheses SHOULD be used when there are multiple license identifiers or license refs, but

Re: signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

2017-10-12 Thread Brad Edmondson
Thanks Bradley, I took Wayne's note to mean he thought it was more human-readable that way (with parens) for people working on his project, not that it would evaluate differently than a list of ORs with no parens. Best, Brad Edmondson -- Brad Edmondson, *Esq.* 512-673-8782 |

signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

2017-10-12 Thread Bradley M. Kuhn
Wayne Beaton wrote on Monday, 2 October: > (EPL-2.0 OR (LicenseRef-GPL-2.0-with-Assembly-exception OR GPL-2.0 > with Classpath-exception-2.0)) OR Apache-2.0 > > I threw in the extra grouping because it felt like they needed to be > together. Could you explain a bit further why the extra

Re: only/or later and the goals of SPDX

2017-10-12 Thread W. Trevor King
On Thu, Oct 12, 2017 at 10:44:54AM -0400, John Sullivan wrote: > I understand SPDX doesn't want to make legal judgments. Which is > why it should indicate when there is uncertainty. While SPDX should avoid making legal judgements, I don't think it necessarily follows that they need to enable

Re: meeting at top of the hour

2017-10-12 Thread J Lovejoy
we hit our limit on the regular conference line - please go to: Join the call: https://www.uberconference.com/katestewart Optional dial in number:877-297-7470 Alternate number: 512-910-4433 No PIN needed \ > On Oct 12, 2017, at 10:10 AM, J

RE: only/or later and the goals of SPDX

2017-10-12 Thread Wheeler, David A
John Sullivan: > A key part is missing in the description of the original FSF proposal here > though -- which is deprecating the existing GPL-2.0 and similar "plain" > identifiers for GNU licenses so that the identifiers used always indicate > whether the version is "only" or "any later". > > As I

meeting at top of the hour

2017-10-12 Thread J Lovejoy
HI all, We have our usual call at the top of the hour, usual dial-in. http://wiki.spdx.org/view/Legal_Team We will start by checking in on progress of the next release, XML work, and then pick up the discussion on the GNU licenses/ only/or later proposal

Re: only/or later and the goals of SPDX

2017-10-12 Thread John Sullivan
Hi Jilayne, Thanks for writing this up. A key part is missing in the description of the original FSF proposal here though -- which is deprecating the existing GPL-2.0 and similar "plain" identifiers for GNU licenses so that the identifiers used always indicate whether the version is "only" or

RE: only/or later and the goals of SPDX

2017-10-12 Thread Gisi, Mark
Hi Jilayne, It would be helpful to provide actual source code examples of where the proposed operator would be applicable. This was done for each operator included in the first release of the license expression language which was very productive: https://wiki.spdx.org/view/FileNoticeExamples

Re: only/or later and the goals of SPDX

2017-10-12 Thread W. Trevor King
On Wed, Oct 11, 2017 at 11:13:56PM -0600, J Lovejoy wrote: > But this missed a key part of the core goals of SPDX: Implicit in > those above goals is that the SPDX License List (including the > license short identifiers and the license expression language) aim > to provide a “language” to identify