Square’s terms of service forbid use of AGPL-licensed software in online stores

> The other point is that the intention of this license is explicitly to prevent people commercializing software licensed this way through proprietary extensions, additions, etc. The whole point of the license is to make that difficult/impossible. If you use AGPL software, you have to respect this intention.

That may be true, but why should you care if you are not actually doing that and are only using the software without modification?

> Even Gplv2 is generally frowned upon but better understood since there is a fair bit of case law around it

It is pretty uncommon for there to be existing caselaw interpreting a given software license. Proprietary software licenses are commonly unique to the software, sometimes even unique to the customer. If this is a concern then shouldn't a widely used form license like the AGPL be an advantage, because then it's more likely the first time a court has to interpret the text will be in somebody else's case and not yours?

> So, this is not FUD but basically lawyers doing their jobs and they are fairly consistent in their reservations with respect to this license across the industry. You talk to lawyers in any fortune 500 company and they'll probably will be very reluctant to sign off on any AGPL dependencies.

Have you experienced asking lawyers for their opinions on contract text? You'll generally get back a document identifying various concerns with just about every provision in the text, because that's their job.

For example, here's a fun provision from the Windows 10 license:

> [you may not] use the software as server software, for commercial hosting, make the software available for simultaneous use by multiple users over a network, install the software on a server and allow users to access it remotely, or install the software on a device for use only by remote users;

What does that mean? How will a court interpret it? Should corporations avoid Microsoft Windows as a result, because they might violate some interpretation of the license and then be liable for copyright infringement?

Lawyers having concerns about license terms is par for the course. What you haven't established is what makes the AGPL unusual in that regard, as compared with the above or a hundred other provisions in various other licenses.

What kind of interaction matters? Only directly interfacing with the Software through TCP/UDP (other OSI L4+ protocols)? What if I put a reverse proxy there? An API gateway?

Sure, courts can decide these things, they can make it intent-dependent and/or use some other weighing method.

If I modify this popular commandline program to do my deep learning based manipulation on my server, do I have to publish my changes if asked?

Suppose Go has this license. If I don't distribute Go but modify it to serve some kind of requests in 2 ns instead of built in Go's 1200 ms for that operation, do I have to share my version even if I am only using it in-house, if it serves some traffic to people (its "output") and they request my code?

If any of the backend of Google's search engine, Google, which crawls the whole web, includes tooling that this license and which they've modified internally, can I request a copy if I see its crawl results as a user?

Please answer these questions.

>"You sign a contract that you won’t do it."

As that is not the be all and end all of contracts.

FUD would be spreading unreasonable fear and uncertainty to create doubt.

The thing you don't seem to get about these licenses is the generally fuzzy language about derivative works, distribution, and modifications. The legal interpretations vs. the intent of the authors vs. the technical interpration of these licenses are three things. An engineer saying, "it's fine" means absolutely nothing. These licenses are versioned for a reason: the intent and legal reality apparently don't always line up and people try to fix these things.

The key point of the AGPL license is that it deliberately intends to prevent proprietary bundling/extensions of software licensed that way by demanding it is open sourced under a similar license (aka. the viral nature of the license). Gplv2 had similar intentions but contained enough ambiguity and weaker requirements that gave clever lawyers enough wiggle room to get away with e.g. creating things like Android which definitely has a lot of proprietary stuff covered in patents and other things. Hence, GPLv3 which aimed to rectify some of these ambiguities.

And yes, I have experience being lectured on this by actual lawyers (with a clue no less) in the context of Nokia's OSS efforts a few years back around their linux based mobile os. They had thousands of engineers collaborating with the OSS community on hundreds of projects with all sorts of licenses. Their job: protect Nokia's IP and prevent inadvertent legal fall out with patents, copyrights, etc. due to improperly licensed software. I learned a lot talking to and listening to these people.

In short their attitude was, MIT/Apache is generally fine. Gplv2, you need to know what you are doing but we know how to deal with this and mitigate potential risks. Gplv3: please avoid adding anything with this license to any Nokia product (patents were a big concern here). AGPL, no way in hell that we would approve this, ever; the risks are substantial and generally not worth it, even for server side only stuff.

Regarding the MS license; lets stay on topic and not digress about the legal saviness of their lawyers. Generally my advice would be to assume they can make life hard for you and thought long and hard about how they would do that. Any court case would likely set you back more than you or your company can afford.