Yes, since we are using OpenJDK to build the jar artifact, jpackage uses its JRE for native applications. So it's packaged with The GNU General Public License (GPL) Version 2.
Kind regards, Illia Barbashov On Wed, Aug 26, 2026 at 3:47 PM Stamatis Zampetakis <[email protected]> wrote: > The Hive convenience binaries have LICENSE and NOTICE files at the root of > the archive to describe the contents. Even though they bundle together many > jar files it is not sufficient to just have the LICENSE inside the jars. I > suppose the same requirements apply for any kind of archive that appears in > the official ASF release repository. I am not a legal expert so I would > suggest raising a LEGAL Jira ticket to clarify what is required or not for > the installer. > > Distributing a JRE along with Hive binaries requires some extra care since > different distributions have different licenses. If the JRE is under GPL > 2.0 with classpath exception then it may be possible to include it in the > release binaries. The ASF license policy outlines what is allowed or not > inside binary distributions [1]. > > I haven't reviewed the content of the beeline jar since it was added > recently but I hope that license compliance was checked when the shading > was introduced. > > Best, > Stamatis > > [1] https://www.apache.org/legal/resolved.html > > On Wed, Aug 26, 2026 at 4:14 PM Illia Barbashov < > [email protected]> wrote: > >> Hi Stamatis, >> >> As I understand it, you mean we must ensure the LICENSE/NOTICE file is >> shipped correctly for all artifacts, including convenience binaries, and >> that we comply with the Apache License. Currently, beeline native >> installers use jpackage to package the beeline-standalone.jar and the JRE >> to make it work as a native application. I mean that we are merely >> distributing the fat jar within the native application wrapper. Hence, the >> apache license should be present in the same way it is for all jars that we >> distribute. We can also use jpackage to include any files we want inside >> the native installer. >> Do you think checking the fat jar's licenses is sufficient for native >> installers, given that the native app contains only that jar and the JRE >> needed to run it? >> >> Kind Regards, >> Illia Barbashov >> >> On Wed, Aug 26, 2026 at 10:48 AM Stamatis Zampetakis <[email protected]> >> wrote: >> >>> The main release burden I have in mind is related to LICENSE/NOTICE >>> generation and verification that is quite complex when it comes to >>> binaries. It's not about signing archives or testing the installers. >>> >>> On every release vote the majority of my time is spent on verifying >>> compliance of LICENSE/NOTICE with ASF guidelines. I am not doing it for >>> standalone metastore archives and I don't think I will find time to do it >>> for other binaries. >>> >>> Best, >>> Stamatis >>> >>> On Tue, Aug 25, 2026 at 11:14 AM Denys Kuzmenko <[email protected]> >>> wrote: >>> >>>> Hi Team, >>>> >>>> +1 for the initiative. >>>> >>>> I think adding Beeline native installers as convenient binaries would >>>> provide a much better experience for users and should not add significant >>>> overhead to the release process. As Illia pointed out, this would require >>>> only an additional PGP signing step, with the installers distributed >>>> alongside the other release artifacts. >>>> >>>> We could also add CI coverage to build and validate the installers for >>>> the supported platforms, reducing the risk of issues during the release >>>> process. >>>> >>>> Overall, the additional release burden seems reasonable compared to the >>>> convenience and accessibility this would provide to Beeline users. >>>> >>>> Best regards, >>>> Denys >>>> >>>
