Thanks to start this thread, it's very important to comply with old the
license restrictions.
1) HDDS-3397 is already opened with a proposed solution to download
jmh jars on-demand, PR is already posted.
2.) from LEGAL-399:
"current policy GPL CPE is considered Category X. However this may
okay if is an Optional or Platform-provided use"
JMH is an optional dependency and used only for testing. It's not on
the classpath of any ozone services just on the classpath of some CLI
dev/admin tools (tools and insight projects, only required by ozone
genesis command).
From the license:
" As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent modules,
and to copy and distribute the resulting executable under terms of your
choice, provided that you also meet, for each linked independent module,
the terms and conditions of the license of that module."
As I wrote, it will be removed with HDDS-3397 (in case of positive
review), but if you can "explain like I five" how is GPL +
classpath-exception is violated in this case, it would help me to learn
sg. (And may help to review HDDS-3397). Current usage seems to be fine
based on the GPL + cl text. Is it conflicted with some point of the ASF
license? If yes, which one? (Just curious...)
Thanks,
Marton
On 4/15/20 1:40 PM, Wei-Chiu Chuang wrote:
Want to raise awareness of this issue. IMO this is a blocker.
mvn dependency:tree
...
[INFO] ----------------< org.apache.hadoop:hadoop-ozone-tools
----------------
[INFO] Building Apache Hadoop Ozone Tools 0.4.0.7.1.1.0-SNAPSHOT
[19/33]
[INFO] --------------------------------[ jar
]---------------------------------
[INFO]
...
[INFO] +- org.openjdk.jmh:jmh-core:jar:1.19:compile
[INFO] | +- net.sf.jopt-simple:jopt-simple:jar:4.6:compile
[INFO] | \- org.apache.commons:commons-math3:jar:3.1.1:compile
[INFO] +- org.openjdk.jmh:jmh-generator-annprocess:jar:1.19:compile
...
We can't use jmh because they are GPL 2 w/ Classpath Exception.
https://www.apache.org/legal/resolved.html
We also include jmh artifacts in test scope in other modules.
Looking at how other projects deal with this situation, there are a few
solutions to it:
1. Make a profile such that the jar is not included in the release /
optional https://issues.apache.org/jira/browse/RYA-373 (Apache Rya)
2. Replace the GPL w/ Classpath Exception with something Apache licensed.
https://issues.apache.org/jira/browse/LEGAL-396 (Apache Lucene)
3. It was also suggested to declare jmh in provided scope so we don't ship
it. (not sure if this is possible. Does JDK runtime provide jmh?)
https://issues.apache.org/jira/browse/LEGAL-399 Apache Calcite
What should we do? Is there any way we can ship JMH? Otherwise I fear we
would end up making an emergency release just to exclude it.
---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org
