> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linking which creates a derivative work, as Google implies, but rather that it makes anyone who uses the the software via the Internet entitled to its source code.
This is the problem: I've fought with IP lawyers we've had on retainer who always boil it down to: "It doesn't matter. We're not going to court to find out."
Is it FUD? Yes. But I am also not a lawyer, and I can only do so much to fight upwards as an IC. I've seen this exact mindset at every company I've ever worked for or with.
The real fear is that once you have an AGPL dependency, it's _possible_ that it makes it way into something you really don't want to release publicly, and now you have a huge mess of a problem. The easy solution: don't use software with that license.
(FWIW I hate this, and fully believe competent developers can not shoot themselves in the foot so extravagantly, but alas.)
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%.
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.
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.
Engineers seek hard truth, which is why the malleable truth of contract and license law is ever elusive. They’re different takes on truth.
For example, here's the Windows 10 license:
> c. Restrictions. The device manufacturer or installer and Microsoft reserve all rights (such as rights under intellectual property laws) not expressly granted in this agreement. For example, this license does not give you any right to, and you may not:
> (v) 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;
With people staying home because of COVID-19, a lot of companies with Windows desktops (with all their line of business software on them) have been having their employees access them from home, exclusively remotely with no local users. Are they now in violation of the license? Do you want to have to find out in court?
It's an excuse which is present anywhere for any non-trivial terms and used as FUD in contexts where someone wants to scare others away from something.
Maybe they are. But not doing that would have killed the company, so the uncertainty was likely considered acceptable.
The punishment for violating a Microsoft license is paying Microsoft more money. The cost of not doing that would have likely been more.
The punishment for building your SaaS on AGPL code and having court decide on the virality on a non-favorable way is much more severe, and cannot in general be immediately solved with a little extra money transferred between two companies.
It's all risk management.
This is also FUD. There's no guarantee that Microsoft wouldn't stand on their rights, demand their statutory $50k/infringement, and refuse to sell you any more licenses going forward. It's not likely they'd do that - but it's not likely that the author of an AGPL library would do it either.
 e.g. "Founded in 2011, Palisade is the leading independent provider of Oracle contract advisory services."
