Is Swiss Ephemeris's AGPL License a Problem for Your Astrology SaaS?

If you are building an astrology product and you searched for swiss ephemeris agpl commercial license saas, you are almost certainly at a specific moment: you have a working prototype, legal or a prospective customer has asked "what's under the hood," and you just discovered that the astronomy engine everyone uses is licensed AGPL-3.0. The short answer to the headline question is: it depends entirely on whether your service is networked and whether you can live with copyleft — and for most commercial SaaS the practical answer is "yes, it's a problem you have to deal with, but it is solvable."

This article lays out, honestly, exactly when the AGPL bites, what the commercial-license path really costs (it is modest, not ruinous), and why a permissively licensed engine removes the question instead of answering it. We build Vedika on our own Apache-2.0 engine, so we have an obvious bias — but the facts below survive a skeptical read, and we concede competitors' real strengths along the way.

What the AGPL actually requires

Swiss Ephemeris, maintained by Astrodienst, is dual-licensed: AGPL-3.0 OR a paid commercial license. If you don't buy the commercial license, you operate under the AGPL. The relevant clause is the one that distinguishes the AGPL from the ordinary GPL:

AGPL §13 ("Remote Network Interaction"): if you run a modified version of the software and let users interact with it over a network, you must offer those users access to the corresponding source code.

Read that carefully, because the internet is full of both overstatement and wishful thinking about it. Two things are true at once:

• The trigger is network interaction, not "distribution." The whole point of the AGPL over the GPL is to close the "SaaS loophole." A classic GPL library only obligates you when you ship a binary to someone. The AGPL says: if remote users interact with the program, that counts. A web API is remote network interaction.
• The obligation attaches to the "corresponding source" of the covered work and its derivative. The genuinely contested question is how far the copyleft boundary extends from the ephemeris into your application code — the classic "linking" debate. The Free Software Foundation's position is expansive (dynamic linking creates a derivative work); some lawyers read it more narrowly. Reasonable engineering counsel differs.

Here is the part most blog posts get wrong, so we will be precise: the AGPL does not automatically force you to open-source your entire proprietary platform the moment you import the library. What it does is create a legal question — "is my application a derivative work that must be disclosed?" — whose answer depends on how you link the engine, how your counsel reads §13, and your appetite for risk. For a venture-funded SaaS or an enterprise white-label deal, "it depends and our lawyer is uneasy" is itself the problem. Procurement teams ask about it. Acquirers' diligence flags it.

When the AGPL actually bites — and when it doesn't

If you are reading this, you are probably in one of the bold rows. That does not mean "abandon Swiss Ephemeris." It means you have a decision to make.

The commercial-license path: honest costs

The most common myth — repeated by people selling alternatives — is that the Swiss Ephemeris commercial license "costs a fortune." It does not. Astrodienst offers a commercial license as a modest one-time fee with long validity (their professional license has historically been valid for decades — effectively the life of the product). For a funded company shipping a paid product, the dollar amount is rarely the deciding factor.

So we will be fair: buying the Swiss Ephemeris commercial license is a completely legitimate, well-trodden path. Many serious astrology products do exactly this. If you love Swiss Ephemeris's accuracy (you should — see below) and you are happy to pay once and stop thinking about copyleft, that is a defensible engineering decision. We are not going to pretend otherwise.

What you are actually buying is removal of the legal question. What you are not escaping is the second-order dependency: your license-compliance posture now depends on an upstream third party's terms, their interpretation, and their continued offering of those terms. For most teams that is acceptable. For some — particularly those who want zero upstream legal dependency, or who are building infrastructure others will embed — it is precisely the thing they want to avoid.

The third option: a permissively licensed engine

