Hacker News Reader

Comment by cic48 | Hacker News Reader

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%.

View on HN

I 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.

The 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.

> 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.

The error is using a pejorative term of FUD to identify uncertainties that are routine in every legal review ever performed. What you’re saying is you have a different risk assessment for your business and you’d take the advice and proceed anyway. That’s your prerogative. That does not extend to “different assessments from my own are objectively wrong,” which is what calling them FUD implies.

Engineers seek hard truth, which is why the malleable truth of contract and license law is ever elusive. They’re different takes on truth.

When working for eBay I've asked our legal department "So if we do this, are when then safe?" - The answer was always "The court decides, before that noone knows."

Right. That's really the issue -- it's not that the risk isn't there, it's that the risk is always there, so it's an isolated demand for rigor.

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.

> Are they now in violation of the license?

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.

> 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.

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.

There's rarely a singular author of an AGPL library, and that's part of the problem -- the business is not likely to have someone to negotiate with. Microsoft is much more of a known quantity, and the likely risk can be put into dollars relatively easily, compared to the AGPL situation.

I'm not sure that actually helps you? If you license a library from Microsoft, anyone could claim to hold a copyright on it; you might be able to get Microsoft to refund what you paid for it, but you're still liable for whatever distribution you did. I don't think library licencors normally indemnify you against that, and if anything you have less ability to defend yourself from trolls since you're unlikely to get a full VCS history the way you usually would with an AGPL library.

RDP and other remote desktop technologies has been in use enterprise for decades and it has never been a legal concern. That clause is meant to prevent people from doing unlicensed workarounds of terminal server, and it's not a concern for people doing remote access to a single-user desktop PC.

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

You're just making the same argument as the article -- that it doesn't really mean that.

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.

A PC at a desk with a keyboard and mouse is very clearly not a device "device for use only by remote users". The person used their PC when they were in office, and would be using it if not for the current pandemic.

If the device is sitting in a rack in a closet, that is a device intended for use only by remote users.

You still seem to be missing the point that your arguments are irrelevant since you would have to make them in court which is fraught with uncertainty and unreasonably burdensome even if you win.

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.

> your arguments are irrelevant since you would have to make them in court

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.

But now your argument has nothing to do with the AGPL at all and everything to do with not doing business with disagreeable people.

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.

> But now your argument has nothing to do with the AGPL at all and everything to do with not doing business with disagreeable people.

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]

Historically Microsoft has been an offensively litigious actor that paid as much attention to the rule of law and ethics in the scope of their area of business as the average drug dealer does in theirs.

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.

At least Microsoft is not Oracle, who are famouse for their horrible license audits where a whole consulting industry [1] sprung up to survive them, but yes I agree.

[1] e.g. "Founded in 2011, Palisade is the leading independent provider of Oracle contract advisory services."

Until recently, it was "extremely far-fetched" that copyright law prevents you from independently reimplementing an API. Google has particularly good reason to be paranoid about this stuff.

> Until recently, it was "extremely far-fetched" that copyright law prevents you from independently reimplementing an API.

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.

It meets the literal definition for each of fear, uncertainty, and doubt. That is true. But the uncertainty is the point. Why risk something as valuable as Google's proprietary source code over something with as little utility as some random CRAN package?

The definition of FUD is that you are spreading fear, uncertainty and doubt as a tactic not that you yourself are afraid, uncertain or have any doubts.

I think the “spreading” aspect is overstated. These are clearly Google’s internal docs that just happen to be accessible to the public.

The article:

> 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.

Quite a leap. Much more likely explanation is someone asked someone else to publish the open source docs and they did the minimum amount of censorship needed to get it out the door.

So Google is wrong for being secretive when not sharing, and wrong when they're not because clearly it's a ruse?

Heads I win, tails you lose. With that logic you can fit any action into what you already "know".

Where is anyone accusing Google of being secretive wrt AGPL decisions? The leap to try to accuse people of some kinda weird hypocrisy is a reach.

The true misrepresentation is:

> 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.

That depend on the industry they are in and how much of an monopoly position they got.

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.

Well, that's simply because most MIT licensed projects don't choose to insist on the copyright infringement damages to which they're entitled with respect to past non-compliance. They could insist on statutory damages (assuming they've registered their copyright), or actual damages/profits of course, without offering the option to remedy past violations.

Most such rights holders simply don't do this as a practical matter given their own goals.

