License and origin details may be missing for Jarjar'red JARs and other bundled 3rd-party?
pombredanne opened this issue · comments
The distributed JARs contain jarjar'red code in /com/google/javascript/jscomp/jarjar/ and I cannot find the corresponding copyright/notices/licenses for these.
The same applies to com/google/javascript/rhino
This seems to be caused by a combo of things:
- the https://github.com/google/closure-compiler/blob/master/rules.jarjar rules and jarjar seem to be ignoring any form of license, attribution or third-party origin documentation
- the definitions in the https://github.com/google/closure-compiler/blob/master/WORKSPACE.bazel do not seem to get correct details in the built JARs
As result, there is a double whammy:
- some license information is missing from the deployed JAR resulting in possible license compliance issues.
- third-party origin information is mostly missing from the deployed JAR resulting in difficulties to track which packages are included and which if any is subject to known vulnerabilities, resulting in security risks
Thanks for the report!
Do you know if the unshaded version (https://mvnrepository.com/artifact/com.google.javascript/closure-compiler-unshaded) fairs better, or if it also suffers from the same issues?
While the unshaded jar shouldn't have those problems for its dependencies (since by definition, it isn't shaded, so each dependency has to be fetched separately, and should have been packaged properly), the closure-compiler-unshaded jar doesn't contain a LICENSE/NOTICE/COPYING file, nor does its pom have a <license>
block (see https://search.maven.org/artifact/com.google.javascript/closure-compiler-unshaded/v20230502/jar). It does at least have a license for the pom.xml file itself, but putting it in a comment seems to imply that the license covers the pom file, rather than being declared for the associated jar (in a <license>
block within the <project>
itself).
I've proposed #4105 as a draft to at least rectify the missing <license>
tag, but adding a file to the jar would probably also be good to cover all bases, though I'll need a little time to remember how to dance with bazel to make that happen.
If someone can point me in the right direction for jarjar, I can see about fixing that side as well?
A quick read over at https://github.com/bazeltools/bazel_jar_jar/ (esp bazeltools/bazel_jar_jar#15) suggests that this might not be presently possible at all, though the fact that the bazel_jar_jar tool has migrated to the bazeltools/ org instead of johnynek's own personal repo (see below) suggests that this is being maintained:
closure-compiler/WORKSPACE.bazel
Lines 157 to 168 in ac8c8de
(Note also that despite the comment above, it appears that bazeltools/bazel_jar_jar does not use google/jar_jar, but its own vendored copy, which was, according to the readme, copied from pantsbuild/jarjar, so some cleanup may be due here.)
The same applies to com/google/javascript/rhino
I was wondering about this, given that the closure-compiler repo reports to be licensed as Apache v2 (which is what I put in my draft PR), so went looking for any attribution in this repository. The file https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/rhino/package.html has a dead link, but https://github.com/mozilla/rhino reports that "the majority of Rhino is licensed under the MPL 2.0". This seems to agree with the headers in the various .java
files that I quickly checked. There is no BUILD file in the rhino package here, which could declare the license for that code as being different from the rest of the project - is this appropriate, and the top-level BUILD.bazel file only lists "notice" (which I understand might be the deprecated way of listing a license, and not accurate for mpl)? Given that mpl-2.0 is a copyleft license (but explicitly at the "file-level" if I am reading this correctly), this should probably be fixed to avoid any confusion about the codebase.
While it appears that the entire MPL 2.0 appears in each header (not required - only the three line header is suggested, with a LICENSE file in the same directory), as @pombredanne pointed out initially, both shaded and unshaded jars may be in violation of the license by distributing binary code without a reference to where the source (and license) can be obtained. (I'm hedging there a bit with "may be", since of course a -sources jar is distributed as well, but if we're assuming that following maven conventions is enough, then likely the poms must be accurate as well.)
Do you know if the unshaded version (https://mvnrepository.com/artifact/com.google.javascript/closure-compiler-unshaded) fairs better, or if it also suffers from the same issues?
Here is the results of a scan of the unshaded JAR
- https://repo1.maven.org/maven2/com/google/javascript/closure-compiler-unshaded/v20230802/closure-compiler-unshaded-v20230802-sources.jar contains MPL or GPL-licensed code and one file an X11 license too. This non-Apache-licensed code lives in https://github.com/google/closure-compiler/tree/master/src/com/google/javascript/rhino
- The POM does not contain any such license reference only Apache
- The POM is not in the source or binary JAR anyway
- The binary JAR has no license notice at all for https://github.com/google/closure-compiler/tree/master/src/com/google/javascript/rhino anyway
Note the that the old Rhino code vendored here is under a choice of MPL-1.1 or GPL-2.0-or-later, not MPL-2.0 ... though technically MPL-1.1 allows relicensing under newer license versions.
And the shaded Jars are still problematic with missing documentation for shaded origins and licenses.
FWIW, even the COPYING at the root https://github.com/google/closure-compiler/blob/master/COPYING feels incomplete and missing the MPL parts
I have been working on this.
One issue is, most of our dependencies are missing their license files in their jar files, so I have been looking into ways to get their licenses into our jarjar file.
6dcbaad should fix this.
Sorry it took so long to fix this problem. I had to get creative, and the result was pretty ugly, as I needed a way to keep the license up to date for our dependencies.