License compliance on updating gcc runtime libraries

License compliance on updating gcc runtime libraries

[hiraku.toyooka]

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?

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?

(*) https://www.gnu.org/licenses/gcc-exception-3.1.en.html
(**) https://www.gnu.org/licenses/gcc-exception-3.1-faq.en.html

Best regards,
Hiraku Toyooka

Re: License compliance on updating gcc runtime libraries

[Jonathan Wakely]

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.

Re: License compliance on updating gcc runtime libraries

[hiraku.toyooka]

Thank you for your reply.

> The exception applies to the application code, not to libgcc_s.so,
> libstdc++.so etc.

I noticed my prerequisite might be wrong.
I thought that the shared runtime libraries are also included in the
"work of Target Code formed by combining the Runtime Library with
Independent Modules" when they are distributed with applications.
But I read the FAQ again. It says:

> Note that if you distribute libstdc++ as an independent library, you
> will need to follow the terms of the GPL when doing so. For example,
> if you distribute the library itself in object code form, you will
> need to provide source code to your recipients using one of the
> methods listed in section 6 of GPLv3.

So the update case is same. The vendor needs to follow the terms of the
GPL for the shared runtime libraries.

Best Regards,
Hiraku Toyooka

Re: License compliance on updating gcc runtime libraries

[Richard Kenner]

> I have questions about the GCC Runtime Library Exception.

Note that nobody can give you definitive answers to questions like this
since they haven't been litigated.  So any answer is an "educated guess".
Having said that ...

> 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?
>
> 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.

My view is that it's both, depending on the context.  Remember that, from
the perspective of copyright law, executing a program is making a "copy"
of that program.  The GPL (or the Runtime Exception) don't include those
copies in their specific restrictions and limitations, but when you
try to define terms, I think you need to reach the fact that these
are copies.

So:

When the new version of the library is distributed, it's an "independent
library" and (assuming it's GPL, not LGPL), the GPL rules apply to it:
the vendor needs to provide the ability to get source under the usual
GPL rules.

But when an application dynamically links with the (new) library, that
application remains a "work of Target Code" and the GPL+Exception rules
apply to any situation where that work is copied.

Re: License compliance on updating gcc runtime libraries

[Simon Wright]

On 27 Feb 2019, at 12:41, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> 
> Remember that, from the perspective of copyright law, executing a program is making a "copy"
> of that program.

Has that (rather extreme) view been litigated?

Re: License compliance on updating gcc runtime libraries

[Richard Kenner]

>      Remember that, from the perspective of copyright law, executing a
>      program is making a "copy"
>      of that program.
> 
> Has that (rather extreme) view been litigated?

That's actually not extreme, but pretty accepted.  And yes, that has
been litigated.  And you can see that in the GPL in the definition of
"propagate": the exclusion of executing it on a computer wouldn't be
necessary if that weren't considered a copy under copyright law.

Much more extreme positions have been in course rulings.  I'm aware of
a case where a jury ruled that linking a program with a library made
the library a derivative work of the program in all cases (it clearly
is in some).  That case was never appealed, so it (luckily) doesn't
establish a precedent.

Re: License compliance on updating gcc runtime libraries

[Zan Lynx]

On 2/27/19 6:20 AM, Richard Kenner wrote:
> That's actually not extreme, but pretty accepted.  And yes, that has
> been litigated.  And you can see that in the GPL in the definition of
> "propagate": the exclusion of executing it on a computer wouldn't be
> necessary if that weren't considered a copy under copyright law.

That depends on your local copyright law. Some, like the US, have
language saying that copies necessary for usual operation are *not*
covered under copyright.

-- 
                Knowledge is Power -- Power Corrupts
                        Study Hard -- Be Evil

Re: License compliance on updating gcc runtime libraries

[Richard Kenner]

> That depends on your local copyright law. Some, like the US, have
> language saying that copies necessary for usual operation are *not*
> covered under copyright.

I'm refering to US law.  Where, precisely, is the language you are
referring to?  Note that there are two separate issues:

(1) Whether executing a program is considered making a copy under
copyright law.

(2) Whether somebody has an implicit right to make such a copy.

Which of these two are you addressing?

Note that there are cases where copyright law acknowleges that
something is a copy, but permits making that copy.  "Fair use" is
probably the best known of those.

Re: License compliance on updating gcc runtime libraries

[Simon Wright]

On 27 Feb 2019, at 18:37, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> 
> 1) Whether executing a program is considered making a copy under
> copyright law.

I had a look through some of the published judgements, and it's clear that in the US at least copying into RAM (for whatever purpose, and provided the copy has more than fleeting duration) counts as copying for copyright purposes.

I can't help feeling (however useless feelings are in the face of the 9th Circuit) that a software publisher should be able to rely on other methods to retain control of their proprietary software. After all, ARM-based MCUs are capable of executing code directly from Flash, with no copying at all.

Re: License compliance on updating gcc runtime libraries

[hiraku.toyooka]

> Note that nobody can give you definitive answers to questions like this
> since they haven't been litigated.  So any answer is an "educated guess".

Yes. I understand I cannot get definitive answers for license interpretation.

> My view is that it's both, depending on the context.  Remember that, from
> the perspective of copyright law, executing a program is making a "copy"
> of that program.  The GPL (or the Runtime Exception) don't include those
> copies in their specific restrictions and limitations, but when you
> try to define terms, I think you need to reach the fact that these
> are copies.
>
> So:
>
> When the new version of the library is distributed, it's an "independent
> library" and (assuming it's GPL, not LGPL), the GPL rules apply to it:
> the vendor needs to provide the ability to get source under the usual
> GPL rules.
>
> But when an application dynamically links with the (new) library, that
> application remains a "work of Target Code" and the GPL+Exception rules
> apply to any situation where that work is copied.

Thank you for your clarification.
I understand the new version of the library will be an "independent library".

Best Regards,
Hiraku Toyooka