XALEN vs Swiss Ephemeris: The First Apache-2.0 Alternative to the AGPL Standard

If you searched for a Swiss Ephemeris alternative with a permissive (Apache-2.0) license, you are almost certainly an engineer who hit one specific wall: the Swiss Ephemeris is dual-licensed under AGPL-3.0 or a paid commercial license, and your closed-source, white-label, or on-prem product cannot live with the AGPL's network-source-disclosure clause. This article answers that query directly, then backs it with real accuracy numbers you can reproduce yourself.

The short version: XALEN is Vedika's own pure-Rust ephemeris engine, released under Apache-2.0. It matches the Swiss Ephemeris and NASA JPL DE440 to sub-arcsecond agreement on every classical planet, with an arcsecond-class analytic Moon. It is the first genuinely permissive alternative built from an independent codebase rather than wrapped around AGPL-licensed internals. We will also be honest about where Swiss Ephemeris remains the reference — because fairness is the only thing that survives fact-checking.

The license problem, stated plainly

The Swiss Ephemeris (from Astrodienst) is excellent astronomy software. It is also dual-licensed: AGPL-3.0 OR a paid commercial license. The choice of license is where most commercial projects get caught.

The relevant clause is AGPL-3.0 Section 13. In plain English: if you run a modified version (or, in practice, a derivative work that links the library) and let remote users interact with it over a network — which is exactly what every SaaS, API, or web app does — you must offer those remote users the complete corresponding source of your application. The GPL family triggers source obligations on distribution; AGPL §13 extends that trigger to network use. A hosted endpoint that returns an ephemeris-derived result is network interaction.

There is a legitimate escape hatch, and we should be clear that it exists: you can buy the Swiss Ephemeris commercial license. It is a modest one-time fee with long (99-year) validity. This is a perfectly reasonable path and we are not claiming it "costs a fortune." But it has two costs that are not money:

• A legal dependency on an upstream vendor. Your licensing posture is now tied to a third party's terms, audits, and continued availability.
• No copyleft freedom. You cannot freely fork, redistribute, or sublicense the engine inside your own permissively-licensed stack.

Apache-2.0 removes both. It is a permissive license: embed the code in closed-source products, ship it in a white-label SaaS, run it on-prem for an enterprise customer, redistribute it — all with zero source-disclosure obligation. It also includes an explicit patent grant, which matters to legal teams. That is the entire thesis of this comparison: the cleanest, least-arguable win for XALEN is the license axis.

The part nobody mentions: most "alternatives" are Swiss in a trench coat

Here is the detail that reframes the whole search. Nearly every astrology API and library on the market wraps the Swiss Ephemeris and therefore inherits its AGPL obligations (or pays for the commercial license, which they rarely surface to you). That list includes widely-used hosted APIs such as Prokerala, AstrologyAPI.com, DivineAPI, and FreeAstrologyAPI, and popular open-source libraries such as Kerykeion, flatlib, immanuel, and VedAstro.

None of those are bad software — several are very good. But switching from one Swiss wrapper to another does not change your license exposure. If AGPL is your problem, you need an engine with an independent codebase. There are only two we are aware of:

• XALEN (Vedika) — pure-Rust, Apache-2.0, independent implementation.
• RoxyAPI's Roxy Ephemeris — its own engine, JPL-Horizons-validated, MIT-licensed. Genuinely independent and a fair credit to them.

So if you are comparing XALEN to a Swiss wrapper, the engine-independence and license story is the decisive difference. If you are comparing XALEN to RoxyAPI specifically, both have their own permissively-licensed engine — that line is a draw — and the comparison moves to the full platform stack, which we cover below.

What XALEN actually is, under the hood

XALEN is a from-scratch astronomical engine written in Rust. The core is:

• VSOP87A for planetary positions (heliocentric rectangular, high-precision series).
• A truncated ELP2000-82 series for the Moon.
• Meeus algorithms for the standard reductions, IAU 2006 precession and the 2000B nutation model.
• An optional JPL DE440 SPK kernel reader for when you need full JPL-grade ephemeris data rather than the analytic series.

Engineering properties that matter for production:

• Zero-unsafe core and thread-safe — safe to fan out across worker threads.
• Compiles to wasm32, so the same engine runs in the browser or at the edge.
• Roughly ~336µs for a full chart — fast enough to compute thousands of charts per second per core.

It is published and installable right now across three ecosystems:

# Rust
cargo add xalen-ephem

# Python
pip install xalen

# JavaScript / TypeScript (WASM)
npm i @xalen/wasm

The published surface is broad: 15 crates on crates.io at v0.6.0 (xalen-ephem, xalen-coords, xalen-houses, xalen-vedic, xalen-western, xalen-time, xalen-ayanamsa, xalen-stars, xalen-chart, xalen-chinese, xalen-world, xalen-lalkitab, xalen-iching, xalen-numerology, xalen-ffi); @xalen/wasm plus @vedika-io/sdk, @vedika-io/mcp-server (36 tools), @vedika-io/cli and @vedika-io/react on npm; xalen 0.6.0 and vedika-sdk on PyPI; and the source at vedika-io/xalen-ephemeris on GitHub under Apache-2.0.

