> I knew what it was going to be before even looking
Assuming that it's just the server part that's AGPL, that's not very restrictive for something that's purely a development tool.
That's VERY different from a library you need to include in your finished application being AGPL or even server software that you might expose to end users being AGPL.
At least AGPL-3.0 is more honest and direct than SSPL or other vague licenses to prevent Amazon'd. Lawyers and internal legal departmens did not catch up to those licenses yet. Pretending to be open source until a point and forking under a new license leaves a bad taste.
It's for sure not "wrong," as (a) it's your software (b) people have different concerns they want to have addressed by license terms
For me, and the company I work for, AGPL is strictly banned. GPL is gravely frowned upon, because the founder had a lot of lawyers involved that almost bombed an acquisition. I appreciate that's anecdata, but for sure it is a "conversation" in the company versus Apache 2 which requires no conversation
I'm actually kind of luke-warm about AGPL for some things, but for what I imagine is a JVM agent, and thus both injected into my software and communicates over the network, hard pass
For clarity: I didn't mean my comment as a scolding: the community is almost certainty better off for you having chosen to share the code, and there will be folks who can and do contribute fixes under the terms of the AGPL. It's just been my overpowering experience that a lot of companies that try to open source code are trying to guard against "being Amazon-ed" and I appreciate why they think that way
> For me, and the company I work for, AGPL is strictly banned. GPL is gravely frowned upon, because the founder had a lot of lawyers involved that almost bombed an acquisition. I appreciate that's anecdata, but for sure it is a "conversation" in the company versus Apache 2 which requires no conversation
This seems to be a development tool that does not need to be incorporated into your software (I'm assuming the library that runs in your software won't be AGPL but I could be wrong *), so it being AGPL should theoretically be strictly less restrictive than just being closed source.
However, perhaps for companies with policies against (A)GPL software like yours it would be better if they offered it both as freeware under a closed source license that doesn't allow modifications AND open source under the AGPL so you could pick which license you like better?
*Actually strictly speaking even if the agent software is AGPL I believe that would only really matter if you distributed a version of the software including the agent outside of your company, so theoretically you could just remove it for production releases, but I agree that it would be a lot more justified to avoid it because of the license in that case, so I hope they intend to release the agent software under a more permissive license.
Personally I'm really happy to see a commercial entity with a FOSS offering that's protecting their revenue using AGPL instead of these new "open source eventually" business licenses. Don't get discouraged. For everyone that would complain about this license choice there are just as many of us who celebrate it.
I think there is a knee jerk reaction against AGPL, because it can be seen as fairly restrictive in the case of software you would incorporate into your application, but it seems perfectly reasonable for a development tool.
Just a guess, but I think a lot of people immediately see the letters "GPL" anywhere and back out, rightly or wrongly. The nuances of licenses are poorly understood by many developers (and even legal departments) and there's a "I can't be bothered" attitude a lot of the time, even where AGPL makes a lot of sense and isn't particularly restrictive on the average end user. There certainly needs to be a lot more education in this area.
We hear this a ton from our friends at big companies, but... surely most of them use Linux? Or Git? Or x264, OpenJDK, GIMP, or VLC? Or (if you include LGPL) the WebCore portions of Chrome/Safari/Edge, which originated in KHTML/Konqueror? Or GTK, Cairo, ffmpeg, or WINE?
It's a little hard to believe the "GPL" is that much of a problem to the industry given how popular *GPL software remains in most places.
GPLv3 I realize is a different story, but even then, the companies seem to find a way to hold their nose when they want to. (When we first released Mosh as GPL 3+, we got a call from Apple, who were unhappy that their employees were using Mosh to connect to servers because Apple apparently doesn't want employees to be installing any GPL v3 software on their company-owned Macs. On the phone call, I told them that (a) I didn't think they had anything to worry about in terms of actual problems from the GPLv3, and (b) if they really disagreed, we're open to the conversation, but it would cost them a lot of money for me to want to think about what it would take to give them Mosh under a different license. Somehow they ended up concluding that the GPLv3 wasn't that bad after all...)
Most of the examples you cite are situations where the software is being used as a client or at a distance (in terms of being far down the stack) and not as part of a deliverable. I think using such software is considered straight forward by most (if not by paranoid corporate policies, such as those you've encountered).
Where it gets more difficult is when potential dependencies are (A)GPL licensed. While I support the use of these licenses (particularly the AGPL for protecting cloud deployment of open source tools), I recognize the "friction" they can cause for certain classes of users who might just use something else to avoid thinking about it. (Which, you might say, is their loss.)
Assuming that it's just the server part that's AGPL, that's not very restrictive for something that's purely a development tool.
That's VERY different from a library you need to include in your finished application being AGPL or even server software that you might expose to end users being AGPL.