These arguments may not be enough to convince some people. There are frequently arguments advanced in opposition to the free software concept. Raymond refutes some of them in 13, but he doesn't take a utilitarian or even an ethical perspective in his arguments. Here, some of these objections are phrased in utilitarian terms, with corresponding answers.
Programmers Need Pay
This is often the first objection to the free software idea. The general idea is, "if software is available at no cost, then nobody will be able to pay the programmers, and they will have to give up their coding skills and find another profession." In utilitarian terms, the argument means "since programmers can't get paid for no-cost software, they will either starve or have to give up their chosen profession, causing unhappiness for them."
However, this argument doesn't work because the premise is flawed for several reasons. First, current estimates put the amount of code written for companies to be used in-house at over 75%. 14 The people to write this code will have to be hired in any case. Then, there is the fact that most time spent in software development is maintenance—fixing bugs, adding new features, and changing the program to meet new demands.
There's No Liability
A lot of corporate officials want to have a "cushion" in case something goes wrong with their software. That is, if the software doesn't work, they want to be able to sue the vendor. To put this argument in utilitarian terms, if a company is hurt because of the problems in the software sold by somebody else, the hurt company wants payment to make up for that harm.
However, this sort of argument ignores several issues. First, much of the most important or most common software for the computer, such as the operating system, is sold under a license that explicitly releases the software vendor from any such responsibility. In many cases, the vendor doesn't even guarantee that it's useful for what it's sold for. It would be difficult or impossible to collect any sort of money from such a vendor.
Secondly, this argument also ignores the fact that free software is less likely to have problems in the first place. If the software is less likely to have problems, there's a smaller chance that there is going to be any harm at all—a utilitarian win.
Third, there are various support companies that can provide guaranteed response time to problems with free software.
Finally, the argument ignores the legal time and cost involved with suing a software vendor. Sometimes this expense is so prohibitive that the hurt company will just take the loss and not try to sue anybody.
In some cases, releasing source code to the general public could be harmful. These cases are extremely rare, and can generally be considered to be limited to that code which is responsible for controlling systems that have significant physical destructive power. This is similar to existing precedent. For instance, while it is generally agreed that exchange of knowledge and ideas is good, the consequences of widespread dissemination of information detailing how to build an atomic warhead override the normal considerations. This is not a strike against free software; rather, it's a reflection of the unfortunate reality that software can be used to kill, and some knowledge ensures human safety better by being withheld. Source code, in this case, simply acts as something that carries the knowledge of these devices. One could write down the information on paper and achieve the same effect. The problem lies not with free software, but rather with the awful burden software is being asked to carry. In utilitarian terms, we can clearly see a great possible harm if knowledge about anything that can cause significant physical destruction gets into the wrong hands.
Many of the benefits derived from free software come about due to the efforts of programmers around the world. For instance, a company might realize that it's great to be able to fix problems when they occur, but the company may not have anyone on staff capable of fixing programming mistakes or making custom enhancements.
Fortunately, this is not really a problem. First, if good problem reports are sent to the author, a task that does not require programming skill, most free software authors respond to them in an amazingly short period of time. Secondly, consultants or contract programmers who understand free software are plentiful. Finding solutions to problems does not require programming knowledge; there are numerous ways to get support for free software programs.