Open Source Communities and Trademarks: A Reprise

Intellectual property and how it is shared have been the cornerstone of open source. Although it is more common to discuss “code” or “copyright,” there are other IP concerns around patents and trademarks that must be considered before investing time and effort in a major open-source project. There are long-established practices that govern these matters. Companies and lawyers involved in open source have been working on and evolving open source project trademark matters for decades.

Neutral control of trademarks is a key prerequisite for open source projects that operate under open governance. When trademarks of an open source project are owned by a single company within a community, there is an imbalance of control.  The use of any trademark must be actively controlled by its owner or the owner will lose the right to control its use. The reservation of this exclusive right to exercise such control necessarily undermines the level playing field that is the basis for open governance. This is especially the case where the trademark is used in association with commercial products or solutions. 

Open source licenses enable anyone to fork the code and distribute and modify their own version. Trademarks, however, operate differently. Trademarks identify a specific source of the code. For example, we all know MariaDB is not the same as MySQL. They’ve each developed their own brand, albeit they’re derived from a common codebase. The key question is who decides when a company should be allowed to associate its product or solution with the brand of the community?

A trademark is a word, phrase or design that denotes a “brand” that distinguishes one source of product or solution from another. The USPTO describes the usage of trademarks “to identify and distinguish the goods/services of one seller or provider from those of others, and to indicate the source of the goods/services.” Under US trademark law you are not able to effectively separate ownership of a project mark from control of the underlying open source project. While some may create elaborate structures around this, at the end of the day an important principle to follow is that the project community should be in control of what happens to their brand, the trademark they collectively built up as their brand in parallel with building up the functionality of their code. 

For this reason, in communities that deem their brand important, we also file registrations for trademark protection to reserve the rights in the mark for the project, commonly in the United States, China, European Union, Japan, and other countries around the world. Registered marks will often have a ® symbol. This is different from a common law trademark right where you often see a ™ symbol with the mark. Having a registered trademark is often important because it enables us to better protect the community against misrepresentation, misuse, and confusion in the ecosystem between what is actually the community-built project, and what is not. This is often based on specific benefits that arise from the registration, which may vary from country to country.

The Linux Foundation started hosting projects outside of Linux a decade ago. From the outset, the brand of a project community we host has been an important asset that we have been asked to protect for our communities. The communities’ goals and motivations are always different, but, in general, the organization contributing a trademark usually wants to ensure it denotes the community they’re helping to establish at the LF, and the other participants in the ecosystem want the confidence that one company can’t tell them what they can or cannot do with a project we host because they retained ownership of the trademark.

This neutrality is the very essence of what we try to establish at the Linux Foundation with our projects. Our projects are set up to be neutral – the Linux Foundation or our project entities own the mark. We then put the control over decisions about the mark into the hands of our project communities, to be determined by them in an open and transparent manner to achieve their collective goals.

For example, in March of 2017, we participated in a meeting hosted at a KubeCon in Berlin, where the organizations involved in Kubernetes sat down in a packed room to discuss what they wanted to do with the Kubernetes brand as it related to companies using Kubernetes in conjunction with their commercial products or solutions. When drafting the governance for CNCF, Google had insisted it was important for the Linux Foundation to also own the Kubernetes mark as part of CNCF—so that branding control would go hand in hand with neutral, community-driven governance. 

However, the LF was not in a position to determine when one company should or should not be able to say their solution was a “Kubernetes”-based product. We needed a program to allow companies and other organizations to use the trademark commercially to denote their distribution or compatibility with the community’s Kubernetes releases. That initial group worked for months to define what it means to have a conformant Kubernetes distribution. That’s also why the promise of portability amongst cloud providers actually works today. Those technical experts from the community as a whole defined exactly what it would take to deliver on the promise of portability. And then the definition of conformance that they established has been backed up by the neutral ownership of the Kubernetes trademark, in the Linux Foundation. What’s even more important is that the community remains in control of the program. In fact, the definition of conformance is controlled by Kubernetes’s SIG Architecture and changes in a carefully controlled process in each release as new APIs become stable and obsolete ones are deprecated. 

This same story has played out in other communities we have hosted. We’ve had many communities build consensus around what it means to be compatible or conformant with the releases coming from our project communities. So many that we recently wrote an entire blog just about the topic.

What these examples show is that a community can neutrally manage a trademark within the LF’s structure. We tend to refer to these as “community-managed trademark” programs. The marks are owned by the LF entity for the project, and we work with the communities we serve to establish the rules around usage of our marks.

Recently there has been a new round of conversations about open source projects and ownership of trademarks. Understandably there has even been concern that open source hasn’t addressed issues of trademarks as it relates to major OSS projects. This is not the case. While the motivations vary, one aspect remains constant: trademark law. 

We’ve been asked, “can we have the LF manage our trademark too?” The answer is yes. Let us know what project you’re managing and we’re happy to help you understand what’s involved in setting up a community-managed trademark program for your project. To date, we have successfully done this for the most important open source projects in the world and projects that are the most important to a few people. We can probably help support you as well.