The below is based on the implementation of the automatic checker for Apache JMeter (Java, Gradle if that matters).
Tony>The expectation is that when importing a third party package, a human examines the license terms and picks the applicable one for their code base in the case of a choice Can you please clarify if you expect that every dependency declaration in Bazel should duplicate the license terms for the dependency? It looks like your design requires to specify each and every license terms individually, even though the package itself could its terms. I guess it would be great if the terms could be fetched from the dependency artifact itself (or from its metadata). For instance, Java's jar files have a standard location for the license expression: Bundle-License header in META-INF/MANIFEST.MF. Tony>We could turn to the use of LicenseA OR LicenseB. What are your expectations for how that applies to a final application that must comply with notice or other requirements? In lots of cases, the license terms require to keep the copyright notice on re-distribution. It would be nice if Bazel could capture that somehow and produce a summary license file for the final package. That is it would be great if it could produce a file with license files (and copyright notices) for all the embedded dependencies. Tony>What I am looking for is how we can mechanically answer if a particular application is compliant with the terms of all its dependencies. Heres's the Apache Software Foundation case. Apache releases come in the source form, and they can be accompanied with pre-built binaries. There's a list of resolved cases (see https://www.apache.org/legal/resolved.html ) that clarifies which licenses can be bundled into source (or binary) releases. For instance, the list says that Apache software must not include items licensed under "JSON License". In practice, it does not really mean Apache-2.0 license is not compatible with "JSON License". It means the ASF decision was to forbid the use of the specific license. >What are your expectations for how that applies to a final application that must comply with notice or other requirements? Checker (e.g. a checker for ASF) should be able to classify every given license expression into category A (allowed), category B (allowed only for binary release), category X (not allowed), unknown. In other words, there should be a way to write a checker that helps with automatic verification of the rules like resolved.html above. If it sees "MIT or Apache-2.0" the checker could deduce that both MIT and Apache-2.0 fall into "category A" (==allowed), so the license looks acceptable. On the other hand, if the expression is "GPL-2.0 OR QPL", then it could deduce the license terms falls under "category C". Of course, different teams might have different understanding for "license categories", however, it is important to capture license expressions. Here's an example of a dependency which is used in Apache JMeter: javax.mail:mail:1.5.0-b01 is licensed under "CDDL-1.0 AND GPL-2.0-or-later WITH Classpath-exception-2.0" --- Note: unfortunately, SPDX license expressions are not well-defined. For instance, there are license terms that allow the use of "this or later version of the license". GPL-2.0+ license expression is likely to mean "GPL-2.0 or GPL-3.0 or ...", because "+" means "or later", however, SPDX provides no relationship between GPL-2.0 and GPL-3.0. There's no metadata that tells that GPL-3.0 is a later version of GPL-2.0. On the other hand, there's GPL-2.0-or-later "license" which is effectively the same as GPL-2.0+ At the same time, "CC_BY_NC_1_0" means "CC_BY_NC_1_0 or CC_BY_NC_2_0 or CC_BY_NC_2_5 or .." because the license text for CC_BY_NC_1_0 contains explicit permission to use the package under later versions of the same CCBYNC license. SPDX contains **no** metadata on license equivalence (==SPDX says nothing on what "+" license modifier does), so the checkers would have to implement that on their own (which might result in different implementations by different checkers :( ). Vladimir -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3866): https://lists.spdx.org/g/Spdx-tech/message/3866 Mute This Topic: https://lists.spdx.org/mt/73090505/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
