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 On Tue, Jan 14, 2020 at 9:39 AM Daniel Pocock <dan...@pocock.pro> 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 > https://danielpocock.com > > > > To: John Sullivan <jo...@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 > >
