Update to GCC copyright assignment policy

Update to GCC copyright assignment policy

[David Edelsohn]

GCC was created as part of the GNU Project but has grown to operate as
an autonomous project.

The GCC Steering Committee has decided to relax the requirement to
assign copyright for all changes to the Free Software Foundation.  GCC
will continue to be developed, distributed, and licensed under the GNU
General Public License v3.0. GCC will now accept contributions with or
without an FSF copyright assignment. This change is consistent with
the practices of many other major Free Software projects, such as the
Linux kernel.

Contributors who have an FSF Copyright Assignment don't need to
change anything.  Contributors who wish to utilize the Developer Certificate
of Origin[1] should add a Signed-off-by message to their commit messages.
Developers with commit access may add their name to the DCO list in the
MAINTAINERS file to certify the DCO for all future commits in lieu of individual
Signed-off-by messages for each commit.

The GCC Steering Committee continues to affirm the principles of Free
Software, and that will never change.

- The GCC Steering Committee

[1] https://developercertificate.org/

Re: Update to GCC copyright assignment policy

[Jakub Jelinek]

On Tue, Jun 01, 2021 at 10:00:06AM -0400, David Edelsohn via Gcc wrote:
> GCC was created as part of the GNU Project but has grown to operate as
> an autonomous project.
> 
> The GCC Steering Committee has decided to relax the requirement to
> assign copyright for all changes to the Free Software Foundation.  GCC
> will continue to be developed, distributed, and licensed under the GNU
> General Public License v3.0. GCC will now accept contributions with or
> without an FSF copyright assignment. This change is consistent with
> the practices of many other major Free Software projects, such as the
> Linux kernel.
> 
> Contributors who have an FSF Copyright Assignment don't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] should add a Signed-off-by message to their commit messages.
> Developers with commit access may add their name to the DCO list in the
> MAINTAINERS file to certify the DCO for all future commits in lieu of individual
> Signed-off-by messages for each commit.
> 
> The GCC Steering Committee continues to affirm the principles of Free
> Software, and that will never change.

What does this mean for the source file comments?

Do we continue using contrib/update-copyright.py --this-year to update
the FSF copyright notices?

When a new source file (that has copyright boilerplate, not say some small
testcase) is added by somebody submitting their work under FSF copyright
assignment, shall the
  Copyright (C) 2021 Free Software Foundation, Inc.
be added?

What about when such a new source file is added by somebody submitting their
work under DCO?  Shall they list
  Copyright (C) 2021 John Doe
or something else (note, update-copyright.py would need all such copyright
lines in it).  If yes and later on somebody with FSF copyright assignment
modifies that, shall the
  Copyright (C) 2021 Free Software Foundation, Inc.
line be added?

Can contributors with FSF Copyright Assignment on file (or those working
for companies with company wide ones) assign all their further work or
just selected commits under DCO?

	Jakub

Re: Update to GCC copyright assignment policy

[Florian Weimer]

* David Edelsohn via Gcc:

> GCC was created as part of the GNU Project but has grown to operate as
> an autonomous project.
>
> The GCC Steering Committee has decided to relax the requirement to
> assign copyright for all changes to the Free Software Foundation.  GCC
> will continue to be developed, distributed, and licensed under the GNU
> General Public License v3.0. GCC will now accept contributions with or
> without an FSF copyright assignment. This change is consistent with
> the practices of many other major Free Software projects, such as the
> Linux kernel.

What about the parts of GCC with FSF copyrights that are not covered by
the GPL, but the GPL with exceptions?  How is it possible to move code
between the parts if a contributor previously used DCO and thus gave
only permission to license under the open source license “indicated in
the file”?

Thanks,
Florian

Re: Update to GCC copyright assignment policy

[Mark Wielaard]

Hi David,

On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote:
> The GCC Steering Committee has decided to relax the requirement to
> assign copyright for all changes to the Free Software Foundation.  GCC
> will continue to be developed, distributed, and licensed under the GNU
> General Public License v3.0. GCC will now accept contributions with or
> without an FSF copyright assignment. This change is consistent with
> the practices of many other major Free Software projects, such as the
> Linux kernel.
> 
> Contributors who have an FSF Copyright Assignment don't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] should add a Signed-off-by message to their commit messages.
> Developers with commit access may add their name to the DCO list in the
> MAINTAINERS file to certify the DCO for all future commits in lieu of individual
> Signed-off-by messages for each commit.

This seems a pretty bad policy to be honest.
Why was there no public discussion on this?

I certainly understand not wanting to assign copyright to the FSF
anymore given the recent board decisions. But changing GCC from having
a shared copyright pool to having lots of individual (or company?)
copyright holders seems like a regression for a strong copyleft
project.

With individual copyright holders companies no longer have clear way to
know whether they are in compliance unless they talk to each and every
individual copyright holder (see also the linux kernel, where there are
some individuals who randomly sue companies just to get some money to
drop the lawsuit). And for users it will be harder to get compliant
sources if they can no longer simply ask the shared copyright holder,
but instead will have to get enough individual copyright holders to get
a distributor into compliance.

If we no longer want the FSF to be the legal guardian and copyright
holder for GCC could we please find another legal entity that performs
that role and helps us as a project with copyleft compliance?

I would be happy to setup a shared copyright pool under the Conservancy
Copyleft Compliance project for example:
https://sfconservancy.org/copyleft-compliance/

Thanks,

Mark

Re: Update to GCC copyright assignment policy

[David Edelsohn]

On Tue, Jun 1, 2021 at 10:15 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Tue, Jun 01, 2021 at 10:00:06AM -0400, David Edelsohn via Gcc wrote:
> > GCC was created as part of the GNU Project but has grown to operate as
> > an autonomous project.
> >
> > The GCC Steering Committee has decided to relax the requirement to
> > assign copyright for all changes to the Free Software Foundation.  GCC
> > will continue to be developed, distributed, and licensed under the GNU
> > General Public License v3.0. GCC will now accept contributions with or
> > without an FSF copyright assignment. This change is consistent with
> > the practices of many other major Free Software projects, such as the
> > Linux kernel.
> >
> > Contributors who have an FSF Copyright Assignment don't need to
> > change anything.  Contributors who wish to utilize the Developer Certificate
> > of Origin[1] should add a Signed-off-by message to their commit messages.
> > Developers with commit access may add their name to the DCO list in the
> > MAINTAINERS file to certify the DCO for all future commits in lieu of individual
> > Signed-off-by messages for each commit.
> >
> > The GCC Steering Committee continues to affirm the principles of Free
> > Software, and that will never change.
>
> What does this mean for the source file comments?
>
> Do we continue using contrib/update-copyright.py --this-year to update
> the FSF copyright notices?
>
> When a new source file (that has copyright boilerplate, not say some small
> testcase) is added by somebody submitting their work under FSF copyright
> assignment, shall the
>   Copyright (C) 2021 Free Software Foundation, Inc.
> be added?
>
> What about when such a new source file is added by somebody submitting their
> work under DCO?  Shall they list
>   Copyright (C) 2021 John Doe
> or something else (note, update-copyright.py would need all such copyright
> lines in it).  If yes and later on somebody with FSF copyright assignment
> modifies that, shall the
>   Copyright (C) 2021 Free Software Foundation, Inc.
> line be added?

The copyright author will be listed as "Free Software Foundation,
Inc." and/or "The GNU Toolchain Authors", as appropriate.

>
> Can contributors with FSF Copyright Assignment on file (or those working
> for companies with company wide ones) assign all their further work or
> just selected commits under DCO?

The update to the policy does not negate any existing or future FSF
copyright assignments -- it solely expands the options available.
Individuals may add a Signed-off-by line or add their name to the DCO
list in the MAINTAINERS file, but it doesn't change the legal
framework for a contribution by an individual or company with a
copyright assignment.  Individuals and companies can choose how to
proceed with their existing FSF copyright assignments.  Individuals
and companies may continue to establish new copyright assignments with
the FSF.

Thanks, David

Re: Update to GCC copyright assignment policy

[Paul Koning]

> On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc <gcc@gcc.gnu.org> wrote:
> 
> The copyright author will be listed as "Free Software Foundation,
> Inc." and/or "The GNU Toolchain Authors", as appropriate.

What does that mean?  FSF is a well defined organization.  "The GNU Toolchain Authors" sounds like one, but is it?  Or is it just a label for "the set of contributors who have contributed without assigning to FSF"?  In other words, who is the owner of such a work, the GTA, or the submitter?  I'm guessing the latter.

That seems to create a possible future complication.  Prior to this change, the FSF (as owner of the copyright) could make changes such as replacing the GPL 2 license by GPL 3.  With the policy change, that would no longer be possible, unless you get the approval of all the copyright holders.  This may not be considered a problem, but it does seem like a change.

I looked at gcc.gnu.org to find the updated policy.  I don't think it's there; the "contribute" page wording still feels like the old policy.  Given the change, it would seem rather important to have the implications spelled out in full, and the new rules clearly expressed.

	paul

Re: Update to GCC copyright assignment policy

[Mark Wielaard]

On Tue, 2021-06-01 at 16:24 +0200, Florian Weimer via Gcc wrote:
> * David Edelsohn via Gcc:
> 
> > GCC was created as part of the GNU Project but has grown to operate as
> > an autonomous project.
> > 
> > The GCC Steering Committee has decided to relax the requirement to
> > assign copyright for all changes to the Free Software Foundation.  GCC
> > will continue to be developed, distributed, and licensed under the GNU
> > General Public License v3.0. GCC will now accept contributions with or
> > without an FSF copyright assignment. This change is consistent with
> > the practices of many other major Free Software projects, such as the
> > Linux kernel.
> 
> What about the parts of GCC with FSF copyrights that are not covered by
> the GPL, but the GPL with exceptions?  How is it possible to move code
> between the parts if a contributor previously used DCO and thus gave
> only permission to license under the open source license “indicated in
> the file”?

Depends on which DCO you uses. Various project use the following DCO,
which makes clear you assign permissions under all applicable licenses
(this helps if the project uses more than one, possibly incompatible,
license and/or is dual licensed):

        Developer's Certificate of Origin

        By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me,
            and I have the right to submit the contribution under each
            license indicated in, or otherwise designated as being
            applicable to, the file.

        (b) The contribution was provided directly to me by some other
            person who certified (a), and I have not modified it.

        (c) I understand and agree that the project and the
            contribution are public and that a record of the
            contribution (including all personal information I submit
            with it, including my sign-off) is maintained indefinitely
            and may be redistributed.

Cheers,

Mark 

Re: Update to GCC copyright assignment policy

[Alfred M. Szmidt]

   GCC was created as part of the GNU Project but has grown to operate as
   an autonomous project.

That is true for all GNU project.

   The GCC Steering Committee has decided to relax the requirement to
   assign copyright for all changes to the Free Software Foundation.  GCC
   will continue to be developed, distributed, and licensed under the GNU
   General Public License v3.0. GCC will now accept contributions with or
   without an FSF copyright assignment. This change is consistent with
   the practices of many other major Free Software projects, such as the
   Linux kernel.

The GCC steering committee is not in a position to make such a
decision that is up to the GNU project head and the FSF legal counsel,
it also fly against the mission statement.  Not to mention that this
was not discussed with anyone, including people in the GNU project.

Re: Update to GCC copyright assignment policy

[D. Hugh Redelmeier]

| From: Mark Wielaard <mark@klomp.org>

| This seems a pretty bad policy to be honest.
| Why was there no public discussion on this?

Agreed.  I also agree with the rest of Mark's message.

(Note: I haven't contributed to GCC but I have contributed to other
copylefted code bases.)

It is important that the pool be trustable.  A tall order, but
solvable, I think.

Two pools (FSF for old stuff, something else, for new stuff if the
contributor prefers) should be quite managable.

This would allow, for example, moving to an updated copyleft if the
two pools agreed.  It is important that the governance of the pool be
trustable.

We've trusted the FSF and now some have qualms.  A second pool would
be a check on the power of the first pool.

Individual unassigned copyright pretty much guarantees that the
copyright terms can never be changed.  I don't think that that is
optimal.

Update to GCC copyright assignment policy

[Christopher Dimech]

I am pleased to see a change based on my recommendation.  The FSF should not refrain
from accepting contributions based on modified versions of software in instances
where the developer of the modified work is unable to get a copyright assignment
of the code, but are legally allowed to use a compatible license without requiring
copyright.

----- Christopher Dimech

Society has became too quick to pass judgement and declare someone Persona Non-Grata,
the most extreme form of censure a country can bestow.

In a new era of destructive authoritarianism, I support Richard Stallman.  Times of great
crisis are also times of great opportunity. I call upon you to make this struggle yours as well !

https://stallmansupport.org/     https://www.fsf.org/     https://www.gnu.org/


> Sent: Wednesday, June 02, 2021 at 2:28 AM
> From: "Mark Wielaard" <mark@klomp.org>
> To: "David Edelsohn" <dje.gcc@gmail.com>, "GCC Development" <gcc@gcc.gnu.org>
> Subject: Re: Update to GCC copyright assignment policy
>
> Hi David,
>
> On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote:
> > The GCC Steering Committee has decided to relax the requirement to
> > assign copyright for all changes to the Free Software Foundation.  GCC
> > will continue to be developed, distributed, and licensed under the GNU
> > General Public License v3.0. GCC will now accept contributions with or
> > without an FSF copyright assignment. This change is consistent with
> > the practices of many other major Free Software projects, such as the
> > Linux kernel.
> >
> > Contributors who have an FSF Copyright Assignment don't need to
> > change anything.  Contributors who wish to utilize the Developer Certificate
> > of Origin[1] should add a Signed-off-by message to their commit messages.
> > Developers with commit access may add their name to the DCO list in the
> > MAINTAINERS file to certify the DCO for all future commits in lieu of individual
> > Signed-off-by messages for each commit.
>
> This seems a pretty bad policy to be honest.
> Why was there no public discussion on this?
>
> I certainly understand not wanting to assign copyright to the FSF
> anymore given the recent board decisions. But changing GCC from having
> a shared copyright pool to having lots of individual (or company?)
> copyright holders seems like a regression for a strong copyleft
> project.
>
> With individual copyright holders companies no longer have clear way to
> know whether they are in compliance unless they talk to each and every
> individual copyright holder (see also the linux kernel, where there are
> some individuals who randomly sue companies just to get some money to
> drop the lawsuit). And for users it will be harder to get compliant
> sources if they can no longer simply ask the shared copyright holder,
> but instead will have to get enough individual copyright holders to get
> a distributor into compliance.
>
> If we no longer want the FSF to be the legal guardian and copyright
> holder for GCC could we please find another legal entity that performs
> that role and helps us as a project with copyleft compliance?
>
> I would be happy to setup a shared copyright pool under the Conservancy
> Copyleft Compliance project for example:
> https://sfconservancy.org/copyleft-compliance/
>
> Thanks,
>
> Mark
>

