The full text of this Article may be found by clicking the PDF link on the right.
e are all surrounded by software and content that is developed by collaborative communities.1 Over a billion people today use Android mobile devices2 that incorporate the collaboratively developed Linux kernel.3 Millions of people use the Linux operating system on their desktop computers,4 often using Ubuntu5 or Red Hat6 distributions. Every fourth Internet user accesses the Internet via the collaboratively developed Firefox browser.7 And even those that don’t use an open source browser or device to access the Internet still use open source software online as 55% of all websites run Linux or BSD8 and 60.4% of all servers for websites run Apache.9 The most widely used Internet platforms, like Google, YouTube, Twitter, Facebook, and Flickr, all rely on the open source database server MySQL.10 Thirty-two percent of the top 100 blogs on the Internet use the collaboratively developed WordPress software.11 What’s more, the world’s largest online encyclopedia, Wikipedia—which regularly ranks in the top search results for a topic—provides articles and photos created by thousands of volunteers around the world and is built on the collaboratively developed MediaWiki software.12 The MediaWiki software is used by big entities such as Intel13 and the US government,14 as well as thousands of individual wikis online.15
All of these sites, platforms, and devices to some extent use software or content to which anyone can contribute. Contributors rely on the free licenses of that software or content to create derivative works without asking for permission.16 Given how freely contributors can share or remix a collaborative project’s code or content, one might expect that the name or logo that represents the project can be used just as freely under the same conditions. This can be a point of confusion and controversy in collaborative communities. One example is the dispute that arose between the Mozilla Foundation and the Debian developer community around 2004. The Mozilla Foundation, which led the collaborative development of the Firefox browser, prohibited the use of the “Firefox” mark in software that had not been approved by the Foundation.17 The Foundation likely imposed this requirement in an attempt to control the quality of products labeled with the Firefox brand as required by trademark law in order to retain trademark rights in the brand.18 Mozilla’s trademark allowed the Foundation to protect users from confusing products such as malicious code disguised as a Firefox browser and provided a unique identifier for the Mozilla developer community to organize around the Firefox project.19 But Debian developers claimed that the Mozilla restriction was incompatible with Debian’s Free Software Guidelines, and that Firefox could therefore not be included in the Debian operating system.20 After an unsuccessful attempt to reconcile their differences with a trademark license, Debian created an alternative to Firefox based on the Firefox codebase, which they antagonistically named “Iceweasel.”21 This was a lose-lose situation for both collaborative communities: Mozilla did not benefit from Debian users’ recognition of the Firefox branding, while Debian provided its users with what appeared to be an obscure web browser. As a result, users had to differentiate between two browsers that were functionally equivalent.22
The Firefox–Iceweasel dispute illustrates an important source of controversy within collaborative communities—members of a collaborative community tend to hold their logos and branding very dearly, and they want the mark to be protected from misuse by others who do not share the same ideals or goals. Trademark law can offer protection for logos and brandings, but it imposes duties on the trademark’s owner.23 These duties may be inconsistent with the practices of most collaborative communities, which depend on a sharing ethos, decentralized decision-making, and a sense of joint ownership over the project.24 Over the years, collaborative communities have come up with different solutions to reconcile the conflict between trademark law and collaborative culture, but these solutions have been developed on an ad hoc basis, sometimes without a thorough analysis of existing solutions or an examination of other possibilities offered by trademark law.25
This Article seeks to clarify the problem of applying trademark law to the work of collaborative communities and offers a taxonomy of solutions that collaborative communities have developed to address this problem. Part I begins by discussing the requirements under trademark law and exploring the problems caused by the requirements for centralized control and licensing standards. It then uses Yochai Benkler’s model of commons-based peer production to introduce collaborative communities, their governance and structure, and their values. It examines why collaborative communities need trademark law for their operations and poses the conflict between the legal requirement for quality control and the values of decentralization and non-hierarchical structure held by collaborative communities.
Part II looks at different solutions that have been developed by collaborative communities over the years and categorizes these solutions into a taxonomy. We refer to these solutions as “hacks” to the trademark system,26 analogizing to the process of writing pieces of software to fill a gap or add a functionality to an existing program. The first category of hacks focuses on how trademarks are held for a collaborative community under trademark law, which does not recognize the community as a legal holder of a mark. The second category of hacks discusses the types of trademarks that can be held on behalf of a community. The third category discusses what restrictions are appropriate for marks that represent the work of collaborative communities. The hacks in the final category deal with designing trademark restrictions in a community-friendly manner. This category includes developing a public trademark licensing model and a proposed policy, which is illustrated with the Collaborative Mark Policy (CollabMark) in the Appendix.
Finally, Part III introduces an assessment of the different solutions. It identifies a number of elements that may be important to consider when deciding whether or not to adopt any of the solutions for any particular collaborative community. Broadly, this Article seeks to map out an application of trademark law that has been largely unexplored in academic writing. The taxonomy is intended to provide a foundation for continued debate on how to best protect the work of collaborative communities, particularly as collaborative work is gaining more significance in our information economy. Some of these hacks may not actually resolve the conflict between trademark law and collaborative culture. Some may only offer limited help when combined with other hacks and only for a subset of collaborative communities. Most of them have never been tried in court and so may hold some legal risk. As with many other types of hacks, the trademark hacks outlined in this Article may ultimately need to be replaced by code that provides a more holistic patch to the identified “bug”27 in the trademark system. The holistic solution may be legal reform or some sort of technology that provides the desired brand recognition without unnecessarily burdening contributors who want to promote the projects on which they work.28
* Yana Welinder is Senior Legal Counsel, Wikimedia Foundation; Non-Resident Fellow, Stanford Center for Internet and Society; LL.M., Harvard Law School; J.D., University of Southern California; LL.B., London School of Economics and Political Science.
**Stephen LaPorte is Legal Counsel, Wikimedia Foundation; J.D., University of California, Hastings College of the Law.
The views expressed in this Article do not necessarily reflect the views of our employers or any other organization. We would like to thank Shaila Nathu and Jessica Tam for their excellent research assistance. We also would like to thank BJ Ard, Thomas Barton, Andrea Rush, Joanna Sax, Luis Villa, participants at the NYU 2nd Thematic Conference on Knowledge Commons, the 2014 Works-In-Progress Intellectual Property Conference at Santa Clara University School of Law, and the staff and affiliates at the Stanford Center for Internet and Society for their feedback on this research. Finally, we would like to thank the Wikimedia community for the inspiration and for their strong commitment to ensuring trademark practices fit collaborative values.
See Yochai Benkler, The Wealth of Networks 64 (2006), available at http://www.benkler.org/Benkler_Wealth_Of_Networks.pdf [http://perma.cc/JSA5-XMAG].↩
See Justin Kahn, Google shows off new version of Android, announces 1 billion active monthly users, Techspot (June 25, 2014, 1:00 PM), http://www.techspot.com/news/57228-google-shows-off-new-version-of-android-announces-1-billion-active-monthly-users.html [http://perma.cc/964H-JSGH].↩
See Jerry Hildenbrand, Ask AC: Is Android Linux?, Androidcentral (Nov. 8, 2012, 6:57 PM), http://www.androidcentral.com/ask-ac-android-linux [http://perma.cc/P68U-X6MD].↩
See Joey-Elijah Sneddon, At $200 to $400, Are Ubuntu Phones Priced for Success?, OMG!ubuntu (Mar. 12, 2014), http://www.omgubuntu.co.uk/2014/03/ubuntu-phones-priced-at-200-400-dollars [http://perma.cc/PX79-NA9T].↩
See Drew Robb, Linux Desktop Comparison: Red Hat, Novell, Ubuntu, Fedora, Datamation (Jan. 14, 2010), http://www.datamation.com/osrc/article.php/3858611/Linux-Desktop-Comparison-Red-Hat-Novell-Ubuntu-Fedora.htm [http://perma.cc/PLP4-9GVB].↩
Browser Statistics, w3schools.com, http://www.w3schools.com/browsers/browsers_stats.asp [http://perma.cc/H5KN-3ZZS] (last visited July 27, 2014).↩
See Usage Statistics and Market Share of Unix for websites, W3Techs, http://w3techs.com/technologies/details/os-unix/all/all [http://perma.cc/J7LR-V7RP] (last visited Nov. 2, 2014).↩
Usage of Web Servers for websites, W3Techs, http://w3techs.com/technologies/overview/web_server/all [http://perma.cc/9ETU-TMVA] (last visited Oct. 27, 2014).↩
The 8 most successful open source products ever, Pingdom (May 29, 2009), http://royal.pingdom.com/2009/05/29/the-8-most-successful-open-source-products-ever/ [http://perma.cc/W6SR-AVQ7].↩
MediaWiki Testimonials, MediaWiki, http://www.mediawiki.org/wiki/MediaWiki_testimonials [http://perma.cc/M7VD-8BRT] (last visited Oct. 25, 2014).↩
See Steve Vogel, For Intelligence Officers, A Wiki Way to Connect Dots, Wash. Post (Aug. 27, 2009), http://www.washingtonpost.com/wp-dyn/content/article/2009/08/26/AR2009082603606.html [http://perma.cc/GH54-L777].↩
See MediaWiki Testimonials, supra note 13.↩
See Firefox Branding, Mozilla, https://www.mozilla.org/en-US/styleguide/identity/firefoxos/branding/ [http://perma.cc/ZY7N-XFBE] (last visited Oct. 25, 2014).↩
See 1 J. Thomas McCarthy, Trademarks and Unfair Competition § 3:10 (4th ed. 2014) (explaining that failure to control quality by licensees can result in a finding of abandonment of a mark).↩
See id.; New Round of Releases Extends Mozilla Projects Standards Based Open Source Offerings, Mozilla (Feb. 9, 2004), available at http://www-archive.mozilla.org/press/mozilla-2004-02-09.html [http://perma.cc/M2MW-4SY4].↩
Mozilla Corporation software rebranded by the Debian project, Wikipedia, http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project [http://perma.cc/V3J8-XW4Q] (last visited Feb. 6, 2015).↩
E-mail from Roberto C. Sanchez, Developer, The Debian Project, to Debian Developers (Oct. 15, 2006, 10:11:08 EST), available at https://lists.debian.org/debian-devel/2006/10/msg00665.html [http://perma.cc/9A6B-8SPZ] (“Beyond [the minor differences], they will be basically identical.”).↩
See 87 C.J.S. Trademarks, Etc. § 256 (2010).↩
See infra Part I.B.1.↩
See infra Part II.↩
As explained in Part II, we call these solutions “hacks” because rather than seeking to amend trademark law, collaborative communities have used existing trademark principles in creative ways to serve projects that are very different from the traditional business models trademark law was intended to address.↩
A “bug” is a term for a software or hardware defect. In the jargon of software engineers, a “hack” is a temporary solution for a “bug.” See generally Software bug, Wikipedia, https://en.wikipedia.org/wiki/Software_bug [http://perma.cc/QQ6R-33HQ] (last visited Aug. 21, 2014).↩
Lawrence Lessig has eloquently articulated the idea of technical regulation or “West Coast Code,” which refers to code written by engineers in Silicon Valley, in contrast to legal code or “East Coast Code” written by lawmakers in Washington, D.C. See Lawrence Lessig, Code and Other Laws Of Cyberspace 53–54 (1999).↩