Why we publish our client license
Custom software shops negotiate intellectual property terms in private, once, at the worst possible moment. Open source solved this decades ago, and we borrowed the answer.
Custom software projects tend to start well. There is a good conversation, some real enthusiasm about what the thing could do, and a scope both sides believe in. Then the contract arrives, usually late, and the energy drains out of the room while two people who are not lawyers try to work out what an intellectual property clause means.
We have stopped doing that. Codestead now has one client license, it is published, and you can read every word of it before you email us.
Negotiating this every time makes it worse
Contract negotiation over IP has a predictable shape. The client’s instinct is to ask for everything, because that is what feels safe from where they sit. Our instinct is to keep everything, for exactly the same reason. Both sides end up somewhere in the middle, mildly unhappy, and nobody has learned a single thing about the software.
The timing makes it worse. By the time the agreement shows up, you have picked a vendor, cleared a budget, and told someone a start date. The contract is now the last obstacle between you and getting on with it. That is the point at which you have the least patience you are ever going to have for a document that repays careful reading.
So it gets skimmed. Six months later, someone finds out what it actually said.
Where the idea came from
Open source worked this out a long time ago, and custom software shops mostly did not notice.
Nobody negotiates with you when you use an open source project. The maintainer holds the copyright, publishes a standing license, and every user gets identical terms. You read MIT or Apache once, you know what you can do forever, and you get on with your work. The license does not change underneath you. If a new version is published, the version you relied on still says what it said the day you relied on it.
There is something clever in that structure. It separates ownership from rights. The maintainer keeps the copyright, which is what lets them keep building. Everyone else gets rights broad enough that ownership stops mattering to them in practice.
That is the same problem custom software has, and we could not find a good reason the same answer would not fit.
What it says
You get the complete source code, in a repository you control, throughout the build rather than at a handover meeting. You get a license to run it, modify it, hire any developer you want to work on it, take it with you if you sell the business, and publish it publicly if you feel like it. Once the build is paid for, that license becomes permanent, and from that point nobody can revoke it. Not a later disagreement, not the end of our working relationship, not us going out of business.
We keep the copyright, and we keep the right to reuse our own work.
That second half is the sentence most firms leave out, so here it is in detail. We stay free to build similar software for other people, including businesses that compete with you. That is how a shop working one industry at a time stays viable, and quietly leaving it unsaid would be the kind of omission that surfaces at the worst possible time.
Two things are carved out of that. Anything you tell us in confidence, and any data your software touches, only ever serve your project, and that includes not rebuilding them in disguised form for somebody else. Separately, components that encode something specific about how you compete get listed by name in your agreement and become your property outright.
If you want more restriction than that, a commitment to stay away from named competitors for a defined period, it is available and it has a price on it, because it is us agreeing to turn down work. We would rather quote that honestly than imply an exclusivity we cannot afford to honor.
Versioning matters more than it sounds like it does
Your agreement names a specific version. Not “the license at codestead.net”, which would let us change your terms by editing a web page, but v0.3 by name. If we publish v0.4 next year, yours is untouched. Every version that has ever been used in an agreement stays online at its own permanent address, including after it is superseded, because somebody may still be relying on it.
That is the whole difference between a published license and a terms-of-service page. One is a commitment. The other is something a company can rewrite on a Thursday.
It is still a draft
The version online now is v0.3, and it is with an attorney. We are publishing the plain-English summary and the structure while that review runs, because the model is the part we want to be judged on. The operative text goes up when it comes back.
If you are thinking about working with us, read it first. If something in it strikes you as unfair, say so. A published document is much easier to argue with than a private one, which is most of the point.
What do you wish your software could do?
Bring us the idea. We'll help turn it into the right system.
An internal tool, an AI capability, a customer-facing product — or something entirely new.