Both license violations can involve a fee. The point is that on a going-forward basis it is sufficient to appropriately disclose use of MIT licensed software. On a going-forward basis, an AGPL violation will require either a release of the entire source tree or a replacement of the AGPL software with an alternative

If we're looking at a going-forward basis as the primary motivator of the different attitude, companies like Google would be more allergic to the regular GPLv2 than they are. The GPLv2 license automatically terminates for a given licensee upon violation, requiring the rights holder to take action to prospectively restore their license if they want to be able to legally distribute the software in the future.

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.

This entire thread has really sold me on AGPL.

The "scripts to control" clause as you say is in all versions of the GPL, exactly the same in GPLv3, and slightly different I presume in GPLv2. It has been tested in court, and its been found to not be expansive like the fud you are spreading.

Can you link to the relevant cases?

The GPLv2 version of the clause says:

> 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.

If you accidentially add a GPL or AGPL library to your codebase your codebase doesn't automatically become GPL or AGPL. GPL and AGPL are just licenses that add restrictions that must be satisfied in order to be allowed to use the software. The worst thing a license can do is deny you the ability to use the software. If your application is not licensed under the GPL/AGPL your application is violating the copyright of the GPL/AGPL library and the author can sue you for copyright infringement which is a pretty good reason to avoid using GPL/AGPL software in a commercial setting but it has absolutely nothing to do with "tainting source code". That's just fear mongering. If what you said was the truth I'd be more worried about software licenses that force you to do absurd things like kill people. "I accidentally added a kill your wife licensed library to our company internal fork of PostGIS".

It's perfectly possible that binaries that google runs on Borg cannot run on a vanilla Linux system.

Not 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.

> 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.

No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to. At Matasano, it became our practice simply to tell new clients we'd be happy to sign their paper and not ours, because we'd lose weeks just to get to the point where their legal would consider looking at our contracts. At my last company, we non-negotiably used our own contracts, and budgeted a month to legal review for every signup. New contracts are a big deal.

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.

> No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to.

[citation needed]

> 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.

The authors of AGPL packages are also not the size of a FAANG! That's the point! If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract.

(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.)

>If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract.

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.

If you're trying to pivot this to a place where I'll concede that AGPL is a good thing, you're wasting energy, because I already think AGPL is a good thing. I'm not making this point about contracts because I'm motivated to talk down AGPL; I'm doing it because, in my experience over the last 15 years, it has definitely not been the case that companies are comfortable entering into arbitrary contracts. It's just not true.

Precisely. Also the negotiation takes a long time and usually the risk is not as high as agpl, since these contracts dont have clauses like 'all your ip is mine'(except one player here known to try to sneak such a clause in every time).

From doing many sales negotiations with companies, my experience has been nobody is _happy_ to modify their contracts. Full stop. They can be convinced to do so if you've got appropriate leverage, but time with lawyers is expensive, and hard to automate (currently). Employment contract changes are not the same as commercial contracts, nor the same as IP arrangements.

>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

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.

The remedy for a violation is also in play. Private contract between two companies, cutting a 10 figure check makes it all better. Being wrong about AGPL, you have to release a lot of code that you really don't want to release, that is very important to your core business.

That's the other side, uncertainty with acceptable error bars vs uncertainty with unacceptable error bars.

> Being wrong about AGPL, you have to release a lot of code

That is also false scaremongering. You always have the option to simply cease distributing until you have re-implemented the AGPL code yourself.

I doubt "turn off Google Maps until we reimplement it from scratch" is an acceptable business continuity risk.

And most companies do resourcing months in advance on top of that. AGPL could have solved all of this with an explicit redress clause that wasn't effectively unbounded downside risk.

Google could certainly afford to implement a stub replacement library as a contingency plan, in case they really would be that worried about it.

The obvious solution is to completely reimplement the AGPL-ed software on your own, as a stub, in case the AGPL-ed software you want to use goes nuclear on you. Surely this will not cost a lot of developer time.

Unfortunately, many software companies obtain their revenue through the exchange of money for their software. This is like asking McDonals do stop serving food (and possibly recall all of the eaten burgers?).

A company which sells that much software can certainly afford to re-implement an AGPL component; or at least implement a good enough stub implementation to make the software run acceptably. Especially if, as Chris DiBona of Google claims, all AGPL software is useless and unneeded.

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.

> afford to re-implement an AGPL component

> 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.

Great! You, and all who do so, are then protected from ever having to face any problems from AGPL.

