4 ms·

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/fus

by 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.

by fathyb 3y ago

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.