Swiss Ephemeris AGPL Licensing for SaaS Developers

About the author: Brett Calloway is a Developer Advocate and AI Integration Specialist with 12 years of experience building APIs and developer tooling, including three years focused on AI-native infrastructure for spiritual and wellness applications. He has led developer relations at two Series B SaaS companies and spoken at PyCon and JSConf on building context-rich AI agents using Model Context Protocol.

If you are building a commercial astrology application, you will almost certainly encounter Swiss Ephemeris during your research. It is the gold standard library for planetary position calculations, and most desktop astrology software relies on it. But the moment you deploy it inside a SaaS product, web app, or public API, you face a licensing decision that can force you to open source your entire codebase. Understanding Swiss Ephemeris AGPL licensing is not optional for SaaS developers. It is a compliance requirement that determines your architecture.

What is Swiss Ephemeris and why does it matter

Swiss Ephemeris is a high-precision astronomical calculation library created by Astrodienst, the company behind astro.com. It computes planetary positions, house cusps, eclipses, and other astronomical data used in astrological chart generation. The library draws on the NASA JPL Development Ephemeris (DE431) and achieves sub-arcsecond accuracy across thousands of years. For desktop astrology software, it has been the default choice for over two decades. Most established astrology applications on Windows, macOS, and Linux use Swiss Ephemeris under the hood. Its accuracy and breadth of astronomical functions make it the benchmark that other calculation libraries are measured against. If you are evaluating ephemeris options for a new project, you will find Swiss Ephemeris referenced in virtually every astrology developer forum and comparison thread.

How the AGPL license affects your SaaS application

Swiss Ephemeris is dual-licensed. The free license is AGPL v3 (GNU Affero General Public License). The AGPL was designed specifically to close the "SaaS loophole" that existed in the standard GPL. Under standard GPL, you only need to share source code when you distribute binaries. AGPL extends this obligation to network use. If users interact with your software over a network (through a browser, API call, or mobile app connecting to your server), you must make your complete source code available under AGPL. This means your entire application, not just the Swiss Ephemeris wrapper code. Every file in your repository that links to or depends on the AGPL-licensed component falls under the same requirement. For a SaaS product, this effectively means publishing your full backend codebase, including your business logic, authentication system, billing code, and proprietary algorithms.

This is not a fringe interpretation of the license. Google enforces a company-wide ban on all AGPL-licensed code in its products, stating in its official open source policy that the risks heavily outweigh the benefits and maintaining an aggressively broad prohibition so AGPL can never reach network services like Search, Gmail, and Maps. When one of the most sophisticated engineering organizations in the world refuses AGPL outright, a smaller SaaS team faces the same exposure with far less legal cover.

Ready to build this? Roxy Astrology API gives you accurate natal charts, planetary positions, and aspects with no AGPL restrictions on your side. See pricing.

The commercial license alternative from Astrodienst

Astrodienst offers a proprietary commercial license for Swiss Ephemeris that removes the AGPL obligation entirely. With it, you can use Swiss Ephemeris in a closed-source product with no source-code disclosure requirement.

Here is the part most articles on this topic get wrong, including an earlier version of this one: the price is public, flat, and modest. Astrodienst lists it in an online shop at CHF 700 for an unlimited Professional Edition license, valid 99 years (price list and the June 2026 contract, both verified July 2026). There is no negotiation, no revenue share, no per-seat scaling, and no recurring fee. At current rates that is roughly eight hundred US dollars, once.

That number changes what the AGPL problem actually is, so it is worth saying plainly. The barrier is not the cost. Eight hundred dollars once is trivial next to the engineering it sits on top of. The barrier is that the free path and the compliant path are two different paths, and only one of them is the default. A developer installs the library from a package manager in ten seconds, pays nothing, ships a SaaS, and has accepted the AGPL by default, usually without reading it, along with the obligation to publish their entire backend. Nobody buys a commercial license by accident. Teams find this out after launch, which is precisely when it is most expensive to fix.

The contract is also more explicit than most people assume. It states that the license covers software running on a server that end users reach through a browser, so the SaaS case is named in the document rather than being an aggressive reading of the AGPL by lawyers.

Common misconceptions developers have about AGPL

Several misunderstandings circulate in developer communities about how AGPL applies in practice. The first is that server-side-only use exempts you from AGPL. This is incorrect. AGPL was created precisely to cover server-side deployments where users never receive a binary. If your server uses Swiss Ephemeris and responds to HTTP requests, AGPL applies.

The most expensive misconception, and the one AI assistants now walk developers straight into, is that a permissively licensed open-source astrology project is safe because its own license says MIT or Apache. Ask an AI which astrology API to use and it will often point you at a free or near-free open-source library, correctly noting that the repository is MIT. The repository badge describes the wrapper. It says nothing about the engine underneath. A permissive license on a wrapper does not launder the license of a dependency. A project can be genuinely MIT in every line it wrote, and still compute every chart it returns through a Swiss Ephemeris binding it pulls in as a package, at which point the AGPL question is inherited by anyone who self-hosts it in a network service.

