Nobody is discussing the reason for the copyright-assignment requirement. I only know about it because I was caught in the issue that it means to prevent nearly 20 years ago.<p>The issue is that in many places (for example New York State), work done by a professional employee actually belongs to your employer. A developer can write code, contribute it where they want, and license it as they wish. But the code is actually owned by their employer. Which means that if there is a future problem, the employer can assert their copyright interest and people who thought that they had the right to use that code, suddenly don't.<p>Because developers themselves are seldom aware of such rules, the FSF took the ultra-safe approach of requiring employers to sign off. That way they are absolutely sure that there will never be a problem.<p>However other open source projects have found that, in practice, problems are rare. And when there is a problem, the employers usually will agree to the license.
This is a good thing for the health of the GNU ecosystem, and I hope other GNU projects adopt this practice.<p>Related story: a couple of years ago, the current maintainer of an Emacs package reached out to me. Apparently the FSF wanted to make it part of the official Emacs distribution, and wanted me to assign my copyright to them. I was happy to do so, BUT: the code was written more than 20 years ago when I was at university, which (according to the FSF) meant I needed to get a copyright release from the university, in a country I no longer lived in and that I had not interacted with for literal decades. This seemed like far too much trouble at that point, so I gave up, and the package never became part of Emacs.
I really hope other GNU projects, in particular Emacs, follow suit, though I doubt it will happen.<p>In my experience it is a massive hassle to get the copyright disclaimer from my employers. I'm currently on hold from contributing to Emacs because my paperwork is working its way through the legal bureuacracy of my new employer. Also, I have former coworkers from previous companies who were enthusiastic about Emacs, but unwilling to go through the trouble of getting the paperwork to contribute.<p>I think getting this paperwork through is probably more difficult in my industry, than in others -- I do R&D at a large pharmaceutical.<p>Still, I think the copyright disclaimer is one of the biggest factors that is limiting the number and diversity of Emacs contributors. I also think it's unnecessary, as Linux does not have this requirement, and it has successfully enforced the GPL, for example on router manufacturers.
The only GNU project I directly contributed code to was GNU nano. I was probably only willing to do so because it did not require anything like a CLA. But, if this didn't need any bureaucracy, I'd be glad to do so. I personally trust the FSF. Every new version of the GPL came after players tried to circumvent it so, having new updated versions of the GPL prevents players from abusing the right they have when new (legal) holes are discovered. AFAICS, the only institution I'd trust to assign my copyrights to is the FSF. They have proved time and time again to not sacrifice freedom and privacy in the name of profit or convenience.
I wonder if this is largely a practical issue -- I've seen people waiting over a year for everything to get sorted out ( for example <a href="https://gcc.gnu.org/pipermail/gcc/2021-April/235288.html" rel="nofollow">https://gcc.gnu.org/pipermail/gcc/2021-April/235288.html</a> ), that's just not reasonable.
I think the FSF is starting to realize that Stallman is not forever, and FSF ethics aren't forever. Having the FSF have exclusive rights to change license terms with "or newer" terms and to hold copyrights to projects is a bad idea as the founders of the FSF are getting older.<p>I trust the FSF, but I have no idea who the FSF will be in another 20 years.
Copyright assignment is an interesting topic.<p>With the copyright assigned the owner of said copyright can release the code under any license of their choosing.<p>Some dual license open source projects do this, the organization requires the copyright assignment and hence they can release the code under an open source license and their own closed license. License changes here are perfectly OK (legally at least).<p>Interesting cases are those without a copyright grant. Now you allow the group to only produce copies and releases in accordance to that specific license. License changes now are questionable. Can you relicense Apache 2.0 as AGPL? BSD as Apache 2.0? (Without owning the copyright, my guess in both cases is no.)
Given three plus decades of FOSS experience, are the fears of permissive licenses like MIT and BSD (that companies will take, fork, and not give back in a meaningful way which will kill open source) considered to be well-founded? Could Linux not be as pervasive and important as it is today had it been released under a BSD license?
This may help contributors, but makes difficult to change the license in the future. I guess this the main reason why FSF requires copyright assignment to them. Now that this is no longer needed, I really hope that the world will not need anything newer than GPLv3.
Off topic but reminds me, I wonder if copyright assignment or trademark assignment (if it applies) would have helped freenode. In the sense of helping it stay as it was, a friendly place for users and project maintainers.
I'm somewhat surprised to hear that many GNU projects have copyright-assignment policies in place. That seems to go against what I used to think the FSF was all about. But after watching videos of Linus on GPL v3, it seems that the FSF is all about exerting control, despite having "Freedom" in their name.
This is a good example of how to not steer a FOSS project. Seriously, what was the steering committee thinking? I mean, I tend to agree with this decision, but do they honestly believe that just announcing such a big change without any public discussion beforehand is going to fly?