COMMENTARY--The International
Telecommunications Union's World Summit on the Information Society
(or WSIS for short, because we need more acronyms in
the world) was last week. The conference was
intended
as a forum to discuss the information technology
revolution, and more specifically, the growing
"digital divide" between rich and poor nations.
In practice, this resulted in a rather diverse set of talking points, as interest groups strove to link their pet issue to the central theme with varying degrees of success (among them a group that went by the name of The Geneva03 Collective, who was most notable for filling my inbox with "out of office" replies from every person registered as a member of the press).
Of particular interest, however, was a moderated debate on the issue of preferential treatment for open-source products in government procurement, a topic I have discussed in the past. Four of the panelists were pro-preference, and represented Malaysia, Cuba, Peru and Kenya. The lone voice opposing such preferences was Bob Kramer, Vice President for Public Policy from the Computing Technology Industry Association (CompTIA), a group upon which Bruce Perens has trained his ever-present "Microsoft is the source of everything bad that happens" machine gun.
The "pro" camp made good points, and you certainly couldn't fault them for failing to be close to the IT situation in their respective countries. There were a few misconceptions, however, regarding the role proprietary software plays in software development. In short, proprietary software is little more than a means of "monetizing" software so as to make it a source of growth and an attractor of investment, and that "monetization" is essential to the health and future growth of a software industry in developing nations.
Highlights of the pro-preference argument
Developing
nations have less money to spend on software than developed nations.
This makes initial cost a far more important discriminator than might
be
the case in rich nations. The "choice" can come
down
to use of free, open-source software or no software
at
all, as proprietary software, most of which comes
from
rich countries and is MUCH more expensive due to
exchange rate differentials, can cost too much from
a
licensing standpoint ("Total Cost of Ownership" only
matters if you can afford to start using IT
solutions
in the first place). The Malaysian representative
spoke of low cost PCs running Linux that were
shipped
out to villages, enabling them to use in some way
information technology without being hit by
expensive
licensing fees associated with proprietary products.
Delegates considered the ability to transition easily from one supplier to another to be an important requirement. Many expressed fear of proprietary company "lock in," where secret protocols and file formats make it hard to move to a competing solution. Admittedly, this may be a particular issue in markets just diving into the Information Technology pool, given that such environments can be expected to go through a certain amount of experimentation on their way towards a "final" software solution (though as anyone in the industry knows, there's no such thing as a "final" software solution, so this issue applies beyond the unique requirements of developing nations).
Lastly, delegates expressed an interest in stemming the flow of money that goes to software companies located in rich nations. An African member of the audience claimed that 80% of all money spent on software in his country went to the United States or Europe. Open-source software allows third world nations to stanch the outflow, leaving more money, at least theoretically, to go towards local software companies.
Why proprietary software exists
Ask yourself the following: how much of a "market"
exists for open-source software, and in particular,
GPLed software? By "market," I'm not talking merely
a
demand for the product. There will always be demand
for software that can be acquired and used for free
(as is the case with most GPLed software). I'm
talking about a true MARKET for software, one that
generates a strong and consistent profit and as a
result, attracts investment capital to the
development
of software as such.
A market certainly exists for high-exposure items such as Linux, though it's interesting to note that its biggest proponents are hardware-oriented companies such as IBM and HP, who are more likely to view software as merely a lead in to sales of hardware. Companies that concentrate on open-source software as such, such as Red Hat, have a much harder time turning a profit, as evidenced by Red Hat's massive rethink of its business model to favor customers who spring for the full Advanced Server over the "hobbyists" who play with the "Fedora" free product. Open-source software has managed to attract some paying customers, but it must be admitted that it hasn't done so in numbers comparable to proprietary software.
Why is this the case? The reason, quite simply, is that it is harder to sell something when a "secret" isn't involved (in this case, the source code), and when there is no restriction on subsequent redistribution of the final product. This revenue-unfriendly model is by design in the case of GPLed software, as even a casual reading of the writings of Richard Stallman, author of the GPL, should make clear. If we take away the possibility of great wealth, then after a while, when the people have readjusted their attitudes, they will once again be eager to work in the field for the joy of accomplishment (Stallman, Why Software Should be Free). What is questionable, however, is whether countries with an interest in domestic production, and the foreign investment and local jobs that entails, should subscribe to this.
Proprietary software exists for one simple reason: as a means of enabling software as such to generate revenue. When software generates profit, it enables companies to grow, attracts investment (as investors prefer profitable companies as a place to put their money) and enables those companies to grow into tremendous sources of innovation and local employment.
I'm not saying that governments shouldn't use open-source software. As I explained in a past article, "harvesting" the productivity of people willing to work for free is good for society. Furthermore, in cases where initial cost creates a choice between no IT solution and a free IT solution, open source is a very good option. However, harvesting the productivity of people motivated by financial return is ALSO useful, particularly given that such people account for the majority of programmers. Most companies associated with software creation rely on the revenue potential of proprietary software licensing, and ALL the largest (and most job-creating) software companies do.
In other words, it is important to support BOTH the proprietary and open-source development model in procurement practices, simply because both are sources of innovation that governments have an interest in encouraging. An open-source mandate on government procurement would merely serve to undermine the development of domestic software companies, the sort who might replace foreign sources of software if they could generate enough revenue to grow into larger companies.
Open protocols vs. open source
A useful goal of government procurement, however, is
to ensure that communication protocols and, to a
certain extent, data formats remain "open."
Governments have large varieties of IT systems, each
of which is tailored to the needs of individual
departments. These departments need to communicate,
and this is facilitated, to a certain extent, by the
use of open interoperability protocols and common,
open data formats.
This does not mean, however, that the source code IMPLEMENTING that protocol must be available for all to see, nor that that protocol/format must necessarily be free. The fact that the source code for a product that makes a web service call is publicly available does not affect whether or not that product makes the proper SOAP envelope (SOAP is a common, W3C-sanctioned protocol used in web services).
Verification of adherence to an open protocol is relatively easy to do, and does not require access to source code. The only reason, therefore, to demand that the source code for the implementation of a particular protocol and/or data format be public is to shut down proprietary software development. As noted previously, that is counterproductive if countries have an interest in building a vibrant domestic software industry.
Intellectual property and open source
One of the issues brought up by open-source
advocates
is that licensed Intellectual Property (IP), such as technology
embodied in a patent, can't be implemented
by GPLed code, which expressly forbids
non-transitive
licensing or licensing fees. This is an interesting
problem, particularly given that I am on record as
arguing against software patents.
However, as I've explained in another article, companies operating within a patent regime have no choice but to acquire patents in order to build defensive libraries and effect patent trades.
From a government procurement standpoint, I think it's fair to require that a communication protocol or data format be open to anyone who wants to use it (in other words, equitable licensing to competitors and non-competitors alike). Furthermore, I also think it's fair to require that such licensing be at no, or at least low, cost. I don't find it important, however, to accommodate a license which has artificially created a conflict with proprietary software by disabling the defensive power of intellectual property.
For patent libraries to act in a defensive capacity, sub-licensing CANNOT be automatic, as required by the GPL. Furthermore, I think it is rather draconian and unnecessarily dismissive of the innovation provided by proprietary companies to insist that any intellectual property be licensed at no cost. As noted in my article opposing software patents, companies such as IBM were built on the foundation of judicious use of the patent system. Of course, I think that the dangerous potential of software patents far outweighs any possible gain from proper use of such patents. However, short of abolishing software patents (which would be very hard to do, and either way, won't happen tomorrow), governments can walk the line between the dangerous and the useful by requiring legally-binding, low-cost licensing regimes for important and useful intellectual property.
Lots of innovative companies will attempt to leverage their state-granted monopoly rights over ideas (a.k.a. "Intellectual Property") as a means of generating revenue. Governments can moderate the more harmful byproducts of that power by securing legally-binding, low-cost licensing contracts for useful, proprietary IP. They gain nothing, however, by discarding the benefits of fee-based protocols or data formats simply on principle, as what matters most is harvesting human innovation, wherever it might come from.
In summary, the problem GPL code has with licensing is self-imposed, and should not be a trump card which overrules use of IP which isn't automatically sublicensed or charges a fee for use. There are plenty of alternatives to the GPL that do not create an artificial conflict with proprietary software.
Conclusion
Proprietary software is an extremely successful
business model. It has been very profitable, has
attracted lots of investment, and has enabled
software
companies to create large numbers of well-paying
jobs.
Many of the delegates in the pro-preferences camp lamented the lack of a domestic software industry and the need to send lots of valuable software capital overseas. It is important to recognize, however, that those large foreign software companies became centers of software innovation using the revenue-generation power of proprietary software.
Undermining that revenue-generation capacity is not the right way to encourage more domestic production. The right solution is to make no preference with respect to open-source or proprietary software. Instead, favor open protocols and data formats, leaving implementation details, and business models, to software companies to decide.
biography
John Carroll is a software engineer now living in Geneva, Switzerland. He specializes in the design and development of distributed systems using Java and .Net. He is also the founder of >Turtleneck Software.
| 12/16/03
