[joshuamorton]

> All these contracts are "unchallenged in court", by definition, because they are entirely custom.

They do, however, very often use existing language, and custom language is minimized.

> Another type of custom and complex contract is employment.

Where contracts are often almost entirely standard per-company, and often standard between companies. And very rarely is the company in danger from the non-boilerplate clauses.

If you want an example of such a clause, consider Google's own IP clause in its contracts, which contend that Google owns basically all of your IP while you work at Google, unless you take steps to declare ownership of it in advance (and Google approves).

Will this clause entirely hold up in court? Probably not. Do you want to be the one to test it with your multi-billion dollar startup on the line?

The risk of using AGPL software is significantly higher than not, and the benefits are relatively small.

[ran3824692]

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

[joshuamorton]

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

[ran3824692]

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.

[joshuamorton]

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.

[zeveb]

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

[joshuamorton]

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)