License Policy

1. The short version

The RailCall Station, Studio, and CLI ship under the MIT License. Every release published to date is MIT, permanently, including the right to sell. Fork it, run it, change it, build a business on it. You do not need our permission, an account, a key, or a conversation with us.

What MIT does not hand you is our name. The code is yours to use; the marks are not. And the services we run — RailHub, the gateway, the Marketplace, the dashboard — are governed by our Terms, because those are things we operate, not things you downloaded.

2. What you may do today

Under the MIT License, with any RailCall release you hold:

The one condition MIT attaches: keep the copyright and permission notice in copies and substantial portions. That is the whole obligation.

3. What is under which licence, today

The licence text shipped in every release is the standard MIT License, with this notice line:

Copyright (c) 2026 MeterCall contributors

"MeterCall" is what the project was called before it was RailCall. "Contributors", plural, is deliberate and accurate — see the next section.

4. Who holds the copyright

Copyright in RailCall is held jointly by AiTrade LLC and the individual people who wrote the code. No contributor has assigned their copyright to the company, and the company does not claim sole ownership of the codebase.

We state this for two reasons. The first is that it is true, and a licensing page that misstates who owns the code is worthless for the only purpose such a page has. The second is that it is a real constraint on us, and it is why the forward-looking notice in §6 commits to a version-forward-only change rather than a retroactive one: a licence change reaching code we do not solely own is not something we could do by publishing a page.

If you contributed to RailCall, you still own what you wrote.

5. What the licence does not cover

5.1 Our name and marks

MIT is a copyright licence. It licenses code. It does not license trademarks, and it never has.

RailCall, RailCall Station, RailCall Studio, RailCall CLI, and RailHub, together with the RailCall logo, are marks of AiTrade LLC. Publishing the code under MIT does not license them, and no clause of MIT can be read to.

You may, freely and without asking:

• state truthfully that your product runs on RailCall, is built on RailCall, is compatible with RailCall, requires RailCall, or is a fork of RailCall;
• use the name in ordinary descriptive text, documentation, comparisons, reviews, and criticism;
• keep the copyright notices in the source, which MIT requires anyway.

You may not:

• name your fork, product, company, or domain RailCall or RailHub, or something confusingly close to it;
• use the logo as your product's mark;
• present your build as official, certified, verified, approved, endorsed, or supported by us, or as the RailCall;
• imply an affiliation, partnership, or authorship relationship that does not exist.

Fork the code and ship it — that is what the licence is for. Ship it under your own name. Full terms are in Part B of this page, published identically as the RailCall Trademark Policy.

5.2 Services we operate

The software licence covers software you run. It does not cover a service we run for you.

RailHub, the hosted gateway, the Marketplace, the dashboard, sign-in, and licence/entitlement issuance are operated by us on our own infrastructure. Access to them is governed by the Terms and, for the Marketplace, by the Marketplace Terms. Those documents may set conditions the software licence does not — rate limits, acceptable use, fees, suspension for abuse, and anti-circumvention terms covering the entitlement, licence, metering and rate-limit checks a service we operate performs — because they govern a different thing.

Those terms stop at our boundary. Signing, receipt issuance, and receipt verification as they run on your own station are functions of the MIT-licensed Software, not of a service we operate. Turning them off on your own machine is a configuration choice, not a breach of anything — Terms §8.1 says so in terms. What remains prohibited is presenting something as carrying a RailCall signature, receipt, or verification when it does not, which is a misrepresentation claim rather than a claim about what runs on your computer.

Neither of those documents narrows the software licence. If one of them appears to restrict what you may do with code you already hold, that is a drafting error on our side and this page governs. Tell us and we will fix it.

5.3 Patents

MIT does not include an express patent grant.

6. Looking forward — and what will never change

We may, in the future, publish new components or new versions of RailCall under different licence terms. We are not announcing that today, and no such release exists. But saying "this will always be MIT no matter what" would be a promise about a company that does not exist yet, and we would rather tell you the shape of any future change now than surprise you with it later.

If we ever do it, four things will be true, and we are committing to them here:

• It applies from a stated version forward, and never retroactively. Every release already published stays under the licence it shipped with, permanently, for everyone who has a copy — including the right to modify, redistribute, and sell.
• The exact version boundary is named on this page and on railcall.ai, before the first release that crosses it. You will not discover it in a diff.
• The release says so itself. Any release under different terms carries its own LICENSE file stating those terms, in the artifact, not only on a website.
• We will not call it open source if it is not. If a release is not under an OSI-approved licence, we will not describe it as open source in our marketing, our docs, our README, or our install flow.

