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

[Brian Goetz]

Volker;

AndrewH and Mario have now both asked that we refrain from the licensing 
discussion here to focus on the technical discussion, and I'll add my 
own: this is not an appropriate place for licensing or legal 
discussions.  The charter of this list is: " Technical discussion 
related to the JDK Project ".  Let's keep it on topic please!

On 4/26/2021 2:29 PM, Volker Simonis wrote:
> 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
>>>>>