Square’s terms of service forbid use of AGPL-licensed software in online stores
squareup.com
squareup.com
They looked at the AGPL and completely misunderstood the context. There is no way in hell anyone can interpret AGPL in a way that makes Square responsible for any license violations their customers make selling software.
You need artificial stupidity to misunderstand the "Interacting with Program through a computer network" in the way Square seems to understand it. Distributing software via online store is not interacting with the program.
Has that been tested in a court yet? If it hasn't, then a lawyer would immediately see risk.
I mean, look at Oracle vs Google on whether or not an API is copyrighted.
And AGPL isn't the only "must publish all your server's source code" license available, so to prohibition is too specific if that's the actual reason.
This is why we have the DMCA safe harbor provisions - it'd be incredibly easy to be on the hook for copyright infringement as a company hosting any user content otherwise. Those safe harbor provisions aren't a blank check to knowingly commit wanton copyright infringement however, as can be seen with all the legal wrangling over Megaupload, as an example [1].
Square knows about the AGPL, knows they might not be abiding by it's terms if they redistribute AGPL code, and knows they probably don't have the right to redistribute under any other term. They can choose to knowingly possibly violate the license, or to knowingly commit copyright infringement, or to ban AGPL code. Those first two options, with that "knowingly" in there, open them up to potential legal action.
> And AGPL isn't the only "must publish all your server's source code" license available, so to prohibition is too specific if that's the actual reason.
If you make Square's lawyers aware of some of those other licenses, it wouldn't suprise me if they get banned too for the same reason. It's not like they have psychic knowledge of the existence of all licenses. Failure to audit the universe doesn't mean that's not their reason.
[1] https://en.wikipedia.org/wiki/Megaupload#Safe_harbor_provisi...
If the third party sold a copy of MS Windows using Square's services/software/platform, could Square even in theory be sued by Microsoft for copyright infringement?
It sounds like "yes" from my reading of what you write. So AGPL isn't something special.
Their lawyers don't need to be psychic about other licenses. Why did they specifically qualify with "v3"? That is, the original Affero license is one of the other alternatives, yet they seem to allow it.
If Square was knowingly engaged in the distribution of Microsoft's software against Microsoft's license terms, absolutely. (EDIT: Well, I'm assuming they're helping distribute it, might be "conspiracy to commit copyright infringement" otherwise?)
> So AGPL isn't something special.
Correct...ish. I'm sure piracy, if not explicitly against the ToS, will get you kicked off too. The closest the AGPL gets to being special is the nebulous situation we find debated throughout this HN discussion tree - is it legal for Square to distribute? It's reasonable that customers might think so. It's reasonable that square's lawyers might think not.
But you've pointed out that even that isn't unique to the AGPLv3 specifically - so why call it out, specifically? My wild uneducated guess - a customer used AGPLv3 software, Square became aware of it somehow (license review team? or perhaps someone tried to exercise AGPLv3 rights and requested server code?), and eventually involves their Lawyer. Lawyer then looks into the specific case of their customer using specific software, reads the license of said software (AGPLv3), and becomes nervous about Square's possible legal exposure.
After the awkward conversation with their customer (possibly much like the discussion in this HN thread as to if Square would/wouldn't be knowingly facilitating AGPLv3 license violations by not sharing their own code, and thus legally liable), Square settles the matter by banning the specific license outright, possibly after giving them a chance to move away from AGPLv3 software first since it wasn't strictly against the ToS, and then explicitly adds it to the ban list for the benifit of customers and customer service who probably weren't privy to whatever lengthy private discussions might've been had with that one specific customer.
It does make some sense to see AGPL singled out, because it is different from most other free and open source licenses in one major way.
Almost all other free and open source licenses only require you to distribute modified source code of a derivative work you've made if you distribute that derivative work.
If I take code under those licenses, modify it, link it with my own code, and just run the resulting derivative work on my computer, they do not require me to distribute those modifications or my code, no matter what I'm using the program for, or where from, who from, or how I get its input, or what I do with, where I send, or who I give its output.
Not so with AGPL. With AGPL, the requirement to distribute derivative works can be triggered by code running entirely on my computer if it gets its input from and sends its output to people over a network.
That's a huge difference from prior free and open source licenses.
>3. Online Store > I. Your Content and Content Restrictions
MongoDB's new license targets scenarios where Google would provide a hosted MongoDB service to their customers (like Amazon's RDS offering, for example). It has no impact on individual customers personally spinning up their own MongoDB on their own set of servers for their own use.
Honestly they are probably correct to be worried about this because it's pretty unclear whether or not it would be covered. At the very least, by making it against the TOS it is clear that it's the users fault not theirs if there is a violation.
As an example, let's say that I have a game. That game happens to want to have a way of rendering some HTML content for printing / making a PDF. It's OK to ship an open source thing with your game, like a hypothetical FrozenFluff web-browser licensed in AGPL. There are two distinct entities there: a FF binary that gets called with a file to render (which is AGPL and an AGPL processed result that is under the copyright of whomever's material was rendered) and another distinct binary the GameX that happened to call an external process.
The line to cross there is that the AGPL stuff can't be linked against your own program. I'm even more unsure how a module might or might not be licensed. I think since that's an addin then the code for the module (including headers) would have to be AGPL compatible and released, but that the rest could probably be closed.
This line is less clear when it comes to websites however. I think the best equivalent would be to make a wrapper interface that is AGPL licensed, published, and links to/calls the AGPL software. It should have a distinct URL. That URL might only be on the localhost (for security) and would hand back whatever results exist. The proprietary interface could talk to that URL and get results.
I am also not a lawyer, however my take on many legal things is that it doesn't matter what my take is, or even if courts will agree with my take, what matters is whether the benefit is worth the hassle if I end up needing a lawyer to deal with it.
Even if you "win," the engagement with lawyers can cost you so much that it becomes a pyrrhic victory, and the amount of time required to deal with certain legal squabbles is astounding.
So sometimes, the right thing to do is to shy clear of anything that carries with it some risk of legal potholes.
This is a great advantage of the AGPL IMO. You can release your free software/open source code, and big tech companies won't use your code and make lots of money.
Some companies tried to relicence their code to some 'source available'/'non commerical' licence because they didn't like the MIT's lack of conditions. AGPL could have helped.
https://squareup.com/us/en/online-store
not Square Payments.
It looks like it's a lot broader than just the Online Store, although it doesn't mention Payments specifically.
Still, "any associated products and services" sure seems like it would cover Payments as well? What's the dividing line for a product that's associated with the Online Store?
EDIT: This specific clause is listed under section 3 "Online Store", so it does seem likely to me that it's not meant to apply across the entire TOS.
Still a weird restriction for the online store, but given that there's also a non-disparagement clause right under it, it's certainly not the most egregious thing in this license.
> engage in excessive advertising on your website, which includes adding more than three ad units per page, or any advertising that greatly reduces the usability of your website;
Still no idea why they single out AGPL the way they do.
> B. Content Restrictions. In addition to the restrictions set forth in these Additional Product Terms, the General Terms and Payment Terms, you will not: [...]
> 15. use, under any circumstance, any open source software subject to the GNU Affero General Public License v.3, or greater;
>"You sign a contract that you won’t do it."
As that is not the be all and end all of contracts.
So I think these restrictions only apply to websites they designed or host. I think it would be fine to distribute software under the AGPL and use square for the payment. Or run AGPL software on your own ecom site and use them as the payment provider.
Does this sound right? And if so, I guess they wouldn't want to have to redistribute the modified versions of software?
- AGPL v2? it says:
> This is version 2 of the Affero General Public License. It gives each licensee permission to distribute the Program or a work based on the Program (as defined in version 1 of the Affero GPL) under the GNU Affero General Public License, version 3 or any later version.
- Dually licensed software? Does this prohibit software licensed under BSD and AGPL? Granted, the only reason to do that is to troll Square.
"15. use, under any circumstance, any open source software subject to the GNU Affero General Public License v.3, or greater;"
Which perhaps could be interpreted as version 0.3 or later?
See also, https://softwareengineering.stackexchange.com/questions/2630....
Doesn't sound good at all
If the AGPL program is unmodified, you don't have to share its corresponding source no matter what it is integrated with.
If the AGPL program is modified, you only have to offer the corresponding source of that program, not all programs that connect to it over the network.
That’s useful to consider, but it doesn’t reassure me enough to remove the risk altogether. I would, if I were a coder in Square’s position, acknowledge this explanation and then very likely still move to deny AGPL interactions as a whole rather than try to finesse the exact legality as described. I care a lot about licensing but I also want to get work done without fear of AGPL lawsuits.
I'd rather not have code source available under things like AGPL than run the risk with the minefield for lawyers it becomes.
The restriction applies to software sold in their online store. It is not possible to interpret "Interacting with Program through a computer network" as distributing software via online store. The program must be running and executing it's code.
> Additional Point of Sale Terms of Service >3. Online Store > I. Your Content and Content Restrictions
Does the AGPL specify its terms of infection such that “a third-party seller listing a physical CD full of AGPL software sold on Amazon” would bind Amazon by the terms of AGPL source code release for Amazon.com?
Does the AGPL specify its terms of infection such that “a third-party seller publishing CD listings to Amazon using an AGPL script” would bind Amazon by the terms of AGPL source code release for Amazon.com?
And so in those terms, the core question of this thread is, “may I sell items and services on Square that are composed of AGPL code as long as I do not use AGPL-containing or AGPL-integrated code or content when interacting with or publishing listings on the Square Store or when interacting in any way with Square services or APIs?”.
So the clause wouldn't apply to someone using the store to sell CDs with AGPL software, but they would apply to someone using an AGPL Javascript module in the web frontend of a (Square-hosted) store that sells shiny rocks.
[1][https://opensource.stackexchange.com/questions/4691/java-and...]
Plus, if you treat the cloud service provider's code separately from the user's code, there is a pretty strong danger of opening loopholes that defeat the entire purpose of the AGPL. It's not clear that people releasing code under the AGPL would even want the AGPL to be interpreted that way.
I mean my end users never interact with that service. They interact with a - let's say - proprietary one. And that service is the client to the AGPL service.
Or anything AGPL touches turns into AGPL? What is considered touching? If I use an AGPL firewall do the packets turn into AGPL? If I use an AGPL log aggregator? Or an AGPL centralized identity management thing every other service that auths turns into AGPL?
Furthermore the combining with other works is not clear in on GPL3 cases.
When combining happens and when doesn't? What happens if I combine it with proprietary software?
I wonder if it's about control. With a SaaS you can switch to a competitor. It's possible to switch between GNU/Linux distros and the companies that support them. Change is possible. This can protect you from a vendor tanking or who has bad behavior.
Oracle is an outlier. They aren't going away. There's enough business to keep them around. And, many companies are trying to get away from them slowly.
When you have an AGPL and commercial dual license it puts that vendor in control. Do big businesses like putting others in a position of power and control over them? If that business is small or a startup do they want to have that as a hard dependency? Is it a risk to the big business?
This isn't about paying for commercial licenses. It's about risk mitigation. Something big businesses do a lot of.
> 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.
So that's about who you have to give the source code to if you modify the program, right? But isn't the salient point there that it only matters if you make modifications? Why should anybody who is using the software unmodified care about that at all?
And all the stuff about "what is linking" would be the same as it is for the ordinary GPL, would it not? The "Source Code" section of both licenses are word for word identical, anyway.
It all seems like a lot of FUD from people who don't like the AGPL because it requires them to follow the spirit of the ordinary GPL when they actually do make modifications but then use them in a public-facing service instead of distributing them as a software product, i.e. when it does exactly what it's intended to do.
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.
Gplv3 is also not that popular with legal departments for the same reason. Even Gplv2 is generally frowned upon but better understood since there is a fair bit of case law around it and known ways of dealing with it when e.g. shipping binary kernel modules with an OS, which is one of those legally grey areas where you have to depend on legal interpretations of the license. Gplv3 was explicitly written to close some of those loopholes in Gplv2: they were unintentional.
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.
> 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.
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.
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.
https://github.com/moll/node-pg-error/issues/1
It also seems worthwhile to examine the differences between the APGL and the recently introduced (and much critiqued, albeit I find somewhat unfairly, in some aspects) SSPL:
1. https://news.ycombinator.com/item?id=18352171
2. https://news.ycombinator.com/item?id=18301116
The above should let you find the answers to your questions, but I'll use this comment to also point to some less on topic but still very much related to licensing granularity matters.
Compare the various FSF licenses to the OSET license:
http://www.osetfoundation.org/public-license
Two specific things I find rather atrocious about all the FSF licenses seem easiest to highlight by pointing out what the OSET license does to explicit avoid these pitfalls:
1. "Sovereign Immunity. Contracting with governments brings up a special issue that doesn’t apply to anyone else: normally, if you grant a license to government, you may not be able to sue for a violation because governments can be immune from legal claims. We ask recipients to waive this restriction, so there is a remedy if the recipient does not abide by the terms of the license. See Section 9.2 of the OPL"
2. "The OSET Foundation (then the “OSDV Foundation”) attained its full tax-exempt status under 501(c)(3) of the Internal Revenue Code declaring us a public charity in the 3rd quarter of 2013. In the course of seeking this status, as part of a negotiation⁴, we agreed to make certain changes to the license to ensure that our source code is free for everyone to use. Section 5.3 of the 2.0 license now requires that a licensee who does not abide by the terms of the license must make the Covered Software available in Source Code Form on a publicly available computer network for a period of no less than three (3) years. This goes beyond the source code delivery requirements of standard open source licenses. Section 5.4 reserves the ability of a licensor under our license to seek injunctive relief for violation of the terms of the license. It is not clear at this point whether a court could, under applicable law, order a violator to release source code. But we cannot control the law, only our license. Therefore, if that remedy is available under law, we want to make sure it is available under our license as well."
And then, even more peripherally related, none of the libre licenses I know have some variants for transcopyright, a licensing concept almost forgotten, and outlined by Ted Nelson, here:
http://www.youtube.com/watch?v=x3l7CpnpyGw
At this point, I really wish we'd have some sort of mathematically sound "mix and match" license generator, where you can pick what you want your license to do with extreme granularity, based on as detailed of a parameterization of what one might do with Software licenses in general, and get a standardised, reproducible license build.
There does exist this:
https://en.wikipedia.org/wiki/Rights_Expression_Language
But it doesn't actually really do what you might expect it to do.
For example, compare these two RDFs for the GPLv2, and the GPLv3:
https://www.gnu.org/licenses/gpl-2.0.rdf
https://www.gnu.org/licenses/gpl-3.0.rdf
The GPL v3.0 RDF pulls in http://xmlns.com/foaf/0.1/ as an additional XML Namespace, and has a logo, but in terms of the actual ccREL encoding, they seem completely identical, both just contain this:
<cc:requires rdf:resource="http://creativecommons.org/ns#Copyleft"/>
<cc:requires rdf:resource="http://creativecommons.org/ns#SourceCode"/>
<cc:requires rdf:resource="http://creativecommons.org/ns#Notice"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#Distribution"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#Reproduction"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#DerivativeWorks"/>
Mostly, yes[0]. Parts of the package are under BSD, others FreeType license, others GPL etc.
I don't know which ones are used in imagemagick, so I can't say whether AGPL "infected" it.
[0] https://metadata.ftp-master.debian.org/changelogs//main/g/gh...
Most of our stack was CentOS, MySQL, ruby and java. The DC automation, such as it was, was mostly homegrown layers on top of kickstart.
I don’t know of anything we depended on that was AGPL.
I guess there is probably some berkelydb floating around, and the datastores team uses mongo for an internal app.
AFIK, they still mostly run on this stack but are moving to k8s, then k8s on cloud.
I know nothing about the new legal change, but do know I often had to talk legal down from being overly cautious and paranoid about other technical issues they didn’t understand.
We all grew lax with copyleft cause all this corporate pro open source stuff, and now there isn't a critical mass of AGPL projects compelling Square's lawyers to read harder. I have no idea how to build that critical mass.
That's spooky. Any idea why?
Even if they do though it would be a stretch to hold them liable, it's like requiring github to be agpled if you upload your agpl code there.
1) they place no restrictions on any other license. What if I use the Server Side Public License, or something else with a similar requirement to distribute?
2) the specifically say "v3", while the original AGPL also had that requirement.
I, like Illniyar, also think the AGPLv3 doesn't have that interpretation in the first place. At what point would Square have accepted the copyright license?
I think gpl is enough for web apps. I don't think I should have the right to demand all of gmail's or google search's server-side code if they use but don't distribute gpl software as part of making it.
But all companies need to steer really clear of agpl code. Even editing an image using an agpl image editor could taint the image, even though you're not exporting any code.
I would absolutely demand that anyone working for me not use any agpl software. I think it would taint even the copywrite on a logo.
Maybe I would be tainted by publishing a document they wrote in an agpl text editor, even if they license it to me.
Just my impression after 5 minutes of research. If someone has more detailed legal position please do correct whatever I got wrong.
This is an outrageous claim. Citation needed.
>Just my impression after 5 minutes of research. If someone has more detailed legal position please do correct whatever I got wrong.
after 5 minutes of Googling. downvoting my personal research results after 5 minutes of Googling won't get anyone to answer with the corrected version. I had never heard of agpl until I googled it and summarized what I saw.
It's a summary. if you put up a web app where you modify open source software as part of your stack, you have to publish those changes if people ask for them. Even if you are not distributing those changes. (This is my impression.)
I look forward to a correction from an expert - it's why I posted what I found. (Yes, what I found was outrageous.)
Only specifically your changes to AGPL code, but otherwise correct.
This is reasonably well described on GNU's own page[0] on the AGPL.
Your private forks are private, even if you produce something using them. You can't taint that production or force someone to publish changes they don't want to publish and aren't distributing.
You are saying if a textbook publisher modifies open source layout software then uses it to set a textbook, they can't retain those internal modifications if someone asks to see them. I think they should be able to keep them private.
Honestly we should be downvoting comments like these more. The AGPLv3 isn't new and the original text isn't that long. We don't need incorrect third hand summaries of the license text with additional wild speculation and unfounded advice. Everyone writes comments here like they are an authority on every topic, but it's a good reminder that many authoritative-sounding comments aren't any better than gossip.
Basically everyone I've talked to has an incorrect understanding of the AGPL and it's not because the original text is ambiguous (although there are parts that are ambiguous). It's because people read and write bad summaries and until the common knowledge is completely wrong.
Here is a good summary: the AGPLv3 is essentially the GPLv3 with the addition of section 13:
https://www.gnu.org/licenses/agpl-3.0.en.html
> 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.
> Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
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.
Go is a compiler+runtime. AFAIK any copyleft compiler worth using explicitly makes exceptions for its output and runtime, but the FSF says generally that the output of a GPL program is not also GPL[0]. If the runtime is AGPL (without such exception) and you link it into your program, your program is now considered a modified version of the AGPL runtime (e.g. it works exactly like the GPL in that linking is considered modifying). If your service interacts with users over a network, you have to offer the source of your modified program. Since you linked the runtime, you didn't even have to modify the Go source code to make an improvement (if there were an LAGPL, the linking could be OK unless you made the modification).
The other two cases are more ambiguous since they do deal with the ambiguous part of the license. The license says "interacting with it remotely through a computer network". However, it's not clear how much indirection is allowed, so you have to use some judgement. The FSF gives guidance [1]
> If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category.
However, I would be careful not to create a combined work that does interact with a user over a network in an attempt to circumvent this. E.g. a network proxy that was intimately tied to a non-networked program. See [2]
> By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Unless you consider the imagemagick command line arguments "complex internal data structures", it's probably difficult to run afoul of this.
For the Google search engine case, it depends on what degree the tooling interacts with users over a network. E.g. if it's part of an batch process to calculate rankings, it's not interacting with users over a network. If it's a backend that renders part of the results page for user requests, then probably yes. If it's crawl infrastructure that downloads pages on the web, probably no since that network interaction probably isn't considered to be with a user[3].
0: https://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGP...
1: https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...
2: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
3: https://www.gnu.org/licenses/gpl-faq.html#AGPLv3ServerAsUser
So under these conditions: if you have a server where you upload a picture of yourself, and it shows how you will look in 20 years, and the server does this by making actual modifications to imagemagick, then you don't think I have to publish my changes to imagemagick? I mean if I dig into the AGPL source code and really modify the whole program to do what I want/need. I can keep those modifications private, in your opinion? While even selling the output?
I wouldn't worry too much about this case in practice because there are very few programs that choose the AGPL and don't have network interactivity.
"we know we're not liable, but the customer might get into trouble, let's make it easy to understand what can and can't be done and just forbid it"
Note to self: create a license whose concepts/terms are similar to the AGPL but don't call it that.
I guess it's AGPL then.
You only have to provide the source of derivative work, and only to users of your service.
So only the micro service using AGPL code.
If you use an AGPL database for example, you don't have to provide any source code unless you change the source code of the database. This idea was behind the business models of Rethink DB and Mongo DB.
A microservice doesn't get around it if it's tightly coupled. It would only be enough if your main application was not dependent on the AGPL microservice (e.g. you have another image processing microservice that provides perfect parity).
Again, AGPL restricts what developers can do with software to let users enjoy more freedom.
Actually I don't care much about that, I just don't want to see companies come and exploit developers work without having to give back anything. So I really favor GPL and AGPL. Then, if somebody prefers BSD and MIT, no hard feelings.
I can see why they would want to explicitly decline to participate in AGPL infections.
And "infection" is a creepy way to write "compliance".