The Free Software Foundation (FSF) has in the past previously required developers working on projects such as GCC (the Gnu Compiler Collection) to assign its copyrights to the FSF. The logic is that this does make enforcement easier against people using the code in contravention of its licence (GPL). The theory is that, since the FSF styles itself as the ultimate custodian of software freedom, there can be no harm in the developers assigning their rights to it. The GPL is intended to guard against free software becoming controlled by the powers of evil.

Copyright assignment requires significant trust. Simon Phipps has written eloquently about the rights ratchet, and assigning rights to a business requires the developer assigning the copyright to be open to the possibility that the business might want to close the code (https://meshedinsights.com/2021/02/02/rights-ratchet/). Maybe the current management and shareholders of a business are happy that their company is licensing its products under an open source licence, but there may always be a change of shareholders, and those shareholders may take the opportunity to force the management to take what they perceive as a short-term financial gain of closing the project and milking the current customer base.

It’s not only businesses that the developer needs to trust – any other organisation requiring a copyright assignment needs to be examined carefully, to see whether its governance model is capable to preventing it from doing the wrong thing. This is by no means straightforward. Some could argue that an FSF without Richard Stallman (RMS) as its guiding hand would be an organisation more likely to depart from its founding principles of software freedom, and use its powers for evil. Others may argue that the management decisions made around RMS’s departure and reinstatement suggest that the FSF isn’t an appropriate body to be a copyright steward in the first place. (For more background, see https://www.theregister.com/2021/03/22/richard_stallman_back_on_fsf_board/).

This may be seen as an issue more for copyleft licences than permissive ones (as anyone contributing to a permissively-licensed project is already open to the idea of their code becoming proprietary. However, I would argue that the situation is more subtle than that: there are more reasons for a project to remain open than the demands of the underlying licence (the power of upstreaming being one of them).

My view is that for GPL projects, the GPL itself provides, in most cases, sufficient protection for developers. They should retain the copyright, and license their contributions to the project under the same version and flavour of GPL as the project uses. The Linux Kernel is licensed under GPLv2 only, and this protects the developers: they know that it is virtually impossible for the Linux Kernel as a whole to be relicensed under any other licence. There have been sufficient reported cases of GPL enforcement of copyright violations concerning the Linux Kernel across sufficient jurisdictions (and, presumably, many more cases which have been settled and are unreported) to suggest that any concerns about lack of concentrated copyright control giving rise to difficulties in raising legal standing (the right to sue) in the courts are misplaced.

There is always the argument that the FSF, by taking an assignment of the copyright, is taking two bites of the cherry because it not only has free rein to relicense in its capacity as the copyright holder, but also, assuming the project is one which is licensed under a “GPL version x or later” option, it has the ability to relicense under any licence it wishes, by issuing a version 4 (or higher) of the GPL. It’s only the governance of the FSF (which is where we started with potential trust issues) which prevents this relicensing becoming evil (unless you fancy trying to use the courts to enforce the “similar in spirit” wording in the GPL: not a prospect I relish).

That’s not to say that there aren’t growing problems with the GPL as it stands which it would be helpful to address. I’m not talking about absorption of code into the cloud (which I think is a separate issue, and truly believe is beyond the scope of “similar in spirit” – but this was a point argued forcefully by both sides in the GPLv3 drafting process, and was ultimately not addressed in GPLv3, being left to AGPL to fill that gap, to an extent). I’m talking about the increasing problem of attributions and source code provision. It’s becoming increasingly difficult to comply with GPLv2 (in particular) in an embedded environment because shipping the device (if it doesn’t have an interactive display) requires shipping quite a lot of material alongside the device itself, something which benefits neither the developers, the device producers of the recipient of the code. It would be significantly easier and better for everyone if the compliance notices were able to be placed in a sure, persistent location on the web, which can easily be accessed through a short-form URL printed on the device itself.

Unfortunately, at least in some jurisdictions (I’m looking at you, Germany) a relicense or exception to the GPL would be required to permit this. It’s also worth bearing in mind that even the Linux Kernel is not exclusively licensed under GPLv2. It contains many components licensed under permissive licences such as BSD and MIT, so even if the (tens of thousands of) copyright holders of code licensed under GPLv2 were to agree to relicense, relicensing by consent may also be necessary for those components licensed under the other permissive licences because any agreed relicense of the GPLv2 components may create licence compatibilities with some of the permissively-licensed components.

Ultimately, the longevity and success of any project is dependent on maintaining a healthy balance between the rights and interests of the project as a whole, and those of individual contributors. A healthy contributor community means a healthy project. A licence-in licence-out model is simple, but it acts very effectively to balance those rights.