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.

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.

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

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)