Open Source: Freedom, Responsibility and Choice

That idea has consequences far beyond programming. It affects who controls technology, how knowledge is shared, whether improvements can benefit others, and the choices available to people and organisations when their circumstances change.

Open source does not mean that everything is free of cost or that maintaining software requires no effort. It means that certain freedoms are deliberately preserved, allowing people to build upon existing work rather than depending entirely on whoever created it.

To understand why that matters, it helps to know what open source is, how it developed, what responsibilities accompany it, and why people continue to make their work available to others.

Source code is the human-readable form of software: instructions written by developers in programming languages. Some programs are compiled into machine instructions before they run, while others are interpreted or executed through a software runtime. In either case, access to the original source code makes it possible to study how the program was written and to modify it.

That access is what separates software you can only use from software you can investigate. Without the readable form you can observe how a program behaves and ask its author for anything more; with it, you — or someone you engage — can see why it behaves as it does, what it sends across a network, where a fault lies and where a change would go. The comparison sometimes drawn is a recipe and a finished cake, and it is useful as far as it goes: the recipe tells you how the thing was made, which the cake itself does not. Like most analogies it has a limit — a program can be rebuilt and rearranged in ways a cake cannot.

Open source is not a description of how software is made, and it is not a promise that the code happens to be visible. It is a set of permissions attached to software by its licence, and there is a widely used written definition of what those permissions must contain.

The Open Source Initiative maintains that definition and uses it to decide which licences count as open source. Its criteria require, among other things, that the software may be redistributed freely; that the source code be available in the form a programmer would actually use to make changes; that modified and derived versions may be created and distributed; that the licence place no restriction on who may use the software or on what they use it for; and that no part of it depend on a particular technology or style of interface. The definition was drawn from the Debian Free Software Guidelines, and it is the reason the term means something specific rather than something agreeable.

The distinction that follows from it matters in practice. A licence that lets you read the code but forbids commercial use, or forbids sharing your changes, is source-available but is not open source under this definition. A great deal of software is described as open when it is only visible.

Four different things are often spoken of as one when people discuss the freedom an open-source licence provides, and keeping them apart makes everything that follows easier to follow.

The permission. The licence grants rights — to use the software, to study it, to change it and to share it — subject to the conditions it sets. This is a legal position, and it is the only one of the four that a licence can settle by itself.

The access. Permission to read source code is of little use if the code, the documentation or the project's records are not actually available, or if the version you are running cannot be rebuilt from what was published. In open source the two usually arrive together, but they are not the same thing and they can drift apart: a project can be perfectly licensed and practically impenetrable.

The capability. Being allowed to change software is not the same as being able to. Somebody has to understand the system, have the tools and the time, and be prepared to take responsibility for the result. That may be you, a member of your team, or a developer you engage — but it is never nobody.

The other dependencies. Software rarely stands alone. A website depends on hosting, a domain, a data source, an integration, a payment provider, a set of working habits, and sometimes on services belonging to one particular platform. A licence can remove a legal obstacle to leaving; it cannot remove an obstacle that was never legal in the first place.

The practical conclusion is worth stating plainly. A licence grants permission; it does not supply the means. Open source creates the possibility of independent control, and a possibility is not the same as a working arrangement. An open licence is a necessary part of the position this project takes, and no substitute for architecture, documentation or skill. The sections that follow describe what the licence grants, what it requires, and how the project behind this site tries to make independence practical rather than theoretical.

Copyright reserves nearly everything by default. Someone who writes a program holds the right to decide who may copy, change and distribute it, and silence on the subject is not permission. Software becomes open source when its copyright holder grants those permissions to everyone who receives a copy, in a licence. Licences differ in the conditions they attach, and two broad shapes are common — though some licences sit between them, and some add conditions that apply only to a particular kind of software.

Permissive licences attach few conditions. You may generally use, modify and redistribute the software, including inside something you keep private, provided you observe the terms, which typically include preserving copyright notices and the licence text. Apache License 2.0, which this project uses, is permissive: it grants broad rights to use, modify and redistribute the work, it includes an express patent licence from contributors, it states that the software comes without warranty, and — like every copyright licence — it grants no rights in the copyright holder's name or logos.