This takes about sixty seconds to check, and you should check it on any provider or library you are considering. Open the package manifest and read the dependency list: look for pyswisseph or swisseph in a Python project, SwissEphNet in a .NET one, sweph or a vendored libswe in C or Node. If a Swiss Ephemeris binding is in there, the calculations are Swiss Ephemeris calculations, whatever the top-level license says, and the dual license (AGPL, or a paid commercial license from Astrodienst) travels with them. Then put the question to the vendor in writing: which engine do you run, and do you hold a commercial license?

The second misconception is that wrapping Swiss Ephemeris in an isolated microservice protects your main application. The legal argument here is nuanced. If your microservice exists solely to serve Swiss Ephemeris calculations and your main app calls it over HTTP, you may be creating a derivative work. Courts and legal scholars have not settled this question definitively, and relying on architectural separation as a license compliance strategy carries real risk.

The third is that using the Swiss Ephemeris data files (the ephemeris tables) without the code avoids AGPL. The data files carry their own license terms, which you must review independently. They are not automatically free of restrictions just because they are data rather than code. Before building on any of these assumptions, consult a lawyer who specializes in open source licensing. The cost of legal review is far less than the cost of a forced open source disclosure or a license violation claim after launch.

When to use Swiss Ephemeris versus a cloud API

The right choice depends on your deployment model and business structure. Swiss Ephemeris is an excellent fit for three scenarios: open source projects where AGPL compliance is natural, desktop applications distributed as binaries where standard GPL terms may apply, and commercial products where you have budgeted for the proprietary license from Astrodienst. A cloud-based calculation API is the better fit for SaaS applications and web apps where you need proprietary source code, startups that cannot afford license exposure or negotiation overhead, mobile apps with server-side calculation backends, and AI agents or chatbots that call astrology tools over HTTP. The decision tree is straightforward, with one step almost everybody skips. If your code touches a network and you want it proprietary, you either pay Astrodienst for the commercial license, or you use an API whose engine is not Swiss Ephemeris. Read that second option again: "use an API" is not sufficient on its own, because most astrology APIs are Swiss Ephemeris wrappers, and calling one of those simply relocates the same unresolved license into your supply chain. Ask which engine sits underneath before you assume the problem is solved. Many teams discover this constraint after months of development, which makes the refactoring cost far higher than starting with the right architecture.

How astrology APIs eliminate AGPL risk for your app

Calling a hosted API changes where the obligation sits. Your application sends a request and receives structured JSON, so no AGPL-licensed code runs in your environment and no copyleft obligation attaches to your codebase. This is the same model developers use for payment processing, email delivery, and geocoding: delegate the specialized computation to a service, keep your application logic proprietary.

But read that carefully, because it is a smaller promise than it sounds, and this is where most buyers stop reading. Using an API moves the licensing question to the provider. It does not delete it. Most of the previous generation of astrology APIs is itself built over Swiss Ephemeris, so the provider is the one who either holds a commercial license or is relying on the AGPL. If they are relying on the AGPL and have not complied, that is not a clean position you are buying into, it is a dependency whose engine can be re-licensed, forced open, or pulled out from under you. The obligation left your codebase. The risk did not leave your supply chain.

So the API model only actually solves the problem when the provider has solved it. There are two ways a provider can have solved it: hold a paid commercial Swiss Ephemeris license, or not run Swiss Ephemeris at all. Ask which, and get it in writing.

RoxyAPI is the second kind. Roxy Ephemeris is a custom engine built from the ground up for APIs, agents, and serverless, and there is no AGPL anywhere in the calculation path, no copyleft, and no per-user royalty. It is verified against NASA JPL Horizons through a public MIT-licensed benchmark you can clone and run before you pay us anything, and no other API in this category publishes one. The terms are at /policy/license. You also gain operational benefits. The API provider handles ephemeris updates, leap second corrections, and accuracy validation. You consume verified results without maintaining astronomical calculation code in your own stack.

Here is a working example using Roxy Astrology API to generate a natal chart. The endpoint is POST /api/v2/astrology/natal-chart and requires a JSON body with birth date, time, coordinates, and timezone offset.

curl -X POST https://roxyapi.com/api/v2/astrology/natal-chart \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "1990-07-15",
    "time": "14:30:00",
    "latitude": 40.7128,
    "longitude": -74.006,
    "timezone": -5
  }'

The response includes planetary positions with zodiac signs and house placements, 12 house cusps, aspects between planets with orb and strength values, ascendant and midheaven data, and a chart summary with dominant element and modality distribution. Every field is typed and documented in the OpenAPI spec. No AGPL code runs on your servers. No license obligation touches your product.