Re: Update to GCC copyright assignment policy

[Richard Kenner]

> > What about the parts of GCC with FSF copyrights that are not covered by
> > the GPL, but the GPL with exceptions?  How is it possible to move code
> > between the parts if a contributor previously used DCO and thus gave
> > only permission to license under the open source license "indicated in
> > the file"?
> 
> Depends on which DCO you uses. Various project use the following DCO,
> which makes clear you assign permissions under all applicable licenses
> (this helps if the project uses more than one, possibly incompatible,
> license and/or is dual licensed):

See above.  The issue is if the project wants to change the status of
a file from GPL to GPL plus exception.  It can't do that if there
was a change to the file made by somebody who did't assign the copyright.
What's said in the DCO you cite doesn't help.

Re: Update to GCC copyright assignment policy

[Jason Merrill]

On Tue, Jun 1, 2021 at 10:52 AM D. Hugh Redelmeier <hugh@mimosa.com> wrote:

> | From: Mark Wielaard <mark@klomp.org>
>
> | This seems a pretty bad policy to be honest.
> | Why was there no public discussion on this?
>
> Agreed.  I also agree with the rest of Mark's message.
>
> (Note: I haven't contributed to GCC but I have contributed to other
> copylefted code bases.)
>
> It is important that the pool be trustable.  A tall order, but
> solvable, I think.
>
> Two pools (FSF for old stuff, something else, for new stuff if the
> contributor prefers) should be quite managable.
>
> This would allow, for example, moving to an updated copyleft if the
> two pools agreed.  It is important that the governance of the pool be
> trustable.
>
> We've trusted the FSF and now some have qualms.  A second pool would
> be a check on the power of the first pool.
>
> Individual unassigned copyright pretty much guarantees that the
> copyright terms can never be changed.  I don't think that that is
> optimal.
>

GCC's license is "GPL version 3 or later", so if there ever needed to be a
GPL v4, we could move to it without needing permission from anyone.

But GPL3 has been a good license for GCC; giving up the theoretical ability
to change the license (other than to a later GPL) does not seem like a
significant loss.

Jason

Re: Update to GCC copyright assignment policy

[Jose E. Marchesi]

> GCC was created as part of the GNU Project but has grown to operate as
> an autonomous project.
>
> The GCC Steering Committee has decided to relax the requirement to
> assign copyright for all changes to the Free Software Foundation.  GCC
> will continue to be developed, distributed, and licensed under the GNU
> General Public License v3.0. GCC will now accept contributions with or
> without an FSF copyright assignment. This change is consistent with
> the practices of many other major Free Software projects, such as the
> Linux kernel.
>
> Contributors who have an FSF Copyright Assignment don't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] should add a Signed-off-by message to their commit messages.
> Developers with commit access may add their name to the DCO list in the
> MAINTAINERS file to certify the DCO for all future commits in lieu of individual
> Signed-off-by messages for each commit.
>
> The GCC Steering Committee continues to affirm the principles of Free
> Software, and that will never change.
>
> - The GCC Steering Committee
>
> [1] https://developercertificate.org/

Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only??

Why current contributors (individuals and corporations) have not been
consulted before making and implementing such important decisions?
Corporations like my employer contribute to GCC under a certain legal
setup.  Changing the conditions under which the contributions happen is
not something to be done unilaterally without a very good reason. The
mere fact you have sent this email to a public mailing list means I have
to get my management involved, and most probably lawyers too.

What is the rationale after these changes anyway?

I respectfully ask the GCC Steering Committee to suspend the
implementation of these changes until the rationale and the practical
consequences of changing the GCC contribution model and its license have
been carefully thought, discussed and preferably consensuated among the
GCC contributors and maintainers.

Re: Update to GCC copyright assignment policy

[Paul Koning]

> On Jun 1, 2021, at 11:08 AM, Jason Merrill via Gcc <gcc@gcc.gnu.org> wrote:
> 
> On Tue, Jun 1, 2021 at 10:52 AM D. Hugh Redelmeier <hugh@mimosa.com> wrote:
> 
>> | From: Mark Wielaard <mark@klomp.org>
>> 
>> | This seems a pretty bad policy to be honest.
>> | Why was there no public discussion on this?
>> 
>> Agreed.  I also agree with the rest of Mark's message.
>> 
>> (Note: I haven't contributed to GCC but I have contributed to other
>> copylefted code bases.)
>> 
>> It is important that the pool be trustable.  A tall order, but
>> solvable, I think.
>> 
>> Two pools (FSF for old stuff, something else, for new stuff if the
>> contributor prefers) should be quite managable.
>> 
>> This would allow, for example, moving to an updated copyleft if the
>> two pools agreed.  It is important that the governance of the pool be
>> trustable.
>> 
>> We've trusted the FSF and now some have qualms.  A second pool would
>> be a check on the power of the first pool.
>> 
>> Individual unassigned copyright pretty much guarantees that the
>> copyright terms can never be changed.  I don't think that that is
>> optimal.
>> 
> 
> GCC's license is "GPL version 3 or later", so if there ever needed to be a
> GPL v4, we could move to it without needing permission from anyone.

I don't think that is what the license says.  It says:

GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.

To me that means the recipient of the software can relicense it under a later license.  It doesn't say to me that the original distribution can do so.

	paul

Re: Update to GCC copyright assignment policy

[Jakub Jelinek]

On Tue, Jun 01, 2021 at 11:25:16AM -0400, Paul Koning via Gcc wrote:
> GCC is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 3, or (at your option)
> any later version.
> 
> To me that means the recipient of the software can relicense it under a later license.  It doesn't say to me that the original distribution can do so.

IMHO that can be easily done by changing anything in the file
under GPLv4+ license (if/when it exists).
Because the user can then choose GPLv3+ for most of the source lines,
but only GPLv4+ for those that changed, which implies GPLv4+ for the whole.

	Jakub

Re: Update to GCC copyright assignment policy

[Jonathan Wakely]

> What is the rationale after these changes anyway?

Development of new features for libstdc++ has already moved away from
gcc.gnu.org to avoid the copyright assignment. Other contributors have
expressed a desire to do the same.

Re: Update to GCC copyright assignment policy

[Andrea Corallo]

"Jose E. Marchesi via Gcc" <gcc@gcc.gnu.org> writes:

>> GCC was created as part of the GNU Project but has grown to operate as
>> an autonomous project.
>>
>> The GCC Steering Committee has decided to relax the requirement to
>> assign copyright for all changes to the Free Software Foundation.  GCC
>> will continue to be developed, distributed, and licensed under the GNU
>> General Public License v3.0. GCC will now accept contributions with or
>> without an FSF copyright assignment. This change is consistent with
>> the practices of many other major Free Software projects, such as the
>> Linux kernel.
>>
>> Contributors who have an FSF Copyright Assignment don't need to
>> change anything.  Contributors who wish to utilize the Developer Certificate
>> of Origin[1] should add a Signed-off-by message to their commit messages.
>> Developers with commit access may add their name to the DCO list in the
>> MAINTAINERS file to certify the DCO for all future commits in lieu of individual
>> Signed-off-by messages for each commit.
>>
>> The GCC Steering Committee continues to affirm the principles of Free
>> Software, and that will never change.
>>
>> - The GCC Steering Committee
>>
>> [1] https://developercertificate.org/
>
> Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only??
>
> Why current contributors (individuals and corporations) have not been
> consulted before making and implementing such important decisions?

Can't agree more.  Critiquing FSF for lack of process transparency and
at the same time implementing such a drastic change with zero
involvement of the community sounds bizzarre to me to say the least.

[...]

> I respectfully ask the GCC Steering Committee to suspend the
> implementation of these changes until the rationale and the practical
> consequences of changing the GCC contribution model and its license have
> been carefully thought, discussed and preferably consensuated among the
> GCC contributors and maintainers.

Quote.

Best Regards.

  Andrea

Re: Update to GCC copyright assignment policy

[DJ Delorie]

Paul Koning via Gcc <gcc@gcc.gnu.org> writes:
>> GCC's license is "GPL version 3 or later", so if there ever needed to be a
>> GPL v4, we could move to it without needing permission from anyone.
>
> I don't think that is what the license says.  It says:
>
> GCC is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 3, or (at your option)
> any later version.
>
> To me that means the recipient of the software can relicense it under
> a later license.  It doesn't say to me that the original distribution
> can do so.

I've never read it that way.  To me it says "a recipient may
redistribute it under terms of a newer license, but the license remains
v3+ even if they do" - we're giving the recipient a choice of actions,
but not power to relicense.

I.e. a recipient is not permitted to relicense the code, ever.  However,
they may act as if it's licensed under a newer license.  If they share
the code, *that* recipient gets to make the same choice - v3 or newer.

So if the original copyright holder can't change the license, nobody
can.

Re: Update to GCC copyright assignment policy

[David Edelsohn]

On Tue, Jun 1, 2021 at 11:14 AM Jose E. Marchesi
<jose.marchesi@oracle.com> wrote:
>
>
> > GCC was created as part of the GNU Project but has grown to operate as
> > an autonomous project.
> >
> > The GCC Steering Committee has decided to relax the requirement to
> > assign copyright for all changes to the Free Software Foundation.  GCC
> > will continue to be developed, distributed, and licensed under the GNU
> > General Public License v3.0. GCC will now accept contributions with or
> > without an FSF copyright assignment. This change is consistent with
> > the practices of many other major Free Software projects, such as the
> > Linux kernel.
> >
> > Contributors who have an FSF Copyright Assignment don't need to
> > change anything.  Contributors who wish to utilize the Developer Certificate
> > of Origin[1] should add a Signed-off-by message to their commit messages.
> > Developers with commit access may add their name to the DCO list in the
> > MAINTAINERS file to certify the DCO for all future commits in lieu of individual
> > Signed-off-by messages for each commit.
> >
> > The GCC Steering Committee continues to affirm the principles of Free
> > Software, and that will never change.
> >
> > - The GCC Steering Committee
> >
> > [1] https://developercertificate.org/
>
> Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only??

The current, active license in GPL v3.0.  This is not an announcement
of any change in license.

Quoting Jason Merrill:

"GCC's license is "GPL version 3 or later", so if there ever needed to be a
GPL v4, we could move to it without needing permission from anyone."

Thanks, David

Re: Update to GCC copyright assignment policy

[Maciej W. Rozycki]

On Tue, 1 Jun 2021, Paul Koning via Gcc wrote:

> That seems to create a possible future complication.  Prior to this 
> change, the FSF (as owner of the copyright) could make changes such as 
> replacing the GPL 2 license by GPL 3.  With the policy change, that 
> would no longer be possible, unless you get the approval of all the 
> copyright holders.  This may not be considered a problem, but it does 
> seem like a change.

 It is a real problem.  As I recall a while ago parts of QEMU had to be 
removed and reimplemented from scratch when the project switched licences, 
because a contributor and therefore a copyright holder (whom I knew in 
person and who I am sure would make no fuss about it) has since passed 
away.

  Maciej

Re: Update to GCC copyright assignment policy

[Alfred M. Szmidt]

   > What is the rationale after these changes anyway?

   Development of new features for libstdc++ has already moved away from
   gcc.gnu.org to avoid the copyright assignment. Other contributors have
   expressed a desire to do the same.

From the GCC mission statement:

  - Other components (runtime libraries, testsuites, etc) will be
    available under various free licenses with copyrights being held
    by individual authors or the FSF.

So that cannot be the rationale for this.

Re: Update to GCC copyright assignment policy

[Jason Merrill]

On Tue, Jun 1, 2021 at 11:15 AM Jose E. Marchesi via Gcc <gcc@gcc.gnu.org>
wrote:

>
> > GCC was created as part of the GNU Project but has grown to operate as
> > an autonomous project.
> >
> > The GCC Steering Committee has decided to relax the requirement to
> > assign copyright for all changes to the Free Software Foundation.  GCC
> > will continue to be developed, distributed, and licensed under the GNU
> > General Public License v3.0. GCC will now accept contributions with or
> > without an FSF copyright assignment. This change is consistent with
> > the practices of many other major Free Software projects, such as the
> > Linux kernel.
> >
> > Contributors who have an FSF Copyright Assignment don't need to
> > change anything.  Contributors who wish to utilize the Developer
> Certificate
> > of Origin[1] should add a Signed-off-by message to their commit messages.
> > Developers with commit access may add their name to the DCO list in the
> > MAINTAINERS file to certify the DCO for all future commits in lieu of
> individual
> > Signed-off-by messages for each commit.
> >
> > The GCC Steering Committee continues to affirm the principles of Free
> > Software, and that will never change.
> >
> > - The GCC Steering Committee
> >
> > [1] https://developercertificate.org/
>
> Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only??
>

No, there is no change in the license.


> Why current contributors (individuals and corporations) have not been
> consulted before making and implementing such important decisions?
>
Corporations like my employer contribute to GCC under a certain legal
> setup.

Changing the conditions under which the contributions happen is
> not something to be done unilaterally without a very good reason. The
> mere fact you have sent this email to a public mailing list means I have
> to get my management involved, and most probably lawyers too.
>

Your employer is very welcome to continue to contribute under the same
legal setup.

Derived versions of GCC could already include code that was not assigned to
the FSF; even the official GCC distribution itself has long included
non-FSF-assigned code in various runtime libraries.
The change is that now we will also be able to incorporate such code into
the source code repository for the compiler.

Jason

Re: Update to GCC copyright assignment policy

[Jose E. Marchesi]

>> > GCC was created as part of the GNU Project but has grown to operate as
>> > an autonomous project.
>> >
>> > The GCC Steering Committee has decided to relax the requirement to
>> > assign copyright for all changes to the Free Software Foundation.  GCC
>> > will continue to be developed, distributed, and licensed under the GNU
>> > General Public License v3.0. GCC will now accept contributions with or
>> > without an FSF copyright assignment. This change is consistent with
>> > the practices of many other major Free Software projects, such as the
>> > Linux kernel.
>> >
>> > Contributors who have an FSF Copyright Assignment don't need to
>> > change anything.  Contributors who wish to utilize the Developer Certificate
>> > of Origin[1] should add a Signed-off-by message to their commit messages.
>> > Developers with commit access may add their name to the DCO list in the
>> > MAINTAINERS file to certify the DCO for all future commits in lieu of individual
>> > Signed-off-by messages for each commit.
>> >
>> > The GCC Steering Committee continues to affirm the principles of Free
>> > Software, and that will never change.
>> >
>> > - The GCC Steering Committee
>> >
>> > [1] https://developercertificate.org/
>>
>> Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only??
>
> The current, active license in GPL v3.0.  This is not an announcement
> of any change in license.

Thanks for confirming.

Re: Update to GCC copyright assignment policy

[David Edelsohn]

