On Sun, Dec 24, 2017 at 11:22 PM, Mario Torre <neugens.limasoftw...@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.simo...@gmail.com> > wrote: >> >> Andrew Haley <a...@redhat.com> schrieb am So. 24. Dez. 2017 um 09:27: >> >> > On 23/12/17 17:02, Volker Simonis wrote: >> > > Andrew Haley <a...@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 >> >