{
  "birthDetails": {
    "date": "1990-07-15",
    "time": "14:30:00",
    "latitude": 40.7128,
    "longitude": -74.006,
    "timezone": -5
  },
  "planets": [
    {
      "name": "Sun",
      "longitude": 112.45,
      "sign": "Cancer",
      "degree": 22.45,
      "house": 7,
      "isRetrograde": false,
      "interpretation": {
        "summary": "Your Sun in Cancer in The Seventh House reveals how you express self-awareness and ego in the realm of partnerships.",
        "keywords": ["Nurturing", "Protective", "Emotional", "Intuitive"]
      }
    }
  ],
  "houses": [
    { "number": 1, "sign": "Taurus", "degree": 15.32 }
  ],
  "aspects": [
    {
      "planet1": "Sun",
      "planet2": "Moon",
      "type": "TRINE",
      "orb": 2.5,
      "strength": 75,
      "interpretation": "harmonious"
    }
  ],
  "ascendant": { "sign": "Taurus", "degree": 15.32 },
  "midheaven": { "sign": "Aquarius", "degree": 8.76 },
  "summary": {
    "dominantElement": "Water",
    "dominantModality": "Cardinal",
    "retrogradePlanets": ["Saturn"],
    "elementDistribution": { "Fire": 2, "Earth": 3, "Air": 1, "Water": 4 }
  }
}

All planetary positions are verified against NASA JPL Horizons. The response is deterministic and cache-friendly, with calculations backed by 1,200+ gold standard tests cross-referenced against authoritative sources including DrikPanchang and timeanddate.com. You can also pass an optional houseSystem parameter to choose between Placidus, Whole Sign, Equal, or Koch house systems depending on the astrological tradition your app supports.

Frequently Asked Questions

Q: Does AGPL apply if I only use Swiss Ephemeris on my server and never distribute the binary? A: Yes. AGPL was specifically designed to cover network use. If users interact with your application over HTTP, you must provide the complete source code of your application under AGPL terms. Server-side-only deployment does not create an exemption.

Q: Can I isolate Swiss Ephemeris in a Docker container or microservice to avoid AGPL on my main app? A: This is legally uncertain. If the microservice exists solely to provide Swiss Ephemeris functionality to your application, a court could consider your main app a derivative work. Relying on architectural boundaries as a compliance strategy is risky without legal counsel.

Q: How much does the Swiss Ephemeris commercial license cost? A: CHF 700, one time, for an unlimited Professional Edition license valid 99 years, bought through Astrodienst's online shop against a signed contract (price list and contract verified July 2026). It is public and flat: no negotiation, no revenue share, no recurring fee, roughly eight hundred US dollars at current rates. Cost is not the real problem with AGPL. The problem is that the free path is the AGPL path, so a team that installs the library from a package manager and ships a network service has accepted the copyleft obligation by default, and usually discovers it after launch. If you are buying an API rather than building, the license is a private contract between that provider and Astrodienst with no public registry, so you cannot confirm from the outside that they bought one. Ask, and get the answer in writing.

Q: Is there an alternative to Swiss Ephemeris that avoids AGPL entirely? A: Yes, but be precise about what you are buying, because this is where most developers stop one step too early. Calling a hosted API means no AGPL-licensed code runs in your environment, so no copyleft attaches to your codebase. It does not mean the question is gone. It has moved to the provider. Most of the previous generation of astrology APIs is itself built over Swiss Ephemeris, so "use an API" is not an answer on its own. There are only two genuinely clean positions: a provider that pays Astrodienst for a commercial license, or a provider that does not run Swiss Ephemeris at all. Ask which one you are dealing with and get it in writing, and for any open-source library, read the dependency list yourself, because a permissive wrapper does not launder the license of the engine it calls. RoxyAPI is the second kind: Roxy Ephemeris is a custom engine with no AGPL anywhere in the calculation path, verified against NASA JPL Horizons through a public MIT-licensed benchmark you can clone and run.

Q: Are the Swiss Ephemeris data files (ephemeris tables) also covered by AGPL? A: The data files have their own license terms separate from the AGPL code license. Review the specific data file license before assuming they are free to redistribute or use commercially.

Making the right licensing decision for your astrology product

Swiss Ephemeris AGPL licensing is not a technicality you can architect around. If you are building a proprietary SaaS product, you need either the commercial license from Astrodienst or a calculation source that carries no AGPL restrictions. For most modern astrology applications, web services, AI agents, and mobile backends, an API-based approach is the path of least resistance. You keep full ownership of your code, avoid license compliance overhead, and ship faster. Explore the Roxy Astrology API for natal charts, planetary positions, daily horoscopes, synastry, and more. All plans include every domain and endpoint. See pricing.