LibrePCB: an EDA suite with its own library model

What LibrePCB solves, and for whom

LibrePCB is an EDA suite for developing printed circuit boards, and the README lists Windows, Linux and macOS as supported platforms. The stated purpose is narrow: draw a schematic, lay out a board, produce the files a fab house needs. It is not an electronics simulator, and nothing in the repository description claims otherwise.

The audience is the engineer who wants a GPL-3.0 toolchain and is willing to accept a specific opinion about how parts should be organised. LibrePCB's central design decision is that a schematic symbol, a board footprint and the device that binds them are separate artefacts. In practice that means a component in your schematic is not a single file you edit; it is a device that references a symbol and one or more footprints, and the library system enforces that relationship. Teams that have been burned by a symbol whose pin numbering silently disagreed with its footprint tend to like this. People who want to drop in a downloaded library and start routing immediately tend to find it tedious.

The project's own framing is broad ("for everyone"), but the honest scope is narrower: it fits someone designing a board from scratch who is willing to build or curate libraries properly. The README points new users at the quickstart tutorial rather than describing the workflow itself, which is a fair signal that the learning curve is real and documented elsewhere.

The library model is the architecture

The repository layout reflects the separation. There is an apps/ directory for the applications, a libs/ directory for shared code, a share/ directory for data that ships with the program, and a tests/ directory alongside them. The library concepts live in the shared code and in the shipped data, not inside the schematic editor, which is why the same device can be placed on a schematic and on a board without either side owning the definition.

That structure has a cost that the README does not discuss. A device with several footprint variants, say a part available in both a small and a large package, is one device entry with multiple footprint references, and the board decides which one is used. Managing that across a project means understanding the library editor before the schematic editor is useful. The README gives no guidance on migrating an existing library from another tool, and no import path is documented there.

The build system mirrors the same split. CMakeLists.txt at the top level drives the build, cmake/ holds the modules it pulls in, and libs/ is compiled before the applications that depend on it. If you plan to patch behaviour rather than just use it, the boundary between libs/ and apps/ is where you will spend your time.

Installing LibrePCB: download page or build from source

The README is explicit that official stable releases are provided on the download page at librepcb.org/download, and that the user manual covers installation and use. It does not give a package manager command for end users, so there is no apt or brew line to quote for installing the application itself. If you want a working editor, start at that download page.

Building from source is documented in more detail, and the requirements are specific. You need a C++20 compiler (g++, MinGW or Clang), a Rust toolchain of at least 1.92 in its GNU variant rather than MSVC, Qt 6.2 or newer with the imageformats plugin installed, OpenSSL, and CMake 3.22 or newer. OpenCASCADE and GLU are optional. On Debian or Ubuntu the README gives a package list for Ubuntu 22.04 and newer:

sudo apt-get install build-essential rustup git cmake openssl \
     qt6-base-dev qt6-tools-dev qt6-tools-dev-tools qt6-l10n-tools \
     libqt6opengl6-dev libqt6svg6-dev qt6-image-formats-plugins \
     libglu1-mesa-dev libtbb-dev libxi-dev occt-misc libocct-*-dev
rustup install stable

On Arch the equivalent is a single pacman line, and on macOS the README uses Homebrew with `brew install qt6 cmake opencascade rust` followed by `brew unlink qt && brew link --force qt6`. Windows is the awkward case: LibrePCB does not compile with MSVC, so you install the Qt for Windows installer and select the MinGW 11.2.0 64-bit compiler, the matching Qt 6.x binaries, Qt Image Formats, and CMake, then add Rust with the `x86_64-pc-windows-gnu` toolchain. OpenCASCADE on Windows has to be built by hand unless you set the CMake option `USE_OPENCASCADE=0`.

The clone step matters because of submodules, and the README warns about it:

git clone --recursive https://github.com/LibrePCB/LibrePCB.git && cd LibrePCB

Then the build itself is three commands, and the README says the binary ends up in `build/apps/librepcb/`:

mkdir build && cd build
cmake ..
make -j8

