20 ms·
I’ve taken AGPL through two FAANG reviews. Both arrived at the same very-much-not-FUD legal conclusion. Paragraph 1 of section 13 requires modifications to be
by cic48 6y ago
I’ve taken AGPL through two FAANG reviews. Both arrived at the same very-much-not-FUD legal conclusion.
Paragraph 1 of section 13 requires modifications to be disclosed and source code for them to be offered to remote users. The license uses the term of art Corresponding Source for this.
Corresponding Source is defined in section 1 in a crystal clear way. Two separate teams of lawyers concluded that they could coherently argue the Corresponding Source definition implied not only the modified AGPL software, but also stuff that merely _uses_ it, on the basis that “scripts to control” among other things implies the infrastructure most shops build around software, such as Borg configuration and possibly by extension Borg. After all, a modified version of PostGIS is only useful to run in context, and Corresponding Source requires the context.
AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s risk aversion, not ideology, and it’s important to remember that identifying an argument as part of legal review does not call it the correct one. Anyone who’s ever worked with legal matters knows there is no such thing as “correct,” there are rulings. The existence of the argument condemns the license for FAANG, not its validity. Testing that validity against a claim is perilous.
Perhaps if random engineers stopped calling legal opinion FUD and falsehoods and took a moment to listen to the feedback from lawyers who didn’t write the license, we’d get somewhere with finding a palatable license for all parties. Instead, we get a holy war.
Strong disagree on developers not shooting themselves in the foot. If it’s on GitHub, it ships. If you think about licenses in your day to day engineering, you are the 1%.
- pydry 6y agoThe holy war could be avoided if Google simply paid authors of AGPL code they wanted to use instead of going on a tirade against the license. I think half the reason it exists is to make it deliberately risky for FAANGs etc. because they're exactly the ones who SHOULD be ponying up to support the open source ecosystem they rely upon.
- knorker 6y agoThey do, but it requires the existance of a dual license for that project, which usually requires copyright reassignment was put in place from the project's inception. The current maintainer can't just sell a copy under non-AGPL if there are other copyright holders (contributors).
- cic48 6y agoFree as in beer with the expectation of Venmo, is it? Joke aside, given Stallman’s writings about large businesses and their practices, characterizing a policy document as a “tirade” is a strange position. They’re not exactly buying airtime to advocate against the license. They’ve chosen to make a policy open access, something we’d normally applaud.
- TAForObvReasons 6y agoGoogle is in the position to just use non-AGPL alternatives or build their own. That an open source library exists doesn't obligate Google to use it.
- jeffbee 6y agoWell, this is the heart of the issue. Chris DiBona has publicly stated that AGPL software just isn't valuable enough to care about. The authors of such software tend to overestimate its utility. https://www.theregister.com/2011/03/31/google_on_open_source_licenses/ https://www.theregister.com/2011/03/31/google_on_open_source...
- liability 6y agoIf they don't want to use AGLP software anyway, then they have nothing to complain about.
- Lammy 6y ago"Person who benefits monetarily from developers avoiding AGPL suggests developers should avoid AGPL". I'm surprised Googlers don't have betters ways to spend their time than having such furious debates about the licensing of supposedly worthless software. Google fear AGPL so much that they used to ban you from using it for projects hosted on Google Code: https://www.theregister.com/2010/09/13/google_code_accepts_all_open_source_licenses/ https://www.theregister.com/2010/09/13/google_code_accepts_a...
- cic48 6y agoChris DiBona is paid to care about exactly this issue. Compliance is his job description and AGPL policy companywide is comfortably in that portfolio. That you disagree with him does not indict Google nor create an alternative universe where Googlers are setting out unprompted to screw the free software world that gave them 50% of their infrastructure for no reason other than fear. You underestimate the rigor required in compliance. We are talking about FAANG compliance, too, which holds nary a candle toward compliance in other verticals. This thread should illustrate why compliance decisions are largely made independently of engineering.
- pydry 6y agoThough they try to hide it it does seem that ideology is driving this at Google - not practicality. I mean, Google code banning AGPL kind of gives the game away. That, and him saying that Apache (most liberal) is really his favorite license. Oh and "we never really wanted any of the AGPL code it's all crap anyway". None of those things are about rigor in compliance. Those are about a corporation stamping its feet.
- heavyset_go 6y agoI release my open-source software under the AGPL with the option for different licensing upon discussion or negotiation, partly for this reason. The other reason is that common open-source licenses are generally incompatible with one another, and I'm happy to overcome those incompatibilities via alternative licensing for other open-source projects.
- an_opabinia 6y agoYes but on the other hand: > In truth, Google was never going to buy your software. So what difference does it make? Stop making stuff for Google for free if they won’t contribute back. It’s that simple.
- dathinab 6y agoHonestly I'm not a big fan of using *GPLvX and I didn't even know what Google was thinking about it. It's more about the bothersome of the question what the actual legal implications are. I would love if such licenses ship with a long list of positive and negative examples which if they exactly fit you overrule any interpretation of the rest of the contract... EDIT: To clarify my opinion in this context is about cases where the AGPL is in something like a library position. AGPL on software which is used as a service seems to be quite reasonable without much legal surprises.
- deleted 6y ago[deleted]
- foobiekr 6y agoI have had the same experience and the same feedback. It’s much, much, much worse in the embedded world. I think the author is being quite disingenuous on his take.
- jcheng 6y agoI agree that random engineers should have the humility to listen to feedback from lawyers. And IANAL. Here's the sentence with "scripts to control": > The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. That being said, it feels like a stretch to me that the particular orchestration infrastructure your company uses could be considered part of this. Borg is clearly not "needed to... run the object code and to modify the work" (PostGIS), which you could easily demonstrate by running and modifying PostGIS without Borg--as every other user of PostGIS does.
- knorker 6y agoIt's perfectly possible that binaries that google runs on Borg cannot run on a vanilla Linux system.
- cic48 6y agoNot only possible, it’s a fact. Borg executables make many assumptions about available runtime services and cannot operate in their absence. It’s probably impossible to derive and operate the same artifact Google is running without a complete Google architecture in place and operating, from Chubby on up. How does one comply with the AGPL in that scenario? “Rearchitect a not stupid way” is probably the answer here, so it’s a nonstarter.
- jeffbee 6y agoThe AGPL virality is considered such a big risk, and the "scripts to control" clause is considered so sweeping and vague, that Google has its own internal version of R that won't download AGPL libraries from CRAN, because just looking looking at the performance stats from production services in R using an AGPL library could taint the source code of the service itself. Nobody knows.
- saagarjha 6y ago> because just looking looking at the performance stats from production services in R using an AGPL library could taint the source code of the service itself I think this is what is being referred to as "FUD". Anyone can go after you for some sort of supposed license issue, but at some point you need to consider that many of these are extremely far-fetched and serve only to quite literally add FUD around AGPL.
- belorn 6y agoUnder the same meeting ask the lawyer about the linux kernel and where the border is for its license. They will likely give a similar answer, through if the company relies on selling devices with a linux kernel the risk vs reward will result in a very different decision in the end.
- nine_k 6y agoGPL 2 has been tried in courts many times, and there is a consensus that Linux kernel's license applies to the kernel (publish your patches) and not applications that use the kernel. E.g. Go is shipped under a BSD license, not GPL, and sidesteps libc for quite a few APIs.
- Conan_Kudo 6y agoThe Linux kernel explicitly has a user-space exception written into its license, which is why the requirement of reciprocity stops there.
- debiandev 6y ago> AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s risk aversion, not ideology, and it’s important to remember that identifying an argument as part of legal review does not call it the correct one. Anyone who’s ever worked with legal matters knows there is no such thing as “correct,” there are rulings. The existence of the argument condemns the license for FAANG, not its validity. Having worked with lawyers, this largely overstates the risk. Companies are happy to discuss, modify and sign new contracts every day. All these contracts are "unchallenged in court", by definition, because they are entirely custom. A lot of software licensing contracts for closed source have complex and restrictive clauses to prevent "renting" such software through SaaS or weakening limitations using legal loopholes. Yet companies still sign such contracts. Another type of custom and complex contract is employment. Furthermore, companies sue each other every other day over contract violation around IP, copyright, trademarks, patents but also employment contracts, rent, building regulations, shipment delays, all of that. The idea that a FLOSS license is some scary monster is propaganda. The goal of such propaganda is to drive the FLOSS community to provide valuable software for free and with zero strings attached - aka free labor.
- joshuamorton 6y ago> All these contracts are "unchallenged in court", by definition, because they are entirely custom. They do, however, very often use existing language, and custom language is minimized. > Another type of custom and complex contract is employment. Where contracts are often almost entirely standard per-company, and often standard between companies. And very rarely is the company in danger from the non-boilerplate clauses. If you want an example of such a clause, consider Google's own IP clause in its contracts, which contend that Google owns basically all of your IP while you work at Google, unless you take steps to declare ownership of it in advance (and Google approves). Will this clause entirely hold up in court? Probably not. Do you want to be the one to test it with your multi-billion dollar startup on the line? The risk of using AGPL software is significantly higher than not, and the benefits are relatively small.
- ran3824692 6y ago> They do, however, very often use existing language, and custom language is minimized. Guess what, AGPL does that too. Its only 1 paragraph different than GPL. > Where contracts are often almost entirely standard per-company "standard per-company", means custom and used used throughout the company. That doesn't make it less risky, and its not like these things don't constantly change and are hugely complicated, just look at privacy policies. AGPL is standard for all companies. > And very rarely is the company in danger from the non-boilerplate clauses. Citation needed.
- waisbrot 6y agoBy this reasoning, if I run some AGPL software on GCP, wouldn't that place all of GCP under AGPL? I've written "scripts to control" the AGPL software, so my stuff is AGPL and Google's cloud offering is to run my code automatically so all of GCP is a "script to control".
- jeffbee 6y agoSome companies do read the AGPL that broadly. That's why Square requires its own customers to not use AGPL software. https://squareup.com/us/en/legal/general/pos https://squareup.com/us/en/legal/general/pos
- jkaplowitz 6y agoWow, that "under any circumstance" is dangerously broad as a prohibition... Courts could very well read that phrase to override the assumption that otherwise might exist that actions unrelated to the services purchased from Square are outside of scope of the contract. It shouldn't jeopardize a company's ability to use Square if an employee plays with MongoDB on their corporate workstation. I realize enforcement wouldn't target this in practice, but the wording is sloppy enough to arguably bring it into scope. Also very weird is that the Canadian terms are dramatically different and don't mention this restriction at all. In fact the whole long list of prohibited stuff in section 3.II.B is absent, even though both countries' terms cover the Online Store service in which the US terms include this wording. Given that, maybe the true cause of the wording is boilerplate wording from their US lawyers which their Canadian lawyers don't have in their boilerplate? It's not simply about Square Canada being less of a liability risk than Square Inc, as most provisions of the Canadian terms do have Square Inc as the contracting party.
- rjmunro 6y agoIt would mean that because GCP is not itself under AGPL, you are not complying with the license, so you could be sued by the maker of the software for copying it to GCP. You are doing the copying, you are breaking the copyrights.
- jrockway 6y ago
- ran3824692 6y agoCorresponding source has the exact same definition in GPLv3 and almost exactly the same in GPLv2, so all this "its completely untested" thing is completely disingenuous. Google uses Borg to control gplv3 code that they also distribute, so, exactly the same case and its complete BS you are spreading. Lawyers are actually pretty good at spreading FUD about GPL, they always have been.
- ran3824692 6y agoAGPLv3 is exactly the same as GPLv3 except that it adds 1 paragraph. That paragraph has nothing to do with corresponding source or what a derivative is. Google ships distros with Gplv3 to customers GCP, so Borg and GCP stuff would be equally affected by the "risk to Borg" and other server side code, so, I don't believe that the claimed legal risk is real, just FUD.
- vslira 6y ago> AGPL is unchallenged in court What would be the cheapest way to settle this? Can I found a SaaS company that uses AGPL code, grow to ~100 usd/month and basically ask the FSF to sue me? Even if the legal fees alone amount to tens of thousand dollars, that should be low enough that a small company or a motivated (and financially secure) individual could try.
- cogman10 6y agoBit harder than that mostly because the court system is designed to avoid universally "resolved" issues as much as possible. The first hurdle is to get it into federal court (since you probably want this tested beyond your current state). To do that, you'll need someone from out of state to sue you. The next hurdle is how to get this case resolved in other federal courts. You could either setup the same scenario for each district (requiring that your 2 parties have businesses in 2 states in each of the districts) or you could try to appeal all the way to the supreme court. Tricky, because this really isn't likely to be a case that the SC would take up (it'd need the lower courts to disagree with each other. Further, they'll usually not do it unless the district courts also disagree). Overall, the whole thing would be super expensive to pull off.
- tyrion 6y agoWouldn't it be a good idea to "fix" the AGPL in order to make it clearer? It seems to me that every time there is a discussion around GNU licenses many people have no idea how to interpret them and then decide not to use them out of fear. It does not seem to me that this is in the interest of the GNU project. Why not fix this?
- saagarjha 6y agoWell, for one that would require GPLv4. And another one is that if you "fix" it down too much some smart-aleck comes around and says "but I was actually just running it and the results of the computation were beamed into people's brains, so they never knew about the software I was using and so I shouldn't have to release my source code". That being said, I think they should really update their Q&A; one personal one that I would really like revisited is the GPL and the App Store.
- ksec 6y agoEXACTLY. Instead people waste time trying to defend something that neither side can prove. And business / Startup doesn't want to risk anything when there are always an alternatives.
- rmc 6y ago“The company might have to release the source for everything!” isn't a downside for some people. The FSF's philosphy is that all source code should be opened. What you're describing as a bug (for a company), is (I think) a feature for the FSF.