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 compound set of licenses (represented by joining together > multiple licenses using the license expression syntax)..."
I don't see anything about newlines in there. What I'm wondering is whether: APACHE-2.0 OR GPL-3.0 is a valid license expression, and whether: SPDX-License-Identifier: (APACHE-2.0 OR GPL-3.0) is a valid SPDX-License-Identifier entry. I *do* see [1]: The tag should appear on its own line in the source file… which is using the singular ‘line’, although it's not clear to me whether that was intention, or whether it should have been line(s). > 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. Email addresses this with folding headers [2,3,4]: FWS = ([*WSP CRLF] 1*WSP) / obs-FWS obs-FWS = 1*WSP *(CRLF 1*WSP) compare the ABNF spec's [5]: LWSP = *(WSP / CRLF WSP) and you can see that LWSP allows the consecutive-folds problem discussed in [4]. As long as something like: FWS' = ([*WSP CRLF] 1*WSP) was used in our spec (for tag:value? Maybe just use RFC 5322 for tag:value?), I don't see any ambiguity. We'd probably want a more relaxed newline: FWS" = ([*WSP NL] 1*WSP) NL = CR LF / CR / LF because we're not always looking at internet-standard-newline files, but that's not a big pivot. > 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. I don't actually see anything in the spec about allowing multiple lines. Can you point at the wording? Or maybe there is no such wording in the spec, and we should add it (for 2.2?). Cheers, Trevor [1]: https://github.com/spdx/spdx-spec/blame/cfa1b9d08903befdf03e669da6472707b7b60cb9/chapters/appendix-V-using-SPDX-short-identifiers-in-source-files.md#L25 [2]: https://tools.ietf.org/html/rfc5322#section-2.2.3 [3]: https://tools.ietf.org/html/rfc5322#section-3.2.2 [4]: https://tools.ietf.org/html/rfc5322#section-4.2 [5]: https://tools.ietf.org/html/rfc5234#page-14 -- 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
