Your website, your choice

Owning a website is not one thing. It is a bundle of separate things that are easy to conflate: the software the site runs on, the words and pictures it publishes, the settings that describe your business, the address people type, the account that serves the pages, and the services the site talks to. In practice, control over a website is only as strong as your control over each of those parts separately.

That is why "you own your website" deserves explaining rather than asserting. A licence can be permanent and still leave you unable to move, if the address, the hosting account and the build settings belong to somebody else. A copy of the files can be yours and still be useless, if the system that turns those files into a live site is not part of the arrangement. Ownership that cannot be exercised is a promise rather than a position.

Foundation was built with that distinction in mind. The platform is a shared public product under an open licence; the site you build on it is yours. Where the accounts that serve your site sit — with you, or with us under a managed arrangement — depends on the operating choice you make, and this page is explicit about which is which. What follows describes each part of the arrangement in turn, what a handover looks like in practice, and what changes if you decide to work with someone else.

Foundation's own code and documentation are licensed under the Apache License 2.0, one of the most widely used permissive licences in existence. Under it you may use, modify, distribute and commercially exploit the platform, including inside a website you keep private, on the terms the licence sets out — chiefly keeping the copyright notices and the licence text intact. There is no licence fee, no account and no renewal to keep using it: the permissions are irrevocable, so they cannot be withdrawn from you, or from anyone else who has received the software, at a later date.

That is a statement about permissions, and it is worth separating from the things that keep a website serving. A licence cannot guarantee that a domain stays registered, that a hosting provider keeps trading, that a third-party service stays available, or that an account stays open. Those depend on the accounts, the providers and the arrangements in place — which is precisely why the rest of this page is about who controls them.

What the licence also does not do is transfer exclusive ownership of the original platform code to you, and it is worth seeing why that is a strength rather than a limitation. Foundation stays open source for everybody. Your copy is one of many, and the version you hold keeps working whatever anybody else decides to do. A copyright licence of this kind grants no rights in the Provelopment name, logos or branding either, and it implies no endorsement of anything built with the software.

Third-party material bundled with Foundation keeps its own licence and attribution, exactly as it arrived: the icon library is MIT-licensed, and other owners' marks stay governed by their own rules. Foundation does not relicense other people's work, and nobody could pass on rights in it that they do not hold. Your own material — your content, your branding, everything you or your suppliers add — is a separate matter again, and the answer is simpler: it is yours, and the platform's licence has nothing to say about it.

Licence conditions, attribution and the questions that arise when several parties are involved are the subject of Licensing and your rights. Where this page and that one disagree, the licence text governs.

A handover is not a formality, and it is where an ownership claim either holds up or does not. What follows is the standard we intend to work to. It is a description of good practice rather than a contractual entitlement — the terms of a particular arrangement still have to be agreed, and some of the steps below depend on third parties cooperating.

A sensible handover covers:

• The repository. The current source of the site: the platform, and more importantly your site's own configuration, pages, language files and artwork, together with a note of which Foundation release the site is running.
• Licence and attribution information. The licence the platform is under, and the third-party notices that travel with it, so that nothing has to be reconstructed from memory later.
• Your content and assets. Provided as files, in the form they are maintained, rather than copied out of a browser.
• The domain and the DNS. Either the registrar account itself, where you hold it, or a transfer arrangement where it is held on your behalf. DNS records need particular care, because a domain's zone is usually shared with email and mail records must not be disturbed.
• Hosting and deployment settings. The provider project, its production branch, its build settings, and the canonical address the site publishes.
• Environment variables and other secrets. Identified, and passed on by a secure route rather than by email or in a document.
• Third-party services. A list of the services the site uses — enquiry delivery, maps, analytics and anything else — with whatever export or transfer arrangement each of them supports.
• Operational documentation. Enough for a competent developer who has never seen Foundation before to take responsibility: what the site is, where it is deployed, what happens automatically, and what has to be done by a person.
• An honest list of remaining work. What is currently maintained, how often, and by whom, so that whoever takes over knows what they are taking on.

Two of those items are routinely underestimated. The first is secrets: a repository contains no passwords, so a handover that stops at the code has not finished. The second is the domain. Ownership of a repository has no bearing at all on the registration of a domain, and a site whose address is controlled elsewhere has not really been handed over.

One structural point about how a site is held is worth adding, because it decides what can be moved. Foundation groups a website into an installation, and an installation can hold more than one website — each a complete site with its own configuration, content and domain. An installation is the smallest unit that is owned, transferred, upgraded and rolled back as one, so a website that shares an installation with others does not automatically have its own transfer or upgrade timing. Where two websites may need independent ownership or upgrade schedules, they belong in separate installations — a decision made when a site is created, and worth revisiting if the answer changes.

Permission and practicality are different things, and the difference is easy to test. If a different developer were taking over next week, what would they need, and could they get it?

Foundation's design makes that question answerable. Your configuration, content and branding sit apart from the platform's code, so a new developer can work with your site without first unpicking it. The platform is publicly documented, including adoption, customisation, upgrade and troubleshooting manuals written for somebody who has never seen it before. And its lifecycle is deliberately bounded: an installation of Foundation is the smallest unit that is owned, transferred, upgraded, rolled back and operated as one, so a single website stays a single thing to hand over rather than a fragment of somebody else's larger system.

That is the sense in which leaving should be practical rather than a permission written into a licence. It does not follow that moving is effortless. Changing provider is a piece of work with a short list of tasks; it may involve third-party services that are slower to cooperate than the software is; and it can carry costs — in time, or in fees — for whoever does it. What it should not need is anybody's permission.

Foundation costs nothing to obtain or use. Everything that happens afterwards — hosting, configuration, updates, troubleshooting, the services the site talks to — costs somebody something: your time, your staff's time, or a supplier's invoice. The licence changes none of that, and no licence could.

What a free licence does change is who you are able to buy that work from. The site is files rather than a rented service, so your own developer, an agency you choose, a freelancer you found this week and Provelopment can all work on the same site under the same licence.

The practical question for an owner is therefore not "what does Foundation cost?" — the answer to that is nothing — but "who does the work, and on what terms?". That question has several good answers, and this page is about keeping all of them available to you.

The commercial idea here is deliberately unremarkable: do work worth paying for, and be judged on it. Provelopment intends to earn continued business by being useful — competent implementation, reliable operation, and the accumulated judgement that comes from running websites rather than only building them.

Both outcomes are therefore acceptable to us. A customer who takes their site and runs it confidently is a success: the project did what it said it would do. A customer who stays because Provelopment is genuinely the most useful option is also a success, and it is the kind we would rather have, because it is the only kind that survives being compared.

If another developer or provider suits you better — on cost, on location, or on a specialism we do not have — that is a decision you are entitled to make, and the software is arranged so that you can act on it. Two honest qualifications: choosing another provider does not mean an identical outcome, because capability, price and quality vary between developers; and none of this is a promise about Provelopment's own future. What is written here describes an intention the software has been built to support, not a guarantee about the company's circumstances.