“Open source” is a category of licences, not a price list. The Open Source Definition, published by the Open Source Initiative in 1998, lists the criteria a licence must meet: free redistribution, source code available, the right to make derived works, no discrimination against persons or fields of use. A program can meet all of them and still charge for itself; it can break one and still run free. For a small business deciding what to rest its technical infrastructure on, that is the first distinction to settle.

Context

In two years open-source software has come out of the university labs and into companies’ purchasing decisions. Apache has been the most widely used web server on the network since April 1996, according to Netcraft’s monthly surveys, and in 1999 the group that writes it gave itself a legal form with the Apache Software Foundation. In January 1998 Netscape announced the opening of its browser’s code, published the following March under the Netscape Public License. On the financial side, Red Hat’s flotation in August 1999 and VA Linux’s in December carried the subject beyond the circle of technicians.

For a small business this means that an open-source stack — a Linux- or BSD-derived operating system, Apache for the web, a language such as Perl or Python, a database — is now a concrete, documented choice rather than a gamble. The question is no longer “does it work” but “what obligations am I tying myself to”.

What the licence says

The licence is where the practical consequences gather. It is worth keeping at least three families apart.

Copyleft licences, of which the GNU General Public License version 2 (published by the Free Software Foundation in June 1991) is the most widespread example, oblige anyone who redistributes the program — or a work derived from it — to do so under the same licence, with the source available. The obligation is triggered by distribution, not by internal use. A small business running its own systems on GPL software need publish nothing; it must do so only if it hands a derived program to third parties.

Permissive licences, such as BSD-style ones or the Apache licence, let the code be redistributed even inside closed products, usually asking only that the copyright notice be kept. Whoever builds a proprietary product on a permissive base has more room to close it; whoever contributes has no guarantee that their changes will stay open.

Hybrid licences, such as the Netscape Public License with which the browser code was opened, oblige modifications to the original code to be shared but allow it to be combined with separate proprietary modules.

Choosing among these families decides what can be done with the software three years from now, and what the suppliers one relies on will be bound to do. It is an operational decision, not an ethical option.

The critical point: supplier dependence

For a small business the soundest technical argument for open code is reduced dependence on a single supplier. With proprietary software, data formats and protocols are often known only to whoever produces them; if that supplier closes, adjusts its prices or drops the product, the company has no low-cost way out. The Open Source Definition demands source availability and the right to derived works precisely to keep that way out open.

The consequence can be felt directly. If the supplier of an open-source mail system disappears, the code remains, the messages stay readable, and another technician can take over maintenance. This property holds even when the supplier does not disappear: it makes the relationship less one-sided, because leaving costs less.

There is a flip side, and it is not minor: responsibility for maintenance changes hands. With a proprietary contract you pay someone to keep the system running; with open-source software adopted without support, that someone has to be in-house or has to be hired. Available source is a necessary condition for independence, not a sufficient one: exercising it takes competence.

What follows for those choosing

For anyone deciding today, some consequences are immediate. Check the real licence of every component before building on it, because “downloads free” and “open-source licence” are not the same thing. Keep internal use apart from redistribution, because copyleft obligations trigger on the latter. Assess the support supplier separately from the licence: the licence says what you may do with the code, the support contract says who answers when something breaks.

For a small business whose work is integrating open-source software, there is a further effect. What it sells is not the code, which everyone has, but the competence to choose it, integrate it, adapt it and keep it standing. The market for support and integration around Linux and Apache, made visible by the 1999 stock listings, rests on exactly that. noze, the company set up in Pisa around a Linux, Apache, Python and Zope stack, is built on that same choice — competence in open-source integration sold as a service — as described in the insight published by noze: https://www.noze.it/en/insights/noze-founding/.

Limits

The above concerns the contractual and operational consequences of adoption, not the technical quality of individual programs, which must be weighed case by case. The list of licences approved by the Open Source Initiative is in motion and new licences are under review; to know which requirements apply to a real case you have to read the text of the specific licence, not a summary. The reasoning about supplier dependence assumes that adequate skills exist in-house or on the local market, and in mid-1999 that condition is not uniform everywhere.

Cover image: Linus Torvalds, creator of the Linux kernel, in a close-up portrait while speaking — photo by unknown author, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Linus_Torvalds.jpeg