Likely the best outcome for the project barring company sponsorship that pays him to continue working on it as OSS.
He'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]:
> I will never ask end users for financial support. FUSE will always be free. However, what I'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't think that is unreasonable.
So he'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.
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/development of it, which anyone is free to do by creating and maintaining a fork.
> He's been the sole maintainer on the project since 2012 [1] and has never been compensated for it
I have to object to that. I work for a company which pays him to build branded versions of FUSE for macOS, and has been doing so for several years.
He does reliably ship us new builds, but it has sometimes been a little difficult to get him to respond to feature requests or even patches that we send him.
I don't believe that he is scaling much better with his commercial licensing than he was as a FLOSS maintainer.
As it is, we're fairly happy with his work to continue to support new versions of macOS, which is fairly hard to ship systems software on these days (the code signing and notarization requirements keep getting more and more onerous, system integrity protection keeps getting in the way of debugging, and so on), but it would be nice if we weren't limited to a single person working on the project.
I'd really rather he kept the project open source, and continued to provide custom builds for companies on a contract basis. Due to the difficulties of building and signing the kernel extension across all of the versions of macOS that it supports, just having the source available but keeping the binaries under a proprietary license would probably be sufficient to make it worth the while of most companies to license with him to provide custom builds like we do.
Sounds like a lot of additional work for him to provide custom builds? Maybe he wants to be paid for the core product development that provides most of the value?
No, the custom builds aren't much more work than the vanilla builds, it's getting the build environment set up in the first place that's a pain, since you have to build against a different SDK for each version of macOS you support; and the custom builds are what he sells to customers, since with a custom build it can be installed and updated independently of the free-as-in-beer version that is used for things like SSHFS and might be updated out from under you in a way that breaks your application. Updating with your application means that you can test each new version and fix any issues or report back to him before shipping it.
Well, in this specific case, I think the best outcome would be for Apple to merge the module in the MAC OSX kernel so it's there by default, FUSE is kind of a de-facto standard and is clearly a widely useful piece of code.
But, big picture, yes a lot of OSS projects have the same issue. Funding is clearly one aspect, but another aspect is also to work on having less "single person projects" (and I'm not talking about one time PRs but a genuine second core developer). I'm not sure how to encourage that however, maybe more commonly adding "HELP WANTED!" in the project README, maybe a button "I want to become a permanent contributor of <PROJECT>" button in Github, I don't know. If you are alone on a project, even if funded, chances are you will loss interest after a while, leaving the project with tons of possible improvements not realized, and a on/off maintenance, having more "N>1 core developers projects" would help mitigate that.
Adding someone into a solo project introduces social overhead. That's not necessarily a bad thing and can even be a very good thing (I much prefer making music with other people and seeing how our influences mix as opposed to making music solo). But there is a cost/risk there which I could certainly see some solo developers just not being interested in taking on.
On the other hand, since this is OSS, if an organization does need N>1 badly enough, then they can commit their own resources to it, forking if necessary.
I wouldn't mind if there was a "DONATE" button, I'd certainly donate 5$ or 10$. Under these circumstances even more since this driver is unique and several other drivers I use depend on it. (sshfs, perkeep, ext4fuse, ...) Probably these small but frequently used projects should also be supported by the FSF, at least in the *GPL case.
So this is an area of significant interest to me. I have researched this extensively, talked to a few dozen medium-to-large OSS maintainers, and have a project on the back burner about this. The only conclusion I've been able to draw is that literally every approach from OpenCollective to a PayPal link demonstrably does not work. Donations do not work.
You have to give people something of value, even if nominal value, to actually get corporate interest and to drive the kind of ROI that makes it viable to continue spending so much dang time on these projects. And a lot of people pfft at that and wave their hands about their right to other people's free time (or that an invisible hand will Make Things Work should those people choose to spend their free time in other ways, ignoring that that usually just means other people get to burn out instead). The only sustainable way to build open-source software is to get businesses to pay for it. And that's why we're where we are with these conversations: it's not the end-user free riders who matter, it's the commercial ones.
(I don't think the Redis license is the right approach, FWIW. I think there are better ones. Happy to chat offline with folks who have a similar interest in this space; email's in my profile.)
Basically it comes down to companies having systems for paying invoices. It's hard to get small and medium sized companies to make charitable donations - especially to open source which doesn't even help their corporate social responsibility goals.
This will keep going on, until FOSS community accepts that beyond university projects, someone pumping up their CVs, having a company sponsorship, or being able to pimp it up with some kind of subscription/consulting, there is little to no money to be made and everyone has bills to pay.
I think the developers generally understand that. No sensible person goes into FOSS for the money. It's the customers - consuming non-developers - who have a problem of expectations.
well, going FOSS can be an effective marketing strategy: by making something open and free (in both meanings) you get much higher probability of that something becoming popular. That in turn gives a lot new opportunities to sell complementary something or other something. This is best case scenario though, and you need to have resources/other sources of income for the time it needs to get widely adopted and popular (or the very possibility that it will not happen at all)
> going FOSS can be an effective marketing strategy: by making something open and free (in both meanings) you get much higher probability of that something becoming popular. That in turn gives a lot new opportunities to sell complementary something or other something.
Right, and then people try to do that, fail to sell whatever it is that they thought they would, and end up putting some sort of annoyance on the code to punish those who are using it.
But every person, sensible or not, has bills to pay. When you say "no sensible person goes into FOSS for the money" you are saying "most people can't afford to actively maintain a FOSS project", and you really can't claim that is in any way good for FOSS.
That doesn't sound like much of a change from the last 30 years. FOSS has done fine so far.
Really the only thing that might work is if there was broad community acceptance of not changing all the lower parts of the software stack all the time so the maintenance burden is lower.
Honestly; if we were interested in what was good for FOSS all that needs to happen is that hardware stops improving all the time. Then everyone can calm down, declare things finished and move on without requirements changing. The Linux graphic system (c.f. Xorg v. Wayland) still hasn't finished adjusting to graphics cards. That sort of change is bad for FOSS.
In a sense, this sort of thing is what is being showcased here. The breaking changes to FUSE are probably going to be linked to design changes in Catalina triggered by RAM/CPU/Network changes and the RPM/SSD transition that has been going on for however long. When that sort of thing subsides in 50 years there is going to be this amazing FOSS renaissance as working things stop breaking because of hardware changes and the balance really tilts towards free & available software.
So what? Maybe FOSS cannot get us a competitive modern desktop, but in many areas open source projects have virtually eliminated all proprietary competition. Linux is running everywhere these days and e.g. in databases it is among the open source options where the growth is. Does FOSS need to be able to solve all software problems in the world for you to count it as successful?
Only if by everywhere you mean cloud centers, where the likes of Amazon, Google and Microsoft have their golden eggs not shared with the community.
If you are going to mention ChromeOS or Android, ChromeOS is hardly a blip outside US school system, and what kernel is being used on Android is irrelevant to user space, there is Fuschia on the horizon and Google has been replacing everything, with the Linux kernel being the last piece of GPL code standing.
Then if you mean embedded, plenty of IoT OS are MIT based and even Linux Foundation now has Zephyr as alternative to Linux, all operating systems where OEM can profit without giving anything back.
If you mean compilers, plenty of embedded OEMs are now happy LLVM users free of contributions, while reducing their development costs.
> That doesn't sound like much of a change from the last 30 years. FOSS has done fine so far.
Compared to what knowledge of how good it could be if we had a more sustainable model than hoping someone has the charity or hobby to work on something we need for free?
This reminds me of when gamers assert how game modding has done fine so far limited to just labors of love and weekend hobbyism. Though I'm sure gamers are more coming from an angle of not wanting to pay for anything, we can only imagine the gaming mods we'd have if we had more of a culture around allowing people to work full-time on things we enjoy instead of only waiting for the few hobbyists with the masochism or compulsion to do it.
Modding is fundamentally different, because it's always beholden to the whims of the IP owner of the original game. They tend not to allow people to build profitable mods, since they see that profit as rightfully theirs.
The charitable part of the economy is pretty effective. You need to compensate people a lot before they'll do for you what they might otherwise do for free.
I'm not sure the argument "FOSS has done fine so far" is that convincing when you then lay out many of the places where FOSS has been failing miserably.
Not to forget the many, many places where it has and is succeeding happily.
Here's my "get off my lawn" perspective: those developers who remember a world where there was little or no free software (from, say, the mid-1980's, when Sun made the C compiler a for-cost option on SunOS through until commercial Linux distributions), have a visceral understanding of free software that those who came to it later, and (perhaps understandably) take it for granted, don't have.
Free software is a commons. In a healthy community, people pitch in to help, and maintainers become overwhelmed by the scale of activity, not because they've been left alone to support many users by themselves for years.
> In a healthy community, people pitch in to help, and maintainers become overwhelmed by the scale of activity, not because they've been left alone to support many users by themselves for years.
It's entirely because many of these projects are run by professional software developers, not professional managers. So many projects with single maintainers are that way because the maintainer feels a sense of ownership rather than a sense of stewardship.
It's not to say that solo maintainers are bad people; just that the jobs of writing software and coordinating software development require different, non-overlapping skill sets.
I don't think there's any question that this is true.
There are some efforts to address it (eg. SSL, Mongo, etc), but they're the first "drafts" if you like.
When a majority of the users of free software were programmers themselves, things were quite different to today. The world has changed, but the free software model has not kept pace.
With hindsight, I think the "Open Source" definition can be seen as a turning point, and the issues we have today stem from the decisions to give everyone the use of free software, even those who aren't of the community, or able to contribute in turn.
I don't think that was a bad or wrong decision, but I think that the ramifications are still playing out.
Most people can't afford to do effectively anything other than go to work and flop on the couch.
I don't think that's a problem for FOSS, it's a problem (if you call it such) of the economic system that we live under.
Generally the only realistic answer to that for most people at an individual level is to focus on financial security so that you don't have to care about that sort of fluff.
Most people can't. That's how our world works. In the general case creatives earn effectively nothing and only a few blockbuster individuals 'make it', regardless of the field; and usually they have to go proprietary to some extent.
"Most people can't afford to actively maintain a FOSS project" has always been true. It has been a hobby for some, a privilege allowed by the workplaces of others, and in a few rare cases companies have been built that charge for consulting and manage to fund a distro or other project that way. Or dual-license tech like Trolltech.
> It's the customers - consuming non-developers - who have a problem of expectations.
If FOSS zealotry wasn't a thing, then said expectations would be unreasonable. Sadly we live in a world where many people can withstand the cognitive dissonance of "You should use FOSS" and "You shouldn't complain about it because it is free".
I'm really curious, what do you want the FOSS community exactly to accept and what would the outcome be?
There are some FOSS business models. Sometimes they work. Sometimes they don't. Overall there's more FOSS than ever before, it's an amazingly successful concept. It doesn't always work, some projects and companies fail or decide to stop being FOSS. That doesn't change the fact that it's an amazingly successful concept.
I think the concept hasn't been as successful as some had hoped for when it comes to moving power and control over software away from big corporations towards users.
As an anti-capitalist movement/dream, open source has utterly failed. As a concept that has provided lots of opportunities for developers and startups it has been a great success.
Agreed. The GPL has been a great success, so much so it's been banned by capitalists in their organizations with the result of dying pretty much everywhere except the kernel, GNU userland and an occasional dual licensed fully enterprise-copyrighted software. BSD with its take it and run with it approach enables people to make a living by modifying (or selling unmodified) software. The situation is dire especially in the internet non-core-router infrastructure.
All BSD/MIT does is allow it to end up tivoized and remove power from the user. GPL is freedom for the user. BSD is freedom for the dev. Not all users are devs, but all devs are users. Users should take precedence.
Users won't have any power if they don't have software to use. It just happens that BSD (or similar) licenses are easier to deal with when developing things.
I am open to and find some merit in the argument that users could just fork, etc. Using GPL does seem to favor certain profit models more than others inherently, but non are exclusive, and there have been quite a few GPL success stories money wise out there.
I really like RedHat for this reason. It shows that it is the service and support, and the act of maintaining software, that makes it's money, and their books are open so you can see exactly how it works. A comparable startup/project probably won't get VC'd into a unicorn, but there is plenty of room for growth in the GPL software for sale along with service and support category.
Personally I mostly associate GPL with capitalism, due to almost all projects controlled by a single for profit company using GPL while community and hobbyist projects more often tend to use BSD/MIT/Apache.
> almost all projects controlled by a single for profit company using GPL
Which ones? The two flagship ones I can think of for GPL, Linux and GCC, don’t really have one company in control of them. And on the flip side LLVM and the browser engines, which are arguably under reasonably strong control of one or two companies, are usually Apache or similar.
The GNU created the GPL and licensed most of their software under it. I can't think of an organization less interested in capitalism. Rather the opposite because the viral nature of the license.
Linus picked the GPL to be less commercial/restrictive than the Minix source code.
No, this wouldn't have been a problem if the software had been gpl licensed, as the companies would've been forced to give back whatever they changed themselfes, potentially helping him out a lot
FUSE is generally shipped as a separate executable, which requires no modifications.
So no, GPL would have changed nothing. Companies would still have been able to ship it unmodified for free without contributing anything.
They could have kept their own code that uses FUSE secret, but even if they had had to release that code, that code is often useless to anyone else. It would not have helped or supported the author of the original code in any way whatsoever.
Or better from a funding PoV: dual licensed. AGPL by default, with non-FOSS licences available for a price.
That way companies or other projects that won't touch *GPL for whatever reason have an option that allows them to use the code while helping the project.
Of course this could make the code incompatible with other open licence (or the licensing policies of some larger projects) so isn't a perfect solution. I'm not sure a perfect solution exists when the project maintainer(s) need income to be able to justify the time to continue their work and have not found some other form of sponsorship.
If it were GPL-licensed, they'd have to give back the whole Happy meal, not just the FUSE fries. Perhaps you're thinking about LGPL, or a linking exception of some kind?
Alternatively, he totally could have gone and dual-licensed GPL and a permissive commercial license as a monetization strategy, like the author pointed out.
But you might be able to pay rent with it if those not wanting to feed back their work wanted the code enough to negotiate a paid licence under other terms.
That can be messy for projects with many past maintainers where the licence options at the time of individual contributions did not explicitly allow this or arbitrary relicensing, but in this case (single current maintainer, other contributions made under a licence that allows him to do this) it needn't be.
I'm not sure how that works, legally. If I understand you, you're suggesting that you can GPL your work to create leverage in a future negotiation with a potential user who wants to modify it privately and/or integrate it into proprietary software.
Can you un-GPL your work for a single entity? Doesn't that mean that you yourself are violating the GPL? I'm legitimately asking, not being rhetorical.
If you're the sole author of the code (or own the copyright or have the ability to relicense), then you can. It's not "un-GPL"ing the code because whatever you GPL'd will continue to be available under the GPL forever.
But you can say, hey, I'm ALSO releasing this code under a separate commercial license that costs $X dollars to get.
Well, that's pretty cool actually. I was unaware that was an option, and I'm pretty sure that many other people don't know that's an option either! It seems eminently fair to ask for money from people who are making money from your thing (and if they aren't, to not ask for anything).
I know a lot of FOSS contributors but have never met one IRL that seriously believes there is money in it. Outside of people on internet platforms (that by and large aren't to be taken seriously to begin with), have you encountered real zealots like this? I doubt that they exist in truly great numbers.
If the end goal is earning an income, sure. Yet there are other reasons to adopt an open source model. It is useful as a collaborative model. For that to happen, people have to be willing to submit code and the maintainer has to be willing to accept code. It sounds like that was not happening here.
That said, the FOSS community has created bigger companies and made bigger money than some of your favourite commercial projects (proprietary compilers, etc).
First, why should they contribute? You make it sound like a problem for the FOSS guys being exploited, but the choice of license is usually made explicitly to allow third parties to profit from their project without the burden of contribution.
Second, despite not having to contribute, license while, LLVM has still seen so much contribution from big companies (Apple for one) that the whole argument is moot.
Third, I meant companies like RedHat, or projects like Mongo, MySQL and others -- far more successful money-wise than most niche commercial compilers the kind that you appear to be a fan of while deriding FOSS for not making money...
I would hazard that that main reason that many (by no means all) FOSS projects are migrating to LLVM is that clang is dramatically easier to work on, and at or over parity in efficiency of output.
the Libre Software community understands this, which is one of the reasons we push for the Use of Copy-Left licenses, and not Permissive licenses.
So something like what happened here is not even possible. If the FUSE project on OSX would have been GPL from the beginning this person would not be able to change the licensing since he originally forked it, unless he rewrote all of the GPL code in a clean room rewrite which is not really realistic
If it was GPL from the beginning, wouldn't it be a "ZFS on Linux" like situation?
I don't think you can legally distribute GPL kernel modules for non GPL kernels. Even if you linked the module to the Darwin code, which is released under an OSS license (APSL), the two are not compatible and it's not clear if redistribution is fine (see "Darling: macOS compatibility for Linux")
Absolutely -- sustainability requires there to be money involved.
Honestly, the only model that seems to work in the long-term is corporate-backed OSS where maintainers are paid a salary. Professionalism endures long after the passion has faded.
> Likely the best outcome for the project barring company sponsorship that pays him to continue working on it as OSS.
The project page on github mentions two sponsors though, Boxcryptor and Editshare. I don´t know any of the story behind this though, just tought I should mention it.
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:
>Then drop it and let someone else maintain it.
I want to reply to this person: then fork the last open source version and maintain that. That's the whole point really. Besides he apparently made the change two years ago and people only start noticing now, it's pretty clear that there's not a vibrant community of contributors ready to take the project over.
It's not entirely fair in this case because of the certificate needed to sign the kernel module but if it'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's maintainer. Besides what can he reasonably do? Just give the certificate to whoever asks for it? That's going to get it revoked by Apple in approximately 4 femtoseconds.
Companies benefiting from the work of opensource projects and not giving anything back is genuinely a big problem IMO. It's not illegal of course, but it is unethical in my opinion. Look at the state of OpenSSL, one of the most (if not the most) popular crypto library out there, who has to beg for scraps in order to fund the project. And when there'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.
I'm a startup tech founder, benefiting massively from FOSS code. I realise there is a debt here, and the plan is definitely to repay that debt once we're cash-positive.
Being able to have that plan, and not having to pay for software licences up front, is awesome.
But I totally understand TFA's point of view. Maintaining a FOSS library is hard work, and those benefiting from it should contribute. If he's not seeing that happen organically, then he's quite within his rights to make it happen.
And to be fair, he's not even saying "I'll charge you". He's just saying "contact me". I'd speculate that if I needed to use his code, I could cut a deal where we would pay him when we get cash-positive.
"Small companies don't have the resources"... that's some backward thinking right there.
By failing to contribute, small companies cost themselves money very quickly. How can a small business afford to live in a world of un-maintainable forks, patches and tech debt?
Only large companies can afford to maintain private forks of FOSS. Small companies have to give back, or they will simply disappear.
I can't count how many times I've submitted a patch only to hear my supervisors complain that I made a contribution to the thing that makes the business profitable.
I know you are deploying irony but due to competing interpretations I can't figure out its intent. Do you mean the supervisors do complain or they don't?
Company A and Company B both use the same FOSS application. Company A has internal devs that add/fix the FOSS, but keep those updates internal. This gives Company A an advantage Company B does not get. Company A managers recognize this, and feel that since the updates were made on company time, they do not have to provide that to the rest of the world. Company A devs commit their updates to the repository, and now Company A mangers feel like they have given away work product for free. Lots of way pointy hair bosses to be upset in this scenario.
I think it more accurately depends on the nature of the project and the nature of the patch. Not every patch is "technical debt" [itself a term that often encourages incorrect conclusions due to the debt metaphor not fitting perfectly] and not every amount of maintenance is scary. People react this way in fear before they understand the work.
But sure, it's a good idea to send patches upstream.
The problem with tech startups, especially VC funded ones, is that they are rarely profitable until they are sold to a bigger company or (in rare cases) go public.
And once either of those happens, there will be forces opposing substantial OS contributions ("fiduciary duty" etc), which will win out if the leadership doesn't fight for it.
This is why I said "cash positive" not "profitable". Not the same thing. e.g. Amazon is cash positive, but not profitable.
My priority is making sure payroll is covered. After that, I'd put OS contributions as an infrastructure cost (like licence fees for paid software), so fairly high up the list of priorities, and an annual budget item.
Red Hat sort of did that when they had their IPO. They allowed contributors to the open source they used to buy Red Hat shares during their IPO at the IPO price.
They were remarkably generous in who they considered to be a contributor for this. For example, I found a bug in trn that caused it to trash .newsrc files on Red Hat. I spent about 30 minutes figuring out what was going on, and submitted a patch to Red Hat to fix it. It was a very simple patch, merely changing a declaration of one variable from char to unsigned int [1].
This was enough for Red Hat to classify me as a contributor and invite me to participate in the IPO. I bought $2000 worth of their stock at the IPO price on the morning of the IPO, and sold it that afternoon for $9000.
[1] There was some function or macro that given a character returned a set of flags indicating if the character was upper case, lower case, numeric, etc., and apparently on all other systems the flags that trn cared about where in the lower 8 bits, and so storing the flags in a char worked. On the then newest Red Hat, that was not true.
Because I think that owning a tiny shareholding in a business is more hassle than it's worth for everyone involved. Options is more of a possibility, but again, more hassle than just cash. And involves more explanation to non-techies who won't understand, and will possibly intervene.
I can just put "software licence" as a budget line item and make a payment, and everyone's happy, no questions asked.
> What prevents me from making Microsoft a 1% shareholder of my company Cockwombles Inc?
I don't see the mechanism by which this would be possible. Companies (and individuals) are not under some legal obligation to accept donations.
> Or giving them a specific exemption in my license for the cockwomble software library?
I've seen licenses over the years that say things like "this software cannot be used by companies or contractors working in the defense industry" or "this is free except when used by FrombleCo, which will need to pay me $500 per user." I suppose it's a way of expressing your disapproval of FrombleCo (or the defense industry), although I'm not sure how I really feel about that approach personally.
> then fork the last open source version and maintain that.
But the current maintainer has the Apple provided signing cert, that's the whip hand in this whole deal.
I personally don't blame this fellow and in fact apluad him. To many companies exploit OSS maintainers. I think it's great to see someone turn it around for once.
>But the current maintainer has the Apple provided signing cert, that's the whip hand in this whole deal.
So apply for a new signing cert? The only thing I'm hearing is "he closed and I don't want him to close it but forking it takes a lot of effort and I don't want to put in that effort".
If nobody is willing to put even the basic effort of applying for a new signing cert, color me skeptical that they'll actually maintain the entire project including the apparently voluminous changes needed to work with Catalina.
I hate nothing more than people who complain something isn't open source but want it to be maintained by someone else's time and effort. People's time isn't free, and they have no obligation to give you their current or previous time for nothing. (Not talking about you personally, referring to the guy in the original post)
From what I recall, Apple really doesn’t like signing competing forks of the same software. It’s next to impossible to get e.g. your own fork of Firefox into the App Store. They see it as a phishing attempt on the “real” app, I think.
Huge tangent but this is the same thing that bothers me about pro piracy arguments. Some people feel they have a right to get a copy of someone’s music without paying for it and get upset when there are protections to prevent this.
Yes, I didn't understand why TFA considered the signing cert issue significant. AFAIK, Apple would not refuse issuing multiple certs for forks of the same code base.
> I agree that any aggressive towards the maintainer is unwarranted, even if I personally disagree with his move.
I also agree, being aggressive towards a volunteer maintainer achieves nothing and brings the possibility that he'll simply stops working altogether on it for free, like what happened with wiringPi some time ago.
The developer always thought that contributing back code or financial support should be a requirement of use but failed to reflect this in the license chosen and now is correcting this.
The developer over time has changed their believe of what the requirements for use should or need to be. This change of thought may have been informed by the behavior of those using the code but is still a change of thought on the developers side.
In both scenarios the developer changing their license is not acting unethically nor were those previously using the code while meeting the terms it was previously available under.
What may be unethical is the developer trying to put blame for the license change on those that were using the code while meeting the requirements of the previous license because under the first scenario the developer is at fault and under the 2nd neither is at fault.
In my system of value (which is of course subjective and you may not share) I do consider that these open source projects suffer a sort of tragedy of the commons where some companies benefit immensely from them (think how expensive it would be to build and maintain something like osxfuse from scratch) but don't contribute anything back to it. It's like big corporations managing to pay little to no taxes in the countries they do most of they business, is it illegal? Probably not in most cases. Still unethical in my personal opinion.
But instead of just complaining about it I could try to be more productive and offer an alternative. Maybe there could be a nonprofit dedicated to centralizing these donations and redistributing them, for instance by polling the donors to figure out what they use and then split the cake based on the results. I'm sure in many situations it's not so much that the company doesn't want to give anything bad, it's just that they can't be bothered or don't know how. I don't know how realistic that would be though.
Part of this goes back to the entire GPL/AGPL vs everything else debate. Everyone has been getting away from GPLv3 and it's derivatives for the past decade.
In that world, would it matter so much if some commercial interests took a product, since they'd always have to at least show their work? The idea was that we'd eventually have FOSS replacements for everything from Photoshop to Word to video editors.
2019 and GIMP is is nowhere near the level of Photoshop, Libreoffice is pretty decent through, and DarkTable isn't too shabby.
Still, this FOSS utopia of all our software never happened. Linux as a kernel for Android has led us to an even more closed system than before. Sure if Linux was GPLv3, maybe we wouldn't see it as the basis of Android at all, but if we had gone down that route, I wonder how things would be different.
Yeah, but they're Google. Their business model is lighting piles of cash on fire, then advertising to the crowd that shows up to watch the pile of burning money.
That was a very good write-up. Quite fair, and Kool-Aid-free.
It is a pretty good synopsis of the issues faced by open-source developers, these days.
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 "sexy."
Open-source developers (of which I'm one) need to make extra efforts to document and "decorate" their projects, and often dream of "going viral."
However, like so many folks have found on YouTube, fame != money.
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.
I strongly suspect that a lot of OS developers have walked away from promising projects because of this crap. I'm a stubborn, cantankerous bastard, so I haven't; but I also have the "advantage" of not having any projects that have gone massively viral. It's been a drip that I can use a saucepan to catch; not a deluge.
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.
I'm starting to feel that September is slowing and it might end at some point, that in the end it really is related to the technology adoption life cycle[1].
If you look at the bell curve on that page, its integral is the technology penetration, that is a sigmoid: start slowly (initial period), accelerate (eternal september) for a while, and start to decrease the penetration speed.
At some point, enough people will likely have knowledge about the technology that new entrants will take much less time for those already in to bring up.
You can argue that those that enter the field now are adopting GAFAM rather than OSS alternatives, but I think that as long as you have the "eternal september" feeling, it means that a lot of people are jumping in, and will in turn help the upbringing of others later in the cycle.
Hopefully FOSS culture and knowledge will become endemic in companies at some point; that's all I'm saying. But it's hard, at any point of the curve, to predict where we are in that cycle, and when it will end.
I'd be curious to see some data on say, the number of Facebook users. I'm pretty sure it can be seen as a sigmoid.
Are you sure? I am certain it's accelerating. More and more people use the Internet for their daily life and more and more services are "going digital". I know some 16 year olds (born 2003, after XP how depressing, I feel old) and the concept of NOT having the Internet and dirt cheap music streaming etc. is completely alien to them. They also have no concept of privacy and will install every service known to man on their devices (with the sucking up of data from them) without any thought because "it's free". This only increases the expectation of free (as in £0.00) software and services.
When's the last time you met anyone without a Facebook account? Tell them you don't have a Facebook account or a WhatsApp account and they will look at you as if you are from Mars, and trying to explain to them why you don't want such an item is like talking to a brick wall.
Try living without Google.
It's all getting very difficult to do because the alternative is so very very easy.
I was installing everything that was “free” back in 1995. You cannot expect a teenager to be familiar with internet-privacy mantras; it’s actually horrible how we’ve created a situation where these poor kids are forced to learn and self-defend against an onslaught of trackers.
Agree! I can't see it getting any better for 99% of users either - you have to be quite technical.
And once DNS over HTTPS is the norm (thanks Google + Microsoft) I literally have no clue what I'm going to do - I won't be able to stop any of the tracking domains requested or "telemetry".
It's a nightmare and I think the Internet will be "over" for me at that point.
eg. Little Snitch tells me all the outgoing requests on my Mac, I have to run piHole for DNS to block 27% of my DNS requests (yes that much), OOSU10 is mandatory on Windows 10 to turn off a boatload of telemetry, and every site on earth these days don't self-host - they pull from 20 different sites instead of just their own site. That's 21 different organisations that know I've visited their site,
eg. visiting White Stuff's website (clothing) for my wife and I get
whitestuff.com,
googletagmanager.com,
google-analytics.com,
wsweboptimisejs.blob.core.windows.net,
via.placeholder.com,
tag.bounceexchange.com,
fsm.attraqt.com,
fonts.googleapis.com,
data.rci.eggplant.cloud,
cdn.optimizely.com,
c3n4sovn.cloudimg.io
You can block all IP ranges owned by the tracking companies. Sure many services will stop working.
Some people go vegan, some people go GNU. There are plenty of content to discover beneath the mainstream commercials. There is so much content on the web, and the Internet is not just the web. That I'm sure you can live a happy life, without consuming the services which business model is centered around how many ads, trackers and spyware they can install on your devices.
Yes this is true. I am quite happy living my life without all of this garbage, but more interested in how to effectively be able to stop this kind of garbage without constantly playing whack-a-mole.
They are using the internet, but they're no longer internet citizens. They don't have any understanding of how it works (even on a basic level), and are being walled off into proprietary apps like cattle.
I would tend to agree with this. But we don't have to spend much time upbringing them to that level.
There are likely a few dynamics at play for this "eternal September": initial population size and increase rate, target population and its attrition rate, and transfer rate between the two. I'll see if I can run a few plots...
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.
as I interpret most permissive license's, they say something like "must retain the above copyright notice, and this list of conditions.", which makes it not possible to change the license. But you can always go "closed source", and there's nothing stopping you from charging money (which is why Business likes these permissive license's)
The footnote says Google are using their own fork. Now we don't know when they forked and how much they diverged, but it's quite possible that were going to maintain their own fork, anyway.
It's also noteworthy isn't the "original author of osxfuse". In fact, Google is. So while I can empathise with the general complaint about commercial use, one doesn't get to make that complaint against the one company that originally started the project and released it under a permissive license.
Disagreeing with someone is no excuse for saying their freedom to exercise the rights of an open source license should be restricted, nor for declaring they have no right to speak their mind openly. Open source grants them this freedom, unpalatable as it may be to you.
There is no legal reason preventing their complaint from being made. It may not be well-received by those who demand unlimited reuse without compensation. Regardless, that does not restrict one’s right to make that complaint and take that action.
This isn't a question of rights. Most people understand in English that "can't complain" means "you can complain if you like but won't be taken seriously or regarded as a valid complaint".
Non-disparagement agreements are a common thing in business. They restrict your right to "complain". I regret the conflict between my understanding of English and that of others, but I stand by my statement.
That's why I prefer the GPL and variants for personal projects that I don't intend to profit off monetarily. It's a conscious choice that I do want compensation, and I don't want to work for free"--but said compensation should be in code and not necessarily in money.
It's why contributing to a BSD-licensed project as a hobby can feel a bit icky, and doing the same on a GPL-licensed project doesn't.
If I don't want my code to be used in a commercial setting I use AGPL. It's super-banned in every company for which I know the open source policies. It's also the most sensible open source license in today's SAAS world.
In addition to the sensible question of whether Google even would need to link against any GPL code raised by other commenters, there's also the question of whether the GPL would even make any sense for a kext, considering the kext needs to include Apple's header files (largely APSL-licensed) and link against macOS's kernel. (binary-only proprietary fork of the open source xnu source dump)
(I've licensed my own FOSS kext code as LGPL - either way, the copyleft aspect wouldn't affect any userland code using the kext as it'd be running in a different process. And AGPL doesn't change anything in this context either as far as I'm aware as its additional provisions are only relevant for code running on systems not under the user's control, and again if you're not linking against it, your code isn't a derived work.)
Maybe. What we know factually at this point in time: osxfuse was BSD licensed, Google used it and haven't contributed back. osxfuse is popular project.
If it was GPL licensed, do you think Google would bother to use it? Or would they write their own instead? Would we even know about osxfuse then?
MIT/BSD is amazing on bootstrap phase, when getting code used and building user base is top priority. Monetization always comes later. Using GPL from the start might just turn your first users away and you might never manage to get critical mass of users to be able to monetize product at all.
In this particular case we don't know if there were any other previous attempts at financing it, like have maintainer contacted Google to provide consulting services? Or provide enterprise support to other parties? etc.
MIT/BSD is in a kill free software phase, where commercialization of SAAS and other services are king.
MIT/BSD is turning open source software, in to open source dev tools and libraries, no longer is should the end user software be free and open, no just the tools, frameworks, languages, and libraries used to create the end user software
I wasn't aware that osxfuse is distributed by Google. If that is the case then I am sorry for spreading false information and indeed, the GPL would apply.
It's still not clear whether the GPL would apply in the way commenters here think it would.
GPL clauses would only affect Google code upon linking. It's often possible to use fuse style software without linking - they could use it via the command-line and mount whatever they need at startup or even dynamically.
Does osxfuse have a command line tool? Most fuse style software does. If it doesn't, Google could have written a command-line client and open sourced just that.
> GPL clauses would only affect Google code upon linking. It's often possible to use fuse style software without linking - they could use it via the command-line and mount whatever they need at startup or even dynamically.
This doesn't matter. If you distribute the isolated program you need to provide the sources anyway. Having to license other Google code as GPL is not the issue. It's making it required to provide back the changes you've made to fuse itself.
There may be some GPL proponents that really want it to "virally" infect other code. But what atq2119 was describing is just wanting to make sure you at least get back the changes to your own code. That's also why I think the trend towards BSD/MIT in open-source is dangerous. GPL/LGPL/AGPL should be perfectly fine for corporations when used appropriately. They are almost always just ways to make sure the best version of your project doesn't end up closed-source. I can't recall cases of those licenses being used to force other code to be open-sourced but maybe they exist.
GPL also only affects people other than the copyright owner. Google can relicense the code to themselves for their own internal use, if they hold the copyright on all the code they are using.
As far as I understand this would be a "mere aggregation" since the application and the kernel module communicate at arms length through the kernel syscall interface https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation .
So they'd have to make the source of the kernel extension available (as the GPL requires) but it would not be viral to the application using the kernel extension.
As the FAQ entry says this is a legal question "which ultimately judges will decide" and as far as I know that hasn't happend yet. Which is probably one reason many don't want to do it and err on the safe side and choose another project with non-viral license.
You conveniently left out the "and variants" in your quote.
I personally wouldn't mind this kind of internal use for the kinds of projects I'm involved in. For the kinds of software that is more likely to play a substantial role in customer-facing services, some people would feel differently. That happens to not be my cup of tea, but in any case there's the AGPL, as another commentor points out. And for yet other situations, there's LGPL.
Though as gdrive does have locally installed components, if those used code covered by standard GPL they at least would be covered even if the server-side components were considered separate enough that they would not.
I'm not sure if the dev feels entitled for _compensation_ per se, but G and other companies don't contribute back to the project in any form. Not $ and not in code. Now that is not a very good thing... though technically that's exactly what you get with permissive O/S licenses. It looks like the dev realized that and changed the license.
It also doesn't look like he trusts this companies much, because otherwise he could've just slapped the Commons Clause on his existing license and be done with it. So he closed the source instead.
Fleischer isn't harmed by Google using it, in the same sense that Google isn't harmed by him releasing osxfuse 3.10 under a proprietary license instead of BSD.
For the community it's certainly a pity, but I guess if you consider open source projects to be "default dead", not contributing to keeping it alive isn't the same thing as harming a project community.
To many developers, the main reason they contribute to open source software is for the benefit of leveraging each others work. If one is the sole author due to lack of contributions, from that perspective there is no value to the developer in providing it as open source. The problem is compounded if they look around and see companies profiting off of their work and neither contributing fixes/improvements back nor funding the developer(s) who do.
So how is it harmed? By exactly the situation playing out with FUSE: the person who has been maintaining it has been seeing no benefit financial or otherwise and decides to take his ball (the source code) home as he has every right to do. I suspect if he doesn't see some corporate sponsorship soon he may very well decide to stop releasing future updates entirely.
> To many developers, the main reason they contribute to open source software is for the benefit of leveraging each others work.
Then these developers need to understand copyright and licensing, and choose a license that enforces that motive. If you release under BSD, you're not encouraging companies with a profit motive to contribute back.
So, on one hand, it's not a stone soup situation in the sense that it's not like there's any less soup if Google comes and takes all the soup they can eat. On the other hand, open source software only survives when _someone_ contributes needed maintenance, bug fixes, security patches and features. If you don't find a way to incentivize people to contribute, the project can fail. Incentivizing people who are already using your code and have large sacks of cash seems like the easiest place to start.
> It also doesn't look like he trusts this companies much, because otherwise he could've just slapped the Commons Clause on his existing license and be done with it. So he closed the source instead.
If he doesn't have a copyright assignment, he probably can't easily change the license.
However, if the license is BSD, he can just not release source code. And, if he wasn't getting any contributions anyway then he gets no loss.
No, you don’t need copyright assignment to relicense permissively-licensed code, you (or anyone else really) literally only need to say “fuck it” and start building on the old BSD code with a new license.
It is when you’re relicensing to a less restrictive license, say GPL to BSD, that you need CLA shenanigans beforehand.
I know exactly what you mean, but this is incorrect.
CC is not "closed source". CC makes a license incompatible with the OSI definition of "open source", which is one of the interpretations of the term.
There's a persistent confusion over the difference between OSI's definition and the casual understanding of it. To the laymen, if you can _see_ the source, then it's an _open_ source. And if you can _use_ and _change_ it, then it's a _free_ source.
So when you start claiming that if it's not "OSI's open source", it's "closed source" - it doesn't help matters in the slightest, nor does it help advancing OSI's view of the open source.
Are you going to tell me next that "free speech" means not paying for the radio? And that everything else is just one interpretation of the term? Or that freeware and free software are interchangeable terms?
CC is not open source and does not get to pretend it is. Come up with your own marketing name.
> CC is not open source and does not get to pretend it is.
CC is not a closed source license either, which is what GP claimed. That's the point.
> Come up with your own marketing name.
... and the second point is that OSI zealotry doesn't make anyone any good. "Open" is an ambiguous word. It's the same issue as with "Free software", which is almost universally followed by the "free as in speech, not as in beer" explainer. 25 years in use, still ambiguous.
"Open source" is a misnomer, it doesn't mean exactly what it says. Ideally, it should've been called "libre source" or some other made-up name, but that boat has sailed. And so flipping people off because their understanding of the term is different from the OSI definition only serves to antagonize them and needlessly paint the whole open source movement bad.
Saying this as someone with all side projects released under OSI licenses, some as far back as in mid 90s.
The GP is me. CC is not open source^TM and hence closed source^TM.
> "Open source" is a misnomer,
Sure, but who cares? The fact is that if you tell me "this software is open source" I know that this is a domain specific term and what it means, just like "this is a normal vector". In particular "normal" here means something else than in standard English.
The only thing you are then doing is complaining about how you wanted to use "normal" for your new cool definition.... That ship has sailed.
Aka pretend it is. If you have to say that you are not actually <adjective> but only "<adjective>", then this is not an alternative definition but alternative facts (i.e. you are lying to deceive people).
Given that the main selling point of permissive licenses is that they make it easy for businesses to incorporate code into a project that can be closed-source for the sake of competitive advantage, this would seem to be an incident that might have been prevented with a license more in line with the author's motivations.
He doesn’t call google out by name but what grandparent says explains this:
> Starting with this release, redistributions bundled with commercial software ...
The question is, is google going to call his bluff and pay up or reassign some internal resources? I’m assuming they’d want their gdrive fork to work on Catalina.
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.
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.
> It’s a shame that the article is written in this tone
The article seemed pretty neutral excluding the slightly shady stuff like not mentioning the license change properly, timely or even in expected locations
> the dominant sentiment among open source folks
The dominant sentiment of open source folks is that they want open source instead of proprietary software? That seems expected, it’s after all the whole point.
That's a lie, lots of people donate voluntarily for their favorite free software every day. If you decide to be a leech that's fine too, but don't try to convince yourself others are that way as well.
Since you brought up the Linux Foundation as an example, the large pool of contributions are from Fortune 500 happy to use Linux instead of paying for UNIX licenses.
Which in any case only a tiny part of kernel contributors can live from.
Tiny part? Your immediate preceding sentence observes that the large pool of kernel contributors live on salaries provided to them by Fortune 500 companies.
Is that a roundabout way of admitting that you're wrong and open source can be sustainable?
Not even close, because those developers are employees from Fortune 500 companies in one way or the other, they are not being paid by other developers paying to use Linux based software as such.
I don't understand. "Not even close to sustainable", you say, then complete the sentence by describing the situation in which Linux has been and continues to be sustainable.
What is the relevance of that part? Your claim that open source projects can't be sustainable is straightforwardly false, regardless of whether there are any Linux developers who are payed by other developers in order to use Linux-based software.
Similarly, your claim that "open source folks" don't value open source software as worth paying for is straightforwardly false, regardless of whether they pay out of their personal bank accounts or push their Fortune 500 employers to donate money and time (which every Fortune 500 calculates in terms of money).
Linux Foundation is an obvious example of big corporations paying for the development of a project they rely on: most money comes from huge corporate membership fees, most code comes from salaried programmers at those corporations.
Most devs though would balk at the idea of paying for Linux.
Yes, big corporations like Google, who is perfectly capable of paying for osxfuse, too.
Balk? You think the MBAs at those big corporations are pushing them to pay for Linux over the objections of the devs? No, devs don't balk, devs are the reason those companies are paying for Linux.
What in the world do any of your points have to do with the discussion at hand? My parent, pjmlp, claimed that (1) open source can't be sustainable because (2) open source supporters don't value open source work as being worth paying for, both of which are contradicted by the incontrovertible facts that (1) sustainable open source projects exist and (2) they're sustainable because of open source supporters who pay for it. Corporate supporters, yes, but corporations are composed of people, and corporate supporters of open source are only that way because their "open source folk".
- There are very few sustainable opensource projects.
- Of those which are, such as Linux, they are sustainable not because community cares about them (they might or might not) or because community pays for them (they might or might not), but because corporations find enough vested in them to support them (through money and/or people). I highly doubt Linux Foundation is sustainable without corporate sponsors.
- If you ask a typical dev to pay for a Linux distribution, they will balk at it. A one-off donation? Maybe. And that's Linux, a major and a clearly expensive project. How many projects are there that we take for granted? How many of them are sustained by the oh-so-great-and-generous open source community? Dozens? Less?
There's a very clear division:
- Strategic projects with vested interests get picked up my huge corporations (or started by them).
- A few lucky projects get enough traction to be able to live off donations whole working on them full time.
- The absolute vast majority of all the rest can and do survive only because devs can afford to work on them. As soon as they can't, good bye development and support.
So...you're not disagreeing with anything I said, you're just trying to educate me on how difficult it is to build sustainable open source projects? Thanks, I'm painfully aware, I have experience maintaining an unsustainable open source project.
Or maybe you are trying to disagree with me, in the self-contradictory sentence in which you state that projects like Linux are not sustainable because community cares about them, but because community members find enough vested in them to support them. What's the difference between "care about" and "vested in and support"?
Or, for some reason, you and pjmlp don't consider people who work at corporations to be "community members". Turns out if you exclude most of the people who are paid to work on open source, then you find that there's no money being put into open source!
Look, I'm sorry to be snarky, but it's frustrating to be told facts that don't contradict nor add to what I've been saying, and that I'm already all too aware of. I don't know what point you're trying to make.
If you're just trying to point out that many important open source projects can't get corporate backing to become sustainable, again, I already know that from painful personal experience, but in the case of osxfuse it actually seems like it is in a position to get Google to pay up, and in any case the problem of sustainability in open source is squarely not the open source community's fault like pjmlp implied. That's been my point the whole time. I don't know what yours is.
18 years ago, since then it's been open source and paid for by donations
>and has some big studios doing those donations
These big studios started donating this past year when the development fund was started (and really took off during the latter part of this year for some reason), before that it was donations and in later years also the Blender Cloud service.
>And I bet only a lucky few of the contributors get to see the money.
Well, most (if not all) of the Blender developers now working full time where Blender contributors, also Blender is a non-profit organization.
We lived in that world a few decades ago, it sucked for users, and where it's still common practice, it still sucks for users, and the only players really allowed to play that game are a few big names.
I think there should be either a dual licensing model, where if a company earns more than X$ they need to pay a license, if you are a student wanting to learn more about how its implement then it's free, or you just have to pay for it.
OSS has killed indie development, for the benefit of large corporations. Thousands of developers out there are putting in their own sweat blood and tears in advancing "humanity" by building great OSS products, only to be taken advantage of. Seal the pipe. Charge money for great work!
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.
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, after spending thousands of dollars on a MacOS system
No world has ever produced a violin small enough to play an elegy for those “victims.”
If you wanted a Free Software FUSE, maybe a Linux desktop would have been a better choice?
I fail to see how that is in any way the heart of the matter. The articles mentions someone being mad completely in passing, in a quoted tweet. If anyone in this HN thread is mad, they're a tiny minority because I haven't seen any.
Instead it seems more like the heart of your comment is that you view everything in terms of an ideological battle between the Free Software movement and everyone else. So when you came upon an article and HN thread calmly discussing a maintainer's decision to change their project's license for understandable reasons but in a somewhat underhanded way, you immediately sorted everyone into heroes and villains and self-righteously took a stand.
> "you immediately sorted everyone into heroes and villains and self-righteously took a stand"
And when you proclaim that this person "views everything in terms of an ideological battle between the Free Software movement and everyone else", would you say that's a more nuanced and balanced take on the matter?
They might seem to be, so let me explain: To me it looked like you were doing exactly what you accused the other poster of -- immediately sorting them into the 'villain' bin and taking a self-righteous stand against them.
Interesting. To me, calling people "calm" doesn't sound particularly heroic, nor does calling someone "self-righteous" sound particularly villainous when I don't suggest they did any harm. Being harmlessly self-righteous may be embarrassing, perhaps, but hardly villainous.
By contrast, "free riders", "huge amount of unpaid work [for] wealthy software workers", "No world has ever produced a violin small enough to play an elegy for those “victims.”"—I don't think I addressed my parent in remotely approaching that much disdain.
Becayse you're free to take the existing source code and adapt the software to work with your choice of OS and hardware. There is no requirement for free software to support every platform in existence out of the box.
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.
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.
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.
The BSD license and other similar licenses, while seemingly more free - really aren'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.
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 "paid for" in code. It won't put food on the table, but it is the least that someone could do, imho, by benefitting from the rest of the codebase.
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 "paying for" code with code, so that code nor changes to it will ever "go missing" or become "locked up" into some proprietary version of the code, and ultimately benefiting users less (whether they know or understand it or not).
I honestly didn’t see the need for GPL until a project I had sunk a lot of time into contributing to changed their license from Apache to Proprietary and started charging more than I could possibly afford for a license.
I feel tricked and betrayed, it has been a year and I am still upset. The whole thing feels like I got robbed. I donated my time to a project I thought was for the good of the community, turns out I was just doing free work on a proprietary product others stood to make money on.
It’ll be a long time before I sign another CLA on something I care about.
On the flip of this, if it were GPL it likely wouldn't have seen the adoption by commercial companies that it has had. Barring whatever signing key they are talking about, nothing is in principle barring people from forking this and continuing it as open source.
No code has "gone missing" or has become "locked up." You simply don't have access to the new code he's written, and why should you? Frankly, if this were GPL the result would have likely been that he simply stopped working on it. You still wouldn't have gotten any code you think you deserve, and you also wouldn't have the current commercial option.
This example just highlights to me why I prefer licenses like the BSD license.
I'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 & free source advocate, and I am completely biased for it.
I think everything done here seems legal, because BSD licensing pretty much allows for this (I am not a lawyer though, and I haven't examined how things were with third-party contributions for example).
Morally, the only fault I can say on the maintainer'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 "quietly" isn't an option when a big number of users and/or big players are involved (as it seems Google is involved to some extent).
> Morally, the only fault I can say on the maintainer's behavior is a lack of transparency.
Totally agree with that. The maintainer seems to have made very little effort to get compensated for his work. It would surely be nice if some company stepped-up and offered to sponsor the development of the project. But it's also kind of childish to scheme and hold grudges for not getting something you never bothered asking for.
Other open-source developers have been in a similar position in the past, but the handling of the situation was much more transparent and considerate. Off the top of my head, I can remember the example of Synergy [1]. When the developer needed support, he announced well in advance the changes to the model of development. And actually put the time to spin-up a company around the project, and offer ways for normal users to support development.
I'm very happy for you getting paid to contribute to open source. I wish I could find someone willing to sponsor me. My field is fairly narrow though with few users and not that much commercial action.
Just to clarify. I'm not "sponsored". I am payed to do software. Something someone else wants done. I wouldn't work on it on my free time. But it's still open source.
I think this is fairly overblown, there are a fair number of FUSE for macOS forks out there with signing certificates.
I have kext signing certificate for ExpanDrive, Google has one for Google Filestream, I suspect many others have one as well. Rightfully, Apple doesn'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're not going to panic end-user systems, you can get one too.
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.
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
I have no inside information but assuming they continue to expose the VFS layer they will very likely build a usermode extension framework that is quite like FUSE, but supported by the OS and maintained by Apple.
I am afraid there's nothing people can do about this issue: according to https://github.com/osxfuse/osxfuse/blob/master/LICENSE.txt the project is BSD licensed and AFAIK closing the sources of a BSD-licensed project ("re-licensing") is allowed.
Yep, he's allowed to do this and people basically have to suck it up.
This couldn't have happened if the code was GPL-licensed.
This might be a good occasion take a moment to think about all the BSD-licensed software you'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.
A key problem is getting people to pony up. People are all for "the community" and the maintainers doing right by "the community" when that means they (as a member of the community) get the benefit of the code. They are often less vocal about being part of the community then the project maintainers ask for financial assistance, generally assuming that other people will chip in so it'll be OK if they don't.
This isn't just commercial interests: this is private individuals too. Welcome to the idealism of F/OSS rubbing up against less altruistic parts of human nature.
While I'm judging others I'll have to hold my hands up and say that, while I have helped out some projects in the past via both bug-fix contributions and small financial ones, and having opened some of my projects in the dim & distant past, I don't think I can claim to be a net contributor by any wider measure.
I don't see this as idealism vs a selfish human nature, not directly at least. The maintainer has been delivering a low level open-source product within a proprietary operating system. That's got to be tough, and as the article states, it's the main source of hurdles to others taking up the project.
There is one huge thing that can be done about this. Push the commercial users of osxfuse to penny up and share some profit. According to the article they are using osxfuse for free and not contributing any code back either.
If you use software that is dependent on osxfuse....send an email to your sales contact and let them know that they need to contribute back to the community.
If he wanted to switch to GPL, he wouldn't have to relicence all the code; just the code that is by him alone. The contributions by others are in a permissive license that is compatible with the GPL, so they could remain in their current state; but the whole project would contain GPL code so anyone redistributing the project would have to do abide with the terms of the GPL.
this quite reminds of the openssl saga, but on a smaller scale, with single developer more or less responsible for world's encryption for decade.
it's a pity, it'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.
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't it?
if it's true that VeraCrypt, the G company and others based work on this developer's efforts and forgot, for decade, to give back anything, well - it'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.
all other companies building big-software based on hundreds opensource projects should rethink their strategies.
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.
Why should companies give back when the code was licenced in such a way as to not require it?
If a developer works on a project and wants commercial companies to give back then they can choose a suitable licence such as GPLv3; if they just want to get their code out there and don't really mind how it's used then BSD is more suitable.
Maybe they don't need to, but it would be good to have an ecosystem that incentiviszed sharing instead of relegating it to an altruistic few. That's on both the companies and the creators.
If a large software company had to pay 0.1% of its profit (revenue?) to each foss dependency they wouldn't have any left.
And contributing back is not as easy as lobbing code over the wall, you have to spend a lot of time and energy coming to agreements on what makes sense to share and how to organize it. It would probably be a full time job for Mr Benjamin to vet external contributions even if everyone could agree that all were desirable.
From the amount of people complaining here, it seems to me more like everyone is now pissed off that the supplier decided to go elsewhere and stop offering gratis services, as means to pay their bills.
> 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.
Just a note here, my understanding of the legal status of software licenses is that they don’t supersede your own ownership of copyright.
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.
Now, if he’s closed sourcing and using/changing someone else’s contributions that were licensed to the public in a copyleft license, that’s a different story.
> 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.
> As the nearly-sole contributor, the author can violate his own license for the code he created.
To be more specific, it is not in a violation of copyright. I am pretty sure that when I publish my code under any standard* licence it is not an exclusive license.
I can still sell access on a more business friendly licence, publish it under CC0 and so on.
*is there even serious licence that includes "no dual licencing" exclusivity clause that is binding the author? Is it even possible to do as a licence?
I guess you could draft it as some kind of exclusivity licence "this work will only ever be available under this licence". You would still own the copyright, just contractually bound not to exercise it.
But even that wouldn't be very convincing. If the author republishes under another licence this isn't in violation of copyright or any criminal law, it's more like "I gave written agreement not to do something I have the legal right to do, did it anyway, and nobody can demonstrate any damages. Sue me"
IANAL, but a license, can't, in itself, restrict anyone's rights because it is a grant of usage, and a more restrictive licenses is really a lesser grant. In the case of software licenses, the rights were already restricted by the claim of copyright.
And that's generally the case: you give someone license to enter your home, which they were implicitly restricted from by your holding the right to passage about your property.
The legal mechanism that lets you negotiate to restrict your or others rights is a contract, and that's completely different from a license.
I’ve tried using FUSE for the Mac many times throughout the years, mostly for curl_fs and ssh_fs.
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.
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.
So between native NTFS read, ExFat read/write and decent for most people remote disk apps, there are probably very few users who care about FUSE on the Mac.
I don'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.
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'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'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't contribute back you need to buy open source credits.
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've burnt? Probably doesn't make sense. Maybe a logarithmic scale. But the real value of open source isn't dollars but people time (which, if you'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.
Until we have a value and a currency for open source there won't be an open source economy.
To me, this is the root of the difference between Free (libre) software as defined by the FSF and open source software as popularized by the OSI.
The primary case for open source is business and money - money is more efficiently spent on supporting open source, and all of the businesses that spend money on open source get to benefit from contributions from others. In this model an open source economy is desirable because that's how you prevent one greater fool from funding all of the open source software that everyone else uses without paying.
The primary case for Free (libre) software is the social utility/social value of the software. Their case is primarily moral and ethical first. They're not against making money on Free (libre) software, but that's not their end goal. Their end goals are political and focused on end users, not businesses.
I'm not trying to say one is inherently better than the other, just trying to highlight the differences.
I agree to some degree, but I don't think an open source economy is fundamentally opposite Libre/FSF style objectives, in that they are not opposed to people getting paid for their efforts, but that binary only distribution and restrictive licencing are bad in a variety of ways.
If we consider a company like Oracle, which seems antithetical to open source principles on many levels, it would be possible to treat them as an open source debtor. Transactions between Oracle and open source economy participants would incur a tax, making their products less competitive with others, until they started contributing or bought open source offset credits. This provides the dual benefits of funding open source and penalising non-sharing. Things that really cost companies nothing, like publishing their Android patches, become valuable, and keeping them private becomes a cost.
I used to only donate in BTC. It reduced fees and promoted the use of BTC as a currency. Unfortunately that's not longer the case. Fees have increased significantly and complexity has increased, reducing the number of non-profits that accept it.
IIRC, FUSE is also required for VeraCrypt to function. So now the source code of this library (module? whatever) that's used by popular encryption software won't be available for public scrutiny. Amazing.
The author is, of course, completely within their rights to stop publishing the source code of their software, but this is a real pity.
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't know who (if anyone) will step up and take responsibility.
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.
You make it sound like there's a tonne of FOSS community on-hand just waiting for the chance to step in and create a popular fork that will lead to fragmentation, when he's effectively been the sole maintainer since 2012 [1].
It's far more likely there will no future well maintained OSS forks, he'll continue developing it as a closed-source product, allowing end-users to install it for free but any company who wants access to his future source code and improvements can compensate him for it. This is a far better outcome than it turning it into abandonware where that will stop working in future macOS versions.
> software won't be available for public scrutiny.
It's a popular cliche to think all OSS projects have healthy development communities and many eyes pouring over it, but as he's the only person contributing fixes, the only way the product was going to improve is if he spends more time working on it which is more likely to happen if he can get sponsored to continue working on it.
None of your fears are likely to come to pass and the health of the project would be far worse off if he abandoned it.
1. I'm sorry if I make it sound like that, definitely not my intention. I recognize that there's a serious lack of volunteers and contributors in the FOSS ecosystem.
2. When it comes to FOSS encryption software, it is important that it's audited every-so-often. Relying on closed-source frameworks makes that impossible. All FOSS software may not be scrutinized, but it's a definite advantage that it can be, when the need arises.
So, so many of the use-cases for osxfuse/macfuse involve people using sshfs to mount SFTP-capable logins into the Finder.
All of this could be very simply avoided if Apple just made SFTP a supported protocol under "Connect to Server".
I've asked/wished/pleaded for this since 2005.
It's one of those Apple deficiencies that makes you wonder just how do people at apple get work done if they don't have this feature ? It'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 ?
> 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
> Deploying a kext requires it be signed using a special Kernel Extension Signing Certificate, which can only be acquired from Apple
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.
Kernel extensions are bloody dangerous and I'm happy with Apple putting additional scrutiny on them.
Yep. Same with Windows; you get a big red screen and warning message when checks are disabled. You have to be able to do this in order to develop custom drivers and kernel extensions.
One the one hand, it makes it difficult for regular users to install malicious root-kits, but it also limits all wide scale adoption of FOSS tech like this at the pure whims and discretion of Apple.
That's a difficult question because it might limit supply of open machines for users who want the freedom to hack their own stuff. I think it's okay to offer computers that are basically Facebook appliances, but there should always be a toggle somewhere that allows people who know what they're doing to do whatever they please.
Macs do have such a toggle. You can boot from the recovery partition, launch the terminal and issue the `csrutil disable` command.
This will turn off all the security features that have been added over the years, including the “Catalina Vista” prompts people were complaining about in September.
The reason this requires booting from the recovery partition is to make it impossible for malware to flip the switch and to make it convoluted enough that even the most gullible of users will question their actions when pushed to do these steps by malware.
(Apple has stated publicly and in very clear language that they fully intend for the Mac to continue to be able to run unsigned code, so I believe this toggle isn’t temporary)
> This will turn off all the security features that have been added over the years, including the “Catalina Vista” prompts people were complaining about in September.
I installed it back in June, so my memory might be a bit hazy, but as far as I’m aware SIP doesn’t control TCC.
I'm surprised it doesn't say anything about security concerns with depending on a single individual to develop a kernel module without any ability to audit the code.
Well, I'd be surprised if companies like Dropbox and Google didn't audit it. And if it is used as much the article says, it would also be a decent target for security researchers, if for no other reason than they could send a bounty request to the big companies that rely on it.
Dropbox doesn't use FUSE -- in large part because I was terrified of adopting 60k LoC in the kernel (from FUSE) that we weren't experts on versus 1k LoC that we actually needed (and had audited by third parties).
Not relevant but it's funny that the maintainer of osxfuse has the name Fleischer and is discussing on github with Metzger. Both are german words for "butcher".
(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.
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.
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.
> Apple makes it very difficult to use 3rd party kernel modules. That is the whole thing. The open source thing is a complete red herring
I would argue that the Apple part is the red herring. It’s boring; it’s common knowledge that they don’t particularly like kernel extensions and it’s somewhat difficult to develop them.
> 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.
think of it this way - like all the other companies, he's maintained his own private fork of the open source osxfuse code. his happens to work on catalina, and he's telling those companies that if their forks do not, he's willing to sell them access to his code.
Is there any copyright/licence specialist here? I'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/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 "f## off" 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'm asking here is whether this would be possible to do so and enforce in a court or a legal dispute.
[0] or otherwise inacceptable in corporate environment
[1] I'm assuming that this would also be acceptable for the derivative projects: end-users might find that acceptable while businesses would not.
> with a clause that forbids removing/disabling that message
This sounds similar to the "invariant sections" clause of the GNU Free Documentation License; except you're talking about software instead of documentation.
> I assume that many developers or end-users[1] at home are perfectly fine with a messagebox popping up once a month with a "f## off" message
>Some people are really angry about GNU Parallel's citation "nag
the way I understand this, is that by requiring to interactively enter "will cite" the ability to run it as part of a larger script is broken. This would break a cron-job as well. The non-interactive nag in output would not cause such probles.
The non-interactive message in output of course could create problems on its own - especially if the nag would or would not display randomly. If someone intends to parse the output, this would require additional code to discard the nag. If the nag would sometimes display and sometimes not, this could randomly break stuff - if there was no nag during tests someone could not notice that they need to discard it.
But there are non-intrusive ways to insert some offensive message - they could be put to syslog, or a file with an offensive name/content would be created. My general idea is not to nag the users per se but do something that does not cause actual inconvenience for the user but is unacceptable in corporate environment.
For a GUI app a simple message box appearing once a month would not cause a major problem or hurt productivity of the end-user but I assume that for example Apple or Google would not find it acceptable for their software to display "f-off" even if this was rare.
For non-interactive/non-GUI software other ways to inject that message would be needed. For instance, a http server could inject additional X-F-Off header or a daemon could require env variable ICONSUMEFECES set to "daily"
Dual licensing is fairly common. Then there's also nag messages that asks the user to pay. Then there's also "free for personal use".
The thing is though, that people don't pay unless they have to. In my experience nag screens are not that effective, but adding profanity might make it more effective :P If you make it "I CAN'T AFFORD TO PAY $10 FOR THIS SOFTWARE" or something, businesses will want to get rid of it.
If you're an open-source maintainer and either don'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's best to either use a strong copy left license like the (A/L)GPL (only use LGPL for libraries, never anything else), or just stay closed source.
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.
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 your code, you should be profiting too.
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.
Developers abandoning Apple should be the taste of their own medicine for them.
The FUSE maintainer (and this article) implies that kernel driver signing certificates are so difficult to get that forking is not realistic, even without considering the technical issues.
I don't know if that is true, but if it is, then that is a certainly due to Apple policies.
It's also interesting to contrast with Linux FUSE, which to my knowledge has never been associated with any maintainer drama.
Doesn't matter. Apple is a gatekeeper, and that was exactly my point. They cultivate such kind of approach, and maintainer becoming a gatekeeper simply mirrors their own attitude.
It was BSD-licensed the whole time, so it's not like you're entitled to an "open-source" application at all. Pay the guy, or use free software so this doesn't happen.
> I will never ask end users for financial support. FUSE will always be free. However, what I'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't think that is unreasonable.
Sounds like he should have released it under GPL type of licensing.
I'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't happen now.
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.
It's API is not very clear, but it does seem to have roughly equivalent functionality to FUSE. The only obvious restriction is that there must be a physical file on disk rather than doing everything in-memory.
The restriction is that the FileProvider api is only used by desktop applications for user files. You can’t for instance run the application itself from there.
If he made a software that is making companies using it millions, and he still doesn'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.
Here neither big companies nor the sole maintainer is breaching any license clause.
If anyone want to get the project mainstream, just find and fork the last open-source code version available, fork it and contribute/maintain/re-license as needed use case.
another options is to, hire/contract the sole maintainer to develop needed feature of current version.
This is a very sucky situation to be in, and I've been on both sides of it.
I wrote KSCrash [1] a decade ago, and it's become the de-facto standard for crash handling in the Apple ecosystem. I didn't intend for this to happen; I just wanted crash handling MY way. But it'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.
Musashi [2] is a smaller example. It's an emulator, so it doesn'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't mind so much with this one because, as I said, it's pretty low maintenance.
Today, my latest itch is efficient and human-accessible data communications, and so I'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'll probably not see any donations or thanks from those who benefit the most.
Please don't take this as complaining. I'm still going to develop and support my babies, because I'm not doing this for the money; I'm doing it to better the state of computing systems (mostly for my own sanity). However, because I'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'm running at 1/4 my usual velocity when I require separate employment. For bigger projects that turns a 1 year project into 4 years.
However, from a company perspective I also understand. Giving donations is actually a big pain in the ass, especially if it'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's a tricky situation...
Dual licensing is your friend. Look at QT for an example of a company that has managed to generate decent revenue while maintaining a popular open source project.
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.
It saved me some headaches from bundling an installer for macFUSE or Dokan's blue screens in the past. There are server implementations and also FUSE wrappers on GitHub. It's not perfect but worth a try. And it'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?
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'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't have certificate to sign it?
You'd be forking 2 year old code, he hasn't updated the repo in the last 2 years, knowing that the next OS release would leave commercial users at his mercy. Apple also doesn't just hand out kernel extension signing certificates to everyone that signs up for a developer account, you'd have to be someone with some reputation.
It was a well-executed fake punt, he'll get people to pay; Catalina is out now and if you want to pick it up from the fork it would take a long time to get it right. That said, I would imagine organizations like Google will make the effort after paying the toll this time because the price will only go up.
It all sounds clever but obviously Catalina was not released yesterday, it was released some time ago and if a companies software required changes for Catalina they should have noticed many months ago while testing on the beta releases.
Problem is that the 2017 version, the last version that's open source, won't run on Catalina (or Mojave or High Sierra for that matter). The amount of fixes and compatibility patches that the author did is quite extensive. Replicating his work would be quite an undertaking and wouldn't be trivial.
Let's all wait for BSD license apologists to insist true freedom is the freedom to blackmail your users.
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.
Maybe this comment is too slashdot 2006 era, but still, licenses matter.
> Let's all wait for BSD license apologists to insist true freedom is the freedom to blackmail your users.
You assume that the author would have continued working on it if the code was GPLed. If you look at the list of contributors, you'll notice there's only 4 people (besides him) who have contributed any code [1]. That means that had he not continued working on it, the project would have died long ago. GPL doesn't somehow make code write itself. Unless there are incentives for programmers, all projects can perish regardless of what license they use.
In this case, you could also argue that the sole reason why OSXFuse still exists and is being updated is because it's BSD and the author continued releasing it because it was a binary-only release.
Correct me if I'm misinformed, but I don't see your point? The original author of code is always free to stop publishing their software as FOSS, regardless of which license they use, as long as they don't try and stop the re-distribution and forking of existing FOSS releases?
In this case the original author was an employee of Google and is not the current maintainer.
Google then released their implementation under the BSD. It was forked and worked on, and eventually it now comes to the maintainer. Had GPL been used at any point the current maintainer would not own full copyright and thus not have legal grounds to distribute binaries without source.
Original authors can only unilaterally change licenses if they were the sole authors, or with agreement of all other authors. Or with copyright assignment contracts as you see in GNU projects.
My comment is also not about the maintainer. My comment is about how BSD as a license is often framed as an equivalent choice to GPL or other copyleft licenses.
Years ago this was a topic hackers cared a lot about. Not so much anymore I imagine, but there was indeed a time when hackers cared if their software was open source/copyleft or BSD. Most of the online chatter was hypothetical, today it is practical.
> My comment is also not about the maintainer. My comment is about how BSD as a license is often framed as an equivalent choice to GPL or other copyleft licenses.
Are they really? But they're clearly not the same. Both are "open" licenses, but one is permissive, and the other is strong copyleft. The intentions behind them are quite different, and I don't see how anyone could read them and not understand this.
Still, I don't appreciate the aspersions I see being cast in this thread towards application of the BSD license. When I release OSS, I prefer to do so under MIT license - because I just want to put it out there for people to use, should it prove useful to them. I don't expect anything in return for it, nor do I wish to place restrictions on its use. Why should I be crucified for selecting a license that accurately reflects my intentions?
I think copyright makes it more complicated than that. If more than one person has ever contributed to the codebase (and if there's not some explicit copyright assignment), then under copyleft licenses no one person would be allowed to distribute anything containing anyone else's copyrighted code without also making the source available. (Perhaps technically it is the case that that's not "allowed" even in the case of a single copyright owner, but then you'd only have to worry about being sued by yourself?)
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.
Did we read the same article? Seems like Apple has been happy for this guy to have a signing certificate for his kernel extension for years. And he has been using it, and everything has been fine. Now the guy decides (not unreasonably, IMO, though it clearly impacts a lot of people who're used to getting the benefit of his efforts for free) that he wants to make some money... and the conclusion is "fuck Apple"?
Well, they allow one blessed developer to have a cert, only for historical reasons, leading to exactly this situation. That doesn’t seem like something to cheer about to me. Like it said in the article, a fork is impossible because they won’t get a cert.
Also, my complaint is mostly that apple keeps changing their API’s, as you can also read in the article.
All together this kind of stuff makes life needlessly hard on third party developers, so yeah, fuck apple.
Uh no. There’s nothing that says Apple only allows 1 kext developer. The article only says that getting the dev cert is such a significant pain in the ass that only one has ever gone through the effort. Anyone motivated enough to fork MacFuse can apply.
On a tangent: wouldn’t it be nice if all packages were signed? It would do the community a great service if an organization like Brew negotiated an agreement and implementation with Apple (and something that no one could unilaterally retract).
> The article only says that getting the dev cert is such a significant pain in the ass that only one has ever gone through the effort. Anyone motivated enough to fork MacFuse can apply.
I've been there. It's not just "a royal pain".
I implemented a clean-room Xbox One controller kext to expose it as HID Class gamepad in macOS some years ago†. I paid the Apple dev license on my own dime, and applied multiple times for the dev cert to be upgraded to kext dev. I was rejected each time, the answers each time being entirely tone deaf. Apparently I'm not notable enough, not commercial enough, not big company enough to get either a kext dev cert or an exception in the kext whitelist as others did.
The discussion on GitHub strongly implies that it's more than effort, and that random people don't just get certificates regardless of effort, because Apple is being cagey and reluctant to issue them even to large and prominent companies. I wonder what the specifics of that are...
Well, compromising a kext would be a significant 0wn and quite difficult to explain away.
I can see how Apple would be cagey and reluctant: although it’s technically feasible to revoke compromised publishers imagine the hysteria “OMG Apple kernel got 0wnd!”, “Apple kernel phones home to spy your extensions!”, “Apple can remotely brick your Mac with key revocation!”
It’s bull of course...
... I guess FUSE is one kernel service Apple should just provide out of the box
It's far from impossible, or I wouldn't have to try to figure out which developer accounted for which kexts and whether I should just remove them instead of granting permissions for something like twenty developers when I upgraded to macOS Catalina.
apple kept changing/breaking Api’s to try to kill vlc so that they could try make money of the paid version of the QuickTime player which then existed.
I must admit it was just comments made by VLC devs, so it’s anecdotal.
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 not 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:
> Then drop it and let someone else maintain it.
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.
Rather than "taking [his] marbles and going home" isn't it more like he's exercising his right to finally get paid after working for free for the benefit of others (including, presumably, many commercial users who aren't kicking in a cent) for a very long time?
How is "...then stop" different from "Taking your marbles and going home"? They didn't remove previously-published source code. So you can use the last open release in both scenarios, and the license change only adds the option of getting the maintained version under a commercial license.
The commercial version probably isn't useful in many scenarios, but by the simple rules of logic, having any additional option(s) can never be worse than having fewer options.
It is, however, somewhat shady to implement this license change without announcing it. Indeed I seem to remember being quite confused by this recently. I also just don't understand why that tactic was chosen? If you want to sell software, it tends not to hurt to make people aware of options to give you money.
It's not childish. That's the main problem with open source as a whole: devs expect somebody else to maintain projects indefinitely long, for free. This is what's unsustainable.
As discussed in https://news.ycombinator.com/item?id=20174418, with comments from devs represented in that "Software below poverty line" article, the interpretation from the article is seriously flawed.
He'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]:
> I will never ask end users for financial support. FUSE will always be free. However, what I'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't think that is unreasonable.
So he'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.
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/development of it, which anyone is free to do by creating and maintaining a fork.
[1] https://github.com/osxfuse/osxfuse/graphs/contributors
[2] https://github.com/osxfuse/osxfuse/issues/590#issuecomment-5...
[3] https://github.com/osxfuse/osxfuse/issues/590#issuecomment-5...