legalize-es: Spain's Legislation in Git-Versioned Markdown

What legalize-es stores

legalize-es is a repository of Spanish legislation in Markdown, with each law represented by one file and each reform represented by a commit. Its intended audience is broader than a legal publisher alone. The repository is useful for engineers building searchable legal-information systems, researchers tracing changes to a provision, and readers who want a readable file-based representation of BOE material. The README describes state legislation and autonomous-community legislation published through the BOE, including constitutional text, organic laws, ordinary laws, royal decree-laws, legislative royal decrees, royal decrees and other state instruments. It also lists foral and regional ranges for autonomous communities.

The repository does not present every publication as an undifferentiated corpus. It distinguishes between point_in_time, which the README describes as a historical consolidated version, and as_enacted, which is the original text without later reforms incorporated. The distinction matters because a consolidated text can answer a different question from the wording of the act at its original publication. The repository also records publication and entry-into-force dates separately, including separate commits for phases of entry into force.

This makes legalize-es a versioned source for legal text rather than a hosted legal research interface. It provides files, metadata and Git history, but the README does not document a web application, search service, editor or API built on top of the repository.

How the BOE data becomes Markdown

The repository is organized around the BOE data model and an ELI-based directory structure. State legislation is placed under es/, while autonomous-community material appears under directories such as es-pv, es-ct and es-ga. The path is divided into subdirectories named with the first two characters of the SHA-1 of the norm identifier. The manifest .legalize.yml declares the route for each norm, while YAML frontmatter records fields such as the legal range and version metadata.

The README identifies two important timing fields. Source-Date represents publication of the act. last_updated represents entry into force for the version included. If a publication has multiple entry-into-force phases, the repository keeps a separate commit and Effective-Date for each phase. Where the BOE does not state the date on which a block becomes effective, the repository omits last_updated and records uncertainty in extra.effective_date_unknown_blocks. That design preserves an explicit gap instead of presenting an inferred date as certain.

Conversion also changes the source format. Markdown is used for the text, references to official images are retained without copying binary assets, and nested tables are represented as HTML so their cells remain available. Acts without consolidation retain their original body and known reforms rather than receiving reconstructed consolidated wording. Judicial acts, independent corrections and publications dominated by images are excluded, with exclusions recorded during download.

Reading a law's reform history

The defining interface of legalize-es is Git history applied directly to legal files. The README says that the git log for each law exposes when it was enacted, which articles changed and which norm caused the change. This is more useful than a single current download when the question concerns the sequence of reform, but it also means consumers must understand the repository's conventions before treating a commit as a legal event. A commit records the repository's version of a reform, while publication dates and effective dates remain separate metadata fields.

A typical reader would locate a file by its ELI-style identifier, inspect its YAML frontmatter, and then read the Markdown body. The filename pattern is documented as BOE-A-AAAA-N.md, with examples such as the Constitution at es/bb/BOE-A-1978-31229.md and a law at es/70/BOE-A-2015-11430.md. The reader should check whether the frontmatter describes point_in_time or as_enacted before comparing it with another source.

The Git-based model also creates practical integration choices. A developer can consume the repository as a filesystem snapshot, process Markdown and YAML directly, or treat commits as change events. The README does not specify a supported ingestion API, update cadence, schema version or compatibility policy, so an application should not assume that every upstream change is limited to a simple file replacement.

Installation and first use of the repository

The README does not provide an installation command, package name, release artifact or setup script. It identifies the repository as the access point for the legislation and links to the Legalize project homepage and the BOE data sources. Consequently, there is no documented command to place in an installation tutorial. A first use begins by obtaining the repository through its normal Git workflow, then locating a norm in the jurisdiction directory and reading its Markdown file with YAML frontmatter. The file and directory names above provide verified starting points.

The repository is not a packaged application, so there is no documented configuration file for a runtime, no environment variable to set and no service port to open. The relevant configuration-like artifact is .legalize.yml, which maps norms to paths. The first inspection should therefore focus on data provenance and version semantics rather than on deploying a service.

For developers, the safest first workflow is to parse the Markdown and frontmatter while preserving identifiers, dates, legal range and effective-date uncertainty. If change tracking is needed, Git commit history is the project's documented mechanism. Any automation should also retain the BOE attribution because the README says citation of the source is mandatory under the BOE reuse conditions.

Coverage gaps that affect adoption

The most important limitation is explicitly stated by the project: consolidated text is informative, and the history reflects the versions supplied by the BOE. It may omit earlier redactions when the source does not expose them. That boundary prevents a complete claim about the legal history of a provision. A user needing every prior wording must confirm whether the missing redactions exist elsewhere in the authoritative record.

The repository also excludes judicial acts, corrections issued as independent documents and publications dominated by images. Those exclusions are recorded during download, but the README does not promise that every exclusion has an equally detailed machine-readable explanation. A search or archival system that requires complete coverage of BOE publications will need to account for those gaps.

Uncertainty is visible rather than hidden. A missing last_updated can mean that the BOE did not declare the effective date for a block, with extra.effective_date_unknown_blocks identifying the uncertainty. This is preferable to guessing, but downstream code must handle an omitted field. Likewise, as_enacted documents may contain known reforms without a consolidated body, so a consumer must not automatically interpret the file as the currently applicable wording.

The repository has no GitHub releases, and the README does not document a migration or rollback procedure. A production consumer should therefore inspect commit changes and metadata before updating its local copy.

Legalize, BOE data and licensing

The repository separates the licensing status of the pipeline from the licensing status of the data. The README states that pipeline code is MIT licensed and links to legalize-pipeline. For the legislation data, it identifies the BOE reuse conditions, specifically the Resolución de 27 de junio de 2024, and requires citation of the Agencia Estatal Boletín Oficial del Estado. The top-level LICENSE file is identified as a custom license that GitHub cannot classify, so the README's summary is not a substitute for reading that file.

This distinction affects adoption. An organization interested in the conversion pipeline may find the code license straightforward, but redistribution or publication of the corpus must account for the separate data conditions. The README's attribution example names the BOE and describes the repository as a derivative work based on BOE data. It does not claim that MIT applies to the Markdown corpus as a whole. A legal-information product should preserve provenance and check the actual LICENSE and BOE terms before distributing data at scale.

The repository was not archived, and the last push was on 2026-10-16. That supports recent repository activity, but no GitHub release is available and the README does not promise a stable release cadence. Maintenance of an integrated product still depends on monitoring upstream file and metadata changes.

Editorial conclusion

Adopt legalize-es when you need inspectable BOE-derived Markdown and Git history for Spanish legislation, provided the BOE reuse conditions and the absence of judicial acts or image-dominated publications fit your use. Do not treat it as a complete legal database or as a substitute for formal legal advice. Verify the license file, the applicable BOE attribution requirements, the point_in_time or as_enacted designation of a norm, and any effective_date_unknown_blocks entry before relying on a specific text.

Frequently asked questions

Official sources

1. Issues
2. legalize-dev/legalize-es on GitHub
3. Project website
4. README