When you pull updates later, the README states you must refresh submodules recursively or you may get strange compilation errors:

git submodule update --init --recursive

There is also a prepared Docker image at `librepcb/librepcb-dev` with dependencies pre-installed except GUI tools. The README notes these images are used for CI but are useful for local builds, which is the closest thing to a reproducible environment the project offers.

Where LibrePCB is the wrong tool

The clearest limitation is stated by the project itself, in bold: the master branch always contains the latest unstable version, and everything done with it could break your workspace, libraries or projects. The README tells you not to use it productively. If you want a fix that only exists on master, you are choosing between an unstable build and waiting for a release.

The second limitation is the toolchain. LibrePCB does not compile with MSVC, and the Windows path requires a specific MinGW 11.2.0 64-bit setup plus a GNU Rust toolchain. Anyone whose build infrastructure is standardised on Visual Studio will be building a parallel environment for this project alone. The same applies to Qt: 6.2 or newer with the imageformats plugin, which the README flags as needed at runtime, not just at build time.

The third is scope. There is no mention of SPICE simulation, no mention of an import path from other EDA formats, and no API documentation in the README beyond a link to the developers documentation. If your process depends on simulating before you route, or on round-tripping a design from another tool, LibrePCB is not the instrument for that job. The README does not document rollback of a library change either, which matters given how central libraries are to the design.

LibrePCB versus KiCad: two different bets

The comparison people actually search for is LibrePCB versus KiCad, and the difference is not feature count. It is where each tool puts its complexity.

KiCad's model is closer to the traditional EDA arrangement, where schematic symbols and PCB footprints are separate library types that you pair up as you go. LibrePCB's model makes the pairing explicit in a device, so the relationship is declared once rather than reconstructed per project. That is the trade: more work up front when you create a part, less chance of a mismatch later. Neither approach is free, and the README does not argue the case for either.

The second difference is the build and distribution story. LibrePCB ships official binaries through its download page and is packaged across distributions, as the packaging badge in the README indicates, but the project does not present a package-manager-first install for end users the way many desktop applications do. Building it yourself is a documented path with a specific dependency list, not an afterthought.

A third difference worth naming: LibrePCB's own documentation is split between a user manual and a separate developers documentation site, and the README links to both rather than merging them. That split is a reasonable sign that the project expects contributors, but it means a user looking for library internals has to leave the user manual.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-09-23. The most recent release listed is 2.1.1 from 2026-06-12, with 2.1.0 on 2026-05-19 and 2.0.1 on 2026-02-22. That cadence is enough to say releases happen, and the gap between the last release and the last push is a few months, which is normal for a project that keeps development on master between releases.

Upgrade cost depends on which track you are on. If you install official releases from the download page, upgrading is replacing the application. If you build from source, every upgrade includes `git submodule update --init --recursive` before rebuilding, and the README warns that skipping it produces compilation errors. If you run master, you have accepted the README's warning that your workspace, libraries and projects can break.

On licensing: LibrePCB is published under GPL-3.0, and the repository carries a LICENSE.txt plus a LICENSES/ directory and a .reuse/ directory, which is the structure the REUSE tooling expects. For most users of a desktop EDA tool the practical effect is that you can use it freely and redistribute it under the same terms. What that means for a design you produce, or for distributing a modified build inside a company, is a question for your own legal review; the README does not address it.

Editorial conclusion

Adopt LibrePCB if you want a GPL-3.0 EDA suite whose library model forces symbols, footprints and devices to stay separate, and you are willing to learn that model before your first board. Do not adopt it if you need to reuse an existing KiCad library unchanged, if you expect simulation inside the schematic editor, or if you want a prebuilt binary from a package name you already know. Verify first that the download page has a package for your platform, that your Qt version is at least 6.2 with the imageformats plugin, and that your workflow does not depend on a feature only the master branch carries, because the README states that branch is unstable and should not be used productively.

Frequently asked questions

Official sources

1. LibrePCB/LibrePCB on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases