Live data from Hacker News

Why we picked AGPL

blog.paradedb.com

231–240 of 312 posts

Re: Why we picked AGPL

#231
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"?

Steal from the users of the software, yes. It's not about developers, it was never really about developers if we're talking copyleft licenses.

Re: Why we picked AGPL

#232

Earlier quoted context omitted.

Well that's not Op's question. They're asking "if I use Minio in my stack without modifications (as a file server that my other services interact with via an API), do I have to AGPL all the stuff the touches Minio or not?" (Minio is basically a FOSS S3) [0]. You're asking about linking, which is covered in the FAQ [1]: "You have a GPLed program that I'd like to link with my code to build a proprietary program. Does t…

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 to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph."

Therefore, what I said about linking applies to both.

To be clear, you only have to offer source code if you've modified an AGPLv3 program and you're distributing it publicly or "interacting with it remotely through a computer network (if your version supports such interaction)". Op's scenario neither modifies Minio nor distributes it, so they're under no obligation to offer source.

Re: Why we picked AGPL

#233
post #138

Earlier quoted context omitted.

I think you're 90% right in what you say here and in following comments, but I think you're skewing things in a way where I end up disagreeing with your conclusions. > Here is the rub: free software permits unconditional use. Why are you using the term "free software" here, when it has a well-defined meaning that is very much what you get with copyleft and the GPL and not what you get with BSD/MIT? I think you mean "…

When I'm using the term "free software", I mean this: https://www.gnu.org/philosophy/free-sw.html#four-freedoms Straight from the gnu's mouth! "The freedom to run the program as you wish, for any purpose (freedom 0)." > But the purpose of the AGPL has nothing to do with people using the software in ways that the license chooser doesn't like Yes it is. If you wrote a network program, and you specifically don't like th…

> Straight from the gnu's mouth! > > "The freedom to run the program as you wish, for any purpose (freedom 0)."

That gnu's mouth spoke 3 other clauses, and finished up with:

> A program is free software if it gives users adequately *all* of these freedoms. [emphasis mine]

>> But the purpose of the AGPL has nothing to do with people using the software in ways that the license chooser doesn't like > > Yes it is. If you wrote a network program, and you specifically don't like the idea that someone can modify it and then host that modified version for users without letting them have the source code, then the AGPL is a tool that nicely expresses your intent.

Ok, let's stick with "The freedom to run the program as you wish, for any purpose". We're talking about running the software here, not modifying it or hosting it. You can run the program as you wish. For any purpose -- what purpose are you claiming is disallowed? "For the purpose of running it on my server without giving out my changes" is not about running it, that's about something incurred as a result of running it. Which is unfortunate, I agree; it would be nicer if all obligations were only incurred when distributing it. But that still doesn't restrict the running part.

But never mind, this is too much of a semantic argument at this point. I was trying to understand why the AGPL bothers you more than the GPL. I get the argument that it triggers a condition based on usage rather than distribution, but given that the condition does not restrict the usage, I'm not sure why you care. Is it a principle? I agree that it feels a little messy, but given my understanding of the core goal of copyleft licenses, it actually feels to me to be pretty close to a minimal encroachment beyond the GPL that still satisfies the original goal of the GPL for server-side software.

> For instance, the GPL has turned out to very nicely suit corporate interests. The copyright holder of a GPLed software component has a competitive edge over the licensees. They have to abide by the license and release all their changes, which you can help yourself to; meanwhile, you can have a proprietary version in parallel.

Yeah, and my previous message didn't adequately cover this part. AGPL+CLA has a purpose and expresses an intent beyond the intent behind GPL. I'm personally more concerned with the evolution of the software I and others release, even if I find this corporate usage of the AGPL somewhat fascinating. If I understand correctly, your philosophical objections to the AGPL aren't based on this corporate scenario either, though?

You care about restrictions on usage and want as few restrictions as possible, so a corporation building upon BSD code internally without releasing changes doesn't bother you. But AGPL does bother you, because that corporation (or any other user) would need to consider the requirements of running that code. Do I have that right? (Or strictly speaking, running and modifying the code, since there are no requirements placed upon just running it if you haven't changed anything.)

Re: Why we picked AGPL

#234

Earlier quoted context omitted.

You don't need CLA for legal protection, Developer certificate of origin is enough. https://en.m.wikipedia.org/wiki/Developer_Certificate_of_Ori...

We've looked into the DCO before. It turns out CLAs are more common and easier to deal with, thanks to a tool like cla-assistant.io. We ended up opting for it for the sake of simplicity.

It's not a good argument, smoking was once very common and still is common in many parts of the world.

https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html

Re: Why we picked AGPL

#235
post #173
post #104

Earlier quoted context omitted.

