WARNING: This document is made public for archival and historical purposes only. Not all of the information is current, and accuracy cannot be guaranteed.
As discussed in Sections 3.1 and 7.2 of this tutorial, the GPL only governs the activities of copying, modifying and distributing software programs that are not governed by the license. Thus, in FSF’s view, simply installing the software on a machine and using it is not controlled or limited in any way by the GPL. Using Free Software in general requires substantially fewer agreements and less license compliance activity than any known proprietary software.
Even if a company engages heavily in copying the software throughout the enterprise, such copying is not only permitted by GPLv2 §§1 and 3, but it is encouraged! If the company simply deploys unmodified (or even modified) Free Software throughout the organization for its employees to use, the obligations under the license are very minimal. Using Free Software has a substantially lower cost of ownership — both in licensing fees and in licensing checking and handling – than the proprietary software equivalents.
Using Free Software in house is certainly helpful, but a thriving market for Free Software-oriented business models also exists. There is the traditional model of selling copies of Free Software distributions. Many companies make substantial revenue from this model. Some choose this model because they have found that for higher-end hardware, the profit made from proprietary software licensing fees is negligible. The real profit is in the hardware, but it is essential that software be stable, reliable and dependable, and the users be allowed to have unfettered access to it. Free Software, and GPL’d software in particular, is the right choice. For instance IBM can be assured that proprietary versions of the their software will not exist to compete on their hardware.
For example, charging a “convenience fee” for Free Software, when set at a reasonable price (around $60 or so), can produce some profit. Even though Red Hat’s system is fully downloadable on their Web site, people still go to local computer stores and buy copies of their box set, which is simply a printed version of the manual (available under a Free license as well) and the Free Software system it documents.
Custom support, service, and software improvement contracts are the most widely used models for GPL’d software. The GPL is central to their success, because it ensures that the code base remains common, and that large and small companies are on equal footing for access to the technology. Consider, for example, the GNU Compiler Collection (GCC). Cygnus Solutions, a company started in the early 1990s, was able to grow steadily simply by providing services for GCC — mostly consisting of new ports of GCC to different or new, embedded targets. Eventually, Cygnus was so successful that it was purchased by Red Hat where it remains a profitable division.
However, there are very small companies that compete in this space. Modern industry demands the trust created by GPL protected code-bases. Companies can cooperate on the software and improve it for everyone. Meanwhile, companies who rely on GCC for their work are happy to pay for improvements, and for ports to new target platforms. Nearly all the changes fold back into the standard versions, and those forks that exist remain freely available.
A final common business model that is perhaps the most controversial is proprietary relicensing of a GPL’d code base. This is only an option for software in which a particular entity holds exclusive rights to relicense.1 As discussed earlier in this tutorial, a copyright holder is permitted under copyright law to license a software system under her copyright as many different ways as she likes to as many different parties as she wishes.
Some companies use this to their financial advantage with regard to a GPL’d code base. The standard version is available from the company under the terms of the GPL. However, parties can purchase separate proprietary software licensing for a fee.
This business model is at best problematic and at worst predatory because it means that the GPL’d code base must be developed in a somewhat monolithic way, because volunteer Free Software developers may be reluctant to assign their copyrights to the company because it will not promise to always and forever license the software as Free Software. Indeed, the company will surely use such code contributions in proprietary versions licensed for fees.
GPL compliance is in fact a very simple matter — much simpler than typical proprietary software agreements and EULAs. Usually, the most difficult hurdle is changing from a proprietary software mindset to one that seeks to foster a community of sharing and mutual support. Certainly complying with the GPL from a users’ perspective gives substantially fewer headaches than proprietary license compliance.
For those who go into the business of distributing modified versions of GPL’d software, the burden is a bit higher, but not by much. The glib answer is that by releasing the whole product as Free Software, it is always easy to comply with the GPL. However, admittedly to the dismay of FSF, many modern and complex software systems are built using both proprietary and GPL’d components that are clearly and legally separate and independent works, merely aggregated together on the same device.
However, it sometimes is easier, quicker, and cheaper to simply improve an existing GPL’d application than to start from scratch. In exchange for this amazing benefit, the license requires that the modifier gives back to the commons that made the work easier in the first place. It is a reasonable trade-off and a way to help build a better world while also making a profit.
Note that FSF does provide services to assist companies who need assistance in complying with the GPL. You can contact FSF’s GPL Compliance Labs at <licensing@fsf.org>.
If you are particularly interested in matters of GPL compliance, we recommend the next two parts, which include both recommendations on good compliance and compliance case studies.
1Entities typically hold exclusive relicensing rights either by writing all the software under their own copyrights, collecting copyright assignments from all contributors, or by otherwise demanding unconditional relicensing permissions from all contributors via some legal agreement