Resumption of Leyden Discusssion (was Re: Result: New Project: Leyden)

Mon Apr 26 18:29:37 UTC 2021

Anderson Vasconcelos Pires <andvasp at gmail.com> schrieb am Mo., 26. Apr.
2021, 14:20:

> Hi Volker,
>
> Looks like the graal uses the similar license of openjdk.
> I understand they would have the same limitation to generate native
> images, right?
> If I am not wrong, why do they decide to have native image? We couldn't
> use at least the same approach?
>

That's not right. The complete SubstrateVM [1] (which is GraalVM's
equivalent of HotSpot in OpenJDK) is fully GPLv2+CPE licensed.

That's actually exactly the difference to HotSpot which is mostly GPLv2
only (without CPE) and the thing I wanted to point out if we decide to
implement Leyden in top of the current HotSpot.

[1] https://github.com/oracle/graal/tree/master/substratevm

> Best regards,
> Anderson.
>
> On Sat, Apr 24, 2021 at 5:44 AM Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
>> Hi Andrew,
>>
>> thank you so much for resurrecting the discussion on project Leyden! I
>> read through your leydendoc [1] which I think is an excellent and
>> technically deep-dive summary of the current workings of the GraalVM
>> Native Image Generator. The analysis and ideas how this functionality
>> could be implemented in the context of OpenJDK and HotSpot is
>> technically sound and very interesting.
>>
>> I'm really a little reluctant to add some non-technical doubts and
>> acting as a killjoy here, but I think there's one real caveat with
>> your approach and that's (unfortunately) licensing. As you know, the
>> whole HotSpot code base (with the exception of very few header files
>> [2]) is licensed under GPLv2 WITHOUT Class Path Exception (CPE).
>> HotSpot code can only be accessed without getting tainted by the GPL
>> through a restricted set of exported, GPLv2+CPE licensed interfaces
>> [2]. This is already a "weak" construct which has never been disputed
>> but I don't want to discuss that here.
>>
>> I'm however afraid that your approach of linking large parts of the
>> HotSpot code together with application classes into a single static
>> image will undoubtedly "infect" all the user code with the GPL
>> license. I think that's unacceptable for the majority of Java
>> applications which are not already GPLv2 licensed. Unfortunately, in
>> my opinion this seems to be a much bigger problem compared to the
>> technical difficulties to implement your approach. Maybe we should
>> have a look at alternative, existing JVM implementations (like OpenJ9,
>> which I'm not all all familiar with) which are more liberally
>> licensed? Having another write-up, similar to yours, which explores
>> the same possibilities with OpenJ9 would be definitely a nice read :)
>>
>> As a side note, it seems like all the Java classes and even the native
>> code parts of the class library are all licensed under GPLv2+CPE. So
>> linking them into a native image together with user/application code
>> seems to be less of a problem.
>>
>> Thanks again for your great analysis,
>> Volker
>>
>> [1] https://github.com/adinn/leydendoc
>> [2] jvm_md.h, jmm.h, jvm_constants.h, jvm.h, jvm_io.h, jvmtiLib.xsl
>>
>> On Fri, Apr 23, 2021 at 5:30 PM Andrew Dinn <adinn at redhat.com> wrote:
>> >
>> > Hello All,
>> >
>> > There has been a rather long and quiet interlude since the result of the
>> > Leyden vote was reported (see below). Unfortunately, there has not yet
>> > been any follow-up announcement of a project repo, mail list(s) or
>> > working group. However, that's no indication that the project is not
>> > still of great interest to those of us who voted for it, nor that some
>> > of us have not been thinking about how we might proceed.
>> >
>> > I'd like to resume the initial discussion and, I hope, trigger some
>> > follow-up actions by offering a few recommendations for how we might
>> > wish to progress with Leyden. This is based on lessons learned from
>> > working with the GraalVM Native implementation over the last year or
>> two.
>> >
>> > Please note that I'm not suggesting that GraalVM Native provides a
>> > blueprint for how Leyden should proceed. Indeed, I recognise that one of
>> > the key reasons for creating the Leyden project is to sharpen up the
>> > definition of static Java and, in doing so, critique some of the choices
>> > made in implementing GraalVM Native.
>> >
>> > The path I am proposing we follow here is to:
>> >
>> > - identify some of the key architectural and design decisions made in
>> > implementing GraalVM Native that appear to be relevant to a Hotspot
>> > implementation
>> >
>> > - gauge how far those decisions contribute to improvements in certain
>> > aspects of GraalVM Native performance vs degradation in other aspects
>> >
>> > - at the same time assess how systematically and coherently those same
>> > decisions deal, or fail to deal, with some of the problematic semantic
>> > issues involved in delivering static Java deployments
>> >
>> > - consider whether similar decisions might be worth taking in the
>> > context of an implementation based on the current Hotspot code base
>> >
>> > I have posted a document to github [1] that provides a summary of my own
>> > thoughts on the above themes. It starts with a critique of GraalVM
>> > which, for the benefit of OpenJDK project members who are not familiar
>> > with the implementation, also explains (as accurately as my
>> > understanding permits) relevant aspects of the design and
>> > implementation. It then goes on to discuss how this might be relevant to
>> > a Leyden implementation that reuses existing Hotspot components as far
>> > as possible.
>> >
>> > The document has been reviewed informally by a few OpenJDK project
>> > colleagues. I'd be very grateful if others who have expressed an
>> > interest in the project could take the time to read it and reflect on
>> > it, either providing feedback directly on the document or following up
>> > with their own opinions and suggestions for how to proceed.
>> >
>> > [1] https://github.com/adinn/leydendoc
>> > n.b. the repo has a Creative Commons 1.0 open source license.
>> >
>> > regards,
>> >
>> >
>> > Andrew Dinn
>> > -----------
>> > Red Hat Distinguished Engineer
>> > Red Hat UK Ltd
>> > Registered in England and Wales under Company Registration No. 03798903
>> > Directors: Michael Cunningham, Michael ("Mike") O'Neill
>> >
>> >
>> >
>> > On 11/06/2020 17:36, mark.reinhold at oracle.com wrote:
>> > > Voting on the Leyden Project [1], with me as the initial Lead,
>> > > is now closed.
>> > >
>> > > Yes: 38
>> > > Veto: 0
>> > > Abstain: 0
>> > >
>> > > (Two votes, by individuals not in the Members Group [2], did
>> > >   not count.)
>> > >
>> > > According to the Bylaws definition of Lazy Consensus, this is
>> > > sufficient to approve the new Project and its initial Lead.
>> > >
>> > > - Mark
>> > >
>> > >
>> > > [1]
>> https://mail.openjdk.java.net/pipermail/announce/2020-May/000289.html
>> > > [2] https://openjdk.java.net/census#members
>> > >
>> >
>>
>