Colombia (CO) — internal licensing notes

Source research, 2026-09-16 — first proper audit of this country

No .licensing-notes.md existed for CO before this pass. datasets/co/datapackage.yml carries only a placeholder sources: Multiple sources link and created: '2024-10-01' / modified: '2024-11-07' on its one resource — never audited under this project's convention.

What the CURRENT R2 file actually is — verified, not assumed

Fetched the live public sample at https://postal.datahub.io/co/co.csv (the URL datapackage.yml points to): HTTP 200, 7,865 bytes, 100 data rows — a 13-column country_code,postal_code,place_name,admin_name1,admin_code1,admin_name2,admin_code2, admin_name3,admin_code3,latitude,longitude,accuracy,alternative_city_name file. admin_name3/ admin_code3 are empty on every row. admin_code1 is a small sequential integer (1, not an ISO or DIVIPOLA code); admin_code2 is a 5-digit number.

Cross-checked against download.geonames.org/export/zip/CO.zip directly: byte-for-byte identical postal codes, place names, admin names/codes and lat/lon for every row compared (Leticia 910001/910007/910008, El Encanto, La Chorrera, etc., down to the coordinate decimals and accuracy=4). GeoNames' CO.txt itself has 3,681 rows. This is not a coincidence — this repo's own scripts/geonames/geonames_parse_to_R2.py, run monthly by .github/workflows/run-monthly-geonames-to-R2-script.yml (Hetzner self-hosted runner), scrapes GeoNames' zip listing page for every country except allCountries.zip and re-uploads each one to R2 unmodified, monthly, indiscriminately — this is what produced the co/co.csv object dated 2026-07-30 in the brief (a routine monthly re-run, not a rebuild from a better source). I could not open the private main bucket directly — this repo's .env here has no R2_ACCESS_KEY/R2_SECRET_KEY (only CF_API_TOKEN/HETZNER_API_KEY, both blank) — but reconstructing the 12-core-field CSV from the fetched CO.txt lands at 257,792 bytes, in the right range of the reported 285,969-byte object once alternative_city_name enrichment (which the script also performs, from GeoNames' alternateNames dump) is added. Verdict: the R2 file is unmodified, monthly-refreshed GeoNames data, not anything sourced fresh from Colombia. GeoNames' own admin_code1 here is a GeoNames-internal per-country ordinal (01, 02, …), never an ISO 3166-2:CO or DIVIPOLA code — this is GeoNames' documented behaviour, not specific to CO.

The official source — found, live, and it's the SAME underlying data (with a defect)

4-72 (Servicios Postales Nacionales S.A.) is Colombia's national postal operator and publishes its own postal-code lookup tool at visor.codigopostal.gov.co/472/visor/ — like Panama's codigospostalespanama.gob.pa, this looks like an address-lookup UI, not a bulk download page (not deeply probed this pass; the actual government open-data record below is the load-bearing find).

datos.gov.co (Colombia's official open-data portal, Socrata-based) hosts the real bulk dataset: "Códigos Postales Nacionales" (www.datos.gov.co/Ordenamiento-Territorial/ C-digos-Postales-Nacionales/ixig-z8b5). Queried its Socrata metadata and resource APIs directly (api/views/ixig-z8b5.json, resource/ixig-z8b5.json, resource/ixig-z8b5.csv):

• Publisher/attribution: "Servicios Postales Nacionales - 472, Bogotá D.C." — this is 4-72's own data, published through MinTIC's open-data portal.
• Licence: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) — confirmed directly from the dataset's own license metadata field, not inferred from the portal's general policy. This is a share-alike licence, not a plain attribution one.
• Row count: 3,681 — an exact match to GeoNames' CO.txt row count. Spot-checked Leticia (department 91, municipio 91001): both datasets carry the identical three postal codes (910001/910007/910008) with identical boundary/type detail. This confirms GeoNames' Colombia postal layer is itself sourced from this exact 4-72/datos.gov.co dataset — GeoNames is not an independent or lower-quality copy here, it is a downstream derivative of the same official file, stripped down to GeoNames' schema (no boundary streets, no barrio/vereda lists) plus GeoNames' own centroid coordinates.
• Columns (14, richer than GeoNames'): codigo_departamento (DIVIPOLA department code, e.g. 91=Amazonas, 05=Antioquia, 88=San Andrés — matches known DANE codes), nombre_departamento, codigo_municipio (5-digit DIVIPOLA municipality code, e.g. 91001 Leticia, 05002 Abejorral), nombre_municipio, zona_postal, codigo_postal (the 6-digit postal code itself), limite_norte/sur/este/oeste (literal street/municipality/ river boundary descriptions of the postal zone), tipo (Urbano/Rural), and two fields GeoNames drops entirely: barrios_contenidos_en_el (neighbourhoods inside the code) and veredas_contenidas_en_el (rural veredas inside the code).
• Update cadence: portal metadata says "Frecuencia de Actualización: Anual"; rowsUpdatedAt = 2025-05-20; createdAt = 2020-11-24.

A real data-quality defect found in the official file itself, not a Socrata rendering artefact of my fetch: codigo_postal (and zona_postal, and the row-index noid) are typed as Socrata numbers, and a meaningful share of values have a stray decimal point with inconsistent digit-grouping — e.g. 153.42 (Rondón, Boyacá — should almost certainly be a 6-digit code, and this string round-trips to only 5 significant digits), 55.03 (Abejorral, Antioquia), 253.427 (Quebradanegra, Cundinamarca), 880.007 (San Andrés), 910.001 (Leticia — this one IS clean). The grouping isn't a fixed thousands-separator position (sometimes 2 digits trail the point, sometimes 3), which rules out a simple "re-insert the missing zero" fix — this needs to be resolved against a second source (the visor lookup tool, or reconstructing from zona_postal + boundary context) before codigo_postal can be trusted at face value from this file's number-typed export, not treated as cosmetic. Confirmed by pulling both the JSON and CSV export of the same rows — identical corruption in both, so it's in the underlying data, not a WebFetch parsing issue.

DANE / DIVIPOLA — the admin crosswalk, same portal, same licence

datos.gov.co also hosts "DIVIPOLA - Códigos municipios" (gdxc-w37w): 1,122 rows — matches Colombia's real count of 1,122 municipalities/districts. Also CC BY-SA 4.0. Interestingly its attribution field reads "Gobernación de Guainía, Guainía" — this specific record was harvested into the federal catalog via a regional government's Socrata instance rather than DANE's own, though the content (DIVIPOLA nomenclature) is DANE's standardised national scheme either way. DANE also publishes this directly from its own domain — geoportal.dane.gov.co/descargas/divipola/DIVIPOLA_Municipios.xlsx — found via search but not yet fetched/verified in this pass; would be the cleaner primary citation over the harvested Socrata copy if this gets built.

Colombia has 32 departments + Bogotá D.C. (33 first-level units — matches the codigo_departamento distinct count of 33 queried directly against the postal dataset). ISO 3166-2:CO defines alpha codes (CO-AMA, CO-ANT, …) for these same 33 units; the DIVIPOLA numeric department code (91, 05, …) is NOT itself the ISO code and would need a name-based crosswalk to get admin_code1 into ISO form, consistent with how every other country row in this project's registry is built. Not attempted in this research-only pass.

An old dead end, checked and ruled out

A second dataset, www.datos.gov.co/Ordenamiento-Territorial/C-digo-postal/pw6b-n5gb, appeared in search results but returns 404 on both the portal page and its Socrata resource API (resource/pw6b-n5gb.csv → {"code":"dataset.missing"...}) — a removed/superseded dataset, almost certainly the predecessor to ixig-z8b5. Not a viable source.

Verdict

Do not build yet — flag for a licence decision first, this is not a routine GeoNames refresh. Three findings change the shape of this one from a normal "GeoNames vs. official" comparison:

1. GeoNames' CO data is not a lesser copy of the official source — it's the same official source, one hop removed, missing only the boundary/barrio/vereda detail and GeoNames' own centroid replacing whatever precision the original had. There is no "upgrade to official" story here in the way LK/PA had a genuinely-different candidate; the real decision is whether to go direct to ixig-z8b5 for the richer fields (neighbourhoods, veredas, real boundary descriptions) and a DANE-direct DIVIPOLA crosswalk for admin_code1/ admin_code2, instead of leaving the pipeline pointed at GeoNames' stripped derivative.
2. The official file's own codigo_postal values have a real, unresolved numeric-formatting defect on an apparently-inconsistent subset of rows (documented above with examples) — any direct build off ixig-z8b5 must resolve this before shipping, not copy it forward. GeoNames' own copy of the same codes (910001-style) looks clean for the rows spot-checked, which raises the possibility GeoNames pulled a cleaner historical snapshot, or fixed this client-side, or the corruption is Socrata-export-specific and a differently-formatted export of the same underlying dataset (e.g. an Excel/CSV attachment instead of the API) would not have it — not established either way in this pass.
3. The licence is CC BY-SA 4.0 (share-alike), on both the postal dataset and the DIVIPOLA admin crosswalk — confirmed from each dataset's own Socrata metadata, not inferred. This is the same class of conflict this project's OSM/ODbL gate exists for: share-alike requires a derivative to be redistributed under compatible terms, which does not sit well with selling a proprietary-labelled extract with no share-alike passthrough. Per the durable provenance/licence gate (datahub-next#941 §6), licence_status.decision for CO must stay "unresolved" until a human explicitly resolves this tension — it must NOT reach datapackage.yml/datapackage.json as "compatible" by default just because a government portal calls it "open data". GeoNames' own re-export is CC BY 4.0 (no share-alike) per its standing licence — if the share-alike question can't be resolved in time, staying on GeoNames (properly re-attributed, properly crosswalked to ISO admin codes) remains the lower-risk path, even though it forgoes the richer official fields.

Recommended next step: do NOT touch datapackage.yml or build anything yet (out of scope for this pass anyway). Bring this to a human for a licence call: (a) is CC BY-SA 4.0 acceptable for a paid, non-share-alike-labelled product line, or does it force either an attribution-and- share-alike-passthrough model for CO specifically, or staying on the GeoNames CC BY 4.0 layer; (b) if official is approved, resolve the codigo_postal numeric corruption against a second official source (the 4-72 visor, or DANE's own DIVIPOLA Excel) before any row is trusted; (c) either way, source admin_code1/admin_code2 from a direct DANE crosswalk (geoportal.dane.gov.co/descargas/divipola/) rather than GeoNames' internal ordinal, since a clean ISO 3166-2:CO crosswalk is achievable and DIVIPOLA numeric codes are already present in the official postal dataset's own codigo_departamento/codigo_municipio fields.

Build — EXECUTED 2026-09-16 (LOCAL ONLY, nothing published)

Built on the GeoNames path per instruction ("build co with geonames"), since the richer official source (4-72/datos.gov.co) remains CC BY-SA 4.0 (share-alike) with no human licence decision made yet — that question is still open, see above. This build does not resolve it; it ships the licence-clean GeoNames layer instead.

Result: 3,681 rows, 33/33 ISO 3166-2:CO departments, 1,122/1,122 municipios (Colombia's real total, matched exactly). Frictionless: valid: True.

admin_code1 derived via a verified name-based crosswalk (33 departments incl. Bogotá D.C.) against Wikipedia's ISO_3166-2:CO page — GeoNames' own admin_code1 is a bare internal ordinal ("01".."33"), not ISO or DIVIPOLA. admin_code2 needed no fix: GeoNames' own value here already is the real 5-digit DIVIPOLA municipality code — cross-verified by asserting every row's DIVIPOLA department-prefix (first 2 digits) maps to exactly one ISO department code across all 3,681 rows, with zero inconsistencies. This is a stronger check than a spot-check: it would have failed loudly on any row where the name-based ISO crosswalk and the source's own numeric DIVIPOLA prefix disagreed.

Fixed the "nan" defect in the currently-sold file: confirmed the raw GeoNames export itself contains no literal "nan" string anywhere — the defect is introduced downstream by this repo's own R2 enrichment pipeline (scripts/geonames/geonames_parse_to_R2.py), not by GeoNames. This build sources from the raw export directly and does not reproduce it. admin_name3 ships correctly empty.

postal_code alone is the primary key — verified unique across all 3,681 rows, no composite key needed (differs from PK/LK/RU which needed a composite key; simpler here).

licence_status.decision: compatible — GeoNames' own re-export licence (CC BY 4.0, attribution-only, no share-alike), which is the licence that actually attaches to what's shipped. The richer official file's CC BY-SA 4.0 status is unaffected and unresolved by this build.

NOT done, by instruction: no R2 upload, no git commit, no _meta/catalog.json change, no publish_r2.py, datasets/co/ datapackage.yml left untouched (still the "Multiple sources" placeholder, no licenses, no premium_tier, stale resource bytes/modified date).

Owner decision, 2026-10-09: rely on GeoNames' CC BY 4.0

The open question was whether the CC BY-SA 4.0 licence of 4-72/MinTIC's file, which GeoNames' Colombia layer derives from, carries through to us. Decision (owner): rely on GeoNames' own CC BY 4.0 grant as published, and keep selling at tier B. The share-alike origin stays disclosed in ATTRIBUTION.txt. Status: closed by owner decision. Reopen if GeoNames changes its terms for CO or the rightsholder objects.