Is there some AGPL equivalent on top of GPLv2 instead of GPLv3
After reading the rational for v2 for the Linux kernel, Ive always found v3 a bit off putting.
Why we picked AGPL
101–110 of 312 posts
Re: Why we picked AGPL
#102Correction: they chose AGPL with a poison pill (CLA) so they can benefit from it and take it away whenever they want more.
They can always pay you to sign the CLA… works both ways.
Re: Why we picked AGPL
#103Earlier quoted context omitted.
You don't need CLA for legal protection, Developer certificate of origin is enough. https://en.m.wikipedia.org/wiki/Developer_Certificate_of_Ori...
We've looked into the DCO before. It turns out CLAs are more common and easier to deal with, thanks to a tool like cla-assistant.io. We ended up opting for it for the sake of simplicity.
You can use DCO legal text with CLA Assistant though!
Re: Why we picked AGPL
#104Earlier quoted context omitted.
In practice, projects that take this approach do the majority of development in house, and external contributions are small. It makes sense that a company that may have spent several years developing a product can sell commercial licensing. The only alternative way to monetize AGPL works is to provide services and support. Nobody is forcing anyone to give away their rights. You can always distribute contributions und…
I love single-license-per-project F/OSS companies like Red Hat, but they're rare. I'm attracted to companies who are so committed to F/OSS as a practice that their software is copyleft and they don't require a CLA. But dual-licensing is a tried-and-true strategy and the basic premise is very clear and very fair: share your downstream changes or pay a fee. And a CLA is required to make that work. Something commenters…
There are clear differences. [Let's say I am not a competitor and Amazonifying them] I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
Even worse, let's say I am a paid customer for their support and run on their proprietary license. Once they rug pull or jack up the prices or whatever, I cannot fall back to AGPL hosted locally. If it were permissive I would have had other options.
AGPL I fully respect as Free Software. AGPL+CLA, however, is not your friend and is pure deception. If you are a sufficiently large commercial entity, you are probably wise to act as if it is proprietary. In fact, it might be slightly worse as folks are sometimes cavalier in accepting contributions without proper copyright license/assignment and they pass them on to you under their paid license and expose you to some risk.
Re: Why we picked AGPL
#105Earlier quoted context omitted.
I love single-license-per-project F/OSS companies like Red Hat, but they're rare. I'm attracted to companies who are so committed to F/OSS as a practice that their software is copyleft and they don't require a CLA. But dual-licensing is a tried-and-true strategy and the basic premise is very clear and very fair: share your downstream changes or pay a fee. And a CLA is required to make that work. Something commenters…
There are clear differences. [Let's say I am not a competitor and Amazonifying them] I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner. Even worse, let's say I am a paid customer for their support and run on their proprietary license…
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates.
That part is exactly the same under AGPL, no?
Re: Why we picked AGPL
#106Correction: they chose AGPL with a poison pill (CLA) so they can benefit from it and take it away whenever they want more.
This. The AGPL deception is you brand yourself as community-minded. As long as you don't rely on external contributions that's fair. But what the AGPL startups don't emphasize is they require you to either assign your copyright to them or give them extra privileges to your contributions to be able to relicense it under non AGPL (if they don't they don't know what they are doing). AGPL is also not considered a very sa…
> The AGPL deception is you brand yourself as community-minded. As long as you don't rely on external contributions that's fair. But what the AGPL startups don't emphasize is they require you to either assign your copyright to them or give them extra privileges to your contributions to be able to relicense it under non AGPL (if they don't they don't know what they are doing).
There's nothing specific to the AGPL or startups here, it's a common model. The FSF themselves require copyright assignment if you want to contribute to FSF projects.
Re: Why we picked AGPL
#107Is there some AGPL equivalent on top of GPLv2 instead of GPLv3 After reading the rational for v2 for the Linux kernel, Ive always found v3 a bit off putting.
What rationale would that be? I doubt the FSF would write a version of the AGPL designed to let you use DRM to end-run around it if that's what you're getting at (you can always write such a license yourself, but, why?)
Re: Why we picked AGPL
#108Earlier quoted context omitted.
There are clear differences. [Let's say I am not a competitor and Amazonifying them] I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner. Even worse, let's say I am a paid customer for their support and run on their proprietary license…
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. That part is exactly the same under AGPL, no?
Strictly speaking you are correct. I concede that from an individual licensee perspective. The scenario I had in my head is under permissive, if the community forks, they would be on par with the original author. Under AGPL+CLA, if the community forks, the original author can sell "usable" licenses but the fork community will be stuck to developing an AGPL-only solution, which is a practical hinderance for the new community gaining any ground at all.
Re: Why we picked AGPL
#109Earlier quoted context omitted.
Genuine question, how does AGPL restrict use? From my reading of it, it is only ensuring that any modifications to the source code must be made available if you "distribute" the software, where distribution now includes hosting it as a service. It seems more or less in the original spirit of GPLv2 but updated for a SaaS driven world. If you consider v3 restrictive then you must also consider v2 restrictive, just in a…
Running a program, as a service or not, isn't redistribution. It is use. The original spirit of the GPL is about identifying people doing bad things we don't like and trying to prevent them. All those bad things have to do with redistribution, not with using the program. The AGPL is still about identifying people doing bad things we don't like, except now those people are just running the program. This is no differen…
> The original spirit of the GPL is about identifying people doing bad things we don't like and trying to prevent them. All those bad things have to do with redistribution, not with using the program.
It's not. It's about making sure users can fix the bugs in the software they want or need to use, and share those fixes with others. Rules about redistribution are a means to that end.
The GPL was originally written in an era of mainframes and terminals, the idea of running a program via some intermediate system is not novel. But no-one in that era would have dared try to argue that a program hadn't been distributed to you because it was running on a machine in a different building rather than one under your desk.
> This is no different from Adobe, Apple, Microsoft, ... identifying people using their software in ways they don't like, and crafting their EULA terms to turn those activities into a license violation.
If you make your equivalences broad enough then anything is equivalent to anything else. "This license is written in text, making it no different from that license that is written in text".
> A free software license can only use copyright law, and only be concerned with copying.
You're confusing ends and means. The free software movement was actively opposed to copyright law and wanted software to be uncopyrightable. But that was no reason not to use a copyright license that served their goals.
Re: Why we picked AGPL
#110Earlier quoted context omitted.
I think AGPL requires the whole cloud stack that's used by a deployment of this SW to be AGPLed as well.
If true, this license does nothing to mitigate the risk that a user may get locked into contracts they don't like, or the ability to continue to use the software if the developer goes bankrupt or is bought by a competitor. If you can't use the AGPL version now, you can't use it later either. And I don't see how it prevents "Cloud Vendors" from using it, but not everybody else as well.
Even if the (CLA-owning) organization changes the license, the last version available under the AGPL will always be available under the AGPL.
> If you can't use the AGPL version now, you can't use it later either.
Right. But you can use it now and later.
> And I don't see how it prevents "Cloud Vendors" from using it, but not everybody else as well.
Cloud vendors can use it. What they can't do is fork it and start making private changes that they do not release for others to use. Forking it is fine, making incompatible changes is fine, but keeping those changes proprietary is not.
The AGPL defends against competition from a big cloud operator, but not in the way you're thinking. It does not prevent the cloud operator from using or even modifying the software. It does prevent that operator from creating a competitive fork that benefits from starting with the AGPL code but then diverges in a way such that customers will want to pay the cloud operator for their up to date fancy version instead of the original project. I mean, they still could try to get people to pay for that, but the original project will have access to all of their changes so the cloud operator won't have any advantages when selling support or a license with different terms.