Accuracy: the honest framing

This is where credibility is won or lost, so we will be precise. The Swiss Ephemeris reproduces NASA JPL to roughly one milliarcsecond and is the accuracy reference. XALEN does not beat it, and we will never claim it does. What XALEN does is match Swiss/DE440 to JPL-class parity on the classical planets — sub-arcsecond agreement — with an analytic Moon that is arcsecond-class rather than milliarcsecond-class.

The numbers below are a real benchmark of XALEN against NASA JPL DE440 over the 1900–2050 range, and they are reproducible — not a marketing figure:

cargo run -p xalen-validation

Every planet is sub-arcsecond. A separate 20,000-chart sweep over the same grid produced zero charts exceeding 0.1° of error on any body. To put that in perspective: a 0.1° error is far below the threshold at which any sign placement, house cusp, nakshatra, or yoga determination would change. For natal charts, divisional charts, dasha timing, and matching, this is indistinguishable from the reference.

The one place to be deliberate: the analytic Moon sits around 2.8″ RMS, wider than the planets and far wider than Swiss's milliarcsecond Moon. For the vast majority of astrology — including Vedic Moon-based systems where the Moon's sign and nakshatra are what matter — 2.8″ is irrelevant. But if you genuinely need JPL-grade lunar or outer-planet precision (precise eclipse work, research-grade timing), load the DE440 SPK kernel; XALEN's optional kernel reader gives you full JPL-class results on demand. Use the analytic path for speed and portability, switch to the kernel for the last fraction of an arcsecond.

To say it once more, cleanly: XALEN matches Swiss/DE440 to sub-arcsecond parity on the planets. It does not, and we do not claim it does, beat the Swiss Ephemeris.

Where Swiss Ephemeris is still the better choice

Fairness, not deflection. Reach for the Swiss Ephemeris when:

• You need milliarcsecond fidelity from a single analytic call across millennia, including a milliarcsecond Moon, without managing kernel files.
• You are doing research-grade astronomy where it is, definitionally, the gold reference everyone calibrates against.
• Your project is itself open-source under AGPL/GPL-compatible terms, in which case the AGPL is no obstacle and you get the most battle-tested engine in the field.
• You are happy to take the commercial license and want decades of production hardening behind you.

If any of those describe you, Swiss is a great call. XALEN's case is for the large middle of the market: commercial, networked products that need parity-grade accuracy without AGPL exposure.

Beyond raw astronomy: the full Vedika stack

One more honest distinction. The Swiss Ephemeris provides raw astronomy only — planetary positions, houses, the mathematical primitives. It does not compute yogas, doshas, dashas, or compatibility. That work is yours to build. The same is true of any bare ephemeris.

XALEN is the engine layer of the broader Vedika Intelligence API, which adds the interpretive and product layers on top:

• 25 divination systems / 704 operations (around 250 available in a public sandbox for free testing).
• 104–131 computed yogas, doshas, Vimshottari and conditional dashas, 36-guna matching, Lal Kitab, KP, 60 divisional charts, 50 ayanamsas, and 23 house systems — every figure code-computed, not model-guessed.
• A native RAG-grounded conversational endpoint (POST /api/v1/astrology/query) — answers grounded in classical sourcing, not canned templates.
• Native voice (speech-to-text → reasoning → text-to-speech) in 30 languages, and 30 languages platform-wide.
• An MCP server with 36 tools so agents can call the platform directly.
• Pricing from $12/month.

Classical claims served by the platform are tied to sourced texts rather than fabricated — the engine is precise and the interpretation layer is grounded. The point of the comparison stands at every layer: where a Swiss-based stack gives you astronomy plus an AGPL question to answer, XALEN gives you parity-grade astronomy under Apache-2.0, with the higher-order astrology already built on top.

How to decide

• Closed-source, white-label, or on-prem SaaS and you want to avoid AGPL §13? → XALEN (Apache-2.0). This is the clean win.
• Need the full astrology layer — yogas, dashas, matching, conversational, multi-language — not just coordinates? → Vedika on top of XALEN.
• Need a milliarcsecond Moon from a single analytic call, or you're fine with AGPL because your project is open-source? → Swiss Ephemeris.
• Need research-grade lunar/outer precision but otherwise want Apache-2.0? → XALEN with the DE440 kernel loaded.

You can verify everything here yourself: cargo add xalen-ephem, pip install xalen, or npm i @xalen/wasm to run the engine; cargo run -p xalen-validation to reproduce the accuracy benchmark; and the source on GitHub at vedika-io/xalen-ephemeris to read the Apache-2.0 license for yourself.

To explore the full platform, the free sandbox and developer docs live at vedika.io — try the ~250 public sandbox operations with no auth, then wire in the SDK or the MCP server when you're ready to build.