Nothing on this page, and nothing we publish later, modifies, conditions, revokes, or reaches back to the MIT grant already delivered in every release to date. That grant is delivered. It is not ours to take back, and we are not trying to.

7. Third-party components

The Studio app bundle redistributes third-party open-source packages under permissive licences (MIT, Apache-2.0, BSD-2/3, ISC). Those components are governed by their own licences and notices, which travel with them and are not superseded by ours.

We are adding a consolidated NOTICE file listing every bundled component and its licence to the app bundle and to the release artifact. Until it lands, ask at legal@railcall.ai and we will send you the current list.

8. Questions

Licensing questions, including "is what I want to do allowed" — legal@railcall.ai, or the RailCall Discord.

We answer these in writing, and where an answer is generally useful we publish it here so the next person does not have to ask. If the honest answer to your question is "MIT already lets you do that", that is the answer you will get.

0. How to read this part

0.1 What this is

This is the brand and trademark half of the RailCall legal package. It governs the marks: the word RailCall, the hexagonal "C" symbol, the product names, and the certification badges. It does not govern the software — that is the licence, Part A — and it does not govern selling on the Marketplace — that is the Marketplace Terms.

0.2 The rule, and the four questions

The rule: use our marks to tell the truth about your relationship to RailCall. Do not use them to be us.

If you are unsure, answer these four. Any "yes" means you need written permission (§9); all "no" means go ahead without asking.

• The label test. Would a reasonable person seeing your name, logo, domain, package, or listing think the thing itself came from us, or was checked by us?
• The prominence test. Is our mark the biggest, first, or most memorable element — the thing that identifies your product, rather than a description of what it works with?
• The claim test. Are you saying, or implying, certified, official, authorized, approved, partner, endorsed, or verified, without a signed agreement from us?
• The substitution test. Are you offering something under our name that a customer might buy instead of RailCall, believing it is RailCall?

1. The Marks

1.1 Word marks and product names

1.2 What is not claimed

Stated plainly, because a policy that claims too much is worth less than one that draws the line honestly:

• We claim no exclusive rights in ordinary descriptive words used descriptively — airlock, receipt, ledger, station, studio, workflow, approval, dry run, blast radius, governed, agent, hub. You may describe your own product using any of those words. What is ours is the specific product name — "Action Airlock" as the name of our feature, not "airlock" as an English word.
• We claim no rights in the ideas or mechanisms the software implements. Signing receipts, verifying them offline, gating writes behind human approval, declaring blast radius — reimplement any of it, independently or from our published source, under your own name. That is the point of publishing it.
• We claim no rights in your use of the word "rail" or the word "call" separately, or in either used in a context nobody would connect to us.

1.3 The symbol

The RailCall symbol is a hexagonal enclosure opened on its right side into a "C", with two rounded bars sitting in the mouth of the opening. The enclosure reads as a protected space; the negative space forms the C of the name; the bars read as flow between systems. It is rendered either in the brand gradient — #FF155D (pink) at the top-left ramping to #E54A00 (orange) at the bottom-right — or as a single-colour silhouette inheriting its surrounding colour.

Canonical artwork, and the only artwork anyone should use: railcall-mark-gradient.png (full colour), railcall-mark-white.png (reversed, for dark or photographic backgrounds), railcall-mark-black.png (single colour, print and monochrome), railcall-logo-horizontal.png / -white.png (symbol + wordmark, horizontal), and railcall-logo-stacked.png (symbol + wordmark, stacked).

1.4 Trade dress

The pink-to-orange gradient applied to the symbol, in combination with the symbol's geometry, is a source identifier and is treated as part of the mark. We do not claim the colours pink or orange, gradients generally, dark interfaces, or grid backgrounds. What is prohibited is imitation of the specific combination in a way likely to confuse — a look-alike site or product chrome that a user could mistake for ours. See §4.7.

1.5 Symbol marking

Until counsel confirms otherwise, marks are marked ™ and never ®. Using ® for an unregistered mark is not a formality — in the United States it can itself be actionable as false designation, and it is the kind of error that turns an enforcement letter into an embarrassment.

