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 repeated.
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 letter
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 processes
and making them well-known. I'm all for that. but please don't burden maintainers
forever just to make a point.
Thanks.
--joel sherrill
RTEMS, GCC, Binutils, GDB, Newlib
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
https://danielpocock.com
To: John Sullivan <johns@fsf.org>
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. https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters