Copyright Notices

[Mats Nilsson]

Hello!

Thanks for a neat library. I am integrating version 51168a1d13d8577e854625c06b0949987c17fcf7 at my workplace.

What is the workflow supposed to be for copyright notice? For example boost have a huge list of authors/contributors. Could that be added dynamically to the SBOM/json somehow?

Kind Regards

Mats

[Tony Aiuto]

On Mon, Nov 14, 2022 at 9:44 AM Mats Nilsson <matn...@gmail.com> wrote:

Hello!

Thanks for a neat library. I am integrating version 51168a1d13d8577e854625c06b0949987c17fcf7 at my workplace.

Can you point to a PR or something concrete, what repository is that even in?

 

What is the workflow supposed to be for copyright notice? For example boost have a huge list of authors/contributors.

Can you point to what boost does there?

 

Could that be added dynamically to the SBOM/json somehow?

Without context I can't say. I can, however, say,

• If we can get copyright notices into BUILD files or some other source (maven POM, other package definition, ...) then we can mechanically splice that into an SBOM
• I strongly believe it is the responsibility of a package author to put the copyright notice they want in a well-known place. That would be in the package definition. Of course, package definitions vary widely depending on the environment, Maven != NPM != BCR != PIP != Go module != configure
• The Bazel team is explicitly not working on scanning your third party source code to pull out copyright notices and get them into the build graph.
• Likewise, we are not working on scanning source code to find the OSS licenses, but Google does sponsor an OSS license scanner project.
• I welcome projects that do scan code for copyright notices, but not as part of rules_license at this time.

FWIW, I think code scanning is a difficult research problem.  If you have a project with many contributors and distinct slices, you can have different licenses used and needed copyright notices depending on what slice you use.  So, until the project itself provides Bazel BUILD file which clearly define those things for each distinct sub-component one could depend on, you have an impedance mismatch.

 

Kind Regards

Mats

--
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/b9b9465f-a8ae-4441-87a7-adc53200d375n%40bazel.build.
For more options, visit https://groups.google.com/a/bazel.build/d/optout.

[Mats Nilsson]

Sorry for too little information, I am referring to the bazelbuild/rules_license repo:
https://github.com/bazelbuild/rules_license/commit/51168a1d13d8577e854625c06b0949987c17fcf7

In that version of the implementation of rules_license there is the license metadata tag:

license( name = ..., package_name = ..., copyright_notice = "<what to put here>", ... )

The copyright notice is trivial when the author/contributor list is small eg. "Copyright (c) YYYY John Doe", but the boost C++ library, https://github.com/boostorg/boost, has unique copyright author-year pairs which number in the thousands.
Should we manually add this to the license metadata in our patched BUILD.bazel-file? Upstream license attributes is missing in this case and for many of our dependencies.
I just noticed that in this specific case the license says that it's not needed if distributed in binary form:
> [...] unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor [...]
But if rules_license is not planning on adding any functionality for extracting Copyright from src files we might try to automate that on the side and import that into our deliveries.

I notice some SPDX identifiers in the draft PR 59, https://github.com/bazelbuild/rules_license/pull/59, is SPDX SBOM format on the near term roadmap?

[Tony Aiuto]

On Mon, Nov 14, 2022 at 2:25 PM Mats Nilsson <matn...@gmail.com> wrote:

Sorry for too little information, I am referring to the bazelbuild/rules_license repo:
https://github.com/bazelbuild/rules_license/commit/51168a1d13d8577e854625c06b0949987c17fcf7

You're better off with https://github.com/bazelbuild/rules_license/pull/59

 

In that version of the implementation of rules_license there is the license metadata tag:

license( name = ..., package_name = ..., copyright_notice = "<what to put here>", ... )

Right. I also have it in package_info(). There is no clear case where the copyright should go, but I think package_info is slightly better than license()

The copyright notice is trivial when the author/contributor list is small eg. "Copyright (c) YYYY John Doe", but the boost C++ library, https://github.com/boostorg/boost, has unique copyright author-year pairs which number in the thousands.
Should we manually add this to the license metadata in our patched BUILD.bazel-file? Upstream

Yes, but obviously no. There needs to be a way to point to a file which contains all the copyright notices.

 

license attributes is missing in this case and for many of our dependencies.
I just noticed that in this specific case the license says that it's not needed if distributed in binary form:
> [...] unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor [...]
But if rules_license is not planning on adding any functionality for extracting Copyright from src files we might try to automate that on the side and import that into our deliveries.

Yes. Extracting it is tricky because people are often sloppy about what they include and if they even need it.

For example, if an Apache-2.0 project includes a GPLed piece of autoconf, but you don't build with configure, do you need that license? If there was an optional part contributed by someone who wants notice on the copyright line, but you don't use the optional part, should you mention them?

I notice some SPDX identifiers in the draft PR 59, https://github.com/bazelbuild/rules_license/pull/59, is SPDX SBOM format on the near term roadmap?

Yes.  I'm just not focusing on it right now because text formats are easier to show to people and discuss. Big blobs of JSON are not conducive to that, even if that is what people need to produce.