Copyleft licences add a condition intended to keep the software open for the people who receive it afterwards: recipients are entitled to the same freedoms you were given, which is usually achieved by requiring that a version you distribute carries the same licence. The GNU General Public Licence family is the best-known example.

Copyleft licences are not all alike, and the differences matter more than the single label suggests. What triggers a requirement varies from licence to licence, and so does the scope of what it covers. Most commonly the trigger is redistribution — passing the software, or a modified version of it, to somebody else. Under particular licences, use over a network can trigger a requirement as well, which is why it is worth reading the licence rather than assuming. The clearest example is the GNU Affero General Public Licence, which is the ordinary GNU General Public Licence version 3 with one added requirement: if you run a modified version on a server and let other users communicate with it there, your server must also allow them to obtain the source of the version running there. That condition belongs to that licence and others of its kind; it is not a general rule of open source.

What no open-source licence requires is that you publish your own private work. A change you make and keep to yourself — not distributed, and not offered to others as a service where an Affero-style condition applies — does not trigger those requirements. This is one of the commonest misunderstandings about copyleft, and it discourages people from using software they are perfectly entitled to use.

The detail of licence conditions is a legal matter, and it matters most when you redistribute software or offer it to others as a service. Licensing and your rights is the page that deals with it for this project. A licence also describes permissions and not quality: it says what you may do, not that the software will suit your situation, remain maintained, or be free of faults.

Open source is sometimes described as if it began with a small group of people in the late 1990s. The Open Source Initiative's own account is more careful than that: development based on the sharing and collaborative improvement of source code has a history essentially as long as software development itself. What changed over the decades was not the existence of sharing, but the legal and commercial conditions under which it happened.

In the earliest decades of computing, software was often written by the people who used it or by the manufacturers who supplied the machines, and programs circulated between users. Research institutions treated shared code as a working norm, because a program that solves a common problem is worth more to a research community when it circulates. Manufacturers and user groups distributed programs and their documentation among members. The GNU Project's own history records that in the early 1970s even computer companies often distributed software without restriction, and that programmers were free to cooperate with one another and frequently did.

That picture should not be overpainted. Sharing was neither uniform nor universal: some of it was academic practice, some was commercial convenience, some was a way of making expensive hardware more useful to its owners, and a great deal of software was never shared at all. The history is closer to a collection of overlapping local cultures than to a single cooperative golden age — but it is equally wrong to assume that software has always been somebody's exclusive product.

What ended that arrangement was not one event but the growth of a market. Computing became cheaper and far more widespread; software became valuable in its own right rather than as an accessory to a machine; and companies found that they could license programs rather than supply them. By the 1980s the overwhelming majority of software was proprietary: it had owners who forbade and prevented users from copying or changing it. For anyone who wanted to adapt the software they depended on, a door had closed. The sharing did not stop — it persisted in universities, in standards work and in projects that were shortly to be built as a deliberate answer to the change.

The most direct answer to that change came from the GNU Project. Richard Stallman made the initial announcement of GNU in September 1983, describing a complete operating system that would be free software and compatible with Unix, and work began in January 1984. The purpose was explicit: to bring back the cooperative spirit of earlier computing by removing the obstacles to cooperation that proprietary software had imposed.

The order of work was dictated by necessity. A computer needs an operating system before it can do anything else, and every usable system at the time was proprietary, so a free operating system came first; an editor, a compiler, utilities, libraries and documentation followed. In October 1985 the Free Software Foundation was founded to support the work, and the GNU General Public Licence was designed for a specific reason. Rather than placing software in the public domain, where a later version could be made proprietary, the licence would keep software free for everyone who received it. The GNU Manifesto, published in 1985, set out the argument and asked others to join the effort.

