Red Hat, Inc. is the largest and only publicly traded corporation whose business model relies entirely on free software products and services. Nonetheless, Red Hat reported more than US$ 1.7 billion in revenues in 2015. In this paper, I explain the relationship between Red Hat and its sponsored free software projects, and how it enables the company to transform free software products into proprietary commodities that provide the foundation for its business model.
free software, open source, peer production, intellectual property, commons
by Benjamin J. Birkinbine, University of Nevada
Free software emerged in the 1980s as a radical alternative to proprietary software (Weber, 2004; Moody, 2001) after Richard Stallman began developing a Unix-based language called “GNU”, a recursive acronym for “Gnu’s Not Unix”. Along with the programming language, Stallman launched the GNU General Public License (GPL), which was the first copyleft license, a form of copyright that allows other users to run, copy, distribute, study, change and improve the software as long as the modified code is made available under conditions that do not restrict the rights granted by the GPL (Free Software Foundation, 2014). Stallman founded the Free Software Foundation as a way to promote the cause of free software, which he summarised in his famous dictum, “free as in free speech, not as in free beer”, thus positioning free software as a moral right (Stallman, 2002). The ambiguity of the English term “freedom” is sometimes clarified by using the term libre instead of gratis.
While free software does not preclude commercial use of the software per se, many free software projects are available at no cost. Indeed, making a project available at no cost is one of key ways to make sure that others will contribute to the project. The fact that many free software projects are available at no cost, however, does not mean that commercial enterprises have been uninterested in free software projects. On the contrary, free and open source software projects are increasingly becoming associated with large commercial enterprises. For example, the most recognisable open source project, Linux, receives significant sponsorship from large corporations like Intel, IBM, Google, Texas Instruments, Cisco, Hewlett-Packard and Samsung, as well as others (The Linux Foundation, 2015).
Red Hat, Inc., is similarly exemplary of this trend, as it is the largest and only publicly traded company whose business model relies entirely on free software. The company reported more than US$ 1.7 billion in revenue in 2015 (Red Hat, Inc., 2015: 43). These figures become even more striking when one considers that most of Red Hat’s software is covered by copyleft licenses, which means that Red Hat cannot rely on traditional copyright protections to prevent others from using its code. Rather, the broader free and open source community contributes code to Red Hat’s sponsored projects, including Fedora, RDO and JBossDeveloper. In this sense, Red Hat has found a way to incorporate commons-based peer production into its corporate structure.
Benkler (2006: 60) defines commons-based peer production as “… a new modality of organising production: radically decentralised, collaborative, and nonproprietary; based on sharing resources and outputs among widely distributed, loosely connected individuals who cooperate with each other without relying on either market signals or managerial commands.” Benkler claims that this radical new form of organising will continue to disrupt the ways that commercial firms function. Indeed, Benkler notes that the nature of the firm itself is radically transformed by this new modality of production:
As the companies that adopt this strategic reorientation become more integrated into the peer-production process itself, the boundary of the firm becomes more porous. Participation in the discussions and governance of open source development projects creates new ambiguity as to where, in relation to what is “inside” and “outside” of the firm boundary, the social process is. (2006: 125)
While Benkler’s claims are justified, as exemplified by increasing corporate involvement in FLOSS projects, there has been comparatively less work done on exploring exactly how these dynamics are taking shape. To that end, this paper examines the dynamics that exist between free (libre) and open source software (FLOSS) communities and the corporations that are involved in or make use of their projects. In doing so, this study expands on theories of the commons and commons-based peer production by illustrating how FLOSS processes and products are being incorporated into broader corporate structures and strategies. In this sense, Red Hat’s strategy is illustrative of the tendency to move from the commons to capital.
To illustrate the specifics of how this process takes place, I begin by providing a brief historical overview of Red Hat, which specifically focuses on the company’s two core commodities, Red Hat Linux and Red Hat Enterprise Linux. Next, I focus on the Contributor Licensing Agreements that Red Hat uses to control the types of intellectual property licenses that are included in its code base. These agreements enable Red Hat to commercially exploit the code, while simultaneously insulating the company against any ownership claims from the community. Finally, I conclude with reflections about the Red Hat business model and what it means for the broader FLOSS community.
The history of Red Hat, Inc.
Red Hat Software, Inc. was founded in 1995 when open source software was still an emerging but rapidly growing phenomenon. In 1991, Linus Torvalds released the code for his Linux kernel project. While those who supported the open-source project were extremely dedicated to its cause, the market for software and, more specifically, the market for operating systems was still dominated by large firms, most notably Microsoft and its Windows operating system. In 1993, Bob Young formed a company, the ACC Corporation, which primarily sold Unix- and Linux-related accessories and books, and Mark Ewing created his own distribution of Linux, Red Hat Linux in 1994. One year later, Red Hat Software, Inc. (simply referred to as “Red Hat” from here onwards) was founded after Bob Young’s ACC Corporation merged with Mark Ewing’s company. Red Hat was founded with the purpose of making open source a commercially-viable business model by lending credibility to the emerging open-source phenomenon. In effect, Red Hat was intended to bring the power of open source to businesses by providing packaged solutions to customers, while funnelling their earnings back into the open-source community by supporting free software projects. As Bob Young declared in 1999,
We recognised the value of giving customers control of their software, and sought to bring brand reliability to the Linux product. We would offer support to customers and accelerate development of the operating system by investing our own R&D [research and development] dollars in new Linux technology that would then be given back for free to the community, for any Linux programmer or distributor to use. We had no intention of ever “owning” the intellectual property we created. Instead, our business model was based on quickly expanding the market, and earning a small amount of revenue from a large number of customers who would buy a product that was better quality than that being offered by the industry leader, Microsoft. (Young and Rohm, 1999: 10)
The “better quality” that Young is referring to is the Linux-based operating system, which is created by collaborative development, as opposed to closed proprietary development. The open and collaborative model of development, exemplified by Linux, is notable for its efficiency, innovativeness and security. Red Hat found a way to offer an operating system that could be easily adapted to the unique needs of different customers. This was particularly important in a time when hardware vendors were reliant on large, proprietary firms such as Microsoft to develop operating systems that could run on their hardware. The speed at which new versions of proprietary operating systems could be developed was much slower compared to the open-source options. Consequently, Red Hat negotiated—and continues to rely on—strategic partnerships with hardware manufacturing companies, such as Intel, IBM, Dell, CISCO, Hewlett-Packard, Sony and others.
Such partnerships are beneficial to Red Hat and its partners for several reasons. First, Red Hat pursues its original goal of endowing to free and open source software with commercial credibility because of its support from major information technology firms. Second, Red Hat positions itself as a leading company dealing solely in free software. Third, Red Hat continues to funnel funding back into free software projects as a way to support the developer communities that work on these projects. In this sense, Red Hat serves as an intermediary between large information technology firms and the FLOSS community.
However, Red Hat also benefited from venture capital investment after it was established, particularly at a time when the “dot-com” investment bubble was on the rise. Frank Batten, Jr., through Landmark Communication, was an early investor in Red Hat and committed US$ 2 million to the company in 1997 (Young and Rohm, 1999). Landmark Communication was famous for investing in the Weather Channel, and the company remains a privately-held investment firm that now operates under the name Landmark Media Enterprises. Red Hat also received investment capital from Greylock Limited Partnership and Benchmark Capital, a company based in Menlo Park, CA, and known for its investment in, and support of, the open-source community. All three of these entities—Landmark Communication, Greylock and Benchmark Capital—became major shareholders in Red Hat after its initial public offering (IPO).
Red Hat held its IPO in August 1999. The investment from venture capital firms, as well as the company’s partnerships with major information technology companies, led to rapid growth of the firm’s value. In September 1999, Red Hat’s stock price rose to more than US$ 122 per share, up from its original price of US$ 14 per share. At the time, Frank Batten, Jr., owned 15 million shares of the company, while Greylock Limited Partnership owned 8.7 million shares, and Benchmark Capital owned 5.8 million shares (Kanellos, 2002). However, in the interest of giving back to the FLOSS community, the company tried to compile a list of all FLOSS developers who contributed to Linux and other FLOSS projects. While arriving at a fully comprehensive list was not possible, the company managed to develop a list of approximately 5,000 developers. The intention was to make these developers stockholders in the company so they could benefit from the company’s growth. While Securities and Exchange Commission regulations prevented a large portion of these developers from becoming investors, more than 1,000 of the eligible 1,300 developers became early shareholders in the company (Young and Rohm, 1999). Making the effort to include members of the FLOSS community as early shareholders in the company signalled Red Hat’s commitment to the community.
In the years following the IPO, Red Hat continued to enjoy growth in revenue. What is particularly striking about Red Hat’s growth was that the company was not significantly affected by the dot-com bubble crash between 1999-2001. Rather, Red Hat emerged from this period and continued to grow. One reason for the company’s steady growth during this period may be the strategic partnerships that Red Hat negotiated with large information technology firms in the lead up to the dot-com crash. Those firms—Intel, Cisco, IBM, Dell, etc.—also survived the crash and many have solidified their position as leaders in the market for information and communication technologies. Even though Red Hat was a start-up company, the partnerships that the company formed with these larger firms ensured that Red Hat would be supported by these businesses into the future.
While the company continued to enjoy growing revenues, its net profits exhibited a noticeable decrease during the dot-com bubble crash. Red Hat’s profits dipped from 1998 until 2002, but rose again in 2003. This performance almost perfectly coincides with changes in management, and can also be explained by a shift in Red Hat’s business strategy. In 1999, the original co-founders, Bob Young and Mark Ewing, left the company. In 2001, Paul Cormier joined Red Hat and began to lobby in favour of shifting the company’s business model. Specifically, Cormier wanted to provide FLOSS solutions at the enterprise level rather than in the consumer market. To more fully explain the nuances of this shift, the following section contains an in-depth discussion of Red Hat’s core products, how those commodities shifted focus over time, and how Red Hat was able to centralise intellectual property within its corporate structure.
Red Hat’s core commodities and intellectual property
Red Hat’s business model relies primarily on its ability to provide an easy-to-use and accessible version of Linux by producing packaged distributions of the operating system, while also providing services and customer support that cater to its products. Red Hat’s revenue come from these two streams. The majority of Red Hat’s revenue is derived from a subscription-based model, whereby clients get both products and support from Red Hat, in exchange for a fee. The types of products and services provided depend on the level of subscription. The effectiveness of this subscription model is based, to a large degree, on two interrelated factors: Red Hat’s recognition as a trustworthy provider of FLOSS products and services, as well as Red Hat’s position as a legally-recognised institution, which can be held liable for the products and services it provides.
Most importantly for its customers, Red Hat is able to provide a way to outsource services that may otherwise be too expensive to perform within a company. Indeed, any one of Red Hat’s customers could perform the work done by Red Hat, especially because the underlying code that Red Hat relies on is free software. Red Hat does not own the intellectual property rights for the free software that its services are based upon, and the company is not necessarily trying to exclude others from this intellectual property. Rather, Red Hat has built its business model on free software that is protected by the GNU General Public License (GPL), as well as other FLOSS licenses. As such, any of its customers could, in theory, produce the same software that is sold by Red Hat, but they would need to perform the work themselves. However, Red Hat is a legally-recognised corporation that is liable for the products and services it supplies. Because of this, its customers are presumably reassured that support will be available when they sign a contract with Red Hat and this, in turn, is how Red Hat has been able to become the market leader providing FLOSS distributions and services to earn revenues. Prior to Red Hat’s founding, FLOSS projects had differing degrees of trustworthiness. By forming a corporate entity that could be held liable for the products and services it provided, Red Hat provided corporate legitimacy to a system of production that was massively distributed and not driven by market forces. Such a system engendered projects that varied in their attractiveness to developers, which threatened the ability of certain projects to survive.
In order to understand the types of products and services that underlie Red Hat’s market position, we need to examine exactly how Red Hat has been able to profit from free software. I begin with a discussion of Red Hat Linux, which was the original operating system sold to customers from 1994-2004. Then, the company shifted its strategy to focus more on providing business solutions with Red Hat Enterprise Linux. Most importantly, I address the relationship between Red Hat’s core commodities and the Fedora Project, which is one of the major FLOSS projects supported by Red Hat.
Red Hat Linux
When Red Hat first began offering products and services in the early 1990s, it sold a compact disc (for approximately US$ 50) that contained a Linux distribution called Red Hat Linux, some additional applications and documentation. Red Hat Linux was based purely on computer code that was protected by the GPL and other FLOSS licenses—that is, code that must remain freely available for distribution, modification, adaptation, etc. Red Hat Linux provided the principal source of revenue for Red Hat during its early years. Revenue came primarily from sales of Red Hat Linux to distributors and original equipment manufacturers (OEMs) for inclusion on their hardware. These companies are some of those which invested directly in Red Hat during its early years: Dell, Cisco, Hewlett-Packard, IBM and Intel. Because Red Hat had a potentially very large and distributed labour force to draw on—namely, the FLOSS community—its business model was highly scalable. That is, Red Hat had the ability to quickly expand its market share to provision a large number of customers without incurring increased investment costs. This was precisely Red Hat’s strategy: To rapidly increase the market, deriving a small amount of revenue from a large number of transactions, while reinvesting part of its earnings back into the FLOSS community.
While Red Hat Linux constituted the primary commodity for Red Hat during its early years, the bulk of its work was coming from the support it provided for this software. Red Hat’s employees provided customer support, education, training and technical support to its clients. This strategy, along with Red Hat’s strategic partnerships, allowed the company to begin picking up market share during its early years. While the company’s revenues were still growing up until 2004, it still had not become a profitable business. This was in part due to a spate of acquisitions of other software firms before the dot-com bubble crash, but also because the company had not yet found a way to substantially increase subscription sales at the enterprise level. This is precisely the change that occurred when the company shifted its focus to Red Hat Enterprise Linux, which became its core commodity and continues to be today. The final stable version of Red Hat Linux was released in 2003, which was the same year that Red Hat Enterprise Linux was released.
Red Hat Enterprise Linux and the Fedora Project
In 2003, Red Hat split its Red Hat Linux project into two separate projects: Red Hat Enterprise Linux and the Fedora Project. Red Hat Enterprise Linux continued as a core commodity for Red Hat in the same way that Red Hat Linux had been before. The Fedora project, however, became a community-based FLOSS project. Red Hat Enterprise Linux relied on the same model as Red Hat Linux in terms of providing packaged distributions of a free operating system but, rather than selling individual compact discs containing the software, Red Hat Enterprise Linux was made available solely through a subscription model. Depending on the level of subscription, customers could get access to customised versions of the Red Hat Enterprise Linux operating system, plus the different levels of support services for the operating system. In effect, Red Hat Enterprise Linux was a similar product to Red Hat Linux with a different customer distribution model. Red Hat then used the revenues from sales of Red Hat Enterprise Linux to support the Fedora Project. The relationship between these two projects provides perhaps the most interesting insight into how Red Hat incorporates the commons.
The split into Red Hat Enterprise Linux and the Fedora Project in 2003 was made with the intention of finding a mutually beneficial way for the FLOSS community and Red Hat to collaborate on developing software. Red Hat Enterprise Linux continues to serve as one of Red Hat’s core commodities, and the company profits from subscription sales to its customers. The Fedora Project was meant to be a community-sponsored project that would provide an incubator for innovation. In return, the innovation that occurred within the Fedora Project could then be implemented into Red Hat’s commercial offerings. This was possible because of the ownership and governance structure of the Fedora Project, as well as the worker contracts established with contributors to the project.
Ownership, governance and intellectual property in Fedora
Red Hat, Inc. exercises ultimate control of the Fedora Project. However, the Fedora Project Council leads the Fedora Project. The Council is comprised of six members with full voting powers: two members appointed by the community for engineering and outreach, two members elected by the community, and two members who are employees of Red Hat and are appointed by the company. The Council may also have two to four additional community members at any given time who are appointed to take the lead on specific project objectives. These members are considered auxiliary Council members with binding votes only in the areas specified by their appointment. In addition, the Council also has two additional auxiliary seats: the Diversity Advisor, who is appointed by the Council, and the Fedora Program Manager, who is appointed by Red Hat with the approval of the Council.
While the governance structure of the Fedora Project has changed over time, perhaps the most interesting factors in this structure pertain to the members appointed by Red Hat: the Fedora Project Leader and the Fedora Community Action and Impact Coordinator. The Fedora Project Leader serves as Chair of the Council, while the Action and Impact Coordinator is responsible for coordinating decision making with budgetary concerns. Previously, the Project Leader was also given veto power over any decision made by the Fedora Project Board, but now all voting members can block decisions “with a valid reason” (The Fedora Project, 2016). However, the Project Leader does have “a limited power to ‘unstick’ things if consensus genuinely can’t be reached and a decision needs to be made” (The Fedora Project, 2016). The language used here is vague, but it does suggest that the Fedora Project Leader may still maintain ultimate control over the project, although he or she would presumably expend considerable political capital in making decisions that conflicted with the interests of the community.
Thus, the governance structure of the Fedora Project operates as an intermediary between Red Hat and the FLOSS community that contributes to the Fedora Project. Red Hat supports the community by sponsoring the project and directing funds to Fedora through one of its appointed employees, but it then uses the work performed by the community in its commercial offering, Red Hat Enterprise Linux. The reason Red Hat is able to appropriate the labour performed within the community is because all contributors to the Fedora Project have signed a contributor’s agreement. These agreements have changed throughout the history of the Fedora Project, but all have similar effects. Originally, contributors needed to sign the Individual Contributor Licensing Agreement (ICLA), which effectively assigned the contributors’ copyright to the Fedora Project. However, the ICLA was later abandoned in favour of the Fedora Project Contributor Agreement (FPCA), which no longer assigned copyright to Red Hat, but specified the types of licenses that could be included in the Fedora Project. This shift made it possible for code that had already been licensed under a previous licensing scheme to be included in the Fedora Project, as long as the licenses were compatible with the guidelines established by Fedora.
Both the ICLA and the FPCA provide the mechanism that allows Red Hat to commercially exploit the labour that occurs within the commons-based peer production of free software projects. In this sense, the agreements allow Red Hat to incorporate these projects into its corporate offerings by having the right to use these projects transferred to the company. In the case of the ICLA, it provided a direct assignment of a contributor’s copyright to Red Hat, whereas the FPCA does not necessarily assign copyright to Red Hat. In this sense, the FPCA can be viewed as less restrictive because it allows contributors to assign licenses to their work prior to submitting the work to the Fedora Project. However, those licenses must be compatible with the goals of the Fedora Project, and the Fedora Project wiki maintains a Software License List that identifies the acceptable and unacceptable licenses that can be included in Fedora. Importantly, Red Hat does this because it becomes legally responsible for the products that it offers to customers.. In the event that content other than code is included in the submission (text, images, logos, etc.), the contributor must waive his or her moral rights to the content. This ensures that Red Hat will not be subject to infringement claims. In effect, these licensing agreements provide a way for Red Hat to control what is included in the commons-based project (Fedora) so that when that material is included in their commercial offering (Red Hat Enterprise Linux or other software), the company will not be subject to intellectual property infringement claims by the contributors.
By taking these preventative measures to control what is included in Fedora, Red Hat can provide its customers with a guarantee that they will not need to fear a potential claim against intellectual property infringement. Red Hat does this through its Open Source Assurance Program. As the Open Source Assurance Agreement contract states, in the event that a third party alleges infringement of intellectual property in the software provided to the client by Red Hat, the company will,
(i) defend Client against the Claim and (ii) pay costs, damages and/or attorneys fees that are included in a final judgement against Client (without right of appeal) or in a settlement approved by Red Hat that are attributable to Client’s use of the Covered Software; (Red Hat, Inc., 2016)
Furthermore, if the Client’s use of Red Hat’s software is found to infringe the third party’s intellectual property rights, then Red Hat will
(i) obtain the rights necessary for Client to continue to use the Covered Software consistent with the Support Agreement(s); (ii) modify the Covered Software so that it is non-infringing; or (iii) replace the infringing portion of the Covered Software with non- infringing code of similar functionality (subsections (i), (ii) and (iii) are the “IP Resolutions”); provided that if none of the IP Resolutions is available on a basis that Red Hat finds commercially reasonable, then Red Hat may terminate the Support Agreement(s) without further liability under this paragraph, and, if Client then returns the Covered Software that is subject to the Claim, Red Hat will refund any prepaid subscription fees related to Covered Software. (Red Hat, Inc., 2016)
From Red Hat’s perspective, then, this is the legal-juridical benefit of controlling what is included in the Fedora Project, as well as centralising control of the intellectual property rights within its corporate structure. Red Hat relies on the FLOSS community to perform the cooperative labour of developing new features, fixing bugs or otherwise improving the Fedora Project so that these features can be included in its commercial offerings. In order to assure its customers that they will not be subject to intellectual property infringement claims from third parties, Red Hat requires contributors to assign licenses to their work that will allow Red Hat to continue providing its services. In effect, Red Hat is separating authorship from ownership, which is one of the primary critiques of intellectual property laws (see Bettig, 1992). However, Red Hat does not use copyright to prevent authors or anyone else from making use of the code in other ways. Rather, Red Hat is just trying to ensure that the rights to use the code in Fedora have been legally transferred to the company, which allows the company to provide assurances to its customers. Red Hat’s method for protecting its core intellectual property does not come from copyright, but the company still prevents exact redistributions of its property through trademark law.
Red Hat, trademark and CentOS
As stated earlier, Red Hat does not own the intellectual property that makes up its core commodities. Most of the code in these core commodities is covered by the GPL, which allows others to freely copy, modify and redistribute it. Therefore, rather than relying on copyright to protect its core commodities, Red Hat relies on trademark law to protect its properties. The details of this strategy can be found in Red Hat Trademark Guidelines document (Red Hat, Inc., 2006b). Hypothetically, anyone could make an exact copy of Red Hat’s open source software and begin selling it, but they would be prevented from including any registered trademarks. These trademarks include the logos and names of software, which means that exact copies of Red Hat’s open source software would need to be given a different name. Red Hat’s trademarks also prevent products from having names that are sufficiently similar, like “Green Hat” or “Red Cap” or “Redd Hatte”. While these restrictions exist, CentOS provides an example of a project that served as an exact replacement for Red Hat Enterprise Linux.
CentOS began in 2004, and served as a functionally compatible version of Red Hat Enterprise Linux. Indeed, CentOS was based on the publicly available code for Red Hat Enterprise Linux. Rather than competing with CentOS or trying to prevent them from using code included in Red Hat Enterprise Linux, Red Hat was largely ambivalent about CentOS. This is, in part, due to the perception that customers who want to use CentOS will probably continue to use it, but also because those customers could switch to Red Hat Enterprise Linux at any time because the two operating systems were basically the same. However, whatever tension may have existed between the two operating systems became a moot point in 2014, when Red Hat officially became a sponsor of the CentOS project. The move was perceived as a way to meet users’ demands across the three major versions of Red Hat’s software—Red Hat Enterprise Linux, Fedora and CentOS—by giving users access to features that may not be included across all versions of the operating system (Vaughn-Nichols, 2014). As part of Red Hat’s new sponsorship of the CentOS project, all CentOS trademarks were transferred to Red Hat.
Red Hat’s use of trademark law to protect its market position is used in conjunction with its ability to control the intellectual property included in its commercial offerings. By sponsoring the CentOS project, Red Hat is able to increase its intellectual property holdings, while also eliminating a rival form of free software that was offering a functional equivalent of its commercial software. In this sense, Red Hat’s sponsorship of the CentOS project functions similarly to a corporate acquisition or an instance of horizontal integration.
Core commodity conclusions
Red Hat, as an institution, may be viewed in at least two different ways. On the one hand, Red Hat can be viewed as a pragmatic way to centralise commons-based peer production within capitalism. In this way, Red Hat serves as an intermediary institution for providing commercial access to commons-based peer production. In other words, Red Hat is situated between capital and the commons. Importantly, however, Red Hat is clear about its intentions and involvement in FLOSS projects, and it is one of the largest contributors to other FLOSS projects. Furthermore, the company is actively paying its employees to contribute to other FLOSS projects. For these reasons, Red Hat maintains a relatively good relationship with its FLOSS communities. Indeed, Red Hat’s entire business model was founded on finding a way to bring the power of FLOSS production to other businesses. In return, Red Hat reinvests in the FLOSS community by supporting FLOSS projects, acquiring new businesses and then releasing source code to the community. The relationship between Red Hat and the FLOSS community is one of mutual benefit: Red Hat’s financial success benefits the FLOSS community, more revenue for Red Hat means more investment in FLOSS projects, and more investment in FLOSS projects means higher quality products and services that Red Hat can offer to its customers.
On the other hand, Red Hat can also be viewed as an institution that operates no differently than other corporations within a market-driven capitalist economy. Red Hat relies on centralising production within its corporate structure, separating authorship from ownership through worker agreements, and protecting intellectual property through trademark laws for the purpose of making a profit. The difference is that Red Hat cannot prevent some actions that are commonly copyright violations because of the rights granted by free software projects. Furthermore, Red Hat does not directly employ its entire labour force, which exempts the company from directly compensating all of its labourers through wages and benefits. Aside from those members of the Fedora Council that it directly employs, it relies on other informal ways of compensating those programmers who contribute to Fedora. Because the company relies on the development of an active Fedora community, it is in the company’s best interest to maintain a good relationship with that community. If the company were to exercise unwanted influence in the Fedora Project, those who contribute to the project may choose to abandon the project, thus ceasing development of new and innovative features that could potentially be included in Red Hat Enterprise Linux.
From the commons to capital
In weighing these two interpretations, at the very least, Red Hat provides an exemplary case for understanding how the boundaries of a firm can become blurred as it orients itself toward commons-based peer production. In this sense, Red Hat demonstrates the ambiguity of commons, particularly as it pertains to the potential for radical change. Furthermore, Red Hat demonstrates how a distributed system of commons-based peer production can be centralised or incorporated into a corporation’s broader strategy and turned into a profitable business. As demonstrated throughout this paper, Red Hat accomplished this through both formal and informal mechanisms.
Red Hat was one of the earliest companies to position itself as the leading company providing services for FLOSS. As such, Red Hat sought to lend an element of professionalism to the emerging FLOSS phenomenon by establishing the formally recognised institution of a publicly traded corporation that could be legally liable for the services provided. Consequently, Red Hat needed a formalised way to control the commons-based peer production that it incorporated into its core commodities. The company accomplished this through Individual Contributor License Agreement (ICLA) and later the Fedora Contributor License Agreement (FCLA) that granted the company rights to use the production that was performed by developers.
The contributor licensing agreements constitute a formal mechanism for controlling the informal production that takes place in commons-based peer production. These agreements are essential to Red Hat’s business model because they allow Red Hat to be legally liable for the products it sells, particularly when it comes to allegations of intellectual property infringement. Red Hat is certainly not alone in using these types of agreements. The issuing of contributor licensing agreements is common practice in FLOSS projects, although the terms of the agreements may differ from organisation to organisation. Some CLAs, like the ICLA formerly used by Red Hat, represent the most striking example of how institutions, whether for-profit or non-profit corporations, or any other type of legally recognisable organisation, formally control commons-based peer production by separating authorship from ownership. However, other CLAs like the FPCA now used by Red Hat do not require full copyright transfer. Nonetheless, CLAs in general provide a mechanism for transferring rights from commons-based peer production to commercial firms like Red Hat.
While this may be viewed as a pragmatic solution for monetising FLOSS production and products, it also illustrates the limits of Benkler’s claim that the boundaries of the firm will become porous. Indeed, despite the seemingly revolutionary potential of this new modality of production, it still maintains the hallmarks of capitalist production: centralisation, control and appropriation of surplus value. Insofar as one claims FLOSS production to be exemplary of commons-based peer production or “non-market production”, the labour performed under these conditions can still be appropriated for corporate gain. In the case of Red Hat, the company has been able to benefit from the creative input of the FLOSS community contributing to the Fedora Project. However, in the same way that Red Hat relies on both formal and informal degrees of controlling production within the Fedora Project, the company similarly relies on both formal and informal mechanisms for compensating those who contribute to its FLOSS projects.
Red Hat provides direct compensation to those members of the Fedora Council who are employed by and appointed to the Council by the company. Red Hat also directs funding back to the Fedora Project through the Open Source and Standards group, which provides funding for one of the full-time employees who serves on the Fedora Council. For those contributors who are not directly employed or paid by Red Hat, their compensation comes to them informally. Typically, community members do not have access to the budgetary funding provided by Red Hat, although community members may be elected or appointed to the Council, in which case they will at least have a say in how funds are directed. Aside from this, they may also attend public events or trade shows where institutions like Red Hat provide sponsorship or other goods and services for the community. However, this informal economy is only sustainable for as long as the institutions supporting FLOSS projects remain transparent about their intentions for the products of FLOSS developers’ labour and continue to support the community through the provision of paid employment, sponsorship of additional FLOSS projects and events, and informally through gifts given to the community.
In sum, Red Hat complicates binary distinctions between market-driven production and commons-based peer production by illustrating the way that one firm has been able to implement a hybridised model of commons-based market production. Furthermore, the case study of Red Hat illuminates the contours of the ways in which the boundaries of a firm can become more porous, as was claimed by Benkler (2006). However, those boundaries are still discernible, and the production within Red Hat’s corporate structure is still largely market-driven. But Red Hat, through its sponsorship of, and relationship with the Fedora Project, has found a way to move somewhat informal production from the commons to capital.
Benkler, Y. (2006) The wealth of networks: How social production transforms markets and freedom. New Haven, CT: Yale University Press.
Bettig, R. (1992) “Critical perspectives on the history and philosophy of copyright”. Critical Studies in Mass Communication 9(2): 131-155.
The Fedora Project (2016) “Council”. Available at: http://fedoraproject.org/wiki/Council (accessed on 31 August 2016).
The Free Software Foundation (2014) “The GNU General Public License”. Available at: http://www.gnu.org/licenses/gpl-3.0.en.html (accessed on 31 August 2016).
Moody, G. (2001) Rebel code: The inside story of Linux and the open source revolution. Cambridge, MA: Perseus Publishing.
Kanellos, M. (2002) “Red Hat stock surge creates billionaires”. CNet. 2 January. Available at: http://news.cnet.com/Red-Hat-stock-surge-creates-billionaires/2100-1001_3-205557.html (accessed on 31 August 2016).
Red Hat, Inc. (2000) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2001) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2002) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2003) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2004) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2005) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2006a) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2006b) Red Hat trademark guidelines. Available at: http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf (accessed on 31 August 2016).
——— (2007) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2008) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2009) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2010) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2011) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2012) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2013) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2015) “Form 10-K”. Annual report. Available at: http://investors.redhat.com/financial-information/sec-filings (accessed on 1 May 2017).
——— (2016) “Open source agreement”. Available at: http://www.redhat.com/en/about/open-source-assurance-agreement (accessed on 31 August 2016).
Stallman, R. M. (2002) Free software, free society: Selected essays of Richard M. Stallman. Boston, MA: Free Software Foundation.
The Linux Foundation (2015) “Linux kernel development: How fast is it going, who is doing it, what are they doing and who is sponsoring the work”. Available at: http://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2015 (accessed on 21 October 2015).
Vaughn-Nichols, S. J. (2014) “Red Hat reveals CentOS plans”. CDNet, 28 March. Available at: http://www.zdnet.com/article/red-hat-reveals-centos-plans/ (accessed on 31 August 2016).
Weber, S. (2004) The success of open source. Cambridge, MA: Harvard University Press.
Young, R. and W. G. Rohm (1999) Under the radar: How Red Hat changed the software business – and took Microsoft by surprise. Scotsdale, AZ: The Coriolis Group.
 I have used the combined terms “free and open source software projects” here. However, there are important distinctions between the two. “Open source” generally refers to a method of developing software, whereby the source code is made freely available to facilitate distributed development. “Free software” is generally associated with a social movement that ascribes to the ethical and moral principles of respecting the rights of software users.
 Two regulations are most significant here. First, you must be a US-based taxpayer to buy IPO shares for a company listed on an American exchange. This regulation eliminated approximately half of the eligible investors. Second, since the SEC designates IPO offers as extremely high-risk investments, it regulates against “inexperienced investors” buying shares in IPOs. This regulation eliminated another 15% of developers, as they were either students or qualified as “inexperienced investors” according to SEC guidelines.
 Unless otherwise noted, the information from this section comes from Annual Reports (Form 10-K) filed with the Securities and Exchange Commission in the United States between the years 2000-2015.
 Information about the Fedora Project Council is publicly available on the project’s wiki, which is available at: http://fedoraproject.org/wiki/Council (accessed on 31 August 2016).
 Information about the Individual Contributor Licensing Agreement can be found on the project’s wiki at: http://fedoraproject.org/wiki/Legal:Licenses/CLA (accessed on 31 August 2016).
 Information about the Fedora Project Contributor Agreement can be found on the project’s wiki at: http://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement (accessed on 31 August 2016).
 The Software License List can be found at: http://fedoraproject.org/wiki/Licensing:Main?%20rd=Licensing#Software_License_List (accessed on 31 August 2016).
 The full text of the Open Source Assurance Agreement can be found at: http://www.redhat.com/legal/open_source_assurance_agreement.html (accessed on 31 August 2016).
 The Red Hat Trademark Guidelines are available at: http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf
Benjamin J. Birkinbine, University of Nevada