Interesting. We use about 8000 open source packages, and add roughly 90 a week right now.
"Perhaps you work with companies where adopting technology stacks is more of a top-down decision where legal counsel is always involved. In those situations, GPL doesn't pose a particular barrier because all open source software faces that same barrier. But some companies give more autonomy to their developers, and in those cases there's a difference in overhead when managing GPL compliance."
Actually, i work at a company (Google) where autonomy is given. People are free to use basically anything but AGPL. We simply tell them what will be required of them if they use it, and enforce that this happens.
The overhead of GPL compliance is not any more than the overhead of any other license compliance, for us, in practice.
You still have to do stuff for BSD and MIT anyway, so you need a process that knows what is going into shipping software.
The short version is that:
Overhead is kept low by doing it as part of the same check-in process as any other source code (IE you don't fill out some magical form and send it to lawyers), among other things.
Shipping time is simple verification that nothing changed (and the build system will verify it anyway).
My experience is that companies find GPL compliance overhead higher because they aren't doing the right thing for other licenses anyway. In particular, they never produce correct attribution for MIT/BSD/etc, so having to do "anything at all" is higher overhead.
This experience comes from reviewing a large number of companies for acquisition :)