On Tue, Jun 1, 2021 at 10:40 AM Paul Koning <paulkoning@comcast.net> wrote:
>
> > On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > The copyright author will be listed as "Free Software Foundation,
> > Inc." and/or "The GNU Toolchain Authors", as appropriate.
>
> What does that mean?  FSF is a well defined organization.  "The GNU Toolchain Authors" sounds like one, but is it?  Or is it just a label for "the set of contributors who have contributed without assigning to FSF"?  In other words, who is the owner of such a work, the GTA, or the submitter?  I'm guessing the latter.
>
> That seems to create a possible future complication.  Prior to this change, the FSF (as owner of the copyright) could make changes such as replacing the GPL 2 license by GPL 3.  With the policy change, that would no longer be possible, unless you get the approval of all the copyright holders.  This may not be considered a problem, but it does seem like a change.
>
> I looked at gcc.gnu.org to find the updated policy.  I don't think it's there; the "contribute" page wording still feels like the old policy.  Given the change, it would seem rather important to have the implications spelled out in full, and the new rules clearly expressed.

The GNU Toolchain Authors are all of the authors, including those with
FSF Copyright.  All of the authors agree to the existing license,
which is "...either version 3, or (at your option) any later version."
 If the project chooses to adopt a future update to the GPL, all of
the authors have given permission through the existing copyright
assignment or through certification of the DCO to utilize the newer
license.

Thanks, David

Re: Update to GCC copyright assignment policy

[Paul Smith]

On Tue, 2021-06-01 at 11:50 -0400, David Edelsohn via Gcc wrote:
> The current, active license in GPL v3.0.  This is not an announcement
> of any change in license.
> 
> Quoting Jason Merrill:
> 
> "GCC's license is "GPL version 3 or later", so if there ever needed
> to be a GPL v4, we could move to it without needing permission from
> anyone."

It depends on what you mean by "move to it".

It's true that anyone could redistribute it under GPLv4.

What's not true is that you can *change the license*.  For example you
can't change the current wording of the license from "GPL version 3 or
later" to "GPL version 4 or later".  Or make any other changes to the
license, without collecting approval from all copyright holders.

So, if there should be some issue with GPLv3 so that you really want to
stop using it (maybe a court case is decided which negates a
significant element of GPLv3 and GPLv4 is released to address the
issue), it won't be possible to do that easily.

Someone else mentioned that new code could be released only under that
license so that in effect the entirety of the codebase becomes GPLv4+.

I'm not sure about that.  Doing that for brand new files that were
created solely by one person who wanted to use GPLv4 or later only
would work I suppose.  But adding changes to an existing file that was
GPLv3+ and saying that these new changes are GPLv4+ would be pretty
gross.  You might have to list both licenses in these files, since you
can't change the previously-in-use license unless you get agreement
from the FSF, who currently holds the license, plus anyone else who
changed the file since the assignment was relaxed.

Personally I think that while assignment is a PITA and I wish it were
easier, it is extremely valuable and provides a lot of flexibility, and
shouldn't be abandoned without very, VERY careful consideration.

And, that decision and those considerations should be documented and
the responses to the issues raised here published for everyone to see.

Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Wednesday, June 02, 2021 at 4:01 AM
> From: "Maciej W. Rozycki" <macro@orcam.me.uk>
> To: "Paul Koning" <paulkoning@comcast.net>
> Cc: "Jakub Jelinek" <jakub@redhat.com>, "GCC Development" <gcc@gcc.gnu.org>
> Subject: Re: Update to GCC copyright assignment policy
>
> On Tue, 1 Jun 2021, Paul Koning via Gcc wrote:
>
> > That seems to create a possible future complication.  Prior to this
> > change, the FSF (as owner of the copyright) could make changes such as
> > replacing the GPL 2 license by GPL 3.  With the policy change, that
> > would no longer be possible, unless you get the approval of all the
> > copyright holders.  This may not be considered a problem, but it does
> > seem like a change.
>
>  It is a real problem.  As I recall a while ago parts of QEMU had to be
> removed and reimplemented from scratch when the project switched licences,
> because a contributor and therefore a copyright holder (whom I knew in
> person and who I am sure would make no fuss about it) has since passed
> away.
>
>   Maciej

That assumes that one wants to use the original developer version.  But if a maintainer
wants to include and support that piece of code for some particular reason, he should be
able to do it.  A free software license should not stop us from using the code, whether he
died or not.  Indeed the licensing is there to avoid such problems.  It is also legally
enforceable.  It was one of wy arguments in favour.


----- Christopher Dimech

Society has became too quick to pass judgement and declare someone Persona Non-Grata,
the most extreme form of censure a country can bestow.

In a new era of destructive authoritarianism, I support Richard Stallman.  Times of great
crisis are also times of great opportunity. I call upon you to make this struggle yours as well !

https://stallmansupport.org/     https://www.fsf.org/     https://www.gnu.org/

Re: Update to GCC copyright assignment policy

[Jose E. Marchesi]

>> > GCC was created as part of the GNU Project but has grown to operate as
>> > an autonomous project.
>> >
>> > The GCC Steering Committee has decided to relax the requirement to
>> > assign copyright for all changes to the Free Software Foundation.  GCC
>> > will continue to be developed, distributed, and licensed under the GNU
>> > General Public License v3.0. GCC will now accept contributions with or
>> > without an FSF copyright assignment. This change is consistent with
>> > the practices of many other major Free Software projects, such as the
>> > Linux kernel.
>> >
>> > Contributors who have an FSF Copyright Assignment don't need to
>> > change anything.  Contributors who wish to utilize the Developer
>> Certificate
>> > of Origin[1] should add a Signed-off-by message to their commit messages.
>> > Developers with commit access may add their name to the DCO list in the
>> > MAINTAINERS file to certify the DCO for all future commits in lieu of
>> individual
>> > Signed-off-by messages for each commit.
>> >
>> > The GCC Steering Committee continues to affirm the principles of Free
>> > Software, and that will never change.
>> >
>> > - The GCC Steering Committee
>> >
>> > [1] https://developercertificate.org/
>>
>> Eer, so you are changing the license of GCC from GPLv3+ to GPLv3 only??
>>
>
> No, there is no change in the license.

Ok, then please consider changing

  "GCC will continue to be developed, distributed, and licensed under
   the GNU General Public License v3.0"

to

  "GCC will continue to be developed, distributed, and licensed under
   the GNU General Public License v3.0 or any later version as published
   by the Free Software Foundation."

in your announcement (in case you are publishing it somewhere else) to
avoid misunderstandings.

Re: Update to GCC copyright assignment policy

[Maciej W. Rozycki]

On Tue, 1 Jun 2021, DJ Delorie via Gcc wrote:

> > GCC is free software; you can redistribute it and/or modify
> > it under the terms of the GNU General Public License as published by
> > the Free Software Foundation; either version 3, or (at your option)
> > any later version.
> >
> > To me that means the recipient of the software can relicense it under
> > a later license.  It doesn't say to me that the original distribution
> > can do so.
> 
> I've never read it that way.  To me it says "a recipient may
> redistribute it under terms of a newer license, but the license remains
> v3+ even if they do" - we're giving the recipient a choice of actions,
> but not power to relicense.

 My interpretation of this would be for modifications rather than original 
sources, so v3+ applies to unmodified sources (for obvious reasons, given 
that the recipient of the sources is not a copyright holder), however as a 
copyright holder I can release my modifications say under v4 or v4+.  It 
is unclear to me if the newer licence will then "stick" to the rest of the 
sources, but I suspect it will.  A copyright assignment made to FSF (or 
another legal entity) prevents this complication from happening.

  Maciej

Re: Update to GCC copyright assignment policy

[Maciej W. Rozycki]

On Tue, 1 Jun 2021, Christopher Dimech wrote:

> >  It is a real problem.  As I recall a while ago parts of QEMU had to be
> > removed and reimplemented from scratch when the project switched licences,
> > because a contributor and therefore a copyright holder (whom I knew in
> > person and who I am sure would make no fuss about it) has since passed
> > away.
> 
> That assumes that one wants to use the original developer version.  But if a maintainer
> wants to include and support that piece of code for some particular reason, he should be
> able to do it.  A free software license should not stop us from using the code, whether he
> died or not.  Indeed the licensing is there to avoid such problems.  It is also legally
> enforceable.  It was one of wy arguments in favour.

 You can use and modify original code under the terms of the original 
licence (provided it permitted it), but you cannot change the licence, 
because you are not a copyright holder for that piece of code.

  Maciej

Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Wednesday, June 02, 2021 at 4:09 AM
> From: "Paul Smith" <paul@mad-scientist.net>
> To: gcc@gcc.gnu.org
> Subject: Re: Update to GCC copyright assignment policy
>
> On Tue, 2021-06-01 at 11:50 -0400, David Edelsohn via Gcc wrote:
> > The current, active license in GPL v3.0.  This is not an announcement
> > of any change in license.
> >
> > Quoting Jason Merrill:
> >
> > "GCC's license is "GPL version 3 or later", so if there ever needed
> > to be a GPL v4, we could move to it without needing permission from
> > anyone."
>
> It depends on what you mean by "move to it".
>
> It's true that anyone could redistribute it under GPLv4.
>
> What's not true is that you can *change the license*.  For example you
> can't change the current wording of the license from "GPL version 3 or
> later" to "GPL version 4 or later".  Or make any other changes to the
> license, without collecting approval from all copyright holders.
>
> So, if there should be some issue with GPLv3 so that you really want to
> stop using it (maybe a court case is decided which negates a
> significant element of GPLv3 and GPLv4 is released to address the
> issue), it won't be possible to do that easily.
>
> Someone else mentioned that new code could be released only under that
> license so that in effect the entirety of the codebase becomes GPLv4+.
>
> I'm not sure about that.  Doing that for brand new files that were
> created solely by one person who wanted to use GPLv4 or later only
> would work I suppose.  But adding changes to an existing file that was
> GPLv3+ and saying that these new changes are GPLv4+ would be pretty
> gross.  You might have to list both licenses in these files, since you
> can't change the previously-in-use license unless you get agreement
> from the FSF, who currently holds the license, plus anyone else who
> changed the file since the assignment was relaxed.

You can actually re-license with another compatible license.
GPLv3+ would allow you to re-license the code as GPLv4+

You do not have to keep all the previous licenses because the intention of the
gpl is to give back to users those rights which copyright would otherwise withold.

> Personally I think that while assignment is a PITA and I wish it were
> easier, it is extremely valuable and provides a lot of flexibility, and
> shouldn't be abandoned without very, VERY careful consideration.
>
> And, that decision and those considerations should be documented and
> the responses to the issues raised here published for everyone to see.
>


----- Christopher Dimech

Society has became too quick to pass judgement and declare someone Persona Non-Grata,
the most extreme form of censure a country can bestow.

In a new era of destructive authoritarianism, I support Richard Stallman.  Times of great
crisis are also times of great opportunity. I call upon you to make this struggle yours as well !

https://stallmansupport.org/     https://www.fsf.org/     https://www.gnu.org/

Re: Update to GCC copyright assignment policy

[Jonathan Wakely]

> So that cannot be the rationale for this.

I do not want to contribute my work to a project that requires FSF
copyright assignment to the rest of the project, even if it wouldn't
be required for (some of) my own contributions. In any case,
historically libstdc++ *does* require an assignment. If you were even
slightly familiar with the project you might know that.

Re: Update to GCC copyright assignment policy

[Alfred M. Szmidt]

   But GPL3 has been a good license for GCC; giving up the theoretical ability
   to change the license (other than to a later GPL) does not seem like a
   significant loss.

That will cause trouble incorperating code or documentation snippets
from the code base into the GCC manual; which is not under the GNU
GPL.  As it is, the FSF can and does give such permission to relicense
bits and bobs -- now you've entierly lost that ability.

The other loss is that parts cannot be relicensed under say the Lesser
GPL for whatever reasons, incase a library might be more useful
outside of GCC.  The FSF has always been open to create special
exemptions to the copyright assignment process.

This is just all ill thought, and clearly shown by the lack of any
discussion with anyone.

Re: Update to GCC copyright assignment policy

[DJ Delorie]

"Maciej W. Rozycki" <macro@orcam.me.uk> writes:
>  My interpretation of this would be for modifications rather than original 
> sources, so v3+ applies to unmodified sources (for obvious reasons, given 
> that the recipient of the sources is not a copyright holder), however as a 
> copyright holder I can release my modifications say under v4 or v4+.  It 
> is unclear to me if the newer licence will then "stick" to the rest of the 
> sources, but I suspect it will.  A copyright assignment made to FSF (or 
> another legal entity) prevents this complication from happening.

I see two cases here:

1. You release a modified copy of gcc, your parts can be whatever you
   want, sure, as long as it's GPLv3 compatible.

2. You're contributing *to* gcc, in which case, I'd hope that any
   attempts to impose a different license would be rejected at the patch
   review step.

Re: Update to GCC copyright assignment policy

[Paul Koning]

> On Jun 1, 2021, at 12:09 PM, David Edelsohn via Gcc <gcc@gcc.gnu.org> wrote:
> 
> On Tue, Jun 1, 2021 at 10:40 AM Paul Koning <paulkoning@comcast.net> wrote:
>> 
>>> On Jun 1, 2021, at 10:31 AM, David Edelsohn via Gcc <gcc@gcc.gnu.org> wrote:
>>> 
>>> The copyright author will be listed as "Free Software Foundation,
>>> Inc." and/or "The GNU Toolchain Authors", as appropriate.
>> 
>> What does that mean?  FSF is a well defined organization.  "The GNU Toolchain Authors" sounds like one, but is it?  Or is it just a label for "the set of contributors who have contributed without assigning to FSF"?  In other words, who is the owner of such a work, the GTA, or the submitter?  I'm guessing the latter.
>> 
>> That seems to create a possible future complication.  Prior to this change, the FSF (as owner of the copyright) could make changes such as replacing the GPL 2 license by GPL 3.  With the policy change, that would no longer be possible, unless you get the approval of all the copyright holders.  This may not be considered a problem, but it does seem like a change.
>> 
>> I looked at gcc.gnu.org to find the updated policy.  I don't think it's there; the "contribute" page wording still feels like the old policy.  Given the change, it would seem rather important to have the implications spelled out in full, and the new rules clearly expressed.
> 
> The GNU Toolchain Authors are all of the authors, including those with
> FSF Copyright.  All of the authors agree to the existing license,
> which is "...either version 3, or (at your option) any later version."
> If the project chooses to adopt a future update to the GPL, all of
> the authors have given permission through the existing copyright
> assignment or through certification of the DCO to utilize the newer
> license.
> 
> Thanks, David

By DCO do you mean the document you linked in your original annoucement?  If yes, could you point out which of the words in that document give the GCC project permission from the copyright holder to relicense the contributed work?  I do not see those words in the document you linked.

