FUSE for macOS (or, the kernel extension formerly known as osxfuse) is a project
dating back to 2011. It in turn is based on even older projects, such as
MacFUSE, the Linux FUSE module, and even some code open sourced by Apple.
Until 2017, the project was open source, released under an amalgamation of the
fairly 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 are
provided, leaving Fleischer as the only person with access to the complete
source. For some previous discussion, check
here,
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 software
project, feel free to contact me via email. You can find my email on my GitHub
page.
– @bfleischer
Have you ever written a single line of kernel code or debugged a massively
parallel 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 of
GitHub! That being said, this actually is a pretty serious issue, and
@pmetzger, as a maintainer for
MacPorts, has every right to be concerned.
You may also notice that I’ve only linked to random GitHub issues and mailing
list posts. That’s because this licensing change hasn’t been noted in the
README or
LICENSE files of
the repo–that is, the most obvious (i.e. only) places that people check for
these 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 tells
the whole story. It’s a Linux kernel module that allows developers to implement
a filesystem outside of the kernel, just like a normal application. This vastly
simplifies the development process, since you have access to all of the normal
libraries and utilities you use in desktop development. It was mainlined way
back in 2005, and even then it wasn’t a new concept1.
Some notable FUSEs are Google Drive’s File Stream2, sshfs, Keybase’s
KBFS, and ntfs-3g. The point is, this is a piece of technology that has been
used and abused endlessly, and that a ton of projects depend on.
As I mentioned earlier, since shortly after FUSE was created, people have
wanted their filesystems to run on other operating systems. Windows, bizarrely
enough, seems to get far more love here, with Dokan, Dokany, and WinFsp filling
the void.
Support for macOS, however, has been… limited, despite the fact that it and
Linux have far more similar sets of file operations thanks to POSIX. MacFUSE
was started at Google in 2007 and, from what I can tell, was abandoned sometime
around 2009. osxfuse was then forked from it around 2011, and has been the only
solution for running your FUSE on macOS since then.
osxfuse is, by necessity, a kernel module (or “kext” in Apple land). Using the
BSD VFS interface, it presents itself as a traditional filesystem driver, and
then forwards filesystem operations across the kernel boundary to the FUSE. At
this high level, it operates very similarly to FUSE on Linux, though obviously
there are some differences at the lower levels. Since it’s a kext, shipping it
to users requires some special provisions.
Now this may come as a shock to some of you, but Apple really doesn’t seem to
like 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 in
2014–and that was only because Dropbox just kept reverse engineering it
anyway.
Deploying a kext requires it be signed using a special Kernel Extension Signing
Certificate, which can only be acquired from Apple. Getting one of these certs
requires going through a fairly rigorous application process. And of course, at
the end of it all, you can be denied with no real recourse. Basically, your
project lives and dies at the will of Apple–a markedly different approach from
what you’re used to if you’re used to the Linux and Windows approaches to
third-party kernel modules.
Now here’s the kicker: Benjamin Fleischer has one of these certificates for
osxfuse. In fact, if you google his name, the vast majority of the results are
confused users asking why they’re being prompted about installing software by
ol’ 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 most
people from forking his module.
The current codebase is permissively licensed, so he can do with it what he
will.
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 in
the upcoming macOS Catalina. And according to our subject matter expert,
they’re pretty gnarly to
support. Fortunately, osxfuse 3.10 has support for Catalina!
But there’s a catch. If you go to download this
release,
you’ll notice a bit of text in the release notes:
The license has changed. Starting with this release, redistributions bundled
with commercial software are not allowed without specific prior written
permission. Please contact Benjamin Fleischer.
The last public source code release was in 2017. Now, two years later, just a
few short months before the Fucking Catalina Release
Mixer, Fleischer could finally
get 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 quietly
announces that the licensing terms of the project are now different.
At this stage in the proceedings, companies’ choices are to pay up or tell
their 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 give
the 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 Apple
Public Source License, which has a “soft copyleft.” But in theory, if no
further changes are made to this part of the code, it already meets the
requirements for source code distribution.
Now I’m not a lawyer (yada yada this shouldn’t be considered legal advice), but
it 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 source
software can use the module for free. And companies or individuals who want to
distribute the software in a proprietary project have to pay up. As an example
in the same space, this is the strategy used by WinFsp.
It’s possible that things get weird given Apple’s code signing requirements, so
I’m not 100% sure if this strategy would work–that’s more an issue for the
FSF’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 keeping
the project open source is not a situation that benefits him. And that’s
unfortunate, 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 has
been of enormous benefit to the software community as a whole. Instead of just
being a Linux-only thing, FUSE became a de facto standard for quickly
spinning up a filesystem that does cool and useful things for users. This was
in part due to his work, as well as the work of many others over the course of
years.
While some of this may have come off as harsh, it’s really not Fleischer with
whom we should take issue. He wouldn’t be the first maintainer to have gripes
with the ways in which his labor is taken advantage of; nor is he likely to be
the last. Mongo created the SSPL due to similar issues, and Redis Labs added a
clause to its license forbidding companies from selling (parts of) its
software. Now while osxfuse is in a slightly different domain than these
datastores, the root cause is the same: companies often reap far more from FOSS
than 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.
The free and open source software movements have done amazing things for the
world, and while I respect the decisions made in this case, I certainly hope
this doesn’t become the new normal. In the meantime, consider sending a couple
bucks to the maintainer of your favorite project. And maybe use a copyleft
license next time you release some code, so that when some random company wants
to use it, you can finesse a cut of the action.
While in isolation this might seem like a minor issue, if looked at as a
symptom of a deeper problem… Trust me, it’s a big deal.
