Project license, declared dependencies

[Thomas Jaeckle]

Hi there, I just stumbled upon this project and it's functionality is looking really great. Exactly what I was looking for in order to safely execute JavaScript from the JVM.

I don't want to be a smart-arse, I just want to point out some potentially legal and dependency issues of the project, hope you are not offended.

• the LICENSE.TXT must contain the license texts, otherwise I fear it is not valid - for a dual license both license texts should be there, e.g. https://choosealicense.com is a good resource for templates and choosing a license (note that both MIT and ASL2.0 license have same placeholders to fill in with year + name of copyright holder)
• your pom.xml even defines 3 licenses (MIT, ASL2.0 and GPL) - I'm not an expert but I am not sure if GPL is compatible to both ASL2.0 and MIT .. is GPL intended? every user of this library would also have to make his source-code GPL (which would lead to that a none GPL project cannot legally use it)
• the sources include the "beautify.js" and "beautify.min.js" which is a problem as you redistribute this library. https://github.com/beautify-web/js-beautify has MIT license, so you must include its copyright notice if you re-distribute it (otherwise you violate the MIT license)
  • an easy solution would be to simply add the webjar dependency in Maven:

  <dependency>
   <groupId>org.webjars.bower</groupId>
   <artifactId>js-beautify</artifactId>
   <version>1.6.12</version>
  </dependency>

  • webjar scripts can be loaded in Java by e.g.: InputStream is = getClass().getResourceAsStream("/META-INF/resources/webjars/js-beautify/1.6.12/js/lib/beautify.js");
• the project has a dependency for log4j (which is a concrete log-impl) - it should use SLF4J-API instead and not provide a log4j.properties in its sources, otherwise I as user of this library will be forced to use log4j and the provided logger config
• I see you are using OSGi - is there a reason to have a package import of "org.junit"? that would lead to that I would have to provide junit in my OSGi container during runtime ..

Sorry that I don't provide a PR fixing all this, but the license should be chosen by you guys.
I would really love to use this library and am happy to give advise if you want to.

[Max Rohde]

Hi Thomas,

Thank you for opening this issue and for your input. Please see a revised license.txt file in the commit linked to this issue.

It is clarified there that users of the license may use ANY of the licenses; so if one would choose to use it under MIT, the GPL license won't apply . I am not sure about the convention in Maven module definitions. Is it assumed here by auditing tools that ANY licenses may be used or that ALL licenses apply?

I tried out the code you provided for linking in beautify.js but it didn't work. Feel free to create a pull request with using the webjar version as dependency. Otherwise, the license for beautify js is included in the source file - but using the Maven dependency is preferable in my view!

I would happy for log4j & log4j properties to be removed. But I think it would be better to replace it with log4j2 instead of slf4j?

[Thomas Jaeckle]

Hi Max.
Thanks for clarifying regarding the license. Do you see a benefit in choosing 2 very "open" licenses and additionally GPL? Just saying that 3 declared licenses are quite uncommon ;)
I think in the pom it should be ok to list them all in order to specify that one of them applies.

I created a PR with the webjar + logging changes.
The benefit of slf4j-api is that you can choose to use log4j as logger (I added that as "test" dependency) or log4j2 (or others like e.g. logback).
So uses of the library can use their logger implementation they already use.

Regards

[Max Rohde]

Hi Thomas,

thank you for the pull request, that looks all good!

As to including GPL in there; I included it so that it the library has full compatibility with any project which uses a GPL license. In my understanding, the different open source licenses are not 100% compatible with each other. Maybe it would be an idea to replace GPL with LGPL? That should still provide full compatibility and won't scare anyone concerned about the ANY or ALL license requirement? What do you think?

[Thomas Jaeckle]

Ah, I see. Good point.
I think LGPL would be "more friendly" and does not "scare anyone" away as you mentioned ;)

[Max Rohde]

Done! Let me know if there is anything else you can think of! Thank you!

[Steve Devore]

One note about the license..At the beginning of LICENSE.TXT, you state the library is available under:

Apache 2.0: http://www.apache.org/licenses/LICENSE-2.0
The MIT License (MIT): http://opensource.org/licenses/MIT
GPL v3: https://www.gnu.org/licenses/gpl-3.0.en.html

but then you list the LGPL.
Would it be possible to fix it to make it clear that it LGPL is one of the choices?

[Max Rohde]

@steve1066d Thank you for picking that up! License file has been updated accordingly!