Hacker News Reader

Comment by mathiasgredal | Hacker News Reader

What prevents Apple from just integrating MacFUSE(or a reimplementation) into the their kernel, and then shipping it with the next release?

View on HN

They already have something like this, it's just not a public API and only used for their own FAT and NTFS implementations: https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...

Isn’t Fuse itself LGPL? Thats perhaps one reason since copyleft licenses aren’t favourable from their view.

I would really love any equivalent API though as dealing with Perforce is a pain in the butt sometimes, and what Microsoft have done with the Prrforce Virtual File system is amazing.

Macfuse itself has been closed source for a long time. Whether their EULA is compatible with the LGPL though, I don’t know. (Also, the old question: are APIs copyrightable?)

But do they bundle libfuse as a dylib? If they do, they’re probably in the right.

And API copyright aside, how would one prove it’s only API compatible and not using the implementation as well without also open sourcing their implementation?

It would almost be better to be similar but not the same. Then everyone else can just do subtle ifdef changes to their fuse code.

I'd be shocked if there was any technical reason they couldn't; if they haven't, they either don't care or actively don't want to for some reason. (But yes, I think they could and a lot of people would be very happy if they did)

If they ever do this, it’ll probably take the form of a proprietary userspace FS interface that will only work through Finder and will require the binary to be downloaded from the Mac App Store or otherwise signed by Apple. Every dev that wants to use it will have to pay Apple for the privilege.

But maybe I’m just being cynical.

Basically doesn't fit their roadmap.

Reply on news.ycombinator.com