search

spdx / spdx-spec

The SPDX specification in MarkDown and HTML formats.
https://spdx.github.io/spdx-spec/
Other
274 stars 134 forks source link

Want to include only package files that are exceptions to package license #61

Open kestewart opened 6 years ago

kestewart commented 6 years ago

Yev Bronshteyn 2016-04-26 17:12:03 UTC Currently, either all the files in a package must be specified or, via the filesAnalyzed attribute, none.

However, there's a use case for specifying only those files that are exceptions to package-level licensing or, perhaps, other metadata. From the email conversation at http://lists.spdx.org/pipermail/spdx-tech/2016-April/003068.html:

I don't see the value of including the filesAnalyzed tag in my use case. I'm not doing "analysis", I am telling you what the answer is. Others can later do analysis, using that and other data, if they want to. Since this is human-created, I'm trying to minimize the number of lines.

Bill Schineller 2016-05-17 17:57:21 UTC Won't come to closure on this for 2.1 version of the Spec, so setting bugzilla Version to 'unspecified'

wking commented 6 years ago

On Tue, Jan 02, 2018 at 07:56:04PM +0000, Kate Stewart wrote:

However, there's a use case for specifying only those files that are exceptions to package-level licensing or, perhaps, other metadata.

I like this idea, however, I think the implementation needs to be a bit more complicated. My impression of the package license fields [1,2] was that they were indended to cover the whole package including outliers, not just “the usual” content. That means the package license fields are a poor source of default data. I'd rather have an explicit default per-file/snippet metadata setting, which individual per-file/snippet entries could inherit (and optionally override). In case it helps, pax does something simmilar with its global extended header records 3.

Another wrinkle is that without per-file checksums 4 it won't be clear which files the author intended to cover with their default settings. Are we ok punting that to higher levels?

So I think there may be room for something in this direction, but I'm not particularly excited about sorting out the details we'd need to address to make it work robustly ;).

goneall commented 3 months ago

Kicking this down the road to 3.1 - perhaps we should close this as it hasn't been taken up for several years.

Thoughts @kestewart ?