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

201–210 of 312 posts

Re: Why we picked AGPL

#201

Post by richardwhiuk »

powersnail wrote: post #195
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…

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

Re: Why we picked AGPL

#202

Post by sangnoir »

Vegenoid wrote: post #194
sangnoir wrote: post #193

Earlier quoted context omitted.

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

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

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

Re: Why we picked AGPL

#203

Post by zzo38computer »

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.

That is only if the license of that software says they can use later versions of GPL; it is not automatic.

Re: Why we picked AGPL

#204

Post by itsgabriel »

dgb23 wrote: post #148
keskival wrote: post #135

Earlier quoted context omitted.

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

Thank you! This might be a viable licensing scheme for Swiss government contractors now. The federal government requires open source licenses for all software projects as of last year or so. (A)GPL+CLA might be a good way to ensure the interests of the both the Swiss people and the flexibility or competitiveness of contractors, allowing them to retain proprietary licenses where needed or wanted. Follow up: Am I corre…

Contributions to a fork could be done under just the AGPL, without any CLAs (also to the original repo, but those won't be accepted). Then the entire fork is effectively AGPL only. I don't think any original CLAs would apply to the fork, unless the fork owner is the same legal entity/successor as defined in there. Same goes for the original authors, they'd need CLAs from all fork contributors.

Re: Why we picked AGPL

#205

Post by powersnail »

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.

If I accept their license on 2024-08-14 to use their software, they can do whatever they want to the license after that, but they won't be able to revoke my license to use the code as of 2024-08-14 under the license present to me on 2024-08-14.

No update on the license can retroactively change what I agreed to.

Re: Why we picked AGPL

#206

Post by kragen »

jillesvangurp wrote: post #157
JohannesSuenden wrote: post #24

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…

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

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

Re: Why we picked AGPL

#207

Post by kragen »

jan_g wrote: post #156
ashkankiani wrote: post #154

Earlier quoted context omitted.

Copying reply to a child comment: "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.

But you forgot to cite the next sentence: 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 f…

this is basically talking about compilers and things like dumping a memory image from gforth or emacs

if someone said 'no, the output from my gpl-licensed compiler is never covered by the gpl', then would-be infringers would have an easy escape from the gpl: just compile the compiler with itself, and its author guarantees that the compiled output isn't covered by the gpl! so that's why the fsf carefully says 'only if the output, given its content, constitutes a covered work'

similarly, emacs or gforth has the ability to dump a memory image after loading up a bunch of source code and compiling it to bytecode; that way it can instantly load the image without taking the time to recompile all that code. this memory image includes all the code that's loaded, including not just your code, but also all the standard library code that comes with the system. but that shouldn't give would-be infringers an easy escape from the gpl for the standard library code

Re: Why we picked AGPL

#208

Post by tgma »

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.

Importantly, GPL does not include such line. That line is not part of the GPL. Critical software such as Linux famously do not have that and are not GPLv3 for example.

The Author can choose to license the Copyrighted Work under various licenses. The common boilerplate that many Authors of GPL software choose to use is a boilerplate that says they are licensing their Work under GPL version X or any later versions supplied by FSF. That boilerplate is Author's declaration of license contract and not the license itself.

Basically the Author is directly saying (not through the GPL text) that "I trust FSF to come up with future licenses and call whatever they want GPL version Y [Y>X] and I'll be willing to license my work under that license sight-unseen also."

Re: Why we picked AGPL

#209

Post by mrwyz »

The AGPL is great, even for business. I make a living from AGPL software. Lots of people generally don't like it, because AGPL was not written to please the largest number of developers, but rather to protect the basic software freedoms of end-users. In a sense, the AGPL guarantees more freedoms, is more free, than other licenses such as MIT/BSD for end-users. But depends on the point of view.

Many developers don’t like to have their freedom to steal to be restricted by such strong terms as those imposed by the AGPL. And that’s a good thing for you, my fellow maintainers. It’s also a great thing for you, dear end-users.

Re: Why we picked AGPL

#210

Post by baggy_trough »

mrwyz wrote: post #209

The AGPL is great, even for business. I make a living from AGPL software. Lots of people generally don't like it, because AGPL was not written to please the largest number of developers, but rather to protect the basic software freedoms of end-users. In a sense, the AGPL guarantees more freedoms, is more free, than other licenses such as MIT/BSD for end-users. But depends on the point of view. Many developers don’t l…

"freedom to steal"?
Post reply on HN