4517 2013-05-20 18:25:30 +0000 SPDX license calculation tool 2025-01-09 16:30:32 +0000 1 1 7 Build System, Metadata & Runtime OE-Core configuration unspecified x86 Multiple NEW Medium enhancement Future 4516 1 elizabeth.flanagan unassigned alberto bluelightning elizabeth.flanagan JPEWhacker randy.macleod richard.purdie sgw wmills --- --- Yes (doc changes required) oldest_to_newest 33161 0 elizabeth.flanagan 2013-05-20 18:25:30 +0000 As someone concerned with the accuracy of LICENSE data, I would like an optional inherit that trys to determine the license of downloaded src. This should WARN when a recipe's stated license is not the determined license. This should ERROR when a license file is found that is not within the LICENSE_SRC_URI. 33165 1 elizabeth.flanagan 2013-05-20 18:38:12 +0000 *** Bug 2275 has been marked as a duplicate of this bug. *** 94585 2 randy.macleod 2022-12-22 16:07:52 +0000 We think that Alberto may have some code to help in this area. https://summit.yoctoproject.org/yocto-project-summit-2022-11/talk/CPWETR/ 94598 3 alberto 2022-12-23 08:03:42 +0000 (In reply to comment #2) > We think that Alberto may have some code to help in this area. > https://summit.yoctoproject.org/yocto-project-summit-2022-11/talk/CPWETR/ I might, actually :) It depends on the kind of approach we want to use here: - local/offline check: - it would require the installation some (possibly heavy) external tool(s): does that fit into Yocto's "philosophy"? - it may prove difficult to determine the *main* license of a *component* (single source files may have many different licenses) unless such information is already there in some format (eg. in a package.json file or in a single, unambiguous LICENSE or COPYING file) - but implementing a license check would make more sense precisely when this is *not* the case[^1] - online check: - there is a number of possible available resources (eg. Software Heritage, Clearly Defined, ScanOSS, Debian project...): each one has a different scope, philosophy, etc. - the check depends on the availability of such (free) remote resource(s), which may have filters to prevent too many connections In Oniro compliance project we use a mixed approach: offline + online check + (last but not least) an experienced audit team validating the results. One of the goals of the project is sharing validated results, but for now we just share them as downloadable SPDX artifacts for each release of Oniro, we still have to implement some web service where one can search stuff through public API. An idea could be to develop a local "License Oracle" with some simple API, that can be configured to use one or more modules/resources to determine component's main license(s), so that the optional inherit can just ask the oracle, without the need of adding too much logic into Yocto. Many modules we developed for the Oniro compliance toolchain may (and actually, have been originally designed to) be reused in a future "License Oracle" project (in Oniro, the "oracle" idea was originally proposed by Zygmunt Krynicki and Andrei Gherzan). Might it be the right time to start it? [^1]: moreover, there are cases when provided information is simply wrong - eg. https://github.com/michaeloryl/saml-encoder-decoder-js/issues/2 100589 4 randy.macleod 2025-01-09 16:30:32 +0000 Still mostly a good, nice to have, feature. The SPDX data could be used. Joshua Watt might check if we get an error from the SPDX code if there's a license identified there that is not in the recipe license list.