On 08/22/2017 11:15 PM, Sebastian Huber wrote:
> Hello Jeff,
> 
> On 03/08/17 07:11, Sebastian Huber wrote:
>> On 02/08/17 21:30, Jeff Law wrote:
>>
>>> On 07/24/2017 12:03 AM, Sebastian Huber wrote:
>>>> gcc/
>>>>
>>>>     PR libgcc/61152
>>>>     * aarch64/rtems.h: Add GCC Runtime Library Exception. Format
>>>>     changes.
>>>>     * arm/rtems.h: Likewise.
>>>>     * bfin/rtems.h: Likewise.
>>>>     * i386/rtemself.h: Likewise.
>>>>     * lm32/rtems.h: Likewise.
>>>>     * m32c/rtems.h: Likewise.
>>>>     * m68k/rtemself.h: Likewise.
>>>>     * microblaze/rtems.h: Likewise.
>>>>     * mips/rtems.h: Likewise.
>>>>     * moxie/rtems.h: Likewise.
>>>>     * nios2/rtems.h: Likewise.
>>>>     * powerpcspe/rtems.h: Likewise.
>>>>     * rs6000/rtems.h: Likewise.
>>>>     * rtems.h: Likewise.
>>>>     * sh/rtems.h: Likewise.
>>>>     * sh/rtemself.h: Likewise.
>>>>     * sparc/rtemself.h: Likewise.
>>> This seems horribly wrong.  Did anyone ack this change?  I'm fully
>>> supportive of target maintainers taking care of their areas, but
>>> licensing stuff probably should get explicitly ack'd.
>>>
>>> I just reviewed all the rtems config files and I don't see anything in
>>> any of them that deserves a runtime exception with the possible
>>> exception of rs6000/rtems.h.
>>>
>>> Seriously.  Redefining the CPP builtins?  LINK_SPEC?  #undefs? Those
>>> are not things we should be granting an exception for.
>>>
>>> The one that looks marginal to me would be rs6000/rtems.h and its
>>> definition of CRT_CALL_STATIC_FUNCTION.
>>
>> I asked on the mailing list:
>>
>> https://gcc.gnu.org/ml/gcc/2017-07/msg00171.html
>>
>> Jakub Jelinek said that for header files included by libgcc it is
>> important whether they have the runtime exception or not:
>>
>> https://gcc.gnu.org/ml/gcc/2017-07/msg00176.html
>>
>> There is also this PR61152 from 2014
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152
>>
>> which adds the runtime exception to a couple of gcc/ subdirectory
>> files (including some RTEMS files). So, I had no explicit acknowledge,
>> but my impression was that I did simply fix some left over files.
>>
>> If you don't add the runtime exception to files included by libgcc,
>> then the user of GCC must check that these files contain no content
>> that deserves a copyright. Is this really user friendly?
>>
> 
> What should I do now? It would be nice to have a general guideline on
> how to deal with header files used by libgcc.
You have to look at each header and determine how the contents are used
and whether or not those uses are of a nature that requires an exception.

So, yes it's important to get the exception in there when it's needed.
But that doesn't mean we just drop the exception into every file that's
included by something in libgcc.  We are stewards of the GCC sources for
the FSF and we have to be very careful when it comes to changing the
licensing on any code.

WRT 61152.   That doesn't mean splatting the runtime exception into
those files is/was the correct thing to do.  Again, one has to look at
it on a file by file basis.  I have not looked at those changes in
detail to know if they really need the license exception or not.

The FSF has been very clear through the decades that linking against
libgcc should not drag the user's code under the terms of the GPL.  So
all users have to do is extend a degree of trust.  When files have
actually needed a license change we've taken care of it and always will.


I'm not going to demand you revert the change, but let's please get an
explicit ack before changing the licensing terms in the future.

jeff

Reply via email to