Hacker News Reader

Comment by PlutoIsAPlanet | Hacker News Reader

Why is there a GitHub and no source code?

Does not answer your question directly, but related: 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

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.

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)

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

Unprivileged FUSE has been a thing for a while now: https://zameermanji.com/blog/2022/8/5/using-fuse-without-roo...

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.

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.

They actually tried with crowdfunding, but it didn't go well. Mostly because German laws and other things.

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

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

Reply on news.ycombinator.com