Open source software projects and other collaborative communities are built on the principle that information should be shared and remixed. Some of these projects have grown to have widely recognized names and logos. But collaborative communities that wish to have legal protections for their name or logo face a difficult challenge: trademark law expects some degree of restriction (or “quality control”), whereas collaborative communities expect their work to be free for anyone to use.
This has historically been a challenge for various projects. The Linux community had several controversies around their trademark. The Mozilla community had a disagreement with the Debian community over what sort of trademark restrictions were appropriate for a free software project. And a similar issue recently came up in a dispute over whether a community that works on legal and technology problems needs a trademark registration for the mark “Legal Hackers.”
Why do trademarks matter for collaborative communities?
The identity of a collaborative project is valuable. Trademark law may strengthen that identity by providing a legal right to:
Keep the project distinct so that a community can recruit new members and build a strong reputation.
Prevent other projects from using their name and logo in confusing ways.
Prevent an imposter from offering incompatible, insecure, or malicious software that is confusing to users.
Fight cyber squatters (an unfortunate problem for any popular domain) and phishing sites that pretend to be the collaborative project to steal users’ login information.
But not all names and logos are eligible for trademark protection. For example, generic terms for a particular type of project or names that are confusingly similar to pre-existing marks can usually not be trademarked.
Why are trademarks challenging for collaborative communities?
The main issue for collaborative communities is that trademark law expects some degree of quality control. Collaborative principles, on the other hand, usually expect information to be free to share and remix without any restriction. This conflict is a “bug” in trademark law that became apparent when collaborative communities found a way to produce goods and services through unconventional and decentralized systems.
The quality control requirement in trademark law is rooted in the notion that a trademark represents the source of a good. It allows users to rely on the trademark as a symbol for the source without the need to do further research. In FreecycleSunnyvale v. The Freecycle Network, the Ninth Circuit held that allowing others to use a trademark without proper control over how the trademark is used can result in naked licensing, a form of involuntary trademark abandonment. So if a collaborative community wants trademark protection over its name and logo, there needs to be some form of restriction over how community members and others can use those trademarks.
The community also needs to designate a holder of the trademark, which cannot be held jointly by a decentralized and fluid community. The holder of the mark in turn needs to ensure that the trademark is managed consistent with the community’s values. Being overly restrictive may be contrary to the values that make collaboration possible.
What's the solution?
Collaborative communities have come up with a few different “hacks” to mitigate the bug in trademark law. However, there are no complete solutions and the hacks may have to be used in parallel depending on the needs of a community. Here are some things that communities may think about:
Is the project ready for trademark registration? New projects could start with general principles about how to govern their identity, and then consider registering their trademarks once the project is old enough to make that decision.
Who holds the mark? Projects have sometimes had difficulties when individuals or companies hold trademarks on behalf of a community. Some projects are big enough to have a dedicated nonprofit, like the Python Software Foundation. Others have turned to an umbrella organization, such as the Software Freedom Conservancy.
What type of trademark? Some projects have maintained an unregistered mascot, such as the Tux penguin, to accompany their protected trademark. Another option is to register a collective membership mark, which requires less quality control.
What type of restrictions to put in place? Trademark holders can identify the good uses that the community wishes to encourage and the damaging uses that the community members should avoid (and often already do).
How to design the trademark restrictions? The trademark holder should ensure that any trademark processes are effortless for the community. It may help to decide the trademark restrictions through a process that is consistent with the community’s usual decision-making systems, such as email discussions or requests for comments. Another potential solution is a “public license” style trademark policy, similar to how the Creative Commons license “hacks” copyright law.
These are just a few considerations that collaborative communities have hacked around. They may not completely address the problem of protecting an identity while empowering maximum sharing and remixing. A hack is ultimately a temporary stopgap: trademark law might require a more holistic patch to solve the bug in the trademark system.
By Stephen LaPorte and Yana Welinder. We discuss the above hacks, and more, with supporting examples from major open source and free culture projects in our forthcoming paper: Hacking Trademark Law for Collaborative Communities.