4 ms·

Why is there a GitHub and no source code?

fathyb 3y ago
Does not answer your question directly, but related: https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment-1420347389 https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... > The project consists of two components: libfuse and fuse-t server. libfuse is LGPL licensed and can be downloaded from here: macos-fuse-t/libfuse [1]. You can modify and build it as you wish, the build instructions are provided in the README file. The fuse-t server on the other hand is a proprietary component, it's written in go and doesn't link to or includes anything GPL related, all respective copyright owners are mentioned in License.txt file [...] [1] https://github.com/macos-fuse-t/libfuse https://github.com/macos-fuse-t/libfuse
- kelnos 3y ago
  Weird that early in the issue comments the author claims they're going to release source for fuse-t, but then later in the comments changes course and says it's proprietary. Sounds like they originally wanted to release it as open source, but under a restrictive non-commercial license (which is fine, I guess), but then has gone back on that promise. I'm not gonna be one of those "proprietary software is immoral" people, but it just rubs me the wrong way to see someone take a concept/protocol that was originally developed in the open and released as open source (the Linux version of FUSE itself), and then build something proprietary.
  - PlutoIsAPlanet 3y ago
    Especially something like FUSE where it’s potentially the middle man of personal data. If there’s concern about other companies profiteering, release it under a license that prevents such and those companies can pay to license under something else. This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers)
    - flakes 3y ago
      > This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers) By viable do you mean secure? You can definitely use FUSE within containers, but you do have to cap-add SYS_ADMIN.
      - Conan_Kudo 3y ago
        Unprivileged FUSE has been a thing for a while now: https://zameermanji.com/blog/2022/8/5/using-fuse-without-root-on-linux/ https://zameermanji.com/blog/2022/8/5/using-fuse-without-roo...
  - deleted 3y ago
    [deleted]
- soraminazuki 3y ago
  I respect the author's choice to use a proprietary license, but I wish they'd been honest about it. I've been tracking that GitHub issue when FUSE-T came out. Initially, the author promised to open source. But then there was a long silence, after which the issue was closed as "completed" without any explanation. It's unfortunate because proprietary software requires more trust for users. The lack of communication demonstrated here is concerning.
deleted 3y ago
[deleted]
rgovostes 3y ago
There are two FUSE implementations for macOS and neither is open source, unfortunately. One reason: it’s a critical component of several profitable, commercial products, but the authors of then-open source FUSE implementations found that none of those companies were willing to financially support their work. Those authors also haven’t seemed interested in crowdfunding when it has been proposed.
- xaerise 3y ago
  They actually tried with crowdfunding, but it didn't go well. Mostly because German laws and other things.
- krackers 3y ago
  See https://www.theregister.com/2019/12/16/fuse_macos_closed_source/ https://www.theregister.com/2019/12/16/fuse_macos_closed_sou... for more info. I wonder why a dual-licensing approach was not pursued though, e.g. some viral license (AGPL?) for the open-source part. This could have the same benefit of getting companies to negotiate an explicit (paid) license agreement while still making source available.
blackpanda467 3y ago
From the author: right now fuse-t cannot be made open sourced because it won't play nice with existing contracts. You can try my other project which is open source and can be an alternative to fuse: https://github.com/macos-fuse-t/go-smb2 https://github.com/macos-fuse-t/go-smb2

Does not answer your question directly, but related: https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment-1420347389 https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... > The project consists of two components: libfuse and fuse-t server. libfuse is LGPL licensed and can be downloaded from here: macos-fuse-t/libfuse [1]. You can modify and build it as you wish, the build instructions are provided in the README file. The fuse-t server on the other hand is a proprietary component, it's written in go and doesn't link to or includes anything GPL related, all respective copyright owners are mentioned in License.txt file [...] [1] https://github.com/macos-fuse-t/libfuse https://github.com/macos-fuse-t/libfuse

kelnos 3y ago
Weird that early in the issue comments the author claims they're going to release source for fuse-t, but then later in the comments changes course and says it's proprietary. Sounds like they originally wanted to release it as open source, but under a restrictive non-commercial license (which is fine, I guess), but then has gone back on that promise. I'm not gonna be one of those "proprietary software is immoral" people, but it just rubs me the wrong way to see someone take a concept/protocol that was originally developed in the open and released as open source (the Linux version of FUSE itself), and then build something proprietary.
- PlutoIsAPlanet 3y ago
  Especially something like FUSE where it’s potentially the middle man of personal data. If there’s concern about other companies profiteering, release it under a license that prevents such and those companies can pay to license under something else. This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers)
  - flakes 3y ago
    > This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers) By viable do you mean secure? You can definitely use FUSE within containers, but you do have to cap-add SYS_ADMIN.
    - Conan_Kudo 3y ago
      Unprivileged FUSE has been a thing for a while now: https://zameermanji.com/blog/2022/8/5/using-fuse-without-root-on-linux/ https://zameermanji.com/blog/2022/8/5/using-fuse-without-roo...
- deleted 3y ago
  [deleted]
soraminazuki 3y ago
I respect the author's choice to use a proprietary license, but I wish they'd been honest about it. I've been tracking that GitHub issue when FUSE-T came out. Initially, the author promised to open source. But then there was a long silence, after which the issue was closed as "completed" without any explanation. It's unfortunate because proprietary software requires more trust for users. The lack of communication demonstrated here is concerning.

deleted 3y ago

[deleted]

rgovostes 3y ago

There are two FUSE implementations for macOS and neither is open source, unfortunately. One reason: it’s a critical component of several profitable, commercial products, but the authors of then-open source FUSE implementations found that none of those companies were willing to financially support their work. Those authors also haven’t seemed interested in crowdfunding when it has been proposed.

xaerise 3y ago
They actually tried with crowdfunding, but it didn't go well. Mostly because German laws and other things.
krackers 3y ago
See https://www.theregister.com/2019/12/16/fuse_macos_closed_source/ https://www.theregister.com/2019/12/16/fuse_macos_closed_sou... for more info. I wonder why a dual-licensing approach was not pursued though, e.g. some viral license (AGPL?) for the open-source part. This could have the same benefit of getting companies to negotiate an explicit (paid) license agreement while still making source available.

blackpanda467 3y ago

From the author: right now fuse-t cannot be made open sourced because it won't play nice with existing contracts. You can try my other project which is open source and can be an alternative to fuse: https://github.com/macos-fuse-t/go-smb2 https://github.com/macos-fuse-t/go-smb2