From the same EULA:
> (v) Remote access. No more than once every 90 days, you may designate a single user who physically uses the licensed device as the licensed user. The licensed user may access the licensed device from another device using remote access technologies. Other users, at different times, may access the licensed device from another device using remote access technologies, but only on devices separately licensed to run the same or higher edition of this software
The clause you're referring to says you can designate a user, but that could have to be the same user who uses the machine locally, and then they can also use it remotely. The first clause still proscribes use "on a device for use only by remote users" -- so maybe remote use is only allowed when local use is also present. Has this theory been tested in court? Do you want to be the one to test it?
And common practice doesn't save you. Lots of companies use [A]GPL software too. Look what the Federal Circuit did with API copyrightability -- everybody had been assuming that wasn't the case forever. And maybe they're right to, if another court overrules it or narrows it into nothing or a new law is passed before it matters for anybody else, or maybe not.
Uncertainty is the default. Which is terrible, but nonetheless.
If the device is sitting in a rack in a closet, that is a device intended for use only by remote users.
And I doubt Microsoft would agree to the premise that you could avoid the "no servers" restriction just by putting the server at a desk and plugging in a keyboard and mouse that nobody has touched in months.
This is simply not the case. Relationship matters a LOT here.
Microsoft's license is not like the GPL/AGPL in that there can be many random parties to it. There's not 10,000 forks of Windows each with a different rights owner who might hop out of the woodwork looking for a quick buck. The only relevant parties to their EULA are you and MS. If you are an enterprise doing existing business with MS (i.e. you aren't already pirating Windows), you simply aren't going to end up in court over some contract technicality taken out of context.
The danger to the AGPL is that there's unclarity in the language AND some rando you don't know and don't do any business with could potentially exploit it.
And many free software projects require copyright assignment (e.g. the FSF requires this), so in all of those cases you're not dealing with 10,000 different parties, only the one. If that party is litigious then it doesn't really matter which license they use, they'll still be able to find an excuse to cause you grief.
The ability for anyone to contribute is an inherent and intended feature of the AGPL, and it's something unique when compared to a traditional EULA for commercial software. The potential risks to this model might not be intentional, but they are nonetheless a result of the design.
>And many free software projects require copyright assignment (e.g. the FSF requires this), so in all of those cases you're not dealing with 10,000 different parties, only the one
To your point about arguments having nothing to do with the AGPL -- this is not part of the AGPL, and many AGPL projects do not have a copyright assignment agreement.
The bottom line of my point is -- risk is amplified by uncertainty.
[A little bit of uncertainty] * [a bunch of organizations who DGAF about us at all] = [possibly a significant concern]
[A little bit of uncertainty] * [one organization with a profitable, existing, and predictable relationship] = [disagreements are probably being settled by an invoice not a lawsuit]
If relationship counts then surely the fact that you will be dealing with one of the worst actors in IT doesn't help your argument much.
No, it really wasn't far-fetched; quite the opposite.
Don't confuse legal opinions with advocacy. Unless you're paying someone, what you read and hear online is advocacy. Attorneys in the FOSS community are no less guilty of pretending that their advocacy is the letter of the law than anti-FOSS attorneys.
I believe celebrity FOSS legal scholar, Lawrence Lessig, for example, has lost on the merits every major copyright case (as listed on Wikipedia) he got behind. (And other ones, too, like the two major election law cases mentioned there.) But all his books and articles preceding those cases, and sometimes even afterwards, made his position sound like a simple application of well established law. It was a simple application of law, alright, but of the law he and many others desired, not the law as it existed or was likely to exist when subject to the scrutiny of the court system.
While U.S. courts seem to have begun more rigorously scrutinizing pro-patent holder arguments, the opposite is true when it comes to copyright. U.S. courts are increasingly kinder to a very broad and strict (i.e. fewer defenses) application of copyright law. It's a real shame, and we could lament all day how they're "getting the law wrong", but people should set their expectations accordingly. For example, don't expect SCOTUS to overturn Oracle v. Google, at least not to the extent that it supports Google's original defense that APIs aren't copyrightable. There's a reason the judge's original opinion siding with Google was so exceptionally long and detailed--he was trying to bend the law in a different direction than it's most recent trajectory. He did an admirable job, but his interpretation was sadly but firmly in the minority.
> Ask yourself: why is documentation of internal-facing decisions like what software licenses to use being published in a public place? The answer is straightforward: to influence the public.
Heads I win, tails you lose. With that logic you can fit any action into what you already "know".
> Anyone can go after you for some sort of supposed license issue
Suppose the software in question is MIT licensed. There are certain requirements, none of them involve users having to decide between releasing their source code or paying fees. Remedying most MIT project license violations usually involves adding a disclosure somewhere in the website.
As a whole, for reasonably large companies it's a lot easier to just pick a non-AGPL project (and make one if it doesn't exist) than to bother with these questions.
Ask what would happen if a email project at google that was estimated to be released this year got delayed an additional year. How much would that impact their revenue and stock values, or even the general market share of gmail?
Then take a an high competition area where multiple companies are in heavy competition. How much of developers focus can you shift away from the main product in order to re-implement code that is already written and could be used today?
Companies in a low competition market that are large enough to already be in a dominant position can just re-implementing AGPL code. Being risk averse might also be an effective strategy, and having higher costs and slow development won't cause any direct harm to the core part of the company. In worst case they will just scrap the project and cut their losses.
In a high competition industries you can not afford that. Every single advantage that can give you an edge will be used unless it goes against the core business model. Unsurprising this is also the places where I personally have seen the least amount of license purity. The most extreme examples are from the game industry which tend to use what ever software they can get their hand on in their games and support systems as long it does not prevent the core business model.
Most such rights holders simply don't do this as a practical matter given their own goals.
Nobody avoids GPLv2 software due to this clause. Affero's original version of the AGPL (v1) based on the GPLv2 has the same clause, nothing harsher. The currently common version of the AGPL (v3) published directly by GNU/FSF shares the GPLv3's much less harsh termination provision, and indeed companies like Google do sometimes allow use of GPLv3 code. (Those companies like Apple which are opposed to GPLv3 have issues with different provisions, not this one.)
The difference between the MIT license and the AGPL, whether it's unreasonable FUD or reasonable caution by lawyers, is not about the difference in how violators are treated going forward.
By the way, in my reading as a non-lawyer who nevertheless previously attended part of law school including the contract law course, the AGPL doesn't give any specific right to _demand_ the source code of any party any more than the GPL does. It just forces the parties who act outside the license to accept treatment as copyright infringers, as with any other unilateral license, including the damages and injunctions (and sometimes criminal convictions) that can lead to. Companies can pick their poison.
Maaaybe some jurisdictions would analyze this differently as a contract that the company agreed to, with the option to order specific performance of releasing source code. I'm not 100% sure. Again, I'm not a lawyer. I don't view this as likely if the company doesn't somehow indicate to the licensor / court / public that it agrees to the license, beyond the mere fact of acting in a way that would otherwise infringe copyright.
> For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
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.
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.
And, what's more, the contracts we're talking about are all basically pro-forma. They're nothing like the AGPL, which has, in reasonable interpretations, far-reaching impact on IP across the whole company.
> And, what's more, the contracts we're talking about are all basically pro-forma.
I had very custom employment contracts with 2 well-known large tech companies. When asking to remove some clauses and add new ones they did not flinch at the ask and let me have meetings with their lawyers.
I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on
Matasano is not the size of a FAANG and similar or maybe it has a small legal team by choice.
(I have zero problem with AGPL and happily use it myself for things, but I use it the same way I feel most of my peers use it, as an explicit "no, FAANG, you can't use this code, pay me instead" marker.)
This would stop being true if (and when) FAANG figured out how to effectively use AGPL internally. In my opinion, this is inevitable as long as software continues to be published under this license. From their perspective it seems they don't even have to do anything besides wait for other smaller companies to get in legal disputes and set a precedent. Or better yet, wait for a potential acquisition to come along that happens to have won one of these disputes.
It would be surprising if these negotiations were accomplished within a small number of months. I am a small company (smaller than Matasano) and have had my contract accepted, but it is a non-trivial effort. There will certainly be items that come back, then they go to my lawyer followed by more discussion.
In the past, I did a contract negotiation with a very large (non FAANG) company and it took months, and required me to recruit internal advocates for my position.
That's the other side, uncertainty with acceptable error bars vs uncertainty with unacceptable error bars.
That is also false scaremongering. You always have the option to simply cease distributing until you have re-implemented the AGPL code yourself.
However, the point was that releasing the proprietary (oh so secret) source code is never the only option, and it is indeed false scaremongering to claim that it is.
> good enough stub implementation to make the software run acceptably
This is what the company I work for does, and most that I've heard about do, but preemptively.
If you ever work at a software company, you'll understand that you never have enough time to do what you want, and you have to pick and choose the most valuable tasks and go with those. Rewriting perfectly working code is never valuable.
No personal attacks, please.
I do, in fact, work at a tech company, and do, in fact, write a lot of code to do my job. However, it is not a software company, as it does not sell proprietary software directly.
> Rewriting perfectly working code is never valuable.
It might be far more valuable than the other option, i.e. releasing the proprietary software under a free software license. An AGPL licensing issue will only ever, in a worst case scenario, force you to choose one of those two options, no more.
Additionally, every use or purchase of software undergoes strict legal review, and there are some licenses that are flat not accepted.
This is not propaganda, and it is not in particular motivated to do anything economic to the FLOSS commmunity.
If anything, Google probably would like to see more software released under AGPL just to screw with Amazon.
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.
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.
Yes, and the point is that paragraph is particularly risky and untested.
> Citation needed.
I gave an example.
There's an entire class of tooling to make sure that GPL-tainted software isn't distributed (https://opensource.google/docs/thirdparty/licenses/#restrict...), but because the class of software that Google distributes under the GPL is limited (can you think of any?), this is workable, and such things can be isolated.
That doesn't work if the definition of "distribution" is broadened significantly. Then the derivative work questions (which aren't as cut and dry as you claim) do suddenly matter a lot more.
Amazing the lengths people go to in order to avoid sharing and treating others well! Imagine if they did the opposite: imagine if they just freely shared their source code.
> 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.
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...
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.
It’s much, much, much worse in the embedded world. I think the author is being quite disingenuous on his take.
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.
The current maintainer can't just sell a copy under non-AGPL if there are other copyright holders (contributors).
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_a...
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.
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.
Right, which doesn't really address the point being made above, which is that Chris DiBona is paid to care about the issue, has a position on it, and now has a reason to claim that AGPL code is not useful.
"MongoDB is probably the most prominent AGPL project, he said, but it replicates software already used within the Google back-end infrastructure. Google uses a proprietary custom-built distributed database known as BigTable. The company has repeatedly indicated that it will not open source BigTable, but it has published a research paper on the platform, and its basic ideas are now used in open source platforms such as Hadoop HBase and Cassandra.
In similar fashion, the company has not open sourced core platforms such as the Google File System (GFS), its distributed file system, and MapReduce, its distributed number-crunching platform."
He also made this quote:
""If you look at the interior of Google and how we make software, we don't launch a lot of software to the outside world," he said. "With the AGPL, you have to be very, very careful with how it is expressed. Otherwise you have to invoke the sharing in many different places. [The ban] is really about saving engineering time."
This part sounds like a partial truth and a partial lie. I'm sure it does save a little on engineering time, but it seems odd not to acknowledge the elephant in the room that they may have to share software they don't want to.
This is certainly not a controversial topic for anyone working in a software company. There are always pieces of software that a commercial entity is not willing to share freely with the whole world.
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.
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?
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.
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.
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.
Similar arguments would involve suing Intel for copyright infringement because their memory controller copied copyrighted information from RAM into cache. That's copying! But ultimately, Intel is just infrastructure; some user got the copyrighted data into RAM and knew full well that CPUs copy it into cache from time to time. That doesn't make Intel a party to your copyright infringement lawsuit, even though they did instruct the infringer's device to make a copy without your permission. It simply isn't reasonable -- no efficient CPUs could be manufactured if you won your lawsuit. So it's unlikely a court would hold Intel responsible.
Finally, there is the classic "if you read this, you owe me $50." You just did! But any court would find that an unenforceable contract because you didn't really consent to it. So I won't be suing you for $50. The world couldn't function if I could do things like this. So contract law exists without that particular contract being valid.
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.
* If you expect your code to be used as a dependency to a proprietary system, don't use the AGPL.
* If you are building a stand-alone system, or tools for an open ecosystem, use the AGPL.
That's a question of suitability-to-purpose. Although this use is permitted, AGPL simply isn't a good license for PostGIS (which is correctly licensed under the GPL). It is a great license for end-user applications. It's also nice for dual-licensing.
Licenses aren't something to get ideological about; it's more of a right-tool-for-the-right-job kind of thing. If you use a hammer with screws, you'll get hurt. Same thing with using BSD where AGPL fits, or AGPL where BSD fits.
* The article is right that Google IS spreading FUD. They're making legal statements which are probably false to minimize usage of the AGPL outside of Google.
* Google came to a sensible conclusion, that THEY shouldn't use the AGPL
* Google's articulated reasons don't hold legal water, and following Google's lead and interpretation causes many companies to mislicense their code
It's a right tool for the right job kind of thing, and AGPL is not the right tool for Google's job.
I've used all sorts of license in projects I've worked on. It's always a pragmatic evaluation. Right now, I'm working on a project which, pending legal review, should be AGPL. Any other license would be business suicide. AGPL gets us the ecosystem we'll need, without having to unfairly compete with our own code.
No. This is incorrect. One cannot create derivative works with AGPL code. Linking does not necessarily create a derivative work. Whether or not it does depends on the specific case, and the degree to which the code intertwines. If I have an AGPL back-end and a proprietary front-end for an online photoeditor, that's probably a problem. If I have an AGPL database and a proprietary web app using it, that's generally not a problem.
Even in the photoeditor case, it only becomes a problem at distribution. For an internal tool, AGPL+proprietary is often okay (depending on who the internal team is). AGPL means a consumer-facing web app becomes a problem.
There is a sensible decision path for avoiding linking, but it has nothing to do with this. The arguments are:
1) Engineers aren't lawyers. For a big company, it's easier to have a hard rule (no AGPL) than to train engineers to be lawyers. For small companies, more nuance is okay.
2) AGPL is as much a legal mechanism as a social signaling mechanism. If I'm using a tool not the way the authors intended for me to use -- in an open ecosystem -- that creates its own problems.
The article points out that that is not the case.
If you are using AGPL code as a library, however, then your application as a whole must be under an AGPL-compatible license. It's just that connecting to a server does not constitute linking in the GPL, and the AGPL doesn't change that.
The downside risk is damages. Those usually aren't monumentally huge. There's a calculation, but they're based on how much damage was done:
1) How much did Google profit from the code?
2) How much did the other party lose?
3) Are statutory damages greater?
Pick the highest of the three. If it's intentional -- and in this case it isn't -- you triple it. You might toss in legal fees.
#1 is the relative cost to going with an alternative solution (build in-house, license, etc.). #2 is usually zero for AGPL code. #3 is pocket change for Google. So you're likely to go with the cost of not having gone with AGPL in the first place, twice (once in damages, and once for the migration).
And I think most engineers would rather be doing other things than arguing with their employer's legal team. Their legal opinions may or may not be correct, but it doesn't really matter either way, because you are unlikely to change their mind. If Legal says "AGPL is not allowed", you don't waste your time arguing with them or begging for an exception, you just go look for an alternative component with a license they'll accept.
(If, hypothetically, one's employer's legal team were saying things completely outside the norm of the industry, it might be worth making an issue of it – but, banning AGPL is certainly well within the norm of the industry.)
”A license is required if [...] You have a commercial application that ONLY works with MySQL and ships the application with the MySQL server. This is because we view this as linking even if it is done over the network.”
Not sure if they ever actually enforced this rule.
I wrote this just to point out that different companies can view these licenses differently. If company chooses AGPL, they clearly want to block certain use cases. I would be cautious when trying to dance around the limitations.
It's not an unreasonable fear either given past events like the SCO/Linux lawsuit. IBM had deep enough pockets to fight it and win. Anyone else would have folded or been ruined.
It makes it hard to be anything but 100% "libre" (almost public domain) or commercial and closed source.
Being 100% libre means someone big can (and sometimes does) just take your work and put their name on it and monetize it. This wasn't much of a problem years ago, but it's a growing issue now. Being 100% commercial is of course the opposite. We're excluding the middle, to great detriment, and we really need a workable legal solution that won't scare lawyers.
Even SQLite, which is public domain, offers a commercial "warranty of title"  if your company requires a guarantee that there can't be a lawsuit regarding the use of this software.
GPL and standardized licences destroy this part of their business.
Also who pays a lawyers to read the thousands of page of licences for say Microsoft software (all the version of all the software deployed)? Where I work no one is able to know what Microsoft licence we need to buy, even when we ask licence sellers they mostly don't answer, and it changes all the time.
IIRC early Microsoft Visual C++ licences did not authorize the diffusion of debug compiled executables (don't know if it's still the case). How many violation of this?
It's not even whether you comply, the issue is that if your company is getting bought you do NOT want the deal to get hung up over software licenses.
Oh dear, your company's lawyers are afraid of the AGPL? Well then pay the project for a commercial license.
That's not really an argument, the lawyers are just pulling rank on you.
I’ve followed you for a while, Drew, and it’s a recurring theme. Respectfully, you could stand to listen from time to time. This is one of those times.
But that reading has never been tested in court, so from counsel’s perspective why risk it?
No competent lawyer would take the AGPL at prima facie, they’re going to look for case law - and there isn’t any.
Most areas of law have enormous amounts of case law precedent. Privacy (originally) and the AGPL (today) are areas where the lack of any prior case law makes the legal risks (as in legal uncertainties) somewhere between much higher and effectively infinite. That isn't the case with most other areas where case law precedent results in far more conventionally bounded risks/uncertainties.
Not trying to be rude, but are you a lawyer? To interpret such a license with potentially huge legal ramifications, I would rather listen to lawyers than laypeople.
This isn't settled law, and DannyBee would be quick to point out that the practice of law has a major component of risk management.
There are good rationales and bad rationales for a decision. Google made a good decision with a bad rationale. Daniel made a good decision with a good rationale. Why does this matter? If I'm running my own business, my business context won't be the same as Google's. There are times to pick AGPL, and times to not pick it, and that requires accurately understanding the law.
There are quite a few logical leaps between:
1) Daniel writing a reasonable post on HN
2) Daniel being correct in everything he does
3) Daniel making all decisions for Google
4) Daniel being the one who handles all communications about those decisions
All I know is #1.
The logic chain can break at any of those points. Perhaps Google made the decision with good rationale which was simplified or changed for communications. Perhaps someone else at Google decided. Etc. I don't know.
Some of Google's policies, viewed from the outside, look crazy ("Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office."), but may have valid justifications too. For example, Google could have automated systems which do audits which would choke on this sort of thing.
What I do know is that many companies have an irrational, unjustified fear of the AGPL, and that it often makes good business sense.
I also trust Eben for his legal judgement. He's brilliant, and usually right.
That's the entire chain of reasoning. Nothing about him always being right, only him being right in a context where your already admitted he was right. Nothing about him anyways being a decision maker, just the belief that he isn't lying about Google's reasoning.
He is not responding to a random post from a Googler on HN, or to Google's internal policies or decision-making processes. Google has a bunch of scary-sounding public-facing FUD about the AGPL, containing a bunch of legal nonsense, which is scaring a lot of people. That's out-of-line with Google's former policy of not being evil. This whole discussion has that as the overarching context.
That a reasonable Googler posted a reasonable argument somewhere about why Google made the internal decision has no connection to this discussion. If Daniel's rationale is why Google made the decision, Google should by all means post it on the page above.
As a footnote, most companies I know which use AGPL code keep a clean bright line between AGPL and non-AGPL. That's a pretty sensible policy. AGPL is mostly used for things like stand-alone apps, which don't link to anything, rather than for things like libraries which link to internal systems. People contribute code to AGPL projects without hesitation if there's a bug.
> AGPL is mostly used for things like stand-alone apps, which don't link to anything, rather than for things like libraries which link to internal systems.
Right, except for when they don't, which is just as (if not more) important from a legal perspective.
"This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed. Because Google’s core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube), the consequences of an engineer accidentally depending on AGPL for one of these services are so great that we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner."
Daniel's explanation doesn't have false FUD like this. It has reasonable legal analysis of the effect of AGPL when you have a large labor pool, which is in-line with everything else Eben, I (not-a-lawyer), or any sane lawyer would say. It's a simple distinction.
Google lies that if you so much as touch the AGPL, you risk your business imploding and the end of Google products like Maps, GMail, etc. which suddenly become open source! That's really scary! That's a lie that scares a lot of people.
There is no "viral effect" -- that's smear language designed to scare people about having a commons -- there's a share-alike. And that implosion cannot happen -- it's simply not the result of a copyright violation. It doesn't take Eben or Daniel to tell you that. If you make an accident, the worst-case outcome is you pay damages. Damages aren't a trillion dollar punitive thing -- they're designed to set things right. You pay either:
* Statutory damages (peanuts for Google)
* Profits (how much you would have made if you hadn't used the AGPL code but e.g. licensed the code otherwise)
* Damages (how much the other party lost due to your use; typically zero)
And a little bit of engineering work to remove the AGPL stuff so the violation does not continue. Then you move on.
AGPL provides no dangers beyond those of normal, licensed commercial code. If I pay for five licenses and accidentally install ten, or similar, the exact same thing happens. The AGPL is careful NOT to explode as Google describes, exactly for this reason. It's a simple rights grant. If you do X you can do Y. If you don't, that doesn't mean I can suddenly force you to do X; it reverts to traditional copyright.
There are decades of GPL enforcement actions out there, so the no precedent stuff is nonsense too; you don't need to go to a Supreme Court to understand how these things behave in the real world. It hasn't gone to a court of appeals precisely because it doesn't need to. There is little unsettled law here.
There is a little bit of ambiguity about where the line for 'derivative work' sits, but it's also not the sort of scary thing Google makes it out to be. There is some case law around this as well, just not around the AGPL. It's not rocket science to translate.
Google is trying to kill an open ecosystem, adopting exact tactics from Microsoft's nineties-era anti-Linux playbook, right down to adopting the exact same mean, dirty language to scare people. That's a nasty, dirty thing to do.
(and in the meantime, Microsoft became, by some metrics, the world's largest open source contributor; how times change!)
I mean, this isn't a lie though. Statically linking AGPL software, even by accident, does put all of Google's services at risk. It's not a certainty that they'd need lose, but you're denying that it's a risk. That's false.
Consider the values: We link AGPL software and there's an x% chance we have to spend 10 billion dollars in litigation, engineering effort, and fines to keep our stuff closed source. At what value of X do you make this rule?
> Damages aren't a trillion dollar punitive thing -- they're designed to set things right. You pay either
Punitive damages exist. They're a thing. Why are you pretending that they aren't?
> Google is trying to kill an open ecosystem, adopting exact tactics from Microsoft's nineties-era anti-Linux playbook, right down to adopting the exact same mean, dirty language to scare people. That's a nasty, dirty thing to do.
I don't follow this argument at all. What ecosystem is Google trying to kill? The AGPL "ecosystem", which is what exactly? You yourself keep insisting that AGPL only really makes sense for products, not libraries, so in what sense is there an ecosystem to kill? A random collection of products isn't an ecosystem.
That X% is at most the same for using proprietary software. AGPL does NOTHING beyond an ADDITIONAL license grant beyond that. You can pretend AGPL code was Copyright (c) All Rights Reserved. Google ought to ban all software not written in-house under that argument.
In practice, since you've set the bar at $10 billion, that X% is 0%. There is no AGPL software in existence where damages would go over a few million dollars. If you're gonna swing around paranoid conspiracy theories with 10 billion dollar numbers, as you seem prone to, you should build all your data centers underground in case aliens form Mars attack. At what X% does that stop making sense? You're risking a TRILLION dollar business.
> Punitive damages exist. They're a thing. Why are you pretending that they aren't?
You're clearly not a lawyer here. You're confusing copyright law, normal business law, and tort law. Can you please name a realistic scenario where Google might be at risk for punitive damages under the AGPL?
In a worst-case, if the copyright violation is intentional, which is astronomically unlikely, you'd be looking at treble damages. Which goes from peanuts to 3x peanuts.
re: last comment. I apologize I accused Google about lying. Never confuse malice for stupidity. It's very possible Google is just being grossly idiotic. I still have vague memories of the old Google which used to hire smart people, so perhaps I just overestimated the company.....
Can you explain to me how I'd import proprietary software into google's source code repository? The concern is about source code under the AGPL. Google treats AGPL source the same way as proprietary source: you don't stick them into the source repository unless you have access under a dual (or in the case of proprietary, single) license.
> There is no AGPL software in existence where damages would go over a few million dollars.
While I was incorrect about punitive damages, you're also incorrect about "profit" as damages, it's not the lost profit of the infringed, but the illegitimate profit of the infringer. So the potential loss isn't the cost of a negotiated license, but the total profit of Gmail or Youtube or Ads or all three over the infringing period. Yes, that's potentially billions in copyright claims.
See for example the Oracle v. Google case, where the copyright claim is for $8.8 billion in damages. So we have prior art for a ridiculous sounding copyright case with ~10Bn in damages that's currently awaiting a supreme court ruling. So X is clearly >0.
You grab a .dll file with a library you like, or a .so, and you commit it into git. Voila! This happens all the time.
> The concern is about source code under the AGPL.
No, the concern is about AGPL programs in general touching anything Googly. Google has batshit crazy text like this: "Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office." If you run an AGPL drawing program, you've broken Google policy.
> While I was incorrect about punitive damages, you're also incorrect about "profit" as damages, it's not the lost profit of the infringed, but the illegitimate profit of the infringer. So the potential loss isn't the cost of a negotiated license, but the total profit of Gmail or Youtube or Ads or all three over the infringing period. Yes, that's potentially billions in copyright claims.
No, you're incorrect about everything so far. I gave a correct explanation of how damages are calculated in this thread:
"1) How much did Google profit from the code? 2) How much did the other party lose?3) Are statutory damages greater? Pick the highest of the three. If it's intentional -- and in this case it isn't -- you triple it. You might toss in legal fees."
Profit isn't "total profit of Gmail or Youtube or Ads or all three over the infringing period." That'd be fuckadumb. Profit is the DIFFERENCE in how much Google made with the AGPL code compared to if didn't have that code (so loss in profit from a bit less functionality in Gmail/Youtube/Ads, cost of licensing the functionality elsewhere, or cost of developing similar functionality).
Java is core to Android. Ergo, potential damages were high. If Google decided to replace gmail with an AGPL email client, than you're correct. Perhaps if everyone at Google is as dumb as this conversation suggests, you're right, that might happen without a policy like this. In that case, X>0, and this policy makes perfect sense. If your employees can't tie their shoelaces, you need draconian policies to prevent really dumb things from happening. I was assuming a slip-up where a little bit of AGPL code slipped in, though. Not something like that.
The alleged logic behind it doesn't make sense, but I can see why Google wouldn't post "Our employees are idiots, so we won't allow the AGPL. We might shoot ourselves in the face with it if we did. We're installing padded walls too, because our hiring didn't work out, and we don't want the liability if someone runs into the wall repeatedly." Perhaps Google is saving face here.
This would also violate Google's source code policies. So yes, the policies are remarkably consistent here.
> No, you're incorrect about everything so far. I gave a correct explanation of how damages are calculated in this thread:
Yes, and then you later gave an incorrect (overly limited one)one.
> Profit is the DIFFERENCE in how much Google made with the AGPL code compared to if didn't have that code (so loss in profit from a bit less functionality in Gmail/Youtube/Ads, cost of licensing the functionality elsewhere, or cost of developing similar functionality)
Note I said "potential". I agree that for an accidental temporary misuse, use the value wouldn't be astronomical. But for long term use it would be. As is evidenced by the current Oracle litigation.
But note what this means: Google can't intentionally use any AGPL software in any of its products on purpose, because that opens them up to legitimately huge damages. So there's basically no legitimate business reason to import them. Accidental misuse is also potentially bad, though yes only hundreds of thousands or millions of dollars bad, not billions. But there's no upside. You can't use the software for legitimate business purposes.
So banning it is completely rational, and banning it on the reasons stated is also completely rational, because there is only downside.
I never said banning wasn't rational. I said Google SMEARING, AND LYING was a dick move, and an evil move.
P.S. To make a more consistent policy, Google should ban employees from having .dll or .so files on their company laptops, and make public page about how libraries are DANGEROUS. :)
I've demonstrated that the reasoning is reasonable.
In general (leaving out the specific $10 billion threshold, which I would agree is silly but detracts from the valid point being made), no, it's not, because AGPL software is far more likely to have lots of copyright holders who haven't transferred copyright, each of whom could sue Google, widening the litigation risk, and those copyright holders are more likely to be ideologically rather than financially motivated, which means they are more likely to pursue a case when the cost of litigation is disproportionate to the potential returns.
In either case, the outcome is damages. If I've contributed 5 lines of code to an AGPL program, damages to me are peanuts. If Google makes a reasonable settlement offer, and I decline, I'm likely on the hook for Google's legal fees.
I'll tell you a little story that happened around 10 years ago:
I got a call from a representative of Oracle, he asked me if we where using MySQL, and if I could described him how, because he wanted to help us make Better use of this tool.
We where pretty happy about MySQL at the time, and I went into deep details about how we used it.
At the end, he told me point blank that the PHP's MySQL driver was licenced under the GPL and that we had to licence our whole codebase under the GPL since it was contaminating our code as a whole.
(Even if we had encapsulated all the accesses to the driver around a single class)
The alternative was to pay the right to use it under a non GPL contaminating way.
Oracle then called and threatened us many times.
The argument that made them stop was when we told us that we where hosting the applications. This argument would not have been sufficient with the agpl.
There claim was unfonded but I can assure you that I didn't sleep well for a while!
I find I don't want even to use the GPL at times. Why? Not because I want to give away free stuff to Google. Rather, because I don't want to force others to use the same license that I use. You can use MIT code from a GPL code base, for example. I want to be nice. If Google uses it without paying me, that's fine, too. Honestly I'd probably feel pretty proud of myself at that point.
Providing the software under an open source licence was a very early choice.
But what if a rogue concurrent decided to fork and hire engineers to provide it's own, better version of the soft while keeping it closed source?
The only open source licence providing protection that I'm aware of is the AGPL.
When you throw on the project your lifetime savings, it is quite a reassuring licence.
I know we all have to eat; I'm not a zealot who thinks all software should be open either. But I don't see how developers exercising a monopoly in order to extract rent is software freedom. I just want some rectification of names.
Unless you are already under contract or other legal order to do so, you do not have to tell anyone anything regarding the nature of your business. Every piece of information you give to one of those assholes is something that will be used against you in a lawsuit. Don't make things harder on yourself.
I didn't get that, can you please rephrase?
A service provider who hosts applications does not distribute software. They use it internally to provide the service. Thus, they do not trigger the distribution part of the GPL.
So Oracle can't say "you have to distribute source to your GPL-derived work or pay us lots of money" because you didn't distribute binaries for your GPL-derived work.
Using an AGPL library for a Saas company will be flagged as a risk by lawyers during the due diligence process.
At Truework, we love open source and try to contribute when we can, but the reality is that if a library is AGPL, I'll ask my team to not use it. It's just not worth it to risk so much for a single library. Yes, it's unlikely that you will have to go to court because you use that one library, but if you do... well that's bad news for you.
If you build a business, it's about making sure that there there is a reasonable ROI for risks that you take. APGL tilts the balance towards "we shouldn't use this, it's too risky". Make your own decisions, but keep that in mind.
That's the main point, though. You aren't, in fact, a lawyer. And this is not, in fact legal advice. You are presumably expert in a non-legal field, and you are giving expert opinion on something you are not an expert on.
The GPL is tested. The LGPL less so, but lawyers seem to be more comfortable with it.
There's the extra complexity that Google compiles its binaries statically.
You're calling Google liars. There's an alternative interpretation of events where a whole legal department, with great lawyers, and backed by great engineers to clarify the technical aspects for the lawyers, come to a different conclusion than yours.
And you just dismiss that as lies. I don't think that's fair at all. You wouldn't want a lawyer to come and say "bah, you should just make that inherently NP problem complete fast for all inputs. How hard could it be? If you say it's hard then you're lying.".
> this is for informational purposes only
This is pretty arrogant. "I'm not a lawyer, but here are the real legal facts to ACTUALLY educate you".
You should say it's "for speculation purposes only", or "for entertainment purposes only".
> Don’t be afraid to use the AGPL, and don’t be afraid to use software which uses the AGPL.
This is ignoring one big problem though. Agree or not, call them liars or not, but Google and it's employees will NOT touch your software. Not only will you not get Google as users (though if you dual-license yes in fact Google DOES buy software, if they can buy it as non-AGPL), you will not get Google employees as contributors.
Google claims that they care about your privacy. Entire teams of engineers and lawyers will say the same thing. But when you look at it, you can plainly see that they are probably just saying that because their main business is collecting data about you. Similarly, Google runs many projects with a closed-source server-side component, and using the AGPL would not let them do that. Do you see why it is not surprising they would come to a different conclusion?
Is that your argument?
So because MS was wrong once, Google is wrong other times of your choosing?
I'm no longer with the organization, but it had:
* Hundreds of open-source contributors
* Millions of users, mostly paying
* Zero direct competitors using the software. With equal ground for technology, it'd be almost impossible to overcome first-mover and branding advantage unless the organization really messed up
* Hundreds of major open source users doing interesting things with the software and using it in non-competing contexts. That translated into product enhancements.
With GPL or BSD, it almost certainly would have played out as lots of competitors doing an extend-and-proprietize, and instead of a successful open company, it would have been a dead organization.
So many misconceptions abound.
The flip side, though, isn't that everyone should use the AGPL. You should have the right license for the right context.
(Btw, one can argue that you have a vested interest in strengthening AGPL so that other companies would more readily choose your AGPL software and then be locked in to your ecosystem, so you're knowingly minimizing the associated risks on this thread.
You see what I did there? Yeah, attack on your integrity based on speculations, exactly like TFA.)
I think the one exception -- and this was an extreme example -- was the firmware of a medical device which could endanger human lives if modified. Things were locked down.
But generically? I'm batting maybe 75% with open source in highly-regulated industries.
You can certainly use open source in regulated industries -- the question is, can they risk the legal possibility of being forced to open source the rest of their stack if the a court determines AGPL requires it.
NDA / sensitive government work -> FOIA makes restrictions tough. I can request government source code.
Trade secrets -> The government can't really keep trade secrets. I guess if I were working with classified code?
Hard-coded exceptions -> Not specific to regulated industries but bad design.
Legal possibility -> This is not a legal possibility. A legal possibility is paying damages. It's the same if I break a proprietary license too (for example, accidentally ship out a copy of a library I paid for just one license with my product).
Above, I was referring to trade secrets in the private sector, but actually, that is one of the FOIA exemptions too.
Also, a lot of code running in production is poorly designed. I'd bet the vast majority of it is poorly designed.
Damages are one part of it, but you also have to return to compliance, which means you either have to follow the license or stop using the code. Given that the AGPL doesn't have linking exceptions, the concern is that might be all of an organization's code.
That's not to say that you can't use open source in industries where these might be concerns -- almost all other common open source licenses don't have this problem.
I've run into lots of libraries over my career with vague, conflicting, or otherwise questionable licenses. So far, 100% of the time I've been able to easily find an alternative open source project with a better, more clear, license. If both get the job done, I'll pick the one that doesn't keep me up at night every time.
I had a similar experience. I took exams on patent and copyright law with IP lawyers as teachers during my degree.
Then I worked in well known tech companies and had the opportunity to attend meetings with lawyers, business people, read contracts, etc. and oh boy!
Misconceptions abound terribly. The average techie overestimates his/her understanding of law and business.
"permissive" licenses are stupidly lenient. Companies never sign similar contracts between each other when exchanging goods or services. Contracts have hundreds of defensive clauses to mitigate risks or ensure fairness.
Why? Because for most open-source licenses, it's clear how to avoid any license controversy entirely by simply never conveying the licensed work. If I don't ship you ("convey to you") any binaries, I have no obligations to you under GPL (or MIT or Apache, obviously). For the most part, we don't ship anyone outside the company binaries, so compliance (both in fact and in provability of that fact) is relatively easy. Not so with AGPL.
If there was critically useful code only licensed under AGPL, we'd consider it, of course. But it would get a lot more review than a typical Apache/MIT/GPL license situation. I have no philosophical objection to AGPL; I just find it a much less practical license than most of the other, much more commonly used, licenses.
It depends on what you're trying to accomplish. If your goal is to build a low-friction library for others to adopt (e.g. JQuery), it's a horrible, horrible license. If you're trying to build an ecosystem around an end-user tool (e.g. I'm making a web-based competitor to Adobe Illustrator), it can be an awesome license. Lots of open source tools aren't intended to be integrated into other systems, but used stand-alone. That's where licenses like the AGPL really shine.
So i'm just going to say:
1. The author claims the Google states something, then doesn't actually quote anything google stated, but instead writes their own interpretation of the words and a made up example. That's not a good start.
2. Having set up their own example, the author then proceeds to say it's wrong because of an appeal to authority, asserting no reasonable disagreement is possible - when not only is it possible, but large numbers of IP lawyers disagree on what the AGPL requires. It's true that someone wrote it, and there are FAQ's, but depending when and where, their opinion on what it means is not as relevant as one might think.
In truth, lots of people disagree over interpretation of the AGPL - many more than disagree about GPL interpretation or LGPL interpretation (which are fairly settled at this point). Searches over any legal licensing list in existence will you this.
When I wrote the interpretation you see here, it was the best available info at the time, guided not just by own views, but by listening to a lot of smart lawyers, counterparts at other companies, etc.
Even if you ignore all the lawyers and whatever as useless, the author has the huge problem that There are people who make AGPL software that take the view listed in the google policy
So it's not just Google or lawyers, it's software authors. Not just a few, either.
While companies are generally happy to ignore one or two people whose interpretation is outside the norm (and just not use their software), that's much harder when there is such widespread difference in view of the AGPL.
3. For no particular reason at all, the author then decides to assert a tremendous amount of bad faith in interpretation of the AGPL and reasons for publishing such policies.
We published our policies because over the years I (and others) were repeatedly asked by counterparts at other companies, various communities, and others to understand what our policies look like, for a variety of reasons (to understand for themselves, to use as a template, etc)
That's the whole reason.
It even says this: https://opensource.google/docs/
The author here has decided that's clearly all lies or deliberate misinformation, without even bothering to even ask anybody.
It's a shame the original article has such flaws in its argumentation, because at the core of it I think there are some good points. Notably, other people don't have to blindly follow Google's example and reasoning. In fact, as discussed here, there are good reasons not to. For one, because Google is so highly integrated (with Borg and its monorepo, not to mention custom approaches to security), it's harder to use AGPL software without risking linking. Most other users outside Google would just apt-get a package or the like. And of course the business risk to Google is large simply because of their scale.
You can even disagree with Google's decision not to use AGPL, but they have openly explained their reasoning, and I think that adds to the discourse.
Disclosure: I used to work at Google, and was fairly actively involved with open-source activities in different capacities while I was there. I am also on record as sharply criticizing Google when I believe that is warranted. This is just not one of those times.
Not that I'm surprised, as you've always been pretty forthright and honest. Thanks for continuing to be that way.
I actually do think it's reasonable to expect companies to re-evaluate every few years (at a minimum) because the world changes. At some point, the reasoning from X years ago will not make sense anymore.
One of the top rules of sane policy making is to write into the policy the conditions that should cause you to re-evaluate it, whether it's time, or change in evidence you relied on, or ...
You want people to understand your rationale and what might change your mind, otherwise you shouldn't expect them to go along with it.
Even though such a rationale exists in various emails, etc, I actually failed to do that in the resulting police here, unfortunately (the internal version is not any better in this respect). That one is on me and I think would be a more legitimate complaint here.
I don't think it would have changed yet (if anything, the AGPL has become more contentious as the economy has gone south), but that's just an at-a-glance view.
Is there an existing national court case which supports this assertion? Otherwise it's a valid concern given that lawsuits and judges may have different interpretations than engineers. Just look at the Oracle vs. Google debacle over Java.
Courts will also look at the bargaining power of the parties. If the party offering the contract is a lot more powerful than the party accepting the contract, they will tend to favor the accepting party when it comes to ambiguous terms.
Someone writes a blog post with an 'IANAL' disclaimer on top saying that what Google's army of lawyers have gathered from reading a legal document is false, and I should favor his interpretation instead. I don't know, I'm not exactly convinced.
Microsoft with their giant army of lawyers also said GPL is a cancer and they promoted this idea a lot but today Microsoft "loves" GPL. I think you can conclude that you should use your own brain to decide and not let a giant company decide for you, they might have a huge financial interest to promote a certain narrative. It is clear in this case that Google would prefer their employees won't work on their free time on AGPL code.
Google's army of lawyers say: If PostGIS 'this' => Google Maps must be 'this'. And the author says, 'no, that's false'. Someone must be wrong here. And if I had to place a bet on which side is more likely to have gotten it the way a court of law might interpret it, I'd put my bet on a bunch of people with law degrees.
Consequently, always treat guidance from folks with law degrees with a degree of skepticism. Do your own research and ideally get your own person with a law degree to develop an opinion you can trust.
I think you mean "your own lawyers". And my experience says that the AGPL opinion among these experts are about as one-sided as scientists and climate change.
But you're suggesting to armchair lawyer it?
It's OK to drive drunk, as long as you put a blindfold on so you can't see that you're drunk?
Don't do X because Google is doing it, think for yourself and if you consider that you are not sure then ask for an expert. My point is if Microsoft says GPL is evil and you believe that and later when MS is open sourcing stuff and contributing to Linux you will have to admit that maybe MS had a giant interest to say that. those interests changed so MS changed, you should have never listen to MS without thinking for yourself and considering what MS interests are.
Before starting to use code for my business, I'd check the license, yes. Almost all the time it's a standard one, so I know approximately that yes BSD, MIT, GPL, etc… means. Though I have to be careful about BSD with advertising clause.
Before starting to depend on code for my business, yes I would make sure that I am not violating a license.
Your "only if you decide you need a lawyer" seems to be saying that your opinion is necessarily right. You don't decide if you need a lawyer, you either do or you don't. And you make the right choice or you don't. (and their guidance is right or it isn't)
> Don't do X because Google is doing it, think for yourself and if you consider that you are not sure then ask for an expert.
Sure. You can peruse the AGPL, and if you think your amateur interpretation of this legally untested license does not add unacceptable risk, then you can choose to go ahead with it.
Google got sued for reimplementing an API. And they may lose (currently awaiting the supreme court).
People have been suing much smaller companies for GPL violations. It's a matter of time before someone sues for perceived AGPL violation due to what Google's lawyers are describing.
> My point is if Microsoft says GPL is evil and you believe that and later when MS is open sourcing stuff and contributing to Linux you will have to admit that maybe MS had a giant interest to say that.
Yup. That doesn't mean they're factually wrong. But yes there's the aspect of "It's hard to make someone understand that they are wrong when their income depends on them not understanding it".
But just because someone has a reason to do something, doesn't mean they did it. It's not an argument about correctness.
Exactly, Google using or not using a license or some shady practice does not mean it is correct. It sucks that in US you have this weird thing where until someone is brought to court you are not sure what the rules actually are interpreted, from what the other comments mentioned the author(a lawyer) responded to this concerns and clarified things but yeah, we might need to forever wait or find some more courage
"No" is pretty cheap, and they were pretty good at it.
Now, is it really? Paying a team of software engineers to recreate every AGPL project surely isn't…
The problem is not just the risk associated with AGPL, it's also that the benefit is actually quite small. I think most companies would be a lot more willing to use AGPL, if there were any compelling projects using it.
And yeah, this goes entirely counter to making profit, but hey, I think we're privileged enough to afford to try ideas like this.
TBH, I'm interpreting this statement just like Google is:
> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code.
What's the definition of 'derivative work' here?
For example, if I build an extension which works with Chrome and Firefox, over a well-defined API, that's an independent work. AGPL/GPL/LGPL does not apply.
If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.
There's a lot of literature out there about static versus dynamic versus microservice abstraction. That's mostly nonsense. Lawyers don't care about that. You can't get around the AGPL (or even the original GPL) that way, by isolating the GPLed code into a corner over a network service.
(disclaimer: not legal advice, get a laywer if you want legal advice).
> If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.
So why does the LGPL/Linking Exception exist at all? Software which links against libc doesn't have a mutual dependency; libc is quite happy to run crt0 as long as there's a main symbol somewhere, and yet apparently linking against libc would be enough to constitute a derivative work were it not for the exceptions in the LGPL.
LGPL mainly exists because statically linking a library into a binary (especially with link time optimizations enabled) will somewhat modify the binary code of the linked library in the way it is placed in which some lawyers use to argue that static linking is always a derived work.
So LGPL let's you rest in peace if you need static linking.
(I also have read arguments that even dynamic linking is derived work or that it's totally independent of the linking method but on how the linked code is used. All from lawyers, through not all from US lawyers. Also that was quite a while ago, some curt might have clarified such aspects.)
What LGPL can do is to reassure people by providing specific permission to use the code in some resulting work, no matter if it turns out that it actually is derived work (in which case the licence would grant you the rights you need) or not, in which case you don't need the permission, but it doesn't hurt to have it.
Because RMS wanted a long time ago to have a bright line in the sand that differentiated between a single derivative work and two works that simply communicate with each other. As the story goes he initially thought that linking was two works communicating with each other, but after consulting with a lawyer, the lawyer presented the following scenario. A person goes in front of a judge and say: this piece of software which can not start without my work, (if statically linked) can't be compiled, can't do anything useful by itself, is not an independent work. What will the judge say?
RMS then agreed with that scenario and decided that this served as a good line for enforcing the GPL, and for projects like the standard library and similar tools an exception was needed.
Also considering the internal-only patches to OSS libraries, it'd be at least a pain, and quite possibly a wide avenue for trade secrets to leak (not to mention that most of those are so specific to Google's highly specialized production stack that are useless to anyone outside).
> You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
> c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
This is a requirement which is common to many GPL-like licenses, and one which some developers object to (the later requirements for use over the network notwithstanding).
That said, I don't believe the above terms would apply to the hypothetical Google Maps example above, as the license's requirements for making the software controllable over a network seem to be significantly less restrictive:
> 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.
In that situation, the question of what constitutes a "derivative work" might come into play.
Disclaimer: I'm not a lawyer and this isn't legal advise, just my own interpretation based on my reading of the license.
At least, that's my layperson's understanding of it.
I believe this is only as a result of the linking exception; I don't know if this has ever been tested, but my understanding was that linking (either statically or dynamically) against a library was generally considered enough to be a derivative work.
Legally people can't decide which form of linkage count as deriving and if the linkage form even matter, but static linking with LTO is most times seen as causing a derivative to be produced.
The former, as a general rule, does not create a derivative work. It's specifically called out in the GPL FAQ as something that does not create a derivative work. (Another case that doesn't is fork/exec of a separate program.)
The latter, linking a library, is why the distinction between the GPL and LGPL exists. As a general rule, if you link to a GPLed library, you do need to provide your source under a GPL-compatible license. (glibc is LGPLed.)
But people wouldn't use PostGIS by linking to a library, they'd use it by talking to a server.
Could you point me in the direction of a court ruling establishing this general rule? I couldn't find anything after a quick search.
You didn't mention this part of the GPL FAQ (directly after the part you talked about):
> 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.
Determining what constitutes "intimiate enough" sounds pretty difficult and open to interpretation: what's a "complex internal data structure"? If PostGIS is serialising its (presumably complex) representations of data and sending them over a socket to your program (and vice versa), then does that count?
I think it's also worth noting that "derivative work" is an established legal term; if it comes to a lawsuit, it's probably more likely that the judge will fall back on established precedent on what constitutes a derivative work and enforce the literal terms of the license as opposed to looking at FAQs written by someone who is not a party to the contract.
The last case I could find that substantially attacks the question of what constitutes a "derivative work" in the case of software was in 1994 (!), and I can't find any case that tries to answer it in the case of software libraries (whose only purpose is to be used in larger works). There are tests for determining "derivative work", but a) minor circuit split there and b) they're difficult to apply. In the context of what we're talking about here, it is not an established legal term. In such cases, courts are going to lean more heavily on consensus interpretation.
There's a not-well-understood interplay here between the rights of authors to control derivative works; extending analogies copyrightable and non-copyrightable elements of literary works (well-established) to software (far less so); fair use; and general contract principles (specifically, selling a product confers necessary rights to use it). Our current legal understanding of the situation is almost entirely based on an informal consensus rather than any case law, and there is wide potential for a single oddball case completely wrecking everything... like Google v Oracle.
> Determining what constitutes "intimiate enough" sounds pretty difficult and open to interpretation
I read that generally as suggesting a mens rea approach: if you're building IPC in such a way as to specifically avoid meeting license obligations, you should be considered in violation. If instead you're using it in a more well-defined and sanctioned API boundary, you're probably okay.
As I understand it, the rationale for that FAQ entry was that a blanket statement that communication over a socket never creates a derivative work would allow for things like "what if we built a stub that just moves a shared library out-of-process and copies memory back and forth over a socket", or other similar tricks.
Of course, if Oracle v. Google holds as case law (which we'll find out any month now), then the software world turns upside-down and inside-out, and much of the industry will have cases against each other over "API copyrights"; in that world, I have no idea where this would fall.
The case won't be heard until Oct 7, and I would think a decision unlikely before January.
I can't imagine the tortuous logic one would need to arrive at a different conclusion.
From a legal perspective I'm unaware of any ruling which establishes a difference between components communicating via TCP and components communicating through function calls at the ABI level (e.g. linked libraries); the latter is apparently enough to constitute a derivative work (see the LGPL/Linking Exception). There are obvious technical differences, but it's not clear that they should be treated any differently from a legal perspective.
It's like saying a public transportation company derives from a specific model of trains they use.
Sure the storage system enables Google Maps to work but any storage system with similar functionality would.