You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Wei-Chiu Chuang <we...@apache.org> on 2020/04/15 11:40:41 UTC
[DISCUSS] Remove JMH which is not Apache License compatible
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.
Re: [DISCUSS] Remove JMH which is not Apache License compatible
Posted by Steve Loughran <st...@cloudera.com.INVALID>.
we could use it in tests, as long as it was not exported as a downstream
dependency. Including it in tarballs is probably a blocker on ozone releases
On Wed, 15 Apr 2020 at 12:41, Wei-Chiu Chuang <we...@apache.org> 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.
>
Re: [DISCUSS] Remove JMH which is not Apache License compatible
Posted by Wei-Chiu Chuang <we...@cloudera.com.INVALID>.
This comment from Henri Yandell (current Apache VP of Legal Affaris) is
quite clear to me (Nov 2019 so I think the argument is still valid):
<goog_571575865>
https://issues.apache.org/jira/browse/LEGAL-336?focusedCommentId=16968946&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16968946
1) Can we treat GPL CPE as Category B?
No. It isn't Category B in the current sense that you can include a GPL CPE
library with your code.
2) Can we build software for a platform that is GPL CPE?
Sure. You can build software for a platform that is Oracle Proprietary too
(assuming you have access to develop with the Oracle Proprietary platform;
which in the case of Java doesn't seem clear).
3) Can we use GPL CPE in Apache Foo to do XYZ?
Open a specific Jira issue.
4) What about the Eclipse link from Matthias?
Looks like good text. Pretty much equates to open a JIRA; obey the GPL CPE
licensing; don't fork the GPL CPE code.
I.e.: by default we can't bundle jmh into a convenience binary. To
investigate Ozone's inclusion of jmh, we should open a LEGAL jira.
On Thu, Apr 16, 2020 at 12:49 AM Elek, Marton <el...@apache.org> wrote:
>
>
> 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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: ozone-dev-help@hadoop.apache.org
>
>
Re: [DISCUSS] Remove JMH which is not Apache License compatible
Posted by "Elek, Marton" <el...@apache.org>.
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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-dev-help@hadoop.apache.org
Re: [DISCUSS] Remove JMH which is not Apache License compatible
Posted by Steve Loughran <st...@cloudera.com.INVALID>.
we could use it in tests, as long as it was not exported as a downstream
dependency. Including it in tarballs is probably a blocker on ozone releases
On Wed, 15 Apr 2020 at 12:41, Wei-Chiu Chuang <we...@apache.org> 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.
>