PS Use of jmh was addressed explicitly: https://issues.apache.org/jira/browse/LEGAL-399
On Fri, Dec 29, 2023 at 4:50 PM Julian Hyde <jh...@apache.org> wrote: > > According to https://issues.apache.org/jira/browse/LEGAL-450, it's OK > to use a GPL linter. And a project can use GPL "build tools provided > they leave no code traces (licensed under a cat X license) in your > final release artifacts". > > In Calcite we use jmh on the understanding that it does not produce > any artifacts and therefore was acceptable. > > Can someone explain how a benchmarking utility is different from a linter? > > Julian > > On Wed, Dec 27, 2023 at 9:19 AM tison <wander4...@gmail.com> wrote: > > > > > For instance, if your maven build is `-Pbenchmark` and it's clear > > > that the user needs to include this license when compiling from source. > > > > Yeah. I'm going to collaborate with Fury to follow this approach and > > document clearly how a developer can intentionally run benchmark with > > JMH as a dep. > > > > Best, > > tison. > > > > John D. Ament <johndam...@apache.org> 于2023年12月28日周四 01:07写道： > > > > > > On Wed, Dec 27, 2023 at 11:38 AM tison <wander4...@gmail.com> wrote: > > > > > > > > application, a developer has preinstalled the JDK (or using a manager > > > > > of > > > > > some kind to install it - so not something we're forcing upon them). > > > > > In > > > > > > > > No. To running a Java Application in a normal way, the JRE is > > > > required. Saying "not something we're forcing upon them" sounds > > > > sophistry. > > > > > > > > Best, > > > > tison. > > > > > > > > tison <wander4...@gmail.com> 于2023年12月28日周四 00:27写道： > > > > > > > > > > Hi John, > > > > > > > > > > Glad to hear your feedback. Reply inline: > > > > > > > > > > > In the case of JMH, the repository I linked above forces the user to > > > > download > > > > > > the additional dependency from maven central (or similar repository) > > > > rather > > > > > > than relying on the system preinstalled library. > > > > > > > > > > From a technical view, this is not true because you can download the > > > > > libs manually and place them under MAVEN_HOME. Then it can be regarded > > > > > as a "system preinstalled library". It's the same as download JDK and > > > > > place them under JAVA_HOME. > > > > > > > > > > Except that's not how these libraries are listed within your pom file. If > > > there was a step where you required a developer to download these files, > > > what you're describing would be accurate, but they're downloaded in an > > > automated fashion. Keep in mind, this isn't the JMH that's distributed > > > with the JDK that you're using here, it's an add-on library you're using. > > > > > > > > > > > > > > > > > you can't use org.openjdk.jmh:* as a compile/test compile > > > > > > dependency in your project > > > > > > > > > > fury-benchmark is not released in binary form. But we can of course > > > > > make it an optional dependency (or the entire module optionally) > > > > > behind a profile and deactivated by default so that it's the same as > > > > > how ASF projects can optionally depend on MySQL Connector Java under > > > > > the same license. > > > > > > > > > > The question here isn't about binary form. Keep in mind that first and > > > foremost ASF projects produce source code releases, the convenience > > > binaries are a separate artifact. I'm presently approaching your thread > > > focused on the source code release. I can see your point though and > > > that's > > > where I'm suggesting asking legal may give you additional guidance that I > > > could see leading to a similar situation as Java 9 JavaScript embeddings. > > > Just keep in mind that you're making a module optional to compile, rather > > > than optional to use, even though it's only being used for testing > > > purposes > > > and our expectation (even though it may differ from reality) is that we're > > > reviewing the contents of the source bundle that a user downloads to > > > compile your code, not the binary artifact they depend upon in their > > > projects. > > > > > > > > > > > > > > > > A related discussion can be found at [1]. > > > > > > > > > > Yes, and Hen's response is very appropriate to that situation. It's not > > > really relevant to your situation though since the concern in this thread > > > is your source release, not binary release. You can make something like > > > this optional, and if you keep the benchmark as optional you should be > > > fine > > > as well. For instance, if your maven build is `-Pbenchmark` and it's > > > clear > > > that the user needs to include this license when compiling from source. > > > > > > > > > > > > > > > > >> THEY MAY BE RELIED UPON WHEN THEY SUPPORT AN OPTIONAL FEATURE > > > > > >> "Will the majority of users want to use my product without adding > > > > > >> the > > > > optional components?" > > > > > > > > > > No. Benchmark is for testing; most users don't even know it and cannot > > > > > depend on it as a Maven artifact. > > > > > > > > > > > > P.S. > > > > > > don't approach things as "TLP [x] does it this way so > > > > > > it must be the preferred way" > > > > > Yeah .. Even I don't think Flink did it correctly, this expression > > > > > increases confusion. Most readers don't have the context to understand > > > > > the referred case. I'll avoid it. > > > > > > > > > > Best, > > > > > tison. > > > > > > > > > > [1] https://issues.apache.org/jira/browse/LEGAL-437 > > > > > > > > > > John D. Ament <johndam...@apache.org> 于2023年12月27日周三 23:57写道： > > > > > > > > > > > > On Tue, Dec 26, 2023 at 8:09 PM tison <wander4...@gmail.com> wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > The new podling Fury depends on jmh[1] which is licensed under > > > > > > > GPLv2 > > > > > > > with "CLASSPATH" EXCEPTION. > > > > > > > > > > > > > > > > > > > Just to confirm, are you referring to the code under [benchmark]? > > > > > > > > > > > > > > > > > > > > > > > > > > IIRC Flink ever factored out its benchmark code into a separate > > > > > > > repo > > > > > > > [2] to comply with ASF's license policy [3]. > > > > > > > > > > > > > > > > > > > As a word of caution, don't approach things as "TLP [x] does it this > > > > way so > > > > > > it must be the preferred way" > > > > > > > > > > > > > > > > > > > > > > > > > > But since Fury doesn't modify jmh's code, just refers to some > > > > > > > "org.openjdk.jmh." classes, I wonder if it's the same that a Java > > > > > > > source file refers to JDK's classes under GPLv2 with "CLASSPATH" > > > > > > > EXCEPTION. > > > > > > > > > > > > > > Or, we can exclude the benchmark code from the release like [4] > > > > > > > but > > > > > > > still hold it in the VCS. > > > > > > > > > > > > > > > > > > > There's a difference between the GPL+CPE Cat X ruling we list on our > > > > > > license website and how you're using JMH. When it comes to a Java > > > > > > application, a developer has preinstalled the JDK (or using a > > > > > > manager > > > > of > > > > > > some kind to install it - so not something we're forcing upon them). > > > > In > > > > > > the case of JMH, the repository I linked above forces the user to > > > > download > > > > > > the additional dependency from maven central (or similar repository) > > > > rather > > > > > > than relying on the system preinstalled library. > > > > > > > > > > > > It's probably worth a question to legal, but I'm inclined to believe > > > > the > > > > > > answer is no, you can't use org.openjdk.jmh:* as a compile/test > > > > > > compile > > > > > > dependency in your project but would be happy to be wrong about > > > > > > that. > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > tison. > > > > > > > > > > > > > > [1] https://github.com/openjdk/jmh?tab=GPL-2.0-1-ov-file > > > > > > > [2] https://github.com/apache/flink-benchmarks > > > > > > > [3] https://www.apache.org/legal/resolved.html > > > > > > > [4] > > > > https://github.com/apache/incubator-opendal/blob/main/.gitattributes > > > > > > > > > > > > > > > > > > [benchmark]: > > > > > > https://github.com/apache/incubator-fury/tree/main/java/fury-benchmark > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
