Let’s Get Away From Slime Sourcing

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:

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.