OpenNN 26 moved from LGPL to AGPL with a linking exception, and that is a licence change to plan for

What the library does, and the table that tells you where to start

OpenNN is a C++20 library for building, training and running neural networks. It supports tabular data, images, time series and text, with CPU and optional CUDA execution. Models can be embedded in C++ applications or exported as standalone source code for supported architectures.

That export capability is the one that distinguishes it from most libraries of its kind, and it is worth understanding what it means. A trained OpenNN model can be written out as C or Python source code, so a deployment does not need the OpenNN runtime at all. The quick start points at the Iris example for exactly that workflow, training a classifier, evaluating it and exporting predictions as C or Python code.

The README opens with a routing table, and the table is a good sign about how the project is organised. Each row is a task and each points at a specific document.

| I want to | Start here | | --- | --- | | Build and run my first network | Quick start | | Choose CPU/CUDA backends and build options | Build options in AGENTS.md | | Use OpenNN in my C++ application | Install and link | | Train, evaluate or export a model | Examples README | | Update an 8.x application or model | Migration in AGENTS.md | | Understand the source folders | Repository contents | | Run or review performance comparisons | Benchmarks README | | Use OpenNN under the AGPL or a commercial licence | License |

The row about updating an 8.x application points at a migration guide, which tells you the project treats the version jump as something users will actually have to do.

The primary language is C++, the homepage is opennn.net with tutorials there, the last push to the repository was on 2026-10-15, and the repository is not archived.

The build needs a modern compiler and separates CPU from CUDA directories

The quick start is specific about the toolchain, and the requirements are higher than they used to be.

You need Git, CMake 3.24 or newer, and a C++20 compiler with `std::format` and OpenMP: GCC 13 or newer, Clang 17 or newer, or Visual Studio 2022 C++ tools. On macOS you install the OpenMP runtime, `libomp`. And CMake retrieves missing dependencies during the first configuration, so that step needs internet access.

The configure line carries three build options.

git clone https://github.com/Artelnics/opennn.git
cd opennn
cmake -S . -B ../opennn-build -DCMAKE_BUILD_TYPE=Release -DOpenNN_DISABLE_CUDA=ON -DOpenNN_BUILD_TESTS=OFF -DOpenNN_BUILD_EXAMPLES=ON
cmake --build ../opennn-build --config Release --target blank --parallel

Building a single target, `blank`, is the fastest way to verify the toolchain, and `blank` is the example the quick start then runs. On Linux and macOS you run `../opennn-build/bin/blank`, and with Visual Studio on Windows it is `../opennn-build/bin/Release/blank.exe`.

The CUDA path is deliberately kept in a different build directory so the two configurations do not overwrite each other.

cmake -S . -B ../opennn-build/cuda -DCMAKE_BUILD_TYPE=Release -DOpenNN_REQUIRE_CUDA=ON -DOpenNN_BUILD_TESTS=OFF -DOpenNN_BUILD_EXAMPLES=OFF
cmake --build ../opennn-build/cuda --config Release --target opennn --parallel

The option names are worth noting as a pair. `OpenNN_DISABLE_CUDA=ON` turns CUDA off, and `OpenNN_REQUIRE_CUDA=ON` requires it, which the README describes as a way to make missing GPU build dependencies an error rather than a silent fallback. That is the difference between a build that quietly produces a CPU-only library on a machine you meant to be GPU-accelerated, and one that tells you the toolkit is missing. The CUDA build also needs a C++20 compatible CUDA toolkit and cuDNN 9 or newer.

The `--parallel` flag on the build and the separate build directories are the two practical points, and together they make a CPU and a CUDA build of the same tree coexist, which is what you need while iterating on both.

Installing the package means importing a CMake target, and what gets installed is deliberate

Using OpenNN in an application goes through a proper CMake package, and the install prefix has been thought about.

You install a completed build to a separate prefix.

cmake --install ../opennn-build --config Release --prefix ../opennn-install

And then consume the installed target.

cmake_minimum_required(VERSION 3.24)
project(MyApplication LANGUAGES CXX)
find_package(OpenNN 26.0 CONFIG REQUIRED)
add_executable(my_application main.cpp)
target_link_libraries(my_application PRIVATE OpenNN::opennn)
target_compile_features(my_application PRIVATE cxx_std_20)

Two details in that snippet matter. The `find_package` call requires version 26.0, which is how a consumer pins to the new major line rather than accidentally picking up an older installed copy. And the exported target supplies OpenNN's include paths and dependency linkage, and the package still works after moving the install prefix, which is a property that matters in a CI environment where the prefix changes between runs.

The `tools/package_smoke/` directory is a complete working example of a package consumer, which is the right way to make sure the packaging is tested rather than assumed.

The list of what does and does not get installed is the part to know before you plan a deployment. Fetched Eigen and zlib are installed with the library. OpenMP, oneTBB, oneDNN, MKL and the NVIDIA runtimes are not copied into the installation, so you supply those selected by the build. And you are told to use a compiler compatible with the one that built the package.

