It's why contributing to a BSD-licensed project as a hobby can feel a bit icky, and doing the same on a GPL-licensed project doesn't.
(I've licensed my own FOSS kext code as LGPL - either way, the copyleft aspect wouldn't affect any userland code using the kext as it'd be running in a different process. And AGPL doesn't change anything in this context either as far as I'm aware as its additional provisions are only relevant for code running on systems not under the user's control, and again if you're not linking against it, your code isn't a derived work.)
If it was GPL licensed, do you think Google would bother to use it? Or would they write their own instead? Would we even know about osxfuse then?
MIT/BSD is amazing on bootstrap phase, when getting code used and building user base is top priority. Monetization always comes later. Using GPL from the start might just turn your first users away and you might never manage to get critical mass of users to be able to monetize product at all.
In this particular case we don't know if there were any other previous attempts at financing it, like have maintainer contacted Google to provide consulting services? Or provide enterprise support to other parties? etc.
MIT/BSD is turning open source software, in to open source dev tools and libraries, no longer is should the end user software be free and open, no just the tools, frameworks, languages, and libraries used to create the end user software
I would not call this trend "amazing"
This is a pretty common misunderstanding. Google is using oxfuse internally and does not distribute it, so the GPL would not change anything here.
As the FAQ entry says this is a legal question "which ultimately judges will decide" and as far as I know that hasn't happend yet. Which is probably one reason many don't want to do it and err on the safe side and choose another project with non-viral license.
Though as gdrive does have locally installed components, if those used code covered by standard GPL they at least would be covered even if the server-side components were considered separate enough that they would not.
GPL clauses would only affect Google code upon linking. It's often possible to use fuse style software without linking - they could use it via the command-line and mount whatever they need at startup or even dynamically.
Does osxfuse have a command line tool? Most fuse style software does. If it doesn't, Google could have written a command-line client and open sourced just that.
This doesn't matter. If you distribute the isolated program you need to provide the sources anyway. Having to license other Google code as GPL is not the issue. It's making it required to provide back the changes you've made to fuse itself.
There may be some GPL proponents that really want it to "virally" infect other code. But what atq2119 was describing is just wanting to make sure you at least get back the changes to your own code. That's also why I think the trend towards BSD/MIT in open-source is dangerous. GPL/LGPL/AGPL should be perfectly fine for corporations when used appropriately. They are almost always just ways to make sure the best version of your project doesn't end up closed-source. I can't recall cases of those licenses being used to force other code to be open-sourced but maybe they exist.
I personally wouldn't mind this kind of internal use for the kinds of projects I'm involved in. For the kinds of software that is more likely to play a substantial role in customer-facing services, some people would feel differently. That happens to not be my cup of tea, but in any case there's the AGPL, as another commentor points out. And for yet other situations, there's LGPL.