Note that they can't "take it away" completely. The AGPL ensures that the community AGPL licensed code will always have to be open source, and that anybody else can use it too. So a developer who has contributed to an AGPL codebase cannot be denied access to it. Due to the AGPL license, any code will always be open source and thus the CLA cannot claim exclusivity over the contributed code and prevent its (re)use by the developer in any manner.
The only concern then is ethical - will the developer be monetarily compensated if the product makes money? I believe they should be. Other open source developers may disagree.
Note also that for a commercial open source project, a CLA can offer some legal protection - by signing a CLA a developer declares that they own the copyright on the code, which reduces the liability of the commercial venture behind the open source product if someone contributes "pirated" code.
Is this actually legally binding? What would be the difference w.r.t. informed consent, between DCOs and the "I have read and accept the terms and conditions" checkboxes from most websites?
It also gives me similar vibes to the Do-Not-Track HTTP header since both can be enabled by default.
DCO is something like "Signed-of-by: me myself <me@example.com>" you have to actively add to your contributions, which is usually a conscious and willful act that is far more complex than blindly ticking a box (or even leaving a pre-ticked box ticked). Since that bar is higher, I think the legal weight should be higher.
CLA-Assistant is also similarly simple to fill out, so that can't be the difference there...
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.
> The AGPL ensures that the community AGPL licensed code will always have to be open source, and that anybody else can use it too.
That's true in the sense that there will always be an AGPL version, but it's not true that "anybody else" can use it to. In many situations you need to acquire a non AGPL license from the original copyright holder to be legally able to use the software in certain environments. That's why CLAs are important so that there is always a copyright holder that can give you a non AGPL version.
If your business depends on some form of closed-source codebase, than yes, an AGPL codebase will not suit your need. But from an opensource developer perspective it doesn't matter. For example, if you release your source code under the more freer license (like BSD, MIT or Apache), you can indeed close source your code. But so can others. I can use your source code, add more features to it, and close source it. I would be under no obligation to share my code with you, while also having the right to use your code as I please. This is not so with the AGPL. An AGPL + CLA makes this explicit - a developer has to voluntarily give away this right with a CLA. (And this gives developers some additional leverage).
Unless you define Open Source developer as Hobby only licenses matter. I’m an Open Source developer and I want to be able to use software no matter the situation.
And as a result free software was released to the world which everyone can freely use and modify under the AGPLv3 terms. And unlike permissive open source licenses, only the copyright owners have the right to sell proprietary versions. They maximized freedom and secured a business model in one fell swoop. People are only required to transfer copyright if they want to upstream their code, they can always keep their copyrights by maintaining a fork instead.
It's pretty much perfect. Stallman himself suggests selling exceptions to the GPL as a viable business model for companies, Qt being the number one example. I actually emailed Stallman and asked what he thought about this new AGPLv3 SaaS pattern, here's his reply:
> It is my understanding that as the copyright holders
> they have the right to do it without any problems.
> They leverage the AGPLv3 to make it harder for their
> competitors to use the code to compete against them.
I see what you mean. The original developer can engage
in a practice that blocks coopertation.
By contrast, using some other license, such as the ordinary GPL,
would permitt ANY user of the program to engage in that practice.
In a perverse sense that could seem more fair, but I think it is
also more harmful.
On balance, using the AGPL is better.
Their github repo just says AGPL 3.0. Can you point me to the other constraining terms are? This would be quite interesting (like the "Open Core" people). And when I say "interesting" I don't mean a positive feature.
The project is licensed under AGPL, but outside contributors have to sign away their rights with CLA if they wish to contribute to the main project. It's in CONTRIBUTING.md [1]
> In order for us, Retake, Inc. (dba ParadeDB) to accept patches and other contributions from you, you need to adopt our ParadeDB Contributor License Agreement (the "CLA"). The current version of the CLA can be found here.
> You hereby grant to the Company and to recipients of software distributed by the Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
TL;DR: my quick read is that they are trying to do the right thing.
My not super-close reading is that this is actually reasonable (but note: I wrote the original GNU blanket assignment back around 1989 or 1990 so you may consider my perspective bogus).
This agreement says that you confirm that you have the right to license your contribution (that what you wrote isn’t actually your employer’s), and that they can use it without restriction, even if there’s something patented in the submission. It doesn’t stop you from using the code for something else. But you can’t come back later and say “hey, yank out these lines of code which I sent you long ago”. It's not even an assignment -- you retain ownership.
If I were doing this, personally, I might add something to the effect of “btw if the company tries to change the license in a way incompatible with the AGPL 3.0 or later versions this license I have you becomes void” but that could implicitly be in there (if explicit, I missed it in my quick read).
Interesting. I think concerns about legality of contributions are completely understandable.
But doesn't this CLA in particular (and most CLAs out there generally) assign the company behind it a license to distribute all contributions under any license they wish? Specifically the part that I quoted where contributors give them an "irrevocable copyright license" to "sublicense" their contributions?
As far as I understand, this allows them to unilaterally re-license the project as a whole (to proprietary or non-free open source) without asking contributors for permission.
The only way I'd agree to a CLA is if it included explicit language that ensured that they couldn't do this, e.g. "You hereby grant [...] under the terms of the AGPL v3 license", but I'm not a lawyer.
> As far as I understand, this allows them to unilaterally re-license the project as a whole (to proprietary or non-free open source) without asking contributors for permission.
That's generally how CLAs work, to enable re-licensing. For many commercial AGPL projects that's also needed because the copyright holding entity will sell/provide non AGPL versions to customers that legally cannot use AGPL software.
> But doesn't this CLA in particular (and most CLAs out there generally) assign the company behind it a license to distribute all contributions under any license they wish?
Yes. CLA requirements for commercial AGPL open-source projects actually highlights an important feature of the AGPL - you need explicit permission from the developers to use their code in a proprietary codebase.
Codebase under a permissive open-source license like BSD, MIT, ZLIB etc. can be used by anyone and even packaged into a closed source codebase (with a proprietary license) even without a CLA. All that such license demand is that you do not deny public attribution to the developers and highlight the original license (here's an example from the old Opera Presto browser which was a proprietary closed browser with open source components in it - https://imgur.com/a/KDavWLd ). On the other hand, an AGPL codebase cannot be packaged into a proprietary codebase because the license requires not only attribution but also the requirement that the all source code, even the non-AGPL parts, has to be compulsorily shared if you link it with an AGPL codebase (i.e. it forces all code to be always open source).
The underlying philosophy of the xGPL license is the right to repair the software you use. And you can only do that if you have access to the source code of the software. Under AGPL it is illegal to close-source an AGPL codebase. But, AGPL also recognizes the rights of a developer on the code they created. It thus doesn't prevent the original developer from re-licensing their own code or even transferring the rights to another. Thus, in some way, AGPL actually forces the CLA requirement (if you want to distribute a software under proprietary license) and let's the developer decide if they want their code to be reused in a proprietary codebase.
"In order for us, Retake, Inc. (dba ParadeDB) to accept patches and other contributions from you, you need..." makes it sound like their hands are tied, you must assign copyright, there's no other option.
In reality, this is a (contributor-hostile) choice they made. They could have made different ones.
But you aren’t assigning copyright, you’re getting a license to bundle the contribution with the rest of the package.
And they don’t feel safe including a patch without a license to use it. Not an unreasonable position to take.
The wording is explicit (italics mine):
> You hereby grant to the Company and to recipients of software distributed by the Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to…
When you contribute code to an AGPLv3 project without a CLA, you are also giving them a license to use your code. The name of that very license is... 'APGLv3'!
The CLA means you're giving them an additional license: one that lets them do things that the AGPLv3 wouldn't, like use your code in proprietary software.
This is common for FOSS-maintaining organizations that want to use dual-licensing as part of their revenue strategy. Users (including organizationswho are comfortable publishing any downstream changes they might make under the terms of the copyleft license use the free version. Users who are not can instead choose to purchase a proprietary license, like they would with closed-source software.
Often there's some hope that as users of F/OSS, the developers and users are overlapping groups, and there's enough alignment of interests there to provide some level of assurance that the developers (or publisher, in the case of a corporation or collective entity) won't suddenly make drastic changes without user input. (Often, too, that isn't actually the case.) A CLA can give the developer the ability to make such drastic changes as taking a copyleft project and creating a closed-source fork. In cases where the development work is supplied predominantly by a single commercial entity, that means that they can essentially orphan the project out from under you, leaving the open-source version of their software an unmaintained vestige of a proprietary commercial offering, at any time.
So CLAs involve a lot of trust or a lot of risk. Some companies have set up non-profit foundations to be the official stewards of their dually-licensed software so that the chief/commercial maintainers of the software can leverage the dual-licensing revenue strategy while fostering strong community trust. See, for example, the Free Qt Foundation. When Google wanted a CLA as insurance against patent litigation for Kubernetes, they did a similar thing and set up the Cloud-Native Compute Foundation so that Kubernetes could have a 'trustworthy CLA', so-to-speak.
I hope that clears up both why upstream developers might sometimes want a CLA of this kind and why downstream developers can sometimes be leery of them.
Honestly I think this is fine, especially how they've done it. Most CLAs seem to require copyright assignment, but theirs does not. Outside contributors keep their copyright, but grant the company a license to (more or less) do whatever they want with it.
I think we're at a bit of a crossroads here. Enough (smaller) companies have been bitten by the likes of Amazon monetizing their code and crushing the original developers' monetization strategy. So we see some companies turning to non-F/OSS "source available" type licenses instead. This is bad for the open source community as a whole.
IMO, AGPL+commercial is a fine compromise, and companies need to be certain that if they take contributions from the community, that they can still sell commercial licenses for the whole product, including the contributions, without issues in the future. Requiring contributors to assign copyright is one simple way to do that, but I think the path this company has chosen is a lot nicer in letting contributors keep ownership over their contributions.
For a piece of software where the expectation is that the company is going to be doing 90% of the work, and outside contributions will be relatively small, this seems entirely fair to me.
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 under AGPL in a forked repo.
The alternative is that if you're making meaningful contributions then it's in the company's best interest to hire you full time to do it.
Contributing upstream can benefit the ecosystem around the project, and the money that comes from commercial licensing also benefits it. In some cases the project would die if it didn't have the commercial side. They're not running a charity and if they aren't generating enough revenue they'd likely be working on something else rather than maintaining a FOSS project that doesn't make any money.
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 here seem to miss is that all permissively licensed software is vulnerable to the same kind of maneuver that copyleft+CLA software is. If MIT or Apache don't scare you, neither should GPL+CLA.
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.
> 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.
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.
> 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.
You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor strikes me as somewhat ironic here: what, the same deal that you give to your own customers for your own product is one you simply 'can't' take yourself because it's not 'reasonable'?
> If you are a sufficiently large commercial entity, you are probably wise to act as if it is proprietary.
But right about this. In the scenario you describe, you're a customer under the proprietary license— the kind of dependency your proprietary software product has on the software is the same kind it might have on any other proprietary software. The AGPLv3 version is not a backup option for you.
And it's true that the dual-licensing game the original vendor has set up is one that only they will ever be allowed to play.
If my company were considering purchased dual-licensed AGPLv3 software, I'd give advice like the following:
> It's great for the wider public that there is an open-source version of this exact same software our there. But what we're considering buying here is not that— what we're considering buying is proprietary software. For us, all that the availability of that open-source license means is that this is proprietary software whose source code would be easy for us to inspect, and that upstream might even accept our patches for issues that we encounter. I think both of those things are huge advantages! But if this vendor gets bought out or shuttered, we could potentially be left in the lurch much as we would if the software were exclusively proprietary. That's often an acceptable risk, in my opinion, and it's certainly one that our company has deemed acceptable with many past and present proprietary software purchases. But we should note that on the assessment: if we buy this, we're not buying or depending on open-source software; we're buying and depending on proprietary software.
All that assuming, of course, that the proposition is to use the AGPLv3 software in a user-facing, proprierary web service under the assumption that the copyleft component of the AGPL extends to that web service. If we were evaluating it for use in an internal service, where the end users are our own employees, or an external-facing service that we'd be comfortable releasing under the GPL, or we think that the way we want to use it would not require any license changes for us even if we take thw AGPLv3 version, I'd instead say something like
> Ask the lawyers as always, but I don't foresee any problems. I think this is great and I'd love to use it. If our legal people aren't used to considering copyleft licenses, can we have them consult with the FSF or the SFC or the EFF or something before they make a decision about this? Is that a thing?
Anyway, I agree with you about how being the customer (under the proprietary license) of a company like this is different from being the customer (for support services only) of a company who publishes permissively-licensed free software. I don't agree, though, that the dual-licensing thing is a trick! I think it's totally possible for everyone to go into that kind of arrangement eyes open and be happy with it. I hope and expect that's the goal for companies like that of TFA.
> You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor strikes me as somewhat ironic here: what, the same deal that you give to your own customers for your own product is one you simply 'can't' take yourself because it's not 'reasonable'?
I am not discussing ethics or morality here, just practicality, and yes, from the perspective of a user that is not primarily releasing open source. Note that it's somewhat different and more general than your characterization. I might be in another business, not software, but unwilling to touch AGPL within my infrastructure due to risk of virality. Strictly speaking, I am not a "proprietary software vendor" as I am not even in the software business, primarily. Nevertheless, your general point stands.
I am not arguing it is bad. Simply that I would not characterize AGPL+CLA as "no vendor lock-in because open source." I put it right in the bucket of e.g. Oracle proprietary database. I am not saying it is bad or totally unreasonable. I just don't buy up the marketing koolaid.
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 safe license by large organizations even if you want to run it internally unmodified, alongside the rest of your application. Many big companies have blanket bans on AGPL.
What happens if you (the contributor) fork the project, make a really great feature in your own fork, make it available as the license requires, then the startup integrates changes from the fork back into their own project. Does this then prevent them from ever changing the license away from AGPL?
Yes. If they do it they will be able to license the form back as AGPL but that wouldn't let them license the new thing under their commercial license (effectively useless commercially). At that point they are a peer with you.
Some startups may not know this or knowingly violate 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).
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.
Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.
Secondly, don’t equate the FSF with any other company. The FSF is in the unique position in that the FSF could change the GPL if they wanted to. If you use the GPL/AGPL, the FSF is inherently trustworthy; therefore, it’s completely reasonable to also trust the FSF with a copyright assignment.
> Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.
The FSF requires copyright assignment for many (possibly no longer all?) of their own projects, e.g. GnuTLS. Of course it's up to an individual project whether it requires it (how could the FSF possibly control what some unrelated project does?), but on those projects that the FSF themselves run (or at least many of them, and traditionally it was all of them), they require it.
> The FSF is in the unique position in that the FSF could change the GPL if they wanted to. If you use the GPL/AGPL, the FSF is inherently trustworthy;
They cannot change the GPL. They can publish new version of it, and recommend that you license your project with a term that permits it to be used under those new versions, but this is not obligatory (and notably e.g. the Linux kernel does not).
> The FSF requires copyright assignment for many (possibly no longer all?) of their own projects
The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers. Which is what I wrote. The fact that many projects do choose to require copyright assignment does not make you be less wrong when you said that the FSF requires it.
> They cannot change the GPL.
Technically true. But the FSF can publish a new version of the GPL, which all GPL-licensed software using the “or any later version” language, which is most GPL software, will then use. Linux is an oddity here.
> The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers.
And in the case of their own projects, the projects where the FSF is the project/the maintainers, what is it they do? They require copyright assignment.
Many GNU projects are maintained directly by the FSF/GNU (the same entity; their own statements acknowledge that they share personnel and have no clear boundary between them). And for many more projects they hold the copyright and provide the funding/hosting/etc. and the named maintainer is either a member or affiliated with the FSF/GNU, which suggests they exercise some control over it (e.g. the published hosting requirements for Savannah say that projects they host "should" follow the GNU hosting standards, which include requiring copyright assignment to the FSF if the FSF holds the copyright).
Well, requiring copyright assignment (not just a CLA) is in their published rules for using Savannah, and something almost all major GNU/FSF projects did in the past. Even if it's now something they merely encourage rather than require (and I'd be interested to see a public confirmation of this) my point stands.
Importantly, GPL does not include such line. That line is not part of the GPL. Critical software such as Linux famously do not have that and are not GPLv3 for example.
The Author can choose to license the Copyrighted Work under various licenses. The common boilerplate that many Authors of GPL software choose to use is a boilerplate that says they are licensing their Work under GPL version X or any later versions supplied by FSF. That boilerplate is Author's declaration of license contract and not the license itself.
Basically the Author is directly saying (not through the GPL text) that "I trust FSF to come up with future licenses and call whatever they want GPL version Y [Y>X] and I'll be willing to license my work under that license sight-unseen also."
If I accept their license on 2024-08-14 to use their software, they can do whatever they want to the license after that, but they won't be able to revoke my license to use the code as of 2024-08-14 under the license present to me on 2024-08-14.
No update on the license can retroactively change what I agreed to.
The model is equivalent. Everything else is different.
FSF's structure, purpose, history and guardrails against non-hijacking make it distinct from a startup whose purpose is to claim "open source" but preclude Amazon and keep their revenue stream. Nothing against them or their business model; it's their prerogative, of course. So is the community and customer's read on their future actions. To claim you should assume they are the same is preposterous and/or fooling yourself. Criminals and police officers both have guns too. Doesn't make them identical.
Organisations that start by claiming to be open-source and rug-pulling are something to be wary of. But neither AGPL nor CLAs are a particular red flag for that. Plenty of well-behaved organisations use CLAs or copyright assignments, and plenty of badly-behaved organisations use licenses other than the AGPL (e.g. Redis had a 3-clause BSD-style license but still did the same thing).
Can’t really refute a hypothetical. Is there a polymarket bet for that? I will categorically take the under on your position for any company doing CLA with AGPL. The intent is so glaringly obvious.
