After 10 years or 10,000 hours, most SRE & DevOps practitioners are YAML expert witnesses. We've written tens of thousands of lines of YAML - Kubernetes manifests, GitLab CI pipelines, Ansible playbooks, Docker Compose files, infrastructure definitions. We understand the format intimately. We know its quirks, its strengths, its limitations. This expertise is widespread, not proprietary. YAML mastery is a common skill in modern infrastructure engineering.
Nobody owns YAML. The spec is open. The implementations are open. But what licenses govern all those YAML parsers across 42+ programming languages?
You can't patent the YAML spec. The YAML 1.2 specification is an open standard maintained by the YAML Forum under the Open Standards Compact. This explicitly protects implementers from patent assertions - no one can claim exclusive rights over the specification through patents. Any implementation of the standard is protected from patent infringement.
YAML is data, & data is not code. Even when YAML expresses configuration logic, workflow definitions, or infrastructure-as-code, it remains a data serialization format. For example, botoform (developed 10 years ago, initial commit 2015) uses YAML to represent the desired state of AWS infrastructure - created before the machine learning era, before CloudFormation supported YAML (when it was JSON-only), & before Terraform had extensive provider support. These YAML schemas describe infrastructure state as data, not executable programs. Data structures & formats are not patentable subject matter under established legal precedent - raw data, database schemas, & file formats are considered abstract ideas that lack the technical novelty required for patent protection. Attempting to patent data schemas or configuration formats creates barriers to interoperability & harms the open ecosystem that makes modern software development possible.
State machines are mathematics, not inventions. Finite state machines, state transitions, & graph-based logic are fundamental computer science concepts - like algorithms & mathematical formulas - that exist in the public domain. You cannot patent the concept of a state machine any more than you can patent addition or the Pythagorean theorem. When you express state machine logic in YAML (defining states, transitions, & rules), you're describing mathematical relationships using a data format. For example, dbsnap_verify (started October 3rd, 2017) implements a state machine to verify AWS RDS snapshots across regions & accounts - the state transitions & logic represent graph theory applied to infrastructure verification, not a patentable invention. The underlying concepts have been taught in computer science curricula for decades & represent shared human knowledge, not proprietary innovations.
Let's find out what licenses actually govern the implementations.
the question
Every programming language needs a YAML parser. But who controls the code? What licenses apply? Can you use them commercially? What restrictions exist?
After researching YAML implementations across 42 languages (the same count as in the webwords project), clear patterns emerged.
the foundation
Most YAML parsers trace back to libyaml - the canonical C implementation written by Kirill Simonov & maintained by the YAML community.
License: MIT
This permissive license means you can use it anywhere, modify it freely, & include it in commercial projects. Many language implementations either wrap libyaml or use it as inspiration.
the licenses
Here's the complete breakdown across 42+ programming languages:
| Language | Library/Implementation | License | Notes |
|---|---|---|---|
| C | libyaml | MIT | Canonical implementation, foundation for many others |
| C++ | yaml-cpp | MIT | Popular C++ alternative to libyaml |
| Python | PyYAML | MIT | Standard YAML library for Python |
| JavaScript | js-yaml | MIT | Most popular JS implementation |
| JavaScript | yaml (eemeli) | ISC | Modern alternative, functionally identical to MIT |
| Node.js | Same as JavaScript | MIT/ISC | Uses js-yaml or yaml package |
| Deno | deno.land/x/yaml | ISC | Third-party module |
| Deno | @std/yaml | MIT | Official Deno standard library |
| Java | SnakeYAML | Apache 2.0 | Some files use EPL-1.0, LGPL-2.1, GPL-2, or BSD |
| Kotlin | kaml | Apache 2.0 | Kotlin-specific implementation |
| Kotlin | hoplite | Apache 2.0 | Configuration library with YAML support |
| Scala | circe-yaml | Apache 2.0 | Functional approach to YAML |
| Groovy | groovy-yaml | Apache 2.0 | Ships with Groovy |
| Clojure | clj-yaml | EPL | Eclipse Public License, weak copyleft |
| Ruby | Psych | MIT | Wraps libyaml, included in standard library |
| Go | go-yaml/yaml | MIT & Apache 2.0 | Dual license: libyaml ports use MIT, new code uses Apache 2.0 |
| Rust | serde_yaml | MIT or Apache 2.0 | Dual license, pick either |
| C# | YamlDotNet | MIT | Works across .NET languages |
| VB.NET | YamlDotNet | MIT | Same library as C# |
| F# | YamlDotNet | MIT | Same library as C# |
| PowerShell | powershell-yaml | Apache 2.0 | Wraps YamlDotNet |
| PowerShell | PSYaml | MIT | Alternative wrapper for YamlDotNet |
| Haskell | HsYAML | GPL-3.0 | Copyleft: derivative works must use GPL-3.0 |
| OCaml | ocaml-yaml | ISC | Permissive license |
| Elixir | yaml_elixir | BSD-2-Clause | Wraps Erlang's yamerl |
| Erlang | yamerl | BSD-2-Clause | Pure Erlang YAML 1.2 parser |
| Perl | YAML::XS, YAML::Syck, etc. | Artistic & GPL | Multiple modules, Perl's standard dual license |
| PHP | Symfony YAML | MIT | Part of Symfony framework |
| PHP | php-yaml | PHP License | libyaml bindings |
| Lua | lubyk/yaml | MIT | Based on libyaml |
| R | yaml | BSD-3-Clause | Wraps libyaml |
| Shell | yq (mikefarah) | MIT | Go-based YAML processor |
| Shell | yq (kislyuk) | Apache 2.0 | Python-based wrapper |
| Bash | Use yq | MIT/Apache 2.0 | Don't parse YAML with pure Bash |
| AWK | Use yq | MIT/Apache 2.0 | AWK isn't designed for YAML parsing |
| Zig | Various | Emerging | Limited libraries, mostly permissive |
| Nim | NimYAML | MIT | Native Nim implementation |
| Crystal | Standard library | Apache 2.0 | Built into language |
| D | D:YAML | Boost 1.0 | Permissive license designed for libraries |
| V | Various | Emerging | Limited libraries available |
| Odin | Various | Limited | Few YAML libraries available |
| Swift | Various | Mostly MIT | Most wrap libyaml or use permissive licenses |
| Fortran | FYAML | MIT | Modern Fortran implementation |
| Fortran | fortran-yaml | GPL | Copyleft alternative |
| Dart | yaml | MIT | Standard Dart YAML package |
| Julia | YAML.jl | MIT | Follows Julia's standard licensing |
| Tcl | tcllib | BSD-style | Part of Tcl standard library |
| Prolog | prolog-yamltiny | Various | YAML subset parser |
| Common Lisp | cl-yaml | MIT | Standard CL implementation |
| Scheme | Various | Limited | Few YAML libraries available |
| COBOL | None found | N/A | Use external tools or commercial solutions |
| Mojo | None yet | N/A | Too new, ecosystem still developing |
the pattern
Looking at the table, three patterns emerge:
MIT & Apache 2.0 dominate the ecosystem.
Over 90% of implementations use permissive licenses. These let you use the code commercially, modify it freely, include it in proprietary software, & redistribute it without restrictions.
Copyleft is the exception, not the rule.
Only three implementations use copyleft licenses: - Haskell's HsYAML (GPL-3.0) - strong copyleft - Some Fortran parsers (GPL) - strong copyleft - Clojure's clj-yaml (EPL) - weak copyleft
libyaml's MIT license propagated through the ecosystem.
Many implementations wrap libyaml or port its code. The permissive MIT license enabled this reuse without legal friction.
why it matters
YAML's permissive licensing shaped its adoption.
When you add YAML to a project, you're not inheriting restrictive obligations. No copyleft requirements. No commercial use restrictions. No patent concerns (Apache 2.0 includes explicit patent grants).
This made YAML the default choice for: - Configuration files - GitLab CI pipelines - Kubernetes manifests - Docker Compose - Ansible playbooks
The licensing enabled the ecosystem.
conclusion
Nobody owns YAML. Everybody can use it.
The YAML 1.2 spec is open. The reference implementations use MIT, Apache 2.0, & other permissive licenses. This created a self-reinforcing cycle:
- Open spec means anyone can implement
- Permissive licenses mean anyone can use implementations
- Wide adoption creates network effects
- Network effects drive more adoption
The result? YAML became ubiquitous without a single controlling entity.
When you ask "who owns YAML?" the answer is: the community. The spec is maintained collaboratively. Implementations exist across every major language. All freely available.
That's the power of open standards & permissive licensing.
important notes
All licenses are valid. We're proponents of all open source licenses - they each serve different purposes. Copyleft (GPL, EPL) ensures derivative works remain open. Permissive licenses (MIT, Apache 2.0) maximize reuse flexibility. Both approaches have merit.
Check specific files. SnakeYAML's main license is Apache 2.0, but some files use EPL-1.0, LGPL-2.1, GPL-2, or BSD for historical reasons. Review if license compatibility matters.
Shell scripting best practices. Don't parse YAML with AWK, sed, or pure Bash. Use yq instead - it understands YAML's data structures & prevents parsing bugs.
Emerging languages. Zig, V, Mojo, & Odin have limited YAML ecosystem support. Consider contributing implementations if you need YAML in these languages.
references
Research was conducted across official GitHub repositories, package registries (npm, PyPI, crates.io, etc.), & language-specific documentation.
Key sources: - https://yaml.org/ - Official YAML site - https://github.com/yaml/libyaml - Canonical C implementation - Language-specific package registries & repositories