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

261–270 of 312 posts

Re: Why we picked AGPL

#261

Post by gspr »

bityard wrote: post #197
gspr wrote: post #165

Earlier quoted context omitted.

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

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.

Re: Why we picked AGPL

#262

Post by gspr »

philippemnoel wrote: post #217
gspr wrote: post #165

Earlier quoted context omitted.

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.

Re: Why we picked AGPL

#263

Post by thisislife2 »

the_mitsuhiko wrote: post #151
thisislife2 wrote: post #47

Earlier quoted context omitted.

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 t…

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

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

Re: Why we picked AGPL

#264

Post by dspillett »

camgunz wrote: post #258
dspillett wrote: post #241

Earlier quoted context omitted.

The "or very definite answers to the question" is important there. Linus has explicitly answered the question, and if you use any of the Linux headers then yes you should release that software under the GPL. Under this circumstance your "which is definitely not the case" is incorrect. [EDIT: after reading the information in the link provided by actionfromafar, I'm pull that back a bit: headers marked appropriately ca…

> That is certainly the case for LGPL, but by my understanding it isn't for GPL nor by extension AGPL. If you don't modify, you have no obligations. Easy.

Nope. That is LGPL. Under (A)GPL if you make a derivative work you have obligations even if you do not modify. Easy.

[Well, not so easy, as this discussion and the likes of Minio saying “get your own lawyer to tell you what our licence says” illustrate – what constitutes a derived work is apparently not objectively well-defined]

Don't believe me? Ask Google and their vast legal team: https://opensource.google/documentation/reference/using/agpl...

Re: Why we picked AGPL

#265

Post by dspillett »

camgunz wrote: post #257
dspillett wrote: post #246

Earlier quoted context omitted.

I'm not sure that interpretation is correct. I don't read the intention that way (but I'd have to reread the licenses on detail to refresh myself before speaking more definitively). Having said that, the fact that minio's documentation answers the question with a shrug and says "lawyer up" (see https://github.com/minio/minio/blob/master/COMPLIANCE.md ) seems quite telling.

I mean, they have a strong incentive to get you to buy a commercial license. I'm not surprised they're uninterested in giving you free legal advice in service of not paying them.

That isn't what they say though. Their statement reads as “we don't actually fully know how the licence we have chosen works”.

The answer to “can I do X with your product?” shouldn't, in a reasonable world, constitute expensive legal advice. It feels rather shifty to me.

Re: Why we picked AGPL

#266

Post by dspillett »

camgunz wrote: post #232
richardwhiuk wrote: post #198

Earlier quoted context omitted.

That's GPL, not AGPL. The AGPL license implies that communicating with it over the network is sufficiently to count as a violation.

If you diff them, you'll see the AGPLv3 is essentially the GPLv3 with this extra clause added: "13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity t…

If connecting over the network doesn't constitute linking in a way that imposes AGPL obligations, then Google's position, or the reason they state for it, (https://opensource.google/documentation/reference/using/agpl...) is simply wrong. No offence, but I'm going to believe their expensive legal team not being able to find a way around this means that your interpretation is not correct.

Re: Why we picked AGPL

#267

Post by teddyh »

lmm wrote: post #237
teddyh wrote: post #134

Earlier quoted context omitted.

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…

> 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 pro…

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

Re: Why we picked AGPL

#268

Post by teddyh »

richardwhiuk wrote: post #201
powersnail wrote: post #195

Earlier quoted context omitted.

> The FSF is in the unique position in that the FSF could change the GPL if they wanted to. They can publish new versions of GPL if they want to. They can't retroactively change the terms that users of the software and contributors agreed to. Just like any code owners who has the complete control of copyright can publish their code under a different license.

GPL includes a line which allows it to be used under any future version of the GPL. So if you license under GPLv2, the FSF can create GPLv5 and add whatever clause they like in it.

> the FSF can create GPLv5 and add whatever clause they like in it.

They cannot add anything to it; the new license has to, IIRC, be substantially similar in spirit.

Re: Why we picked AGPL

#270

Post by M2Ys4U »

kazinator wrote: post #60
olavgg wrote: post #38

Earlier quoted context omitted.

AGPL doesn't restrict use: "You are not required to accept this License in order to receive or run a copy of the Program."

I would say that's an unhelpfully misleading statement in the license. There exist obvious circumstances of the program's use with which the license doesn't concern itself, and does not speak to, and so in those circumstances the user is not required to enter into the license. A redistributor must enter into the license because it's a derivative of the GPL, and so it has requirements related to distribution. A user w…

>A user who runs the program in such a way that visitors communicate with it from remote stations obviously is required to enter into the license also and comply with its requirements.

Only if the user modifies the program.

The remote network interaction provision of the AGPL is conditional.

Post reply on HN