How to publish code without making it open source?
For years the software market offered a dead-end binary choice. SESL closes the niche that was left empty between the two.
Either Open Source — total openness, where corporations can take your code with impunity, wrap it into their own product and use it without you — or Proprietary / Closed Source — total isolation, where nobody sees the code, nobody can improve it, and you cannot build a community of collaborators around it.
The answer is simple: rights to use the code are granted only to Participants — the crew building the product together with you.
Two complete models, not one and a weakened copy
| NC — No Commercialization | Protects by exclusion. Nobody may embed the code in their product, whether they pay for it or not. |
|---|---|
| CA — Commercialization Allowed | Protects by payment, on terms written into the blank in advance. |
That NC comes first and is selected by default is not an oversight but a sensible default: the author gets the stricter, better-protected blank from the start, rather than a compromise.
Here is why SESL solves the problem of appropriation while staying open to your own people.
1. No public domain by default
Under classic Open Source — MIT or Apache, say — the code is set adrift. Anyone may take it, change it and monetise it without asking the author. SESL works differently: the code is open to read and to work on together, but it is not ownerless. Its sovereignty stays firmly with the creator — the Project Initiator — and with the pool of accepted Participants, the crew.
2. A collaborative shipyard instead of a thoughtless fork
In open source a fork is the legal way to take a project: somebody copies the repository, develops it separately, and leaves the author with nothing. SESL turns development into a shared vessel instead.
- You may take part and contribute — much as you would open a pull request — but by the rules of the project.
- The code is meant for those who build software for themselves and for the author, not for reselling somebody else's work elsewhere.
3. Protection against transformational appropriation
Corporations and outside developers often bypass licences not by copying lines of code but by copying the logic, the architecture and the algorithms in another programming language. SESL treats the engineering thought and the logic of the product as a licensed object, not merely the text files. An attempt to move an architecture quietly into a closed commercial circuit is blocked by the terms of the licence, legally and conceptually.
This protection arrives in Basic License versions above 0.3. Version 0.3, the one this site issues, does not carry it yet.
4. A legal bridge to commercialisation under the author's control
In classic “for our own use only” software, or inside a hard non-commercial circuit, any possibility of business is cut out. SESL carries a clear choice instead — CA: the code is open to collaborators, the project lives and evolves, but the right to take it to market, on fixed rules, stays under the author's control. Nobody on the outside can commercialise your MVP behind your back.
In short
SESL gives a developer what no standard licence gave: the chance to throw the doors open to like-minded people and build the product together, while remaining the only master of your own shipyard. The code is open to the eye and closed to piracy and corporate high-handedness.