Topics

In favour of what are §4.9–4.11 deprecated?

Matija ?uklje
 

Hi all,

I notice that in 2.1 spec the following are marked as deprecated
on the file-level:

• 4.9 Artifact of Project name
• 4.10 Artifact of Project Homepage
• 4.11 Artifact of Projecr Uniform Resource Identifier

…and I wonder what was the new equivalent to get information of
origin for a file in the package. Is the assumption now that files
of alien origin to the analysed package must belong to a different
package and that package should have its own SPDX file, to which
the first SPDX file should refer to?

A use common use case I can see could be how to mark font and
image files that are commonly copied from elsewhere instead of
each piece of software reinventing their icons and type faces.


cheers,
Matija Šuklje
--
gsm: +386 41 849 552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...

Gary O'Neall
 

Hi Matija,

-----Original Message-----
From: spdx@... <spdx@...> On Behalf Of Matija ?uklje
Sent: Wednesday, July 24, 2019 7:19 AM
To: spdx@...
Subject: [spdx] In favour of what are §4.9–4.11 deprecated?

Hi all,

I notice that in 2.1 spec the following are marked as deprecated on the file-level:

• 4.9 Artifact of Project name
• 4.10 Artifact of Project Homepage
• 4.11 Artifact of Projecr Uniform Resource Identifier

…and I wonder what was the new equivalent to get information of origin for a
file in the package. Is the assumption now that files of alien origin to the
analysed package must belong to a different package and that package should
have its own SPDX file, to which the first SPDX file should refer to?
[G.O.]
[G.O.] The idea is that there would be a package definition. It could be in a separate SPDX document, or more likely, as a separate SPDX package definition within the same SPDX document. The originating package definition could have the FilesAnalyzed set to false which allows for a rather small number of required fields. The origin could then be indicated by a relationship between the file and the package.
-=-=-=-=-=-=-=-=-=-=-=-
[G.O.] Gary

Matija ?uklje
 

On nedelja, 28. julij 2019 22:15:26 CEST, Gary O'Neall wrote:
[G.O.] The idea is that there would be a package definition. It could be in a separate SPDX document, or more likely, as a separate SPDX package definition within the same SPDX document. The originating package definition could have the FilesAnalyzed set to false which allows for a rather small number of required fields. The origin could then be indicated by a relationship between the file and the package.
I see. Is there already any tooling available to make this actually usable in practice? Sw360, DejaCode?


cheers,
Matija

P.S. Sorry about the late reply, I had a lot going on in the past few weeks/months.
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...