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 > >
