Need to be able to express Dependencies on a range of versions.

[kestewart]

Thomas: See a need for syntax to capture how a package dependencies where the dependencies are specified with version range e.g. resulting non deterministic builds. SPDX only now offers to specify dependencies using fixed one-on-one relationships e.g Package A depends on Package B v1.1. In reality Package A specifies it relies on Package B v1.0 or newer.

Having this in the spec provides package maintainers a technology agnostic way to specify their dependencies closer to reality. Provides consumers of these packages with an indicator that including package may result license mix that can change with every build. May also be useful to handle the difference between the declared (by maintainer) and resolved dependencies (by package manager).

Example - SPDX specifies dependency on angular 4.1.1, see it’s package.json specifies depends on core-js 2.4.1 or newer

Note: approach is not figured out yet, but general agreement that this is a problem and we should look into solving it for the next release.

[wking]

On Tue, Aug 01, 2017 at 04:57:33PM +0000, Kate Stewart wrote:

Thomas: See a need for syntax to capture how a package dependencies where the dependencies are specified with version range e.g. resulting non deterministic builds. SPDX only now offers to specify dependencies using fixed one-on-one relationships e.g Package A depends on Package B v1.1. In reality Package A specifies it relies on Package B v1.0 or newer.

But for build-time dependencies, the resulting build artifacts will only include particular versions (e.g. B v1.1). In ecosystems that encourage vendoring (e.g. npm, Go, …) the build artifacts may include multiple versions for a single package (e.g. A 1.0 pulls in B 1.1 and C 2.0. B 1.1 pulls in D 3.4 and C 2.0 pulls in D 4.0. So both D 3.4 and 4.0 are included in the build artifacts). But you'll know what got included, you don't need a floating version.

For link-time dependencies and similar, you may have floating dependencies (e.g your build artifact may have a dynamic link to libncurses.so.6, but not care about the exact version of ncurses as long as it provides the API covered by that version. Declaring an SPDX relationship for this would be more complicated, but I don't see why you'd need to do it. If the dynamically linked consumer and the library it links are distributed as separate projects, they'll have independent SPDX. If they're distributed as part of a single project, then it's like the build-time case and you know exactly which versions you're distributing.

Having this in the spec provides package maintainers a technology agnostic way to specify their dependencies closer to reality.

Dependency declaration for package management is complicated and already covered by existing tools which focus only on package management. Attempting to cover it from within SPDX feels off topic to me, and without investing significant resources I doubt we'd be able to provide something more useful than the tools that package managers are already using. So I'd argue for closing this issue and contenting ourselves with being able to express licenses for things that are actually distributed, without getting distracted by attempting to cover everything which could be distributed.

[goneall]

I ~~think~~ this is a non-breaking change, so I'm moving it to 3.1.

@kestewart - let me know if you think this may lead to a breaking change.