On Thu, Oct 12, 2017 at 08:33:18PM +0000, 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 expression or just some > > other text. To solve this ambiguity, we introduced the > > parenthesis requirement for compound licenses only. When this was > > discussed, we also considered requiring compound licenses to be > > restricted to a single line, but we decided that would be too > > limiting. > > Good to know! But you still don't need parentheses when the entire > expression fits on a line (e.g., "MIT OR BSD-3-Clause")…
But how do you determine “fits on one line” without either clear rules
for folding whitespace or a requirement for encapsulating parens?
> …and such expressions are used in the wild anyway, so tools should
> correctly interpret data in this form.
Wild example [1]. I haven't been able to turn up a multi-line example
yet. If we can't find one, perhaps we can safely replace the old
encapsulating-paren requirement with a folding-whitespace requirement.
> In addition, if the purpose is to unambiguously find the end, you
> only need parentheses at the outermost layer…
I agree with this and the next paragraph.
> For clarity, I think that the spec should be tweaked to make this a
> little more obvious.
Yes please :). [2] is my attempt to start on that.
> > For the Tag:value format, any license expression that consists of
> > more than one license identifier and/or LicenseRef, should be
> > encapsulated by parentheses: "( )".
This issue isn't really quantity, it's whitespace. For example:
SPDX-License-Identifier: LicenseRef-Muahahahahahahahahahaha-1.0
WITH u-boot-exception-2.0
only has a single LicenseRef.
> Tools still need to be *able* to parse SDPX license expressions that
> aren't completely surrounded by parentheses. People are likely to
> provide data without parentheses, and tools need to be able to
> correctly parse those cases.
If we can get specific rules for them, then sure. Otherwise I think
parsing malformed data is up to the tool on a best-effort basis. And
some tools are going to want to be more conservative than others.
> Many SPDX license expressions occur outside SPDX files (e.g., in
> package manager data), and in some of those formats it's not
> possible to have multi-line data anyway.
A benefit to folding at the tag:value layer is that the *license
expression* is still a single logical line.
Cheers,
Trevor
[1]:
https://github.com/DataSoft/u-boot/blob/793fd86f722f5c5e13290be2074816b001359b76/arch/arm/dts/vf-colibri.dtsi#L4
[2]: https://github.com/spdx/spdx-spec/pull/37
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
