Redis enforces its trademark against client libraries
After a decade of allowing third-party language-specific bindings to operate under the Redis name, Redis is altering the deal. Pray they do not alter it further.
Modern software is built by assembling programs out of building blocks. Software engineers call their personal building blocks their "stack."
When I got my first post-college job in 2008, most web stacks were open-source software. Each software application was written by volunteers and included free contributions from companies. Anyone could use or modify the software for free. But eventually companies discovered that the following is a lucrative business model:
Find free server software written by hobbyists.
Verify that the license permits unrestricted commercial use.
Build a business running that software for people as a platform.
Charge companies a huge markup for usage.
A classic example is Amazon’s RDS service. They host MySQL or PostgreSQL databases and charge their heaviest users millions of dollars per year. Amazon isn’t the only player in this game. Platform businesses were so lucrative that tons of related business models appeared. Some companies build their own free software and give it away, knowing that some fraction of people would still pay them for hosting. Some companies earned so much money from hosting that they bought the rights to the project from the initial owners. Some companies are just machines that convert venture capital money into a solution to some problem – with the assumption that a behemoth suffering from that problem will buy them eventually.
But now these companies have acquired a harder problem. Their server software is written in – usually – a single programming language. However their customers might use many different programming languages, or need to interact with it across a network. Each programming language needs its own API that can interact with the software.
Companies have a few options for managing this complexity. They could use a tool to automatically generate libraries from the same declarative specification. But in my experience, there's always something weird about the output of these tools. Some of it will be noticeably ugly, difficult to use, and poorly documented in at least some of the languages. At worst, it’s obviously crap written by a robot. Platform companies could also build all of the libraries in-house, and just accept that people will be mad at the companies for having non-idiomatic APIs. This is basically like interacting with a loud rude tourist.
But most companies choose the third option: wait for some nerd who knows each language to write their own binding and publish it as open-source software. They sometimes even link to the third-party libraries from their official documentation as the "recommended" approach. And why wouldn’t they? It’s evidence that their for-profit company is a Strong Supporter of Open-Source Software.
I've been this nerd! In 2010 I wanted to understand Git better. So I wrote a personal Github clone as a throwaway project. I wanted my service to have profile pictures. Supporting picture uploads can be a pain for hobby projects. So I wrote a Python wrapper for Gravatar. Gravatar allows developers to convert an email address into a link to the user's profile picture. They host the images. I read their documentation and wrote my own plugin. I uploaded my Python wrapper to PyPI (the main Python registry) under the name "gravatar", and then forgot about it. I even deleted the project code from my Github at some point, for reasons I don't even remember.
Apparently people still use my library. It was downloaded 820 times last month when I checked the weekend before publishing this newsletter. Not bad for 30 minutes of work!
But what happens if the company that owns the rights suddenly wants more control?
Redis is a popular in-memory data structure database. It was originally started by a software engineer with the handle antirez. But because Redis hosting was so lucrative, commercial project sponsorships bounced between a few companies and now it is owned by a company named Redis, Inc. You can read the gory details on Wikipedia if you’d like.
Anyways, Redis, Inc. has the same problem as mentioned above. Redis has an extensive API that must be accessible from popular programming languages.
Rust is one such language. Rust is a new systems programming language poised to become more important in the next few years, as the US Government starts trying to encourage their contractors to move away from C and C++ and towards more memory-safe languages. Rust is the most obvious direct replacement for those languages.
Anyways, the same thing happened with Redis’ Rust integration. An enterprising Rust programmer wanted to use Redis. He decided to make his own language-specific bindings, and published it under the name redis-rs. Flash forward about a decade, and he has not been involved in the maintenance of the library in quite some time. However, because he founded the project he got pulled into a discussion with Redis lawyers.
Future Crate Maintenance and Redis Inc. Relationship
However as it stands I got an email from the company currently controlling redis (Redis Inc.) which basically informs me that the present state of this library is not acceptable to them. I also had a 45 minute call with someone from there to walk me through their thinking. They offered some options but it basically comes down to these it seems:
Commercial buy-out and transfer to Redis Inc.
Renaming the package on crates.io where the name of the library constitutes a trademark violation in their mind
Continued continue maintenance under the governance of the Redis project.
As someone who is not very active with this crate any more, and historically has built it largely for my own uses I do not feel qualified in making a call here. However it's very clear to me from that call, that Redis has some increasing interest in client libraries. They have some customers now that want Rust support and they need to figure this out somehow. They also transferred the Python and Go client libraries to redis, not sure under which terms and they are trying to do this with the remaining ones of interest.
So to summarize, Redis, Inc. cannot force the project to cease-and-desist. However, they have a newfound interest in the quality of client libraries in their ecosystem, and they've decided that their best course of action is to exercise control over popular libraries that have their own name.
This tactic seems to work pretty well. The author of the thread notes that Python and Go client libraries have already had their ownership transferred to Redis, Inc. If you read more of the discussion thread, other maintainers are also keen on moving development to a new name and transferring registration of the redis-rs project to Redis, Inc.
And why wouldn't they? They're not Redis' employees. This is just their personal side project.
This isn't a trend yet. At the moment, companies seem perfectly happy with some nerds maintaining the language-specific bindings for their projects.
What does this mean for my little ol' Gravatar library? I have one advantage, which is that Gravatar’s API is trivial and the Python code can be trivially written without third-party dependencies. My library is just for people who are truly too lazy to even seek out the official documentation. I'm sure ::checks notes:: Automattic doesn't want to get involved in another public dispute over their trademark. Right? It’s clearly a liability for me to keep the project published, but I would also be happy to transfer control of the package to Gravatar/Automattic if they preferred. Plus then I’d get to write a cool newsletter article if they strongarmed me!