This makes absolutely no sense. I'm almost certain that Square lawyers fucked up big time.
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.
I think this is about including AGPL code in a website that you have hosted by Square. They are probably worried that if AGPL code is included, this will result in Square sending it to browsers together along with their own proprietary code, which could be interpreted as an AGPL violation by Square.
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.
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.
I am not a lawyer - However my own take on the AGPL is that if there's an external tool, an entirely separate process that is open source and does things, then as long as that source code is published and public a user is OK to use AGPL things.
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 not a lawyer - However my own take on the AGPL is that...
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.
That is the intent of the AGPL, right? Presumably if there was something under AGPL that was good enough, your company would open source everything so they could use it.
My limited understanding is that it gets substantially more complicated than that, as it pertains to 3rd party liabilities, obligations and what not. I am not a lawyer so I am not entirely sure what risks they are avoiding. Maybe it really is all about money. I just know they won't budge.
The reaction to the AGPL seems to almost mirror the reaction to the GPL 20 years ago, so many companies were afraid of running anything GPL'd then but they got over it eventually. I think the same will happen with the AGPL, cloud providers will probably be the MS of this era, they'll be the last to accept it.
And even if there were liability concerns due to copyleft or other clauses in AGPL, singling out AGPL makes no sense. If they want to avoid copyleft, it should be better phrased like so.
Note: I've not looked into the details of what square is doing. This comment is on AGPL in general compared to other licenses.
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.
From the very specificity of the restriction, I gather that they're not copyleft-adverse. They're "Don't upload stuff that risks us being forced to divulge our closed-source code.". Without the prohibition, even if a user of the service included some AGPL libraries without Square's knowledge, a cunning lawyer could argue that Square was complicit in distributing this code to end-users and thus liable. The prohibition makes that argument difficult.
Square is bound by copyright law just as much as anyone else. Agreeing to that license is the only thing giving them permission to redistribute it in the first place.
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.
Square didn't agreeing to that license. A third party did.
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 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?
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's almost like they used some kind of AI software to scan legal documents, then it found sentence fragments like " .. opportunity for all users interacting with your Program through a computer network ..".
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.
Some would maintain that being a legal analyst requires you to be artificially stupid because you are looking for loopholes and trying to avoid being trapped by ridiculous edge cases, whereas AI is trying to find a general solution that will work in 6-9s cases.
I see that aswell. else, google would need to provide the source code for gcloud, since I can run agpl software on top of their compute nodes...
like wtf?
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.
My comment was a reply to the parent comment, not a reference to the article. What the parent comment says sounds like the true purpose of the new mongo license.
I mean I never understood AGPL for client-side code to be honest. Would the GPL not cover this use case? My understanding of the license is that the GPL would of been enough, unless the AGPL has some terms I'm not aware of that aren't server specific like ensuring access to code in unobsfucated form or something.
I don't think your expectations are the limit, but rather what your users (and their users) will end up actually doing, whether or not you expect or foresee it.
> By using Square Point of Sale, Customer Engagement, Appointments or Employee Management, Square Online Store, and any associated products and services (the “Services”)
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.
FWIW they also clearly ban a lot of other things in that section that are obviously only targeting the hosted online store. For instance:
> 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;
I don't use square so I haven't read the full terms, but I think it's important that B 15 is under
3. Online Store
I. eCommerce Terms
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?
> 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.
Yeah but why in particular wouldn't this one be? There's no reason you couldn't have it be a condition of a contract that software licensed under some particular license isn't allowed. Choice of software license isn't a protected class or anything like that.
Doctrine of equality does not apply to private trade of products and services. This is not a public procurement announcement and they can disallow particular products to be used in their premises.
I think the amount of discussion on this thread shows why AGPL is such a horrible license, there are loads of interpretations and the only way to know for certain is being sued.
I'd rather not have code source available under things like AGPL than run the risk with the minefield for lawyers it becomes.
Yes. AGPL attempts to infect with copyleft all services it is integrated with, so contractually prohibiting AGPL integrations is the only defense against AGPL infections.
This is a common misunderstanding of the AGPL. It has the same combined work rules as the GPL. It just has the additional condition that a modified work offered as a network service must make the corresponding source available.
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.
So, then, since Square’s application is a work, if an AGPL service interacts with it to modify Square’s work, your assertion is that this does not count as a modification introducing AGPL responsibilities.
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.
Square is taking a conservative approach on what a “modified version” as used in the AGPL is. It hasn’t really been litigated so different lawyers have different opinions. Square’s position appears to be combining Square’s products with AGPL code creates a “modified version” of the AGPL code and would require providing the code for Square’s products.
Conservative approach would be taking approach that is possible interpretation of the license. Their lawyers made just a mistake.
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.
The restriction applies to anyone “using Square Point of Sale, Customer Engagement, Appointments or Employee Management, Square Online Store, and any associated products and services”. I’m not sure why you think it only applies to people selling software. Nothing in the terms says that.
To clarify the question without trying to answer it myself, restated in terms of Amazon rather than the less-understood Square Store, here are two similar questions that may have different answers under the Square terms update:
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?”.
In this context "Your Content" is not the stuff you're selling, but the content you're using to customize the store frontend.
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.
AGPL is really weird. There are widely differing opinions on what it means. There is this extreme where it is horrific, then you have this guy on stackoverflow who makes it shound like a kitten with claws removed [1] The ambiguity itself in interpretation (or at least how the "general public" interprets it) is a danger signal to avoid it.
From the comment thread, there seems to be a bit of confusion on what the AGPL actually can do, so people are just avoiding things under AGPL as an abundance of caution. It seems that the license has never been tested in legal challenges. Seems like this would be something right up the EFF's alley. Is it really in the open source community's advantage to have something this confusing lingering for so long, or would it be better to get this kind of confusion cleared up altogether?
I don't think it's just the wording of the license, though. It's really hard to envision every possibility and decide how the AGPL should handle it. E.g., are they really going to add something as specific as "If a cloud service provider hosts its own code along with user code that includes AGPL code, the cloud service provider is not bound by the AGPL and the user does not need to include the provider's bundled code when they release the source code in compliance with the AGPL."?
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.
The only way for case law to be developed would be for a copyright owner of AGPL-licensed code to sue a user of their code. EFF wouldn't have standing to sue unless they are a copyright owner of AGPL-licensed code.
Scratching Square off my list of service providers. I bet half of their datacenter software is in some way or the other using AGPL-licensed stuff; hypocrisy is just insane.
It might be GPL but I would guess it's not AGPL. AGPL requires you to open source the code to run the service. They've not done that. Their legal people are likely on top of this. It's not hard to run a SaaS and avoid all AGPL
How does "linking" works in this regard? If I have an internal AGPL service do I have to open source that too?
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?
This is half the reason why many large companies have prohibitions on using AGPL code - no one is quite sure exactly what counts as 'interacting remotely', and thus what would be in scope for the source release requirements. In the absence of any case law to clarify the situation, many orgs just prefer not to bring in that uncertainty in the first place.
> 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.
That's your interpretation and that's the problem because you might be wrong in some subtle way that a lawyer could exploit. Also, you are looking at a single paragraph, there's a lot more to this and it includes notions of linking, derivative works, distribution, etc. Lawyers really don't like having a lot of open questions around this stuff and some of the more extreme interpretations would be very disruptive for any business that wants to keep parts of their software proprietary.
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.
You're arguing that companies should fear the license because there is uncertainty and you doubt that an unproblematic interpretation is accurate, but that that isn't FUD. It's fear, uncertainty and doubt.
> 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.
It's reasonable fear, not unreasonable fear if countless lawyers in countless companies seem to be coming to the same conclusions and enforcing very strict policies regarding this (fact, not imaging this). When in doubt, listen to lawyers, not engineers.
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.
> interacting with it remotely through a computer network
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.
Usually AGPL products are dual licensed, allowing development of sustainable free software businesses, so I suspect the real reason is that companies simply don't want to pay for commercial licenses.
Companies often pay for commercial licenses and to use SaaS. Just look at the number of companies paying for Oracle or support from a GNU/Linux vendor like Ubuntu or Red Hat.
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.
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:
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:
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:
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.
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:
Didn't debian change to the AGPL version of ghostscript in a patch security update? If you use imagemagick or other pdf related libraries that maks use of ghostscript, this could happen easier than you think.
Up until 2 years ago, I ran Squares Production Engineering Infrastructure group, this included all datacenters and networking. Included automation for both.
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.
iText and Ghostscript use AGPL, but both have alternative licensing under commercial licenses. There really aren't many important AGPL projects and they are easy to avoid.
I anal but My personal opinion is that if you use the ghostscript binaries by someone else and your software simply wants to create a PDF (for example) using ghostscript that is already installed on that machine, then it doesn't make sense to say I have to give the people who interact with the software my software's source.
As a consumer I actively avoid vendors who use Square, anyways (at least whenever I can). Way too creeped out by their data harvesting and tracking of purchases. I made the mistake of choosing "email me my receipt" years ago and have been paying for it ever since. As far as I'm concerned, Square is garbage.
It's not rare to see even very high profile legal firms totally mess up when it comes to software licensing in general and open source licensing in particular. Chalking this one up to incompetence rather than malice until there is proof it is the latter.
That's fine but there needs to be more demand to force competance.
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.
I don't fully understand the context, but I'm guessing that if you provide a service using software that's AGPL licensed and use Square to sell it, they have no way of complying to the AGPL terms of providing end users (your customers) with the source code and/or a link to it.
I have two problems with accepting that as a correct interpretation:
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 looked it up. Agpl is meant to close the loophole whereby, you know Google can use GPL tools while they index the web but I can't demand a copy of their private repos source code, since I just get to use the result (over the web). Agpl closes this loophole.
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.
>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.
Dude, I literally didn't know what agpl is. I found:
>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.)
> 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.
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:
> 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?
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].
Thanks for your detailed reply, I read it carefully. Let's stay on imagemagick, except we pretend it has an AGPL license (that's not it's actual license, but this is the example I want to stick to.)
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?
If you keep your modified imagemagick a separate program from the server that interacts with users (and don't e.g. exchange complex internal datastructures over IPC between imagemagick and the server) then it seems fine. If you add network interactivity directly to imagemagick then no.
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.
>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
Only specifically your changes to AGPL code, but otherwise correct.
This is reasonably well described on GNU's own page[0] on the AGPL.
Well I shouldn't have to publish them, if I'm not distributing that software.
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.
This seems either a prank or ideologically motivated. Beyond the fact that there is no legal reason to prevent your users from using copyrighted code since you are not breaking copyright if you are not a party to the contract, the wording is bad - there could be similar licenses that are problematic but aren't named AGPL v2 (or greater)
Network GPL, like GPL but if any system in your network (think of a chain of micro services) uses an AGPL/AGPL-like dependency, then all of your services have to be open sourced too.
That's not true although it is easy to misunderstand AGPL in this way.
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.
Except AGPL doesn't have the linking exception from LGPL, so your entire application is covered.
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).
IANAL, but the source distribution requirement from network use only comes into play if the original AGPL work is modified. Section 13 of the AGPL seems to be the only part of the license that deals with remote network access, and it specifies modified versions. Everywhere else the discussion is around "convey", which in the definitions specifically excludes interaction over a network.
Some days I wonder if my brain is just wired significantly differently than most people. These single letter shift typos rarely even register in my mind. Hell, my mind registers words with 2-3 letters off perfectly fine. What usually gets me is when sentence structure is significantly off, not this kind of stuff.
My description was a little too short and poorly worded. I meant if you implement the service using the agpl project, and only expose the API over the network, the source becomes subject to the same terms as if you had distributed the service binaries. So in this case whoever does own the service has the liability.
I don't understand why are there so many proponents of the AGPL when it's one of the most restrictive and therefore against freedom licences there are.
It removes developer freedoms in order to ensure user freedoms; claiming it is "against freedoms" is like saying the Bill of Rights--which restricts the acts of government--is "against freedom".
It's the opposite thing because there usually are a thousand users for every developer, so you're restricting the freedoms of 1000 people to defend the freedom of 1 person. While there's 1 government official whose freedoms are restricted for every 1000 people (made up numbers but you get the point)
In this metaphor developer == government official and users == citizens, so you should agree with GP.
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.
Please re-read your parent's point. By your own logic, if no.(users) > no.(devs), then it makes sense to prioritise freedoms(users) > freedoms(devs), which is precisely what the AGPL does.
All it does is ensure copyleft works with software as a service, in which you don't even get a binary that you could, with GPL, request the sources for.
Similar to how my freedom to shoot you is restricted by your freedom to be safe. There is no such thing as a licence that protects every freedom for everyone.
Because for some people, open source is not about freedom of use of the software, but freedom of source. They feel that existing FOSS licences can't protect against modification without release in the case of cloud usage, so they use this licence to protect the openness of modification.
If your operating system is AGPL3+, are you prohibited from using tools upon it to access any/all Square services for any reason? Are you in violation of every copyright agreement on your hard drive due to your failure to reconcile the AGPL3+ terms with the software licenses you are integrating with the operating system through installation and use?
I can see why they would want to explicitly decline to participate in AGPL infections.
Most proprietary software with EULAs does not contain a copyleft provision that forces itself upon other software. I find copyleft creepy and power-hungry, so my choice of word reflects how I perceive it.
an agpl lisc only requires that you provide the code you altered in order to integrate. prohibiting it from running on their servers simply closes the door on people coming to them for code they don't even own!
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.