4 ms·

> That's why I prefer the GPL This is a pretty common misunderstanding. Google is using oxfuse internally and does not distribute it, so the GPL would not chan

• joking 7y ago
  are you sure? it's not using oxfuse on the google drive clients that the users download and install on their own machines?
  • jagged-chisel 7y ago
    Distributing it inside the client does indeed qualify as 'distribution' under the GPL and would require the client to then be licensed under the GPL.
    • tobias3 7y ago
      As far as I understand this would be a "mere aggregation" since the application and the kernel module communicate at arms length through the kernel syscall interface https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation . So they'd have to make the source of the kernel extension available (as the GPL requires) but it would not be viral to the application using the kernel extension. 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.
      • jagged-chisel 7y ago
        I agree. I was thinking along the lines of linking the code into the app, rather than an included kernel module.
• jacobush 7y ago
  Unless it was GPLv3 he liked.
  • dspillett 7y ago
    Or AGPL. 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.
• pvg 7y ago
  GDrive Enterprise is a publicly available product with a Mac client so the footnote doesn't seem to line up with what you're saying.
  • deng 7y ago
    I wasn't aware that osxfuse is distributed by Google. If that is the case then I am sorry for spreading false information and indeed, the GPL would apply.
    • yyyk 7y ago
      It's still not clear whether the GPL would apply in the way commenters here think it would. 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.
      • pedrocr 7y ago
        > 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. 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.
      • asdfasgasdgasdg 7y ago
• atq2119 7y ago
  You conveniently left out the "and variants" in your quote. 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.