[dns_snek]

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.

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

[gumby]

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

[dns_snek]

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.

[the_mitsuhiko]

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

[thisislife2]

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

[growse]

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.

[gumby]

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…

[pxc]

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.

[warkdarrior]

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.