That last point is a real constraint for C++ libraries with heavy template use, and stating it plainly is better than discovering an ABI mismatch later. The installation packages also exclude example datasets and models, which keeps the installed footprint to the library itself.

On the include side, the guidance is to include the public module headers directly, for example `#include "opennn/network/network.h"`, and explicitly not to include the private precompiled header `opennn/core/pch.h` in an application. That is the usual rule for a library with a precompiled header, and it prevents a consumer from depending on an internal detail that changes between versions.

A large example set, and a benchmarks folder with its own protocol

The examples directory is extensive and the names tell you the range of problems the library is used on.

There is `blank/`, which is the toolchain check, and `iris_plant/`, which is the tutorial. Then the classification and regression sets: `breast_cancer/`, `mnist/`, `melanoma_cancer/`, `concrete/`, `yacht_hydrodynamics/` and `amazon_reviews/`. Then the time series and signal ones: `airfoil_self_noise/` and `electrocardiogram_anomaly_detection/`. Then the language and architecture sets: `bert/`, `gpt2/`, `qwen3/` and `translation/`, plus `emotion_analysis/`. And then `yolo/`, which is a detection model rather than a classifier.

The presence of transformer examples alongside a YOLO one is the interesting signal. A library that supports BERT, GPT-2 and Qwen3 is doing more than feedforward networks on tabular data, and the `examples/prepare_data.cmake` file suggests the datasets are prepared as part of the build rather than assumed to be present.

The benchmarks directory is the part most libraries get wrong, and this one has a `PROTOCOL.md` with measurement rules attached to it, and the README describes the contents as OpenNN versus PyTorch comparisons. A protocol file means someone wrote down what the measurement is allowed to do, which is the difference between a benchmark and a set of numbers.

The repository layout follows the same discipline. There is `opennn/` for the library itself with its public headers, implementations, models and CPU and CUDA backends, and an `AGENTS.md` with a module map and dependency listing. There is `tests/` for the C++ unit tests, `tools/` for verification scripts, code checkers, fuzzing, package checks and agent skills, and `.github/workflows/` for continuous integration. A `CMakePresets.json` at the root means the common build configurations are named rather than typed each time, which is what makes a repository with this many build options navigable.

The contribution process is described with the same specificity. Base contributions on `dev`, include the validation you ran, and describe the resulting behavior in the pull request. A pull request can be merged only after its author has accepted the Contributor License Agreement, and `AGENTS.md` holds the engineering rules, verification commands and release procedure. For a bug report they ask for the OpenNN commit, operating system, compiler, CPU or CUDA configuration, reproduction command and error, which is a well-specified bug report template.

The licence change is the decision that needs a lawyer, not a README

The licence section is the most consequential part of the README, and it is worth reading closely.

OpenNN is copyright 2026 Artificial Intelligence Techniques, S.L., which is Artelnics, and Roberto López González, and it is dual licensed. The open source option is the GNU Affero General Public License, version 3 only, with additional permissions for linking with NVIDIA CUDA, cuDNN and Intel oneMKL and for the code and model files that OpenNN generates. The commercial option is a licence from Artelnics for closed source products and hosted services that cannot meet the AGPL's terms.

The AGPL is the licence to pay attention to. It reaches networked use, so a hosted service built on OpenNN is in scope in a way that the previous licence was not.

And the previous licence matters here. OpenNN 8.x and earlier, and the development snapshots published before this change, were distributed under the GNU Lesser General Public License, version 2.1 or later, and copies of them keep those terms. So the project moved from LGPL to AGPL, and the migration is not retroactive.

That is a real change for anyone with OpenNN in a product, and it is the kind of change that gets a deployment on the list of things to check. The additional permissions for linking with CUDA, cuDNN and oneMKL exist because a GPL or AGPL library otherwise complicates linking against proprietary or separately licensed runtime components, and the permission for the generated code and model files exists because you should not have to license the output of a training run back to Artelnics.

Two more notices complete the picture. Dependencies and downloadable pre-trained weights keep their own terms, listed in `THIRD_PARTY_NOTICES.txt`. And example data keeps its publishers' terms, recorded in the `SOURCE.md` notice of each data folder, which is the kind of detail that matters if you train on the bundled datasets and ship the result.

`LICENSING.md` is the document with the details, and the README points at it rather than trying to compress the terms into a paragraph, which is the right call.

Editorial conclusion

Adopt OpenNN if you are writing C++ and need a neural network library that ships trained models as portable source code rather than as a runtime dependency. Do not adopt it in a closed source product or a hosted service without reading LICENSING.md, because the open source option is the AGPL version 3 only, with additional permissions for linking against NVIDIA CUDA, cuDNN and Intel oneMKL and for the code and model files OpenNN generates, and a commercial licence from Artelnics is the alternative. Verify first that your compiler meets the C++20 with std::format and OpenMP requirement, that the model export format you need is one of the supported architectures, and that the licence route you take covers the way you distribute or serve the result.

Frequently asked questions

Official sources

1. Artelnics/opennn on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases