FUSE for macOS is no longer open source

Likely the best outcome for the project barring company sponsorship that pays him to continue working on it as OSS.<p>He&#x27;s been the sole maintainer on the project since 2012 [1] and has never been compensated for it, he says it will always be free to end users but wants companies that are financially benefiting from it to help sponsor continued development [2]:<p>&gt; I will never ask end users for financial support. FUSE will always be free. However, what I&#x27;m asking for is for companies, that are selling FUSE-based products or rebrand FUSE and bundle it with their apps, to re-invest some of the profits in the continued development of FUSE on macOS, if they can afford it. I don&#x27;t think that is unreasonable.<p>So he&#x27;s just exercising the same BSD rights that all the other companies who have been taking and commercializing his work and not contributing back any fixes or funding for continued development.<p>Given that the alternative was to abandon the project [3], the only way it was going to see continued development as an OSS project was is if others took over maintenance&#x2F;development of it, which anyone is free to do by creating and maintaining a fork.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;osxfuse&#x2F;osxfuse&#x2F;graphs&#x2F;contributors" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;osxfuse&#x2F;osxfuse&#x2F;graphs&#x2F;contributors</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;osxfuse&#x2F;osxfuse&#x2F;issues&#x2F;590#issuecomment-508021742" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;osxfuse&#x2F;osxfuse&#x2F;issues&#x2F;590#issuecomment-5...</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;osxfuse&#x2F;osxfuse&#x2F;issues&#x2F;590#issuecomment-501809602" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;osxfuse&#x2F;osxfuse&#x2F;issues&#x2F;590#issuecomment-5...</a>

I agree that any aggressive towards the maintainer is unwarranted, even if I personally disagree with his move. In particular this comment quoted in TFA amused me:<p>&gt;Then drop it and let someone else maintain it.<p>I want to reply to this person: then fork the last open source version and maintain that. That&#x27;s the whole point really. Besides he apparently made the change two years ago and people only start noticing now, it&#x27;s pretty clear that there&#x27;s not a vibrant community of contributors ready to take the project over.<p>It&#x27;s not entirely fair in this case because of the certificate needed to sign the kernel module but if it&#x27;s really that difficult to get a certificate from Apple as an open source project that seems more like a problem with Apple than with osxfuse&#x27;s maintainer. Besides what can he reasonably do? Just give the certificate to whoever asks for it? That&#x27;s going to get it revoked by Apple in approximately 4 femtoseconds.<p>Companies benefiting from the work of opensource projects and not giving anything back is genuinely a big problem IMO. It&#x27;s not illegal of course, but it is unethical in my opinion. Look at the state of OpenSSL, one of the most (if not <i>the</i> most) popular crypto library out there, who has to beg for scraps in order to fund the project. And when there&#x27;s a critical vulnerability like heartbleed, who gets mocked online? The poor guy or gal who authored the commit, not the countless multi-billion dollar corporations who deployed their code for free without paying for a thorough audit or contributing anything back.

