Building hsdis?

Mario Torre neugens.limasoftware at gmail.com
Sun Dec 24 22:22:23 UTC 2017


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

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


More information about the build-dev mailing list