As someone who wants GPL enforcement, I still say don't sign a CLA, for two reasons:
- Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time and defeat the copyleft (e.g. Oracle killing off OpenSolaris). I consider this a worse outcome than a copyleft that is unenforced. It also encourages malicious enforcement (e.g. Oracle v. Google) that runs contrary to the goals of FOSS.
- Due to some very specific peculiarities of US law, regular users can sue companies that don't follow the GPL, because the source code disclosure requirement makes you a third-party beneficiary of the copyright license (which in US law is a contract).
The last one is a bit unfair to the article because the rulings in question happened after it was published. But it obviates the biggest benefit of centralized ownership - clear and unambiguous standing to sue. If things were the opposite - i.e. the courts said third-party beneficiaries can't sue and only owners can - then there would be an argument for keeping ownership of critical parts of the project in an entity with no conflict of interest against enforcement.
Even then, I don't see why ownership has to be centralized. Under US law, joint owners of a single copyrighted work both have standing to sue. Having more owners means more people with standing. In lieu of a classic CLA with a single point of failure, you could have a policy of accepting any code that is either owned by the developer itself (after their employment contracts have been vetted) or any of a number of trustworthy FOSS organizations who are committed to enforcing GPL. All parties would have standing to sue individually and could additionally sue as a class in a single action.
I think you may be overestimating the usefulness of a third-party beneficiary approach. There are two issues with it:
(1) Isn't SFC vs the only case where how third-party beneficiary law applies to GPL enforcement has come up? That case has not yet gone to trial. The third-party beneficiaries have only been considered in the context of motions of summary judgement. The court ruled that this will have to be determined at trial.
(2) You can only have a third-party beneficiary to a contract when there is a contract.
The defendant should be able to defeat a third-party beneficiary claim by saying that they did not agree to the license. They saw code they wanted to use and thought it was public domain or thought their use would be covered by fair use or decided that they would go ahead and infringe its copyright because they thought the risk of the copyright owners suing was negligible.
That approach would have some risks if the copyright owners later do sue, because it would be tantamount to admitting their infringement was willful which can greatly increase statutory damages.
> Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time and defeat the copyleft
It also grants the ability to make the project more open. I once wanted to change a project I was part of to a more permissive public domain license. Leadership was in favour but ultimately rejected it due the impracticality of dealing with getting agreement from everyone who had ever contributed (there were no CLAs). So it remained with the old license.
If an entity unilaterally changes the license, you can still fork it at the time the change was made and continue from there.
Now, I’m not defending Contributor License Agreements. I also dislike them and the hurdles they cause to contribution. Plus, the situation you described of the project becoming more locked down instead of less is likely more common, and forks can be a pain for everyone. Still, wanted to share the other side.
>Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time and defeat the copyleft (e.g. Oracle killing off OpenSolaris).
I don't understand how copyright ownership of FOSS code would impact an entity locking down the project. I don't think owning the copyright gives the entity the ability to do that. Maybe owning the trademark or the Github repo would, but not the copyright.
The entity holding the copyright can change to a new restrictive license, and continue development there, effectively killing the old GPL version and so locking down the project.
The original contributors would not agree, but they gave up their rights.
However, I think for the entity to do that in practice, the entity would need to also own the trademark and the Github repo (or wherever development takes place). So there's no real risk to assigning copyright to the FSF if the FSF doesn't also own the trademark and the Github repo.
I don't disagree with the general claim, but about your scenario specifically - the "entity holding the copyright" is not, generally, the entity doing the development. If it is, then the question is not copyright assignment but just whether or not the main developing entity sticks to a FOSS development or not.
If I contribute code to a GPL project without signing a CLA, and they later decide to re-license, they cannot use my contributions in the re-licensed version.
The original code up to that point is still GPL though, so they can't lock down your contribution, they are just using it in a closed system. The open system is still available for everyone.
If you want to switch the license on a software project away from GPL, that is possible. All old versions were and will remain GPL. Any new versions can stop being GPL as long as all copyright holders agree to let this happen.
You cannot use the GPL license to allow publishing this new version. But you can use permission by all copyright holders as an exception.
> Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time...
By this logic, as well as refusing to sign CLAs you should also refuse to adopt any MIT licensed or similar software, since that can also be "locked down".
The FSF is the only entity I'd trust with a CLA. Considering they're the stewards of the GPL, if they went evil everything would be FUBAR anyway. So I'd say yeah, the FSF doing it is fine.
- Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time and defeat the copyleft (e.g. Oracle killing off OpenSolaris). I consider this a worse outcome than a copyleft that is unenforced. It also encourages malicious enforcement (e.g. Oracle v. Google) that runs contrary to the goals of FOSS.
- Due to some very specific peculiarities of US law, regular users can sue companies that don't follow the GPL, because the source code disclosure requirement makes you a third-party beneficiary of the copyright license (which in US law is a contract).
The last one is a bit unfair to the article because the rulings in question happened after it was published. But it obviates the biggest benefit of centralized ownership - clear and unambiguous standing to sue. If things were the opposite - i.e. the courts said third-party beneficiaries can't sue and only owners can - then there would be an argument for keeping ownership of critical parts of the project in an entity with no conflict of interest against enforcement.
Even then, I don't see why ownership has to be centralized. Under US law, joint owners of a single copyrighted work both have standing to sue. Having more owners means more people with standing. In lieu of a classic CLA with a single point of failure, you could have a policy of accepting any code that is either owned by the developer itself (after their employment contracts have been vetted) or any of a number of trustworthy FOSS organizations who are committed to enforcing GPL. All parties would have standing to sue individually and could additionally sue as a class in a single action.