Comment by JohannesSuenden | Hacker News Reader

Comment by JohannesSuenden | Hacker News Reader

Parent Full thread

JohannesSuenden

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.

Best of luck to you!

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.

Yes. I think what makes some people unhappy is the perceived inequality: you can do whatever you want with my contributions, but I can't do whatever I want with the software.

But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).

If you want a closed source license, use a closed source license. Nothing wrong with that; many companies do that. This particular license combination just creates the illusion of openness without most of the benefits for would be contributors.

> But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).

That's the view of a single company that wants exclusive control, not the view of a company that wants to create a healthy OSS community. Healthy OSS communities tend to have more than one company involved and a diverse group of contributors. That's why OSS licenses exist that protect their mutual rights. It's a necessary compromise to prevent any contributor having that kind of power and allow them to collaborate and share code. This is the opposite; and it cannot create a healthy OSS community.

Which raises the question of what the point is of using this kind of licensing? I don't think it's about soliciting outside contributions as this kind of actively discourages that. And why else would you open source something?

> And why else would you open source something?

It's nice to know when you're building something on top of other tech that if you need to, you can dig in to the code and fix issues. If the company folds, and you rely on their tech, you can continue to maintain it. If you want to look at their code to see how something works, you can do that. If you want to hire somebody to do a security audit on it, you can do that. If you're picking software to build with, having the source code be open or available is a positive.

And there's no downside to companies doing this. I see this happening frequently: people getting upset at companies that do some kind of sort-of-open-source/source-available thing, because they think the company is just out to get their free labor. If you don't want to give them free labor, then don't.

And besides, they are using AGPL! OSI-approved! What more can you ask for? That the company either dissolve completely, so that their software may become a garden on their grave, tended to by a community of free engineers, or else must remain cloistered and strictly closed? You don't need to celebrate it, but I just don't see the point in pooh-poohing this.

> But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).

True. But not all software has to be commercially viable, arguably the most useful/critical and yet valuable isn't - currently my list is Linux, git, Postgres, Python, dozens of Python libs (perhaps thousands, if I go down the dependency trees).

Declaring my biases: I'm partial to GPL licenses and believe providing value to users is more important than making life easier/profitable to developers. IMO, the difference between GPL-style and BSD-style licenses is not being "restrictive" or not, but who gets restrictions (end users and developers being on opposing ends).

While I agree with you that these are non-commercial, by now many of them have very big commercial backings. Many Postgres core contributors work at Microsoft, AWS, etc. who make billions of dollars selling Postgres-as-a-Service today.

Those projects aren't inherently commercial, and great software can be built by passionate hobbyists, but often times the two go hand-in-hand

If you need something else, you pay for it.

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!

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

Blog author here. I couldn't agree more. Thank you for your kind words and for sharing the academic perspective of using the AGPL - super interesting!

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.

That's fair. We use AGPLv3. I haven't seen any AGPL project that wasn't using v3, so we decided to keep it short for readability, but you bring up a very good point.

AGPL is great; CLAs are not.

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.

Do you have any insight on this?

[1] https://bugs.gentoo.org/737708

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.

> 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.

This I understand. But it doesn't really address Martin's worry about an accidental modification. Or apparent confusion about what constitutes modification.

There's no accidental modification.

> Not true. There is no need to accept the license if you exercise only your statutory rights, which in many jurisdictions includes the right to run the program and to patch it if necessary (e.g., for compatibility with other programs).

Interesting. Do you have any clarification about which these "many" jurisdictions are? Like, can we expect this to be the case in most of the world?

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.

Could you elaborate a bit with specifics? I feel both sides are just opining, and I'd love to know where to stand on a license, the main idea of which I love.

Reply on news.ycombinator.com