I get the feeling that the current change was rushed and not well considered.  It certainly has that feel.  I do not remember discussion of it, I do not see updated policy documents on the gcc.gnu.org website.  The discussion just now is raising a pile of questions which are being answered with a whole bunch of different answers, not all consistent with each other.  If the change had been carefully made this would not be happening; there would instead be a known answer (the outcome of prior discussion) and there would be published policies that could be pointed to where those answers are explicitly stated.

It's not that I object to the spirit of the change, and I have contributed to a number of open source projects where there is no copyright assignment so that isn't a strange thing to me.  What concerns me is a disruptive change made with what seems to me to be inadequate care.

	paul

Re: Update to GCC copyright assignment policy

[Joseph Myers]

On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote:

> The copyright author will be listed as "Free Software Foundation,
> Inc." and/or "The GNU Toolchain Authors", as appropriate.

And copyright notices naming "The GNU Toolchain Authors" should not 
include a date - that's following the recommendations at 
https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/ 
for the form of copyright notices in projects with many copyright holders.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Update to GCC copyright assignment policy

[Paul Koning]

> On Jun 1, 2021, at 12:44 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote:
> 
>> The copyright author will be listed as "Free Software Foundation,
>> Inc." and/or "The GNU Toolchain Authors", as appropriate.
> 
> And copyright notices naming "The GNU Toolchain Authors" should not 
> include a date - that's following the recommendations at 
> https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/ 
> for the form of copyright notices in projects with many copyright holders.
> 
> -- 
> Joseph S. Myers
> joseph@codesourcery.com

That's a nice document, but it makes clear that a collective designation of a group of authors in a copyright notice is just a convenient shorthand.  It mentions that the copyright notice is just a notice that doesn't actually affect the copyright (which remains with the individual authors or their employers, unless assigned).  So "GNU Toolchain Authors" is a description referring to a set of individual owners, one that changes over time.  It doesn't describe a legal body, and it isn't an owner of anything.

	paul

Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Wednesday, June 02, 2021 at 4:24 AM
> From: "Maciej W. Rozycki" <macro@orcam.me.uk>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Paul Koning" <paulkoning@comcast.net>, "Jakub Jelinek" <jakub@redhat.com>, "GCC Development" <gcc@gcc.gnu.org>
> Subject: Re: Update to GCC copyright assignment policy
>
> On Tue, 1 Jun 2021, Christopher Dimech wrote:
>
> > >  It is a real problem.  As I recall a while ago parts of QEMU had to be
> > > removed and reimplemented from scratch when the project switched licences,
> > > because a contributor and therefore a copyright holder (whom I knew in
> > > person and who I am sure would make no fuss about it) has since passed
> > > away.
> >
> > That assumes that one wants to use the original developer version.  But if a maintainer
> > wants to include and support that piece of code for some particular reason, he should be
> > able to do it.  A free software license should not stop us from using the code, whether he
> > died or not.  Indeed the licensing is there to avoid such problems.  It is also legally
> > enforceable.  It was one of wy arguments in favour.
>
>  You can use and modify original code under the terms of the original
> licence (provided it permitted it), but you cannot change the licence,
> because you are not a copyright holder for that piece of code.
>
>   Maciej


You can change it as much as the license allows you.  The gpl is intended to give you
back all the rights taken from you by copyright.  Thusly, you are not restricted
by anyone because they have the copyright of the original work.  It's important that
you understand this.

Update to GCC copyright assignment policy

[Christopher Dimech]

A file should be kept with the author name, date and changes done by each contributor.

Including this is the source code would make the history too long.  Otherwise, such information
can be put at the end of the file.

----- Christopher Dimech

Society has became too quick to pass judgement and declare someone Persona Non-Grata,
the most extreme form of censure a country can bestow.

In a new era of destructive authoritarianism, I support Richard Stallman.  Times of great
crisis are also times of great opportunity. I call upon you to make this struggle yours as well !

https://stallmansupport.org/     https://www.fsf.org/     https://www.gnu.org/


> Sent: Wednesday, June 02, 2021 at 4:44 AM
> From: "Joseph Myers" <joseph@codesourcery.com>
> To: "David Edelsohn" <dje.gcc@gmail.com>
> Cc: "Jakub Jelinek" <jakub@redhat.com>, "GCC Development" <gcc@gcc.gnu.org>
> Subject: Re: Update to GCC copyright assignment policy
>
> On Tue, 1 Jun 2021, David Edelsohn via Gcc wrote:
>
> > The copyright author will be listed as "Free Software Foundation,
> > Inc." and/or "The GNU Toolchain Authors", as appropriate.
>
> And copyright notices naming "The GNU Toolchain Authors" should not
> include a date - that's following the recommendations at
> https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/
> for the form of copyright notices in projects with many copyright holders.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

[PATCH] MAINTAINERS: create DCO section; add myself to it

[David Malcolm]

On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote:
> GCC was created as part of the GNU Project but has grown to operate
> as
> an autonomous project.
> 
> The GCC Steering Committee has decided to relax the requirement to
> assign copyright for all changes to the Free Software Foundation. 
> GCC
> will continue to be developed, distributed, and licensed under the
> GNU
> General Public License v3.0. GCC will now accept contributions with
> or
> without an FSF copyright assignment. This change is consistent with
> the practices of many other major Free Software projects, such as the
> Linux kernel.
> 
> Contributors who have an FSF Copyright Assignment don't need to
> change anything.  Contributors who wish to utilize the Developer
> Certificate
> of Origin[1] should add a Signed-off-by message to their commit
> messages.
> Developers with commit access may add their name to the DCO list in
> the
> MAINTAINERS file to certify the DCO for all future commits in lieu of
> individual
> Signed-off-by messages for each commit.
> 
> The GCC Steering Committee continues to affirm the principles of Free
> Software, and that will never change.
> 
> - The GCC Steering Committee
> 
> [1] https://developercertificate.org/
> 

The MAINTAINERS file doesn't seem to have such a "DCO list"
yet; does the following patch look like what you had in mind?

ChangeLog

	* MAINTAINERS: Create DCO section; add myself to it.
---
 MAINTAINERS | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index db25583b37b..1148e0915cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -685,3 +685,15 @@ Josef Zlomek					<josef.zlomek@email.cz>
 James Dennett					<jdennett@acm.org>
 Christian Ehrhardt				<ehrhardt@mathematik.uni-ulm.de>
 Dara Hazeghi					<dhazeghi@yahoo.com>
