Working on free software, you earn your revenue from the services around the code, not from selling copies of the code itself. The distinction is plain enough in contractual terms, but it changes how the technical work is organised and changes what is actually sellable. I am writing it down because over these months I keep hearing it raised as an objection — “if the code is free, what are you selling?” — and answering it takes more technical detail than the objection lets you imagine.

Context

By 2006 the subscription model has stopped being a wager. On 5 June Red Hat acquired JBoss, and on 18 September it released the Red Hat Application Stack, folding the JBoss middleware into its own certified offering. The two companies had the same economic arrangement: the software is free and anyone can download it, while the subscription covers support, maintenance, updates and — a point often underrated — the certification that the software works alongside the rest of the customer’s stack.

For anyone working this way the released code is not the object of the sale. The object is continuity: the assurance that someone knows that code well enough to fix it, update it and keep it running next to a production system. It is a property no tar command copies.

What makes free software sellable

Three technical properties, independent of the licence, decide whether a service can be built around a free project.

Knowledge of the code and its domain. A production system breaks in ways that are not in the manual. Reading an application server’s stack trace, working out why a query degrades under load, or why a third-party library clashes with a kernel update: that is competence built up over years, and it does not transfer with the source. The customer pays for this ability to intervene, not for the .java or .c files.

Contractual responsibility. Free licences — GPL, BSD, MPL — exclude any warranty in writing. The GPLv2 puts it in capitals: the program is provided “as is”, without warranty of any kind. A firm that places itself between the upstream project and the customer takes on the responsibility the licence disclaims. The value sits exactly here: there is a named party, with an address and an invoice, who answers when the system stops.

Integration and certification. The least visible and most expensive piece. Getting a database, an application server, an operating system and the customer’s applications to work together takes repeated testing on real configurations. This is exactly what Red Hat sold with the Application Stack: not the software, but the tested assurance that those components run together.

The state of licensing at the close of 2006

On the legal side, 2006 is a year of settling. On 16 January the Free Software Foundation published the first discussion draft of the GPLv3, opening the public revision of the most widely used copyleft licence. In the meantime the GPLv2 (1991) remains the working standard: it is the licence under which most of the software one works on today still runs.

In parallel, the Open Source Initiative took on the problem of licence proliferation. The Proliferation Committee’s report, accepted by the board in 2006, regroups the OSI-approved licences into descriptive groups — among them one for licences that are “popular, widely used or have strong communities” — and recommends a guided tool for choosing them. The motivation is practical: too many near-equivalent licences make it hard to assess compatibility and reuse, which are technical problems before they are legal ones. In the same year the OSI published its Open Standards Requirement for Software.

For a firm this carries real weight: the licence of the project on which a service is built decides which other components that project can be combined with and redistributed alongside. The GPLv2 is strong copyleft: linking a GPLv2 library binds the whole result to a compatible licence. Knowing this before starting an integration spares you a rewrite once the project is under way.

Critical point

The fragility of the model lies in its dependence on competence, not in the licence. If what you sell is knowledge of the code and the ability to intervene, then the firm’s asset is the people who hold that knowledge, and the risk is their replaceability. It is the reverse of the proprietary-licence model, where the asset is a transferable, archivable right.

From this follows something that bears directly on how the technical work is organised: documenting, splitting knowledge across several people and contributing upstream are not optional extras. Contributing to the upstream project narrows the gap between the code the customer runs and the code the team knows. The more that gap widens — because local, unmerged patches pile up — the more maintenance costs, and the more it depends on whoever wrote those patches.

Implications

The model holds as long as the firm stays close to upstream. Selling support on a private fork of a free project produces the same lock-in costs as proprietary software, with the added disadvantage of bearing them alone. The opposite direction — contributing, keeping the gap small, letting the changes made for customers flow back into the public project — lowers the marginal cost of each new installation, because every customer inherits the work done for the previous ones.

Limits

This note describes the subscription-and-support model, one way to build a business on free software, not the only one: dual licensing, bespoke development and service hosting also exist, each with different constraints. The licence-compatibility points here are general; any concrete combination needs case-by-case checking, and the GPLv3 — still in draft as of today — may change some of these constraints once it is finalised.

A small firm working with exactly this subscription-and-services model is noze, recognised for the choice by the Premio Imprenditoria Giovanile (Young Entrepreneurship Award): https://www.noze.it/en/insights/young-entrepreneurship-award/.

Cover image: the noze logo.