EDIT: The only FOSS license I know about that doesn't do this is AGPL, which Google is known to be extremely averse to.
* The OpenWatcom license requires source code publication on use. This was approved by the OSI but not FSF, which means its one of the few times a license can be described as Open Source but not Free Software.
* SSPL extends AGPL's copyleft clause to include support utilities, which didn't pass muster at either OSI or FSF (which is inconsistent with the OSI's prior opinion on OpenWatcom but )
IMHO, Google's not wrong to reject AGPL. The license makes it very difficult to use modern fork-and-pull-request workflows unless you write all your code to be a quine. And the lack of people using it makes it mostly useful as an exception sales vector rather than a legitimate renegotiation of the copyright bargain like GPL is. But Google's objection to it is rather weird, based on some hypothetical scenario of "GPL virality" making them publish internal tools. This is a misreading of underlying copyright law; I have yet to see a court demand specific performance of any source code publication requirement[0]. They will give you money damages and possibly an injunction prohibiting use of the specific application in question - not your entire internal stack.
[0] Practical example: that one time Atari hired a subcontractor to republish old Humongous Entertainment games on Wii and wound up infringing the GPL on SCUMMVM. Atari actually considered GPL compliance, but then realized that this would violate their obligation from Nintendo not to disclose game source at all.
http://sev-notes.blogspot.com/2009/06/gpl-scummvm-and-violat...
What do you mean? AGPL means that you have to open source your server stack, which of course proprietary server-software-based companies don't want to do.
Read the GPL...