Darknet/YOLO after the Codeberg move: what version 5.x actually changes
Darknet/YOLO object detection framework
At a glance
- What is it?
- The C/C++/CUDA object detection framework now lives on Codeberg with a GitHub mirror, and its version string tells you which generation of the codebase you are running. Here is what the README documents, where the migration and API breaks bite, and what to check before you build.
- Who is it for?
- Adopt Darknet/YOLO if you need a C and C++ inference and training framework you can link into an existing product under Apache-2.0, and if you are willing to build from source with CMake.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 16 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Darknet/YOLO solves, and who is actually building it
Darknet is a neural network framework written in C, C++, and CUDA, and YOLO is the real-time object detection system that runs inside it. That combination is the point: a detection model that can be compiled into a native binary rather than hosted behind a Python runtime. The README describes the framework as usable on Raspberry Pi, cloud and Colab servers, desktops, laptops, and training rigs for the CPU build, with GPU builds requiring either a CUDA-capable NVIDIA card or a ROCm-capable AMD card. Linux, Windows, and Mac are all listed as known to work.
The audience is narrower than the topic list suggests. If you are prototyping in a notebook, this is not the shortest path. If you are shipping a detector inside a C++ service, a robotics stack, or an embedded device where pulling in a Python interpreter is unwelcome, the framework's native build story is the reason to look at it. The README is explicit that people are generally expected to train their own network, and that pre-trained weights exist mainly so the software can be tested quickly after installation. Two weight sets are named: People-R-People with two classes, person and head, and MSCOCO with 80 classes. Treat the weights as a smoke test, not as a finished product.
The version command is the first thing to run, because the codebase changed four times
This repository has an unusually legible version history, and reading it saves debugging time. The original Darknet written by Joseph Redmon between 2013 and 2017 had no version number and is treated as 0.x. The repo maintained by Alexey Bochkovskiy from 2017 to 2021 is treated as 1.x. The Hank.ai sponsored repo maintained by Stéphane Charette starting in 2023 was the first with a version command, returning 2.x "OAK"; its last branch is version 2.1 in the v2 branch.
Development from mid-2024 shipped as 3.x "JAZZ" in October 2024. That release removed many old and unmaintained commands and modified the legacy C API. The README states plainly that applications using the original Darknet API will need minor modifications, pointing at the api.html page, and that a new C and C++ API was introduced alongside sample code in src-examples. Version 4.x "SLATE" arrived in early 2025 with AMD ROCm support and a rewrite of all printf() and std::cout calls so logging can be redirected. Version 5.x "Moonlit" followed in August 2025 with OpenBLAS for CPU-only builds, Profile-Guided Optimization, experimental ONNX export, and incomplete Java bindings. The most recent release is v5.1, released in December 2025, which extends the ONNX export tool to include nodes for both "confs" and "boxes" and rewrites the mAP function.
So the version string is not cosmetic. If a command you relied on has vanished, the README's own advice is to check out the v2 branch, and to report the missing command so it can be considered for reinstatement. That is a workable fallback, but it means two codebases in your build matrix.
Repository location: Codeberg is primary, GitHub is a mirror
The README states that in August 2025 the repo moved to Codeberg.org/CCodeRun/darknet, and that all commits are automatically mirrored from Codeberg to the older Hank.ai GitHub repo. The practical consequence is where you file and read issues. If you are tracking changes, the upstream of record is Codeberg; a pull request or issue opened against the GitHub mirror may not be where maintainers work. The project also points to a web site at ccoderun.ca/darknet, a FAQ page, and a Discord server for support.
The metadata for this GitHub repository shows a last push of 2026-08-30 and an archived flag of false, with a single listed release, v2.0 (weights), dated 2023-11-13. That release entry does not reflect the 3.x through 5.x line described in the README, because those versions are documented in the README's version history rather than as GitHub release objects. Do not read the release list as the project's current state.
Getting it built: CMake is the unified path, with Docker and Colab as shortcuts
The README's building section documents one unified CMake route for Windows, Linux, and Mac, which was introduced during the 2.x era specifically to replace the older per-platform steps. Separate subsections cover the Linux CMake method, the Windows CMake method, Google Colab, WSL, and Docker. The README does not reproduce the individual CMake invocations in the excerpt available here, so the exact configure and build commands should be taken from the corresponding section of the README or the web site rather than guessed.
What the material does establish is the dependency shape. CPU-only builds gained OpenBLAS support in 5.x, which matters if you are targeting machines without a discrete GPU. GPU builds need CUDA for NVIDIA or ROCm for AMD, and the README notes that MIOpen support still needs to be added, so the AMD path is not complete. Profile-Guided Optimization is available as of 5.x, which implies a two-pass build if you want it. The version command is the verification step once you have a binary: it returns the 5.x "Moonlit" string on current code.
For usage, the README lists a CLI section and a training section. The CLI is the interface for running detection against the pre-trained weights; training is the workflow you are expected to follow for real work. Sample applications live in src-examples, and the files.html page on the project site indexes them. If you are integrating rather than running the CLI, start from those examples rather than from the CLI, because the C and C++ API was rewritten in 3.x and the examples are the reference for the current shape.
The API break in 3.x is the real migration cost
The single most consequential line in the README for an existing user is that the legacy C API was modified in the 3.x release and applications using the original Darknet API will need minor modifications. "Minor" is doing a lot of work in that sentence, and the project does not quantify it. The replacement is a new C and C++ API documented at the api.html page, with sample code in src-examples.
If you have a wrapper layer around Darknet, the migration is bounded: you rewrite the wrapper against the new API and the rest of your code is untouched. If you have Darknet calls scattered through a codebase, the cost scales with the number of call sites, and you have no way to estimate that from the README alone. The honest position is that this is a breaking change with a documented destination and an undocumented size. Budget a spike against your own code before promising a delivery date.
The 3.x release also removed many old and unmaintained commands. The README frames this as cleanup and offers the v2 branch as the escape hatch, but the two options are not equivalent: staying on v2 means forgoing the performance work and the ROCm, OpenBLAS, and logging changes that landed in 4.x and 5.x. The project asks users to report missing commands so they can be investigated for reinstatement, which suggests the removals were not individually negotiated with downstream users.
Where it is the wrong tool, and what to use instead
Two limitations are documented rather than inferred. First, AMD GPU support is incomplete: ROCm was added in 4.x, but the README states MIOpen support still needs to be added. If your deployment target is an AMD accelerator and you need the full acceleration path, that gap is a blocker, not a detail. Second, the ONNX export tool is marked experimental in 5.x, and only in v5.1 did it gain the nodes needed to export both "confs" and "boxes". If your plan is to train in Darknet and deploy through an ONNX runtime, you are on the newest and least settled part of the project, and the export path is not something to design a production pipeline around yet.
The Java bindings are listed as incomplete and in-progress, so JVM integration is not a supported route today. The C++ compiler conversion and the unified CMake build are genuine simplifications, but they also mean the old build recipes you may find in blog posts and forks no longer apply.
For a real alternative, consider a Python-first framework such as PyTorch with a YOLO implementation. The difference in approach is not accuracy on paper; it is where the runtime lives. Darknet compiles to a native binary with a C and C++ API you link against, which is what makes Raspberry Pi and embedded deployment plausible without a Python interpreter in the image. A PyTorch-based detector gives you a much larger ecosystem of training utilities, export tooling, and pretrained checkpoints, at the cost of carrying a Python runtime and its dependency tree into deployment. If your target is a server with a Python environment already present, the native build buys you less than it costs. If your target is a device where Python is the thing you are trying to avoid, the trade goes the other way.
Licence, maintenance and the upgrade treadmill
The repository is Apache-2.0. The README states that the framework is completely free and open source, and that you can incorporate Darknet/YOLO into existing projects and products, including commercial ones, without a licence or paying a fee. That is the project's own summary, not legal advice; if you are shipping a product, have your own counsel read the Apache-2.0 text, particularly the patent grant and the notice requirements, rather than relying on a README sentence.
The maintenance picture is active but fast-moving. Four version names (OAK, JAZZ, SLATE, Moonlit) shipped between 2023 and 2025, with v5.1 in December 2025. Each generation has carried API changes, command removals, or new build requirements. The cost of staying current is not the upgrade itself so much as the re-verification: after each move you need to confirm your call sites still compile against the current C and C++ API, that any CLI commands in your scripts still exist, and that your GPU backend is still on the supported path. The v2 branch is the escape hatch if a removal breaks you, but it is a frozen branch and not a long-term home.
One thing to verify before adopting: the README's performance claims. It states that Darknet V3 "Jazz" can run the LEGO dataset videos at up to 1000 FPS on an NVIDIA RTX 3090, with each frame read, resized, and processed in 1 millisecond or less, and that further improvements landed in V4 and V5. Those are the project's numbers on the project's dataset. Nothing here was independently measured, and the README also asserts that the framework is faster and more accurate than other frameworks and versions of YOLO without giving the comparison. Reproduce the benchmark on your own hardware and your own image sizes before you let those figures inform a capacity plan.
Editorial conclusion
Adopt Darknet/YOLO if you need a C and C++ inference and training framework you can link into an existing product under Apache-2.0, and if you are willing to build from source with CMake. Do not adopt it if you need a stable C API across upgrades, or if you depend on commands that were removed in the 3.x "JAZZ" release; the README says applications using the original API need minor modifications, so check your call sites against the api.html page before you commit to the move. Verify your platform first: CUDA or ROCm for GPU builds, and note that MIOpen support for AMD is still listed as missing.
Community notes