Three servers, one identical EOP file — and only one fit for automation

Several institutions hand out Earth orientation parameters. The files can be byte-for-byte identical, yet they differ in licence and in how you get at them — and one source will happily answer 200 OK with a header promising 3.7 MB of data, then send you 434 bytes of a login page.

If you are building a service that redistributes EOP, you have to pick a source. The choice looks technical. It is mostly legal. What follows is what I established empirically, with the commands, so you can repeat it.

The starting point: finals2000A.all

This is the workhorse file for Earth orientation: polar motion (x_p, y_p), the UT1−UTC offset, length of day (LOD) and the celestial pole offsets (dX, dY). Fixed-width format, roughly 3.7 MB, covering 1973 to date plus a year of predictions.

At least three servers publish it:

• USNO — maia.usno.navy.mil/ser7/finals2000A.all
• IERS — datacenter.iers.org/data/9/finals2000A.all
• NASA CDDIS — cddis.nasa.gov/archive/products/iers/finals2000A.all

The instinctive pick is IERS, because it is the body responsible for these parameters. Or NASA, because NASA sounds dependable. Both instincts lead somewhere awkward, for entirely different reasons.

The CDDIS trap: the headers lie

Start with the sneakiest one. Check whether the file is there using HEAD, as any sensible automation would:

$ curl -sSI https://cddis.nasa.gov/archive/products/iers/finals2000A.all

HTTP/1.1 200 OK
Server: Apache
Last-Modified: Thu, 30 Jul 2026 17:43:15 GMT
ETag: "3958e4-657d79b4eceaa"
Content-Length: 3758308

Status 200. Size 3,758,308 bytes — exactly what the file should weigh. A sensible Last-Modified, a plausible ETag. Everything says the resource is public and ready.

Now GET the very same URL:

$ curl -sS -D - -o /dev/null https://cddis.nasa.gov/archive/products/iers/finals2000A.all

HTTP/1.1 302 Found
Location: https://urs.earthdata.nasa.gov/oauth/authorize?client_id=...
Content-Length: 434

Why is that dangerous? Because the typical download script looks about like this:

# THE NAÏVE VERSION — don't
r = requests.get(URL)
if r.status_code == 200:
    open(CACHE, "wb").write(r.content)   # overwrites the cache with 434 bytes of HTML

HTTP libraries follow redirects by default, so status_code will be 200 — the status of the login page, not of the file. The condition passes. The script overwrites a perfectly good cache from yesterday with HTML. Your service breaks, and the log says “downloaded successfully”.

The correct check asks whether the response looks like data:

# Servers can return 200 with a login page instead of data.
# The status code alone is not enough — check size and content.
data = r.content
if len(data) < 1_000_000:
    raise ValueError(f"response too small ({len(data)} B) — this is not the data")
if not data[:1].isdigit():
    raise ValueError("content doesn't look like finals2000A (expected a year digit)")

# only now replace the cache — and do it atomically
open(tmp, "wb").write(data)
os.replace(tmp, CACHE)

The first character of a valid finals2000A.all is a digit: records open with a two-digit year. HTML opens with <. That single line separates data from an error page.

NASA's own policy is liberal, incidentally — mission data is usually CC0, commercial use is fine, citation is encouraged. The obstacle is not the licence; it is the login requirement, which rules this source out for an unattended cron job.

USNO versus IERS: same file, different licence

That leaves two. Do they actually differ?

$ curl -sS -o usno.all https://maia.usno.navy.mil/ser7/finals2000A.all
$ curl -sS -o iers.all https://datacenter.iers.org/data/9/finals2000A.all
$ sha256sum usno.all iers.all

4b828090fc94114168014b61439fa5e6ec0bdfda518075a32baffea90110954d  usno.all
4b828090fc94114168014b61439fa5e6ec0bdfda518075a32baffea90110954d  iers.all

Byte-for-byte identical. Same checksum, same 3,758,308 bytes, same Last-Modified. Technically the choice between them is a coin flip.

Legally it is not.

USNO: “distribution unlimited”

The maia.usno.navy.mil pages carry this statement:

In practice: there is no rights holder who could impose redistribution terms. You may download, process, republish and use it commercially. Attribution is not legally required — though it remains good scientific practice.

IERS: no explicit licence

The IERS Data Center is operated by BKG, the German Federal Agency for Cartography and Geodesy. Its legal notice is largely a disclaimer of liability. There is no explicit licence — but no explicit prohibition either.

For personal use that hardly matters. It starts to matter for redistribution: a service handing these files onward is republishing someone else's dataset without express permission. In the EU there is also the sui generis database right (Directive 96/9/EC), which protects the collection rather than the individual facts.

ESA: an independent series with a catch

The European Space Agency publishes its own, independent EOP series through the Navigation Support Office. A tempting alternative — until you read the licence.

Since 2017 ESA's default is CC BY-SA 3.0 IGO. The ShareAlike clause requires derivative works to be distributed under the same terms.

For a mixed dataset the consequence is awkward: folding the ESA series into a shared output file could force CC BY-SA onto the whole thing — including the part built from public-domain data. If you want your output free of licence obligations, the ESA series has to live in a separate, clearly labelled module, or stay out.

Summary

Practical takeaways

1. Pull from USNO. The file is identical down to the byte, and the legal terms are as clean as they get. Here, choosing a source is a legal decision with no technical cost.
2. Keep IERS as a fallback. When USNO is unreachable, data under weaker terms beats no data at all — provided you record which source you actually used.
3. Validate content, not status codes. Response size and the first character are enough to tell data from a login page. Without that, one redirect can quietly wipe a working cache.
4. Don't mix licences in one dataset. ShareAlike is contagious; once it is in the shared file, it covers everything.
5. Write atomically. Temporary file plus os.replace(). An interrupted download must never leave a truncated file where the working cache was.

All checksums and server responses verified on 2 August 2026. This describes the state of those sources on that date — terms do change, so re-check before making commercial commitments. This is not legal advice.