I love the AGPL. I can't imagine it becoming popular for generic business functionality in library form, but for highly-specialized libraries (in my case scientific with industrial applications) it was everything I was looking for --- not least because automated license scanners flag it and scare potential parasites away. It's also a great choice for complete pieces of software (such as DBs, as in this case) to offer a free tier for communal benefit, provided you're genuinely willing to let the project develop a life of its own if the open source community finds reason to mobilize around it.
For academic use AGPL compliance is a natural part of life anyway, for non-profits it's a little bit of effort but there's no fundamental objection, and when companies get involved it ensures that either my collaborators and I get a payout for SaaS-ification/proprietarization, or that it only gets used in internal tooling, which means that money gets redistributed to labor (often also to us via consulting fees or custom development arrangements anyway, since we know the code best).
It's a model for software development that I can really get behind.
I'm actually not a fan of this restrictive license and the even more restrictive contributor license that is in place here which is what enables them to sell closed source versions of the software and potentially close source entirely (as other companies have done). AGPL without this is not very practical for companies as it makes selling commercial licenses impractical and is a bit of a turnoff for commercial users.
> Grant of Copyright License. Subject to the terms and conditions of this Agreement, 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.
If you are happy to contribute code and then have them take it and sell it under a closed source license; or at a later stage just decide to relicense the whole thing as closed source; go for it. But most external contributors probably wouldn't like this.
Usually the effect that this has is that the OSS contributor community is pretty much exclusively employees of the company involved. I can't imagine third party companies agreeing on working on this or paying their people to work on this. Why would they?
> If you are happy to contribute code and then have them take it and sell it under a closed source license; or at a later stage just decide to relicense the whole thing as closed source; go for it.
Isn't this a core feature of the "unrestrictive" licenses you're a fan of? If you don't like freeloaders, BSD-/MIT-style licenses are even worse because they allow anyone, not just the maintainers, to sell your contributions in a closed-source product.
Open source does not necessarily mean open contribution. It may turn you off, but the tradeoff is that you can make the changes you need and run for your purposes. If your purposes is to make closed source software with it, you will need to pay for that privilege.
you can also just not accept code contributions from other people
> If you are happy to contribute code and then have them take it and sell it under a closed source license; or at a later stage just decide to relicense the whole thing as closed source; go for it. But most external contributors probably wouldn't like this.
bsd and mit licenses also allow this without a cla (that's the whole reason for using them instead of a strong copyleft like the gpl) and they seem to be very popular
I'm a fan of AGPL as well, but there's a point of possible confusion for GNU license variants I personally run in to and maybe others as well. It may be worth specifying which variant of the AGPL you are using, e.g. AGPL-3.0-only or AGPL-3.0-or-later.
I have no experience with the AGPL, but I really really like the idea of it. However, I get worried when I read takes like Hector Martin's [1]. In essence, he argues that it becomes very easy for the end-user to make even the most trivial of modifications to AGPL code or stuff associated to it and accidentally violate the license's quine requirement.
The best way to avoid any such issue is to contribute changes to the upstream project, which is our goal with the choice of license. We're hoping for a centralized ParadeDB project from which everyone can benefit.
Hector built up a strawman in that bug, and not a very good one. I'm surprised the Gentoo devs were as patient with him as they were, given he kept trying to argue his personal interpretations which are not in line with how the AGPL is generally understood by Gentoo and other distributions. And some of the things he claims are just plain wrong.
The point of an OSS license in these kinds of situations is pretty simple:
They need to pick a license which is salty enough so that big corporations cannot use it, but have to buy a special license from the authors.
Meanwhile they can support and benefit from the open source community without bureaucracy, and get a maximal userbase to create content on the web about this stack, and have a maximal number of people who know this stack and want to use it.
Absolutely. As the copyright owners, the authors of the software can always sell permissions to corporations. This allows software to become free. Stallman himself has suggested this to corporations:
People have pointed out to me that the above is not quite the same as what happens today with people building proprietary SaaS platforms. So I emailed Stallman to ask about the ethics of it. This was 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.
> Can the authors (holding the copyright) distribute code under a different license when there were external contributors under GPL?
No, if any contributions were made under the GPL, they'd have to get permission to change the license to AGPL from every contributor or remove their contributions.
Most projects like this require you license your contributions in a way that lets them sell non-AGPL licenses (see their Contributor License Agreement) https://cla-assistant.io/paradedb/paradedb
So basically they can do whatever they want with your contributions.
By default the contributors also hold copyright and need to consent to the separate licensing.
However, this is typically solved by using a contributor licence agreement (CLA) where all contributors click through a form before submitting a PR where they declare that they own the copyright for the PR and they give a license for the organization to relicense the work and derivatives. Sometimes the whole copyright is transferred to the organization in these agreements.
I didn't check but according to some comments here the CLA in this case is already embedded into the AGPL license.
In principle this scheme guarantees that the original organization always has special rights over all of the open source community, as they can dual license all the derivative works.
Where there is a will, there is a way. Big corporations could use the license and stick to its terms, but no, they don't want to. Better in their view to just take take take and never give. What they don't see however, and what is on no ones quarterly number sheet, is all the talent they don't attract.
I don't know about ParadeDB, but this was very off-putting for me in case of Minio when they switched to AGPL. If you check their answers to various license questions, they are essentially this: if you use Minio in your stack/product (for profit), then we recommend our commercial license or consult with a lawyer if your use case is covered by AGPL or not.
What me and I guess many others wanted was a simple yes/no to the following: if I use Minio in my stack without modifications (as a file server that my other services interact with via an API), do I have to AGPL all the stuff the touches Minio or not? And they do not want to answer this question. I do not understand why is it so hard to answer clearly. I understand that the majority of opinions is that it's fine to use without modifications, but I wanted a clear statement from authors of Minio. Failing that, I then decided to keep the pre-AGPL version for a while and have transitioned away from Minio since then.
This feels like dealing with government agencies where you go out of your way to get clarification to make sure you are doing everything correctly, but they refuse to give a clear answer to they can bother you about it later.
Copyright does not have clear answers. Teachers has always wanted a clear answer to "how many pages can I copy from a book", and they usually get the same answer. There is no cleanly defined number of pages, but fair use do exist so they have to apply they own judgement in each case.
The same questions has been asked about how many seconds of TV/radio is fair to copy, for example as stock footage or in reviews. Many people will say something like "3-5 seconds generally accepted", but each creator has to apply their own judgement per case.
What is a derivative work is one of the most debated aspect of copyright law, likely only second to fair use debates. Only a court of law has any real ability to give a clear answer and then only to a specific case.
The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work.
So, what is 'covered work'? The license says this:
A "covered work" means either the unmodified Program or a work based on the Program.
Do you still think it's clearly written license? To me it's dubious enough that I wanted an explicit answer from the authors of Minio. Failing to get it, I decided to move away from Minio.
The question isn't about modifications to the library/service itself, but whether with other code linking to it in any way is what you have considered a derivative work that should also be covered by the AGPL.
For a library I'd say that was a definite yes. For a service it is someone's less clear, some provide connective tissue (language bindings or other access modules) under less strict licenses which creates an obvious break in the chain, without that or very definite answers to the question on the post you replied to it is unclear how tightly coupled you need to be to need to use AGPL for your own work and I would err on the side of assuming (because it is GPL based) any coupling would have that effect.
Not that this would put me off using LGPL, but it is just as disconcerting, if not more so, to commercial interests, as the GPL is.
IANAL, but I'd also be worried that even if the project answers your question, maybe any one individual contributor to the project could sue you if they disagree.
Only if the project doesn't have copyright reassignment, of course.
> if I use Minio in my stack without modifications (as a file server that my other services interact with via an API), do I have to AGPL all the stuff the touches Minio or not
No and it's spelled out very clearly in the license.
I think the length of this HN discussion is evidence enough that AGPL isn't clear.
In my experience, organizations that use AGPL do so to 1) ward off an active non-paying community with its associated support cost, 2) claim open source to help convince you to buy their software/service, 3) hire skill-vetted programmers, 4) allow third-party security audits, and/or 5) avoid being jaded by someone that can market or host their solution better than they can.
Only after people badgered them to remove their claim that anything communicating with Minio gets infected by AGPL immediately. Their compliance page used to claim:
> Combining MinIO software as part of a larger software stack triggers your GNU AGPL v3 obligations. The method of combining does not matter. When MinIO is linked to a larger software stack in any form, including statically, dynamically, pipes, or containerized and invoked remotely, the AGPL v3 applies to your use. What triggers the AGPL v3 obligations is the exchanging data between the larger stack and MinIO.
That version has, unfortunately, not been archived at web.archive.org or such.
https://www.gnu.org/licenses/gpl-faq.en.html
"However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program."
I think you can interact with GPL/AGPL and retain your code propietary by:
- Don't modify the AGPL program.
- Run separatly, using docker container, vm etc
- Interact with CLI, REST API, filesystem, database etc
- Keep the AGPL interaction only to your program, non public consumption, minimum the surface of distirbution the code.
- Keep your code non directly interact, such as avoid use node npm dependencies directly, avoid library linking, use api gateway, use thirdparty module.
No it is not clearly spelled out. So I am wondering why you think it is clear. Perhaps you are misunderstanding the problem that is being raised? I’m not sure.
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.
> 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.
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.
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.
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?
> 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.
Every so often I run through the common set of licenses to double-check which one I want to personally use for my projects (both commercial and for fun), and I always end up back at AGPL. For me, it just strikes the right balance between open-source and restricting corporations from disproportionately profiting off of my labor.
> For me, it just strikes the right balance between open-source and restricting corporations from disproportionately profiting off of my labor.
A purely F/OSS company could potentially profit way more from your code than you do and still comply with the license. You'd be free to reincorporate their code back into yours, of course. But code isn't money.
That sounds proportionate to me. They get to make profits, and I get to use their improvements if they also benefit me.
This can foster more community than if MIT code were to be taken and locked behind closed doors, for profit and to no benefit for the devs that made it possible.
A gift freely given doesn’t care what the recipient does with the gift. This idea that corporations aren’t legitimate users of GPL software is simply anti-capitalist bitterness. The ability to run a service with GPL software is a feature, not a bug (or “loophole”).
> and restricting corporations from disproportionately profiting off of my labor.
This is anti the ethos of GPL [1]
And that's fine, you choose a list or rules that fitted with your wants, you don't have to respect A/GPL.
But time and time again we see most people on HN not respecting the A/GPL ethos they clam to follow and not understanding what A/GPL will mean in practice.
> disproportionately profiting
Off Topic to GPL. Corporations have provided more value to the world than any person. Which is almost a tautology since corporations are just groups of people working together. "Disproportionately profiting off of my labor" would mean they are providing amazing resources to people who need them.
You sound like you don't want others to succeed. Which is different to you need to make money to live.
[1] The legal/logical issues we see with AGPL are from trying to get the license to match the ethos. It's commendable they did stick it out.
I think trying to prevent disproportionate profit by big companies is plenty compatible with the ethos. The ethos of GPL is all about the end user, after all.
"Future-Proof: Thanks to the copyleft provision, cloud vendors cannot easily resell our project without our consent. This gives us confidence in our ability to monetize without fear of predatory competition. ParadeDB just turned one year old, and we’ve already been contacted by four cloud providers who, had we not chosen the AGPL license, may have privately forked and distributed ParadeDB."
Nothing in the license requires cloud vendors from reselling the project. They just need to make the source available?
Nothing. There is no need for consent. Just fork it and respect the agpl. You can do what you want as long as you respect the AGPL. So reselling is allowed.
This is a common misconception. Nothing in the text of the AGPL requires this whatsoever.
But it's a common enough misconception that my personal recommendation tends to be to just steer clear anyway, if you're planning to run a closed-source business. It's better to not get sued at all, than to get sued by someone who's wrong.
But for reference, the only text added to the AGPL in comparison to the GPL is section 13 here:
In other words, if you run an AGPL database and modify it, you need to provide your users with the source of your modified version.
Nothing remotely suggesting that the rest of your entire software stack becomes AGPL licensed. (In fact I often wonder how people are imagining that would even work. It would basically imply that you can't, for example, run AGPL software on a Windows server...)
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.
Readit News
For academic use AGPL compliance is a natural part of life anyway, for non-profits it's a little bit of effort but there's no fundamental objection, and when companies get involved it ensures that either my collaborators and I get a payout for SaaS-ification/proprietarization, or that it only gets used in internal tooling, which means that money gets redistributed to labor (often also to us via consulting fees or custom development arrangements anyway, since we know the code best).
It's a model for software development that I can really get behind.
Best of luck to you!
> Grant of Copyright License. Subject to the terms and conditions of this Agreement, 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.
If you are happy to contribute code and then have them take it and sell it under a closed source license; or at a later stage just decide to relicense the whole thing as closed source; go for it. But most external contributors probably wouldn't like this.
Usually the effect that this has is that the OSS contributor community is pretty much exclusively employees of the company involved. I can't imagine third party companies agreeing on working on this or paying their people to work on this. Why would they?
Isn't this a core feature of the "unrestrictive" licenses you're a fan of? If you don't like freeloaders, BSD-/MIT-style licenses are even worse because they allow anyone, not just the maintainers, to sell your contributions in a closed-source product.
Open source does not necessarily mean open contribution. It may turn you off, but the tradeoff is that you can make the changes you need and run for your purposes. If your purposes is to make closed source software with it, you will need to pay for that privilege.
win-win!
> If you are happy to contribute code and then have them take it and sell it under a closed source license; or at a later stage just decide to relicense the whole thing as closed source; go for it. But most external contributors probably wouldn't like this.
bsd and mit licenses also allow this without a cla (that's the whole reason for using them instead of a strong copyleft like the gpl) and they seem to be very popular
Do you have any insight on this?
[1] https://bugs.gentoo.org/737708
They need to pick a license which is salty enough so that big corporations cannot use it, but have to buy a special license from the authors.
Meanwhile they can support and benefit from the open source community without bureaucracy, and get a maximal userbase to create content on the web about this stack, and have a maximal number of people who know this stack and want to use it.
AGPL is perfect for this.
https://www.gnu.org/philosophy/selling-exceptions.html
People have pointed out to me that the above is not quite the same as what happens today with people building proprietary SaaS platforms. So I emailed Stallman to ask about the ethics of it. This was his reply:
But apparently it’s also used as a filter of who can interact and benefit from it.
But I don’t really understand all of it.
One thing I always wondered about selling separate licenses alongside GPL:
Can the authors (holding the copyright) distribute code under a different license when there were external contributors under GPL?
No, if any contributions were made under the GPL, they'd have to get permission to change the license to AGPL from every contributor or remove their contributions.
Most projects like this require you license your contributions in a way that lets them sell non-AGPL licenses (see their Contributor License Agreement) https://cla-assistant.io/paradedb/paradedb
So basically they can do whatever they want with your contributions.
However, this is typically solved by using a contributor licence agreement (CLA) where all contributors click through a form before submitting a PR where they declare that they own the copyright for the PR and they give a license for the organization to relicense the work and derivatives. Sometimes the whole copyright is transferred to the organization in these agreements.
I didn't check but according to some comments here the CLA in this case is already embedded into the AGPL license.
In principle this scheme guarantees that the original organization always has special rights over all of the open source community, as they can dual license all the derivative works.
What me and I guess many others wanted was a simple yes/no to the following: if I use Minio in my stack without modifications (as a file server that my other services interact with via an API), do I have to AGPL all the stuff the touches Minio or not? And they do not want to answer this question. I do not understand why is it so hard to answer clearly. I understand that the majority of opinions is that it's fine to use without modifications, but I wanted a clear statement from authors of Minio. Failing that, I then decided to keep the pre-AGPL version for a while and have transitioned away from Minio since then.
The same questions has been asked about how many seconds of TV/radio is fair to copy, for example as stock footage or in reviews. Many people will say something like "3-5 seconds generally accepted", but each creator has to apply their own judgement per case.
What is a derivative work is one of the most debated aspect of copyright law, likely only second to fair use debates. Only a court of law has any real ability to give a clear answer and then only to a specific case.
"This License explicitly affirms your unlimited permission to run the unmodified Program."
In the Basic permissions of the actual content of the license https://github.com/minio/minio/blob/master/LICENSE
It's not that difficult to parse if you actually read it top to bottom instead of skimming.
For a library I'd say that was a definite yes. For a service it is someone's less clear, some provide connective tissue (language bindings or other access modules) under less strict licenses which creates an obvious break in the chain, without that or very definite answers to the question on the post you replied to it is unclear how tightly coupled you need to be to need to use AGPL for your own work and I would err on the side of assuming (because it is GPL based) any coupling would have that effect.
Not that this would put me off using LGPL, but it is just as disconcerting, if not more so, to commercial interests, as the GPL is.
Only if the project doesn't have copyright reassignment, of course.
No and it's spelled out very clearly in the license.
In my experience, organizations that use AGPL do so to 1) ward off an active non-paying community with its associated support cost, 2) claim open source to help convince you to buy their software/service, 3) hire skill-vetted programmers, 4) allow third-party security audits, and/or 5) avoid being jaded by someone that can market or host their solution better than they can.
> Combining MinIO software as part of a larger software stack triggers your GNU AGPL v3 obligations. The method of combining does not matter. When MinIO is linked to a larger software stack in any form, including statically, dynamically, pipes, or containerized and invoked remotely, the AGPL v3 applies to your use. What triggers the AGPL v3 obligations is the exchanging data between the larger stack and MinIO.
That version has, unfortunately, not been archived at web.archive.org or such.
Some remnants of the old compliance text are still mentioned: https://github.com/minio/operator/issues/2030
I think you can interact with GPL/AGPL and retain your code propietary by:
- Don't modify the AGPL program.
- Run separatly, using docker container, vm etc
- Interact with CLI, REST API, filesystem, database etc
- Keep the AGPL interaction only to your program, non public consumption, minimum the surface of distirbution the code.
- Keep your code non directly interact, such as avoid use node npm dependencies directly, avoid library linking, use api gateway, use thirdparty module.
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.
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.
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:
> 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.
https://github.com/paradedb/paradedb/blob/6b829681190684f241...
> 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.
https://cla-assistant.io/paradedb/paradedb
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.
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.
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.
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.
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.
A purely F/OSS company could potentially profit way more from your code than you do and still comply with the license. You'd be free to reincorporate their code back into yours, of course. But code isn't money.
This can foster more community than if MIT code were to be taken and locked behind closed doors, for profit and to no benefit for the devs that made it possible.
This is anti the ethos of GPL [1]
And that's fine, you choose a list or rules that fitted with your wants, you don't have to respect A/GPL.
But time and time again we see most people on HN not respecting the A/GPL ethos they clam to follow and not understanding what A/GPL will mean in practice.
> disproportionately profiting
Off Topic to GPL. Corporations have provided more value to the world than any person. Which is almost a tautology since corporations are just groups of people working together. "Disproportionately profiting off of my labor" would mean they are providing amazing resources to people who need them.
You sound like you don't want others to succeed. Which is different to you need to make money to live.
[1] The legal/logical issues we see with AGPL are from trying to get the license to match the ethos. It's commendable they did stick it out.
I think trying to prevent disproportionate profit by big companies is plenty compatible with the ethos. The ethos of GPL is all about the end user, after all.
> would mean they are providing amazing resources
No it doesn't mean that.
If by value you mean: "have increased gini coefficient", then yes, corporations have done that.
"Future-Proof: Thanks to the copyleft provision, cloud vendors cannot easily resell our project without our consent. This gives us confidence in our ability to monetize without fear of predatory competition. ParadeDB just turned one year old, and we’ve already been contacted by four cloud providers who, had we not chosen the AGPL license, may have privately forked and distributed ParadeDB."
Nothing in the license requires cloud vendors from reselling the project. They just need to make the source available?
What am I missing?
But it's a common enough misconception that my personal recommendation tends to be to just steer clear anyway, if you're planning to run a closed-source business. It's better to not get sued at all, than to get sued by someone who's wrong.
But for reference, the only text added to the AGPL in comparison to the GPL is section 13 here:
https://www.gnu.org/licenses/agpl-3.0.en.html
In other words, if you run an AGPL database and modify it, you need to provide your users with the source of your modified version.
Nothing remotely suggesting that the rest of your entire software stack becomes AGPL licensed. (In fact I often wonder how people are imagining that would even work. It would basically imply that you can't, for example, run AGPL software on a Windows server...)
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.
You can only contribute when you accept the CLA at [1] which gives them the right to license your contributions under said commercial license.
[1] https://cla-assistant.io/paradedb/paradedb
https://github.com/paradedb/paradedb/blob/dev/CONTRIBUTING.m...
Now it's up to you whether to sign that CLA to upstream your changes.
You're welcome to maintain a fully AGPL fork if you don't like that.