> A company which sells that much software can certainly afford to re-implement an AGPL component; or at least implement a good enough stub implementation to make the software run acceptably.

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.

> If you ever work at a software company

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.

Every GPL violation that I've ever heard about remedied was remedied over time often months to years. If you never create derivative works you don't intend to share you will never have an issue. If you do clearly and obviously conspire to break the law you can probably still negotiate yourself enough time to comply with the law and retain the rights to your own software after having tried to get away with breaking the law.

Having worked for a software producer who all but owns one segment of the industry, while they do discuss with their potential clients modifications to the contract, it is fair to say that the terms discussed all relate to fees. There are certain things with respect to IP that are totally not up for discussion.

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.

Google doesn't really care that much about the FLOSS community's contributions - they have in house projects to do everything (even a kernel or two!) just because they have so many engineers. Pretty sure the main reason they don't just ban the use of open source software internally is because it would cause their developers to riot, and the cost savings are a secondary factor.

If anything, Google probably would like to see more software released under AGPL just to screw with Amazon.

The further you deviate from using a standard stack the more you have to spend on training.

Google doesn't really use any of the "standard stack". They use open source libraries for things like SSL but when it comes to the things that matter for quickly ramping up - source control, build/test infra, release management, linters, etc - basically the only thing that isn't in-house is the languages themselves, unless you're using Go or Dart, and the text editor, unless you're using their internal web-based ide.

> 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.

> 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.

> Guess what, AGPL does that too. Its only 1 paragraph different than GPL.

Yes, and the point is that paragraph is particularly risky and untested.

> Citation needed.

I gave an example.

The point people keep talking about here as risky are: what is a derivative work, and what constitutes complete and complete corresponding source definition. Both of those things HAVE been tested. complete corresponding source definition is the same in gplv3, almost exactly the same in gplv2. Derivative work is a general copyright thing tested in many cases. The extra paragraph doesn't have anything to do with them. To recap: 99% of the license is tested, and the "risk" everyone is discussing are about the parts that have already been tested. Basically, what Drew wrote is true.

Derivative work and complete corresponding source has not been tested w.r.t. Google's monorepo (or similar situations), because under the terms of the gplv2/3, Google doesn't distribute any software.

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.

> There's an entire class of tooling to make sure that GPL-tainted software isn't distributed

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.

I mean, there's some amount of code Google really doesn't want to share (it's not shared with me and I and I work there) for various reasons including security. So I imagine there would be downsides ( and not a whole lot of up, much of the useful stuff is already shared)

Yes 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.

Honestly 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.

I 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.

The 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.

They 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).

Well, 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...

"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_a...

Chris 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.

Though 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.

> Chris DiBona is paid to care about exactly this issue.

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.

If they don't want to use AGLP software anyway, then they have nothing to complain about.

I'm a fan of the GPL etc, but in this article he is saying that in 2011, most of the complex AGPL software that would be useful to Google has a substantially similar version already implemented inside of Google. That's something I could believe about Google, especially 9 years ago.

"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.

> 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.

Oh absolutely, but it does seem like they prefer to genuflect to open source / free software ideas and it seems less distasteful to give a more tactical answer.

I 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.

Google 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.

Free 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.

Wouldn'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?

Well, 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.

EXACTLY.

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.

Under 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.

GPL 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.

The Linux kernel explicitly has a user-space exception written into its license, which is why the requirement of reciprocity stops there.

> 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.

Bit 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.

Corresponding 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.

AGPLv3 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.

By 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".

That's unlikely. You're falling into the common trap of assuming laws and computer source code work the same way -- you have a set of instructions that you evaluate from top to bottom until you get an answer. The law doesn't really work that way; there are laws, but there are also reasonable humans deeply embedded in the process. So in your case, you'd have to be the author of some AGPL software, have some third party install it on GCP, and then sue Google to get the GCP source code. Google would send a representative that says "this is a generic platform where anyone can run any computer program they want; we don't suggest that users run this AGPL program, and we have no way to detect that they're running it; this is an issue between Company X and the author." The judge and jury would then see that Google has absolutely no control over that license infringement, and would probably not award you their source code. It would just be unreasonable to any normal person for Google to be involved in your contract; they took no action to enter into a contract with you, after all. No cloud platform could ever exist if they automatically became parties to random software contracts. The legal system would take all of that into account when deciding how to make you whole.

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.

Thank you for taking the time to spell this out.

Some 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

Wow, 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.

It 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.

“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.

Reply on news.ycombinator.com