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

(EI+ISTP)CFPs: EEPT2019 Conference Location: Hangzhou, China

[kuichuyc57316]

|

EEPT2019

March 24-25, 2019 in Hangzhou, China

Welcome to EEPT2019

Conference Name:2019 International Conference on Energy Engineering and Power 
Technology (EEPT2019) 
Date: March 24-25, 2019 Location: Hangzhou(Hilton Hangzhou Xiaoshan), China 
Website: http://www.eept2019.org
This conference is aimed to letting researchers and practitioners from academia 
and industry have the chance to meet, and provide a good platform for them to 
share knowledge and theory, method and application results of energy and power 
engineering and environmental science, and collect the related papers from 
around the world. And give the amateurs in the field an opportunity to 
communicate with professionals. We look forward to your participation in 
EEPT2019!

Publication

Journals: DEStech Transactions on Environment, Energy and Earth Sciences
Published with ISSN: 2475-8833, ISBN and DOI for all papers.

After publication, all papers will be submitted for index in EI Compendex, 
Scopus, Thomson Reuters Web of Science CPCI-S (ISTP indexing) and CNKI Scholar.

 Excellent papers will be selected and recommended to SCI or EI journals 
publishing.

Paper Submission

Please send the full paper & abstract via sub...@eept2019.org or 
eept2...@sina.com. Paper Submission Deadline: March 11, 2019. Your submission 
will be confirmed in 2 days by conference secretary. Should you have any 
questions, please feel free to contact us. Regular papers are allowed to 5 
pages. Extra pages(exceed 5 pages) will incur additional charges.

|

Re: License compliance on updating gcc runtime libraries

[Jonathan Wakely]

On Wed, 27 Feb 2019 at 09:06,  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

[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: [RFC] Change PCH "checksum"

[Florian Weimer]

* Richard Biener:

>> Since the introduction of GNU Property notes this is (sadly) no longer
>> the correct way to iterate through ELF notes. The padding of names and
>> desc  might now depend on the alignment of the PT_NOTE segment.
>> https://sourceware.org/ml/binutils/2018-09/msg00359.html
>
> Ick, that's of course worse ;)  So it's not entirely clear what
> the correct thing to do is - from how I read the mail at the above
> link only iff sh_align of the note section is exactly 8 the above
> ALIGN would use 8 byte alignment and else 4 is correct (independent
> on sh_align).  Or can I assume sh_align of the note section is
> "correct" for all existing binaries?

sh_align doesn't come into play if you look at program headers.

A GNU build ID note will not end up in a PT_NOTE segment with 8-byte
alignment, so I think you can skip those early, like this:

+  if (info->dlpi_phdr[i].p_type != PT_NOTE
+  || info->dlpi_phdr[i].p_align != 4)
+continue;

(Untested, of course.)

Thanks,
Florian

Re: License compliance on updating gcc runtime libraries

[Simon Wright]

On 27 Feb 2019, at 12:41, Richard Kenner  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

Kitware, Inc. - Assignment for all future changes

[Adrien Beaudet]

Hello,

A Kitware employee, Ben Boeckel, would like to contribute a patch of
approximately 100 lines. There is also potential for Kitware employees to
contribute more code in the future. Could you please send us the
appropriate form for signature?

Thanks,
Adrien


Adrien Beaudet
*Associate Contracts Administrator*


Kitware, Inc. 
1712 Route 9, Suite 300

Clifton Park, NY 12065

p: 518-836-3816

Re: Kitware, Inc. - Assignment for all future changes

[David Edelsohn]

Sent offline to Adrien.

- David

On Wed, Feb 27, 2019 at 10:14 AM Adrien Beaudet 
wrote:

> Hello,
>
> A Kitware employee, Ben Boeckel, would like to contribute a patch of
> approximately 100 lines. There is also potential for Kitware employees to
> contribute more code in the future. Could you please send us the
> appropriate form for signature?
>
> Thanks,
> Adrien
>
>
> Adrien Beaudet
> *Associate Contracts Administrator*
>
>
> Kitware, Inc. 
> 1712 Route 9, Suite 300
>
> Clifton Park, NY 12065
>
> p: 518-836-3816
>

Re: [RFC] Change PCH "checksum"

[Nathan Sidwell]

On 2/26/19 11:18 AM, Michael Matz wrote:

Hi,

On Tue, 26 Feb 2019, Richard Biener wrote:


get_build_id_1 (struct dl_phdr_info *info, size_t, void *data)
{


Isn't this all a bit silly?  We could simply encode the svn revision, or
maybe even just some random bytes generated once in stage1 at build time
as "checksum" and be done with.  In the latter case PCHs will then not
work across different compiler builds, but so what?


FWIW, here's what I do on the modules branch, which has similar 
versioning concerns.


1) in experimental mode, I stamp with the local timestamp modification 
of the cp directory.  I allow mixing versions with in the same day (with 
a warning).


2) in non-experimental mode, I plan to lock to the GCC major.minor tuple.

PCH would need to look at more than the cp directory, but that's good 
enough for me.  I'm pondering an 'ignore version' developer option, but 
as it's only me right now, that's not been a need.


nathan

--
Nathan Sidwell

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  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: Question regarding constraint usage within inline asm

[Segher Boessenkool]

Hi!

On Mon, Feb 25, 2019 at 06:32:53PM +, Michael Matz wrote:
> On Thu, 21 Feb 2019, Segher Boessenkool wrote:
> > > That said, the "bug" in the case we're seeing, is that asmcons rewrote 
> > > all of "input"'s pseudos, and it should be more careful to not create 
> > > rtl with illegal constraint usage that LRA cannot fix up.  With the 
> > > fix, operand %1 in the inline asm is no longer hard coded to r3 and it 
> > > uses the pseudo instead, so everything is copacetic.
> > 
> > And that expand used one pseudo for everything in the asm is bad 
> > already.
> 
> I'll contest that.  Asms aren't that special from an input-output 
> perspective and shouldn't be (makes for clearer and hence more correct 
> code).  hardregs are special, OTOH.  expand doesn't (and shouldn't) do 
> anything special for
> 
>_2 = _1 + _1;
> 
> (i.e. it should assign the same pseudo to both inputs), from which follows 
> that it shouldn't do anything special for
> 
>   asm("" : "=r" (_2) : "r" (_1), "w" (_1))
> 
> either.  The picture changes if _1 corresponds to a local decl with an 
> associated hard reg; those don't get SSA names for a reason.  But I 
> believe you're worrying about the common case of off-the-mill SSA 
> names.

Yup.  All good points, I didn't think this through enough obviously.

The _1+_1 isn't great if that single pseudo then ends up in mem (it will
need a reload again on most archs, probably causing another spill), btw.

> Anything that would cause breakage by such behaviour of expand is to be 
> rectified by LRA/reload, not by hackery within expand.

You get worse code that way.  Reload is much too late to make optimised
code, and that isn't its task anyway: its task is to make something that
works where the passes before it couldn't manage.

Yes, reload should be able to fix up anything (well, within some limits).
That is not an excuse to generate code that we know will need such fixups
though.

I suppose check_asm_operands needs to be taught a bit more strict rules
as well about what is a valid asm.  Hrm.  A lot to think about :-)


Segher