Trademarks for open collaboration

A panel session with four lawyers may not sound like it would make the best choice for sitting in on at the 2014 Linux Foundation Collaboration Summit, but it turned out to be one of the more interesting sessions I attended. Luis Villa, Yana Welinder, Pam Chestek, and Karen Copenhaver talked about trademarks, and specifically how they can be applied to open-source projects. All were coming at it from a practical perspective, with Villa and Welinder having just helped lead the Wikipedia community in defining a trademark policy, Chestek has designed a kind of boilerplate trademark policy that projects can use as a jumping off point for one of their own, while Copenhaver deals with trademarks frequently as part of her work as the Linux Foundation's counsel.

Villa is the chair of the licensing committee for the Open Source Initiative (OSI) as well as a general counsel for the Wikimedia Foundation. Welinder is also a legal counsel for Wikimedia. Chestek is a former Red Hat counsel, now in her own practice. As noted, Copenhaver is the general counsel for the Linux Foundation.

Background

The background was set by Villa, who said he would be explaining why trademark issues are interesting for lawyers, but painful for everyone else. The purpose of trademarks is fairly straightforward, but it runs directly counter to the ideas behind open source in some ways. Trademarks are all about controlling the quality of something by only allowing a name to be attached to it under certain conditions. But in the open-source world, users and others must be able to modify the software, so the trademark holder is going to have to give up some level of control.

A trademark is meant to tell consumers that there is one entity behind the product, for example only a single manufacturer that makes the good. But in open source, lots of people participate. For example, no one really controls "Linux", and there are various flavors of Linux available (e.g. Red Hat Linux or SUSE Linux).

It is this right to modify versus the requirement to control that causes problems for free-software projects with regard to trademarks, Villa said. For example, the Firefox trademark was being used to sell modified versions of the browser with adware and sometimes malware. Mozilla's efforts to stop those kinds of abuses caused problems for Linux distributions that wanted to modify Firefox in various ways (e.g. replace the file chooser with a native version). One more thing to keep in mind, Villa said, is that there is a difference between using a trademark to reference a product and using it to sell a product.

Because members of open-source communities often identify themselves using the trademarks (e.g. "I am Linux/GNOME/Wikipedia"), any kind of discussion of trademark "control" can get heated. It can feel like the lawyers are trying to wrest the community member's identity away from them. There are examples of that in nearly every open-source community that has grappled with trademarks, he said.

Wikipedia

With that, Villa turned things over to Welinder, who suggested that one way to solve this tension between the community and the legal side was through collaboration on the policy itself. If the community comes together to create a trademark policy for itself, it will not be an imposed policy but one that came about through agreement. Also, by getting as many eyes as possible on the drafts, bugs can be identified early on in the process, she said.

So, Wikipedia invited its entire community to help determine the policy for using the trademarks held by the Wikimedia Foundation. It took seven months and around 150 community members participated in the process. The first thing learned was that the community had no idea what was in the old (then, current) policy. It was a "wall of text" that was difficult to understand.

So the first step was to break up that wall and make the policy easier to understand. It took legal design, of course, but also usability design to do that. A summary of the policy in a one-page document was an important piece. It told users what they could do with the trademarks ("yes"), what they could do under certain circumstances by following some simple steps ("yes, but first"), and things that are not allowed ("sorry, no").

Beyond just the summary, other usability upgrades included some newly designed icons to help navigate the policy. In addition, interns went through the text to find overly long or complex sentences to target for simplification. Because it was a community document, it couldn't have things hidden in small print, which is something that lawyers often like to do, she said.

Areas that were unlikely to cause consumer confusion (cupcakes with the Wikipedia logo at a hackfest, for example) were explicitly allowed. For other uses, they designed a new trademark license that is short and simple. People just fill it out and send it in; they don't need to wait for permission or approval before using the marks. It makes trademark licensing much more streamlined, she said.

Model trademark guidelines

Chestek was next up. She has dealt with lots of projects that didn't have a trademark policy and realized that there isn't a common understanding about trademarks among FOSS projects. She was concerned that the legal industry would start defining those policies for projects, with potentially "disastrous outcomes" because FOSS is so unusual to courts and lawyers.

So, she has come up with the Model Trademark Guidelines as a tool for projects to use to come up with their own policy. Projects using it will, hopefully, "give the courts a push" in the direction that the FOSS community would like them to go.

To come up with the guidelines, Chestek looked at 30 to 40 projects' trademark policies. The referential (or nominative) use of trademarks was not generally an issue for projects. Many of the policies were concerned with other uses that would require a license or permission, in particular distributing modified versions of the software. So that is what she concentrated on in the model guidelines.

The guidelines are freely modifiable, she said, and are ready to be used by projects if they wish. CentOS is using them currently and is the only project to do so as of yet.

