FYI this is how Fury excludes benchmark from the distribution[1] Best, tison.
[1] https://github.com/apache/incubator-fury/pull/1272 John D. Ament <johndam...@apache.org> 于2023年12月31日周日 23:44写道： > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
