FUSE for macOS (or, the kernel extension formerly known as osxfuse) is a projectdating back to 2011. It in turn is based on even older projects, such asMacFUSE, the Linux FUSE module, and even some code open sourced by Apple.
Oct 03, 2012 Uninstall FUSE for macOS manually. It is likely that you normally uninstall applications by dragging and dropping their icons to the Trash. In the case with the FUSE software program, you will not find its icon in the Applications folder, as FUSE is a type of extension. FUSE for macOS allows you to extend macOS's native file handling capabilities via third-party file systems but is no longer being maintained. I am using it myself to access my vm and mount the remote folders.
Until 2017, the project was open source, released under an amalgamation of thefairly permissive licenses of its various ancestors. But its maintainer,Benjamin Fleischer, decided to change that.While several releases have been published since then, only the binary blobs areprovided, leaving Fleischer as the only person with access to the completesource. For some previous discussion, checkhere,here,and here.
Some choice moments for those without the energy for programmer drama:
The osxfuse-3.9.0 tag shows an empty directory:https://github.com/osxfuse/osxfuse/tree/osxfuse-3.9.0
Checking out with git also produces an empty directory.The archives from there releases page are also empty, i.e.https://github.com/osxfuse/osxfuse/archive/osxfuse-3.9.0.zip
That’s on purpose. If you are using FUSE for macOS for a commercial softwareproject, feel free to contact me via email. You can find my email on my GitHubpage.
– @bfleischer
Have you ever written a single line of kernel code or debugged a massivelyparallel file system? Trust me, that’s a big deal.
– @bfleischer
This is simply too much work for one person in addition to a full-time job
Then drop it and let someone else maintain it.
– @pmetzger
That’s right, we’ve got ourselves a new season of The Real Housewives ofGitHub! That being said, this actually is a pretty serious issue, and@pmetzger, as a maintainer forMacPorts, has every right to be concerned.
You may also notice that I’ve only linked to random GitHub issues and mailinglist posts. That’s because this licensing change hasn’t been noted in theREADME orLICENSE files ofthe repo–that is, the most obvious (i.e. only) places that people check forthese sorts of things.
We’ll get into why, and how, this happened. But first, some background.
FUSE stands for Filesystem in Userspace, and the name pretty much tellsthe whole story. It’s a Linux kernel module that allows developers to implementa filesystem outside of the kernel, just like a normal application. This vastlysimplifies the development process, since you have access to all of the normallibraries and utilities you use in desktop development. It was mainlined wayback in 2005, and even then it wasn’t a new concept1.
Some notable FUSEs are Google Drive’s File Stream2, sshfs, Keybase’sKBFS, and ntfs-3g. The point is, this is a piece of technology that has beenused and abused endlessly, and that a ton of projects depend on.
As I mentioned earlier, since shortly after FUSE was created, people havewanted their filesystems to run on other operating systems. Windows, bizarrelyenough, seems to get far more love here, with Dokan, Dokany, and WinFsp fillingthe void.
Support for macOS, however, has been… limited, despite the fact that it andLinux have far more similar sets of file operations thanks to POSIX. MacFUSEwas started at Google in 2007 and, from what I can tell, was abandoned sometimearound 2009. osxfuse was then forked from it around 2011, and has been the onlysolution for running your FUSE on macOS since then.
osxfuse is, by necessity, a kernel module (or “kext” in Apple land). Using theBSD VFS interface, it presents itself as a traditional filesystem driver, andthen forwards filesystem operations across the kernel boundary to the FUSE. Atthis high level, it operates very similarly to FUSE on Linux, though obviouslythere are some differences at the lower levels. Since it’s a kext, shipping itto users requires some special provisions.
Now this may come as a shock to some of you, but Apple really doesn’t seem tolike it when third party developers change just about anything about their UX.For instance, they only added an API for adding badge icons to Finder in2014–and that was only because Dropbox just kept reverse engineering itanyway.
Deploying a kext requires it be signed using a special Kernel Extension SigningCertificate, which can only be acquired from Apple. Getting one of these certsrequires going through a fairly rigorous application process. And of course, atthe end of it all, you can be denied with no real recourse. Basically, yourproject lives and dies at the will of Apple–a markedly different approach fromwhat you’re used to if you’re used to the Linux and Windows approaches tothird-party kernel modules.
Now here’s the kicker: Benjamin Fleischer has one of these certificates forosxfuse. In fact, if you google his name, the vast majority of the results areconfused users asking why they’re being prompted about installing software byol’ Benny. What can I say, the man’s a celebrity.
So to quickly summarize:
- osxfuse is used by tons of companies,
- and essentially none of them push fixes upstream.
- Fleischer has been the sole maintainer for years.
- He also hasn’t been paid a penny for this work.
- He also holds a magical, aluminum unibody certificate that prevents mostpeople from forking his module.
- The current codebase is permissively licensed, so he can do with it what hewill.
It doesn’t exactly take a rocket surgeon to see where this is going.
Apple has apparently made some pretty significant changes to kernel modules inthe upcoming macOS Catalina. And according to our subject matter expert,they’re pretty gnarly tosupport. Fortunately, osxfuse 3.10 has support for Catalina!
But there’s a catch. If you go to download thisrelease,you’ll notice a bit of text in the release notes:
The license has changed. Starting with this release, redistributions bundledwith commercial software are not allowed without specific prior writtenpermission. Please contact Benjamin Fleischer.
The last public source code release was in 2017. Now, two years later, just afew short months before the Fucking Catalina ReleaseMixer, Fleischer could finallyget his.
- Apple does Apple things and heavily restricts third-party developers.
- Fleischer, having dealt with malarkey like this for close to a decade,realizes he doesn’t get paid enough for this shit.
- He makes the repo closed source in 2017, but doesn’t mention this to anyone.
- In 2019, after making a bunch of critical changes to the code, he quietlyannounces that the licensing terms of the project are now different.
- At this stage in the proceedings, companies’ choices are to pay up or telltheir users that they can’t use the hot new version of macOS.
As far as monetization strategies go, love it or hate it, you’ve got to givethe guy props.
Uh… probably? As I mentioned, most of the code is under BSD-style licenses.The command line utility to actually mount the damn thing is under the ApplePublic Source License, which has a “soft copyleft.” But in theory, if nofurther changes are made to this part of the code, it already meets therequirements for source code distribution.
Now I’m not a lawyer (yada yada this shouldn’t be considered legal advice), butit seems like all of this is perfectly above board.
Many open source projects take the approach of dual licensing with the GPL.This seems to hit the requirements pretty closely. Noncommercial, open sourcesoftware can use the module for free. And companies or individuals who want todistribute the software in a proprietary project have to pay up. As an examplein the same space, this is the strategy used by WinFsp.
It’s possible that things get weird given Apple’s code signing requirements, soI’m not 100% sure if this strategy would work–that’s more an issue for theFSF’s lawyers than some random programmer on the internet. But the point is,there are probably other options than closing the source.
Well… nothing, really. Mr. Fleischer has come to a determination that keepingthe project open source is not a situation that benefits him. And that’sunfortunate, but at a certain point I really can’t fault him.
The software which he has maintained for the past eight or so odd years hasbeen of enormous benefit to the software community as a whole. Instead of justbeing a Linux-only thing, FUSE became a de facto standard for quicklyspinning up a filesystem that does cool and useful things for users. This wasin part due to his work, as well as the work of many others over the course ofyears.
While some of this may have come off as harsh, it’s really not Fleischer withwhom we should take issue. He wouldn’t be the first maintainer to have gripeswith the ways in which his labor is taken advantage of; nor is he likely to bethe last. Mongo created the SSPL due to similar issues, and Redis Labs added aclause to its license forbidding companies from selling (parts of) itssoftware. Now while osxfuse is in a slightly different domain than thesedatastores, the root cause is the same: companies often reap far more from FOSSthan they sow upstream.
All that aside: it would be super cool for osxfuse to be open sourced again,but I don’t know if I can see that happening in the near future.
What Is Fuse For Macos Operating System
The free and open source software movements have done amazing things for theworld, and while I respect the decisions made in this case, I certainly hopethis doesn’t become the new normal. In the meantime, consider sending a couplebucks to the maintainer of your favorite project. And maybe use a copyleftlicense next time you release some code, so that when some random company wantsto use it, you can finesse a cut of the action.
What Is Fuse For Macos
While in isolation this might seem like a minor issue, if looked at as asymptom of a deeper problem… Trust me, it’s a big deal.
Footnotes
What Is Fuse For Macos 11
FUSE supposedly took its inspiration from the HURD concept of translators. I found this interesting mostly as a historical oddity–the HURD was actually useful for something! ↩
Technically speaking, GDrive File Stream depends on Google’s own fork of osxfuse. But their fork was (for a while, anyway) a bit too close to the original source, and caused conflicts with other osxfuse-based filesystems. Whoopsie. ↩