Trademark and Brand Use Policy

1.1 Word marks and product names

RAILHUB — product name, covering both our hosted organizational platform and the free desktop client. It is in use in commerce on both: it names the paid hosted tier on the pricing page, and it is the name on the primary download button — “Download RailHub Studio” — and on the bundled local client throughout the homepage. RAILHUB is not reserved to hosted use, and nothing in this policy should be read to reserve it to hosted use. A mark may sit on both sides of the Software/Services line; the question a reader needs answered is which document governs a given component, and that is settled by what the component is rather than by the name it carries. Terms of Service §1 states the operative rule: anything we distribute for you to run on your own hardware is the Software and is licensed by the LICENSE file shipped with it, whatever name it ships under. RailHub Studio is such a client, so it is the Software, and it is MIT.

METERCALL — legacy word mark, the former product name; metercall.ai is a live sandbox. Do not abandon silently — it appears in the copyright header of every shipped copy.

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. 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.
• We claim no trade-mark right that narrows the MIT licence, and none of these marks makes any shipped code proprietary. RailHub Studio, RailCall Station and the RailCall CLI are released under the MIT License, and they stay MIT-licensed. That a product carries a name we own changes nothing about the code under it: MIT never grants trade-mark rights anywhere, which is why this policy exists at all, and the converse holds just as firmly — this policy takes no copyright right away. Fork it, run it, sell what you build on it, and ship it under your own name. Nothing here is a condition on the copyright licence, and no breach of this policy terminates it. See the Licensing notice.

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 — the symbol, full colour, on light or dark
• railcall-mark-white.png — the symbol, reversed, on dark or photographic backgrounds
• railcall-mark-black.png — the symbol, single colour, for print and monochrome
• railcall-logo-horizontal.png / -white.png — symbol + wordmark lockup, horizontal
• railcall-logo-stacked.png — symbol + wordmark lockup, 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.1 The MIT Licence grants copyright permissions. It does not grant trademark rights.

Every published release of RailCall Station, RailHub Studio, and the RailCall 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:

• 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.
• We will not require permission for truthful statements about compatibility, integration, comparison, or criticism.
• We will not use this policy against security researchers, journalists, academics, benchmarkers, or people who publish results that make us look bad.
• We will not revoke a certification, a permission, or a Marketplace listing because the holder competes with us, forked us, or criticised us.

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 (§3.13).

How these permissions work, stated once so it is not repeated in every subsection. Where a paragraph below grants a standing permission to use a mark or a badge — §3.6 for user groups and §3.8 for the “Built on RailCall” badge in particular — that permission is personal to you, non-transferable, non-sublicensable, conditioned on the terms stated in the paragraph granting it, and terminable on written notice for breach of those terms. We may ask to see how a mark is being used, and you should expect us to ask occasionally rather than take it as a sign of trouble.

This is not fine print for its own sake. A trademark owner who licenses a mark to the public and exercises no control over how it is used can be found to have abandoned it through naked licensing — at which point the mark stops protecting anyone, including the third parties relying on these permissions. The paragraph above is what allows §3 to be this broad. Nothing in it applies to nominative use under §3.1, §3.3, §3.4, §3.7 or §3.13, which are rights you hold under law and are not ours to condition or withdraw.

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:

• It is accurate. The statement is true when you make it, and you correct it when it stops being true.
• 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.
• 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 — the logo as published on railcall.ai — to indicate that your product, workflow, or module runs on RailCall. No application, no fee. The rules exist so the badge keeps meaning something:

• Use the unmodified asset. Do not re-trace it, re-set the wordmark, recolour it, or rebuild it from this description.
• 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.
• Place the words "Built on" or "Powered by" adjacent to it, in text of comparable prominence.
• Do not put it in your application icon, favicon, app-store icon, package icon, or social avatar.
• Do not lock it up with your own logo as though it were a joint mark — no shared enclosure, no "×", no ampersand lockup.
• Link it to railcall.ai where the medium allows.
• Do not use it on packaging, merchandise, or physical product exteriors (§4.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 RailHub Studio, the CLI, receipts, and the Marketplace 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).

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:

• the name of a product, service, application, plugin, extension, theme, or agent;
• the name of a hosted, managed, or white-labelled service — including one that hosts genuine, unmodified RailCall for other people (you may say you host RailCall; you may not call your service RailCall);
• a company name, trading name, DBA, partnership, fund, or foundation;
• the name of a token, coin, NFT collection, treasury, DAO, or any fundraising or investment vehicle. This one is absolute and we will move fast on it, because the harm lands on people who think they are buying something connected to us.

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), pluralisations, and hyphenations, in any TLD, where the domain is used commercially or in a way likely to suggest that we operate, sponsor, or endorse what is on it.

Carve-outs, and we will not send a letter about these. A non-commercial criticism, complaint, or parody site — the classic railcallsucks.com — is protected speech and §3.7 already says so without qualification. A plainly descriptive, non-commercial documentation or migration domain that no reasonable reader would take for ours is nominative use. Where this paragraph is narrower than the law, §3.13 governs and the law wins.

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 — each of which is a commercial name that reads as ours.

4.4 Package names and registry namespaces

You may not publish to a 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 — under a name that reads as ours.

