Using closure modules results in JS output appearing to be licensed as apache v2

[niloc132]

From https://developers.google.com/closure/compiler/docs/js-for-compiler#tag-license, it appears that any @license comments end up in the compiled output, and no flags can prevent that (and perhaps, nor should they). Given a project which uses goog.provides/module/etc, the google/closure-library@1fe1bd8 commit appears to add a license header advertising only apache v2 to the JS output, where previously a (potentially proprietary) project might have had no license shown, giving the impression that the entire file is now apache v2.

My hunch is that this is to make sure that the apache license terms are upheld, but at least as I understand apache v2 this isn't sufficient - the full text of the license still needs to be included elsewhere, so I'm not sure why this is now mandatory.

Sorry for such an open ended report, but I'm not sure what the takeaway should be for downstream projects - including licenses is mandatory? Fork closure-library to remove it? Introduce additional command line args to make this optional (--license-file-provided-outside-js=true)?

[shicks]

For what it's worth, these commits are bringing Closure Library into compliance with a Google-internal rule that the library had previously had a grandfathered exemption from. It is indeed intended to uphold the terms of the Apache license, while adding the minimal number of bytes to compiled output as possible. We were instructed that this text was sufficient (see https://spdx.org for more details, I guess - IANAL). The behavior of @license is based on how Google's build infrastructure handles licenses - it might be reasonable for there to be a flag to support some other workflow, though it might be difficult to prioritize.

In terms of mandatory, you can do what you want with the output of the compiler. If you are documenting your licenses elsewhere, then nothing is stopping you from adding a post-processing step to remove the extra license, and that would surely be preferable to forking the library.

[niloc132]

Well we already fork the compiler so that BUNDLE has sourcemaps and defines, so that the PersistentInputStore is restored, so one more patch isn't a big deal. I'll bring it up on google/j2cl, since no annotations from .java make it into .js, so we can't easily control how arbitrary java jars get their license respected in this way, see if they have a plan...

Agreed that I don't want to get into what a lawyer may or may not suggest (and certainly don't want to advise anyone downstream on what they should be doing), but only want to point out that my naive read of the license file says that this isn't sufficient, a copy of the license is required, not just its name.

You must give any other recipients of the Work or Derivative Works a copy of this License; and...

[concavelenz]

I think it would be reasonable to have an option to output the licenses to another file rather than included at the top of the output or turn it off completely. Ultimately, we don't attempt to provide any enforcement of licenses (not everything file with a license is tagged @license for example) that is up to the folks deploying the code.

Happy to entertain a patch.

[kohlschuetter]

The license comments are coordinated via SingleBinaryLicenseTracker, which is called from Compiler.toSource().

Right now, this is hardcoded. It would be helpful to expose a public toSource(LicenseTracker) method, so users of the Java API could provide their own implementations (no-op, or tracking externally, for example).