[rblatz]

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.

[teddyh]

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

[yencabulator]

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

[foobiekr]

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.

[teddyh]

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

[zaarn]

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.

[nomel]

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

[teddyh]

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.

[nomel]

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

[teddyh]

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

[euroq]

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

[teddyh]

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

[michaelmrose]

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.