Comments (10)
Proposal from David W. on legal team email list: For the Tag:value format, any license expression that consists of more than one license identifier and/or LicenseRef, should be encapsulated by parentheses: "( )".
I don't think this is a change in meaning, since it's clear that a "license expression" is a "license-expression", but it might help the reader go back and look at the actual syntax rules.
from spdx-spec.
There's some explicit whitespace handling in #37, although it doesn't currently allow for CR or LF. If the approach looks promising, I can make them legal. I'd rather restrict the legal newlines (more in #45), but I'm happy to update #37 to reflect whatever the consensus opinion on legal whitespace is.
from spdx-spec.
@wking Thanks for #37 Updating it to reflect this issue and #45 seems to make sense.
There is enough changes in #37 I think we should have a broader review before accepting the changes into the spec. @kestewart - let me know if you agree. Perhaps we could schedule a walk-through on one of the tech calls?
from spdx-spec.
from spdx-spec.
To stay asynchronous, maybe I can refactor #37 into a series of smaller pivots.
I like that idea - it would make the decision making easier.
Until then, maybe folks can provide feedback on the other intentional changes listed in the PR topic message?
Would be a good topic to raise on the email distribution list (the issues are not as widely subscribed to). I'm still inclined to make it a topic for the Tuesday meeting, but perhaps we just discuss it at a high level to align on a direction then finish the details in the PR and issues list.
from spdx-spec.
Steve Winslow volunteers to investigate and see if we can get a PR together or recommend moving to 3.0
from spdx-spec.
Attempting to summarize current state and next-step options for issues #44 (this one), as well as #45, #52 and #80, since these are interrelated. Apologies on the length.
I may be wrong on any of the technical details so folks should feel free to weigh in, and I'll correct this as needed!
Problem:
- complexities in parsing are introduced by enabling license expressions with multiple elements (e.g. AND, OR, WITH) to span multiple lines:
- for tag-value files, if license expressions are permitted to span multiple lines, parsing is non-trivial to determine where the license expression ends
- for identifiers in source files, if license expressions are permitted to span multiple lines, it defeats the efficiencies of being able to grep for
SPDX-License-Identifier
and gather all such information.
- currently state under the spec is:
- for tag-value files, the spec (requires? encourages?) that ALL expressions surround multiple elements with parentheses
- see app. IV: "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 has been specified to facilitate expression parsing."
- "should" rather than "must" => is this actually a current requirement, or just encouraged?
- for identifiers in source files, the spec requires that ALL expressions surround multiple elements with parentheses
- see app. V: "A set of licenses must be enclosed in parentheses (this is a convention for SPDX expressions)."
- "must" rather than "should" => compare to above
- for tag-value files, the spec (requires? encourages?) that ALL expressions surround multiple elements with parentheses
- anecdotally, many tools and use of short-form IDs in the wild don't comply with this requirement for parentheses
Potential solutions:
- postpone a decision: kick it down the road to 3.0 without further discussion now
- prohibit multi-line license expressions: require that all license expressions may only be on a single line. This would make surrounding parentheses permissible but not mandatory.
- For tag-value files, this would be a breaking change (e.g. v2.1 docs with multi-line expressions would become invalid) so probably would need to be kicked to 3.0.
- For source code identifiers, could arguably implement now.
- permit multi-line expressions, but don't require parentheses for single-line expressions: permit license expressions to go across multiple lines, but only make parentheses mandatory if they are multi-line. Single-line expressions do not require parentheses.
- I think this is not a breaking change from v2.1, because it is not invalidating anything that is currently permitted under v2.1.
- permit multi-line expressions, using whitespace unfolding: permit license expressions to go across multiple lines, but using the "whitespace unfolding" process that was documented at #80
- I'm not certain whether or not this would be a breaking change from v2.1...
These could be separate outcomes for tag-value vs. source code identifiers.
from spdx-spec.
Posting as a separate comment, to share my personal thoughts now :)
My preference would be:
- for tag-value files: permit multi-line expressions, but don't require parentheses for single-line expressions
- for source code identifiers: prohibit multi-line license expressions
For tag-value files, I think this keeps maximum backwards compatibility while fitting with what I'm anecdotally seeing happening in practice. Also (as best I can tell) minimizing the tooling changes required.
For source code identifiers, I think any reason to permit multi-line expressions is outweighed by the negative impact it would have on usability / greppability of identifiers.
from spdx-spec.
@swinslow Thanks for writing this up and summarizing the issues.
FWIW - I checked the current implementation of the tag/value parser for the SPDX tools and parenthesis are not required for multiple terms. It does not handle multiple lines for license expressions in the tag/value file and no bug has been filed. This tells me it is not very common to span lines.
I'm OK prohibiting multi-line expressions in the source code identifiers, and even OK prohibiting multiline in tag/value.
from spdx-spec.
Thanks @goneall! Good to hear -- if the Java SPDX tools aren't handling multiple lines at all, then agreed, it's doubtful this is really being followed in a significant way.
I'll prep a PR to prohibit multiline in both, and to explain that parentheses are permitted but optional / not required. Unless anyone objects, we can then merge it and be done with this :)
from spdx-spec.
Related Issues (20)
- SpecVerion should be SpecVersion
- ABNF grammar of Annex D and case-sensitivity
- Current Version on spdx.dev is still 2.3 HOT 5
- List not displayed correctly in 4.2 RDF Serialization HOT 1
- Wrong display for strikethrough text HOT 1
- Copyright information in mkdocs.yml need an update for v3.
- Deadlinks for /Core/DateTime, /Core/PresenceType, etc. HOT 2
- ontology/ directory is no longer updated - suggest deletion HOT 6
- The SPDX 3.0 HTML page does not have the version selection dropdown HOT 3
- The PDF version of the 3.0 specification is broken HOT 1
- Several TODOs in specification version 3.0.0 HOT 2
- Consider more prominently presenting Annex B in the 3.0 spec documentation
- https://spdx.github.io/spdx-spec/latest/ redirects to v2.3 HOT 1
- publish_common.yml made a reference to non-existing mike version (1.2.0)
- Version selector dropdown: Removing RC versions of the versions with stable release?
- Inclusion of Glossary in the spec document? HOT 1
- The software Profile contains the property `None` HOT 1
- The 3.0 spec really want you have the Core tree expanded HOT 2
- The diagrams from the model aren't showing up for the 3.0 spec HOT 2
- Setting up spdx.github.io website without project name
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spdx-spec.