Remove "or later" from copying.txt

[gerald-hartig]

Link to issue number:

Revert #16830

Summary of the issue:

Inadvertently merged PR before licence clarification was fully addressed

Description of user facing changes

Revert "GPL-2 or later" to "GPL-2"

@coderabbitai summary

[seanbudd]

My concern with merging this as-is, in #16830 we declared a bunch of apache licenses as compatible in the license check, but if we revert "or later" these changes should probably be reverted too.

[seanbudd]

Other updates that may need to happen:

• the "license" section in pyproject.toml
• the copyright headers file (however I think we can declare new files as GPLv2 or later with no issue)

[ethindp]

Look, this PR and the older license PR should've never been merged to begin with. Revert the old PR and then re-open it. Right now this project is actively violating the GPL because the right way to do this is to ask (every) contributor, past and present, and to get their confirmation before re-licensing.

[gerald-hartig]

@ethindp We're currently speaking to our legal team and the FSF to get clarity on what is required and the best way to proceed. This PR is on the 2025.1 milestone which means that if this issue is not resolved by the time our next release comes out, the addition of the lifeboat clause will be reverted. The 2024.4 release also does not contain the lifeboat clause.

[ethindp]

@gerald-hartig Ah okay. I do believe I am correct on this matter, unless the FSF explains otherwise. I would recommend you just revert the mistaken PR and go from there.

[XLTechie]

And if we're going to go to that kind of trouble, I would sooner see us ask contributors to assign their rights to NV Access. Of course we would also start making it a contribution policy that future contributions are assigned to NV Access. There will be some who may not (though I think that to be rare), and there will be some who can't be reached, but I think most will, and that will greatly simplify future copyright issues. This "make all contributors copyright holders to their little piece of the whole" idea is kind of untenable in the long run, in my view. Especially when you consider that people who's work has been entirely replaced with newer work, are still counted as copyright holders in the project, even though their only extant piece of work may be a changelog entry from years back..

[ethindp]

@XLTechie That isn't untenable. It's one of the entire reasons open-source works so well. If NVAccess adopts any kind of CLA or similar, your going to drive away pretty much everybody because nobody is going to want to give NVAccess that kind of control over the project and their contributions. See also: Don't Sign a CLA

[XLTechie]

@ethindp The problem (one of them), is that the way we do copyright now, is non-attributive. Just because my name appears in the header of a file as holding copyright on that file with 20 others, does not indicate what fraction of the code in that file is mine, or even if any of it still is. If the section of the file was labeled as being copywritten by me, that might be different. But courts appear to care, at least in some places, that you can prove what part of the fractional copyright is yours, and whether it is significant enough for enforcement purposes. Even the FSF does copyright assignment to avoid the kind of problems this can lead to. https://www.fsf.org/blogs/licensing/FSF-copyright-handling I do agree with you that the original PR needs to be reverted, because up-casting the license is not something that can be done without permission of those holding copyright.

[ethindp]

@XLTechie
This is a problem with copyright, but not necessarily a problem with OSS itself. It in no way means that some kind of CLA is a good idea. Time and time again we see that most projects use CLAs as a way of technically being open source while not really being as open as they should be, or we see projects who have people sign a CLA just so those projects can then turn around and do whatever they want with the code because there's nothing the contributors who wrote that code can do because of said CLA. I am in no way implying that NVAccess would do that, but there are much better ways of doing things, like the Developer Certificate of Origin:

By making a contribution to this project, I certify that:

1. The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
2. The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
3. The contribution was provided directly to me by some other person who certified (1), (2) or (3) and I have not modified it.
4. I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

We could just use that and the CLA (or something similar to it) could be neatly avoided. This is what Linux uses and we know it works well.

[XLTechie]

There are pretty good arguments in the comments of the below, as to why a "sign off" (presumably a git sign-off) is not likely to be a good solution. It makes the git history into a legal record that has to be distributed with the source code. Unless sign-off means something else in this context. That aside, such a statement doesn't solve any of the problems being contemplated. NV Access still can't expand the license without contacting everyone, including the estates of the dead, the employers of the formerly employed, the missing, etc. That's potentially fine, in that we don't necessarily want them able to re-license at will, especially to something more restrictive. But a contribution license can solve that, by requiring continued use of an open source license, or some such thing. I'm sure there's a model out there. It still leaves the code unattributed, and the copyrights in the file either 100% partnerships even for contributors whose code is now gone, or practically meaningless from a legal prospective, except as a headache. https://lwn.net/Articles/912355/

[ethindp]

If there is such a model that actually works, and doesn't violate the open-source definition in some manner, I think every OSS dev that wants to go commercial would love to hear it. To my knowledge, CLAs or the DCO are the only models that work, and as noted the CLA is not treated favorable by the supermajority of OSS developers and is typically used by a corporation as a way of taking total control over a contributor's contribution(s) for eternity and completely excluding them from any and all decision-making processes or procedures involving the project where their contribution(s) are concerned. The fact that re-licensing is such a headache is precisely the point -- re-licensing at will or claiming absolute ownership over every contributor's contribution(s) is dangerous and is more often than not just used to stab the OSS community in the back as soon as the corporation suffers a bad quarter or something. NVAccess is in a unique position in that this would be a lot harder for them, as I don't believe they are a corporation, but the fact that they would do it at all is concerning enough as it is. Just keep the GPL 2.0 license, consider analyzing all deps and replacing those that are incompatibly licensed and be done with it.

[gerald-hartig]

In the interests of all concerned, we're going to merge this revert now. This change was introduced prematurely, and we’re committed to addressing it in a way that best serves NVDA’s future, community and our obligations to prior contributors.

Throughout, we've been consulting with both our legal team and the Free Software Foundation to ensure a clear, secure path forward. Our priority is to make sure that any license change safeguards NVDA's long-term sustainability while respecting contributions, past and present. Until we have comprehensive legal guidance, we are reverting to GPL-2.

We know that some of you have raised concerns about copyright management, potential licensing approaches and the suitability of models like CLAs. I want to assure you that any future changes will be thoughtfully considered, and we will continue to involve the community throughout the decision-making process. Transparency and respect for the values that drive open-source collaboration are foundational to our approach.

NV Access and the development of NVDA is ultimately governed by an independent board of directors who are there to ensure that NVDA remains free (as in beer and as in speech) and open and that all work adheres to our guiding principles: https://github.com/nvaccess/nvda/blob/master/projectDocs/product_vision.md