Not available: the bare marks (railcall, railhub), a scope or organisation that is one of them (@railcall/*, io.railcall.*, ai.railcall.*), and any name that asserts origin or officialdom — railcall-official-*, railcall-sdk, railcall-cli, official-railcall-*, and confusable variants.

Available without asking: a name that carries your identity and describes the relationship — acme-railcall-connectors, railcall-exporter-by-acme, @acme/railcall-adapter. Put a plain sentence in the package description saying it is a third-party package not published by us, and keep the repository description consistent with it. This is the ordinary convention for third-party plugins in every ecosystem, it is nominative use, and pretending otherwise would only push people toward names that are worse for everyone.

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:

• change its colours, including replacing the gradient with a flat colour other than the supplied mono variants;
• rotate, mirror, skew, stretch, or distort it;
• add, remove, or reposition any element — including the two bars in the mouth of the enclosure;
• outline it, add drop shadows, bevels, glows, or textures;
• place it inside another shape, badge, or enclosure, or combine it with another logo into a single lockup;
• animate it in a way that changes its geometry;
• re-set the wordmark in a different typeface, alter its letterspacing, or re-letter it;
• crop it, use a fragment of it, or use the hexagonal enclosure alone as your own mark;
• use it as your own application icon, favicon, avatar, or app-store icon;
• 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 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 — 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 signing, receipts, entitlement checks, and metering — live in the Terms of Service and the Marketplace Terms. 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.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:

• Receipt production. Every action produces a receipt in the published format, with a complete and correct chain-linked hash.
• Signature. Receipts are signed with a key the implementation controls, and the signature verifies.
• 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.
• Round-trip interoperability. The implementation verifies receipts a stock Station produced, and correctly rejects invalid ones.
• 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:

• 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.
• No route-around. There is no code path that executes a write without passing the gate — demonstrated, not asserted.
• Dry-run fidelity. A dry run executes nothing external and says so.
• 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.
• Credential boundary. Credentials do not leave the boundary the declaration states, and the implementation can demonstrate this under observation.
• 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.

When the programme launches, submission will mean sending the material named on the programme page, and we intend to 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, the consequence falls on us, not on the badge. We will expedite the review, waive any fee for that submission, and publish the fact of the delay. What we will not do is let the badge issue by default.

An earlier draft said that on a missed deadline you could use RailCall Compatible until we decided. That was wrong on its own terms. A conformance badge means we checked; a badge granted because a clock ran out means nobody checked, which is precisely the harm §4.9 describes — a buyer relaxing scrutiny because they believe we did the work. It would also have given a competitor a lawful route to the badge by timing a submission, and failure of quality control is the standard way a certification mark is lost. Our administrative failure is our problem to fix; it is not a reason to tell your buyers something untrue.

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:

• The implementation no longer meets the §5.3 bar it was granted against.
• The submission contained a material misstatement.
• The badge is used on a version, product, or component it was not granted for.
• The badge is used in a way §4 prohibits (modified artwork, endorsement claims beyond what it says).
• The holder represents the badge as a security, compliance, or quality certification (§5.4).
• A court, regulator, or sanctions authority requires it.
• 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, as published on railcall.ai (see the note at §3.8 — a dedicated brand assets page does not exist yet).
• 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.

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:

• 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.
• 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.
• The relationship is stated as description, not as branding. "Kestrel — a fork of RailCall" is a description. "Kestrel RailCall" is branding.

A repository name is not a product name, and this test does not reach it. A source repository whose name carries the mark descriptively — railcall-connectors, railcall-exporter, acme/railcall-adapter — is permitted without asking, which is what §3.1’s example table has always said, provided the repository description states plainly that it is third-party and not published by us. Open-source developers may create and publish a repository under such a name, and we will not object to one. Nothing in the Terms of Service narrows this; §4.2 there lists product, domain, package, and app-store names, and deliberately does not list repository names.

Two things this does not license, because they are different acts. Publishing to a package registry under a name that reads as ours asserts origin rather than describing a relationship — §4.4 governs that, and @railcall/connectors is still not available. And the repository name does not name the fork: a fork distributed as a product needs its own product name under §6.2, and putting it in a repository called railcall-fork does not make it lawfully called RailCall.

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 passes the naming test in §6.2 and 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.

Both references are needed and an earlier draft cited only §6.4. §6.4 is a checklist of things to change — name, artwork, domains, support channels, badges. §6.2 is the test the name itself has to pass. A fork called “OpenRailCall” can tick every item in §6.4 while failing §6.2 and §4.1, so a commitment keyed to §6.4 alone would have promised not to object to exactly the naming §6.2 exists to prevent.

7.1 The ladder

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

• A note. Most misuse is a mistake. An email that says what to change and why, with a link to the clause.
• 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.
• 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 personal, non-transferable, non-sublicensable (§3 opening), and revocable on written notice with a stated reason.

Where we revoke or tighten a permission you were complying with, you get at least 90 days to transition — the same floor §10 states for a change to this policy, and the same one the banner at the top of this page relies on when it says the §3 permissions may be relied upon. The only exceptions are §7.1(a) and §7.1(b): use that is fraudulent, or that is causing active harm. An earlier draft said “a reasonable transition period,” which is not the same promise as the banner and is not something a third party can plan around; the floor is stated instead.

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.

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.

• 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.

RailCall, RailHub, the RailCall symbol, and the RailCall product names are trademarks of AiTrade LLC, a Florida limited liability company.

• 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.