Trademarks for open-source projects

SCALE 14x featured a dedicated legal track requiring separate registration. While much of the content was aimed at lawyers working in open-source software or at companies investigating the legal aspects of open-source software for the first time, there were also sessions of interest to software developers. One such session was Pamela Chestek's Trademarks and FOSS: Entirely the Same and Entirely Different, which looked at how trademarks impact developers within an open-source project as well as those who are downstream users of the code.

Many in the community recognize Chestek either from her years at Red Hat or, more recently, for acting on behalf of the GNOME Foundation when it faced a trademark battle with the web service Groupon. While trademark law is well understood by many in the legal profession, she said, open-source projects have tended to ignore it—at least in comparison to their understanding of copyright and patent law.

Chestek opened up the session with a brief look at how trademark law functions. By definition, a trademark is a "symbolic representation of the sum of information about a product or service"—or what marketing calls "the brand." A key concept is that trademark traditionally points to a "unique single source" for a brand, but any particular usage of a trademark can signal a variety of different relationships.

For instance, the Apple logo on a MacBook designates Apple as the party that the laptop "comes from," even though multiple subcontractors actually built it. A software vendor that offers certification may allow independent contractors to advertise with its certification's trademarks, even though they are not employees. That usage designates more a "seal of approval" for the contractors. Trademarks can also be used in advertising relationships, such as "Volvo Fashion Week." That usage makes it clear that Volvo is sponsoring the event, Chestek said, and no one is likely to misunderstand and think that the carmaker is also producing clothing. The absence of misunderstanding is critical, she said: the only thing that the law prohibits is the usage of someone else's trademark in a way that causes confusion about the relationship being signaled.

Trademarks from a project's perspective

For open-source software, though, these principles create considerable tension. First, trademarks are often lumped together with copyrights and patents in the broad "intellectual property" pool, which is generally mistrusted by open-source projects. Second, trademark law's "unique single source" concept does not map well to open-source projects' distributed, ad-hoc membership and open participation model. Finally, trademark law in most jurisdictions comes from the manufacturing era of a century ago, and does not mesh easily with how open-source software is produced.

On the intellectual-property front, Chestek argued that, while almost all open-source developers find software patents "all bad" and copyrights to be a mixed bag (after all, copyright is what allows open-source licenses to function), trademarks should be seen as the "all good" piece of the puzzle. That is because most projects' primary or only trademark is the project name, and looking after the name is how the project protects its reputation.

Trademarks fit well with the "fandom" that many projects rely on to build a community and to turn users into contributors. They also enable projects to offer assurances that users know what they are getting from the software. A bad actor could insert malware into open-source code that it redistributes; while copyright would offer no recourse (as long as the license requirements are met), trademark law would let the project step in and shut down the malware redistributor. Mozilla has had to take such steps more than once in the past.

Regarding the "unique single source" doctrine of trademark law, some lawyers think that open-source development's "anyone can submit a patch" nature undermines trademarks, but Chestek disagrees. Yes, anyone can modify and redistribute code, she said, but it is not "the Wild, Wild West." In reality, projects operate in a systematic fashion. There is a canonical source for releases and there is an organizational structure. Furthermore, she said, many of the same issues (such as who in the organization determines what is allowable trademark usage) already arise in other endeavors—particularly not-for-profit ones. From volunteer work to church raffles to bands that split up and disagree about which member gets to use the old band name, the same issues that open-source projects encounter are regularly seen elsewhere.

Current trademark law in the US was rewritten in 1946, and the previous update was in 1908. In both eras, Chestek said, the assumption was that a product was a physical, manufactured good. But open-source software is built and distributed differently, which can be problematic. For instance, she noted that it is common practice for one project to intentionally choose a name that is similar to another project's, such as NHibernate, which is a .NET port of the Java-based Hibernate framework. That name communicates to the user about compatibility. Although common practice, she said, it is a strategy that projects will likely have to abandon if they grow—much as the Jenkins project had to change its name when it forked from Hudson. The main Hudson developers started the fork, but were told by Oracle that they could not use "Hudson" for its name.

Above all else, Chestek urged projects to register their trademarks—at the very least, in a major jurisdiction like the US or the EU, but wherever possible. There are two benefits. First, the registration forces project members to take a serious look at their structure and have the conversation about who owns what; that conversation can be more valuable than the legal filing it eventually produces. Second, registering a trademark is the key way to get the mark on the radar of anyone doing a trademark-clearance search. Most companies do want to create their own brand and identity in good faith, she said, but they generally do not know where to look for open-source software project names. If the names are registered as trademarks, however, they can be found.

Trademarks from a downstream perspective

Chestek then addressed several frequently asked questions about trademarks that arise for the users of open-source software, including downstream projects. The first question was whether there really is a "duty to enforce" a trademark. Such a duty is often claimed, she said: many cease-and-desist letters assert that the trademark holder has to enforce a trademark or lose it. But "there is actually no such thing," she said, "those words do not appear in the Trademark Act."

Rather, she explained, there is a continuum of trademark usage that could be seen as confusing, and a trademark holder has the right to enforce their trademark on a confusing usage. But only the bottom end of that continuum involves anything like "losing" a trademark, and that situation is when a court decides that a trademark has become so widely used that it has turned into a generic term for a product category. It is a rare occurrence, but not impossible: Chestek speculated that the "Linux" trademark runs the risk of becoming a generic term for a category of software. She wondered how many projects actually bother to apply for authorization from the Linux Mark Institute.

The second question was whether a trademark covers exact copies distributed downstream (that is, whether or not the trademark would have an infringement case if the downstream product used the trademark in, say, advertising). Unfortunately, the answer seems to vary depending on the jurisdiction (in the US, the trademark is likely extended to the copy, but it is likely not in the EU).

Whether a project's trademarks extend to downstream forks is a more interesting question. Chestek believes that the upstream trademark is not transferred to forks, so forks need to remove any usage of the mark. But even that has limits; in particular, she believes a project cannot demand that downstream forks remove its trademarks if doing so would functionally alter the program. The example she gave was a project using its name in function names, class names, and commands. If the command-line tools are FooBuild or FooRun, requiring users to change the names would impede script compatibility, and impair usage.

Nevertheless, she cautioned that there is no US case law on this topic, and others may disagree. For projects concerned about that uncertainty, she said they could always write their own trademark guidelines and offer to grant trademark licenses to downstream users; that would clarify the matter for users.

Chestek closed by recommending that projects explore writing a trademark policy, looking to the Model Trademark Guidelines and FOSSmarks sites for help. Trademarks are underrated and underfunded in open-source software, she said, but an open-source project's name is often its heart and soul, so it needs protection.