That was a very good write-up. Quite fair, and Kool-Aid-free.<p>It is a pretty good synopsis of the issues faced by open-source developers, these days.<p>Much like The September That Never Ended was probably the best thing that ever happened to the Internet, but was really tough on the folks already there, the adoption of open-source systems by commercial entities is making open-source &quot;sexy.&quot;<p>Open-source developers (of which I&#x27;m one) need to make extra efforts to document and &quot;decorate&quot; their projects, and often dream of &quot;going viral.&quot;<p>However, like so many folks have found on YouTube, fame != money.<p>In fact, once your project starts getting all that lovely adoption and enthusiasm, it will also start getting demanding, pithy, threatening and abusive contacts from users.<p>I strongly suspect that a lot of OS developers have walked away from promising projects because of this crap. I&#x27;m a stubborn, cantankerous bastard, so I haven&#x27;t; but I also have the &quot;advantage&quot; of not having any projects that have gone massively viral. It&#x27;s been a drip that I can use a saucepan to catch; not a deluge.<p>This smells like a business opportunity. Maybe set up a service for OS developers that will field all the abuse for them, and make it real cheap.

It is buried in the footnotes of the post, but the ultimate reason behind going closed source is that Google built their enterprise GDrive syncing client for mac off a fork of osxfuse. The original author of osxfuse feels entitled to some compensation for that and is doing his damnedest to make it happen.

Good for him.<p>I hope we see more of this in the future: developers realising that the work they do has value and that they’re not required to spend their lives giving it away for free. So they take control of their work product and start capturing some of that value for themselves.<p>It’s a shame that the article is written in this tone, as it mirrors the dominant sentiment among open source folks. There is still a lot of entitlement to be seen, even here in the comments from people who are likely to end up in the same boat as the software author referenced in the article.<p>I think it’ll take a while to get there.

The heart of the matter is that a fairly small number of people on a proprietary UNIX are mad that they have to pay money to continue to be free riders on the Free Software movement.<p>Mr Fleischer has done a huge amount of unpaid work so a narrow segment of wealthy software workers can avoid the choice between paying for proprietary software and supporting Free Software, <i>after spending thousands of dollars on a MacOS system</i><p>No world has ever produced a violin small enough to play an elegy for those “victims.”<p>If you wanted a Free Software FUSE, maybe a Linux desktop would have been a better choice?

I find this to be yet another example of why the GPL (in general) was created, and why licenses like or similar to the BSD license are flawed.<p>The way I see the GPL is that by modifying and publicly releasing the modified version of the binary, the payment for being able to do that is paid, at a minimum, in the code that should be released to accompany those changes.<p>You want to use my code, and not pay me for it with money? Then pay me (or pay it forward) with the code instead.<p>The BSD license and other similar licenses, while seemingly more free - really aren&#x27;t. They allow for someone or some company to just come in, take the code, then profit off of it in a closed-source manner - provided they give some acknowledgement somewhere that it came from the original BSD based project or whatnot.<p>Now - granted - in neither case would the programmer get paid money - but in the case of the GPL, at the very least the changes, fixes, updates, whatever - get &quot;paid for&quot; in code. It won&#x27;t put food on the table, but it is the least that someone could do, imho, by benefitting from the rest of the codebase.<p>I note that the above is a very simplified understanding of the GPL, BSD, etc - and of this issue in general. But I still think the basic idea stands; that at its core, the GPL is about &quot;paying for&quot; code with code, so that code nor changes to it will ever &quot;go missing&quot; or become &quot;locked up&quot; into some proprietary version of the code, and ultimately benefiting users less (whether they know or understand it or not).

I&#x27;m fortunate enough to have been paid to do open source code for the last ~10 years or so. I am thus a huge open source &amp; free source advocate, and I am completely biased for it.<p>I think everything done here seems legal, because BSD licensing pretty much allows for this (I am not a lawyer though, and I haven&#x27;t examined how things were with third-party contributions for example).<p>Morally, the only fault I can say on the maintainer&#x27;s behavior is a lack of transparency. This kind of decisive move ideally should be accompanied by an equally decisive communication effort. Trying to do this &quot;quietly&quot; isn&#x27;t an option when a big number of users and&#x2F;or big players are involved (as it seems Google is involved to some extent).

I think this is fairly overblown, there are a fair number of FUSE for macOS forks out there with signing certificates.<p>I have kext signing certificate for ExpanDrive, Google has one for Google Filestream, I suspect many others have one as well. Rightfully, Apple doesn&#x27;t hand them out as easily as they do with regular developer certificates, but if you want one and do a reasonable job representing that you&#x27;re not going to panic end-user systems, you can get one too.<p>FUSE for macOS remains open source, fork it if you want. Benjamin merely decided not to work on it for free anymore and essentially providing bug fixes etc for those who pay for it.<p>Lastly - FUSE of macOS is not going to be around in the current form much longer. Apple has made it abundantly clear that Kernel Extensions are on the way out, and that macOS 10.15 will be the last release to fully support kexts without compromises. Check this slide from WWDC<p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;a&#x2F;EAzT6Ch" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;a&#x2F;EAzT6Ch</a>

I am afraid there&#x27;s nothing people can do about this issue: according to <a href="https:&#x2F;&#x2F;github.com&#x2F;osxfuse&#x2F;osxfuse&#x2F;blob&#x2F;master&#x2F;LICENSE.txt" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;osxfuse&#x2F;osxfuse&#x2F;blob&#x2F;master&#x2F;LICENSE.txt</a> the project is BSD licensed and AFAIK closing the sources of a BSD-licensed project (&quot;re-licensing&quot;) is allowed.<p>Yep, he&#x27;s allowed to do this and people basically have to suck it up.<p>This couldn&#x27;t have happened if the code was GPL-licensed.<p>This might be a good occasion take a moment to think about all the BSD-licensed software you&#x27;re currently using, and imagine it disappearing just like this piece of software. Then go back to your repository and re-license as much as you can as GPLv3.

this quite reminds of the openssl saga, but on a smaller scale, with single developer more or less responsible for world&#x27;s encryption for decade.<p>it&#x27;s a pity, it&#x27;s a shame that companies who use FOSS benefit, but do not understand (or do, but ignore) the idea of FOSS, which is to give back to community. this also includes other FOSS companies, etc as everyone uses openssl, zlib and sqlite.<p>to base a project on FOSS requires that you contribute back. or pay back if you can. and when your business makes 1000$ then 1$ out of every 1000$ for the FOSS guy that made it possible is money worth spending, isn&#x27;t it?<p>if it&#x27;s true that VeraCrypt, the G company and others based work on this developer&#x27;s efforts and forgot, for decade, to give back anything, well - it&#x27;s well deserved to leave them staring at the blank repo. well deserved indeed, as they had plenty of time and resource to compensate the author while reaping benefits off his work. well done to choose the BSD license in this case.<p>all other companies building big-software based on hundreds opensource projects should rethink their strategies.<p>there is no free lunch, someone pays for it. and its a shame, when this someone is left alone to pay for his lunch, while hundreds benefit from it. maybe there should be the FOSS Church and at least make these people revered as saints.

&gt; He can do that?<p>&gt; 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.<p>Just a note here, my understanding of the legal status of software licenses is that they don’t supersede your own ownership of copyright.<p>As the nearly-sole contributor, the author can violate his own license for the code he created. Even if the whole thing was GPLv3, I think he could simply remove anyone else’s contributed commits and take the rest as proprietary code. It doesn’t sound like much work was done by other contributors on this project anyway.<p>Now, if he’s closed sourcing and using&#x2F;changing someone else’s contributions that were licensed to the public in a copyleft license, that’s a different story.<p>(IANAL)

I think the issue is lack of user interest.<p>I’ve tried using FUSE for the Mac many times throughout the years, mostly for curl_fs and ssh_fs.<p>Believe it or not, I’m not happy with the FTP alternatives on the Mac. Transmit is beautiful but buggy and lacks features such as general purpose SOCKS proxy. FileZilla is ugly as sin. Cyberduck is neither pretty nor feature packed.<p>Although it got better recently, FUSE for the Mac has always been incredibly slow and buggy, no matter how many command line flags I added.<p>So between native NTFS read, ExFat read&#x2F;write and decent for most people remote disk apps, there are probably very few users who care about FUSE on the Mac.

I don&#x27;t think going closed source is the solution to fight against others leeching off your work. The solution is more stringent GPL-style licenses that are more protective of the open-source community.<p>Overall BSD-style licenses are not protective enough for the open source community, in fact they open it up to predatory behavior by selfish entities with large commercial interests and which don&#x27;t care about giving back to the community. BSD gives the most freedom to the developers (that includes companies making private use of the code), while GPL gives the most freedom to the user of the software (who can then chose to become a developer). BSD code is often higher in popularity but there&#x27;s a reason for that. I think GPL is the better choice overall.

We need something like carbon credits for open source. As in, if you contribute to open source you earn credits. If you make lots of use of open source but don&#x27;t contribute back you need to buy open source credits.<p>How we would value open source is a tricky question. Would AWS owe a gazillion credits for all the hours of linux and apache they&#x27;ve burnt? Probably doesn&#x27;t make sense. Maybe a logarithmic scale. But the real value of open source isn&#x27;t dollars but people time (which, if you&#x27;ve had a pile of dollars and tried to spend it to employ people to do something, you will know is not the same thing). How many people hours is there in producing something like FUSE, and how many hours saved by end users? Maybe that determines the utility.<p>Until we have a value and a <i>currency</i> for open source there won&#x27;t be an open source <i>economy</i>.

IIRC, FUSE is also required for VeraCrypt to function. So now the source code of this library (module? whatever) that&#x27;s used by popular encryption software won&#x27;t be available for public scrutiny. Amazing.<p>The author is, of course, completely within their rights to stop publishing the source code of their software, but this is a real pity.<p>The way to go would be for members of the FOSS community to fork the last version of the source code that was published and continue development, but I don&#x27;t know who (if anyone) will step up and take responsibility.<p>This also leads to fragmentation, were now you have two popular forks of the same thing which may not be compatible with each other. Sigh.

So, so many of the use-cases for osxfuse&#x2F;macfuse involve people using sshfs to mount SFTP-capable logins into the Finder.<p><i>All of this</i> could be very simply avoided if Apple just made SFTP a supported protocol under &quot;Connect to Server&quot;.<p>I&#x27;ve asked&#x2F;wished&#x2F;pleaded for this since 2005.<p>It&#x27;s one of those Apple deficiencies that makes you wonder <i>just how do people at apple get work done</i> if they don&#x27;t have this feature ? It&#x27;s like the multi-year failure of OSX to properly or sanely support 2+ monitor setups ... just what were all those apple employees doing during that time ?<p>How do they not need these things ?

Nitpick:<p><i>&gt; 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 </i><p><i>&gt; Deploying a kext requires it be signed using a special Kernel Extension Signing Certificate, which can only be acquired from Apple</i><p>this restriction has nothing to do with them not liking people doing stuff about their UX and everything to do about the fact that kernel extensions bypass all security boundaries between users and processes.<p>Kernel extensions are bloody dangerous and I&#x27;m happy with Apple putting additional scrutiny on them.

I&#x27;m surprised it doesn&#x27;t say anything about security concerns with depending on a single individual to develop a kernel module without any ability to audit the code.

Not relevant but it&#x27;s funny that the maintainer of osxfuse has the name Fleischer and is discussing on github with Metzger. Both are german words for &quot;butcher&quot;. (but also common surnames)

The article makes this out to be more complicated than it is. Apple makes it very difficult to use 3rd party kernel modules. That is the whole thing.<p>The open source thing is a complete red herring for everyone except the current maintainer who just happened to use some code that might be open source in a different context. The source for the module that could end up in the Apple kernel was never open to begin with. No one else could actually use the result of compiling the code. So the source was not ever open in a way that made any practical difference.<p>The only moral here is that it is sometimes possible to prevent the use of open source code in some contexts and that Apple sometimes does. We already knew that.

think of it this way - like all the other companies, he&#x27;s maintained his own private fork of the open source osxfuse code. his happens to work on catalina, and he&#x27;s telling those companies that if their forks do not, he&#x27;s willing to sell them access to his code.

Is there any copyright&#x2F;licence specialist here? I&#x27;ve come up with an idea of having a free open software library that randomly displays offensive[0] messages full screen that comes with a BSD type licence with a clause that forbids removing&#x2F;disabling that message. I assume that many developers or end-users[1] at home are perfectly fine with a messagebox popping up once a month with a &quot;f## off&quot; message, while any corporation planning to use that library will find it not acceptable to have their software display offensive content. And here comes a dual licensing, where there would be a possibility to buy a different licence that allows to disable that message. What I&#x27;m asking here is whether this would be possible to do so and enforce in a court or a legal dispute.<p>[0] or otherwise inacceptable in corporate environment<p>[1] I&#x27;m assuming that this would also be acceptable for the derivative projects: end-users might find that acceptable while businesses would not.<p>edit: wording of last sentence, formatting

If you&#x27;re an open-source maintainer and either don&#x27;t have a team, have a niche to small, are receiving zero compensation for the work, or some combination of those things, at this point in my life I believe it&#x27;s best to either use a strong copy left license like the (A&#x2F;L)GPL (only use LGPL for libraries, never anything else), or just stay closed source.<p>The problem with permissive licenses is that they do nothing for the people actually developing the software, and makes it extremely likely that others will profit off their back without ever pushing even a line of code upstream.<p>People will try to guilt you into changing licenses so they can use it in a commercial product, but seriously - if that person is going to profit off <i>your</i> code, you should be profiting too.

<i>&gt; Isn’t there a better way?</i><p>There is. Ditch Apple and use sane systems without some control obsessive entities constantly hovering over you and dictating you how to (or not to) use them.<p>Developers abandoning Apple should be the taste of their own medicine for them.

submitter and author of goofys here. As I see it there are 3 issues:<p>1. osxfuse is effectively closed source but the license is not changed<p>2. there&#x27;s no open source fuse on latest version of OS X<p>3. most importantly, having only one maintainer for osxfuse is clearly not sustainable<p>I don&#x27;t really use OS X so mostly have an interest in this because some of my users are on OS X.

&gt; I will never ask end users for financial support. FUSE will always be free. However, what I&#x27;m asking for is for companies, that are selling FUSE-based products or rebrand FUSE and bundle it with their apps, to re-invest some of the profits in the continued development of FUSE on macOS, if they can afford it. I don&#x27;t think that is unreasonable.<p>Sounds like he should have released it under GPL type of licensing.

I&#x27;m not sure if the signing process actually matters in this case? If the signing step is the limiting factor in maintaining a fork, he could have switched to the GPL and achieved the same result (commercial redistribution requiring a paid license) while maintaining the benefit of being open source.

I had a project planned for iOS[0] that would have been so much better if it could use FUSE, but looks like it can&#x27;t happen now.<p>If someone wants to try, having a generic link between FUSE and File Providers in iOS will be a great addition. You could make a generic application that interoperates various FUSE projects against the File Provider API in iOS, so you could mount all sort of crazy stuff in iOS Files application.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;captn3m0&#x2F;ideas&#x2F;blob&#x2F;master&#x2F;opds-ios-file-provider.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;captn3m0&#x2F;ideas&#x2F;blob&#x2F;master&#x2F;opds-ios-file-...</a>

If he made a software that is making companies using it millions, and he still doesn&#x27;t benefit a dime from his work and explicitly wants to, I think he has the right to go this way.

Well, We should respect contributors. It is upto contributor to release their code unless he is redistributing app with viral license like GPL.<p>Here neither big companies nor the sole maintainer is breaching any license clause.<p>If anyone want to get the project mainstream, just find and fork the last open-source code version available, fork it and contribute&#x2F;maintain&#x2F;re-license as needed use case. another options is to, hire&#x2F;contract the sole maintainer to develop needed feature of current version.

This is a very sucky situation to be in, and I&#x27;ve been on both sides of it.<p>I wrote KSCrash [1] a decade ago, and it&#x27;s become the de-facto standard for crash handling in the Apple ecosystem. I didn&#x27;t intend for this to happen; I just wanted crash handling MY way. But it&#x27;s my baby, and I need to support it (technically no, but yes I do), even though I get no financial benefit from it. For a year, I was paid by a private company to supercharge it, but that funding dried up, and as a result the Android port stalled because I took a new job to pay the bills, writing Java code.<p>Musashi [2] is a smaller example. It&#x27;s an emulator, so it doesn&#x27;t need nearly as much attention. All the same, a number of 68k based anthology releases for popular game systems used it and contributed neither fixes nor funds. I don&#x27;t mind so much with this one because, as I said, it&#x27;s pretty low maintenance.<p>Today, my latest itch is efficient and human-accessible data communications, and so I&#x27;m spearheading a new bidirectional, general-purpose, platform agnostic, encryption-capable, transport-agnostic RPC protocol [3], including all of the supporting technology it requires [4] [5] [6] [7] [8] [9]. If it takes off, it will save the entire planet a TON of time, energy, and cost, and I&#x27;ll probably not see any donations or thanks from those who benefit the most.<p>Please don&#x27;t take this as complaining. I&#x27;m still going to develop and support my babies, because I&#x27;m not doing this for the money; I&#x27;m doing it to better the state of computing systems (mostly for my own sanity). However, because I&#x27;m forced to find separate employment to support my family, it leaves me with FAR less time to focus on these technologies. My estimate would be that I&#x27;m running at 1&#x2F;4 my usual velocity when I require separate employment. For bigger projects that turns a 1 year project into 4 years.<p>However, from a company perspective I also understand. Giving donations is actually a big pain in the ass, especially if it&#x27;s to a foreign entity. Normal invoices are FAR easier, but then how do you structure it for free access + payment options without pissing people off? It&#x27;s a tricky situation...<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;KSCrash" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;KSCrash</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;Musashi" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;Musashi</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;streamux" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;streamux</a><p>[4] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;concise-encoding" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;concise-encoding</a><p>[5] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;compact-float" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;compact-float</a><p>[6] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;compact-time" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;compact-time</a><p>[7] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;varpad" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;varpad</a><p>[8] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;variable-bit-padding" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;variable-bit-padding</a><p>[9] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;vlq" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;vlq</a>

By the way if you are searching for some cross-platform FUSE-like alternative for a project I encourage you to try WebDAV if something else is your bottleneck.<p>It saved me some headaches from bundling an installer for macFUSE or Dokan&#x27;s blue screens in the past. There are server implementations and also FUSE wrappers on GitHub. It&#x27;s not perfect but worth a try. And it&#x27;s supported directly by many OS.

Good, but in this case, the osxfuse maintainer expects to be paid by Apply because they derived from his work ... what about original FUSE, of which osxfuse is spiritually derived? When is it ethically OK to profit from your derived work?

See also: <a href="https:&#x2F;&#x2F;tidelift.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tidelift.com&#x2F;</a><p>You pay them to support an open source product. Only a small number of things covered at present, but maybe better than doing it yourself.

Can someone explain to me why there are PRs that seem to be opened and merged by other people, but all of the commits show up as bfleischer? I don&#x27;t quite understand the git history of this project.

Reading the article I cant understand, how is it possible for other companies distribute patched version of FUSE module, if they don&#x27;t have certificate to sign it?

FUSE is a fantastic project that I’ve used since it’s inception.<p>I did notice commercial projects using the source, and if there’s only one dev, I agree he does deserve compensation.

Someone should fork it and apply to Apple as a new kext.

Any price tag known for commercial developers? Was interested in doing something with FUSE on Mac.

Let&#x27;s all wait for BSD license apologists to insist true freedom is the freedom to blackmail your users.<p>Props to the OS Xfuse maintainer, he does deserve a fat payout so begrudging him. Still, it paints the clear picture of how BSD is an inferior license when it comes to freedom for users.<p>Maybe this comment is too slashdot 2006 era, but still, licenses matter.

Go Benny!

This explains why there are banners in macOS that say &quot;x is supported by Catalina!&quot; where x is one of the companies using osxfuse.

His project, his rules. Period.

Finally. People need to understand that expecting someone to put their OWN free time into making something open source, and the ripping off the monetary gain AND expecting them to continue maintaining and adding features for free is pure entitlement.

&gt;&gt;So What now?<p>Easy Switch to Linux and enjoy freedom

This is why permissive licenses are bad news for users.

When a FOSS project closes itself off this way, the proper response is to treat it as abandoned and continue development from the last-good version with source available. In particular, MacPorts should <i>not</i> be distributing the binary-only versions. Total disengagement.

I read more than two thirds of this blog post before realizing the author doesn’t seem to agree with this guy he quoted:<p>&gt; Then drop it and let someone else maintain it.<p>To be clear, if maintenance of a popular open source project is too much for you then stop. Taking your marbles and going home is childish, if the authors third party analysis of the motives behind Fleischer‘s behavior is to be believed. The post says on one hand that he never financially benefited but then on the other hand that he’s justified in obscuring the source because maintenance is onerous.