This is the mail archive of the
gcc@gcc.gnu.org
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, <hiraku.toyooka@cybertrust.co.jp> wrote:
>
> Hello,
>
> 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,
libstdc++.so etc.
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
updated.
> 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.