Opened 7 weeks ago
Last modified 7 weeks ago
#70948 assigned defect
macFUSE is closed source, we should not package it
Reported by: | neverpanic (Clemens Lang) | Owned by: | mohd-akram (Mohamed Akram) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ra1nb0w | |
Port: | macfuse |
Description
macFUSE is binary-only non-commercial freeware starting with the 4.x versions. MacPorts should not package it, it exposes both us and our users to legal risks.
For example, any MacPorts user in a company that installs the macfuse port potentially violates clause 4 of the macFUSE license:
4. Redistributions in binary form, bundled with commercial software, are not allowed without specific prior written permission. This includes the automated download or installation or both of the binary form in the context of commercial software.
MacPorts definitely fulfills the "automated download or installation or both of the binary form" part of this. "in the context of commercial software" is not well defined, and might well be understood by a court or lawyer as "in the context of a company that develops software".
I realize this will break many ports that currently depend on macFUSE, but I don't see good alternatives. We still have the osxfuse port that packages the old 3.x version that seems to be open source.
Change History (3)
comment:1 Changed 7 weeks ago by neverpanic (Clemens Lang)
Cc: | ra1nb0w added |
---|---|
Owner: | set to mohd-akram |
Status: | new → assigned |
comment:2 Changed 7 weeks ago by mohd-akram (Mohamed Akram)
comment:3 Changed 7 weeks ago by markemer (Mark Anderson)
With the upcoming FSKit I'm determined to get a GPL/AGPL macFUSE replacement going. The downside here is that it will only work for 15 and maybe 14. I know I'm not the only one either - I assume a bunch of people are going to band together to do it.
We also went through this a few years ago when it happened. I don't really love what the guy did, and he @pmetzger got into a bit of a back and forth on github, but for now we're sticking with it.
I don't love it. Homebrew removed it for a similar reason - but I understand we don't want to break a bunch of ports people need.
Practically speaking, I don't think the license is an issue since the developer has stated clearly that this clause targets companies that ship commercial software that uses macFUSE without contributing back. There have also been discussions between MacPorts devs and the macFUSE developer and he's never said that we can't have it in MacPorts, rather the opposite. We can check this again with him if necessary. That said, even though I added this port, I did so with a bad taste in my mouth, but it was necessary because all the fuse ports were broken without it. Nowadays, there's a new problem - more and more software is using libfuse3 which is not supported by macFUSE. Adding to that, the most popular FUSE project, sshfs, is no longer maintained. At the same time, Apple is gradually phasing out kernel extensions in macOS due to their many issues. So the FUSE situation is looking dim on macOS from all sides, and the project seems less essential now.
If we choose to remove macFUSE, there might be a way to keep the ports working. We can add a libfuse2 port which uses the macOS-specific version - which is still open-source - on Darwin, and add a note telling users that installation of the kernel extension is required, which they can do themselves from the macFUSE website. Note that even when it was open-source, we still used the binary kernel extensions because they needed to be signed by a kernel developer.