Bug 4516

*** Bug 1778 has been marked as a duplicate of this bug. ***

Do you want the manifests to be source based?  I.e. based on the SPDX description of the sources used to generate a given recipe/package?

Or do you expect further processing to derive the exact sources used to generate the file(s), and then collate those sources into a single SPDX that describes the package, image or SDK?

I can see a few use cases here:

1. I have access to a web repository of all SPDX docs for files within the packages that my image could contain. I don't want to take the time to generate all of this, so my manifest contains an entry for the package with entries for the files for the package and links to the SPDX files.

2. I want to use the metadata to create the SPDX for the packages and create a manifest that would link to this either through a http or file URI.

3. I want SPDX swabber to ignore the metadata, derive the license from the exact sources and use this to generate the manifest.

The typical case that I am aware of is that a recipe can point to an SPDX that describes all of the files/sources that recipe uses.

The packages inherit this value, and simply references or includes this file.

The image / SDK then references each of the file(s) referenced by the packages that were used.

This gives a full description of all of the sources that could have been used to generate the binaries in the package(s) and thus the image/SDK.

It does NOT give an accurate description of the license of an individual binary, or the image/SDK.  Instead it gives a view of the superset of files/license for everything.

This should function not to horribly different from sstate cache/mirror when generating low-def data. The first run will of course be slow, but subsequent runs can utilize the cache and only update src that has been updated. 

Let me hash this out my idea of the use model. (this is me thinking out loud, please don't take this as anything other than that)

I run the yocto project infrastructure/autobuilder system. The autobuilder produces a lot of artifacts used by developers. Download mirrors, sstate mirror, adt repository. I would like to produce an SPDX data mirror. 

I would like to have something like this in my config:

SPDX_DATA_MIRROR = "http://spdx.yoctoproject.org/"
SPDX_DATA_DIR = "/var/www/spdx.yoctoproject.org/"
GENERATE_SPDX_DATA = "1"

# can be license to just rely on LICENSE. 
# If anything else we attempt to inherit the named bbclass.
# This allows for third party plugins

SPDX_DATA_FIDELITY = "fossology" 

During a stage in the build, we would check the SPDX_DATA_MIRROR. If the PN/PV existed:

http://spdx.yoctoproject.org/[a-z]/${PN}/${PV}/files/(rdf of every file)
                                               checksum

and some checksum hadn't changed (probably utilize SRC_URI[md5sum] or something) then we would do nothing. If it had changed, and we had set GENERATE_SPDX_DATA = "1" we would generate the new SPDX data for each file and dump it into:

/var/www/spdx.yoctoproject.org/${PN}/${PV}

We'd then utilize SPDX_DATA_MIRROR to point each entry in our manifest to the appropriate area.

I have been looking for a proof-of-concept
implementation in rpm of "metatag" (i.e. like licensing)
attached to files for several years.

I would like to be able to attach (i.e. through
something like a digest on content, or a digest
on the source files compiled/linked into a library/executable)
a licensing tag.

I would then like to apply transitive closure across
the metatarsi to objectively determine that (say)
    A file that claims to be LGPL does not use any GPL* licensed code

Interested? Mark Hatle knows how to contact me as <jbj@rpm5.org>

Ick "metatags" not "metatarsi"

Fixed by  meta/classes/create-spdx.bbclass. Open a new ER if there are gaps.

bulk change to add Saul's non-WR address.

Bulk change: Remove Saul's old WR address.