google / closure-compiler

A JavaScript checker and optimizer.

Home Page:https://developers.google.com/closure/compiler/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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:

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:

# Jarjar is a Google tool (https://github.com/google/jarjar) for generating
# shaded JARs (https://stackoverflow.com/questions/49810578). This repo contains
# Bazel bindings for Jarjar, under the Apache license.
http_archive(
name = "com_github_johnynek_bazel_jar_jar",
# output from `sha256sum` on the downloaded zip file
sha256 = "fdf2c5276e5c6f27efa1e0b64a301f5a122d84a4c1c0dd80006dbbc530a16773",
strip_prefix = "bazel_jar_jar-171f268569384c57c19474b04aebe574d85fde0d",
urls = [
"https://github.com/johnynek/bazel_jar_jar/archive/171f268569384c57c19474b04aebe574d85fde0d.zip",
],
)

(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.)