She pointed to the "Uses we consider non-infringing" section as an area that is unique to FOSS projects. The section outlines various uses that FOSS projects typically find to be reasonable, without requiring a license or permission. They represent kind of a "safe harbor" for users. It is not a settled area of the law, so the idea is to recognize these uses up front, so that a court would not determine that a potentially infringing use of the mark had been ignored. Trademark owners are required to take action when their marks are misused, so that section tries to set a boundary both for the users and so that the courts recognize certain uses are not being ignored, but are, instead, explicitly allowed.

A common activity with FOSS is one that gives lawyers fits: allowing distribution of the covered software under the mark after modifications have been made. In the proprietary world, lawyers hate trying to create licenses to allow that kind of behavior and the result is a thick stack of legalese. Should a trademark issue end up in court, it should be clear that the agreement requires a certain level of quality control over the modifications, but that doesn't fit too well with some open-source projects.

There are some existing FOSS project policies that address this. For example, the LibreOffice policy allows changing the "skin" of the office suite while still calling it LibreOffice. There may be other kinds of similar requirements that show the project is exercising a level of quality control over its downstreams. There is still some concern that the courts won't agree with that approach, but it is the line she tries to walk in the model. "Hey, I don't know who you are, but you're making my product" is a statement that is "stomach-churning" for lawyers, she said.

In the end, the guidelines reflect her opinion on various matters as she is the author of it and most of the commentary and legal background pages that go along with it. For example, she believes that unmodified distribution of the software by others does not require a license to use the trademarks, but others may disagree. The site is a wiki, and she is quite interested in contributions, particularly from lawyers in non-US jurisdictions.

Summing up

Copenhaver then summed things up by saying that trademarks are going to become more important in the open-source world over time. There are more corporate-run projects whose owners want them to become open-source projects; trademarks are going to cause the most heartburn. Having thoughtful policies about trademarks will show the companies that we are speaking their language, that our policies show a more reasonable approach to trademarks in our space.

Trademarks are one of a project's most valuable assets, she said. They govern how the project is perceived in the world. But trademarks also give a project a way to enforce certain standards. For example, there were multiple companies offering Firefox "licenses" for $200, she said, and the only way that Mozilla could deal with that was via its trademark.

It will be important to courts to see that projects honor the requirements of trademark law because registering a trademark means that one must take on certain responsibilities. One of those is to enforce the trademark against those who are infringing on it; if you don't do that, you can't enforce it against anyone. By defining what we consider to be infringing uses, as Chestek has done, it gives the courts a model to follow.

The law always lags technology by 20-25 years, she said. It took 27 years to test the shrink-wrap license issue, but the industry functioned just fine in that time. Judges tend to honor the way things have been done, so if open-source projects have a general framework for how they handle trademarks, they will be in a better position than if projects are "all over the map" with respect to trademarks.

Q & A

All four then sat down, "panel style", to answer audience questions. As part of that, the idea of a FAQ to accompany a project's trademark policy came up. Most were in favor of creating a document like that to help inform the good players (as the bad players are unlikely to read, or heed, any document), but there were some caveats. Villa noted that FAQs (and accompanying documents, in general) tend to make lawyers uncomfortable since they aren't a part of the legal document. But Copenhaver said that a FAQ can provide good evidence of what the project considers "bad actors", which is most of what the trademark policies are meant to combat.

Enforcement was another topic. Copenhaver often deals with companies turning over trademarks to newly formed open-source projects, and they often expect that the level of enforcement of those trademarks will be high. But enforcement costs a lot of money and could easily eat the entire budget the company is allocating to the project. So, unless the company is willing to write an unlimited check, she recommends that a low, but consistent, level of enforcement be chosen. Inconsistency in enforcement is problematic, as is saying one thing about the mark, but doing something else. For example, many projects will look up all of the domain names related to the trademarks and want to start going after each infringer, but that can be incredibly expensive and swallow up the entire enforcement budget.

Villa said that he is not convinced that the case law for trademarks is as settled as is often portrayed, though other lawyers have literally suggested he be debarred for making such a heretical statement. Chestek agreed with Villa—"I have your back". She said that the trademark rulings that exist come out of the "single manufacturer model" that doesn't take the new collaborative approach into account. So far, the courts just haven't caught up with that change.

The least amount of policing that a trademark holder can get away with was the final question to the panel. Welinder said that identifying truly harmful uses and policing those should be enough. The project's policy should reflect the level of enforcement that it is willing to do, Copenhaver said; as long as it does what the policy says right from the beginning, not three years down the road, all should be well.

That led to some discussion of what happens when enforcement hasn't been done for some period of time. Chestek said that the holder needs to reestablish its rights, or switch away to a new brand. Given that rebranding is expensive, Villa said, it probably makes sense to "get back on the horse" and move forward with reestablishment. Chestek noted that when a trademark is lost, the most common cause is that the owner has caused the problem by genericizing the term, so projects should strive to avoid that.

Trademarks are tricky and sessions about the intersection of trademarks and free software are usually fairly interesting—this one was no exception. It is clear that there is quite a bit of thinking going on in the FOSS trademark space right now, so it was nice to see a status report on that work.

[ Thanks to the Linux Foundation for supporting my travel to the Collaboration Summit. ]