There are clear differences. [Let's say I am not a competitor and Amazonifying them] I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner. Even worse, let's say I am a paid customer for their support and run on their proprietary license…

> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner. You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor stri…

> You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor strikes me as somewhat ironic here: what, the same deal that you give to your own customers for your own product is one you simply 'can't' take yourself because it's not 'reasonable'?

I am not discussing ethics or morality here, just practicality, and yes, from the perspective of a user that is not primarily releasing open source. Note that it's somewhat different and more general than your characterization. I might be in another business, not software, but unwilling to touch AGPL within my infrastructure due to risk of virality. Strictly speaking, I am not a "proprietary software vendor" as I am not even in the software business, primarily. Nevertheless, your general point stands.

I am not arguing it is bad. Simply that I would not characterize AGPL+CLA as "no vendor lock-in because open source." I put it right in the bucket of e.g. Oracle proprietary database. I am not saying it is bad or totally unreasonable. I just don't buy up the marketing koolaid.

Re: Why we picked AGPL

#236

Earlier quoted context omitted.

Sorry but what does "arms length" mean? My software doesn't have arms. Using metaphors full of imagery is cute but essentially meaningless. > Two programs communicating over a socket aren't incorporated. They're two programs. Aren't they? So, if I want to use a GPL library, all I need to do is write a little wrapper program that does RPC over a socket, and boom, I can use a GPL library in my closed source program? Ob…

> Aren't they? So, if I want to use a GPL library, all I need to do is write a little wrapper program that does RPC over a socket, and boom, I can use a GPL library in my closed source program? Yep. This is how MySQL/MariaDB work, for example.

What about when running a wasm component in an AGPL host? Can the compiled wasm file be proprietary? They share the same memory space, but the wasm component is not compiled with the host.

Re: Why we picked AGPL

#237
post #134
post #106

Earlier quoted context omitted.

> The AGPL deception is you brand yourself as community-minded. As long as you don't rely on external contributions that's fair. But what the AGPL startups don't emphasize is they require you to either assign your copyright to them or give them extra privileges to your contributions to be able to relicense it under non AGPL (if they don't they don't know what they are doing). There's nothing specific to the AGPL or s…

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 projects that the FSF themselves run (or at least many of them, and traditionally it was all of them), they require it.

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

They cannot change the GPL. They can publish new version of it, and recommend that you license your project with a term that permits it to be used under those new versions, but this is not obligatory (and notably e.g. the Linux kernel does not).

Re: Why we picked AGPL

#238

Earlier quoted context omitted.

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

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

Re: Why we picked AGPL

#239
post #109

Earlier quoted context omitted.

> 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. It's not. It's about making sure users can fix the bugs in the software they want or need to use, and share those fixes with others. Rules about redistribution are a means to that end. The GPL was originally written in…

The GPL is not simply about fixing bugs. It's about preventing the existence of versions of the program in which you cannot easily find or fix bugs, and the underlying ideology that they should be no such programs. And not only bugs but deliberate undesirable or malicious behavior. The problem with closed source proprietary software is that you don't know what's hiding in the binaries. If software were uncopyrightabl…

> If software were uncopyrightable, they would still be binaries without source code, which you would have to reverse engineer to find out what harm they perpetrate actively or possibly through their security flaws.

True. But reverse engineering could happen openly, and tooling for it would improve. The benefits would outweigh the costs.

> if you wrote a piece of free source code, anyone could do anything with it they wish, including removing your name, and not attributing you in any way in the documentation accompanying the compiled code.

Depends where you are. Many jurisdictions recognise attribution as a "moral right" separate from copyright.

> A program is not distributed to you if someone else installed it on a machine you don't own and you're just borrowing that machine. It doesn't matter if you're physically at the console, we're at a remote dumb terminal or smart client. The program was distributed to your school, company or friend or whoever.

Up to a point. If you pressed the "buy" button, paid the money, and are using it from your machine like a program, then it shouldn't matter where it's metaphysically located. Plenty of software will "phone home" to company servers or even falsely claim to be running computation on the company's machines (SimCity), but that doesn't mean the software hasn't been distributed to you. Just as the courts don't allow you to stream TV from an OTA capture card in a remote datacenter and consider that to be OTA viewing, having a program that you use from your local machine do some of its execution in some remote datacenter (whether through VNC-style remote access, a web UI, or something else) shouldn't make it any less your program that's been distributed to you and that you're using.

Re: Why we picked AGPL

#240

It's a shitty license. If you need to patch anything due to local requirements like the auth system you need to publish it which doesn't make sense at all.

You only need to share those changes with anyone that has access to your modified version.

If you modify an AGPL'd piece of software, but never distribute it outside your org, then your changes don't need to be released outside your org.

Post reply on HN