The reason this question feels inescapable is that nearly every astrology API on the market wraps Swiss Ephemeris and inherits its licensing situation. To our knowledge that list includes Prokerala, AstrologyAPI.com, DivineAPI, FreeAstrologyAPI, and popular open-source libraries like Kerykeion, flatlib, immanuel, and VedAstro. If you build on any of those, you have not escaped the AGPL question — you have inherited it, sometimes without realizing it. (This is worth auditing in your own dependency tree before a customer's lawyer does it for you.)

Two notable exceptions built their own astronomy engine:

• RoxyAPI ships its own Roxy Ephemeris, validated against JPL Horizons, under the MIT license. Credit where due — that is a genuinely independent engine and a real permissive-licensing story. If you only need raw astronomy and want a permissive engine, it is a legitimate option.
• Vedika built XALEN, a pure-Rust, Apache-2.0 ephemeris engine. Apache-2.0 is permissive: you can embed it in closed-source, white-label, or on-prem deployments with no source-disclosure obligation. There is no commercial license to buy, no §13 to reason about, and no upstream legal dependency to inherit.

That is the core argument of this post: a permissive engine doesn't answer the AGPL question — it makes the question disappear. There is nothing for procurement to flag.

What XALEN is, technically

XALEN computes positions from analytic theories rather than wrapping a binary kernel: VSOP87A for the planets, a truncated ELP2000-82 series for the Moon, Meeus algorithms, IAU 2006 precession with the 2000B nutation model, and an optional JPL DE440 SPK kernel reader when you need full kernel-grade precision. The core is zero-unsafe, thread-safe, compiles to wasm32, and produces a full chart in roughly 336 µs.

It is published and installable today, which means every claim here is checkable in about thirty seconds:

# Rust
cargo add xalen-ephem

# Python
pip install xalen

# JavaScript / WASM (runs in the browser too)
npm i @xalen/wasm

The published surface is 15 crates on crates.io (xalen-ephem, coords, houses, vedic, western, time, ayanamsa, stars, chart, chinese, world, lalkitab, iching, numerology, ffi), npm packages (@xalen/wasm plus @vedika-io/sdk, mcp-server, cli, react), PyPI (xalen, vedika-sdk), and the source repo at github.com/vedika-io/xalen-ephemeris under Apache-2.0.

The accuracy question — answered honestly

Permissive licensing is worthless if the math is wrong, so this is where most "Swiss alternative" pitches quietly cheat. We will not. Here is the honest framing, and we mean the word "honest."

Swiss Ephemeris is the reference. It reproduces NASA JPL ephemerides to roughly the milliarcsecond level because it ships the actual JPL data. Nothing analytic "beats" it, and we will never claim XALEN does. What we claim is parity for the classical planets — XALEN matches Swiss/DE440 to JPL-class agreement where it counts for astrology.

Here are the real numbers, validated against NASA JPL DE440 across 1900–2050. You can reproduce them yourself:

cargo run -p xalen-validation

Read that table carefully, because the honesty is in the detail. Every planet is sub-arcsecond. The Moon, computed from the truncated analytic ELP series, is wider — arcsecond-class, around 2.8″ RMS. That is more than precise enough for a birth chart (a chart sign or nakshatra boundary is many arcminutes wide; 2.8″ is about 0.0008°), but it is not milliarcsecond. If your use case genuinely needs JPL-grade Moon or outer-planet precision — high-end research, eclipse timing — load the optional DE440 kernel and you get kernel-grade results from the same engine.

A separate 20,000-chart sweep over the 1900–2050 grid produced zero charts exceeding 0.1° total error. We say "20,000-chart sweep," not some inflated round number, because that is the test we actually ran. If you see anyone (including us) claim "more accurate than Swiss" or cite a "reproducible JPL DE440 benchmark" benchmark, treat it as marketing, not measurement.

Engine vs. platform: what you're really comparing

One more piece of honesty, because it reframes the whole decision: Swiss Ephemeris gives you raw astronomy only. Planetary longitudes, house cusps, ayanamsa, sidereal time. It does not compute yogas, doshas, dashas, or compatibility matching — nor should it; that is not its job. Most of the engineering work in an astrology product lives above the ephemeris.

So if your real question is "build vs. buy the whole stack," the comparison is not Swiss-vs-XALEN-the-engine; it is Swiss-plus-your-own-interpretation-layer vs. a platform that ships the interpretation layer too.

To be fair to Swiss: as a library it is rock-solid, battle-tested over decades, and the most accurate option that exists. If all you need is raw astronomy and you are happy to license it, it is an excellent choice. The platform comparison only matters if you would otherwise be building dashas, yogas, and matching yourself.

So — is the AGPL a problem for you?

A clean decision tree for a founder or CTO:

• Hobby, research, or fully open-source product? The AGPL is not a problem. Use Swiss Ephemeris freely and enjoy its reference-grade accuracy.
• Commercial SaaS, but you are happy to pay once and stop thinking about it? Buy the Swiss commercial license. It is modest, long-lived, and legitimate. Done.
• Closed-source, white-label, on-prem, or you want zero upstream legal dependency? A permissively licensed engine (XALEN under Apache-2.0, or RoxyAPI under MIT for raw astronomy) removes the question entirely — no fee, no §13 analysis, nothing for procurement to flag.
• You also need yogas, dashas, matching, multilingual conversational/voice output? That is a platform decision, not an engine decision — and it is where Vedika's full stack does the work Swiss was never meant to do.

The genuine win of a permissive engine is not "Swiss costs a fortune" (it doesn't) and not "we're more accurate" (we aren't — we match it for planets and stay arcsecond-class on the Moon). The win is copyleft freedom plus no upstream legal dependency: you ship closed-source with a clear conscience and a clean diligence answer.

Try it before you trust us

Everything above is checkable. Install the engine (cargo add xalen-ephem / pip install xalen / npm i @xalen/wasm), run cargo run -p xalen-validation to reproduce the accuracy table, or hit the free vedika.io sandbox (~250 public endpoints, no key) and read the docs. If a skeptical engineer fact-checks this article, we would rather they come away saying "that was accurate" than impressed — accuracy is the whole point of an ephemeris, and of an honest comparison.