That argument was ethical from the outset. Software freedom, in this tradition, is not chiefly a way of producing better programs, although it is often that as well; it is a claim about the people who use computers. Users — individually and collectively, and not only the authors of software — have interests that a licence should protect. The four freedoms in the table above are the statement of that claim, and the Free Software Foundation has held that position, largely unchanged in its essentials, ever since.

The GNU Project was not the only source of freely shared software, and the period should not be reduced to a single story. Berkeley's BSD system grew out of research Unix; it was nonfree when it was developed in the 1980s and became freely redistributable in the early 1990s. The BSD systems that exist today evolved alongside GNU rather than descending from it, and the two traditions have exchanged components in both directions ever since. Other work in universities, in industry and in standards bodies ran on its own paths. What the GNU Project did, decisively, was to make the freedom case publicly and in writing, and to build an operating system to stand behind it.

By 1990 the GNU Project had found or written the major components of its system except one: the kernel, the part of an operating system that manages the machine's memory, processes and devices. In 1991 a student named Linus Torvalds began developing a small Unix-like kernel, and released it as free software in 1992. Combined with the almost complete GNU system, it produced an operating system that anyone could run, inspect and change.

The name of that system is contested, and it is worth being straightforward about it. Most people call it Linux, and that is how it is normally described in public. The GNU Project asks that it be called GNU/Linux, on the ground that the shorter name understates the GNU components that make up most of the system. Both usages are established, the disagreement is a real one within the community, and this article uses "Linux" as the name in common use and "GNU" when it means the project's own components.

The more consequential change was in method. A single large system was being maintained by contributors who had mostly never met, coordinating through the internet, each working on the parts they needed. Similar groups formed around other shared infrastructure, and the pattern proved durable: a project could be improved by anyone affected by it, without anyone's permission and without a central employer directing the work.

The web server that carried much of the early internet developed in exactly that way. In February 1995 the most widely used server was the public-domain HTTP daemon written by Rob McCool at the National Center for Supercomputing Applications at the University of Illinois. Its development had stalled after he left in mid-1994, while many webmasters had built extensions and fixes of their own that had nowhere to go. A group of those webmasters began coordinating their patches; by the end of February 1995 eight core contributors had formed the original Apache Group; building on the NCSA code, they made their first public release in April 1995, and version 1.0 followed in December. Within about a year their server had passed the NCSA one as the most widely used in the world. The project became part of the Apache Software Foundation, which has provided a non-profit framework for intellectual property and financial contributions to projects of this kind since 1999.

Two things in that story are worth noticing. The work did not begin with a grand plan; it began with an abandoned program and a handful of people who needed it to keep working. And when it succeeded, it acquired an institution — a foundation holding the code, the marks and the donations, so that no single company owned it. Both patterns are now ordinary.

Collaborative development acquired a name of its own at the end of the 1990s, and the naming was a deliberate act rather than an organic one.

The moment was created by a commercial decision. On 22 January 1998 Netscape announced that it intended to release the source code of its browser for free licensing on the internet, to be posted from the first Communicator 5.0 developer release, expected by the end of that quarter, under a licence permitting modification and redistribution. That was an announcement of intention, not the release itself, and it showed a company choosing openness for business reasons rather than philosophical ones. The source code was published on 31 March 1998, which is the point at which the Mozilla project began; in the interval Netscape had announced the dedicated team and website that would host the work.

The name was chosen inside that interval. The label "open source" was created at a strategy session held on 3 February 1998 in Palo Alto, California, shortly after the January announcement, and the Open Source Initiative was formed in 1998 to promote the development method and to steward the licence definition. The reason for a new term was practical: "free software" was too often heard as a statement about price, which made it hard to put to a business audience, and the new label could lead with the practical case — better software, faster development, independence from any one supplier's decisions — without requiring an argument about ethics that many of those listeners did not want to have.

Alongside the announcement, Linux was being described in mainstream business publications, which carried the idea of shared development to people who had never met it, and around that time Eric Raymond published an essay contrasting the carefully planned release of commercial software with the noisier, open process he called the bazaar. The Open Source Initiative's own history describes it as published around the time of the Netscape release, and it remains widely read and influential — a participant's account rather than neutral history, but an influential one.