+
+
+DCO
+===
+
+Developers with commit access may add their name to the following list
+to certify the DCO (https://developercertificate.org/) for all
+future commits in lieu of individual Signed-off-by messages for each commit.
+
+			DCO list		(last name alphabetical order)
+
+David Malcolm					<dmalcolm@redhat.com>
-- 
2.26.3

Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Wednesday, June 02, 2021 at 4:20 AM
> From: "Maciej W. Rozycki" <macro@orcam.me.uk>
> To: "DJ Delorie" <dj@redhat.com>
> Cc: "Paul Koning" <paulkoning@comcast.net>, gcc@gcc.gnu.org
> Subject: Re: Update to GCC copyright assignment policy
>
> On Tue, 1 Jun 2021, DJ Delorie via Gcc wrote:
>
> > > GCC is free software; you can redistribute it and/or modify
> > > it under the terms of the GNU General Public License as published by
> > > the Free Software Foundation; either version 3, or (at your option)
> > > any later version.
> > >
> > > To me that means the recipient of the software can relicense it under
> > > a later license.  It doesn't say to me that the original distribution
> > > can do so.
> >
> > I've never read it that way.  To me it says "a recipient may
> > redistribute it under terms of a newer license, but the license remains
> > v3+ even if they do" - we're giving the recipient a choice of actions,
> > but not power to relicense.
>
>  My interpretation of this would be for modifications rather than original
> sources, so v3+ applies to unmodified sources (for obvious reasons, given
> that the recipient of the sources is not a copyright holder), however as a
> copyright holder I can release my modifications say under v4 or v4+.  It
> is unclear to me if the newer licence will then "stick" to the rest of the
> sources, but I suspect it will.  A copyright assignment made to FSF (or
> another legal entity) prevents this complication from happening.
>
>   Maciej

No.  What the copyright holder can do is the re-license by any other license
he wants (even proprietary).  But you can't !!!  That's the basic difference.


----- Christopher Dimech

Society has became too quick to pass judgement and declare someone Persona Non-Grata,
the most extreme form of censure a country can bestow.

In a new era of destructive authoritarianism, I support Richard Stallman.  Times of great
crisis are also times of great opportunity. I call upon you to make this struggle yours as well !

https://stallmansupport.org/     https://www.fsf.org/     https://www.gnu.org/

Re: [PATCH] MAINTAINERS: create DCO section; add myself to it

[Richard Biener]

On June 1, 2021 7:30:54 PM GMT+02:00, David Malcolm via Gcc <gcc@gcc.gnu.org> wrote:
>On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote:
>> GCC was created as part of the GNU Project but has grown to operate
>> as
>> an autonomous project.
>> 
>> The GCC Steering Committee has decided to relax the requirement to
>> assign copyright for all changes to the Free Software Foundation. 
>> GCC
>> will continue to be developed, distributed, and licensed under the
>> GNU
>> General Public License v3.0. GCC will now accept contributions with
>> or
>> without an FSF copyright assignment. This change is consistent with
>> the practices of many other major Free Software projects, such as the
>> Linux kernel.
>> 
>> Contributors who have an FSF Copyright Assignment don't need to
>> change anything.  Contributors who wish to utilize the Developer
>> Certificate
>> of Origin[1] should add a Signed-off-by message to their commit
>> messages.
>> Developers with commit access may add their name to the DCO list in
>> the
>> MAINTAINERS file to certify the DCO for all future commits in lieu of
>> individual
>> Signed-off-by messages for each commit.
>> 
>> The GCC Steering Committee continues to affirm the principles of Free
>> Software, and that will never change.
>> 
>> - The GCC Steering Committee
>> 
>> [1] https://developercertificate.org/
>> 
>
>The MAINTAINERS file doesn't seem to have such a "DCO list"
>yet; does the following patch look like what you had in mind?
>
>ChangeLog
>
>	* MAINTAINERS: Create DCO section; add myself to it.
>---
> MAINTAINERS | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index db25583b37b..1148e0915cf 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -685,3 +685,15 @@ Josef Zlomek					<josef.zlomek@email.cz>
> James Dennett					<jdennett@acm.org>
> Christian Ehrhardt				<ehrhardt@mathematik.uni-ulm.de>
> Dara Hazeghi					<dhazeghi@yahoo.com>
>+
>+
>+DCO
>+===
>+
>+Developers with commit access may add their name to the following list
>+to certify the DCO (https://developercertificate.org/) for all

There should be a verbatim copy of the DCO in this file or the repository. 

>+future commits in lieu of individual Signed-off-by messages for each
>commit.
>+
>+			DCO list		(last name alphabetical order)
>+
>+David Malcolm					<dmalcolm@redhat.com>

Re: Update to GCC copyright assignment policy

[Thomas Rodgers]

On 2021-06-01 07:28, Mark Wielaard wrote:

> Hi David,
> 
> On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote:
> 
>> The GCC Steering Committee has decided to relax the requirement to
>> assign copyright for all changes to the Free Software Foundation.  GCC
>> will continue to be developed, distributed, and licensed under the GNU
>> General Public License v3.0. GCC will now accept contributions with or
>> without an FSF copyright assignment. This change is consistent with
>> the practices of many other major Free Software projects, such as the
>> Linux kernel.
>> 
>> Contributors who have an FSF Copyright Assignment don't need to
>> change anything.  Contributors who wish to utilize the Developer 
>> Certificate
>> of Origin[1] should add a Signed-off-by message to their commit 
>> messages.
>> Developers with commit access may add their name to the DCO list in 
>> the
>> MAINTAINERS file to certify the DCO for all future commits in lieu of 
>> individual
>> Signed-off-by messages for each commit.
> 
> This seems a pretty bad policy to be honest.
> Why was there no public discussion on this?
> 
> I certainly understand not wanting to assign copyright to the FSF
> anymore given the recent board decisions. But changing GCC from having
> a shared copyright pool to having lots of individual (or company?)
> copyright holders seems like a regression for a strong copyleft
> project.
> 
> With individual copyright holders companies no longer have clear way to
> know whether they are in compliance unless they talk to each and every
> individual copyright holder (see also the linux kernel, where there are
> some individuals who randomly sue companies just to get some money to
> drop the lawsuit). And for users it will be harder to get compliant
> sources if they can no longer simply ask the shared copyright holder,
> but instead will have to get enough individual copyright holders to get
> a distributor into compliance.
> 
> If we no longer want the FSF to be the legal guardian and copyright
> holder for GCC could we please find another legal entity that performs
> that role and helps us as a project with copyleft compliance?

Personally, this would have been my preference.

> I would be happy to setup a shared copyright pool under the Conservancy
> Copyleft Compliance project for example:
> https://sfconservancy.org/copyleft-compliance/
> 
> Thanks,
> 
> Mark

Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Wednesday, June 02, 2021 at 7:58 AM
> From: "Thomas Rodgers" <rodgert@appliantology.com>
> To: "Mark Wielaard" <mark@klomp.org>
> Cc: "GCC Development" <gcc@gcc.gnu.org>
> Subject: Re: Update to GCC copyright assignment policy
>
> On 2021-06-01 07:28, Mark Wielaard wrote:
>
> > Hi David,
> >
> > On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote:
> >
> >> The GCC Steering Committee has decided to relax the requirement to
> >> assign copyright for all changes to the Free Software Foundation.  GCC
> >> will continue to be developed, distributed, and licensed under the GNU
> >> General Public License v3.0. GCC will now accept contributions with or
> >> without an FSF copyright assignment. This change is consistent with
> >> the practices of many other major Free Software projects, such as the
> >> Linux kernel.
> >>
> >> Contributors who have an FSF Copyright Assignment don't need to
> >> change anything.  Contributors who wish to utilize the Developer
> >> Certificate
> >> of Origin[1] should add a Signed-off-by message to their commit
> >> messages.
> >> Developers with commit access may add their name to the DCO list in
> >> the
> >> MAINTAINERS file to certify the DCO for all future commits in lieu of
> >> individual
> >> Signed-off-by messages for each commit.
> >
> > This seems a pretty bad policy to be honest.
> > Why was there no public discussion on this?
> >
> > I certainly understand not wanting to assign copyright to the FSF
> > anymore given the recent board decisions. But changing GCC from having
> > a shared copyright pool to having lots of individual (or company?)
> > copyright holders seems like a regression for a strong copyleft
> > project.
> >
> > With individual copyright holders companies no longer have clear way to
> > know whether they are in compliance unless they talk to each and every
> > individual copyright holder (see also the linux kernel, where there are
> > some individuals who randomly sue companies just to get some money to
> > drop the lawsuit). And for users it will be harder to get compliant
> > sources if they can no longer simply ask the shared copyright holder,
> > but instead will have to get enough individual copyright holders to get
> > a distributor into compliance.
> >
> > If we no longer want the FSF to be the legal guardian and copyright
> > holder for GCC could we please find another legal entity that performs
> > that role and helps us as a project with copyleft compliance?
>
> Personally, this would have been my preference.

One thing to consider is whether there exists any legal expertise for this.
This obsession of GCC to disassociate from the FSF is unskilled and unnecessary.
Much effort should rather be put upon doing real work, opposing the European Union
Directive on Copyright in the Digital Single Market that came into force on 7 June
2019.

> > I would be happy to setup a shared copyright pool under the Conservancy
> > Copyleft Compliance project for example:
> > https://sfconservancy.org/copyleft-compliance/
> >
> > Thanks,
> >
> > Mark

----- Christopher Dimech

Society has became too quick to pass judgement and declare someone Persona Non-Grata,
the most extreme form of censure a country can bestow.

In a new era of destructive authoritarianism, I support Richard Stallman.  Times of great
crisis are also times of great opportunity. I call upon you to make this struggle yours as well !

https://stallmansupport.org/     https://www.fsf.org/     https://www.gnu.org/

Re: Update to GCC copyright assignment policy

[Eric Gallager]

On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc <gcc@gcc.gnu.org> wrote:
>
> GCC was created as part of the GNU Project but has grown to operate as
> an autonomous project.
>
> The GCC Steering Committee has decided to relax the requirement to
> assign copyright for all changes to the Free Software Foundation.  GCC
> will continue to be developed, distributed, and licensed under the GNU
> General Public License v3.0. GCC will now accept contributions with or
> without an FSF copyright assignment. This change is consistent with
> the practices of many other major Free Software projects, such as the
> Linux kernel.
>
> Contributors who have an FSF Copyright Assignment don't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] should add a Signed-off-by message to their commit messages.
> Developers with commit access may add their name to the DCO list in the
> MAINTAINERS file to certify the DCO for all future commits in lieu of individual
> Signed-off-by messages for each commit.
>
> The GCC Steering Committee continues to affirm the principles of Free
> Software, and that will never change.
>
> - The GCC Steering Committee
>
> [1] https://developercertificate.org/

One thing I'm wondering about this change is if it allows certain old
changes that previously couldn't be upstreamed to now be upstreamed?
For example, when I have asked about trying to forward-port certain
changes from Apple's old gcc-4.2 branch, I was told that one reason
this couldn't happen was because Apple hadn't assigned copyright for
those changes. Of course, there are still the technical difficulties
of the fact that 4.2 has bitrotted considerably in the years since its
last release, but regardless of those, are the legal difficulties at
least now out of the way?
Thanks,
Eric Gallager

Re: Update to GCC copyright assignment policy

[Jeff Law]

On 6/1/2021 5:22 PM, Eric Gallager via Gcc wrote:
> On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc <gcc@gcc.gnu.org> wrote:
>> GCC was created as part of the GNU Project but has grown to operate as
>> an autonomous project.
>>
>> The GCC Steering Committee has decided to relax the requirement to
>> assign copyright for all changes to the Free Software Foundation.  GCC
>> will continue to be developed, distributed, and licensed under the GNU
>> General Public License v3.0. GCC will now accept contributions with or
>> without an FSF copyright assignment. This change is consistent with
>> the practices of many other major Free Software projects, such as the
>> Linux kernel.
>>
>> Contributors who have an FSF Copyright Assignment don't need to
>> change anything.  Contributors who wish to utilize the Developer Certificate
>> of Origin[1] should add a Signed-off-by message to their commit messages.
>> Developers with commit access may add their name to the DCO list in the
>> MAINTAINERS file to certify the DCO for all future commits in lieu of individual
>> Signed-off-by messages for each commit.
>>
>> The GCC Steering Committee continues to affirm the principles of Free
>> Software, and that will never change.
>>
>> - The GCC Steering Committee
>>
>> [1] https://developercertificate.org/
> One thing I'm wondering about this change is if it allows certain old
> changes that previously couldn't be upstreamed to now be upstreamed?
> For example, when I have asked about trying to forward-port certain
> changes from Apple's old gcc-4.2 branch, I was told that one reason
> this couldn't happen was because Apple hadn't assigned copyright for
> those changes. Of course, there are still the technical difficulties
> of the fact that 4.2 has bitrotted considerably in the years since its
> last release, but regardless of those, are the legal difficulties at
> least now out of the way?
Read the DCO.   If you can satisfy the terms of the DCO, then yes it 
would help.  But DCO still has requirements that may not be easily met 
unless you are the author or know the author and can communicate with them.

jeff

Re: Update to GCC copyright assignment policy

[Mark Wielaard]

On Tue, Jun 01, 2021 at 11:05:24AM -0400, Richard Kenner wrote:
> > > What about the parts of GCC with FSF copyrights that are not covered by
> > > the GPL, but the GPL with exceptions?  How is it possible to move code
> > > between the parts if a contributor previously used DCO and thus gave
> > > only permission to license under the open source license "indicated in
> > > the file"?
> > 
> > Depends on which DCO you uses. Various project use the following DCO,
> > which makes clear you assign permissions under all applicable licenses
> > (this helps if the project uses more than one, possibly incompatible,
> > license and/or is dual licensed):
> 
> See above.  The issue is if the project wants to change the status of
> a file from GPL to GPL plus exception.  It can't do that if there
> was a change to the file made by somebody who did't assign the copyright.
> What's said in the DCO you cite doesn't help.

Right. The point wasn't so much as "here is the perfect DCO", but more
that the DCO as used for the linux kernel project might not be the
best for the GCC project given that GCC is not really a monolitic
project, but a collection of compiler/runtime modules each with their
own licence/exeception statements. So we might need tweaks for the
specific way we reuse code between modules. Or when using GPLed code
in the GFDLed manual.

Another example of a developer certificate of origin, which again
isn't a perfect fit for GCC, but which shows another way to handle
multiple licenses is the Samba one:
https://www.samba.org/samba/devel/copyright-policy.html

Cheers,

Mark

Re: Update to GCC copyright assignment policy

[Mark Wielaard]

Hi Thomas,

On Tue, Jun 01, 2021 at 12:58:12PM -0700, Thomas Rodgers wrote:
> On 2021-06-01 07:28, Mark Wielaard wrote:
> > If we no longer want the FSF to be the legal guardian and copyright
> > holder for GCC could we please find another legal entity that performs
> > that role and helps us as a project with copyleft compliance?
> 
> Personally, this would have been my preference.
> 
> > I would be happy to setup a shared copyright pool under the Conservancy
> > Copyleft Compliance project for example:
> > https://sfconservancy.org/copyleft-compliance/

It isn't too late to start discussing this as alternative. As far as I
understand the SC hasn't talked to the Conservancy yet. But the
Conservancy is happy to share their knowledge and discuss policy
issues with the GCC community if we decide we want their input.

Cheers,

Mark

Re: Update to GCC copyright assignment policy

[Jason Merrill]

On Wed, Jun 2, 2021 at 4:10 AM Mark Wielaard <mark@klomp.org> wrote:

> On Tue, Jun 01, 2021 at 11:05:24AM -0400, Richard Kenner wrote:
> > > > What about the parts of GCC with FSF copyrights that are not covered
> by
> > > > the GPL, but the GPL with exceptions?  How is it possible to move
> code
> > > > between the parts if a contributor previously used DCO and thus gave
> > > > only permission to license under the open source license "indicated
> in
> > > > the file"?
> > >
> > > Depends on which DCO you uses. Various project use the following DCO,
> > > which makes clear you assign permissions under all applicable licenses
> > > (this helps if the project uses more than one, possibly incompatible,
> > > license and/or is dual licensed):
> >
> > See above.  The issue is if the project wants to change the status of
> > a file from GPL to GPL plus exception.  It can't do that if there
> > was a change to the file made by somebody who did't assign the copyright.
> > What's said in the DCO you cite doesn't help.
>
> Right. The point wasn't so much as "here is the perfect DCO", but more
> that the DCO as used for the linux kernel project might not be the
> best for the GCC project given that GCC is not really a monolitic
> project, but a collection of compiler/runtime modules each with their
> own licence/exeception statements. So we might need tweaks for the
> specific way we reuse code between modules. Or when using GPLed code
> in the GFDLed manual.
>

This all seems much more of a theoretical issue than a practical one.  We
don't reuse code between the compiler and the runtimes, and the runtimes
are all either GPL3+GCC Runtime Exception or under a permissive license, so
moving code between them isn't a problem.  As far as I know, we have never
asked the FSF to relicense anything since the GPL3 move except for the
target macro documentation strings, which are easily handled by changing
them in both places at once.

Jason

Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Thursday, June 03, 2021 at 2:36 AM
> From: "Jason Merrill via Gcc" <gcc@gcc.gnu.org>
> To: "Mark Wielaard" <mark@klomp.org>
> Cc: "Florian Weimer" <fweimer@redhat.com>, "gcc Mailing List" <gcc@gcc.gnu.org>
> Subject: Re: Update to GCC copyright assignment policy
>
> On Wed, Jun 2, 2021 at 4:10 AM Mark Wielaard <mark@klomp.org> wrote:
>
> > On Tue, Jun 01, 2021 at 11:05:24AM -0400, Richard Kenner wrote:
> > > > > What about the parts of GCC with FSF copyrights that are not covered
> > by
> > > > > the GPL, but the GPL with exceptions?  How is it possible to move
> > code
> > > > > between the parts if a contributor previously used DCO and thus gave
> > > > > only permission to license under the open source license "indicated
> > in
> > > > > the file"?
> > > >
> > > > Depends on which DCO you uses. Various project use the following DCO,
> > > > which makes clear you assign permissions under all applicable licenses
> > > > (this helps if the project uses more than one, possibly incompatible,
> > > > license and/or is dual licensed):
> > >
> > > See above.  The issue is if the project wants to change the status of
> > > a file from GPL to GPL plus exception.  It can't do that if there
> > > was a change to the file made by somebody who did't assign the copyright.
> > > What's said in the DCO you cite doesn't help.
> >
> > Right. The point wasn't so much as "here is the perfect DCO", but more
> > that the DCO as used for the linux kernel project might not be the
> > best for the GCC project given that GCC is not really a monolitic
> > project, but a collection of compiler/runtime modules each with their
> > own licence/exeception statements. So we might need tweaks for the
> > specific way we reuse code between modules. Or when using GPLed code
> > in the GFDLed manual.
> >
>
> This all seems much more of a theoretical issue than a practical one.  We
> don't reuse code between the compiler and the runtimes, and the runtimes
> are all either GPL3+GCC Runtime Exception or under a permissive license, so
> moving code between them isn't a problem.  As far as I know, we have never
> asked the FSF to relicense anything since the GPL3 move except for the
> target macro documentation strings, which are easily handled by changing
> them in both places at once.
>
> Jason

In my experience, the theoretical problem you claim is a real problem.  When
everything is assigned to the FSF any technical use problems (license compatibility)
could be legally solved very simply by re-licensing to whatever is appropriate
because the FSF owned the copyright.

With the change, contributors got to be extremely careful on how they use and
license code.  And it is very easy for people to screw things up for them and others.

Computer Science schools continue to produce graduates lacking practice competency and
new skills required in using legal instruments in the market economy.  And I have seen
lawyers that spent the bulk of their practice years with technology, yet continue
to suffer from hangovers that are the residual of a professional life spent primarily
among other lawyers who practiced in a different era.

Be prepared for a lot of trouble if you want developers to handle licensing independently.
My recommendation has been to continue with the current system of copyright assignment
to a single entity.  And only allow the use of additional contributions for unique and
special situations that arise.  Because there could be a time where you would not be
able to use that piece of code.  The biggest problem is loosing the right to distribution.
The distribution right is problematic in all sorts of ways.  You would then need to re-code
a lot of things again.  That has happened to me before.

So I would say that if you can transfer the copyright, do it.

----- Christopher Dimech

Society has become too quick to pass judgement and declare someone
Persona Non-Grata, the most extreme form of censure a country can
bestow.

In a new era of destructive authoritarianism, I support Richard
Stallman.  Times of great crisis are also times of great
opportunity.  I call upon you to make this struggle yours as well !

https://stallmansupport.org/
https://www.fsf.org/     https://www.gnu.org/

Re: Update to GCC copyright assignment policy

[Jason Merrill]

On Wed, Jun 2, 2021 at 4:18 AM Mark Wielaard <mark@klomp.org> wrote:

> Hi Thomas,
>
> On Tue, Jun 01, 2021 at 12:58:12PM -0700, Thomas Rodgers wrote:
> > On 2021-06-01 07:28, Mark Wielaard wrote:
> > > If we no longer want the FSF to be the legal guardian and copyright
> > > holder for GCC could we please find another legal entity that performs
> > > that role and helps us as a project with copyleft compliance?
> >
> > Personally, this would have been my preference.
> >
> > > I would be happy to setup a shared copyright pool under the Conservancy
> > > Copyleft Compliance project for example:
> > > https://sfconservancy.org/copyleft-compliance/
>
> It isn't too late to start discussing this as alternative. As far as I
> understand the SC hasn't talked to the Conservancy yet. But the
> Conservancy is happy to share their knowledge and discuss policy
> issues with the GCC community if we decide we want their input.
>

This seems to me a complement rather than an alternative; some Linux
developers use the Conservancy copyleft services while contributing under
the DCO, and some GCC developers could do the same.

Jason

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

Hello GCC developers, 

On Tue, 1 Jun 2021 10:00:06 -0400 David Edelsohn via Gcc wrote:

> The GCC Steering Committee has decided to relax the requirement to
> assign copyright for all changes to the Free Software Foundation.  GCC
> will continue to be developed, distributed, and licensed under the GNU
> General Public License v3.0. GCC will now accept contributions with or
> without an FSF copyright assignment. 

Is it possible to release a new version for the last commit that only
includes changes under FSF copyright, possibly deferring the
introduction of non-fsf copyrighted code as much as technically
possible with git?

A sort of "marker" version.

So that users downstream could say: all copyright on GCC code before
version X is completely owned by the FSF, but since version X (and
maybe, in the future, till version Y) it is owned by several entities.


This could ease things in case of future changes in the copyright
legislations that could require an update to the GPL to close new
loopholes.

Or in case of legal litigations related to copyright, like the ones that
sometimes affect the customizers of the Linux kernel.


In fact, I'd say that such a change is a major one and should be marked
with the release of a new major version of GCC (while previous major
versions should remain unaffected).


Giacomo

Re: Update to GCC copyright assignment policy

[Jakub Jelinek]

On Thu, Jun 03, 2021 at 02:35:51PM +0200, Giacomo Tesio wrote:
> > The GCC Steering Committee has decided to relax the requirement to
> > assign copyright for all changes to the Free Software Foundation.  GCC
> > will continue to be developed, distributed, and licensed under the GNU
> > General Public License v3.0. GCC will now accept contributions with or
> > without an FSF copyright assignment. 
> 
> Is it possible to release a new version for the last commit that only
> includes changes under FSF copyright, possibly deferring the
> introduction of non-fsf copyrighted code as much as technically
> possible with git?

No.  GCC 11.1 has been released a month ago, why don't you treat that as a
marker version if you need any.

> A sort of "marker" version.

	Jakub

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

Hi Jakub,

On Thu, 3 Jun 2021 15:02:16 +0200 Jakub Jelinek wrote:

> On Thu, Jun 03, 2021 at 02:35:51PM +0200, Giacomo Tesio wrote:
> > Is it possible to release a new version for the last commit that
> > only includes changes under FSF copyright, possibly deferring the
> > introduction of non-fsf copyrighted code as much as technically
> > possible with git?  
> 
> No.

May I ask why?


> GCC 11.1 has been released a month ago, why don't you treat that
> as a marker version if you need any.

Well, I'm happy to learn that all previous versions before 11.1 will be
unaffected by this change. Many people still use GCC 10, 9 and even 8.


The problem is that since the new policy was NOT publicly discussed in
advance but decided and imposed by the GCC Steering Committee alone
just two days ago, all commits/contributions in-between the last release
and the new policy introduction will have to be handled differently in
the future in case of litigations.

Why preserve such ambiguity while they can, quite easily, mark the new
copyright management with a new major version?

This is a kind of expensive externality that is very easy to avoid now,
but will be impossible in the future.

Why should the Steering Committee put such burden on GCC users?


I mean: is this a technical issue I'm missing (I'd simply create a
git branch with the non-FSF copyrighted commits and merge it after the
marker major version release) or a political choice?

And if the latter, can the reasoning be shared with the GCC users and
future developers that will be affected by it?

Not much the reasoning about the new policy (despite interesting, at
least for me) but about the choice to NOT consider such change in
copyright policy as a major change deserving a new major release.


Since it would be easy to achieve and will affect all of us, I think it
should be explained somewhere.


Giacomo

Re: Update to GCC copyright assignment policy

[Jakub Jelinek]

On Thu, Jun 03, 2021 at 04:07:07PM +0200, Giacomo Tesio wrote:
> On Thu, 3 Jun 2021 15:02:16 +0200 Jakub Jelinek wrote:
> 
> > On Thu, Jun 03, 2021 at 02:35:51PM +0200, Giacomo Tesio wrote:
> > > Is it possible to release a new version for the last commit that
> > > only includes changes under FSF copyright, possibly deferring the
> > > introduction of non-fsf copyrighted code as much as technically
> > > possible with git?  
> > 
> > No.
> 
> May I ask why?

Because it makes no sense, doing a GCC release is lots of work and GCC has a
roughly yearly release cadence for a reason.  Before a trunk can be released
it needs to be stabilized, which even when the trunk has been open only for
a few weeks would be several weeks of work.
You can always cherry-pick any changes assigned to FSF from trunk to 11.1
on your own, but there is no reason why others should spend significant time
on it.

	Jakub

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

On Thu, 3 Jun 2021 16:14:15 +0200 Jakub Jelinek wrote:

> Because it makes no sense

A change in the copyright policies and ownership of a project is usually
seen as a very big change, so much that usually the project change its
whole name, not just its major version.

> doing a GCC release is lots of work and GCC has a
> roughly yearly release cadence for a reason.

Actually an year of delay on such policy change would be very welcome.

I would have really appreciated if the GCC SC had announced such change
for the upcoming GCC 12 while sticking to the old policy in GCC 11.

> You can always cherry-pick any changes assigned to FSF from trunk to
> 11.1 on your own

Sure, I can.

But most users usually download tarballs.

Having the first non-FSF-copyrighted version in a new version would be
very appreciated by many organizations around the world that prefer
to have as few legal dependencies as possible.

That's why it's a major change for people downstream!


Giacomo

Re: Update to GCC copyright assignment policy

[Jason Merrill]

On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio <giacomo@tesio.it> wrote:

>
> I would have really appreciated if the GCC SC had announced such change
> for the upcoming GCC 12 while sticking to the old policy in GCC 11.
>

That is how I was thinking of the change, but I agree that it needs
clarification.

Jason

Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Friday, June 04, 2021 at 2:45 AM
> From: "Giacomo Tesio" <giacomo@tesio.it>
> To: "Jakub Jelinek" <jakub@redhat.com>
> Cc: gcc@gcc.gnu.org
> Subject: Re: Update to GCC copyright assignment policy
>
> On Thu, 3 Jun 2021 16:14:15 +0200 Jakub Jelinek wrote:
>
> > Because it makes no sense
>
> A change in the copyright policies and ownership of a project is usually
> seen as a very big change, so much that usually the project change its
> whole name, not just its major version.
>
> > doing a GCC release is lots of work and GCC has a
> > roughly yearly release cadence for a reason.
>
> Actually an year of delay on such policy change would be very welcome.
>
> I would have really appreciated if the GCC SC had announced such change
> for the upcoming GCC 12 while sticking to the old policy in GCC 11.
>
> > You can always cherry-pick any changes assigned to FSF from trunk to
> > 11.1 on your own
>
> Sure, I can.
>
> But most users usually download tarballs.
>
> Having the first non-FSF-copyrighted version in a new version would be
> very appreciated by many organizations around the world that prefer
> to have as few legal dependencies as possible.
>
> That's why it's a major change for people downstream!
>
> Giacomo

It all depends on whether the maintainer wants it included.  Has
nothing to do with legal dependencies.  Suppose a person gives
you a free software license, but at a later time changes the
license.  You would still be able to use the code, and distribute
modified copies.  What has to happen is for developers to ask
their employers to issue them with a "Disclamer of Copyright
Statement".

The major problem is still linked to the reality that many
business administrators have a grasping attitude towards
software, science, and knowledge in general, seeing any activity or
knowledge only as opportunities for unjust income, not as
opportunities to contribute to human knowledge.

Workers today have no rights in the new digital world.

----- Christopher Dimech
General Administrator - Naiad Informatics - Gnu Project (Geocomputation)

Society has become too quick to pass judgement and declare someone
Persona Non-Grata, the most extreme form of censure a country can
bestow.

In a new era of destructive authoritarianism, I support Richard
Stallman.  Times of great crisis are also times of great
opportunity.  I call upon you to make this struggle yours as well !

https://stallmansupport.org/
https://www.fsf.org/     https://www.gnu.org/

Re: Update to GCC copyright assignment policy

[Daniel Pono Takamori]

[-- Attachment #1: Type: text/plain, Size: 3219 bytes --]

I'm joining this list just briefly to give some feedback and input on this
thread on behalf of Software Freedom Conservancy, since we were mentioned
multiple times in this thread.  I suspect any conversation about how
Conservancy and GCC might work together should be off-list or another list,
and I have suggestions on that below.

> > On 2021-06-01 07:28, Mark Wielaard wrote:
> > > If we no longer want the FSF to be the legal guardian and copyright
> > > holder for GCC could we please find another legal entity that performs
> > > that role and helps us as a project with copyleft compliance?

> On Tue, Jun 01, 2021 at 12:58:12PM -0700, Thomas Rodgers wrote:
> > Personally, this would have been my preference.

On Wed, Jun 2, 2021 at 4:18 AM Mark Wielaard <mark@klomp.org> wrote:
> the Conservancy is happy to share their knowledge and discuss policy issues
> with the GCC community if we decide we want their input.

Jason Merrill replied:
>> This seems to me a complement rather than an alternative; some Linux
>> developers use the Conservancy copyleft services while contributing under
>> the DCO, and some GCC developers could do the same.

Jason, we agree completely that anything Conservancy might offer is a
complement rather than a replacement for any structure that the GCC community
already has or might want to build.  For example, the Copyleft Compliance
project that Mark mentioned <https://sfconservancy.org/copyleft-compliance/>
is primarily designed for projects (e.g., BusyBox, Debian, Linux, Samba) that
have diversely-held copyright.  We provide logistical and coordination
support for individuals who hold copyright (and help them figure out how to
keep their own copyrights) and we also accept copyright assignment from those
who prefer assignment.  (As a reminder, Conservancy is not a law firm and we
do not provide legal services and advice.)

Also, note that both these models of copyright (assigning to a single entity,
or having diversly held copyright among both entities and individuals) are
compatible with the DCO in our experience.  The DCO is an assent mechanism
for licensing, and is orthogonal to the question of who holds the copyright.

We would be glad to talk off-list with any GCC developers who have already
decided to keep their own copyright about joining an enforcement coalition at
Conservancy.

The final note that Conservancy would like to share on-list is that through
our ContractPatch initiative <https://contractpatch.org>, we've been
encouraging individuals to assure that their employment contract does permit
them to keep their own copyrights.  There are many reasons and advantages
for individuals rather than their employers to take control of copylefted
copyrights.  We'd also be glad to discuss those policy benefits with anyone
who is interested off-list.

If you'd like to discuss any of these topics further with Conservancy, may I
suggest the Contract Patch mailing list at: 
<https://lists.sfconservancy.org/mailman/listinfo/contractpatch>
We definitely don't want to see the GCC mailing list derailed into
discussing this possibly off-topic issue.

-Pono from Software Freedom Conservancy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

Hi Daniel,

On Thu, 3 Jun 2021 12:50:44 -0400 Daniel Pono Takamori wrote:

> We definitely don't want to see the GCC mailing list derailed into
> discussing this possibly off-topic issue.

To be fair, THIS is the correct mailing list to discuss these
topics, so much that such major policy change should have been
proposed and discussed here way before its adoption.

At least, according to https://gcc.gnu.org/lists.html

```
gcc is a high volume list for general development discussions about
GCC. Anything relevant to the development or testing of GCC and not
covered by other mailing lists is suitable for discussion here.

[...]

All major decisions and changes, like abandoning ports or front ends,
should be announced and discussed here. [...]
```

So I think Conservacy could (and should) share its own insights here.


Giacomo

Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Friday, June 04, 2021 at 4:50 AM
> From: "Daniel Pono Takamori" <pono@sfconservancy.org>
> To: gcc@gcc.gnu.org
> Subject: Re: Update to GCC copyright assignment policy
>
> I'm joining this list just briefly to give some feedback and input on this
> thread on behalf of Software Freedom Conservancy, since we were mentioned
> multiple times in this thread.  I suspect any conversation about how
> Conservancy and GCC might work together should be off-list or another list,
> and I have suggestions on that below.

Software Freedom Conservancy cannot dictate what gets discussed here.  Naturally
people, including the GCC Steering Committee could discuss with the Software Freedom
Conservancy Group on matters they wish to discuss.  But, as you could have deduced,
we allow comments ourselves on any aspects, and have allowed absolute freedom of
speech that could well have harmed people's sentiments and emotions very easily.

The law protects a broad variety of honest assessments and discussions.

> > > On 2021-06-01 07:28, Mark Wielaard wrote:
> > > > If we no longer want the FSF to be the legal guardian and copyright
> > > > holder for GCC could we please find another legal entity that performs
> > > > that role and helps us as a project with copyleft compliance?
>
> > On Tue, Jun 01, 2021 at 12:58:12PM -0700, Thomas Rodgers wrote:
> > > Personally, this would have been my preference.
>
> On Wed, Jun 2, 2021 at 4:18 AM Mark Wielaard <mark@klomp.org> wrote:
> > the Conservancy is happy to share their knowledge and discuss policy issues
> > with the GCC community if we decide we want their input.
>
> Jason Merrill replied:
> >> This seems to me a complement rather than an alternative; some Linux
> >> developers use the Conservancy copyleft services while contributing under
> >> the DCO, and some GCC developers could do the same.
>
> Jason, we agree completely that anything Conservancy might offer is a
> complement rather than a replacement for any structure that the GCC community
> already has or might want to build.  For example, the Copyleft Compliance
> project that Mark mentioned <https://sfconservancy.org/copyleft-compliance/>
> is primarily designed for projects (e.g., BusyBox, Debian, Linux, Samba) that
> have diversely-held copyright.  We provide logistical and coordination
> support for individuals who hold copyright (and help them figure out how to
> keep their own copyrights) and we also accept copyright assignment from those
> who prefer assignment.  (As a reminder, Conservancy is not a law firm and we
> do not provide legal services and advice.)

It is important that people understand this - Software Freedom Conservancy does not
provide any legal advice.  The FSF, on the other hand, has a robust Copyright and
Compliance framework where one can report violations.

Furthermore, thue FSF can still help bring about compliance even when the copyright
lies elsewhere.

> Also, note that both these models of copyright (assigning to a single entity,
> or having diversly held copyright among both entities and individuals) are
> compatible with the DCO in our experience.  The DCO is an assent mechanism
> for licensing, and is orthogonal to the question of who holds the copyright.
>
> We would be glad to talk off-list with any GCC developers who have already
> decided to keep their own copyright about joining an enforcement coalition at
> Conservancy.
>
> The final note that Conservancy would like to share on-list is that through
> our ContractPatch initiative <https://contractpatch.org>, we've been
> encouraging individuals to assure that their employment contract does permit
> them to keep their own copyrights.  There are many reasons and advantages
> for individuals rather than their employers to take control of copylefted
> copyrights.  We'd also be glad to discuss those policy benefits with anyone
> who is interested off-list.

The FSF has been at the forefront regarding the Disclaimer of Copyright aspect
from employers.  What we can say is that things will became much more difficult
to manage if things are related without a real understanding of the implications.

> If you'd like to discuss any of these topics further with Conservancy, may I
> suggest the Contract Patch mailing list at:
> <https://lists.sfconservancy.org/mailman/listinfo/contractpatch>
> We definitely don't want to see the GCC mailing list derailed into
> discussing this possibly off-topic issue.
>
> -Pono from Software Freedom Conservancy

It is well known that the Software Freedom Law Center has always sought to resolve
licensing disputes amicably. On the other, the Software Freedom Conservancy takes
much harder line against the noncompliance of licensing terms.

On August 26, 2016, Linus Torvalds stated that he found such type of lawyering
a nasty festering disease, and the SFC is spreading that disease.

I agree with Torvalds following your arguing on what is discussed here.

https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003580.html

----- Christopher Dimech
Administrator General - Naiad Informatics - Gnu Project (Geocomputation)

Society has become too quick to pass judgement and declare someone
Persona Non-Grata, the most extreme form of censure a country can
bestow.

In a new era of destructive authoritarianism, I support Richard
Stallman.  Times of great crisis are also times of great
opportunity.  I call upon you to make this struggle yours as well !

https://stallmansupport.org/
https://www.fsf.org/     https://www.gnu.org/

Re: Update to GCC copyright assignment policy

[Richard Biener]

On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio <giacomo@tesio.it> wrote:
>
> >
> > I would have really appreciated if the GCC SC had announced such change
> > for the upcoming GCC 12 while sticking to the old policy in GCC 11.
> >
>
> That is how I was thinking of the change, but I agree that it needs
> clarification.

I don't think this is very practical - we'd need to check each and every commit
before considering backporting fixes, no?  So most definitely GCC 8.5, 9.4,
10.3 and 11.1 are the "last" FSF-only copyright releases and you should consider
GCC 9.4+ (there'll be a GCC 9.5) "tainted".

Richard.

> Jason

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

Hi Richard,

On June 7, 2021 7:35:01 AM UTC, Richard Biener <richard.guenther@gmail.com> wrote:
> On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc <gcc@gcc.gnu.org>
> wrote:
> >
> > On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio <giacomo@tesio.it>
> wrote:
> >
> > >
> > > I would have really appreciated if the GCC SC had announced such
> change
> > > for the upcoming GCC 12 while sticking to the old policy in GCC
> 11.
> > >
> >
> > That is how I was thinking of the change, but I agree that it needs
> > clarification.
> 
> I don't think this is very practical - we'd need to check each and
> every commit before considering backporting fixes, no?

I'm a bit surprised: aren't such commits reviewed anyway on backport?

Even if they apply smoothly, they could introduce nasty bugs if applied blindly.

Also, are there many non-FSF-assigned contribution in the development 
branch already?



> "tainted"

Sad word choice, tbh.

Given that such major development decision was not discussed here but 
Imposed unilateraly by the Steering Committee, a bit of forewarning would be 
much more professional.

Not because the new version are somehow "tainted" but because the many different
users of GCC around the world deserve a bit more respect, imho.


This is not a minor change and should not be introduced in minor versions.

It's a breaking change, after all.


Giacomo

Re: Update to GCC copyright assignment policy

[David Edelsohn]

On Mon, Jun 7, 2021 at 6:11 AM Giacomo Tesio <giacomo@tesio.it> wrote:
>
> Hi Richard,
>
> On June 7, 2021 7:35:01 AM UTC, Richard Biener <richard.guenther@gmail.com> wrote:
> > On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc <gcc@gcc.gnu.org>
> > wrote:
> > >
> > > On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio <giacomo@tesio.it>
> > wrote:
> > >
> > > >
> > > > I would have really appreciated if the GCC SC had announced such
> > change
> > > > for the upcoming GCC 12 while sticking to the old policy in GCC
> > 11.
> > > >
> > >
> > > That is how I was thinking of the change, but I agree that it needs
> > > clarification.
> >
> > I don't think this is very practical - we'd need to check each and
> > every commit before considering backporting fixes, no?
>
> I'm a bit surprised: aren't such commits reviewed anyway on backport?
>
> Even if they apply smoothly, they could introduce nasty bugs if applied blindly.
>
> Also, are there many non-FSF-assigned contribution in the development
> branch already?
>
>
>
> > "tainted"
>
> Sad word choice, tbh.
>
> Given that such major development decision was not discussed here but
> Imposed unilateraly by the Steering Committee, a bit of forewarning would be
> much more professional.
>
> Not because the new version are somehow "tainted" but because the many different
> users of GCC around the world deserve a bit more respect, imho.
>
>
> This is not a minor change and should not be introduced in minor versions.
>
> It's a breaking change, after all.

It's not a new or different license (unlike GPLv2->GPLv3).  It's not
reverting the existing copyrights and assignments. As Eben Moglen
stated in the ZDNet article: "the FSF will long remain the
preponderant copyright holder in GCC and related projects... No
downstream user, modifier or redistributor of GCC is facing any
changes whatsoever."

The break mostly is psychological, not technical or legal.

Thanks, David

Re: Update to GCC copyright assignment policy

[Richard Biener]

On Mon, Jun 7, 2021 at 3:10 PM Giacomo Tesio <giacomo@tesio.it> wrote:
>
> Hi Richard,
>
> On June 7, 2021 7:35:01 AM UTC, Richard Biener <richard.guenther@gmail.com> wrote:
> > On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc <gcc@gcc.gnu.org>
> > wrote:
> > >
> > > On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio <giacomo@tesio.it>
> > wrote:
> > >
> > > >
> > > > I would have really appreciated if the GCC SC had announced such
> > change
> > > > for the upcoming GCC 12 while sticking to the old policy in GCC
> > 11.
> > > >
> > >
> > > That is how I was thinking of the change, but I agree that it needs
> > > clarification.
> >
> > I don't think this is very practical - we'd need to check each and
> > every commit before considering backporting fixes, no?
>
> I'm a bit surprised: aren't such commits reviewed anyway on backport?
>
> Even if they apply smoothly, they could introduce nasty bugs if applied blindly.

They are, but up until now (and hopefully in the future as well) only technical
review is necessary, not license review.  It would be also bad to not be
able to fix a nasty bug on branches because the fix is under the DCO.

> Also, are there many non-FSF-assigned contribution in the development
> branch already?

I'm not aware of any anywhere yet.

> > "tainted"
>
> Sad word choice, tbh.

That was intended given you think it makes a difference at all.

Ricahrd.

> Given that such major development decision was not discussed here but
> Imposed unilateraly by the Steering Committee, a bit of forewarning would be
> much more professional.
>
> Not because the new version are somehow "tainted" but because the many different
> users of GCC around the world deserve a bit more respect, imho.
>
>
> This is not a minor change and should not be introduced in minor versions.
>
> It's a breaking change, after all.
>
>
> Giacomo

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

Hi David,

On June 7, 2021 1:26:52 PM UTC, David Edelsohn wrote:
> 
> > It's a breaking change, after all.
> 
> It's not a new or different license (unlike GPLv2->GPLv3).  It's not
> reverting the existing copyrights and assignments. 

For sure, but it IS a different legal framework anyway.

Before there was only one, well known no-profit copyright holder.

After, there will be MANY copyright holders, just like in Linux.

And as you might know, many corporate Linux adopter have been sued 
for copyright violation by individual copyright holders (often referred as
"copyright trolls") and settled the cases out of court for money.


> As Eben Moglen
> stated in the ZDNet article: "the FSF will long remain the
> preponderant copyright holder in GCC and related projects... No
> downstream user, modifier or redistributor of GCC is facing any
> changes whatsoever."

For now and for most of downstream users, Moglen is right.

But in the long term, what happens in Linux is likely to happen in GCC too.

Introducing such legal risk on users without writing anything in the Changelog 
an without proper notice has not been much respectful.

GCC is one of core components of today's infrastructure.

It's used all over the world and in many different way and legal envirnment.


> The break mostly is psychological, not technical or legal.

Do you mean such change was just introduced to address a psycological issue?

I've never listen about such kind of therapy, but I know nothing about psychology.


Anyway, to most people it's just a matter of risk assesment.

GCC will now come with a new legal risk that was absemt before, thus 
it should be handled properly, with a proper notice and incapaulated 
in a new major version.

And tbh, it doesn't look such an unreasonable request, after all.


Giacomo

Re: Update to GCC copyright assignment policy

[Jakub Jelinek]

On Mon, Jun 07, 2021 at 02:17:55PM +0000, Giacomo Tesio wrote:
> Anyway, to most people it's just a matter of risk assesment.
> 
> GCC will now come with a new legal risk that was absemt before, thus 
> it should be handled properly, with a proper notice and incapaulated 
> in a new major version.
> 
> And tbh, it doesn't look such an unreasonable request, after all.

Nonsense.  GCC codebase doesn't have a single copyright holder for
decades, just look at the source.

libffi has various copyright holders
include/hsa* has AMD as copyright holder
gcc/go/gofrontend and libgo has The Go Authors as copyright holders
liboffloadmic has mostly Intel as copyright holder
libphobos has mostly Digital Mars (and/or the D Language foundation) as copyright holder
libquadmath has Sun Microsystems as copyright holder on various parts
libsanitizer has mostly the LLVM authors as copyright holders
zlib has various copyright holders

You can look at contrib/update-copyright.py, there you'll find a huge list
of various exceptions, external authors etc.

So, a few extra copyright holders under DCO instead of assignment to FSF
will not really change anything significant.

	Jakub

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

On Mon, 7 Jun 2021 15:48:06 +0200 Richard Biener wrote:

> > Also, are there many non-FSF-assigned contribution in the
> > development branch already?  
> 
> I'm not aware of any anywhere yet.

A very good news!
(but should be confirmed by the Steering Committee)

This means that this issue is still very easy to address.

> > I'm a bit surprised: aren't such commits reviewed anyway on
> > backport?
> >
> > Even if they apply smoothly, they could introduce nasty bugs if
> > applied blindly.  
> 
> They are, but up until now (and hopefully in the future as well) only
> technical review is necessary, not license review.

Well, given the procedure documented [1], it's just matter of reading
the commit message to check for the Signed-off-by tag in the commits.

Something that could even be checked by a continuous build script.

In any case, such "license review" would be negligible compared to the
technical one, don't you think?

> It would be also bad to not be able to fix a nasty bug on branches
> because the fix is under the DCO.

Good catch!

Theoretically, this is a good objection and now that I think about it,
I see how the Steering Committee has been superficial in such decision.


But fortunately it's just a theoretical issue.

Most of bugs are hard to find but trivial to fix.
As you know, when there is only one way to write a piece of code, such
code is not protected by copyright law.

On the other hand, if the fix is not trivial, there are ALWAYS multiple
ways to code it in the (unlikely) case that the author does not want to
assign the copyright to FSF to allow the backport.


Sure, I totally agree that ripristinating the previous policy would
completely avoid such kind of issue, but it's a very theoretical one
and cheap and easy to fix or workaround at a technical level.

The legal risks, instead, are going to be much more expensive to
address for the affected users (as the Linux kernel have shown).


That's why they should be addressed here, as long as it's still cheap.


Giacomo

[1] https://gcc.gnu.org/contribute.html

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

Hi Jakub,

On June 7, 2021 2:44:56 PM UTC, Jakub Jelinek wrote:
> 
> Nonsense.  GCC codebase doesn't have a single copyright holder for
> decades, just look at the source.
> 
> libffi has various copyright holders
> include/hsa* has AMD as copyright holder
> gcc/go/gofrontend and libgo has The Go Authors as copyright holders
> liboffloadmic has mostly Intel as copyright holder
> libphobos has mostly Digital Mars (and/or the D Language foundation)
> as copyright holder
> libquadmath has Sun Microsystems as copyright holder on various parts
> libsanitizer has mostly the LLVM authors as copyright holders
> zlib has various copyright holders


The simple fact that you have been able to list the copyright holders 
of the various submodules (as distinct from the rest of GCC under a 
single FSF copyright) shows the advantage of the previous policy.


> So, a few extra copyright holders under DCO instead of assignment to
> FSF will not really change anything significant.

I'm afraid you are being a bit naive here.

You just need one individual who decide to act as "copyright troll" years 
after his contribution has been accepted (things and people change, 
as you know) to cause demage to some users.

You may choose to ignore such risk because it's unlikely to affect your own 
company, but is it ethical to pose such risk / burden on others?

Just to NOT give proper advise, release a major and properly handle backports?


Please, remember that the world is huge, diverse and varied and 
the future is a lot of time!

"Anything that can go wrong WILL go wrong!"


A professional management of such change in the legal framework of 
GCC might look a bit annoying in the short term but might save a lot 
of money and headaches to users in the medium and long term.


Giacomo

Re: Update to GCC copyright assignment policy

[Jason Merrill]

On Mon, Jun 7, 2021 at 11:23 AM Giacomo Tesio <giacomo@tesio.it> wrote:

> On June 7, 2021 2:44:56 PM UTC, Jakub Jelinek wrote:
> >
> > Nonsense.  GCC codebase doesn't have a single copyright holder for
> > decades, just look at the source.
> >
> > libffi has various copyright holders
> > include/hsa* has AMD as copyright holder
> > gcc/go/gofrontend and libgo has The Go Authors as copyright holders
> > liboffloadmic has mostly Intel as copyright holder
> > libphobos has mostly Digital Mars (and/or the D Language foundation)
> > as copyright holder
> > libquadmath has Sun Microsystems as copyright holder on various parts
> > libsanitizer has mostly the LLVM authors as copyright holders
> > zlib has various copyright holders
>
>
> The simple fact that you have been able to list the copyright holders
> of the various submodules (as distinct from the rest of GCC under a
> single FSF copyright) shows the advantage of the previous policy.
>
>
> > So, a few extra copyright holders under DCO instead of assignment to
> > FSF will not really change anything significant.
>
> I'm afraid you are being a bit naive here.
>
> You just need one individual who decide to act as "copyright troll" years
> after his contribution has been accepted (things and people change,
> as you know) to cause demage to some users.
>

The copyright troll risk is much, much lower for GCC than for Linux.
First, because GPL3 specifically addresses the over-strict automatic
termination rules in GPL2 that copyright trolls leverage.  And also because
there are many fewer redistributors of GCC, and they are in the business of
distributing software.  If you are redistributing GCC, it's going to be in
some sort of package format that is also a convenient medium for
redistributing the source.  If you aren't redistributing GCC, just using
it, then the GPL places no restrictions on you anyway.

Jason

Re: Update to GCC copyright assignment policy

[Jakub Jelinek]

On Mon, Jun 07, 2021 at 11:45:49AM -0400, Jason Merrill wrote:
> The copyright troll risk is much, much lower for GCC than for Linux.
> First, because GPL3 specifically addresses the over-strict automatic
> termination rules in GPL2 that copyright trolls leverage.  And also because
> there are many fewer redistributors of GCC, and they are in the business of
> distributing software.  If you are redistributing GCC, it's going to be in
> some sort of package format that is also a convenient medium for
> redistributing the source.  If you aren't redistributing GCC, just using
> it, then the GPL places no restrictions on you anyway.

Yeah.  From GCC one will typically just redistribute in the products
copyright trolls might target the libraries like libgcc, libstdc++ etc.,
and those have the GCC Runtime Library Exception.

	Jakub

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

On June 7, 2021 3:45:49 PM UTC, Jason Merrill wrote:
> On Mon, Jun 7, 2021 at 11:23 AM Giacomo Tesio <giacomo@tesio.it>
> wrote:
> 
> > > So, a few extra copyright holders under DCO instead of assignment
> > > to FSF will not really change anything significant.
> >
> > I'm afraid you are being a bit naive here.
> >
> > You just need one individual who decide to act as "copyright troll"
> years
> > after his contribution has been accepted (things and people change,
> > as you know) to cause demage to some users.
> 
> The copyright troll risk is much, much lower for GCC than for Linux.

In an ever changing world, this is very arguable.

Yet I think you will agree that with the previous policy such risk was absent.

Thus it's intruduction should be marked (and encapsulated) in a new major version.

> First, because GPL3 specifically addresses the over-strict automatic
> termination rules in GPL2 that copyright trolls leverage. 

GPLv3 allows for remediations within 60 since the violation notification, 
but it's unlikely to stop someone who want to monetize his own copyright suing a company:

- first because more often than not such cases are constructed, the company were NOT really violating the copyright
- second because 60 days to get a response from corporates lawyers is unrealistic in most of the world.

> And also because
> there are many fewer redistributors of GCC, and they are in the
> business of distributing software.  

And why GCC redistribution should be discouraged?

Why such business should be burden with this risk?

People still redistribute GCC with other free software for money where 
connectivity sucks or is overly expensive.

> If you are redistributing GCC, it's going to be in
> some sort of package format that is also a convenient medium for
> redistributing the source.  

So what?

We are talking about risk assessment not final court rulings.

In fact most of such cases do not reach a sentence and are settled out of court.


The Steering Committee can avoid all of this, now.
I cannot really understand why they shouldn't.


Giacomo

Re: Update to GCC copyright assignment policy

[NightStrike]

On Mon, Jun 7, 2021, 06:12 Giacomo Tesio <giacomo@tesio.it> wrote:

> The Steering Committee can avoid all of this, now.
> I cannot really understand why they shouldn't.
>

Likely because the primary contributor to c++ has said he will stop
contributing unless the change is made.

>

Re: Update to GCC copyright assignment policy

[Jason Merrill]

On Mon, Jun 7, 2021 at 12:12 PM Giacomo Tesio <giacomo@tesio.it> wrote:

>
>
> On June 7, 2021 3:45:49 PM UTC, Jason Merrill wrote:
> > On Mon, Jun 7, 2021 at 11:23 AM Giacomo Tesio <giacomo@tesio.it>
> > wrote:
> >
> > > > So, a few extra copyright holders under DCO instead of assignment
> > > > to FSF will not really change anything significant.
> > >
> > > I'm afraid you are being a bit naive here.
> > >
> > > You just need one individual who decide to act as "copyright troll"
> > years
> > > after his contribution has been accepted (things and people change,
> > > as you know) to cause demage to some users.
> >
> > The copyright troll risk is much, much lower for GCC than for Linux.
>
> In an ever changing world, this is very arguable.
>
> Yet I think you will agree that with the previous policy such risk was
> absent.
>
> Thus it's intruduction should be marked (and encapsulated) in a new major
> version.
>
> > First, because GPL3 specifically addresses the over-strict automatic
> > termination rules in GPL2 that copyright trolls leverage.
>
> GPLv3 allows for remediations within 60 since the violation notification,
> but it's unlikely to stop someone who want to monetize his own copyright
> suing a company:
> - first because more often than not such cases are constructed, the
> company were NOT really violating the copyright
> - second because 60 days to get a response from corporates lawyers is
> unrealistic in most of the world.
>

Why would someone bother to hassle a redistributor who can just say
"nonsense, we're in compliance, the corresponding source is at this URL"?
What return on their time can they reasonably expect?

The Linux kernel community adopted the GPL3 curing process ("GPL
cooperation commitment") as a remedy for the troll problem.  Do you think
this was a pointless exercise?

> And also because there are many fewer redistributors of GCC, and they are
> in the business of distributing software.
>
> And why GCC redistribution should be discouraged?
>

It shouldn't!  My point is that businesses redistributing GCC are such that
compliance with the GPL is natural for them, unlike, say, manufacturers of
smart toasters running Linux.

Why such business should be burden with this risk?
>
> People still redistribute GCC with other free software for money where
> connectivity sucks or is overly expensive.
>

Redistributors already need to comply with the GPL.  If they aren't, it's
good to point that out so that they can come into compliance.

Jason

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

Hi NightStrike,

On June 7, 2021 5:18:13 PM UTC, NightStrike wrote:
> On Mon, Jun 7, 2021, 06:12 Giacomo Tesio wrote:
> 
> > The Steering Committee can avoid all of this, now.
> > I cannot really understand why they shouldn't.
> >
> 
> Likely because the primary contributor to c++ has said he will stop
> contributing unless the change is made.

Even so I guess he would have no issues to delay the policy change after 
the next major release.

Nor to stick with the previous policy for fixes backported to the other versions.

I mean, I do not know what's his goal, but I guess he doesn't intend to blackmail 
the Steering Committee and the whole GCC users community to achieve it.


Note that I have no idea about who we are talking about, but lilely about
a reasonable professionist.

Or maybe we are talking about the dictact of a corporation?
In such case the issue would become way more risky.


Giacomo

Re: Update to GCC copyright assignment policy

[NightStrike]

On Mon, Jun 7, 2021, 07:36 Giacomo Tesio <giacomo@tesio.it> wrote:

> Hi NightStrike,
>
> On June 7, 2021 5:18:13 PM UTC, NightStrike wrote:
> > On Mon, Jun 7, 2021, 06:12 Giacomo Tesio wrote:
> >
> > > The Steering Committee can avoid all of this, now.
> > > I cannot really understand why they shouldn't.
> > >
> >
> > Likely because the primary contributor to c++ has said he will stop
> > contributing unless the change is made.
>
> Even so I guess he would have no issues to delay the policy change after
> the next major release.
>
> Nor to stick with the previous policy for fixes backported to the other
> versions.
>
> I mean, I do not know what's his goal, but I guess he doesn't intend to
> blackmail
> the Steering Committee and the whole GCC users community to achieve it.
>
>
> Note that I have no idea about who we are talking about, but lilely about
> a reasonable professionist.
>
> Or maybe we are talking about the dictact of a corporation?
> In such case the issue would become way more risky.
>

It certainly LOOKS like something coming with the corporate backing of
IBM/Redhat.

This is the problem with how this change came to be. The optics are poor.
They indicate that a few people (or companies) that are upset with some
current politics are forcing the institution of significant change as of
late (the recent push to deviate from FSF website standards is yet another
subtle political maneuver with no technical merit other than "I don't like
the FSF").

I'm sure that the people involved will say that it's perfectly on the
level, and it well could be, but it doesn't APPEAR to be.

The Steering Committee should take these issues seriously, be more
transparent, and have a wider, more inclusive discussion of project policy
and direction.

>

Re: Update to GCC copyright assignment policy

[Giacomo Tesio]

Hi Jason,

On June 7, 2021 5:24:12 PM UTC, Jason Merrill wrote:
> 
> Why would someone bother to hassle a redistributor who can just say
> "nonsense, we're in compliance, the corresponding source is at this
> URL"?

Usually it's a matter of money AND details.

> What return on their time can they reasonably expect?

Money.

You are overly underestimating how long in takes to get a sentence over the world.
In Italy it could literally take a decade.

Also there is ALWAYS uncertaintly when in comes to courts.


That's why in most cases, these matters do not reach a sentence.

For most corporations over the world it's way cheaper to pay the "troll", 
be him right or wrong.


With the previous CA policy, this could not happen.

That's why it should be managed like a major breaking change.


> The Linux kernel community adopted the GPL3 curing process ("GPL
> cooperation commitment") as a remedy for the troll problem.  Do you
> think this was a pointless exercise?

At best, it's more a form risk mitigation to the corporate needs of the first world 
than a solution to the "copyright troll" problem.

But the fact is that GCC was completely unaffected with the previous policy.

And I'm not even arguing agaist the new one!

I'm just asking to clearly mark with a new version its application.

In a few years, as the existing versions will be deprecated, the new policy will 
become the only one, but at least users will have had time to assess their 
business with GCC.


> > And also because there are many fewer redistributors of GCC, and
> they are
> > in the business of distributing software.
> >
> > And why GCC redistribution should be discouraged?
> >
> 
> It shouldn't!  My point is that businesses redistributing GCC are such
> that compliance with the GPL is natural for them, unlike, say,
> manufacturers of smart toasters running Linux.

Oh, I misunderstood what you meant, sorry.

Well, maybe not a toaster, but imagine a cheap low-energy eink-based 
zen-mode writing/programming machine running gcc-emacs as sole program.

Why such kind of gcc-distribution business should be discouraged by these legal issues?

Yes, it's an hypothetical example, but you know... Twitter is a business too: 
anything can happen, however unpredictable.

That's why I think the Steering Committee should be very careful while 
changing the legal framework of GCC.


Giacomo

Re: Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Tuesday, June 08, 2021 at 6:10 AM
> From: "Giacomo Tesio" <giacomo@tesio.it>
> To: "Jason Merrill" <jason@redhat.com>
> Cc: "Jakub Jelinek" <jakub@redhat.com>, "gcc Mailing List" <gcc@gcc.gnu.org>
> Subject: Re: Update to GCC copyright assignment policy
>
> Hi Jason,
>
> On June 7, 2021 5:24:12 PM UTC, Jason Merrill wrote:
> >
> > Why would someone bother to hassle a redistributor who can just say
> > "nonsense, we're in compliance, the corresponding source is at this
> > URL"?
>
> Usually it's a matter of money AND details.
>
> > What return on their time can they reasonably expect?
>
> Money.
>
> You are overly underestimating how long in takes to get a sentence over the world.
> In Italy it could literally take a decade.
>
> Also there is ALWAYS uncertaintly when in comes to courts.

What me strive for is for the Gpl to became irrelevant.  Whan there are
no arguments against copyleft.

>
> That's why in most cases, these matters do not reach a sentence.
>
> For most corporations over the world it's way cheaper to pay the "troll",
> be him right or wrong.
>
>
> With the previous CA policy, this could not happen.
>
> That's why it should be managed like a major breaking change.
>
>
> > The Linux kernel community adopted the GPL3 curing process ("GPL
> > cooperation commitment") as a remedy for the troll problem.  Do you
> > think this was a pointless exercise?
>
> At best, it's more a form risk mitigation to the corporate needs of the first world
> than a solution to the "copyright troll" problem.
>
> But the fact is that GCC was completely unaffected with the previous policy.
>
> And I'm not even arguing agaist the new one!
>
> I'm just asking to clearly mark with a new version its application.
>
> In a few years, as the existing versions will be deprecated, the new policy will
> become the only one, but at least users will have had time to assess their
> business with GCC.
>
>
> > > And also because there are many fewer redistributors of GCC, and
> > they are
> > > in the business of distributing software.
> > >
> > > And why GCC redistribution should be discouraged?
> > >
> >
> > It shouldn't!  My point is that businesses redistributing GCC are such
> > that compliance with the GPL is natural for them, unlike, say,
> > manufacturers of smart toasters running Linux.
>
> Oh, I misunderstood what you meant, sorry.
>
> Well, maybe not a toaster, but imagine a cheap low-energy eink-based
> zen-mode writing/programming machine running gcc-emacs as sole program.
>
> Why such kind of gcc-distribution business should be discouraged by these legal issues?
>
> Yes, it's an hypothetical example, but you know... Twitter is a business too:
> anything can happen, however unpredictable.
>
> That's why I think the Steering Committee should be very careful while
> changing the legal framework of GCC.
>
>
> Giacomo
>

Update to GCC copyright assignment policy

[Christopher Dimech]

> Sent: Tuesday, June 08, 2021 at 2:17 AM
> From: "Giacomo Tesio" <giacomo@tesio.it>
> To: "David Edelsohn" <dje.gcc@gmail.com>
> Cc: "Jakub Jelinek" <jakub@redhat.com>, "gcc Mailing List" <gcc@gcc.gnu.org>
> Subject: Re: Update to GCC copyright assignment policy
>
> Hi David,
>
> On June 7, 2021 1:26:52 PM UTC, David Edelsohn wrote:
> >
> > > It's a breaking change, after all.
> >
> > It's not a new or different license (unlike GPLv2->GPLv3).  It's not
> > reverting the existing copyrights and assignments.
>
> For sure, but it IS a different legal framework anyway.
>
> Before there was only one, well known no-profit copyright holder.
>
> After, there will be MANY copyright holders, just like in Linux.

What we wish is that there will be no copyright holders at all.

> And as you might know, many corporate Linux adopter have been sued
> for copyright violation by individual copyright holders (often referred as
> "copyright trolls") and settled the cases out of court for money.
>
>
> > As Eben Moglen
> > stated in the ZDNet article: "the FSF will long remain the
> > preponderant copyright holder in GCC and related projects... No
> > downstream user, modifier or redistributor of GCC is facing any
> > changes whatsoever."



> For now and for most of downstream users, Moglen is right.
>
> But in the long term, what happens in Linux is likely to happen in GCC too.
>
> Introducing such legal risk on users without writing anything in the Changelog
> an without proper notice has not been much respectful.
>
> GCC is one of core components of today's infrastructure.
>
> It's used all over the world and in many different way and legal envirnment.
>
>
> > The break mostly is psychological, not technical or legal.
>
> Do you mean such change was just introduced to address a psycological issue?
>
> I've never listen about such kind of therapy, but I know nothing about psychology.
>
>
> Anyway, to most people it's just a matter of risk assesment.
>
> GCC will now come with a new legal risk that was absemt before, thus
> it should be handled properly, with a proper notice and incapaulated
> in a new major version.

The responsibility will now get transferred to the maintainers.  And we all know how
great most maintainers are with legal instruments.  I can then be entitled to insult
maintainers Ad Nausium about the licensing problems that occur, because I long got fed
up of maintainers thinking too highly of themselves, and and other contributors telling
me to shut up because I am not the major maintainer of Gcc.

> And tbh, it doesn't look such an unreasonable request, after all.
>
>
> Giacomo
>

Re: Update to GCC copyright assignment policy

[Jonathan Wakely]

>> Also, are there many non-FSF-assigned contribution in the development
>> branch already?
>
>I'm not aware of any anywhere yet.

adec14811714e22a6c1f7f0199adc05370f0d8b0
96963713f6a648a0ed890450e02ebdd8ff583b14
621ea10ca060ba19ec693aa73b5e29d553cca849
3e5f2425f80aedd00f28235022a2755eb46f310d
ee9548b36a7f17e8a63585b58f340c93dcba95d8
f6bb145c0bff19767931d37733be11c8acc6fa00 (*)
f78f25f43864f38ae5a6a9fcce8f26c94fe45bcd

The one marked (*) is particularly significant because it's from a new
contributor who has no FSF assignment. He contributed a 5-10x
optimization for std::any_cast, which was accepted into the GCC tree
within 24 hours of the patch being received. I consider this a great
success for the project.

I have more than 30 commits adding significant new C++23 features to
libstdc++ which will be merged soon under the DCO.

Re: Update to GCC copyright assignment policy

[Bradley M. Kuhn]

As most of you are probably aware, glibc is also discussing whether or not
to remove the copyright assignment mandate to the FSF.  I have posted a
comment there regarding that, now available at:
   https://sourceware.org/pipermail/libc-alpha/2021-June/128303.html
… which is supplemented by a longer essay that I published here:
   https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/

I believe there are many complex issues related to the issue of where
copyrights for Free Software projects like GCC go, and while I've written
quite a lot of detail there, I think some of what I've written may be useful
as GCC considers how to build long-term robust plans to assure that the
copyleft of GCC is upheld for the long-term.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter