Forgejo is now copyleft, just like Git

pnutzh4x0r@lemmy.ndlug.org · 2 months ago

Forgejo is now copyleft, just like Git

Norah - She/They@lemmy.blahaj.zone · edit-2 2 months ago

Except both of the projects you just linked too have CLAs, which they updated on switching to AGPLv3. Both use them as a way to offer dual-licensing, so they can charge companies for an AGPL-exception by selling them a proprietary-licensed version, which then supports the FOSS-development. They both were also only able to change to AGPL because of already existing CLAs. At least in Element’s case though, they created a two-way commitment in their CLA:

Now, CLAs come in all shapes and sizes: some good and some bad. It’s critical to understand that our reason for requiring one here is to give us the right to sell AGPL exceptions: not to “do a Hashicorp” and switch to a non-FOSS licence in future. We’ve made this clear in the wording of the CLA (using a similar approach to Signal’s CLA) by committing to distributing contributions as FOSS under an OSI-approved licence – many thanks to those who gave feedback on the original announcement to suggest this. You can find the final CLA wording here, derived from the well-respected Apache Software Foundation CLA.

Here’s the specific text from the CLA:

Element shall be entitled to make Your Contribution available under Element’s proprietary software licence, provided that Element shall also make Your Contribution available under the terms of an OSl-approved open-source license.

I personally consider that a fairly reasonable term. Especially because they specified an OSI-approved license. Element are always going to be bound to that now. This is like the copyleft of contributor license agreements.

whou@lemmy.ml · 2 months ago

whoa! thanks a lot! that’s my mistake.

thanks for the awesome info, I should’ve at least check the repo of the individual projects first (only did so with Forgejo).

I totally agree with you, and do think that it is possible to have positive and harmless CLAs. though I do think we should always take a step back and not assume that a project’s CLA will be in favor of our copyright, with the case being more the exception than the norm, unfortunately.

in the end, I will always be happy that a copyright holder wants to be able to reliably make money with copyleft software, but I can never really face a CLA without at least initial hostility anymore. you may say I have prejudice against CLAs lol

Norah - She/They@lemmy.blahaj.zone · 2 months ago

Yeah honestly these feelings are so bloody valid after the way they’ve been used lately. It’s always good to be sure of these things.

LemoineFairclough@sh.itjust.works · 2 months ago

Maybe a more appropriate practice is to only engage with a Contributor License Agreement if the repository one contributes to is already available with the GNU AGPL or one is actually in control of some money the person one contracts with will gain due to one’s changes. For example:

Before I contribute to a project, I should make a copy of as many relevant repositories I’m able to and ensure each one is easy to redistribute, and only make changes to my copies. That way, I can continue distributing the improved software if a person I engage in a CLA with does something I don’t like later, but they are still able to apply any change of mine to a repository that gets more attention (thus helping more people). Also, I might get money (as an employee) for doing this, which would prevent that money from being used against the Free Software Movement.
If I were a board member, manager, or employee and someone engaged in a CLA with an entity I have influence over, I have a good chance to direct more money to support the Free Software Movement (or block dealing with a person where doing so would be harmful).

If I have already fixed a software issue, made it clear what license should be used with my change, and made it available to the public, I wouldn’t necessarily be against engaging in a CLA (though I might ask to be paid to do so since I wouldn’t normally go out of my way to manually sign things, and I do value my time).

FYI I can navigate to https://blog.hansenpartnership.com/why-microsoft-is-a-good-steward-for-github/ from https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html (using https://blog.hansenpartnership.com/gpl-as-the-best-licence-governance-and-philosophy/ for an intermediary step), so I’m a little suspicious about the author’s thoughts on these matters. I also didn’t find any useful information about the GNU Affero General Public License from the same author, and I consider the GNU AGPL to be important based on https://ploum.net/2024-07-01-opensource_sustainability.html and https://lemmy.world/post/16602135

Norah - She/They@lemmy.blahaj.zone · 2 months ago

Would you not consider signing a CLA (without remuneration) if it binds a project to releasing your code under an OSI license? The only way they could have done better I think is by specifying AGPL instead. I’m not trying to argue that all CLAs are good here, but I don’t think that when they achieve the goals of the free software movement, they should be treated with suspicion or derision.

Honestly, all of the recent light shone on CLAs is a great thing. But there are still valid reasons to maintain a unified copyright for a project. None of these projects would have been able to move to AGPL without having used a CLA for that purpose. It also allows enforcement of that license via things like litigation, because you can have one entity on the docket, instead of a thousand contributors all defending their copyright.

I think the correct course of action isn’t to avoid signing one, but to force projects to commit to the social contract of open source in writing. I think there’s also a discussion that no one has earnestly talked about. A contributor license agreement is a contract between two parties, and under contract laws both parties must materially benefit. “I will get x, and you will get y”. This is known as consideration, and courts will nullify contracts that only benefit one of the parties. The only consideration I think there is to be found in most of the CLAs that have been brought up lately, is basically “your code will be merged into the project and released under it”. They don’t specify the continuation of open source, but it’s heavily implied by the aforementioned social contract. So when someone like RHEL goes and closes their source, they’ve essentially changed that contract to “you will sign over your copyright to us, and we will exploit your labour for profit”. That is not consideration, and it calls into question the validity of every single CLA signed. I genuinely think there’s grounds for every RHEL contributor that signed one to form a class and sue, and I would love to see FSF or EFF organising and supporting that sort of effort.

Back to Element for a second though, as far as I can see, their new CLA is a valid contract, because it gives a right to the contributor, that their code will always be released under an OSI license. So if a successful suit was brought against someone like RHEL, or Hashicorp, we could see other projects scramble to repeat Element here. That would be, in my opinion, a very good thing for the free software movement.

LemoineFairclough@sh.itjust.works · edit-2 2 months ago

I would probably be most upset if a program had its license changed to be “permissive” like the Expat License. I might accept making a reasonable number of contracts to provide a “proprietary” license that doesn’t give any new person (or corporation) permission to distribute software, but a “permissive” license allows people to work against the Free Software Movement without any oversight.

That being said, I don’t think I would be satisfied if a contract specified that “an OSI license” will be used: I would prefer for a specific license to be used rather than just one of a class of licenses. However, if an appropriate license is already being used, I wouldn’t have to sign anything to protect myself!

In general, I’m probably against changing the license of any software: changing a license seems like a lot of work that can probably be better spent elsewhere, and I consider it to be unlikely that any GPL license will need to have a new version anytime soon (they might, and the v3 versions are clearly better to use than any preexisting version, but they might also change for the worse if the FSF changes for the worse), and the GNU AGPLv3 clearly reflects the present state of the art of licensing (so using any other license that is compatible with it would strike me as strange). If I actually had a reason to study any source code that wasn’t available with the GNU AGPLv3 or the GNU GPLv3, I would probably be better off studying the requirements of people who use that software and making my own version with a license I prefer: that way I’d provide more certainty that my changes are available with an appropriate license.

Changing the license of existing projects is clearly useful sometimes, but adapting proprietary programs for use with more open systems hasn’t been very useful to me so far. For example, I use LibreOffice rather than trying to get Microsoft Word to work with my computer.

There might be some people who argue that any influence of a GPL license will make their business model less profitable, but if that’s the case we’re already dealing with business, so I might as well receive my fair share of money and influence from the business (or withhold my participation entirely, if that would be less harmful).

Just to be clear, I’d avoid studying source code only available with the GNU Lesser GPL unless things change.

FYI, I’m discussing “studying” instead of “changing”, since avoiding even looking at source code of questionable provenance might help protect me from accusations of plagiarism. If someone exploits a computer system to copy source code without permission and shares it with me, and then I make a similar program, the copyright holders whose program I copied might have a justified reason to complain. However, there is less chance of that if I study people’s public messages or even compare the behavior of one program to another, and if I don’t study a program, I probably can’t change it either.

I’ll note that, despite what I’ve written,

I don’t actually scrutinize licenses of repositories very much: if I come up with a useful patch, I’m inclined to share it even if it’s unclear what license will be used with it. However, I do scrutinize the license of programs I install (for example, I like that yast2 lets you see the license of packages before installing them), so I’m more likely to want to contribute to programs that are compatible with a GPL license.
I have submitted a patch with text like “By submitting this I give permission to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of this contribution to any person obtaining a copy of this software” that was provided as a template.
I wouldn’t complain much if someone got paid $1,000,000 to distribute some software with the Expat License, since I can’t fault them for taking care of themselves.

FYI, “nominal consideration” is very likely sufficient to establish a contract (“contracts in the United States have sometimes have had one party pass nominal amounts of consideration, typically citing $1”), and a contract is probably hard to neutralize in general due to things like mutual drafting clauses and savings clauses.