Generate license information

[niloc132]

See also google/closure-compiler#3551

Given closure-compiler will always emit a "Copyright The Closure Library Authors.", "SPDX-License-Identifier: Apache-2.0" on any closure output which includes base.js (required to use j2cl output), I propose that j2cl should either take license information as an input, or read it from standard sources (such as SPDX-License-Identifier headers in .java or NOTICE.txt or LICENSE.txt files in src jar META-INF/ dirs.

Without a feature like this, a j2cl_application with no handwritten JS included will generate output which claims only to be apache licensed, and owned by "The Closure Library Authors".

Making it part of the bazel rules could be reasonable as well, generating a standalone JS file who's only purpose is to list the license that covers at least some other files in the project. To make the solution bazel-only and complete, this may need to also traverse other upstream dependencies and collect the license defined in the .java files or in java_library licenses? If passed to J2clTranspiler as a flag or if read from raw .java inputs, it could write to the generated .java.js files, if handled directly by j2cl_library() it could emit a single .js file and synthesize goog.provides/requires as needed to ensure it is included in output, or could prepend the license comment to some/all of the .java.js output.

Based on what the j2cl team thinks is appropriate here, we can plan on what external build tools should do to propagate these licenses correctly - maven has some license conventions for example, which could either be passed to J2clTranspiler or emitted in individual .js files etc.

Not a lawyer territory: given the discussion in the linked issue, it seems plausible that jre.js should include a @license header, and possibly google/jsinterop-base's jsinterop.js should as well.

[gkdn]

Providing it via .js files is a straightforward solution. JRE could be covered by adding a @license in jre.js

[niloc132]

I'm not sure that is so straightforward, but I may be missing something: If a given .js file were created, it would need to ensure that it was depended on any/all generated .java.js files (similar to the issues we work around with System.getProperty), otherwise with --dependency_mode=PRUNE (or just plain --compilation_level=ADVANCED iirc) they wouldn't be necessarily reachable from the entrypoints or exported symbols. It is my understanding that this is why base.js has the only license change in google/closure-library@1fe1bd8, since that is sufficient to ensure that any usage of anything in closure-library ends up with the correct license.

(On the other hand, a general solution here could also solve #1, #76, enforcing somehow that all .java.js files depend on a given .js file, etc.)

Is this something you can provide a sample of how you intend this to work in j2cl_library, j2cl_application? Agree that jre.js is a simple way to solve this, since any use of nativebootstrap.Util$impl (which java.lang.Object itself even must depend on) will always include jre.js, but it doesn't seem to be so simple outside the JRE.

[gkdn]

Ok, this may not a generalized solution due dependency pruning mode. Did you try it?

BTW, closure license is not coming from base.js; all independent closure lib files are including it now.

[niloc132]

I added a new js file next to the helloworld app.js, called unused.js with these contents:

/**
 * @license test
 */

var test = true;

The output was unaffected. Next, I added goog.provide('unused'); after the license jsdoc and likewise, no impact.

Finally, I added an explicit goog.require('unused'); to app.js, and the result now has these contents:

/*

 Copyright The Closure Library Authors.
 SPDX-License-Identifier: Apache-2.0
*/
'use strict';/*
 test
*/
document.write("Hello from Java! and JS!");

These three tests were completed using the maven plugin, which passes command line args --compilation_level=ADVANCED and --dependency_mode=PRUNE, but just to be sure I didn't do something dumb, I also did the first one by directly editing and rebuilding the samples/helloworld app. Oddly, that resulted in the "expected" behavior, kinda:

/*
 test
*/
document.write("Hello from Java! and JS!");

I think, but am not certain, that the closure-library version used by rules_closure is out of date, hasn't yet picked up the license change. As to why "test" was included, samples/helloworld/bazel-bin/src/main/java/com/google/j2cl/samples/helloworld/helloworld.js-0.params provided the details there:

--dependency_mode
LOOSE

(Aside, it appears that helloworld_dev.js-0.params also uses LOOSE, which contradicts what we were initially advised to use when building "dev mode", since that will keep unreferenced JS around, rather than shaking it loose. Also, "LOOSE" as a value for that flag was dropped from closure-compiler in late 2018? google/closure-compiler@bab8ee8 Perhaps the bazel closure rule provide some way to still use it, I didn't check, or perhaps both closure-library and closure-compiler are out of date in rules_closure.)

If bazel+j2cl assumes that only "SORT_ONLY" (appears to roughly be the modern version of LOOSE) will be used for any j2cl_application or closure_binary which uses a j2cl lib, then this is probably sufficient - then again, I should re-do the System.getProperty tests if that's the case.

[gkdn]

since that will keep unreferenced JS around, rather than shaking it loose

That's not true. It will still tree shake. Only difference is; it will keep files that do not goog.provide any symbols.

"LOOSE" as a value for that flag was dropped from closure-compiler
"SORT_ONLY" (appears to roughly be the modern version of LOOSE)

LOOSE is replaced with PRUNE_LEGACY.

[niloc132]

Thank you for the correction - I haven't been using it, since it is referred to as legacy (and other legacy things like legacy namespaces have disappeared on us before).

I can vouch that SORT_ONLY indeed does not shake anything loose, we've toyed with it to try to individually bundle each j2cl library without risk of dropping a type that some downstream lib will need.

[JasonGardner-code]

I am working on fixing this issue with some sites I have been working on. In the end I keep getting a closure compiler that keeps giving me: "Copyright The Closure Library Authors.", "SPDX-License-Identifier: Apache-2.0" when I want it to state a different SPDX- License-Identifier. My team said that this is infeasible, but I want to make it work. Did you find a good workable solution that works 100% of the time?

[niloc132]

Can you clarify a bit what you have for your code/setup? Barring changes to closure-compiler or closure-library, you will continue to see the Apache-2.0 license (since closure-library is licensed under apache2), but you can also add your own license (in a JS file of some kind) and it should show up (see https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#license-preserve-description).

[JasonGardner-code]

Thank you. We are doing a very large scale search and email website. It seems that my team is going to track this as intended behavior. There doesn't seem to be any real issue with our closure compilers continuing to show the Apache-2.0 license.

[kohlschuetter]

I also just ran into this.

The problem with the current implementation is that the "Copyright The Closure Library Authors" always comes first due to dependency ordering in closure-compiler. It would be very helpful if there was a simple way to always prepend the Javascript output file with a customizable comment.

That way, you can have a human-readable message (and possibly a SPDX-License-Identifier) that clearly indicates that not everything in the file is licensed as Apache-2.0.

Even better, there should be a way to forcibly suppress all comments in the output, even if @license statements were declared in some dependencies. The output clearly isn't source code anymore, so it doesn't have to carry the license statements.

[niloc132]

It looked like closure-compiler would welcome a patch to change this behavior - we maintain a fork of closure-compiler with some other patches that they won't accept (sourcemaps working in BUNDLE, etc), but haven't had the need to push this particular issue.

Did you happen to test if @preserve works differently, so that it might let you prepend? Note that between the two of these, you can probably include a .js or .native.js that specifies a short descriptive bit of text, justifying the earlier comment, and any future comments?

[kohlschuetter]

@preserve behaves the same way.

Mixing these with /*!-style comments is even more confusing, as they get added to the same comment as @license/@preserve but below that text.

[gkdn]

Have you tried output_wrapper in https://github.com/bazelbuild/rules_closure#closure_js_binary? You should be able to manually add anything you want using that.