When I talk with with other people about Free-Libre / Open Source Software (FLOSS), I still hear a lot of people mistakenly use the term “commercial software” as if it had the opposite meaning of FLOSS (aka open source software, Free-Libre Software, or OSS/FS). That’s in spite of (1) the rise in commercial development and support for FLOSS, (2) most FLOSS projects’ goal to incorporate improvements (which are actually a form of financial gain), (3) official definitions of “commercial item” that include FLOSS, and (4) FLOSS licenses and projects that clearly approve of commercial support. Terms like “proprietary software” or “closed source” are plausible antonyms of FLOSS, but “commercial” is absurd as an antonym.
Nearly all FLOSS projects are commercial. In this essay I’ll explain why it’s so important to understand that FLOSS software is almost always commercial, and then give examples of each of those four points (listed above) to justify the claim that FLOSS is commercial. The essay then notes that many do not make this mistake, briefly notes some alternative terms, and ends with some conclusions.
It’s important to not confuse “FLOSS” and “non-commercial”. To see why, let’s first define our key terms, “FLOSS” and “commercial”:
As FLOSS has become more prominent in the computer industry, many speakers have tried to differentiate FLOSS from software released under other license terms. That’s fine, but some people have unfortunately been trying to use the term “commercial” as something distinct from FLOSS.
This confusion -- that FLOSS and commercial software are opposites -- is a dreadful mistake. Speakers who differentiate between FLOSS and commercial products, as if they were opposites, are simply unable to understand what is happening in the software industry.
And if you cannot understand something, you cannot make good decisions -- or even create good advice -- about it. Some concepts aren’t important, but software controls every important device on the planet. If you wish to understand the 21st century (and beyond), you need to understand the basics of what controls software... because software controls everything else. It is no longer acceptable to make such a terrible mistake.
So, with that in mind, let’s examine why treating “FLOSS” and “commercial” as opposites is fundamentally wrong.
This terminology is obviously a mistake if you look at what’s really going on in the world of software, where FLOSS is being increasingly supported by for-profit industry heavyweights with billions of dollars on the line. The Apache web server continues to support more websites than any other -- as it has for more than a decade -- and is supported by a large number of companies (including IBM). The Linux kernel powers many organizations, including Google; by 2004 it was noted that 37,000 of the last 38,000 changes in the Linux kernel were made by developers specifically paid to make those changes. Companies such as Red Hat, Novell/SuSE, and others are competing in the marketplace selling commercial GNU/Linux distributions. The Linux Foundation’s December 2010 report “Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It” (by Jonathan Corbet, Greg KroahHartman, and Amanda McPherson) found that 70% of the Linux kernel developers are provably being paid to do this work (I believe the real figure is much higher). Red Hat is listed on the NY Stock Exchange -- so it is a publicly-traded company -- and its primary product is a FLOSS product. Other companies such as MySQL AB (MySQL) and Troll Tech (Qt) develop and sell specific FLOSS products along with support for them. InformationWeek’s David DeJean astutely observes, “Is Open-Source A Business Model? $500 Million Says It Is” - noting that Citrix paid $500 million for XenSource (maker of the FLOSS Xen hypervisor). IBM says that in 2001 it invested $1 billion in Linux, and that by 2002 it had already almost completely recouped that investment, suggesting some astounding returns on investment. My paper Why OSS/FS? Look at the Numbers shows that market after market is being affected by the influx of FLOSS.
A 2008 report from consulting company Bluewolf found that “the advancement of open source software is triggering an increasing need for specialized application developers... higher-end, more complex application development proves difficult to complete overseas... The rise of open source software in application development puts developers with a specialization in those technologies in a position to ask for a 30 or 40 percent pay increase...” (see “Report: Open Source Adoption Increases App Dev Pay” by Nathan Eddy, ChannelWeb, 2008-02-26).
Venture capitalist behavior also shows that presuming FLOSS is non-commercial is a mistake. InfoWorld’s Savio Rodrigues reported on July 10, 2007, that venture capitalists have invested a sum total of $1.44 billion over the period 2001-2006. Back in 2005, John Cook (a Seattle Post-Intelligencer reporter) noted that Venture Capital firms think that FLOSS startup firms are hot commodities. A later report found that Open source funding is up 131% in 2006. Robert Mullins (IDG News Service) reported in December 2006 that “Open source is where the action is in 2007”. He noted that Bernard Dallé, general partner at the venture capital firm Index Ventures, said that “Proposals to invest in open source-based software companies increased by a factor of two or three in 2006 over 2005.” Not every such investment will yield reasonable returns, but venture capital investment is a pretty good sign that this is a commercial industry.
Some non-profit organizations support FLOSS, but were created to support for-profit commercial industry. For example:
Motivations for the use or support of FLOSS differ among different commercial organizations, of course. Many use and support FLOSS as a better support infrastructure for the product or service they actually sell -- i.e., cost avoidance by cost sharing. Others give away the FLOSS and sell the support (such as training, customization, and support/maintenance). Many for-profit organizations have realized the value of commoditizing your complements, that is, you’ll sell more of your product if things related to it (that you don’t sell) are cheaper. Other papers examine for-profit approaches to FLOSS in greater detail. A nice (brief) summary of FLOSS business models is “From Open Source to long-term sustainability: Review of Business Models and Case studies” by Chang, Mills, Newhouse. Another interesting paper is The Business of Free Software: Enterprise Incentives, Investment, and Motivation in the Open Source Community by Dr. Marco Iansiti (Harvard Business School) and Gregory L. Richards (Keystone Strategy, Inc.), who examined investments and showed that unsurprisingly, the FLOSS projects with a large amount of commercial investment involved companies with an economic reason to do so. The key thing here is to note that many FLOSS products are commercial (in the for-profit sense of the term), and FLOSS is becoming more so over time.
Even Forbes (Dan Woods, “The Commercial Bear Hug Of Open Source”, 2008-08-18) acknowledges that “the software created by open source communities became so powerful that commercial interests embraced those communities, supported them, learned from them and now are using the mechanisms of open source to make their businesses run better. This embrace has extended so long that commercial open source and open source are virtually synonymous.”
So even if you limit yourself to the “profit-oriented” definition of “commercial”, where profit is only measured using money, it makes no sense to say that FLOSS is the opposite of “commercial”. Someone who uses “commercial” as the opposite of FLOSS will often have trouble explaining why Red Hat is listed in the New York stock exchange (for example). Indeed, Red Hat, IBM, and even Microsoft have all released at least one FLOSS product, and they would be surprised to discover that they are not commercial companies. That should be enough to bury this nonsense. But that covers one definition of commercial; if you include the wider definition of “commercial” that means public trade, nearly all FLOSS projects are commercial.
FLOSS projects give their users many more rights than proprietary products do. Most developers do this with the expectation that others are likely to contribute back to the project (with new/improved code, documentation, bug reports, and so on). Thus, most “non-profit” FLOSS projects are actually trying to achieve financial gain -- it just happens that they are trying to receive gains of additional/improved software instead of money.
As Linux creator Linus Torvalds noted in a 2003 letter to SCO, the U.S. Code Title 17, section 101 (the law that creates and defines copyrights in the U.S.) explicitly defines the term “financial gain” as including “receipt, or expectation of receipt, of anything of value, including the receipt of other copyrighted works.” (Note the irony of a Finnish software engineer having to explain U.S. law to a U.S. company.) Thus, while FLOSS projects may not receive money directly, they typically do receive something of value in return -- namely, other copyrighted works (improvements).
When you consider the full definition of the word “commercial”, meaning anything that involves trade or dealings, nearly all FLOSS projects are commercial. Which should be unsurprising; economists often emphasize the difference between wealth and money. Some FLOSS projects attempt to earn money (directly or indirectly), but nearly all FLOSS projects attempt to create wealth in the form of improved software. And they attempt to create wealth via trade and dealings... a fundamentally commercial notion. Ganesh Prasad’s How Does the Capitalist View Open Source? captures this concept nicely, and it was written back in May 2001.
The U.S. Court of Appeals for the Federal Circuit has formally stated that there are economic considerations with FLOSS. The U.S. Court of Appeals for the Federal Circuit stated in their ruling on Jacobsen v. Katzer (August 13, 2008) that “Open Source software projects invite computer programmers from around the world to view software code and make changes and improvements to it. Through such collaboration, software programs can often be written and debugged faster and at lower cost than if the copyright holder were required to do all of the work independently. In exchange and in consideration for this collaborative work, the copyright holder permits users to copy, modify and distribute the software code subject to conditions that serve to protect downstream users and to keep the code accessible... Traditionally, copyright owners sold their copyrighted material in exchange for money. The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration, however. There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties. For example, program creators may generate market share for their programs by providing certain components free of charge. Similarly, a programmer or company may increase its national or international reputation by incubating open source projects. Improvement to a product can come rapidly and free of charge from an expert not even known to the copyright holder. The Eleventh Circuit has recognized the economic motives inherent in public licenses, even where profit is not immediate....”
It’s true that not all FLOSS projects actually receive such improvements. Many start-up FLOSS projects fail to receive any improvements, falter, and eventually become dormant. But that’s true about proprietary start-ups too.
Many official definitions of terms like “commercial item” include nearly all FLOSS programs. Let’s look at various official U.S. definitions and policies, to show that this is clearly true in the U.S.
The U.S. government’s own official definition of “commercial item” makes it clear that nearly all FLOSS programs are considered commercial items. The U.S. law governing federal procurement (specifically U.S. Code Title 41, Chapter 7, Section 403) is reflected in the Federal Acquisition Regulation (FAR) System widely used for acquisition (some organizations use more specific regulations based on the FAR, such as the Department of Defense’ DFARS). U.S. law and the FAR have a very detailed definition of the term “Commercial item” which clearly includes essentially all FLOSS; as noted below, specific organizations like the U.S. Navy have specifically stated this.
Before we look at that definition, let’s note that this definition is really important (it’s not just in some dusty, unused part of U.S. law or policy). The FAR specifically requires in part 12 that U.S. government agencies shall, by policy, try to use commercial items or nondevelopmental items wherever they can. More specifically, part 12 requires agencies to “(a) Conduct market research to determine whether commercial items or nondevelopmental items are available that could meet the agency’s requirements; (b) Acquire commercial items or nondevelopmental items when they are available to meet the needs of the agency; and (c) Require prime contractors and subcontractors at all tiers to incorporate, to the maximum extent practicable, commercial items or nondevelopmental items as components of items supplied to the agency.” What’s a nondevelopmental item? The FAR defines it as (1) Any previously developed item of supply used exclusively for governmental purposes by a Federal agency, a State or local government, or a foreign government with which the United States has a mutual defense cooperation agreement; (2) Any item described in paragraph (1) of this definition that requires only minor modification or modifications of a type customarily available in the commercial marketplace in order to meet the requirements of the procuring department or agency; or (3) Any item of supply being produced that does not meet the requirements of paragraphs (1) or (2) solely because the item is not yet in use. Since governments need a lot of software not developed exclusively for governmental use, the policy in the FAR turns out to be a rather strong requirement to use commercial items wherever possible.
So let’s walk through the U.S. government definition of “commercial item” as given by FAR part 2, which clearly shows that typical FLOSS programs are commercial items for purposes of the U.S. government. Here’s what they mean by the term “commercial item”:
The broadness of this U.S. government definition is no accident. DoD AT&L’s “Commercial Item Handbook” (November 2001) explains that the broadness of this government definition of “commercial item” is intentional, because it “enables the Government to take greater advantage of the commercial marketplace.” The DoD policy memo “Commercial Acquisitions” (Jan. 5, 2001), which can be found as Appendix A in a handbook, explains that the benefits of commercial item acquisition include “increased competition; use of market and catalog prices; and access to leading edge technology and ‘non-traditional’ business segments”. Note that those who created these definitions and policies anticipated that there will be changes in the commercial market, including “non-traditional business segments”. At least at first FLOSS was a non-traditional business segment, though at this point it’s probably fair to describe it as a major business segment. In any case, U.S. policy is to embrace changes in the commercial marketplace (like this one) where appropriate, and that has turned out to be very wise.
A related acronym used by many governments is COTS, which is short for “Commercial Off-The-Shelf”. Are nearly all FLOSS programs COTS? Yes, and officially so in the U.S. The paper COTS Based Software Development and Integration defines the term COTS as being (1) commercial, essentially per the FAR definition, and (2) off-the-shelf, meaning that it already exists. Thus, FLOSS programs that are already licensed to the public and have some non-governmental use are COTS.
As noted by Linux.com, Department of the Navy CIO Robert J. Carey signed a June 5, 2007 memorandum titled “Department of the Navy Open Source Software Guidance” to make this even clearer and counter misconceptions. He first notes that misconceptions about whether or not open source software qualifies as COTS (commercial off-the-shelf) or GOTS (government off-the-shelf) software has hindered the Navy’s ability to fully utilize open source software. He then goes on to clearly state that the Navy will “treat OSS as COTS when it meets the definition of a commercial item” in an enclosure to the memorandum, and that enclosure unsurprisingly uses the official definition of “commercial item”, including “(A) Any item, other than real property, which is of a type customarily used by the general public or by nongovernmental entities for purposes other than governmental purposes, and that (i) has been sold, leased, or licensed to the general public; or (ii) has been offered for sale, lease, or license to the general public.” In short, the Navy has issued an official memo stating the obvious - that the rules have not changed, and that when FLOSS meets the definition for a commercial item (true in nearly all cases), such items are commercial items. Indeed, I know that the Navy heard me present the information summarized in this paper (that FLOSS is commercial) - and it’s my understanding that they went back to check the rules, found that I was right, and released the memo based on an earlier version of this paper!
This Navy memo is in line with previous policy directives, such as the 2003 memo “Open Source Software (OSS) in the Department of Defense (DoD)” and Office of Management and Budget (OMB) memorandum M-04-16 “Software Acquisition” of July 1, 2004, which explicitly state that the U.S. Department of Defense and the entire U.S. federal government (respectively) are neutral with respect to FLOSS: FLOSS software must be given the same consideration that proprietary software is given. FLOSS is also clearly identified as commercial in OMB Memo M-03-14 “Reducing Cost and Improving Quality in Federal Purchases of Commercial Software”, - the memo title clearly states that it is about commercial software, and it specifically says that its SmartBuy initiative (which consolidates purchases) will include “open source software support”. All of these policy statements actively work to counter the bias against this new method (to many program managers) of developing commercial software.
Oh, and here’s an important clarification for those who work with the U.S. Department of Defense (DoD). The high-level DoD Directive 8500.1 is implementeed by Department of Defense Instruction 8500.2 (February 6, 2003), “Information Assurance (IA) Implementation”. Instruction 8500.2 lists various rules for deploying applications, and one of its rules is sometimes grossly misunderstood. Many DoD systems are subject to the 8500.2 control DCPD-1, aka “Public Domain Software Controls”, and some people have mistakenly thought that this text prevented the use of open source software in the DoD. They get that impression because they only read the first part of its text: “Binary or machine executable public domain software products and other software products with limited or no warranty such as those commonly known as freeware or shareware are not used in DoD information systems unless they are necessary for mission accomplishment and there are no alternative IT solutions available...”. But they forget to read the whole thing; the text ends this way: “The assessment addresses the fact that such software products are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the Government.” This closing text means that the entire control does not apply to FLOSS, because the the “fact” and the “givens” on which the control is based are manifestly not true for FLOSS. After all, the government (and others) do have access to the original source code, and they can “review, repair, or extend” it as they wish, since by definition FLOSS programs are programs whose source code can be read, modified, and re-released. I should note that for nearly all FLOSS programs there is also an owner who can make such repairs on behalf of the government, but that isn’t even required by this control. This control is focused on countering the risks of certain non-FLOSS programs: abandoned binary-only programs. I think it’s clear that this control does not apply to FLOSS, and thus this control does not limit the use of FLOSS in any way. This document does include other requirements, such as Common Criteria evaluations in certain cases, but many GNU/Linux distributions already meet these criteria, so clearly these requirements do not prevent the use of FLOSS in general.
DoD Instruction 5200.2 points to other official documents that support this interpretation. Its section E3.2.6 (Security Configuration Specification) states that “DISA and NSA support the Defense IA program through the development and dissemination of security implementation specifications for the configuration of IA- and IA-enabled IT products. Examples of such specifications include Security Technical Implementation Guidelines (STIG) and Security Recommendation Guides (SRG).” Basically, documents like the STIGs provide configuration advice for various systems to harden their security. For example, advice for hardening Linux-based operating systems is in the “Unix STIG”. The general STIG Desktop Application Security Technical Implementation Guide (STIG) Version 3, Release 1 (09 March 2007), section 2.4, directly discusses open source software. It states that the DoD does not require “that operating system software be obtained through a valid vendor channel and have a formal support path, if the source code for the operating system is publicly available for review.” It notes that “open source software takes several forms”, and specifically says that:
NSA’s own website for security configuration guides states, “NSA initiatives in enhancing software security cover both proprietary and open source software, and we have successfully used both proprietary and open source models in our research activities.” They then include guides for both proprietary products (like Microsoft Windows) and open source software products (like Red Hat Enterprise Linux). Notice that they don’t say “commercial and non-commercial”, because that would not make sense. Red Hat is a commercial company, after all.
There’s more, but you get the idea. Official U.S. documents, including U.S. law, lead you to the conclusion that FLOSS is commercial, and that it’s perfectly fine to use FLOSS. It’s not just in one place; I’ve listed U.S. law and regulations on federal procurement, U.S. copyright law, and many other official U.S. documents, all of which lead you to this conclusion. I am using U.S. examples, primarily because I am most familiar with the U.S. system. However, I suspect the same is true many other countries.
Is it possible for FLOSS to be non-commercial by these definitions? Yes, but it’s rare. By the U.S. government definition, software that is only used for government purposes is not commercial. But once software is released as OSS, people typically generalize it for more uses, so often software that originally has only government uses will soon pick up a non-government use. A program where the user has FLOSS rights, but will not make it available to the public, is also not commercial by these definitions. But normally FLOSS is commercial by these definitions.
The licenses, and the discussions surrounding both licenses and projects, also make clear that developers in FLOSS projects typically have no problems with commercial development and support, even if you use the narrower definition of “for-profit” for “commercial”. Indeed, many projects are established by commercial organizations as a kind of consortia (e.g., X Windows and Apache), while others are established by single commercial organizations (e.g., MySQL and Qt).
Official commentaries on the two common formal definitions of FLOSS both specifically state that FLOSS is not “non-commercial”:
The FSF goes further; in their article Selling Free Software, they say: “we encourage people who redistribute free software [FLOSS] to charge as much as they wish or can. If this seems surprising to you, please read on... When we speak of “free software”, we’re talking about freedom, not price... Since free software is not a matter of price, a low price isn’t more free, or closer to free. So if you are redistributing copies of free software, you might as well charge a substantial fee and make some money. Redistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it.”
The most popular FLOSS license in the world is the GNU General Public License (GPL), and in version 2 of the GPL it includes one method for copying and distributing the program (”method 3c”) which can only be used for noncommercial distribution (presumably they mean the for-profit definition). Since other methods are not so encumbered, the clear implication is that commercial (for-profit) distribution methods are permitted, as long as they obey the license. Which brings me to an interesting point that can cause confusion.
While the vast majority of FLOSS developers are happy with for-profit commercial development and support of FLOSS, they do not support companies that violate the program license or try to find and exploit legal loopholes in it. In some cases, organizations that violate FLOSS licenses have had to be brought into court so that they would obey the license. Many FLOSS developers become quite upset with companies that fail to obey the FLOSS software license, and external observers sometimes misunderstand this anger as a general opposition to commercial use by FLOSS developers. But this would be a mistake; such anger is directed at violators, not to commercial users in general. Such vehemence is typically true of proprietary software developers, too; proprietary software vendors are quite unhappy with those who do not obey the proprietary license, and are usually even more eager to bring a violator into court. In addition, proprietary licenses permit fewer actions than FLOSS licenses, so there are many more ways a commercial organization could accidentally violate a proprietary license (and risk being brought into court) compared to a FLOSS license. For example, making additional copies for multiple users is encouraged by all FLOSS licenses, but forbidden by most proprietary licenses (unless additional fees are paid). All commercial software developers, both proprietary and FLOSS, expect their users to obey the license provided or negotiate something else, as is required by law.
Some representatives of proprietary software companies leave the mistaken impression that all FLOSS programs are non-commercial. For example, Microsoft gave presentations in 2002 claiming that “research results placed under the GPL are precluded from commercial use”, “Government-funded research released under the GPL can never be commercialized” and “non-commercial software will have an artificial advantage over commercial if government-funded R&D is covered by the GPL” . The problem with these claims was that there were already commercial programs released through the GPL, including ones originally based on government funding. Besides, many government research results are only released to a single proprietary vendor (and not even other proprietary vendors); that is far more exclusionary than a GPL release, which would at least permit multiple vendors to follow up on the research results. Clearly, if a government believes that it will achieve its goals best by releasing some research result under a FLOSS license, it should do so. If a government is willing to release results to a single proprietary vendor sometimes, it should be willing to release under a FLOSS license like the GPL sometimes, for the same reasons. The same slideset correctly notes that the perception of open source (FLOSS) vs. commercial source is flawed, but incorrectly leaves the impression that FLOSS software cannot be commercial software. Gates made similar statements. It does not matter if this mistake is intentional or not; the key is to realize that this is a mistake.
Some supporters of the BSD licenses argue that the BSD licenses are more business-friendly. Supporters of the GPL retort by noting a number of companies (such as Red Hat, MySQL AB, and Troll Tech) that strongly prefer the GNU GPL as evidence that the GPL is more business-friendly. Yet others argue that the LGPL is most business-friendly. The reality is that different licenses are better for different business models, but that is not my point. What’s interesting here is that many people argue over which license is more business-friendly -- which I believe is simply a catchphrase for “commercial”. If so many people are arguing about which FLOSS license is best for commercial use, then clearly commercial utility is considered a good property of a license by many.
I should quickly note that many, many people do not make this mistake. Google searches show that many people use such terminology; a search on +”proprietary software” +”open source software” (requiring both phrases) found 511,000 web articles on January 2, 2007. Larry Rosen’s book “Open Source Licensing: Software Freedom and Intellectual Property Law” says in chapter 4, “The word proprietary is often confused with the word commercial. But a commercial license — which is merely a term used to describe a license used in commerce — can be either open source or proprietary.” Even the title of the 2001 paper Open Source Software: The Other Commercial Software by Hissam and Weinstock (Software Engineering Institute) makes it clear that its authors understand that FLOSS is another kind of commercial software. The Free Software Foundation has been distinguishing the terms “commercial” and “proprietary” for years. There is even a blog titled Commercial Open Source Software.
Microsoft’s relationship with FLOSS is complicated; they use many FLOSS components in their own products, they produce some FLOSS products (such as WiX and IronPython), and even run a site encouraging FLOSS products (CodePlex) but their money is primarily made by selling proprietary products that compete with FLOSS products. Nevertheless, even Microsoft (whose key products have FLOSS competitors) acknowledges that there are commercial FLOSS products in its paper “Microsoft and Open Source” (October 18, 2005).
Indeed, it’s so important that many governments have established organizations and research tasks on commercial FLOSS. Economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU examine the impact of FLOSS on the EU economy, which turns out to be substantial. The COSS (The Finnish Centre for Open Source Solutions is a national development agency for open source business ecosystem. It’s so important that UC Davis researchers have received a three-year, $750,000 grant from the U.S. National Science Foundation (NSF) to study how FLOSS is built.
As noted earlier, the Department of the Navy CIO Robert J. Carey signed a June 5, 2007 memorandum titled “Department of the Navy Open Source Software Guidance” affirming that FLOSS that meets the standard definition of “commercial item” and “COTS” really are “commercial items” and “COTS”. See Open Source Software (OSS) in U.S. Government Acquisitions for more about applying FLOSS to U.S. government acquisition.
The most common antonym for FLOSS is “proprietary software”, though there are other terms like “closed source”, “non-Free”, and “non-FLOSS”. Most terms have minor problems of one kind or another:
I tend to use “proprietary software” as the antonym, simply because it seems to be the most widely used and thus better understood. Any of these terms is better as an antonym compared to “non-commercial”.
It’s time to end the nonsense. Terms like “proprietary software” or “closed source” are plausible antonyms of FLOSS, but “commercial” is absurd as an antonym. The term “commercial” cannot be justified due to: (1) the rise in commercial development and support for FLOSS, (2) most FLOSS projects’ goal to incorporate improvements, which are actually a form of financial gain, (3) official definitions of “commercial item” (at least the U.S. government definition) that include FLOSS, and (4) FLOSS licenses and projects that clearly approve of commercial support.
Trying to use the word “commercial” as an antonym for FLOSS is becoming more absurd every day. Even if you use the narrower definition for commercial that means “for profit”, there are too many for-profit FLOSS projects for this use to make any sense. When you consider the full set of meanings for “commercial”, including the one involving public trade, nearly all FLOSS projects are commercial. In short, there are two kinds of commercial software: proprietary and FLOSS.
This has real-world implications. For example, many organizations prefer commercial software instead of home-grown software (for which they have to pay all of the maintenance costs). This implies that such organizations must search for and evaluate FLOSS projects when they search for commercial software, and if there isn’t an appropriate product available, they need to consider starting such a FLOSS project as one of their possible implementation approaches (examples of the latter are the devIS EZRO and the Georgia Public Library Service’s Evergreen systems). If acquirers ignore FLOSS options, they are ignoring an important and growing part of the commercial sector.
A speaker who uses the term “commercial” as an antonym for FLOSS is probably someone who doesn’t understand FLOSS yet. And someone who doesn’t understand the fundamentals of how software is governed will be constantly confused about what controls every device on the planet. Be wary of people who have such a basic lack of understanding; they are far less likely to give good software advice or to make good software-related decisions.
This paper was originally titled “Commercial is not the opposite of Free-Libre / Open Source Software (FLOSS): Nearly all FLOSS is Commercial”, but that seemed to be too complicated for many people. This simpler title retains the essence. An abbreviated version of this article appeared in the February 2009 Open Source Business Resource (OSBR.com), a monthly publication designed to contain “thoughtful insights on open source issues written for and by people who work with open source”. The article "Open Source Software Is Commercial" (Cyber Security & Information Center Journal, named at the time Journal of Software Technology and formerly named Software Tech News), is based on an earlier version of this paper but focuses on the laws and regulations that cover U.S. federal government acquisition. You can cite this abbreviated version as David A. Wheeler, “F/LOSS is Commercial Software” Open Source Business Resource, Febuary 2009, pp. 25-33.
See David A. Wheeler’s home page for more information and related articles, such as Open Source Software (OSS) in U.S. Government Acquisitions.
