> Why do you say agpl is not for free software / hobby ?

I mean it's not free software, even in the context of the user using it as a hobby thing. Is that what you're asking?

> From my understanding which could be wrong, is that you are free to use "this" software if[…]

So that's a problem right there. You are free to use this software "if…".
FSF's free software definition includes freedom 0: "The freedom to run the program as you wish, for any purpose (freedom 0)"

So I guess I can flip the question around to you. How do you mesh these things:

0. The freedom to run the program as you wish, for any purpose

1. I wish to run this software intertwined with some proprietary code

2. The purpose is to run it as part of a service offered to the public

3. The software is AGPL

4. The AGPL states that I cannot combine 1-3.

5. But I wish to combine 1-3 together, and 0 says I can run it as I wish for any purpose.

> Why is that difficult?

It's not difficult, it's logically impossible. My conclusion is that AGPL throws away freedom zero. And if that's out, then the license could just say "may not be used by companies above size X". And it's not free software.

> If I am using libreoffice and I develop a fix for bug that I found in my usage, why not give it back to the entire community so that the software is made better for the entire mankind?

Indeed. The problem here is that what if it wasn't a bugfix, but a feature where you added support for your company's SSO system, and used libraries that are not open source?

Or what if you're writing a script to launch openoffice in your VMware cluster, to convert from .doc to .docx. You now have to publish that script, if in any way connected to any service that anyone else would possibly and indirectly access.

Like, you can't use openoffice as a report generator in this way without publishing the script that launches openoffice on your cluster system.

And if you edit /etc/init.d/mongodb, you do have to publish that new version.

> Second, which is more important than anything hobbyist use, if I am a for profit corporation looking to earn money, why should I be allowed to take existing code built by God knows how many volunteers, make slight changes and market it as "my" product and totally ignore the work done by these people?

I don't think your scenario here is right. All open source licenses require copyright to be clear. Even BSD license without advertising clause doesn't allow you to claim it as your own.

But reading your question as only applying to services. Hmm… how is this different from you running a blog and not acknowledging all the work that went into the Apache webserver? Why does the public have the right to your startup scripts and apache.conf?

Why do they have the right to your cronjob script that installs a new letsencrypt and restarts the webserver?

Because this is what AGPL demands.

Nobody thinks Amazon invented xen or Linux. Nobody operates in a vacuum. Even Nobel prize winners didn't derive physics from first principles.

The AGPL is the most extreme. I don't think you should consider it the norm. There are many popular licenses that deliberately chose to allow modified binary releases. BSD, for one. And that's fine.

> From what I have been reading over time, no one is going to come after a "serious hobbyist" if they ran GPL code in their projects having proprietary blobs.

Don't confuse GPL and AGPL. Doing that is entirely allowed by the GPL, and thus there's nothing to "come after". Because GPL has freedom 0.

AGPL though, yes you're right nobody is going to go after you and your blog. But you're still in violation. You are pirating that software, because if you don't follow the license then you have broken the contract under which you're allowed to have it, and it defaults to you not.

So you're not actually using AGPL. You're just pirating.
But no, nobody's going to come after you. Unless they're a dick. But you're in the wrong, so if you do get sued you'll likely lose.

> Leeching off of work of community and passing it as own work without passing modifications and improvements to community is what the issue is and unless you want to do that, fine.

I do recognize the problem. The best weapon against it that we have is that it's expensive to maintain your own fork, and to keep merging it with upstream. Part of the reason Google et al contribute to the Linux kernel so much is the selfish reason that it's MORE expensive for them to maintain their own fork with local patches they have to apply every time there's an upstream release. It's why many companies contribute. I've done it too, and small and big companies. It's just cheaper to upstream your patch, and have it show up a while later in an apt-get upgrade.

That won't always work, though. But choosing AGPL all but guarantees no corporate users or contributors. And many many non-corp too. And your project is all the worse for it.

And do you want to make good software for the world to use, or do you just want to stick it to the man? To end on a similar note to you: if your goal is not to make something good, but to stick it to the man, then fine, use AGPL.