The two names now cover very nearly the same software and licence conditions, but they carry different emphases, and the difference has been argued about ever since. The Free Software Foundation's position is that the free-software movement campaigns for the freedom of the people who use computers, and that the later label describes the same software in terms of practical advantage while leaving freedom out of the argument altogether. The Open Source Initiative's position is essentially pragmatic: it maintains the licence definition and promotes the method, and it does not require anyone to hold a particular view about the ethics of software in order to use the term. Both accounts are worth reading; they describe the same events and value different things about them.

People give away their work for many reasons at once, and the mixture differs from project to project. Treating them all as idealists would be as inaccurate as treating them all as salespeople.

To solve a problem they have. A great deal of open-source software began as one person or one company needing something that did not exist, writing it, and deciding that publishing it was more useful than keeping it private. Others with the same problem send fixes, and the software improves for everyone using it.

To learn, and to be seen to be capable. Contributing to a shared project is one of the most direct ways to learn how a large system is built, and to demonstrate that ability. For many developers it is also a public record of their skill, which has real professional value.

Because shared infrastructure is cheaper shared. When several organisations need the same component — a date-formatting routine, a cryptographic library, a part of a web framework — maintaining it in common is more economical than each maintaining a private copy, provided the shared version can be inspected and improved by anyone who finds a fault.

To avoid depending on somebody else's decision. Organisations release software because they do not want their own ability to operate to rest on one supplier's continued interest. Releasing the code means they, and anyone else, can keep it working if they must.

Because they believe software should be free. For a significant number of contributors this is the central reason rather than a side effect, and the free-software movement is explicitly built on it.

Because it is their paid work. Companies frequently pay people to work on open-source software: sometimes on the projects they themselves depend on, sometimes as a way of establishing a standard, and sometimes to attract users to something else they sell. Corporate participation is now a large part of the ecosystem, and its motives are as often commercial as not.

For the community. Shared projects become places where people help each other, review each other's work and hold a common resource together. That is a benefit in its own right, and for some contributors it is the main one.

The ecosystem itself is not a romance. Many projects are abandoned; a great deal of important work rests on very few people; some contributions are made to gain influence over a project's direction; and some companies take part in order to shape a market. None of that makes the software worse, but it belongs in an honest picture.

The permissions in an open-source licence have practical consequences, and it is worth being concrete about which ones matter.

You can inspect the software: read what it does, check how it handles information, and satisfy yourself or your advisers that it is fit for what you need. You can change it: adapt a page structure, a workflow, a report, a translation — work that would otherwise be a request to somebody else. You can build on it commercially, including inside something you never publish. You can continue with it if the original author loses interest, because nothing was withheld that would prevent you, or somebody you engage, from maintaining it. And you can leave: the software is not tied to an account, a subscription or a supplier's continued generosity.

Those are real advantages, and they are advantages somebody has to make use of. A licence hands you capability, not capacity.

One distinction is worth drawing carefully, because it is easy to blur. The freedom to modify software is a freedom to change your copy, and to distribute your own version on the licence's terms. It is not a right to have your change accepted into the project you took the software from. Whether a particular change is incorporated is a decision for the people who maintain that project, under whatever arrangements it governs itself by: it depends on whether the change fits what the project is for, whether it is correct, whether anyone has time to review it, and on rules the project has agreed for itself. Openness makes contribution possible. It does not make inclusion automatic, and nobody can demand it.

Compliance is an obligation. Where a licence attaches conditions, they apply when you redistribute the software or, under particular licences, when you offer it to others as a service — commonly keeping copyright notices, licence texts and attributions intact, and in copyleft cases releasing modified versions under the same licence. That is ordinary work rather than legal theatre, and it is easier when the notices were never removed in the first place. The page on Licensing and your rights sets out what applies here; this article does not attempt to.

Maintenance is continuous. Software ages: dependencies change, faults are found, formats move on. A project is maintained because somebody chooses to maintain it. If nobody does, you either accept the risk, take the work on yourself, or pay someone to do it for you.

