Fellow tech-team participants: Stumbled upon notes from Buildroot's developer days meeting, including notes from their discussion about SPDX.
Excerpt from this page: http://elinux.org/Buildroot:DeveloperDaysELCE2013 legal-info / SPDX[edit<http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2013&action=edit§ion=14>] Arnout introduces SPDX, it's a format to store legal info. It has a header, information about the package (version, who created the SPDX file, a tag saying whether it was automatically created or not, etc.), then a file manifest with all the files in the package. For every file, this manifest specifies the license of that file and other relevant info about the file (copyright holder, a SHA of the file). The overall information also contains the global SHA of the package (the SPDX file excluded). The final section contains the concluded license of the overall package (and the declared license, as given by the upstream package author, which may or may not match the concluded license). There are some tools to manipulate SPDX files, in various formats (JSON, XML, etc.). Fossology is a tool that analyzes the license of files, by doing pattern matching on the files, trying to find common indications of licenses. It used to generate a manifest in a special text format, but the tool was more recently updated to generate a SPDX file. Yocto uses it now: after patching the package, sends it the fossology server, waits for the answer (which can take a long time), and stores it. Fossology allows you to upload a tarball, and then Fossology will analyze it and provide a license report in the form of a SPDX file. There is a public Fossology server, but it's open-source, anyone can install it, except that it's huge and very performance consuming. SPDX is a standard format to exchange informations about licenses, you can give them to lawyers, who can do license analysis. In Buildroot, two possible directions around SPDX: * Buildroot could at least provide its own SPDX file, to declare the license of the different files in Buildroot * Buildroot could query the Fossology server for licensing informations for each package, and store the SPDX results as part of the legal-info. To provide a SPDX file for Buildroot itself, it's difficult: we would have to know the license of each of our files. For the Config.in and .mk files, it's easy, but for the patches that we apply on packages, their license is the license of the package on which they apply. Since it's already a difficult problem to collect these licenses in a reliable way, generating reliable SPDX info for Buildroot seems hard. U-Boot is one project that is being converted to use SPDX properly, by storing SPDX tags in the source files. It doesn't include an SPDX file (yet), however. General feeling is that it seems really complicated to do, and SPDX isn't widely used yet, so the benefits aren't clear. One point raised is that Fossology is almost always not able to determine the license for *all* files, so for all packages, the license returned is always something like "Some GPL, some BSD, some other license, and Unknown license". One more thing is that SPDX has standardised license "acronyms", and of course, it doesn't match what we are using. Question is whether we should base our <pkg>_LICENSE metadata on these SPDX standardised license acronyms. Since there's no immediate need to be compatible with SPDX license names, we don't need to migrate to those names. And because the Buildroot current names and SPDX names is most likely a 1:1 mapping, we can always migrate later one with a bit of sed usage. However, for new packages that have a license that isn't yet in the list of license names used by Buildroot, using the SPDX license name may be a good idea.
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
