This will create a lot of paperwork which puts GNU project maintainers in a
very bad position. In practice, once someone is known to have done
assignment paperwork, there is no reason to check if they have an active
assignment. This assumption would no longer be valid.

Worse, there could be multiple suspensions and reinstatements. This would
result in periods of "ok to merge" and "not ok to merge" of varying lengths

Computationally, this means "OK to assignment" is not a boolean condition
that never changes after going true but a value that is dependent on some
point in
time. How would that precise range of time be managed by the FSF? a
maintainer would have to check that the submission occurred in an
"ok to merge" period. What would the timestamp be that needed to be
compared to the "valid assignment in place" method? How would the
maintainer know?

Assuming this happened, maintainers are burdened by checking that the
assignment is OK and if any mistake is made, there is a copyright assignment
issue which could submarine the project.

If you want to stop submitting code in protest, feel free to do so. Send a
to the FSF telling you why you aren't submitting code. Post it anywhere you
want. But please, do not punish your fellow GNU project maintainers who
will be burdened by having the copyright assignment in force check process
changed forever.

Some of this discussion was about documenting the FSF and GNU Project
and making them well-known. I'm all for that. but please don't burden
forever just to make a point.


--joel sherrill
RTEMS, GCC, Binutils, GDB, Newlib

On Tue, Jan 14, 2020 at 9:39 AM Daniel Pocock <> wrote:

> FSF will not change unless somebody gives them a strong reason to change.
> For example, if GNU developers write the following email to FSF, that
> will bring change.
> Each developer needs to make their own decision if they will send the
> email.  RMS has previously suggested he would not like people to
> completely abandon the agreements.  The email template below is only for
> a conditional suspension of the agreement.  Nobody can tell you to
> continue assigning[1] your rights to FSF if you want to wait for more
> clarity about FSF's future.
> You can still keep coding during the suspension: if a significant
> quantity of code is published and virtually embargoed like this, it
> creates an incentive for FSF to satisfy those people and gain rights
> over that code.
> Regards,
> Daniel Pocock
> --
> Debian Developer
> To: John Sullivan <>
> CC: (relevant project mailing lists)
> Subject: suspension of contributor agreement
> Dear John,
> I am writing to suspend my FSF / GNU project contributor agreement[1]
> signed __/__/____
> I will continue contributing code to (names of projects) retaining all
> intellectual property rights personally during this suspension of the
> agreement.
> I also wish to notify you that my contributor agreement will be
> reinstated when FSF makes a satisfactory commitment about leadership and
> governance issues.  I have not yet decided what will constitute a
> satisfactory commitment, for now, I will review the proposals put
> forward by FSF and I may contribute further criteria as the situation
> evolves.
> All work completed during this suspension will be assigned
> retrospectively to FSF when the conditions of reinstatement are satisfied.
> Sincerely,
> Developer
> 1.

Reply via email to