RFR: AARCH64: Top-level JDK changes

Dean Long dean.long at oracle.com
Fri Nov 14 20:44:13 UTC 2014

On 11/14/2014 12:39 AM, Magnus Ihse Bursie wrote:
>> 13 nov 2014 kl. 19:33 skrev Christian Thalinger <christian.thalinger at oracle.com>:
>>> On Nov 13, 2014, at 6:09 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>>> On 2014-11-10 11:32, Volker Simonis wrote:
>>>> On Mon, Nov 10, 2014 at 10:42 AM, Erik Joelsson
>>>> <erik.joelsson at oracle.com> wrote:
>>>>> On 2014-11-10 10:27, Volker Simonis wrote:
>>>>>> On Mon, Nov 10, 2014 at 9:08 AM, Erik Joelsson <erik.joelsson at oracle.com>
>>>>>> wrote:
>>>>>>> Hello,
>>>>>>> I would certainly like to have these files updated, but unfortunately the
>>>>>>> license on these files changed from GPL2 to GPL3. This essentially means
>>>>>>> that the switch is non trivial from a legal perspective and the
>>>>>>> impression
>>>>>>> I've received when I last inquired about updating these files was that
>>>>>>> it's
>>>>>>> unlikely to ever happen unless a very strong case can be presented for
>>>>>>> why
>>>>>>> it's needed.
>>>>>>> So the reason we have the over engineered solution for config.guess is
>>>>>>> simply that it's much easier than getting legal approval for updating
>>>>>>> these
>>>>>>> files.
>>>>>> OK, but in that case I don't see any reason for keeping this
>>>>>> "over-engineered" solution at all. If there will not be any pulls from
>>>>>> upstream anyway then there's no reason for keeping these file
>>>>>> untouched. I'd propose then to just remove the wrappers and do all the
>>>>>> chenges right in the corresponding files (of course that's not the
>>>>>> topic of this change but should be done separately).
>>>>> And again, the reason we didn't change the existing file but instead wrapped
>>>>> it, was that we don't have explicit legal approval for doing derivative work
>>>>> for these 3rd party files. Maybe it's ok, maybe it's not, I will not be the
>>>>> person saying it is ok.
>>>> OK, now I got it. I thought we just use the wrappers because we want
>>>> to easily integrate the upstream versions. But instead it is only
>>>> because we don't want to edit these files because of legal
>>>> uncertainties.
>>>> So in that case that means we're also not allowed to edit 'config.sub'
>>>> and have to create a wrapper for it, right?
>>> Yes, you are correct. We cannot modify these files.
>>> As far as I understand, the legal reason for including these files are the explicit exception:
>>> # As a special exception to the GNU General Public License, if you
>>> # distribute this file as part of a program that contains a
>>> # configuration script generated by Autoconf, you may include it under
>>> # the same distribution terms that you use for the rest of that program.
>>> But this is just a distribution license, not a modification license.
>>>  From my IANAL point of view, this exception should be enough to disregard if the file is also distributed under GPL2 or GPL3. Unfortunately, as Erik says, our lawyers are apprehensive of GLP3. So while we thought that we could be able to periodically sync these files with upstream (and remove our external "patches" after a while), we have not been able to do so.
>> Why do we have these files in our repository in the first place?
> Because they are needed by the configure script. They are a sort of runtime libraries for configure, but since they are written as shell scripts, the source code form and the executable form is the same.
> The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though.
What if we require Autoconf to be installed on the host?  Does that 
solve any problems?


> /Magnus
>>> So, this fix will need to do the same dance with config.sub as for guess.guess. Unfortunately. :(
>>> /Magnus

More information about the build-dev mailing list