# code.mil: the open source home of a government code portal > code.mil is the repository behind the public Code.mil website, and it doubles as a worked example of a hard licensing problem: code written by United States federal employees often carries no copyright, so attaching an open source licence to it is not straightforward. The repository also holds the written policy on opening defence code and on accepting outside contributions. **Code-dot-mil/code.mil** — An experiment in open source at the Department of Defense. - Repository: https://github.com/Code-dot-mil/code.mil - Website: https://www.code.mil - Stars: 1,325 · Forks: 148 - Language: JavaScript - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/code-dot-mil-code-mil ## A website that explains why releasing government code is hard The repository is the open source home for the public-facing Code.mil website, and the README describes the project as an experiment in open source at the department. The site's purpose, in the project's own framing, is to explain what the department is doing in open source and how to take part. The distinctive part is the reason the site exists at all. The README states that code written by United States federal government employees typically has no copyright protection under United States and some international laws, and that this can make it hard to attach an open source licence to the code. That is the problem the documentation on the site is written to solve, and it is a licensing problem that no private company faces in the same form. The rest of the framing is institutional rather than technical. The department describes a portfolio spanning communications, logistics, education, healthcare and the GPS system itself, and asks for help through issues and pull requests on projects tagged with the code-mil topic, with contribution guidelines published per project. The site is maintained by the department's Chief Information Officer office, and the README points to a contact address for questions about Code.mil itself. ## Two documents carry the real content The most useful links in the README are to two pages, and they are the reason the repository is worth reading. The first is documentation on implementing open source within the department, and the second is a guideline for accepting contributions to department open source projects, with the contributions section of that page linked directly as step four of the process. The stated purpose of both is given in the same sentence: so the department can participate in the open source and free software communities even where it may not have copyright. That phrase is doing the heavy lifting. Without copyright, the usual mechanics of an open source licence do not apply cleanly, so a process document is the only place where the question can be answered. The site also asks for feedback on the strategy itself. The README says the philosophy is continuous iteration, and it invites issues or pull requests with suggestions on how to continue improving, on the repository that hosts the site itself. The document that describes how to accept contributions is therefore open to the same contribution flow it describes, which is a self-consistent way to run a policy site. ## A Jekyll site with a Gemfile and a pinned Ruby The build system is visible in the top-level listing. The build badge points at a GitHub Actions workflow file for jekyll, and the repository holds a Gemfile, a Gemfile.lock, a .ruby-version file and a _config.yml, which is the standard layout of a Jekyll site with its dependencies pinned in two places, a lockfile for gems and a version file for the interpreter. A .gitmodules file is present as well, so part of the site comes from another repository as a submodule. The content lives in src/, which is unusual for Jekyll, where the convention is a top-level _posts or _layouts directory, and the configuration in _config.yml would point the build at it. The scripts/ directory holds the automation around the site, and the .editorconfig and .gitignore entries are the ordinary marks of a repository that expects outside pull requests. The presence of .github/ at the root confirms the workflow runs on GitHub Actions rather than on a self-hosted runner. For anyone rebuilding the site, the practical sequence is the one the workflow encodes: install the Ruby version named in .ruby-version, install the gems from the Gemfile, and let the Jekyll build read _config.yml. The README does not document a local build beyond the badge, so the workflow file is the specification. ## AI4SDLC gets its own documentation build Two entries in the top-level listing point at a second, separate documentation effort. There is an AI4SDLC directory and an ai4sdlc-mkdocs.yml configuration file. The mkdocs suffix indicates a second documentation toolchain alongside Jekyll, which in practice means the repository carries two site builds: the Jekyll site for Code.mil itself and a MkDocs project for the AI4SDLC material, each with its own configuration file at the root. That is a reasonable structure for a repository that hosts more than one body of documentation, and it also means a contributor has to know which build they are changing before they open a pull request. The presence of an INTENT.md, a CONTRIBUTING.md and a CONTRIBUTORS.md is worth noting too, since it is a fuller set of governance files than most sites carry, which matches the site's purpose of modelling how to run an open source process rather than just running one. The README does not describe what AI4SDLC covers, so treat the directory as an area to explore rather than something to summarise from this repository alone. ## MIT on the site code, and a licence problem the site cannot solve by itself The project is licensed MIT, with LICENSE.md at the repository root. That licence covers the code and content of this website repository, which is the ordinary case for a public agency publishing its own site under a standard open source licence. The distinction the README keeps drawing is between the site's own code and the code of the projects it points at. Federal employee work may lack copyright protection, and the department says this can make it hard to attach an open source licence to that code. The site's contribution guideline is the mechanism for handling it: a document that states how outside contributions are accepted, so that a contribution carrying a contributor's own copyright can be handled under terms the department can honour. The MIT licence on this repository does not, and cannot, resolve the question for every project the site links to. For a developer reading the repository with an eye to reuse, the practical advice is to treat LICENSE.md as covering the website code only, and to look at the licence of each individual project before taking anything from it. This is a reading of file boundaries, not legal advice. ## A 2018 release tag and a 2026 commit history The repository is not archived, and the last push was on 2026-08-14, so work on the site is happening now. The release tags tell a different story. The list shows v1.2.1, described as Travis and inventory updates, dated 2018-06-19, v1.2.0 for the press section and inventory updates from June 2018, and v1.1.6 for gem and inventory updates from May 2018. The tag names are content-oriented, which tells you the releases track changes to the site's data as much as its code. So the site itself moves without versioned releases, and the last several years of change are visible only in the commit history. That is a sensible choice for a site whose content is a policy position rather than a versioned artefact, and it also means there is no tag to point a downstream fork at if you want a stable snapshot of the wording of the policy documents. The .ruby-version and Gemfile.lock files are the parts that do need care when updating, since a site that runs on a Jekyll build in CI will break on a gem bump without anyone noticing until the workflow goes red. ## Where code.mil is the wrong repository The first wrong-tool case is a developer looking for a web starter. The site is a specific government portal with its own content, its own navigation and its own maintenance process. Nothing here is packaged as a reusable theme, a generator or a plugin, and the Jekyll configuration is written for one site with one set of pages. The second is a team that wants a contribution intake system rather than a contribution policy. The site describes a process in prose, and there is no code in the repository that implements an intake workflow. A team that wants to receive pull requests from strangers on a public repository can borrow the wording and the checklist, but the tooling side of that problem is not addressed here. The third case is expecting a reference implementation of government open source policy. The two documents are written for one organisation with one set of legal circumstances, including the copyright situation of that organisation's own employees. A company or a non-US public body can read the structure of the argument, and the department itself asks for suggestions on how to continue improving it, but the policy as written does not transfer without legal review of the jurisdiction it applies to. ## Conclusion Adopt code.mil as a reference if you are writing a public-sector open source policy or a contribution intake process, since the two documents it publishes, on implementing open source inside the department and on accepting contributions, are the substance of the repository. Do not adopt it as a software component, a web template or a starter kit, because the code here is a specific government site with its own content and structure, not a general-purpose site generator. Before you reuse anything, read LICENSE.md and INTENT.md, and remember that the last push was on 2026-08-14 while the newest tagged release, v1.2.1, dates from 2018, so the site content moves faster than the tags do. ## FAQ ### What is the code.mil repository? It is the open source home of the public-facing Code.mil website, described in the README as an experiment in open source at the department. It hosts the site itself and the documentation on how the department opens source code and accepts outside contributions. ### Why is it hard for US federal code to carry an open source licence? The README states that code written by United States federal government employees typically does not have copyright protections under United States and some international laws, which can make it hard to attach an open source licence to that code. The contribution guideline on the site is the process written to handle it. ### How is the code.mil website built? The top-level files show a Jekyll setup with a Gemfile, a Gemfile.lock, a .ruby-version file and a _config.yml, built by a GitHub Actions workflow named jekyll.yml. Content lives in a src/ directory, with scripts/ holding the supporting automation and .gitmodules indicating a submodule. ### How do I contribute to a code.mil project? Find a project through the code-mil topic on GitHub, read its contributor guidelines, and submit an issue or a pull request. The site publishes a guideline for accepting contributions to department open source projects, and a contact address for questions about Code.mil itself is given in the README. ### What licence applies to the code.mil repository? MIT, with LICENSE.md at the repository root. The most recent listed release is v1.2.1 from 2018, while the last push was on 2026-08-14, so the site content changes without new tags. ## Sources - [Code-dot-mil/code.mil on GitHub](https://github.com/Code-dot-mil/code.mil) - [License: MIT](https://github.com/Code-dot-mil/code.mil/blob/master/LICENSE) - [Project website](https://www.code.mil) - [README](https://github.com/Code-dot-mil/code.mil/blob/master/README.md) - [Releases](https://github.com/Code-dot-mil/code.mil/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/code-dot-mil-code-mil