Issues versus mailer?

[Billie Alsup]

What is the preferred communication method regarding rules_license repo?  I notice the mailing list is not very active.  Are opening new issues on github preferred?

I'm interested in integrating rules_license into my workspace, and am wondering if there is a roadmap available (possibly needing resources to sign up for implementation).  I'm particularly interested in generating SPDX eventually, and am wondering if there is a plan to support additional attributes as used in SPDX.

I note the calendar link to the monthly eng meeting is not available, at least in the main branch.

[Tony Aiuto]

On Tue, Oct 17, 2023 at 12:14 PM Billie Alsup <billie...@gmail.com> wrote:

What is the preferred communication method regarding rules_license repo?  I notice the mailing list is not very active.  Are opening new issues on github preferred?

Issues on github are the best place for focused issues, and the list is better for open-ended discussions.

I'm interested in integrating rules_license into my workspace, and am wondering if there is a roadmap available (possibly needing resources to sign up for implementation).

We don't have a good roadmap at this time. I'm hoping that when we do a planning sprint at the end of next week, we can deliver one soon after that. The first things to come on line will be java packages from rules_jvm_external. Dealing with the package managers for other languages is a new round of issues, one where help from the community will be needed. 

I'm particularly interested in generating SPDX eventually, and am wondering if there is a plan to support additional attributes as used in SPDX.

The first round is mostly package name and download location. As we pull more components out of the various package

managers it is straight forward to add them.  What particular things are you prioritizing?

I note the calendar link to the monthly eng meeting is not available, at least in the main branch.

It is available via a pinned issue.  https://github.com/bazelbuild/rules_license/issues/34

What did you try that went nowhere.

--
You received this message because you are subscribed to the Google Groups "bazel-ssc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-ssc+...@bazel.build.
To view this discussion on the web visit https://groups.google.com/a/bazel.build/d/msgid/bazel-ssc/c8cfffc5-067c-44e2-a482-8867a7435099n%40bazel.build.
For more options, visit https://groups.google.com/a/bazel.build/d/optout.

[Billie Alsup]

On Wednesday, October 18, 2023 at 9:23:33 PM UTC-7 ai...@google.com wrote: 

I'm particularly interested in generating SPDX eventually, and am wondering if there is a plan to support additional attributes as used in SPDX.

The first round is mostly package name and download location. As we pull more components out of the various package

managers it is straight forward to add them.  What particular things are you prioritizing?

I have been adding license() invocations for files in the workspace, but I also want to be able to able to import license information with external files. External files might be RPMs, or simple firmware images.  Each would have an associated SBOM already (that is the goal anyways) that I would like to import, such that a generated SPDX on a particular target would either include or have an externalDocumentRef entry in the SPDX.  There are many attributes that can be used in SPDX, and I'm wondering how we might want to manage such metadata.  For example, there is a summary field, validUntilDate, licenseComments, LicenseConcluded versus LicenseDeclared, supplier versus originator. etc.    The OpenEmbedded project generates SPDX files for each RPM generated (separate build time and runtime SPDX files iirc) as well as a recipe level SPDX file.  So we will import some prebuilt RPMs and their headers into a sandbox for the compile/link, we might package such RPMs into an ISO, and there may be third part code that is built within the bazel project itself.  I'm wondering if the plan is to generate SPDX from Bazel rules itself, or if the existing json output should simply be fed into external processes to generate an SPDX (presumably using external metadata, versus metadata collected in BUILD files).

I note the calendar link to the monthly eng meeting is not available, at least in the main branch.

It is available via a pinned issue.  https://github.com/bazelbuild/rules_license/issues/34

What did you try that went nowhere.

From the Code tab at https://github.com/bazelbuild/rules_license , the README.md is automatically formatted for display.  Here it shows Monthly eng meeting: calendar_link and that link apparently is set to a URL that doesn't resolve for me:

https://github.com/bazelbuild/rules_license/blob/main/MjAyMjA4MjJUMTYwMDAwWiBjXzUzcHBwZzFudWthZXRmb3E5NzhxaXViNmxzQGc&tmsrc=c_53pppg1nukaetfoq978qiub6ls%40group.calendar.google.com&scp=ALL

[Tony Aiuto]

On Thu, Oct 19, 2023 at 8:20 PM Billie Alsup <billie...@gmail.com> wrote:

On Wednesday, October 18, 2023 at 9:23:33 PM UTC-7 ai...@google.com wrote: 

I'm particularly interested in generating SPDX eventually, and am wondering if there is a plan to support additional attributes as used in SPDX.

The first round is mostly package name and download location. As we pull more components out of the various package

managers it is straight forward to add them.  What particular things are you prioritizing?

I have been adding license() invocations for files in the workspace, but I also want to be able to able to import license information with external files. External files might be RPMs, or simple firmware images.  Each would have an associated SBOM already (that is the goal anyways) that I would like to import, such that a generated SPDX on a particular target would either include or have an externalDocumentRef entry in the SPDX.

This concept is well known and we have to support it. No one has done a proof of concept with rules_license yet.

 

 There are many attributes that can be used in SPDX, and I'm wondering how we might want to manage such metadata.  For example, there is a summary field, validUntilDate, licenseComments, LicenseConcluded versus LicenseDeclared, supplier versus originator. etc.  

These could all be new attributes on PackageInfo

 

 The OpenEmbedded project generates SPDX files for each RPM generated (separate build time and runtime SPDX files iirc) as well as a recipe level SPDX file.  So we will import some prebuilt RPMs and their headers into a sandbox for the compile/link, we might package such RPMs into an ISO, and there may be third part code that is built within the bazel project itself.

 

I'm wondering if the plan is to generate SPDX from Bazel rules itself.

Yes. For trust in the accuracy, you want to create the artifact and the SBOM for it in the same bazel bulid run. We can do this with either a command line aspect, of building a spdx_sbom() target associated with the main artifact.

or if the existing json output should simply be fed into external processes to generate an SPDX (presumably using external metadata, versus metadata collected in BUILD files).

Well, that sort of happens under the hood anyway.  The aspect can only read the graph edges, so we output that in a JSON blob. Then we pass over it to add package information missing in the build, but present in package manager lock files like the MODULE.bzlmod.lock or the maven.lock, then add LICENSE texts if we need those, and maybe more.