2. What the software licence gives you, and what it does not

2.1 The MIT Licence grants copyright permissions. It does not grant trademark rights.

Every published release of RailCall Station, Studio, and the CLI to date ships with an MIT licence file, and the README says, in these words: "Fork it. Use it. Ship on it." We meant it and we still mean it. That licence grants permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software. Those are rights in the work.

A name is not a work. Trademark rights protect the connection between a name and its source, they exist under a different body of law, and they are not conveyed by a copyright licence. The MIT text is silent on trademarks; silence is not a grant. (Apache-2.0 §6 says so expressly; MIT simply never addressed it, which is why policies like this one exist.)

So both of these are true at once, and neither qualifies the other:

• You may take the entire codebase, modify it however you like, and sell it. That grant is delivered, irrevocable, and reaches every copy already downloaded. We are not going to pretend otherwise, and any term anywhere in our documents that suggests otherwise is a defect in our documents.
• You may not call the result RailCall. That was never given, by MIT or by anything else.

2.2 Reservation of rights and forward notice

• Current and past releases are under the MIT Licence and stay there, permanently, for everyone who holds a copy.
• New components, new services, and future versions may be released under different terms. If and when that happens it will be stated plainly, at the version boundary, in the repository and on the site — not discovered.
• This trademark policy applies regardless of which licence the code is under. It applied to the MIT releases, it applies to anything released later, and a change in the software licence neither expands nor contracts anything in this document.

2.3 What we will never do with this policy

Committed here so it can be held against us:

1. We will not use trademark law to claw back, condition, or chill the MIT grant. If you fork under a different name and follow §6, we have no objection and we will not raise one.
2. We will not require permission for truthful statements about compatibility, integration, comparison, or criticism.
3. We will not use this policy against security researchers, journalists, academics, benchmarkers, or people who publish results that make us look bad.
4. We will not revoke a certification, a permission, or a Marketplace listing because the holder competes with us, forked us, or criticised us.

3. Permitted without asking

Everything in this section is permitted now, with no application, no fee, no notice to us, and no waiting. These permissions may be relied on. Where they are narrower than what the law already allows you, the law wins — this section grants, it never restricts (§3.13).

3.1 Nominative and referential use — the general permission

You may use the word "RailCall" in plain text to refer to RailCall. That includes saying that your product, service, integration, course, article, or fork works with it, runs on it, is built on it, is compatible with it, supports it, replaces it, or is worse than it.

Three conditions, and they are the ordinary law of nominative use rather than anything we invented:

1. It is accurate. The statement is true when you make it, and you correct it when it stops being true.
2. You use no more of the mark than you need. The word, in your own typeface, at your own size. You do not need our logo to say your product works with ours, and using the logo where the word would do is the most common way this permission gets exceeded.
3. Nothing implies we sponsored, endorsed, certified, or authored it. Adding "RailCall is a trademark of AiTrade LLC. This project is not affiliated with or endorsed by AiTrade LLC." is the cheapest possible way to satisfy this, and we recommend it.

Worked examples — these are the boundary, stated concretely so nobody has to guess:

3.2 Compatibility and interoperability statements

Stating that your software interoperates with RailCall — including in your documentation, changelog, README, website, marketing pages, sales deck, RFP response, and support articles — is permitted without permission. Naming specific versions and specific interfaces is permitted. Publishing your own compatibility matrix is permitted, and you do not need us to agree with it.

3.3 Comparison, benchmarks, and competitive claims

