Slime sourcing: it’s to the letter of libre licenses, but it’s certainly not to the spirit. Let’s talk about a trend in free and open source software that makes me uncomfortable.
slime source (noun) 1. A project which is under an open (libre) license but which places restrictions on the official compiled binaries or usage in a commercial context through non-licensing means 2. A project which satisfies the requirements of being Free Software but which violates the spirit of Free Software.
slime sourcing (verb) 1. releasing a project under an open (libre) license, but creating restrictions on the use of freely provided binaries 2. hiding the source code of an open (libre) licensed project, using trademarks, or other means to attempt to curb users from distributing their own compiled binaries or using it in a commercial setting 3. Weasel-Wording your way into Commons Clause, e.g. through the program’s behavior
I first saw this anti-pattern in Free Software over in font-design land with the Birdfont project. Birdfont is a typeface/font editor for Windows, OSX, Linux — the big three — written in Vala. It’s an astoundingly capable program, but there’s… Some sticky bits to it. The source is available via GPLv3, but the author intentionally hides the source repository and pushes users to pay money. It in fact, goes so far as to tell the user that commercial use is prohibited: when you first start Birdfont, it asks you what your intent is. If you answer that you’re using this for commercial means, it informs you to go buy a license, and either makes you quit or answer that you’re not using it for commercial use.
It takes some wrangling, but you could take out the checks, add some of the features that aren’t public yourself, and run your own fork of Birdfont. But why create needless forks of projects when a happy medium can be found?
Another example of slime sourcing is Caddy. Caddy is a high-performance, Apache2 licensed, https-auto http/2 server written in Go. It’s a fantastic bit of software, and I was all set to use it until I noticed that they’re placing (artificially limited) restrictions on the compiled binaries that they’re putting out:
They’re totally free to do this, but it feels slimy (hence why I call it slime sourcing.) There’s implications here: That commercial use is outside the scope of the license that Caddy is licensed under (Apache2 makes no restrictions and explicitly allows commercial use of the software). Matt Holt — also author of the open source CSV parser library Papa Parse — makes the argument here that the whole concept of Free Software itself is a sham:
Today you will notice an addition to the Download page: a “Payment” section. Is Caddy no longer free software?
The truth is, it never was. There’s no such thing as free software. The question is, “Who pays the price?"
(correction: previously, I stated that Matt worked on Sublime Text; His previous work was on Papa Parse, a CSV parser, and I misinterpreted the use of “my” — my bad!)
Matt decided to push for commercial licensing of the Caddy server back in 2016. His argument revolves around the fact that there are bills to pay and mouths to feed. He’s not wrong: living costs money, and software needs living, breathing people to be developed. If software developed itself, we’d be in a vastly different world (one where I, and Matt, would be out of a job!)
When Matt made the choice to change up some more of the presentation, Hacker News got wind of it and there were some interesting comments made:
Wow, in the course of this HN thread I went from learning about Caddy, to deciding against using it. Definitely not cool to immediately threaten legal action almost instantly after forking. Definitely not cool to force a header. I’ll be sticking with nginx. [source]
A potential user just went from “I think this is useful to me” to walking away. Another commenter mentions the underhandedness of the change:
after examining the website more I feel the need to write another comment expressing how poorly this is being handled. The website is very misleading — on the download page, it now asks you to pick a license, and says that the “Personal” version is for only personal use and you need to pay for the commercial version. There’s no indication until you click through to the full pricing page that the open source version even exists. On that page, you have the same personal/commercial breakdown, also stating that the personal version is strictly for non-commercial use, but with a sidebar mentioning open source. It assumes you understand the Apache 2.0 license and makes no attempt to clarify that businesses can use the open source version.
The authors are also wasting no time in going after forks to complain about trademark infringement, so if you want to distribute your own patched Caddy builds you can expect to hear from their lawyers. Absolutely devoid of class. [source]
[ed. note: a fork, called Wedge, was threatened over using the name caddy in the source]
A third example comes from another project I nearly wanted to use: OnlyOffice. OnlyOffice is a very well built, commercially supported groupware suite that includes a desktop client that really could challenge the Microsoft suite in terms of features and usability.
Their cloud service can be had for $4/user/mo when bought for a year, but when you want the on-premise options, there’s some confusing options: There are enterprise licenses, development licenses, community licenses…
Their enterprise on-premise license is proprietary , but then you scroll down, you’ll see a tiny link (here, enlarged for detail) pointing to a binary distribution set of the GPL/AGPL3 sources. This isn’t on their “Download” page either, hiding it in a footnote of the enterprise pricing page.
OnlyOffice restricts the number of actively open documents (artificially) in its source-derived “Community” form to 20, though to their credit, that page links to their GitHub organization and includes a very convenient Docker script to get you going:
It’s not not-libre, though
Adding these sorts of restrictions doesn’t per se make it non-free software — the copyright owner is allowed to do whatever they want with their source, the user could in theory patch that out as they see fit or fork, and these sorts of practices are not unethical in the eyes of the Free Software Foundation; to quote What Is Free Software, Stallman writes:
Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”. We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do not mean the software is gratis.
Again, in the context of commercial use, Stallman has similar thoughts, through GPL Exceptions:
Selling exceptions means that the copyright holder of the code releases it to the public under a free software license, then lets customers pay for permission to use the same code under different terms, for instance allowing its inclusion in proprietary applications.
The three projects here: BirdFont, Caddy, and OnlyOffice, are well within their rights, both under their respective licenses and under the philosophy of the GNU project (in the case of BirdFont and OnlyOffice) to sell usage of the software: the source is available, freely distributable, and if someone was so inclined to, they may modify the software to their liking. That’s not what my complaint is about. It’s the deception and underhanded limitations that I take offense with. It’s the soft limitations, the extra-license limitations and social pressure against flexing your rights as a user that I take offense at. I believe that there should be an implication that someone should be able to run libre licensed, publicly open source software without fee should they put the work into making it work, as well as share those executables, packages, etc. under the same license.
Caddy discourages the distributing of builds of Caddy itself by locking the name behind a trademark: the README includes at the very bottom the text
The name “Caddy” is trademarked: The name of the software is “Caddy”, not “Caddy Server” or “CaddyServer”. Please call it “Caddy” or, if you wish to clarify, “the Caddy web server”. See brand guidelines. Caddy is a registered trademark of Light Code Labs, LLC.
The sources to Caddy are libre. The name is not, a practice allowed under the Apache license, which is the same reason that prompted the Debian project to rebrand Firefox as Iceweasel and the GNU project to hard fork Firefox and other Mozilla projects as icecat, GNUZilla, etc. This, in my opinion, makes software like Caddy slime sourced: you’re free to use it and compile it is there, but there’s an implied amount of work in order to distribute that which you’ve built from that source.
These are just modern examples. In the past, we had a rather famous example of XChat. XChat is an IRC client that was released under the terms of the GPL, but which required payment for use on Windows. Free-as-in-beer variants such as XChat-wdk (now HexChat) were regularly built and distributed, often refuting the claims from the XChat Developer that it was “simply too hard” to do the work for free — often with the maintainers of the free-beer variations offering to help, from what I understand.
While I agree that there needs to be a commercial space for free software, there are now connotations that cannot be avoided. The idea behind Libre Software is that because I have the source, and because the source is shared with me under a free license, I am free to use it as I wish (Stallman’s freedom zero clarifies this, and the OSI definition explicitly denote this). There exists a gap that has been filled with what I am beginning to call slime sourcing.
Again, let me be clear: I have no problem with Matt, OnlyOffice, or the maintainer of BirdFont wanting/needing to make their monthly rents and dues off commercial support of the software, even have features in a commercial variant that are only available in the paid variation (This is what the business calls Value Added features) so long as those added features don’t boil down to purely artificial limits such as user count. I don’t even mind them being a little stingy — Bills have to be paid — I just find it disingenuous to hide under the guise that only developers would run things from source, or place barriers in front of users simply because they’re building from source (such as is the case with BirdFont.)
De-sliming: It doesn’t have to be this way
These projects, as we’ve seen, are technically libre. They are licensed under libre licenses and are source-provided. In the case of Caddy, there have been restrictions placed outside the source and its license to keep you from using something commercially, and in the other two, the source itself, outside of the license, keeps you from using the software as you wish.
Projects like Caddy, OnlyOffice, and Birdfont should consider looking at the successes of others: ntop offers commercial support for users who need it. ActiveState has built their lifeblood off supporting Libre languages, including Python, Perl, and Go. Digium maintains Asterisk, the most popular bake-at-home VoIP solution. There are even other web servers that have picked up the same model! Nginx is libre, but the developer offers commercial support and training for a fee. Wordpress is the most deployed piece of Libre web software, as is one of its plugins, WooCommerce. Both rank in the #3 and #4 spots of BuiltWith’s ranking and provide a steady stream of income for the company that owns them, Automattic.
To put it another way: Don’t license your software as Libre and then weasel-word your way into the commons clause or worse, go full commons clause. Doing so is slime sourcing your software, and in the end, it limits your customer base and hurts the overall community.
If Asterisk required a commercial license above a certain number of active SIP sessions, nobody would use it. If Wordpress attempted what Caddy has, it wouldn’t surpass Ghost by a gigantic margin. It’s worth noting that Ghost is licensed under a permissive license, and makes no restrictions on using it from source, only noting that there is maintenance and upkeep that must be done to keep things running smooth. Ghost makes money from their support and hands-off solution.
If you’ve already slime sourced, reach out to your community and begin the process of de-sliming. Wear “We’re libre” as a badge of pride and hold true: show that the source is available, tell people what they get for ponying up money for your software, help people make an informed choice between running it themselves on their own, having a guiding hand, or letting you do all the hard work. Uphold the spirit of Freedom 0 and the OSI definition’s point 6 and don’t discriminate based on endeavor, be it business or personal, through purely software limitations in the libre source. Seek to make your software good enough that people want to pay for it and contribute back. It might make sense to offer a dual-licensed version for commercial entities or add an exception that allows the libre variant to load non-libre libraries that you produce and support commercially. I believe that doing so will extend the audience of your software beyond what it is today, as has been seen with products which were built in the open, such as Wordpress, Nginx, or even software such as QGIS, which suggests many different sources of commercial support.
There is money to be made in free software. The value comes in support and features that make sense at a larger, commercial scale. Truly successful free software gets into the hands of everyone — this is the story of Apache, Wordpress, and Nginx — and when the time comes that users need help, you’ll be the the most qualified to deliver the things that businesses need.