# legalize-kr: Korean Statutes as a Git History

> legalize-kr stores South Korean statutes as Markdown files whose commits carry promulgation dates. It is useful for tracing statutory text over time, but its history can be rebuilt with a force-push.

**legalize-kr/legalize-kr** — 대한민국 법령을 Git 저장소로 관리합니다. 각 법령은 Markdown 파일이고, 각 개정은 실제 공포일자를 가진 Git commit입니다.

- Repository: https://github.com/legalize-kr/legalize-kr
- Website: https://legalize.kr/
- Stars: 1,542 · Forks: 209
- Language: Unknown
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/legalize-kr-legalize-kr

## Why legalize-kr Turns Korean Law into Versioned Files

legalize-kr addresses a practical problem in software work involving statutory documents: ordinary snapshots show the current text, but they do not naturally preserve when and why a provision changed. This repository represents each South Korean statute as a Markdown file and records each amendment as a Git commit whose author and committer dates use the actual promulgation date. Developers can therefore inspect an earlier revision with Git rather than relying only on a website that displays the latest text.

The intended audience includes developers who need searchable legal text, researchers tracing amendment history, and teams that want to review statutory changes through familiar Git commands. The source is the 국가법령정보센터 OpenAPI, and the README states that the statute text is a Republic of Korea government public work. This makes the repository primarily a structured data source. It does not provide legal interpretation, and its Markdown representation should not be confused with a judgment about a provision's legal effect.

Related instruments sit under one statute directory. A law, its enforcement decree, and its enforcement rule can be read as separate files without first translating Korean document names into unrelated paths. This is more useful than treating every statute as an opaque download. It also means that a search for a parent law can lead to adjacent documents, although readers must still check `법령구분`, the promulgation number, and the metadata for each file.

## How the legalize-kr File Layout Encodes Legal Document Types

The repository places files under `kr/`, with one directory for each normalized statute name. Spaces are removed from the directory name to follow the law.go.kr URL convention. Standard filenames identify the legal instrument. A parent law uses `법률.md`, an enforcement decree uses `시행령.md`, and an enforcement rule uses `시행규칙.md`. An independent presidential decree uses `대통령령.md` because it does not belong to a parent law.

That distinction is not merely cosmetic. The README explains that an enforcement decree and an independent presidential decree are both legally presidential decrees, but the former has a parent law while the latter stands alone. The layout records that relationship through naming and location. If separate `법령ID` values would otherwise resolve to the same path, the repository uses a qualified filename of the form `{파일명}({법령구분}).md`. Consumers that assume every directory contains only a fixed trio of filenames would miss these qualified cases.

Titles are normalized too. The middle dot `·` at U+00B7 is converted to the Hangul araea `ㆍ` at U+318D, so a title such as `10·27` becomes `10ㆍ27`. This supports consistent lookup, but it also means that a path lookup based on the original source title may fail. Search should account for normalization rather than treating a normalized path as an exact reproduction of every title returned by the source.

## YAML Metadata and Git Commits Carry Different Kinds of Truth

Each Markdown file begins with YAML frontmatter that identifies the statute and records its legal metadata. Documented fields include `제목`, `법령MST`, `법령ID`, `법령구분`, `소관부처`, `공포일자`, `시행일자`, `상태`, and `출처`. The README also documents `원본제목` for cases where normalization changes the API's original title. `상태` distinguishes enacted statutes from repealed ones.

Git metadata provides the sequence and date-oriented history, while frontmatter provides attributes attached to the current file. Commit messages follow a documented Korean format and include links to the full statute, amendment notice, and old-to-new comparison. They also list the promulgation date, promulgation number, ministry, field, and `법령MST`. Those links are important because the repository represents a public-data compilation and does not replace the official publication source.

There is one explicit boundary in Git's dating model. Git cannot store a commit date before the Unix Epoch of 1970-01-01, so older statutes receive a commit date of 1970-01-01. The repository does not discard the historical date. It records the actual promulgation date in the YAML `공포일자` field. Code that filters amendments only by Git commit time must account for this exception or it will misclassify older material.

## Clone, Inspect, Diff, and Search Korean Statutes

The README's quick start uses Git and standard Unix tools. There is no package installation step or application server. Cloning the repository gives the reader the current Markdown tree and its commit graph. The first useful operation is opening a known statute, followed by examining its revisions.

Clone the data repository and enter its directory:

```bash
git clone https://github.com/legalize-kr/legalize-kr.git
cd legalize-kr
```

Read the current Markdown for the Civil Code:

```bash
cat kr/민법/법률.md
```

The expected result is the Civil Code file, including YAML frontmatter and Markdown body text. Inspect commits affecting its directory to see the recorded amendment history:

```bash
git log -- kr/민법/
```

A developer can compare the law with its enforcement decree using the documented `diff` command:

```bash
diff kr/민법/법률.md kr/민법/시행령.md
```

The output is a line-oriented comparison between two legal document types, not a redline generated from amendment history. For a repository-wide text search, the README uses `grep`:

```bash
grep -r "개인정보" kr/
```

