Quite a few people over the last few months have helpfully pointed out the name collisions in the OpenVox Puppet fork. If you didn’t recognize it, there’s also a VoIP/PBX provider called OpenVox. Surely that’s got to be a violation of some kind of law, right? Even Google gets it very wrong! See how our information is interleaved in this autogenerated profile? The profile Google shows on the right side of the page when you search for an entity it thinks it knows how to describe.

Hold up though. Not so fast because it’s not quite that simple. Lemme tell you a quick story about a name that I’m pretty familiar with: Bolt.

The Bolt story

In August of 2017, Puppet began work on a new project intended to be an agent-less orchestration tool for automating the manual work it takes to maintain your infrastructure. Sure, it started life as an Ansible competitor, but it grew to be pretty neat. For the first time, you could trivially and seamlessly interleave shell scripts and Puppet code and just push that configuration out to nodes in your infrastructure as needed.

Imagine my surprise when I visited the Slack booth at KubeCon the following year and saw their new application library called… none other than Bolt. It had gone through several name iterations, including Slapp which is my personal favorite, but Bolt is what they settled on. I asked if they knew about our tool and they nodded and brushed off my concerns. Obviously, I raised it to our Legal team and was surprised when they also brushed it off.

So then I started noticing all the things named Bolt.

Aaaaand I’m tired of typing out that list, so I’m just gonna stop at that.

What purpose does trademark serve?

Clearly there’s more to trademark enforcement than just the name itself. As it turns out, that’s only a small part of it. At this point, I’ll take a real quick aside to remind you that I’m an open source software nerd, not a lawyer. And I’m certainly not your lawyer so none of this is legal advice. In any case, the concept of trademark law isn’t really to give you an asset to own, it’s to protect consumers in the market from brand confusion. You’ll notice that none of those companies I listed are named Bolt and also do infrastructure orchestration.

A trademark is a word, phrase, or logo that identifies the source of goods or services. Trademark law protects a business’ commercial identity or brand by discouraging other businesses from adopting a name or logo that is “confusingly similar” to an existing trademark. The goal is to allow consumers to easily identify the producers of goods and services and avoid confusion.
– Wikipedia

There’s a commonly used rubric called the DuPont Factors which can help identify whether there is a probable infringement. The rubric has 13 criteria, but they boil down roughly to

  1. Similarity of the marks.
  2. Similarity of goods/services.
  3. Similarity of trade channels.

So that explains why we aren’t concerned with the fact that there’s a product out there named OpenVox but is in a totally unrelated industry. In other words, someone looking for an infrastructure management system isn’t likely to accidentally purchase a PBX system, even if the name is the same.

What about the filenames?

But there’s another point that comes up frequently that’s not quite as clear. That’s the name and paths of the executables and the configuration files and such within the OpenVox packages. At this point, they’re exactly the same as the original Puppet packages. In other words, to configure OpenVox, you edit the puppet.conf file and to run the agent you invoke puppet agent -t. We negotiated this point very heavily with Perforce in order to not cause community disruption.

There are a few non-legally-defensible reasons why Perforce might agree to this usage and a couple reasons that are legally defensible. First off, let’s look at why Perforce might be motivated to allow this usage. These are not reasons that would stand up in court, if it came to that, but are ways in which Perforce benefits from it.

  1. They get a little bit of free marketing. Every time someone types puppet agent -t they’re reminded of where OpenVox came from.
  2. If someone using the system were to be confused by the name, it would likely be to Perforce’s benefit. In other words, if someone trialled OpenVox and typed ‘puppet’ a whole bunch, there is a small chance that when they submit an order to their purchasing department that they might accidentally request a Puppet purchase. It would never go the other direction.
  3. If we had to change all the commands and paths today, then the ecosystem would be forced to write complex abstractions or explanations with every module, tool, tutorial, README, guide, etc. It’s more likely that they’d take the easy way out and choose one or the other, thereby fragmenting the ecosystem.

