Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we picked AGPL

blog.paradedb.com

Post reply on HN
Print view View original

71–80 of 312 posts

Re: Why we picked AGPL

#71

Post by kazinator »

fweimer wrote: post #51
kazinator wrote: post #6

Earlier quoted context omitted.

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 AGPL does not restrict running the program. Only if you run modified versions, things get complicated. That being said, I think the AGPL is only appropriate for programs that come with a built-in source redistribution mechanism that ensures that modified versions automatically comply with the source code redistribution requirement.

You realize that would create a problem for some organization whose idiot employee combined proprietary code with the AGPLed program and the thing automatically redistributed the whole infringing mess to the world.

Even if there were safeguards against such a situation, someone would blow past them.

Re: Why we picked AGPL

#72

Post by wittystick »

Hamcha wrote: post #32

Correction: they chose AGPL with a poison pill (CLA) so they can benefit from it and take it away whenever they want more.

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.

Re: Why we picked AGPL

#73

Post by warkdarrior »

gumby wrote: post #66
growse wrote: post #50

Earlier quoted context omitted.

The duplicitous language is a bit slimy here. "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-fre…

Yes, the CLA says that you give them a license for them to in turn sublicense your code to others in any way they want.

Re: Why we picked AGPL

#74

Post by warkdarrior »

jay_kyburz wrote: post #53

I don't understand why they say "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 Parad…

I think AGPL requires the whole cloud stack that's used by a deployment of this SW to be AGPLed as well.

Re: Why we picked AGPL

#75

Post by pxc »

gumby wrote: post #66
growse wrote: post #50

Earlier quoted context omitted.

The duplicitous language is a bit slimy here. "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-fre…

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.

Re: Why we picked AGPL

#76

Post by wavemode »

warkdarrior wrote: post #74
jay_kyburz wrote: post #53

I don't understand why they say "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 Parad…

I think AGPL requires the whole cloud stack that's used by a deployment of this SW to be AGPLed as well.

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:

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

Re: Why we picked AGPL

#77

Post by pxc »

wittystick wrote: post #72
Hamcha wrote: post #32

Correction: they chose AGPL with a poison pill (CLA) so they can benefit from it and take it away whenever they want more.

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

Re: Why we picked AGPL

#78

Post by warkdarrior »

remram wrote: post #57
kazinator wrote: post #6

Earlier quoted context omitted.

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…

> Running a program, as a service or not, isn't redistribution. It is use. This is not how I see it at all. The ones using it are the users, and if they sit across the network you are distributing it in a very tangible sense. The idea that the admin running a service is the one doing the "use" and not the users of your service is debatable to say the least.

So when you compile a program and distribute over the network as a binary, you are also distributing the compiler that created the binary?

Re: Why we picked AGPL

#79

Post by pxc »

iaaan wrote: post #3

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.

Re: Why we picked AGPL

#80

Post by pxc »

kazinator wrote: post #23
graemep wrote: post #19

Earlier quoted context omitted.

> The AGPL is still about identifying people doing bad things we don't like, except now those people are just running the program. Its the same "bad thing" as distributing a modified binary without the source. Its a way of denying end users access to the source code. You can do whatever you like with AGPL code, as long as you make the source available. it is VERY different from saying "you cannot do this with your so…

The AGPL is absolutely a EULA. The user of a program is the one who installs it somewhere and runs it. Outside people interacting with the program are visitors. They don't have the source code because they don't have the program at all in any form. It has not been distributed to them. The source code to the program doesn't even do them any good. They cannot use that to prevent harms perpetrated by the operators of th…

It might be a ULA, but it's hardly an EULA. The party hosting a web service is not an end user. The end user is that party's customer.
Post reply on HN