As I mentioned in another comment, permissive licenses (MIT, Apache, BSD) are generally seen as making collaboration, especially among commercial entities easier. There are fewer gotchas to merging products and otherwise pulling in code from different places. As a matter of policy, companies are generally more comfortable making use of permissively licensed code in their own software, even if it's intended for internal use.

So you're right that the GPL provides some safeguards about code being reworked into a proprietary product and kept closed. But a lot of the industry has come to see that the flexibility associated with more permissive licenses can outweigh that. (And there's been a general shift towards more permissive licensing. Most everything in the cloud-native open source space is permissively licensed. I believe the CNCF even requires this for projects under its umbrella.)

Sony contributions to FreeBSD shows how well it works, or the various compiler vendors thar now have clang forks, yet clang is now 3rd place in ISO C++ support.

I'm not sure what position your comment is taking. Are you claiming that compiler vendors are forking clang to keep better ISO C++ support proprietary?

Do you also believe Clang would have been in a better shape without the collaboration of all major compiler vendors?

I am claming that some compiler vendors leech from clang and hardly contribute to upstream, mostly they only contribute to LLVM and let others like Apple and Google do the needeful for ISO C++ compliancy.

Now that Apple is focused on Swift, and Google key devs went to play with Carbon, the amount of contributions to ISO C++ compliance has decresead and clang has an honourable 3rd place, between VC++, GCC and clang.

On the other hand, the world of C++ compilers is much bigger than only three compilers, so there are plenty more beyond the 3rd place.