5 ms·

That's why I prefer the GPL and variants for personal projects that I don't intend to profit off monetarily. It's a conscious choice that I do want compensation

That's why I prefer the GPL and variants for personal projects that I don't intend to profit off monetarily. It's a conscious choice that I do want compensation, and I don't want to work for free"--but said compensation should be in code and not necessarily in money. 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.

deng 7y ago
> 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 change anything here.
- 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.
adrianN 7y ago
If I don't want my code to be used in a commercial setting I use AGPL. It's super-banned in every company for which I know the open source policies. It's also the most sensible open source license in today's SAAS world.
dmytroi 7y ago
Maybe. What we know factually at this point in time: osxfuse was BSD licensed, Google used it and haven't contributed back. osxfuse is popular project. 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.
- syshum 7y ago
  MIT/BSD is in a kill free software phase, where commercialization of SAAS and other services are king. 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"
  - fierarul 7y ago
    This trend means open source is working as it was designed to.
pmjordan 7y ago
In addition to the sensible question of whether Google even would need to link against any GPL code raised by other commenters, there's also the question of whether the GPL would even make any sense for a kext, considering the kext needs to include Apple's header files (largely APSL-licensed) and link against macOS's kernel. (binary-only proprietary fork of the open source xnu source dump) (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.)

deng 7y ago

> 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 change anything here.

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.

adrianN 7y ago

If I don't want my code to be used in a commercial setting I use AGPL. It's super-banned in every company for which I know the open source policies. It's also the most sensible open source license in today's SAAS world.

dmytroi 7y ago

Maybe. What we know factually at this point in time: osxfuse was BSD licensed, Google used it and haven't contributed back. osxfuse is popular project. 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.

syshum 7y ago
MIT/BSD is in a kill free software phase, where commercialization of SAAS and other services are king. 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"
- fierarul 7y ago
  This trend means open source is working as it was designed to.

pmjordan 7y ago

In addition to the sensible question of whether Google even would need to link against any GPL code raised by other commenters, there's also the question of whether the GPL would even make any sense for a kext, considering the kext needs to include Apple's header files (largely APSL-licensed) and link against macOS's kernel. (binary-only proprietary fork of the open source xnu source dump) (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.)