Re: JMH dependency vs licensing
We must not publish the jar. GPL is a category X license. On Wed, Apr 8, 2020 at 2:56 PM Stamatis Zampetakis wrote: > > I'm fine with the decision of not publishing the jar. > > I never used the jar itself but I noticed while working with another > project using jmh. > > Indeed having performance benchmarks is a very good idea. > > On Tue, Apr 7, 2020 at 5:56 PM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > >no longer publish the ubenchmark jar to nexus > > > > We could resume publishing benchmark jar, however, it embeds third-party > > code, so it requires to compose the license file. > > I have chosen to skip the publication as a trivial escape hatch. > > > > Have you used ubenchmark.jar previously? > > It would be great if we could have a CI for performance measurements, > > however, it is never enough time to build it :-/ > > > > Vladimir > >
Re: JMH dependency vs licensing
I'm fine with the decision of not publishing the jar. I never used the jar itself but I noticed while working with another project using jmh. Indeed having performance benchmarks is a very good idea. On Tue, Apr 7, 2020 at 5:56 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >no longer publish the ubenchmark jar to nexus > > We could resume publishing benchmark jar, however, it embeds third-party > code, so it requires to compose the license file. > I have chosen to skip the publication as a trivial escape hatch. > > Have you used ubenchmark.jar previously? > It would be great if we could have a CI for performance measurements, > however, it is never enough time to build it :-/ > > Vladimir >
Re: JMH dependency vs licensing
>no longer publish the ubenchmark jar to nexus We could resume publishing benchmark jar, however, it embeds third-party code, so it requires to compose the license file. I have chosen to skip the publication as a trivial escape hatch. Have you used ubenchmark.jar previously? It would be great if we could have a CI for performance measurements, however, it is never enough time to build it :-/ Vladimir
Re: JMH dependency vs licensing
Hello, As of release 1.22.0, we no longer publish the ubenchmark jar to nexus and (I guess as consequence) neither to maven central. Initially, I was a bit surprised but apparently it is related to this thread and LEGAL-399 [1] so it seems normal. I am bringing this up just to avoid that other people (like me) start wondering why in the near future. Best, Stamatis [1] https://issues.apache.org/jira/browse/LEGAL-399 On Sat, Aug 11, 2018 at 2:54 PM Michael Mior wrote: > Thanks for checking this out! > -- > Michael Mior > mm...@uwaterloo.ca > > > Le sam. 11 août 2018 à 04:44, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> > a écrit : > > > Here's legal jira: https://issues.apache.org/jira/browse/LEGAL-399 > > > > TL;DR: JMH is GPL + "Classpath" exception, and that exception allows to > > link JMH with independent modules to produce an executable regardless of > > the license terms of these independent modules. > > > > In other words, no harm is made even if we release `ubenchmark` to > Central > > (or whatever). > > > > JMH use would be valid even if Calcite actually required JMH to function. > > It does not mean I want to use ubenchmark code in something like > SqlToRel, > > but it is for clarification purposes. > > > > Vladimir > > >
Re: JMH dependency vs licensing
Thanks for checking this out! -- Michael Mior mm...@uwaterloo.ca Le sam. 11 août 2018 à 04:44, Vladimir Sitnikov a écrit : > Here's legal jira: https://issues.apache.org/jira/browse/LEGAL-399 > > TL;DR: JMH is GPL + "Classpath" exception, and that exception allows to > link JMH with independent modules to produce an executable regardless of > the license terms of these independent modules. > > In other words, no harm is made even if we release `ubenchmark` to Central > (or whatever). > > JMH use would be valid even if Calcite actually required JMH to function. > It does not mean I want to use ubenchmark code in something like SqlToRel, > but it is for clarification purposes. > > Vladimir >
Re: JMH dependency vs licensing
Here's legal jira: https://issues.apache.org/jira/browse/LEGAL-399 TL;DR: JMH is GPL + "Classpath" exception, and that exception allows to link JMH with independent modules to produce an executable regardless of the license terms of these independent modules. In other words, no harm is made even if we release `ubenchmark` to Central (or whatever). JMH use would be valid even if Calcite actually required JMH to function. It does not mean I want to use ubenchmark code in something like SqlToRel, but it is for clarification purposes. Vladimir
Re: JMH dependency vs licensing
Yep, concur on these points. My understanding on them all. On 8/10/18 12:33 PM, Julian Hyde wrote: That’s my understanding as well. I thought we’d settled this a while ago. (I can’t find a URL to prove it.) Julian On Aug 10, 2018, at 7:58 AM, Enrico Olivelli wrote: I think it is fine to use JMH, you are not "redistributing" it, it is here only to run local benchmarks. We have the same in Apache BookKeeper codebase just my 2 cents Enrico Il giorno ven 10 ago 2018 alle ore 16:56 Michael Mior ha scritto: Perhaps we should just open up a JIRA case on legal for an official ruling. It does seem like we should try to have ubenchmark excluded from releases. Unless I'm mistaken, I don't belive it's required. On Thu, Aug 9, 2018, 4:01 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: There are two questions there: 1) Is it possible to use third party code with "forbidden" licenses? As you say, the answer is "it is OK for optional modules". 2) What should be the license of `ubenchmark` module? It looks like `ubenchmark` code links to JMH in a way that we can't strip out JMH and replace it with another alternative. Apparently calcite-ubenchmark is published to Maven Central, so it does not look like "a temporary use for tests", but it finds its way to the Apache Calcite release. Vladimir
Re: JMH dependency vs licensing
That’s my understanding as well. I thought we’d settled this a while ago. (I can’t find a URL to prove it.) Julian > On Aug 10, 2018, at 7:58 AM, Enrico Olivelli wrote: > > I think it is fine to use JMH, you are not "redistributing" it, it is here > only to run local benchmarks. > > We have the same in Apache BookKeeper codebase > > just my 2 cents > > Enrico > > Il giorno ven 10 ago 2018 alle ore 16:56 Michael Mior ha > scritto: > >> Perhaps we should just open up a JIRA case on legal for an official ruling. >> It does seem like we should try to have ubenchmark excluded from releases. >> Unless I'm mistaken, I don't belive it's required. >> >> On Thu, Aug 9, 2018, 4:01 PM Vladimir Sitnikov < >> sitnikov.vladi...@gmail.com> >> wrote: >> >>> There are two questions there: >>> 1) Is it possible to use third party code with "forbidden" licenses? >>> As you say, the answer is "it is OK for optional modules". >>> >>> 2) What should be the license of `ubenchmark` module? >>> It looks like `ubenchmark` code links to JMH in a way that we can't strip >>> out JMH and replace it with another alternative. >>> >>> Apparently calcite-ubenchmark is published to Maven Central, so it does >> not >>> look like "a temporary use for tests", but it finds its way to the Apache >>> Calcite release. >>> >>> Vladimir >>> >>
Re: JMH dependency vs licensing
I think it is fine to use JMH, you are not "redistributing" it, it is here only to run local benchmarks. We have the same in Apache BookKeeper codebase just my 2 cents Enrico Il giorno ven 10 ago 2018 alle ore 16:56 Michael Mior ha scritto: > Perhaps we should just open up a JIRA case on legal for an official ruling. > It does seem like we should try to have ubenchmark excluded from releases. > Unless I'm mistaken, I don't belive it's required. > > On Thu, Aug 9, 2018, 4:01 PM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> > wrote: > > > There are two questions there: > > 1) Is it possible to use third party code with "forbidden" licenses? > > As you say, the answer is "it is OK for optional modules". > > > > 2) What should be the license of `ubenchmark` module? > > It looks like `ubenchmark` code links to JMH in a way that we can't strip > > out JMH and replace it with another alternative. > > > > Apparently calcite-ubenchmark is published to Maven Central, so it does > not > > look like "a temporary use for tests", but it finds its way to the Apache > > Calcite release. > > > > Vladimir > > >
Re: JMH dependency vs licensing
Perhaps we should just open up a JIRA case on legal for an official ruling. It does seem like we should try to have ubenchmark excluded from releases. Unless I'm mistaken, I don't belive it's required. On Thu, Aug 9, 2018, 4:01 PM Vladimir Sitnikov wrote: > There are two questions there: > 1) Is it possible to use third party code with "forbidden" licenses? > As you say, the answer is "it is OK for optional modules". > > 2) What should be the license of `ubenchmark` module? > It looks like `ubenchmark` code links to JMH in a way that we can't strip > out JMH and replace it with another alternative. > > Apparently calcite-ubenchmark is published to Maven Central, so it does not > look like "a temporary use for tests", but it finds its way to the Apache > Calcite release. > > Vladimir >
Re: JMH dependency vs licensing
My limited understanding is that this is ok since ubenchmark is optional
and not required for Calcite to function. See the JIRA below for a similar
question from Apache Arrow.
https://issues.apache.org/jira/browse/LEGAL-324
--
Michael Mior
mm...@apache.org
Le jeu. 9 août 2018 à 14:53, Vladimir Sitnikov
a écrit :
> Hi,
>
> Apache Calcite has `ubenchmark` Maven module for benchmarking purposes, and
> it depends on org.openjdk.jmh:jmh-core library for that.
> It turns out jmh-core is GPL licensed (e.g.
> https://mvnrepository.com/artifact/org.openjdk.jmh/jmh-core ).
>
> Here's my question: is there a licensing issue there?
> Should we remove `ubenchmark` module from Calcite's sources?
> If so, where is the place to put it?
>
> Here's a relevant part of Calcite's pom.xml:
>
>
> org.openjdk.jmh
> jmh-core
> ${jmh.version}
>
>
> Vladimir
>
