Why Apache-2.0

Lumbridge code is licensed under the Apache License 2.0, with no changes to the text.

That was not our first plan. For a while the plan was a license built from the Apache terms plus one added rule: no malicious use. We wrote that license out, compared it with the alternatives and dropped it. This post explains why. It is our reasoning in plain words, not legal advice.

What we considered

The idea is easy to like. We build a system that lets agents run commands, read mail and reach many machines. We do not want it used to break into systems, deploy malware or spy on people. So write that into the license.

Our draft did it carefully. It listed concrete prohibited acts and avoided any general test of morals. It still had three problems.

Three reasons we dropped it

1. A use restriction is not open sourceThe Open Source Definition says a license may not restrict who uses the software or what they use it for. Any rule about use fails that, however well it is written. A modified Apache license also may not carry the Apache name. We would have had to call the code source-available, and that would have been the accurate word.
2. It mostly burdens honest usersA custom license is one that a company’s lawyers have never read. Standard Apache-2.0 is approved in advance in most places. Anything custom goes to manual review, and many reviews end in no. Linux distributions would not carry the code. Other open projects could not reuse it. All of that cost falls on people who meant no harm.
3. It is hard to enforce against the people it targetsPeople who intend harm do not read licenses, and what they do is usually a crime already. A license clause would add a civil claim that we would have to bring ourselves, after finding the person and proving the use. It would rarely be the thing that stops anyone.

There was one fair point on the other side. A restricted license is easy to loosen later, and an open one is hard to tighten: what is released under Apache-2.0 stays under it. We accept that. We would rather make the promise once and keep it.

What we do instead

• The code is plain Apache-2.0. Read it, change it, use it in a business, keep a private fork. The usual conditions apply: keep the license and the notices.
• The service we run has an acceptable-use policy. Lumbridge 1 is our model, sold by the token through our API. That is a service with terms a customer accepts, and we hold the keys. If someone uses it to cause harm, we can suspend the key. A rule has force where we can act on it.
• The name and mark stay ours. Apache-2.0 does not grant trademark rights. You can fork the code. You cannot ship the fork as Lumbridge or as something from Lumbridge Corp.

Copyright and notices

The copyright holder is Lumbridge Corp, a Delaware corporation. Each repository opens with a LICENSE file that holds the unmodified Apache-2.0 text.

Not all of the code started with us. Core, the App and the TUI began as forks of Herdr, which is also Apache-2.0. Staying on the same license as upstream is the simplest arrangement for everyone. Upstream copyright and attribution notices ship with each repository, along with the notices for third-party code we include.

The source opens on November 13, 2026 at github.com/lumbridge-corp, all twelve repositories together. The license text in each repository is what counts. If this post and that file ever disagree, the file is right.