Finally, select the most recent Civil Code commit before a date. The README documents the following query, which makes Git's time filter the entry point for historical retrieval:

```bash
git log --before="2025-01-01" -1 -- kr/민법/법률.md
```

Readers should inspect the selected commit and frontmatter rather than assuming that the command proves which version was legally effective on that date.

## Force-Pushes and the 1970 Date Floor Limit Downstream Automation

The main operational warning is explicit: if the ingestion and parsing pipeline improves, the project may reconstruct the entire statute history with a force-push. Every commit hash can then change. A fork, mirror, pinned commit, or automation that stores hashes as permanent references can break its historical links even when the visible Markdown remains substantially the same.

The README gives a synchronization command for consumers that have forked or otherwise reference the repository:

```bash
git fetch --all && git reset --hard origin/main
```

This command replaces the local branch reference and tracked working tree with `origin/main`. The README presents it specifically as the response to a force-push. It is destructive to local commits and uncommitted tracked changes, so the project gives no workflow for rebasing private work or reconciling local history. Anyone integrating this repository should treat upstream hashes as references to the current rewritten graph, not stable identifiers for a provision or amendment.

The second limitation is less visible but equally important. Git history before 1970 is not available through commit dates because of the Unix Epoch restriction. The frontmatter preserves the actual date, while the graph uses 1970-01-01 for the affected commits. Systems that consume Git timestamps alone will report false chronology. Legal researchers also need to distinguish `공포일자` from `시행일자`: the repository exposes both, and the README does not claim that they are interchangeable.

## legalize-kr Versus the Official Law Portal and Separate Legal Repositories

The official 국가법령정보센터 is the authoritative publication source linked by the repository metadata. It presents statutes through its own web interface and API, whereas legalize-kr compiles the source into a Git repository organized around Markdown files, commits, diffs, and local search. The practical difference is workflow: legalize-kr is better suited to code review, repository cloning, text search, and Git-based chronology, while the official service remains the place to confirm the published legal document.

The project also separates adjacent datasets into other repositories. `precedent-kr` holds precedent data, `admrule-kr` holds administrative rules, and `ordinance-kr` holds local ordinances. `legalize-pipeline` collects and refreshes public data, while `compiler` turns `.cache` into bare Git repositories. This separation means legalize-kr is not a one-stop Korean legal information platform. A task involving a precedent, administrative rule, or ordinance requires another repository.

Its data provenance is narrower and clearer than a general legal research platform: the README names the 국가법령정보센터 OpenAPI as the source for statute data. It does not document API credentials, refresh commands, cache retention, or guarantees that every query result is represented. Those omissions matter when a team expects a complete mirror or needs to explain why a remote source is absent from the checkout. The repository layout supports deterministic local inspection, but it does not by itself establish completeness or legal currency.

## Maintenance, Licensing, and Upgrade Boundaries for Legalize-kr

The repository is not archived, and its last push was on 2026-10-16. That is current maintenance information as recorded by the repository metadata, although it does not promise a release schedule. The repository has no GitHub releases. Consumers should therefore not expect release tags, packaged versions, or a documented semantic version from which to perform a conventional upgrade.

The README separates licensing by content and repository contribution. It identifies the statute text as a Republic of Korea government public work and identifies the repository structure and metadata as MIT. It does not state one blanket license for every file in the organization, and this article does not infer one. A downstream project should preserve the relevant notices and examine the exact files it redistributes.

Upgrades are primarily Git synchronization operations rather than package-manager updates. Because a pipeline improvement can trigger a full history rewrite, an upgrade may change commit IDs, not just file content. The documented reset command is suitable for a disposable clone used for reading current data. It is less suitable for a clone containing local work. The repository does not document a migration format, release changelog, compatibility policy, or rollback procedure beyond that synchronization warning.

## Conclusion

Adopt legalize-kr when you need searchable, diffable Korean statutory text and are prepared to resynchronize after history rewrites. Do not treat commit hashes as durable identifiers or rely on it as the sole authority without checking the linked text at law.go.kr. Verify the 1970 date floor, the intended file for laws with decrees and rules, and the effect of any force-push before integrating a clone into another system.

## FAQ

### How do I view the current version of the Civil Code in legalize-kr?

Clone the repository, enter the `legalize-kr` directory, and run `cat kr/민법/법률.md`. The file contains YAML metadata followed by the Markdown representation.

### How does legalize-kr represent amendments to Korean statutes?

Each amendment is recorded as a Git commit using the actual promulgation date as the author and committer date. The Markdown file also carries metadata such as `공포일자`, `공포번호`, and `시행일자`.

### What should I do after a force-push in legalize-kr?

The README instructs forks and references to run `git fetch --all && git reset --hard origin/main`. A force-push can change every commit hash, so historical hash references should not be treated as permanent identifiers.

## Sources

- [Issues](https://github.com/legalize-kr/legalize-kr/issues)
- [legalize-kr/legalize-kr on GitHub](https://github.com/legalize-kr/legalize-kr)
- [Project website](https://legalize.kr/)
- [README](https://github.com/legalize-kr/legalize-kr/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/legalize-kr-legalize-kr