[Enhancement] SBoM/OpenChain compliance

[jeremybennett]

Thanks to all who are working on cleaning up and improving this project. I have found this repository useful when I need to quickly build a standard RISC-V tool chain.

However the source files are generally lacking headers giving provenance, which makes the repository hard to use in any OpenChain (ISO/IEC 5230) environment. Increasingly we are finding the need to provide a detailed SBoM is a requirement placed on us.

There is a top level BSD 3-Clause license, but I can't find a declaration of ownership (and hence the right to grant a license) in the source files, or even an AUTHORS file at the top level.

Ideally each source file of any significance should have a header something like:

Copyright (C) <year> <name>
SPDX-License-Identifier: BSD-3-Clause

(not needed in generated files like configure)

In a perfect world, a manifest generated by a tool like Fossology could be included. However anyone worrying about ISO/IEC 5230 should probably be generating that themselves anyway.

Hope this is a useful suggestion for a future enhancement.

[cmuellner]

I'd like to collect some information here, to give an overview of the current situation:

• the top-level LICENCE file includes a BSD 3-Clause license for "the directory newlib and the files configure.ac, Makefile.in, and patches/newlib"
• the top-level LICENSE file includes a GPL-2 license for "the directories binutils, gcc, and linux-headers, and the files patches/binutils and patches/gcc"
• the top-level LICENSE file includes a LGPL-2.1 license for "the directory glibc and the file patches/glibc"

The LICENSE file is clearly out of date.

The current repo has the following contents:

• linked external repositories (listed in .gitmodules)
• Dhrystone source in test/benchmarks
• linux headers
• README.md
• LICENSE
• Makefile.in
• configure.ac (and the generated configure)
• .gitignore
• CI/CD scripts in .github/
• helper scripts in scripts/
• test helpers in regression
• allowlist for failing tests in test/allowlist

The first three items are external sources and have their own license.

The next five items could be considered covered by the BSD 3-Clause license.

The last four items have been contributed and improved by a range of different people over a long period of time. I'm not sure if these files can be claimed to be covered by the BSD 3-Clause license. By interpreting the intent of the LICENSE file, this is clearly the case (for me). However, given these files are not explicitly named, somebody might claim otherwise.

Unless we find a solution for these last four items, I don't see how to solve this issue.

[TommyMurphyTM1234]

However the source files are generally lacking headers giving provenance, which makes the repository hard to use in any OpenChain (ISO/IEC 5230) environment. Increasingly we are finding the need to provide a detailed SBoM is a requirement placed on us.

Are you referring to the files specific to this repo or also those pulled in from upstream? As far as I can see the same issue applies to many files in upstream submodules. As such, the same issue could/should be logged against all relevant upstream projects (e.g. GCC, binutils, newlib etc.).

I note that the OpenOCD project recently adopted a policy of having such copyright/SPDX headers in all files so I guess that something similar would need to be done here and in all relevant upstream submodule projects.

• https://github.com/openocd-org/openocd/blob/master/LICENSES/license-rules.txt

[TommyMurphyTM1234]

• CI/CD scripts in .github/
• helper scripts in scripts/
• test helpers in regression
• allowlist for failing tests in test/allowlist

The first three items are external sources and have their own license.

The next five items could be considered covered by the BSD 3-Clause license.

The last four items have been contributed and improved by a range of different people over a long period of time. I'm not sure if these files can be claimed to be covered by the BSD 3-Clause license. By interpreting the intent of the LICENSE file, this is clearly the case (for me). However, given these files are not explicitly named, somebody might claim otherwise.

Unless we find a solution for these last four items, I don't see how to solve this issue.

Perhaps the original submitters (and all subsequent contributors?) need to be contacted to clarify this?
I can't really think of any other way to make progress with this enhancement request.

[TommyMurphyTM1234]

No activity on or interest in this for a year so I am closing it due to inactivity.
If it becomes a real practical issue for somebody then please post back to request it be reopened.