Intellectual Property Rights and Open Source

Paper in advance of Board Meeting, 5th August 1999

Simon Brooke

Introduction

The Weft business plan as currently drafted is based partly on the concept of developing IPR capital by creating proprietary software components whose source is guarded and kept secret. This has been a conventional concept in software industry business plans for a number of years. However, reading that I have been doing recently have brought me to the view that this concept, if it ever was more than a snare and a delusion, no longer works under modern conditions; and the principle reason it no longer works is the rapid growth of the open source movement.

What is Open Source?

The Open Source movement in the software community is an outgrowth of a much older movement, the Free Software movement. Broadly, both these movements aim to distribute software complete with its source code, under licencing terms which allow the user to make changes to the code and, critically, distribute the code either with or without modifications to others. More and more software is now distributed under open source licences, to the extent that it is now possible for purist Linux distributors to distribute complete working systems comprising only open source components.

In many significant software niches, open source products are either the dominant product (Apache, for example, represents over 55% of all Web servers; BIND represents over 85% of all name servers), or compete only against other open source products (while Sendmail is the most widely use SMTP mail server, it competes against QMail and XMH, both of which are also open source).

Why is software different?

In no other industry is there a movement to give away not only the product but also the design. So why is software different?

Fundamentally, the difference is this: software can easily be reproduced and distributed at no cost, whereas marketing it is expensive. Consequently, there are three models under which software can be distributed:

Mass marketing, where the cost of development is ammortised over very many sales at low per-unit price
Custom marketing, where the cost of development is ammortised over relatively few sales at much higher price, justified by notions of bespokeness or customisation
Free distribution, where the cost of development is not recovered at all.

On the face of it, the first model looks overwhelmingly the best. But in practice to achieve the volumes at which distribution through the retail channel becomes viable requires expenditure on packaging and marketing which small businesses cannot afford.

Consequently, the second model is the one typically followed by small software development businesses.

On the face of it, the third model looks so bad that you wonder why anyone would consider it. But the answer becomes clear when you look at the effect of use on code quality: the more people who are using a piece of code, the more quickly bugs will be found and, if you are efficient, corrected. Consequently, the code will mature to a reliable state much more quickly. Thus free distribution may actually increase the value of the code to its originator.

This effect is enhanced when the source code is also given away, because other programmers using the code can correct bugs as they find them and report bug fixes back for integration into the main corpus of code.

But the further effect of free distribution is its effect on the visibility of the originator. If large numbers of people are using software, its visibility necessarily increases. So too, if the identity of the originators is clearly indicated in the distribution, does the visibility of its originators. So free distribution of useful software has the potential to be a powerful marketing tool, provided the originators can derive an adequate revenue stream from other products and services which users of the free product are likely to need.

The Quality Problem

The issue of quality and open-source software is well rehearsed in Eric Raymond's famous paper, The Cathedral and the Bazaar. In brief: open source software which is widely distributed and widely used will increase in quality much more rapidly than software which is developed by a closed team, simply because the number of informed testers and bug-fixers is higher.

This is reflected in Miller, B P, et al: Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services:

The result of our testing is that we can crash (with core dump) or hang (infinite loop) over 40% (in the worst case) of the basic programs and over 25% of the X-Window applications... The reliability of the basic utilities from GNU and Linux were noticeably better than those of the commercial systems...

The failure rate of utilities on the commercial versions of UNIX that we tested (from Sun, IBM, SGI, DEC, and NEXT) ranged from 15-43%.

The failure rate of the utilities on the freely-distributed Linux version of UNIX was second-lowest, at 9%.

The failure rate of the public GNU utilities was the lowest in our study, at only 6%.

Small software houses offering products in competition with open source offerings could reasonably expect to compete if they could represent to customers that their proprietary offering had a significant quality premium: but as customers become increasingly aware that the opposite is likely to be the case, this case is going to be increasingly hard to make.

Solutions and Components

There probably was a time once when if you wanted a new piece of software you had to write it completely yourself from the bottom up. This is no longer the case. Software is made of components and in most cases the components are layered many layers deep.

Increasingly, there are open-source products in the component niches. There are open source compilers for almost all computer languages; open source servers for almost all protocols; open source data engines; and so on. Indeed with the exception of the Java Development Kit, all the components I have used so far in projects for Weft have been open source. The Java Development Kit, while free, is not at present open source, but an open source replacement for it is in preparation.

The availability of open source components is clearly a benefit for small software houses, in that these components are available to us at no cost, and are of high quality.

Components are not, however, things which end-users of software buy. End-users want solutions, and while many solutions are generic, there remains a large niche of solutions which are specific to a particualr customer or small group of customers: it is in this niche that small software houses can exist.

Weft's strategy

So what do we do with our own components, those we develop ourselves to support the solutions we deliver? We currently do have a our own servlet libraries, developed initially because at the time we started using servlets very few other people were, and there were no libraries available. This is not longer true. There are essentially two routes which I can see us pursuing:

Adopt another supplier's servlet technology, probably Enhydra
Continue to develop our own servlet technology, but release it under open source licence

The third possibility, of continuing to develop our own whilst keeping it private, isn't going to work in practice because we don't have the development effort to invest in it and consequently it would gradually fall behind the open source offerings in terms of quality and features.

If we are to adopt the second course, of releasing our own technology open source, there are still a range of degrees of openness we can adopt:

We can adopt an Apache style licence, which says that the users can use our software, can alter it, and give the results away, and can sell products made by using it;
We can adopt the GNU General Public Licence, which says essentially the users can use our software, and alter it, and give the results away, but may not sell it or sell products made using it;
We can adopt a Mozilla style licence, which says that users can use our software, and alter it, but must communicate their alterations with us and cannot distribute altered versions;

Conclusions and Recommendations

I would recommend that we prepare to release our existing servlet technology under Apache licence, and make it freely available from our own FTP server. I believe that it is good enough to find a niche in the market and become reasonably widely used, for Web-database integration solutions.

Doing so would have the following benefits:

Our own customers would have confidence in their continued access to our code, even in the event of Weft ceasing trading;
Other programmers would identify and currect bugs in the code, and communicate those bugs with us, increasing the quality of the software;
Weft would become widely known as an innovative producer of software, and this would provide us with a marketing visibility which we could build upon to increase sales of consultancy and development services.