Truthful comparative use is expressly permitted, including when it is unflattering to us. You may name RailCall in a comparison table, publish benchmarks against it, write a "why we left RailCall" post, or build a migration tool called "Migrate from RailCall" (as a description of function — not as your product's name).

We will not use trademark law as a substitute for a better product. If a comparison is false our remedy is false-advertising law, not this policy, and we will say which statement is false and why.

3.4 Editorial, journalistic, academic, and analyst use

Journalists, researchers, analysts, students, book authors, and course writers may use the marks — word and logo — to refer to RailCall, without permission, including on covers, in slides, in figures, and in headlines. The only ask is accuracy and that the work not present itself as published by us.

3.5 Talks, workshops, meetups, and courses

You may give a talk, run a workshop, teach a class, record a video series, or write a book about RailCall, including for money, without asking us, and you may use the word and the unmodified logo in your slides, thumbnails, and course listing to indicate the subject.

Event and course naming is where this ends: the mark may appear as the subject, not as the source.

3.6 User groups and community organising

Community groups may use the pattern "RailCall User Group — [Place]" or "[Place] RailCall Meetup" without asking, provided the group: is not-for-profit as to the group's own activities (sponsorship covering costs is fine); does not present itself as operated by us; does not use the marks in a domain name it owns (§4.3) or in a way that reads as official; and stops using the name if we ask in writing for a stated reason. Selling tickets at cost, taking sponsors, and recording sessions are all fine.

3.7 Criticism, parody, security research, and disclosure

Permitted without permission and without qualification: criticism, complaint, satire, parody, and the publication of security findings, including proof-of-concept code and including work that names the product in the title of the finding. Coordinated disclosure is a courtesy we ask for and a security bar we hold listings to; it is not a trademark condition and never will be.

3.8 The "Built on RailCall" / "Powered by RailCall" badge

You may display our unmodified logo, taken from the brand assets page, to indicate that your product, workflow, or module runs on RailCall. No application, no fee. The rules exist so the badge keeps meaning something:

1. Use the unmodified asset. Do not re-trace it, re-set the wordmark, recolour it, or rebuild it from the description in §1.3.
2. Do not make it the largest or most prominent brand element on the surface. Your name identifies your product; ours describes what it runs on.
3. Place the words "Built on" or "Powered by" adjacent to it, in text of comparable prominence.
4. Do not put it in your application icon, favicon, app-store icon, package icon, or social avatar.
5. Do not lock it up with your own logo as though it were a joint mark — no shared enclosure, no "×", no ampersand lockup.
6. Link it to railcall.ai where the medium allows.
7. Do not use it on packaging, merchandise, or physical product exteriors (§4.8).
8. Stop using it within 30 days of your product no longer running on RailCall.

Displaying this badge is not a certification, confers no verification, and must not be described as one.

3.9 Screenshots and interface images

You may reproduce screenshots of RailCall Studio, the CLI, receipts, the Marketplace, and the RailHub dashboard in documentation, articles, talks, courses, and reviews. Do not alter a screenshot in a way that misrepresents what the software does or shows it producing output it did not produce.

3.10 Personal and non-commercial merchandise

Make yourself a sticker, a t-shirt, a laptop decal, or a mug. Print a batch for your team or your meetup at cost. That is fine and always will be. Selling merchandise bearing the marks is not (§4.8) — the line is sale, not craft.

3.11 Forks and redistribution notices

Saying, prominently and repeatedly, that your project is a fork of RailCall is permitted, expected, and encouraged. §6 sets out exactly how to name the fork itself.

3.12 Internal use

Using the marks inside your own organisation — in architecture diagrams, runbooks, internal wikis, training decks, procurement documents, and board slides — needs no permission of any kind.

3.13 This section does not narrow your rights

Nominative fair use, descriptive fair use, first-sale, parody, and news reporting are rights you hold under law regardless of what any policy says. Nothing here waives them, and if this policy is narrower than the law in any respect, the law governs. We wrote this section wide on purpose; if we missed a case that is obviously fair, treat it as permitted and tell us so we can add it (§8).

4. Prohibited without written permission

Everything below requires a signed writing from us (§9). Absent that, do not do it. These are the restrictions we would actually enforce, and each one is a case where confusion about source is the real and likely harm.

4.1 Naming a fork, distribution, or derivative

You may not distribute a modified version of RailCall under the name RailCall, under any name containing RailCall, or under any name confusable with it. You may fork the code — you may not fork the name. §6 tells you exactly how to name your fork so that this is never a problem.

This restriction is not a limit on modification, distribution, or sale. It is a limit on one thing: what the thing is called.

4.2 Product, service, and company names

You may not use RailCall, RailHub, or a confusable variant as, or as part of:

4.3 Domain names

You may not register or use a domain whose second-level name contains RailCall, RailHub, MeterCall, or a confusable variant — including typo variants (railcal, raiIcall, rail-call, ra1lcall, railhubb), pluralisations, and hyphenations, in any TLD.

Permitted without asking, for the avoidance of doubt: a path or subdomain on your own domain that is plainly descriptive and plainly yours — acme.com/railcall-integration, docs.acme.com/railcall. Not permitted: railcall-hosting.com, getrailcall.io, railcall.cloud, railcallpro.com, railhub.dev.

4.4 Package names and registry namespaces

You may not publish under a name containing our marks to any package registry, extension marketplace, image registry, or app store — npm, PyPI, crates.io, Homebrew, Docker Hub, container registries, the VS Code Marketplace, the Chrome Web Store, the Apple App Store, Google Play, or any successor.

That includes railcall, railcall-*, @railcall/*, railhub*, io.railcall.*, ai.railcall.*, and confusable variants. It applies whether or not we have claimed the namespace ourselves.

4.5 Social handles, profiles, and app-store listings

You may not register or operate an account, handle, page, channel, server, or profile that uses our marks in a way suggesting it is operated by us, on any platform. The official account is @railcallai on X; the official community is the Discord linked from railcall.ai. A handle like @acme_for_railcall used by an obvious third party is fine; @railcall_support, @railcallhq, @railcall_official are not.

4.6 Modifying the logo

The symbol must be used exactly as supplied. You may not:

1. change its colours, including replacing the gradient with a flat colour other than the supplied mono variants;
2. rotate, mirror, skew, stretch, or distort it;
3. add, remove, or reposition any element — including the two bars in the mouth of the enclosure;
4. outline it, add drop shadows, bevels, glows, or textures;
5. place it inside another shape, badge, or enclosure, or combine it with another logo into a single lockup;
6. animate it in a way that changes its geometry;
7. re-set the wordmark in a different typeface, alter its letterspacing, or re-letter it;
8. crop it, use a fragment of it, or use the hexagonal enclosure alone as your own mark;
9. use it as your own application icon, favicon, avatar, or app-store icon;
10. place it on a background where it is illegible or where the surrounding design implies it is the source of the product.

Reasonable clear space and a legible minimum size are expected.

4.7 Trade dress imitation

You may not imitate the combination of our symbol geometry, brand gradient, and interface chrome so that your site, product, or listing could be mistaken for ours. Building a page that looks like railcall.ai or railhub.ai in order to collect credentials, keys, or payments is fraud before it is a trademark matter, and will be treated that way.

4.8 Merchandise for sale

You may not sell goods bearing our marks — apparel, stickers, hardware, accessories, print — or use the marks in the branding of a physical product, without a signed agreement. (Personal and at-cost use is permitted; §3.10.)

4.9 Implying endorsement, partnership, or certification

You may not describe yourself, your product, your fork, your service, your listing, your agency, or your course as any of: official, certified, verified, approved, authorized, endorsed, sponsored, accredited, licensed, recommended, partnered, affiliated, a reseller, a distributor, or a member of any programme — in relation to RailCall or RailHub — unless a signed writing from us says so.

This is the clause that does the most work, and it is the one where confusion causes real harm: a buyer who believes a module was checked by us relaxes exactly the scrutiny our whole product exists to encourage.

Also prohibited: presenting our receipts, signatures, badges, or verification output as attesting to something they do not attest to; producing artwork that mimics a RailCall verification badge; or claiming that we audited, reviewed, or security-tested something we did not.

4.10 Circumventing or forging the verification surface

You may not: forge or imitate the Verified Publisher badge or any §5 badge; present unsigned or self-signed material as carrying a RailCall signature; alter, strip, or spoof receipt provenance so that output appears to originate from a verified party; or represent that an entitlement, certification, or verification exists when it does not.

(The technical anti-circumvention terms — for the entitlement, licence, metering and rate-limit checks a service we operate performs — live in the Terms §8.1 and the Marketplace Terms, and they stop at our boundary: how signing and receipt verification are configured on your own station is yours to decide. This clause covers only the trademark half: passing off a claim of verification you were never granted.)

4.11 Genericide protection

Please use the marks as adjectives, not as nouns or verbs. "A RailCall workflow", not "a railcall". "Run it on RailCall", not "railcall it". We are asking, not threatening; a mark that becomes a common noun stops being a mark at all, and at that point nobody's name means anything.

5. RailCall Certified and RailCall Compatible

5.1 What this is and why it exists

Anyone may implement the RailCall protocol. Anyone may fork the code. Neither of those facts tells a buyer whether the thing in front of them actually signs its receipts, actually verifies them, and actually stops at the approval gate rather than routing around it.

So there are two badges, granted in writing, revocable, that say exactly that and nothing else. This is the only place in the entire RailCall legal package where exclusivity lives, and it lives here legitimately: not by restricting what anyone may build, but by controlling who may claim we checked it.

This is not a novel arrangement. Anyone may build a wireless radio; only devices that pass the Wi-Fi Alliance's test programme may carry "Wi-Fi CERTIFIED". Anyone may implement USB; the USB-IF logos require a licence and compliance testing. Anyone may write a kernel; "Linux" is a registered mark administered under a sublicence programme. In each case the specification is open and the name is the quality signal. That is the model here.

5.2 Three badges, three different meanings

They are not interchangeable, and the differences are the point.

5.3 The conformance bar

To be granted either badge, an implementation must — at a specific, named version identified by build hash — demonstrate all of the following, verifiably and repeatably, on a machine we do not control:

For RailCall Compatible

1. Receipt production. Every action produces a receipt in the published format, with a complete and correct chain-linked hash.
2. Signature. Receipts are signed with a key the implementation controls, and the signature verifies.
3. Independent verification. A stock RailCall Station, offline, with no network access, can verify receipts the implementation produced — and rejects receipts that have been tampered with.
4. Round-trip interoperability. The implementation verifies receipts a stock Station produced, and correctly rejects invalid ones.
5. Honest failure. When signing is unavailable, receipts are reported as unsigned rather than presented as signed. Silent degradation is a fail, not a warning.

Additionally, for RailCall Certified

6. Approval gate. Every action classified as a write requires an explicit human approval of the exact payload before execution. No configuration, flag, mode, or API removes this.
7. No route-around. There is no code path that executes a write without passing the gate — demonstrated, not asserted.
8. Dry-run fidelity. A dry run executes nothing external and says so.
9. Blast-radius declaration. The implementation declares what it touches, what is irreversible, where it may send traffic, and what it may spend — and the declaration matches observed behaviour under test.
10. Credential boundary. Credentials do not leave the boundary the declaration states, and the implementation can demonstrate this under observation.
11. Disclosure. A stated channel and commitment for handling security reports against the implementation.

5.4 What these badges do not mean

Stated as prominently as the badges themselves, because the failure mode of every certification programme is that the badge quietly comes to mean more than it says:

5.5 Applying

Open to anyone. No fee.

Send the material named on the programme page. We commit to:

• acknowledging within 5 business days;
• a decision within 20 business days of a complete submission;
• written reasons citing a numbered clause of §5.3 for any refusal, sufficient to fix and resubmit;
• unlimited free resubmission after a refusal.

If we miss the decision deadline by more than 10 business days, you may use RailCall Compatible for the submitted version until we decide, and our eventual refusal is not retroactive as to that use.

5.6 Term, versions, and renewal

• A grant is for a named version and build hash, and lasts 24 months from grant or until that version is no longer offered, whichever is earlier.
• A new major version needs a new submission. A patch release may be self-attested by the holder, in writing, as not changing conformance behaviour — and that attestation is what a later revocation would be measured against.
• We publish the list of current badge holders, with version and grant date, so a buyer can check a claim rather than trusting a graphic.

5.7 Suspension and revocation — the exhaustive list

A badge may be suspended or revoked only for these reasons, and no others:

1. The implementation no longer meets the §5.3 bar it was granted against.
2. The submission contained a material misstatement.
3. The badge is used on a version, product, or component it was not granted for.
4. The badge is used in a way §4 prohibits (modified artwork, endorsement claims beyond what it says).
5. The holder represents the badge as a security, compliance, or quality certification (§5.4).
6. A court, regulator, or sanctions authority requires it.
7. The holder asks us to withdraw it.

Explicitly not grounds for revocation: competing with us; forking us; criticising us; publishing benchmarks; selling outside the Marketplace; refusing a commercial relationship; declining to upgrade.

5.8 Process, notice, and appeal

• Notice first. Except for cases where continued use is actively deceiving buyers, we give 30 days' written notice with the numbered ground and what would cure it. A cure inside that window ends the matter.
• Emergency suspension is available for §5.7(2) and (5) where buyers are being misled now. It must be accompanied, at the time it is imposed, by the written ground and the cure path.
• Appeal. Within 30 days, to a person who was not the original decision-maker. Decision within 15 business days, in writing, citing the ground. If we miss that deadline the suspension lifts pending decision.
• Reinstatement is automatic on cure. We do not require a waiting period, a fee, or an apology.
• Wind-down. On revocation you have 30 days to remove the badge from digital surfaces and 180 days for printed material already produced. We will not pursue material already in the field within those windows.

5.9 Non-discrimination

The programme is open on identical terms to everyone, including our competitors, including forks, including people who have publicly criticised us. The criteria in §5.3 are exhaustive: if an implementation meets them, it gets the badge, and no other consideration enters the decision.

5.10 If we discontinue the programme

If we withdraw either badge programme, existing holders may continue to display the badge for the remainder of their term for the versions granted, and we will publish the reason and the date. Badges already earned do not evaporate because we changed our minds.

5.11 Using the badge, once granted

• Use the supplied badge artwork, unmodified, from the brand assets page.
• Display the version string the badge was granted for, adjacent to it. A badge without a version is a claim we did not make.
• Do not alter the badge's wording, colours, or geometry, and do not build your own.
• Do not use the badge in your product name, logo, icon, domain, package name, or handle. It is a statement about your product, not a part of its identity.
• Link the badge to your entry in the published holder list where the medium allows.
• Stop using it within 30 days of expiry, revocation, or the version leaving your offering.

6. Forks — how to name yours lawfully

This section exists to prevent disputes rather than win them. Follow it and there is nothing for us to object to; we commit in §6.8 that we will not.

6.1 The rule

Fork the code. Change the name. Say what it is a fork of. Three steps, all of them cheap, none of them restricting what your fork can do.

6.2 The naming test

A fork's name is fine if all three are true:

1. It is not our mark, and does not contain it. Not RailCall, not RailHub, not a variant a reader could mishear or mistype into ours.
2. It does not lead with our mark. "RailCall-NG", "OpenRailCall", "RailCall Community Edition", "RailCall Reloaded" all fail — the first thing the eye lands on is our name.
3. The relationship is stated as description, not as branding. "Kestrel — a fork of RailCall" is a description. "Kestrel RailCall" is branding.

6.3 Worked examples

6.4 What to change in a fork you distribute

If you distribute your fork — free or paid — change these before you ship:

• The product name everywhere it appears: README, docs, site, --help output, window title, About box, installer, and the user-visible name of the CLI command.
• The logo and all brand artwork. Remove railcall-mark-*.png, railcall-logo-*.png, the traced SVG symbol, and any derivative of them. Ship your own mark or none.
• The domain and URLs your build points at for updates, telemetry, docs, and support.
• The package or download name and any registry namespace.
• Support channels. Do not point your users at our Discord, our issue tracker, or our inboxes. Your fork, your support. (Sending an upstream bug report is welcome — sending your users is not.)
• The badges. Remove any Verified Publisher, Certified, or Compatible artwork. If your fork qualifies for §5, apply in your own name.
• Any statement that reads as endorsement — "official", "certified", "supported".

6.5 What you keep, and what you must keep

• Keep the code. All of it, modified however you want. That is yours under MIT and this policy does not touch it.
• You must keep the copyright and licence notices. That is an MIT obligation, not a trademark one, and it survives every rename. Removing "Copyright (c) 2026 MeterCall contributors" from the licence file is a licence breach.
• Keep saying what it is a fork of. Attribution helps you as much as us — it is how your users understand what they are getting.

6.6 A block you can paste

## About this project

Kestrel is an independent fork of RailCall Station, forked at v1.5.8 and
maintained separately since 2026. It is distributed under the MIT Licence,
the same licence RailCall shipped under.

Kestrel is not affiliated with, endorsed by, or supported by AiTrade LLC.
RailCall is a trademark of AiTrade LLC, used here only to identify the
upstream project this software is derived from. Please report Kestrel
issues to this repository, not to RailCall.

6.7 Precedent, for anyone who thinks this is unusual

Renaming on fork is the norm across the industry, not an imposition invented here:

• OpenSearch — AWS's fork of Elasticsearch shipped under a new name after Elastic's licence change; the Elasticsearch name was the live dispute, not the code.
• Valkey — the Redis fork, renamed on day one rather than contest the name.
• MariaDB — forked from MySQL by its original author, who still renamed it.
• LibreOffice — forked from OpenOffice.org, renamed because Oracle held the name.
• Chromium / Chrome — the same codebase, one name open, one name not.
• Iceweasel — Debian's rebuild of Firefox, renamed for years precisely because Mozilla's trademark policy and Debian's patching practice could not be reconciled. That one is a cautionary tale for us: a policy too restrictive about patched builds produces a fork of your name whether you like it or not.

6.8 Our commitment

If your fork follows §6.4, we will not raise a trademark objection to it. Not to the fork, not to its distribution, not to its sale, not to its success. If we ever think you have crossed a line, you get a specific written notice with a 30-day cure window (§7.1) before anything else happens.

7. Enforcement

7.1 The ladder

We escalate in order, and we start at the bottom:

1. A note. Most misuse is a mistake. An email that says what to change and why, with a link to the clause.
2. Written notice with a 30-day cure window. Names the specific use, the specific clause, and what would resolve it. A cure inside the window ends the matter with no further consequence, and we will say so in writing.
3. Escalation — platform reports (§7.3), formal demand, or proceedings — only if the cure window lapses without a response or a good-faith fix.

Two exceptions, and only two, where we may act immediately: (a) fraud, phishing, credential harvesting, or impersonation using our marks; (b) a claim of certification, verification, or endorsement that is misleading buyers right now. In both cases the notice still issues at the same time as the action, with the reason.

7.2 Proportionality — what we will not do

We will not: send a demand letter over nominative use permitted by §3; object to a truthful comparison; pursue an individual over a personal sticker, a hobby project, or a user group; use registrar or platform takedowns as a first step; or bring a trademark claim as leverage in an unrelated commercial dispute.

7.3 Platform reporting

Where escalation is warranted we may report misuse to registrars, hosts, package registries, app stores, and social platforms. Before filing any such report we will have: identified the specific mark and the specific use; sent notice under §7.1 unless §7.1(a)/(b) applies; and confirmed the use is not permitted under §3. We will not file a report we would be embarrassed to have published.

7.4 Domains

Confusable and typosquatted domains are the most common real-world abuse and the one with the cleanest remedy.

7.5 Standard terms

No waiver by non-enforcement in any single instance; no licence granted by implication, estoppel, or course of dealing beyond what §3 and §5 say expressly; all rights not expressly granted are reserved; permissions granted under §3 and §5 are revocable on written notice with a stated reason and, except under §7.1(a)/(b), a reasonable transition period.

8. Reporting misuse

If you see our marks used in a way that misleads people — a fake "official" account, a phishing page, a product claiming certification it does not hold, a forged verification badge — tell us.

Where: legal@railcall.ai, the address already published on every RailCall legal page.

What helps: a URL or screenshot, the mark used, what is misleading about it, and the date you saw it. You do not need to be a customer, a lawyer, or right — a good-faith report that turns out to be permitted use costs nothing.

What we commit to: acknowledging within 5 business days, and telling you the outcome when there is one, unless a legal process prevents it.

9. Requesting permission

For anything in §4, ask. There is no fee and no form.

Send to legal@railcall.ai: who you are, what you want to use, where it will appear, for how long, and a mock-up or link if one exists.

We commit to acknowledging within 5 business days and answering within 20, in writing, with reasons if the answer is no.

Things we routinely say yes to: conference and event naming where the event is plainly community-run; merchandise for a meetup or a hackathon; a co-marketing lockup with a genuine integration partner; using the logo above the §3.8 prominence limit in a case-study or launch context; a research or press use that needs the logo at full size.

Things we routinely say no to: anything in §4.2 (product, service, and company names), §4.3 (domains), §4.4 (package namespaces), and any certification claim outside §5. Those are not negotiating positions; they are the marks doing their job.

10. Changes to this policy

• This policy is versioned, dated, and published with a changelog. Superseded versions stay available.
• A permission already granted in writing is not revoked by a later version of this policy for the use it was granted for. If we tighten a rule, existing compliant uses get a transition period stated in the change itself, and never less than 90 days.
• Material changes are announced on the policy page and in the changelog, on both domains that publish it.

11. Entity and contact

RailCall, RailHub, the RailCall symbol, and the RailCall product names are trademarks of AiTrade LLC.

• Trademark, brand, and permission requests: legal@railcall.ai
• Community and general questions: the RailCall Discord, linked from railcall.ai
• Brand assets: see the counsel note below

Suggested notice line for third parties using the marks under §3:

RailCall is a trademark of AiTrade LLC. This project is not affiliated with, endorsed by, or sponsored by AiTrade LLC.