That last point deserves more explanation. OpenVox and Puppet by themselves aren’t terribly useful. Their value comes from the modules that enable the management of Apache, MySQL, SELinux, etc. So the modules and the tools that make building modules easier are of utmost importance. All these modules and tools and the documentation around them are currently written with the expectation of the existing paths.

If we changed these paths, then every single part of the ecosystem would have to account for the path change. It’s a comparatively high lift to abstract the name and paths out, whether it’s in code or docs, so it’s likely that most people will just choose a side and then search and replace ‘openvox’ for ‘puppet’. This is why Puppet modules and GitHub repos are all still in the puppetlabs namespace, for example.

There are two reasons why Perforce would be on the losing end of that schism. First is that Perforce is now attempting to sell something infinitely more expensive than its former price of free. Very few people creating and sharing free open source content would choose to support that ecosystem rather than the FOSS alternative. The second reason is that 96% of Puppet’s enterprise customers use Vox Pupuli modules and, for all practical purposes, 100% of them use Vox Pupuli’s dev tools since they’re vendored into the PDK. Vox Pupuli is obviously choosing to support OpenVox even if that has to be at the exclusion of Puppet itself.

There are also legally defensible reasons. Even if Perforce weren’t convinced by the reasons already stated, these would almost certainly lead to them losing a court case if it came to it.

  1. By the time that someone has researched, and purchased (or not), and downloaded, and installed, and configured the system, it’s highly unlikely that they would be confused about whether they were running Puppet or OpenVox. Remember that the goal of trademark laws are to protect against confusion in the market. Several of the DuPont factors look at trade channels and the difference between downloading an OSS tool and talking to Sales is quite stark. If this were the only point we had to go on, it probably would not be enough. But there are better defenses.
  2. Trademark is intended to protect a brand, not functionality. If something is used for functional purposes, then it cannot under the Functionality Doctrine be considered a trademark infringement. The canonical case here is Sega v. Accolade of 1992. Sega included a “Trademark Security System” which relied on the string “SEGA” to exist in a known memory address on a game cartridge. If the code were present, the game system would display a trademark notification and play the game. If it were not present, then the game wouldn’t play. Accolade added the code to their games and won the court case when Sega sued them for trademark infringement because the trademark was used for functionality.
  3. Command names and file paths are a functional interface to a piece of software. In other words, if a tool or system wants to integrate with Puppet, then it will often do so by configuring puppet.conf or running puppet commands. If we are to build a Puppet-compatible product, then it has to use the same command names and paths. Our industry is littered with examples of this going back for many decades. Think about how many MTAs install /usr/sbin/sendmail, for example. On my Mac, that’s provided by Postfix. The actual Sendmail company, now owned by my former employer Proofpoint, has had three decades to dispute that use and has not. Another example is MySQL, owned by what might be the most litigious company in existence (Oracle.) When MariahDB forked away, it was ten years before they bothered to replace the admin commands like mysqladmin and even today they ship symlinks so you can still run that command.

The path forward

We have no concerns about trademark infringement today. The OpenVox PBX system is in an entirely different industry and won’t be confused with the OpenVox configuration management system. Perforce and OpenVox are both incentivized for us to keep using the existing command names and paths. And even if they weren’t, there is significant legal precedence to defend our use.

With that said, it would benefit our own brand to have our own command names and paths. Over the next year or so, we have a roadmap to achieving this safely and with as little community disruption as possible. We will first build an integration acceptance test framework so that we can tell quickly when we screw it up. Then we’ll gradually start replacing commands and paths with our own versions while leaving symlinks in place so that integrations continue to work. Then finally, we’ll extract those symlinks into an optional openvox-puppet-compat package that will likely never go away.

In order to make Puppet extensions universal, we aren’t planning to ever change the internal file hierarchy that makes up the documented API. And if that ever does change, we’ll do it in cooperation with Perforce to retain compatibility.