Competence is required somewhere. An open licence removes a legal barrier. It does not remove the need to understand what you are running: somebody has to configure it, deploy it, keep it patched and know what to do when it breaks.

Responsibility is yours. No licence obliges an author to fix anything for you, answer your question or keep a project alive. Support may come from a community, from a company selling services around the software, or from nobody at all. Openness does not arrive with a service level attached.

Security is not automatic. Being able to read the code helps, because faults can be found by anyone rather than only by the vendor. But readability is not the same as being read, and a project that nobody reviews enjoys no protection simply because its source is published.

An open-source licence can make software available at no cost, and that fact can obscure a simpler one: somebody, somewhere, is doing the work. Free to use is not the same as free to create.

Making software other people can rely on involves more than writing it once. Someone has to decide what it should do and what it should refuse to do. Someone has to design how the parts fit together, and keep that design coherent as it grows. Someone has to write the documentation that makes adoption possible, answer the questions the documentation failed to answer, review other people's changes, and say no often enough that the software stays comprehensible. Someone has to write tests, run them, investigate the failures, watch for security problems, follow the changing behaviour of everything the software depends on, and keep releases going when nothing is obviously wrong and nobody is thanking them.

This is ordinary, skilled, unglamorous work, and it is unevenly distributed. Many widely used projects are maintained by one or two people in their own time. Others are supported by companies whose business benefits from their health. Some are effectively unmaintained, kept alive by inertia, and quietly relied upon by thousands of organisations that have never heard of them. That is the reality the phrase "the commons of the internet" gestures at without describing.

The licence position, though, is what it is, and it is worth being exact about it. An open-source licence grants permission without payment; that is the point of it, and nobody who uses open-source software is doing anything wrong by using it and contributing nothing. There is no debt. What follows from the work is not an obligation but a choice, and the people who benefit most are simply the people best placed to help it continue, if they wish to.

For a business, the useful questions are not moral ones. Who maintains what we depend on? If that stopped tomorrow, what would we do? Can we look after it ourselves, or pay someone who can? Those questions are worth answering whether or not the software is open source.

Open-source projects continue because people choose to keep them going. There is no mechanism that sustains them automatically, and no shortage of projects that stopped when that choice was no longer made.

Those choices take many forms, and none is more respectable than another. Using a project well — deploying it, keeping it current, telling others what worked — supports it, because a project with satisfied users is easier for everyone else to trust. So does reporting a fault, suggesting an improvement, giving feedback, helping another user who is stuck, or contributing documentation or code. Financial support is a further option, and an entirely voluntary one: a monthly sponsorship, or a one-off contribution. None of these is necessary, and none is preferred over the others. A project that is widely used and never paid for has been used exactly as it was intended to be used.

Somebody who reads this page, builds a site and never contacts anybody has done nothing wrong. Somebody who reports one documentation error has done something genuinely useful at almost no cost. The only thing out of place here would be treating any of it as an obligation, because it is not one.

There is a wider point, too, which matters more than any single project. A modern business rarely depends on one piece of software; it depends on a stack, most of it written by strangers. Some of those projects are healthy, some are maintained by one person in their spare time, and some have nobody behind them at all. If this page prompts anyone to look after the open-source software they rely on — here or anywhere else — it will have done something more useful than describing itself.

The pages on Contribute and Support Foundation explain the practical options for this project, and what each of them does and does not change.

Everything above describes open source in general. This section is about one decision.

Provelopment Foundation — the platform template this website describes — is released under the Apache License 2.0. The licence was chosen deliberately, and the choice followed from what the project is for.

Foundation exists to be a reusable starting point for informational business websites, so that the same underlying work — routing, page structure, navigation, metadata, language handling, accessible presentation, validation and deployment — does not have to be built again from nothing on every project. That purpose would be contradicted by a licence that permitted adoption and then limited what an adopter could do with the result.

