On Fri, Dec 29, 2023 at 7: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". > This is the section that I was raising a concern around. In Fury's benchmark module, there are traces of JMH present in the resulting source code, e.g. you need JMH to compile the test code. Yes, it can be excluded if that's the right thing to do. And if there's enough evidence say that is the right course of action that's fine (though it seems a little odd to me that the git repo doesn't match the source release to me). > > 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 > >
