Fwd: Legal implications of using JMH

[Owen O'Malley]

Apache legal team,

Apache ORC had a benchmark module that linked against the GPL'ed library
JMH. JHM is a micro-benchmarking framework that is tightly integrated into
OpenJDK, but it is shipped separately through Maven Central. I removed the
benchmark module from ORC, because my understanding was that any Java code
that linked against a GPL'ed library had to be released under GPL. It looks
like Apache Druid, Calcite, Hive, Log4j2, and Camel also have been using
JMH for various benchmarking tasks.

Under what circumstances can we use JMH in an Apache project?

.. Owen

-- Forwarded message --
From: Julian Hyde 
Date: Mon, Apr 23, 2018 at 3:12 PM
Subject: Re: Legal implications of using JMH
To: dev@druid.apache.org, Owen O'Malley 
Cc: Slim Bouguerra , Gian Merlino <
g...@apache.org>


We use JMH in Calcite for microbenchmarking. My understanding was that our
use is OK. We are not linking it into the product; during tests, we link
against JMH, run the test, then delete the executable.

In addition to Calcite, it is used in Hive [1] Log4j2 [2], and Camel [3].

I think we should ask for a decision from Legal before changing anything.

Julian

[1] https://github.com/apache/hive/blob/master/itests/hive-jmh/pom.xml

[2] https://github.com/apache/logging-log4j2/tree/master/
log4j-perf/src/main/java/org/apache/logging/log4j/perf/jmh

[3] https://github.com/apache/camel/blob/master/tests/camel-jmh/pom.xml

On Apr 23, 2018, at 2:48 PM, Owen Omalley  wrote:

The relevant page from Apache is:

https://www.apache.org/licenses/GPL-compatibility.html and
https://www.apache.org/legal/resolved.html#category-x

GPL software can not be linked to from Apache projects at all. The problem
is that the GPL is viral and you’d have to license the rest of the code
under the GPL.

.. Owen

Begin forwarded message:

From: Gian Merlino 
>>
Subject: Re: Legal implications of using JMH
Date: April 23, 2018 at 2:14:31 PM PDT
To: dev@druid.apache.org>
Reply-To: dev@druid.apache.org>

I'm not sure why the ORC folks decided this was necessary. I found these
two links,

- https://issues.apache.org/jira/browse/ORC-298
- https://lists.apache.org/thread.html/c27267a6a3df9b76c5e036fc181c86
5150639f4cf15ffc5cca27b690@%3Cdev.orc.apache.org%3E

It looks like they ended up moving the code to a different, non-Apache
repository.

The relevant Apache policy, I think, is: http://www.apache.org/
legal/resolved.html#optional. From what I've seen it comes up most often
with MySQL drivers (which we also use). See also https://issues.apache.org/
jira/browse/LEGAL-200.

It seems to me like JMH and MySQL are in the same boat. Both are optional
dependencies -- there is no reason that a "normal" user needs to run
druid-benchmarks. If this understanding is correct, then we should just
make sure we aren't distributing JMH (or MySQL drivers) as part of binary
releases. But I would be interested in understanding the thought process of
the ORC folks in more detail.

On Mon, Apr 23, 2018 at 1:44 PM, Roman Leventov >>
wrote:

See this:
http://mail.openjdk.java.net/pipermail/jmh-dev/2018-April/002743.html JMH
might be not welcome in an Apache-licensed project.

Re: Legal implications of using JMH

[Julian Hyde]

We use JMH in Calcite for microbenchmarking. My understanding was that our use 
is OK. We are not linking it into the product; during tests, we link against 
JMH, run the test, then delete the executable.

In addition to Calcite, it is used in Hive [1] Log4j2 [2], and Camel [3].

I think we should ask for a decision from Legal before changing anything.

Julian

[1] https://github.com/apache/hive/blob/master/itests/hive-jmh/pom.xml 


[2] 
https://github.com/apache/logging-log4j2/tree/master/log4j-perf/src/main/java/org/apache/logging/log4j/perf/jmh
 


[3] https://github.com/apache/camel/blob/master/tests/camel-jmh/pom.xml 


> On Apr 23, 2018, at 2:48 PM, Owen Omalley  wrote:
> 
> The relevant page from Apache is:
> 
> https://www.apache.org/licenses/GPL-compatibility.html and 
> https://www.apache.org/legal/resolved.html#category-x
> 
> GPL software can not be linked to from Apache projects at all. The problem is 
> that the GPL is viral and you’d have to license the rest of the code under 
> the GPL.
> 
> .. Owen
> 
> Begin forwarded message:
> 
> From: Gian Merlino >
> Subject: Re: Legal implications of using JMH
> Date: April 23, 2018 at 2:14:31 PM PDT
> To: dev@druid.apache.org
> Reply-To: dev@druid.apache.org
> 
> I'm not sure why the ORC folks decided this was necessary. I found these
> two links,
> 
> - https://issues.apache.org/jira/browse/ORC-298
> - https://lists.apache.org/thread.html/c27267a6a3df9b76c5e036fc181c86
> 5150639f4cf15ffc5cca27b690@%3Cdev.orc.apache.org%3E
> 
> It looks like they ended up moving the code to a different, non-Apache
> repository.
> 
> The relevant Apache policy, I think, is: http://www.apache.org/
> legal/resolved.html#optional. From what I've seen it comes up most often
> with MySQL drivers (which we also use). See also https://issues.apache.org/
> jira/browse/LEGAL-200.
> 
> It seems to me like JMH and MySQL are in the same boat. Both are optional
> dependencies -- there is no reason that a "normal" user needs to run
> druid-benchmarks. If this understanding is correct, then we should just
> make sure we aren't distributing JMH (or MySQL drivers) as part of binary
> releases. But I would be interested in understanding the thought process of
> the ORC folks in more detail.
> 
> On Mon, Apr 23, 2018 at 1:44 PM, Roman Leventov 
> >
> wrote:
> 
> See this:
> http://mail.openjdk.java.net/pipermail/jmh-dev/2018-April/002743.html JMH
> might be not welcome in an Apache-licensed project.
> 
> 
> 

Re: Legal implications of using JMH

[Julian Hyde]

I agree with Gian. 

Calcite uses JMH. We don’t distribute the binaries it produces — because we 
only need them for running benchmarks. 

It’s not an identical situation to MySQL because while there are other 
implementations of JDBC — e.g. Postgres — there is only one implementation of 
JMH. But JMH is only used during testing, not production.

So, let’s not do anything rash, like starting to remove code. I think we will 
have clarity in a few days as various folks in Apache react to what Owen has 
done. We can revisit this as part of the first Druid release.

Julian


> On Apr 23, 2018, at 2:14 PM, Gian Merlino  wrote:
> 
> I'm not sure why the ORC folks decided this was necessary. I found these
> two links,
> 
> - https://issues.apache.org/jira/browse/ORC-298
> - https://lists.apache.org/thread.html/c27267a6a3df9b76c5e036fc181c86
> 5150639f4cf15ffc5cca27b690@%3Cdev.orc.apache.org%3E
> 
> It looks like they ended up moving the code to a different, non-Apache
> repository.
> 
> The relevant Apache policy, I think, is: http://www.apache.org/
> legal/resolved.html#optional. From what I've seen it comes up most often
> with MySQL drivers (which we also use). See also https://issues.apache.org/
> jira/browse/LEGAL-200.
> 
> It seems to me like JMH and MySQL are in the same boat. Both are optional
> dependencies -- there is no reason that a "normal" user needs to run
> druid-benchmarks. If this understanding is correct, then we should just
> make sure we aren't distributing JMH (or MySQL drivers) as part of binary
> releases. But I would be interested in understanding the thought process of
> the ORC folks in more detail.
> 
> On Mon, Apr 23, 2018 at 1:44 PM, Roman Leventov 
> wrote:
> 
>> See this:
>> http://mail.openjdk.java.net/pipermail/jmh-dev/2018-April/002743.html JMH
>> might be not welcome in an Apache-licensed project.
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org
For additional commands, e-mail: dev-h...@druid.apache.org

Re: [druid-dev] Apache migration logistics

[Gian Merlino]

Hi Parag,

You should be able to do it by checking out the repo at
https://svn.apache.org/repos/asf/incubator/public and then adding yourself
to the file trunk/content/projects/druid.xml.

On Wed, Apr 18, 2018 at 11:25 AM, Parag Jain 
wrote:

>  I got my apache id recently, its pjain1
> Not sure how to add it to the page - http://incubator.apache.org/
> projects/druid.html. If anyone knows, can you please add it.
> Thanks,Parag
>
> On Monday, March 12, 2018, 4:49:41 PM CDT, Gian Merlino 
> wrote:
>
>  Committers: please,
> 1) If you don't have an apache id already, fill out an ICLA:
> https://www.apache.org/ dev/new-committers-guide.html#
> guide-for-new-committers and then post here and hopefully someone can
> figure out how to get you an id?
> 2) When you have an id, post it here if it's not in
> http://incubator.apache.org/projects/druid.html so someone can figure out
> how to add you to that, and then also try to sign up to
> private-subscr...@druid.apache.org (+ dev-subscr...@druid.apache.org
> which you should be on already). If you can't, then also post here, and
> hopefully someone can figure _that_ out.
>
> Gian
> On Fri, Mar 9, 2018 at 11:28 AM, Xavier Léauté 
> wrote:
>
> This thread is already going to both lists, and it looks like responses
> automatically go to both. Would be good to check what happens if we
> subscribe dev@ to the google group. If responding from the apache list
> doesn't automatically add the google group as well, it will be hard to keep
> the group useful.
> Agree with Julian a cutoff is necessary anyway, since the google group
> inherently becomes less useful over time, as some information only ends up
> in the apache list.
> On Fri, Mar 9, 2018 at 11:14 AM Nishant Bangarwa 
> wrote:
>
> We can register dev@druid.apache.org and us...@druid.apache.org as a user
> in druid user groups so that going forward any mails that are sent to druid
> google groups are also received on the apache lists and is on the record.
> This would be to bridge the gap during the migration only.
> @Julian, I go ahead and try setting this up, If this seems reasonable ?
> On Sat, 10 Mar 2018 at 00:09 Julian Hyde  wrote:
>
> I don’t know. I don’t think it’s easy.
>
>
> On Mar 9, 2018, at 7:31 AM, Roman Leventov  com> wrote:
> Could archives of druid-dev and druid-users mailing lists be transferred
> to the new lists?
> On Thu, Mar 8, 2018 at 8:48 AM, Julian Hyde  wrote:
>
> I’m working on it. It turns that I don’t have sufficient karma to create a
> git repo, so I’ve put in a request on the incubator list.
>
>
> On Mar 6, 2018, at 10:12 AM, Xavier Léauté  wrote:
> Julian, it looks like you or one of the mentors has to request the source
> code repos. Could you request a gitbox enabled repo?
> Based on https://incubator.apache. org/guides/transitioning_asf. html,
> for the initial migration, we need to involve infra to import the initial
> git history and grant them admin rights to the github repo.
> Charles, it also sound like we won't be able to do any code migration util
> legal signs off on the software grant, could you drive that?
> On Mon, Mar 5, 2018 at 12:52 PM Julian Hyde 
> wrote:
>
> The dev, users and private mailing lists now exist. You can see the
> archives:
> * https://lists.apache.org/ list.html?dev@druid.apache.org*
> https://lists.apache.org/ list.html?users@druid.apache. org*
> https://lists.apache.org/ list.html?private@druid. apache.org
>
> To see the last of these, you need to log in.
> There will also be archives at https://mail-archives.
> apache.org/mod_mbox/druid-dev/  etc. (you might need to wait a few
> minutes for the archiver to catch up).
> If you are an initial committer or mentor, you are a member of the Druid
> PPMC and you must be on both dev and private lists now. Send a message
> to dev-subscribe@druid.apache. org and private-subscribe@ geode.apache.org
> .
> Everyone else is welcome to join dev and/or users.
> Julian
>
> On Mar 5, 2018, at 11:58 AM, Nishant Bangarwa 
> wrote:
> Apache Incubator Superset is another example which uses github issues -
> https://github.com/apache/ incubator-superset/issues
> For Superset it works as all the github issue interactions are captured in
> ASF owned mailing list via Gitbox Integration. See -
> https://lists.apache.org/list. html?d...@superset.apache.org
>
> For Druid, If everyone agrees we can also choose to capture interactions
> on github issues at an Apache Owned mailing list e.g
> iss...@druid.apache.org and continue to use github issues.
> @Jihoon, Thanks for the Airflow migration link, super helpful.
>
>
> On Tue, 6 Mar 2018 at 00:44 Jihoon Son  wrote:
>
> Gian,
> there was a discussion for using a third-party issue tracker (
> https://issues.apache.org/