Apache-2.0 was selected because it allows broad independent, private and commercial reuse: a business may adopt Foundation, modify it and build on it, and its own implementation does not become open source as a result. It grants copyright permissions together with an express patent licence from contributors, which a shorter permissive licence is often silent about — and that was one of the reasons for choosing it. It does not transfer exclusive ownership of the original code to each adopter; it grants the broad rights the licence sets out, on the conditions the licence sets out.

Two boundaries are easy to blur. Foundation's own code and documentation is openly licensed; the third-party material it contains or depends on keeps its own licence, attribution and provenance, which the project records and does not relicense. And a copyright licence grants no rights in the Provelopment name, logos or branding, and implies no endorsement of anything built with the software.

The commercial posture behind this is deliberately non-locking, and it is a fact about the architecture rather than a promise in a brochure. The free project is intended to be independently useful and usable with no commercial relationship with Provelopment at all, and it is not made artificially incomplete, awkward or crippled in order to steer an adopter towards a paid service. A site's content, configuration and branding travel with the implementation, and nothing in the architecture is designed to prevent an adopter from leaving with them and operating elsewhere. Help is something Provelopment offers and hopes to earn a living from, not a condition of using the software. The project's own summary of the position is: we give you the code and the instructions; if you need help, we're here. Staying with Provelopment is a service choice, not a technical hostage situation.

The distinction at the centre of this page is worth stating on its own. Open source creates the possibility of independence. Good architecture, documentation and responsible stewardship make that independence practical.

A licence that permits you to leave is worth little if the site you built cannot be moved. A repository that nobody can understand is not truly open to anyone. A platform whose core must be edited for every change makes taking upstream improvements painful, which is a softer version of the same dependence.

Provelopment Foundation works on the parts a project can actually control. Customisation is expressed in configuration, content and assets rather than in edits to the core, so a site can look and behave entirely differently without forking the platform, and the platform's own logic stays separate from what the site says and shows. Content is kept as files in the site's own repository rather than trapped inside a supplier's account. The parts of a site that inevitably depend on somebody else — mapping, booking, messaging, analytics — sit behind provider-neutral interfaces, so the service behind them can be changed without rebuilding the site. That is a boundary drawn deliberately, and not a claim that those dependencies disappear.

Keeping platform code separate from content and configuration makes maintenance and upgrades more manageable, and that separation is the reason for the boundary. It does not make them free of work. Taking an improvement from upstream is a controlled process rather than an automatic one: deciding whether it is wanted, reading what changed, reconciling it with any local differences, testing the result and reviewing it before it goes live. Anything else is a description of an aspiration rather than a process.

None of this makes independence automatic, and none of it is a guarantee about the future. It makes leaving possible, which is the point: independence you cannot exercise is not independence.

One clarification, because the two are easily confused. The Foundation product and this website are not the same artefact. Foundation is an open-source platform template, published on its own and usable in any suitable project; this site is the project's own information home, built on the same platform and describing it. Claims about the product's licence and capabilities belong to the product.

Foundation itself is free to obtain and use under its licence. Running a website is a separate matter: building it, configuring it, hosting it, maintaining it and operating it take time and resources, and somebody has to supply them. No licence can change that, and this one does not try to.

So the choices are the ordinary ones. You can do the work yourself. You can engage a developer or an agency of your choice. You can ask Provelopment for help, on whatever basis you agree — a one-off setup, agreed maintenance on a site you hold, or a fully managed arrangement — or you can combine those. None of it is required in order to use the software, and nothing in the platform has been left deliberately incomplete in order to make paid help necessary.

How those arrangements work, what each of them means for the accounts and the files, and what a handover involves are set out on Ownership and portability. The subject here is the software and the licence behind it.

Open-source licences are unusual in one respect: they widen your options and then leave the decision entirely to you. Nothing on this page is an instruction, and nothing about the project is an obligation.

Open source gives people more choices about the software they use and the work they build upon. Those choices include using it independently, improving it, sharing it, contributing to its development, supporting its maintainers, or simply learning from what others have made.

There is no single right way to participate. The important thing is that the choice remains yours.