Dne petek, 2. avgust 2024 ob 15:38:40 GMT +2 ste napisali: > I think the purpose of the SPDX File Tags was intentionally limited to > file-level metadata, since that’s what aligns with e.g. embedding inside a > single source code file.
That brings me back to `ArtifactOf[…]` tags that were deprecated … more on that below. > Where the goal is to convey package-level information, I’d guess it would > probably be best to just create an actual SPDX document for the package > metadata? With this use case I am not interested in handling information for the whole package/repository, I am in fact interested in _where this file/snippet came from_. Let us say I have a source code repository where there is 1000s of files that are my own, and a few dozen that I copied (files or snippets) from elsewhere. Let us say I want to track where those files (or snippets) came from (for updating, security, license (un)ambiguity, … reasons). And I want that info to travel together with those files (or snippets) if they are copied further. Another use case would be to record the provenance of all the source code files in my own repository, so if they end up elsewhere, it is easy to track down the upstream. How can I do that? This was technically possible until SPDX 1.8.4, as the following were File- level tags: https://spdx.github.io/spdx-spec/v2.3/file-information/#89-artifact-of-project-name-field-deprecated https://spdx.github.io/spdx-spec/v2.3/file-information/#810-artifact-of-project-homepage-field-deprecated https://spdx.github.io/spdx-spec/v2.3/file-information/#811-artifact-of-project-uniform-resource-identifier-field-deprecated So it is not a new need, just that until File Tags and REUSE picked up, I assume it was very limited how they could be actually implied in practice. `ArtifactOf[…]` tags are said to be deprecated in favour of “External Packages”, which is not a thing. The closest to that are “F. External Repository Identifiers” and the “7.21 External reference field”, which are Package-level. So in the conversion that happened in 1.8.4, it seems the ability to associate a file with an external package has been lost. While my use case is about File Tags and storing this information in source code files directly, it seems to me that this gap (at least in 2.x) is also present in SPDX Documents. Unless I am missing something, there is no way (anymore) to associate a covered file with an external package or otherwise indicate its origin. > See also this discussion thread from 2021/2022 regarding the idea of having > a sort of “pre-SPDX” lightweight manifest that could be used to > auto-generate an SPDX document: > https://github.com/spdx/spdx-spec/issues/502#issuecomment-807414277. That is a different, although slightly tangental use case. cheers, Matija -- gsm: tel:+386.41.849.552 www: https://matija.suklje.name xmpp: [email protected] matrix: @silverhook:matrix.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1909): https://lists.spdx.org/g/spdx/message/1909 Mute This Topic: https://lists.spdx.org/mt/107684319/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/spdx/leave/2655439/21656/1698928721/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
