Free and open source software business and sustainability models

by Pete Cooper, Amir Nettler on 3 November 2009 , last updated

Introduction

This document was informed by a presentation given by Rowan Wilson at an OSS Watch workshop in January 2009. It focuses on some of the legal aspects surrounding free and open source software (FOSS) and looks at such issues as enforcement, risks and patents, citing a number of significant legal cases of recent years. It also discusses ways in which FOSS projects can successfully be exploited and sustained.

Enforcements, exclusions and risks

We’ll begin with the question of whether a FOSS licence constitutes a contract between the developer and the user. There are many people within the FOSS community who reject the idea that a FOSS licence is a contract. This is mainly for practical reasons, as contract law varies greatly between countries and it is relatively expensive to litigate. Consequently, many believe that licences are better enforced using the more uniform intellectual property (IP) laws, which, among other benefits, have international treaties and legislation behind them, making them easier to police.

It is interesting at this point to look at a couple of examples of legal challenges to FOSS licences: in Wallace vs FSF it was argued unsuccessfully that the General Public License (GPL) created a kind of price-fixing contrary to US anti-trust law; Jacobsen vs Katzer showed that a FOSS licensor in the US is not reliant on contract law to enforce the conditions in their FOSS licence.

Software patents and FOSS

Traditionally, staff charged with exploiting software IP generated in UK research institutions have considered obtaining software patents. But care should be taken when thinking about how FOSS licensing affects software patents. This is because all FOSS licences, either explicitly or implicitly, grant rights to patents that the software embodies to anyone in the world, at essentially no cost.

It is also worth noting that silently engulfing FOSS within your own software can be a temptation - particularly where the FOSS licence in question has troublesome conditions on reuse - but this can end in expense and publicity problems. Within the community, there in an active body of enthusiasts who decompile software, looking for signs of unlicensed FOSS software reuse, and they have shown in the past that they can force the compliance of even major IT firms through legal action and bad publicity.

Business models of FOSS

The various business and sustainability models of FOSS are not mutually exclusive; most often, they are used in combination, as appropriate. However, open source business models are quite a new development, so little is known about how best to use them, or what their ultimate effectiveness will be. Some of the current successes of FOSS exploitation can perhaps be attributed to dissatisfaction with closed source software, rather than any innate superiority. Looking to the future, the current economic downturn may either help or hinder the future success of FOSS business models; analysts are currently predicting both.

Academic community

The first model to consider is the building of an academic community around a particular software solution. While it may not seem much like a business model at first glance, in fact ‘owning’ a tool that is prominent in a particular problem domain can bring positive benefits to the reputation of the institution and academics in question. This is in addition to funding and industrial partnerships.

Establishing a foundation

The establishment of a separate legal entity or foundation can help greatly with the successful exploitation of a FOSS project. As well as being a workable business model that allows donations and a simpler approach to tax, it also enhances sustainability by transferring risk away from the parent company or institution to the separately established legal entity. For example, a spun-off entity could be created with the intention that liability in the case of a legal action would fall on the spin-off, rather than on its parent or any other contributors. Perhaps even more useful are the several FOSS umbrella organisations containing a number of projects. The Apache Software Foundation is home to many projects, including the Apache HTTP Server and Apache Cocoon. Software in the Public Interest is responsible for Debian Linux and PostgreSQL, and the Software Freedom Conservancy is home to – among other projects – Samba and Wine. In short, the financial benefits of running a foundation are clear: the foundation will provide the necessary book-keeping and risk management, further reducing the potential for risk and/or damage to the parent.

The community source model

Community source provides another route to added value from software, although some would argue that it can present specific problems. In this model, a group of institutions pool resources to create a software solution of use to them all. Initially, the community around the software (and its licensing) is limited to the contributing institutions, although a common next step is to release a FOSS version once the major architecture of the code is complete. For example, the Mellon Foundation-funded projects Sakai and Kuali were both begun under this model.

Provision of paid services

Organisations can also exploit their resources financially by offering consultancy services for software that they produce. This could include things like paid support, bespoke development or certification for specific hardware. They could even release the software freely, but reserve documentation for paying customers. For educational institutions that create software derived from their research activities, for example, this can be a way of making money from these activities. Of course, one could also release such software in proprietary form and sell licences to it while still offering services, gaining income from both routes at once. However, it can be argued that releasing the software with no licence fees under an open source licence might increase the number of users, and thereby widen the potential market for the other services.

Internal cost-savings

