Building hsdis?

[Volker Simonis]

On Sun, Dec 24, 2017 at 11:22 PM, Mario Torre
<neugens.limasoftware at gmail.com> wrote:
>> builds hsdis violates the GNU license because he
>> combines GPLv2 with GPLv3 code
>
> Are those files GPL 2 only or “at your option any later version” too?
>

They are GPLv2 only, otherwise there wouldn't be a problem.

> Indeed, GPL v2 and v3 are not compatible, but if the upgradability is
> allowed then the effective version is already 3. The rest of the openjdk
> code is v2 only afaik though.
>
> Cheers,
> Mario
>
> On Sun 24. Dec 2017 at 13:17, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>>
>> Andrew Haley <aph at redhat.com> schrieb am So. 24. Dez. 2017 um 09:27:
>>
>> > On 23/12/17 17:02, Volker Simonis wrote:
>> > > Andrew Haley <aph at redhat.com> schrieb am Sa. 23. Dez. 2017 um 12:25:
>> > >
>> > >> On 20/12/17 09:54, Volker Simonis wrote:
>> > >>> Yes, that's exactly the issue. And it was communicated to the
>> > >>> OpenJDK
>> > >>> Governing Board more than two and a half years ago (see my mail
>> > >>> "Providing 'hsdis' binaries not possible because of GPLv2/GPLv3
>> > >>> license clash" from May 2015 [1]) and since then reiterated several
>> > >>> times. I'll plan to raise this issue again at the public GB meeting
>> > >>> at
>> > >>> FOSDEM in February next year - however with very little hope that it
>> > >>> will be resolved :(
>> > >>
>> > >> How can the GB resolve it?  I can't think of anything we can do.
>> > >
>> > > The GB obviously can not solve it directly in the same way it can not
>> > solve
>> > > the (still existing) inability to push HotSpot changes or to finally
>> > create
>> > > a Vulnerability Group.
>> > >
>> > > But it can acknowledge the problem and try to put some pressure on
>> > > Oracle
>> > > in order to work on and resolve the problem with a higher priority.
>> >
>> > Such as what, exactly?  Please propose something.
>> >
>> > > If a part of the OpenJDK is practically unusable because of licensing
>> > > issues I consider this inherently unhealthy. From my understanding it
>> > > is
>> > > the GB which is responsible to “oversees the structure, operation, and
>> > > overall health of the OpenJDK”. Who else if not the GB should be
>> > qualified
>> > > to work on resolving it?
>> > >
>> > > [1] http://openjdk.java.net/groups/gb/
>> >
>> > The GB can only solve problems which, in principle, can be solved.  I
>> > know of no reasonable way to solve this one.  There are some extreme
>> > solutions, such as re-licensing all of HotSpot, but that seems
>> > disproportionate.
>>
>>
>> There’a no need for any “extreme” solutions here. We’re speaking about 2
>> (in words “two”) files (i.e. src/utils/hsdis/hsdis.{c,h}) which are
>> neither
>> part of the normal build nor part of any OpenJDK distribution. You have to
>> call the Makefile under src/utils/hsdis/ manually in order to build
>> hsdis.so. But this links in a part of the GNU binutils (which has been
>> relicensed to GPLv3) into the generated shared library. So currently,
>> everybody who builds hsdis violates the GNU license because he combines
>> GPLv2 with GPLv3 code.
>>
>> I simply don’t understand what’s so complicated in relicensing these two
>> hsdis.{c,h} files to GPLv3? Just to stress it one more time: they are NOT
>> part of the HotSpot or the JDK. They are just a tool which can be used to
>> anslyze some HotSpot internals.
>>
>> We could of course reimplement the hsdis functionality in an independent
>> project outside of the OpenJDK, but that would be indeed an “extrem”
>> solution for a trivial problem.
>>
>>
>> >
>> > --
>> > Andrew Haley
>> > Java Platform Lead Engineer
>> > Red Hat UK Ltd. <https://www.redhat.com>
>> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>> >