ppkarwasz commented on PR #597: URL: https://github.com/apache/maven-apache-parent/pull/597#issuecomment-5557612818
I am also opposed to this PR, because this parent POM produces **only** a source archive, and I have no idea what kind of SBOM should be produced for it. The `cyclonedx-maven-plugin` produces `build` SBOMs for the binary artifacts of a build. It **does** have limitations, but it takes into account the **properties** and **active profiles** used in the build, and produces a result that is correct for that single build run. It is not meant to describe a source archive, for which: - multiple **profiles** can change the outcome of a build, - dependency versions can be **ranges**. This is rare, but it is allowed. For a `pre-build` / source SBOM I would expect to see different information: - Vendored source code, with the copyright holder and license of that code. - Bundled JavaScript: most source archives also contain the sources for the website. - Dependencies that are conditional on properties and profiles. - **Curated** license information: is a dependency `Apache-2.0 OR LGPL-2.1-only` or `Apache-2.0 AND LGPL-2.1-only`? In the latter case, can I produce a build that omits the LGPL-licensed part? I honestly find licensing tedious, so I have not thought these aspects through in detail. @jerpelea has integrated SBOM-generation in Apache NuttX, together with the ability for users to opt out at build time of the handful of source files that are **not** `Apache-2.0` licensed. The generated SBOM is a `build` SBOM, but since all source files are tagged with a `SPDX-Licence-Identifier`, this could be reused to generate a `pre-build` SBOM. This is something I would like to see for Java projects too, but it should be generated by the `apache-rat-plugin` rather than by the `cyclonedx-maven-plugin`. To summarize, a source archive SBOM should contain: - The files in the source tree that were **not** authored by the project: `mvnw`, JavaScript for the website, vendored code. I have an idea how this could be done. - Dependencies for all profiles, which at this point are necessarily **external**, so that users can see the license implications. This is a lot of work, and it is mostly useful for companies that rebuild our Java code (AWS, Google, Red Hat) and either use it internally or ship it to their clients. The majority of users will rely on the `build` SBOM of what we publish to Maven Central, and for now I think they should configure a `cyclonedx-maven-plugin` execution themselves, so they “own” each configuration option. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