Cost-reduction is another reason for an organisation to support an internally developed FOSS project, if it provides savings to the organisation greater than the cost of its development, or if it solves an internal problem. Furthermore, a project that has proved useful to one organisation may also be useful to others. This could drive the growth of a cross-institutional community around the project, and also possibly become a source of revenue by creating a market for, for example, paid consultancy work or other services.

Software as a network-based service

The increasing acceptance of software provided as a network-based service can account for another revenue stream. Provision of these services using software licensed on copyleft principles does not break any licence conditions, as the software is not distributed in the traditional sense, and the reciprocal licensing responsibilities are therefore not required. This can provide an alternative model where licence compatibilities might otherwise block exploitation based on distribution. However, it should be noted that proponents of copyleft licensing regard this as a shortcoming of existing licences; efforts to create a licence that does not allow this activity have resulted in the Affero Public Licence. Proponents of non-copyleft open source licences, by contrast, will tend to see this activity as within the spirit of those licences.

Advertising or referral fees

Income can also be derived from advertising and/or referral services. In 2007, the major proportion of the Mozilla Foundation’s $75m income came from a deal with Google, which saw search terms typed into Mozilla Firefox’s search box directed to Google servers. Even for smaller projects, referred links into vendors like Amazon from a project website can provide an income stream. Obtaining a trademark associated with a project name and/or logo can also provide opportunities for both merchandising and outward licensing for third-party training or product creation.

Closed source derivatives, and dual licensing

Now let’s look at the more ‘traditional’ FOSS exploitation techniques - provision of paid support, selling closed source versions or proprietary add-ons, and dual-licensing. The first has already been mentioned. The second involves adding extra features in a non-open source form, for which users have to pay. This can be done either by reserving certain desirable features for a non-open source version of a piece of software, or - where the architecture permits - releasing separate, non-open source add-ons for which a user has to pay. The former is possible when software is either available under a permissive licence (such as the Apache License), which allows anyone to create a non-open source derivative, or if all the copyright holders agree to create a separately licensed, closed source derivative.

The third model mentioned, dual-licensing, also involves releasing a non-open source version of a piece software alongside an open source version. Specifically, it involves releasing software under a strong copyleft licence such as the GNU GPL, and also making available a version under an alternative licence, allowing users who do not wish to be bound by the GNU GPL to pay for the non-copyleft version. Generally, they would do this because they wish to produce a product based on the code but not be confined by a copyleft licence. Models such as those discussed in this section can allow a community to collaborate on an open source ‘core’, while at the same time allowing some members of the community to make money by creating and selling closed source variations on it.

Some examples

Now let’s take a look at some notable examples of FOSS projects that fulfil some of the criteria and features we have discussed. First up is Red Hat, an example of a company that charges for services for software that is otherwise free of charge. Its main products are the enterprise-grade Red Hat Enterprise Linux operating system and the community-developed Fedora operating system. Red Hat Enterprise Linux comes as part of a subscription fee and has an enterprise-friendly roster of consultancy and paid support, an accredited training program, IP indemnification and managed upgrades. While the Red Hat Linux system is also available without payment of a subscription, it comes in a form that is harder to install, and important services such as managed updates are not available. The Fedora operating system, by contrast, is an open development project. It has no fees attached, and includes many of the technical features of Red Hat; however, it does not have the accompanying safeguards and services that Red Hat Linux boasts.

MySQL provides an SQL database system under a dual licence; the software is available in a copyleft licence package as well as a commercial licence aimed at system integrators. Similar to Red Hat, MySQL offers a suite of training and consultancy services and IP indemnification. The key differentiator is their dual-licensing; the copyleft licence is not suitable for developers wishing to incorporate MySQL software into proprietary and/or commercial software, so a commercially licensed version is also available.

Exim, the widely used message-transfer agent, is an example of a project that has been nurtured precisely because of demonstrable cost-savings to its host institution. Exim began as an internal project at the University of Cambridge computing services department in 1996 and since then has reduced costs at the University. Subsequent support has taken the form of staff resources and an externally delivered training programme. Finally, XenSource is an example of a project that grew from academic research and provided a revenue stream to its creators via managed bundles of paid support to third-party vendors.

Conclusion

We have seen that FOSS and commercial software are not antagonistic or mutually exclusive concepts. In fact, FOSS components and code are being increasingly accepted as part of commercial software and Gartner predicts that FOSS will form part of 80 per cent of commercial software offerings by 2012. This will provide a challenge for the sector, given that skills related to open source are still not widely available.

Further Reading

Links:

Related information from OSS Watch: