This is the mail archive of the
mailing list for the GCC project.
Re: License compliance on updating gcc runtime libraries
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: hiraku dot toyooka at cybertrust dot co dot jp
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 27 Feb 2019 09:32:14 +0000
- Subject: Re: License compliance on updating gcc runtime libraries
- References: <CADPJy8VH-1O_nWy1TVswrm9VshVq1tJBpy33UY-p8dpVtsq32g@mail.gmail.com>
On Wed, 27 Feb 2019 at 09:06, <firstname.lastname@example.org> wrote:
> I have questions about the GCC Runtime Library Exception.
> When an equipment vendor distributes an update of shared gcc runtime
> libraries (e.g. libgcc_s.so, libstdc++.so) to the shipped equipment
> and when the equipment has applications which are dynamically linked to
> older release of the shared libraries and which are being linked to
> newer ones, in this case, is the exception applied to the newer ones?
The exception applies to the application code, not to libgcc_s.so,
Updating the runtime libraries doesn't change anything. If the
applications were covered by the exception when compiled, they are
still covered by the exception later when the runtime libraries are
> I read the exception document(*) and FAQ(**).
> I understood that "a work of Target Code formed by combining the Runtime
> Library with Independent Modules" could be propagated as non-GPLv3
> license, even if "the Runtime Library" was dynamically linked to
> "Independent Modules".
> I wonder if an update of the shared libraries are regarded as a part of
> the "work of Target Code" or "independent library" in the above case.
> Could anyone kindly tell me the intention of the exception?
The intention is that GCC can be used to build non-GPL software.
Updating the shared libraries doesn't change that.