CoolProp gives you thermodynamic properties without a REFPROP licence, and its CMake package is stricter than you expect

A free stand-in for REFPROP, and the licence difference is the whole pitch

CoolProp is a thermophysical property database with wrappers for a selection of programming environments. The README states the proposition plainly: it offers similar functionality to REFPROP, but CoolProp is open source and free.

The licensing is unusually clear for this kind of software. The README lists the terms as Commercial ok and Academic ok, and the project metadata declares MIT. That matters more than it might appear. A thermophysical property database is exactly the kind of component that carries commercial restrictions or per-seat terms in a commercial product, and an MIT grant lets a company ship it inside a closed source tool without a legal review of the property data itself.

The project was originally developed by Ian Bell, at the time a post-doc at the University of Liege in Belgium, and it is now maintained as a public project with a discussion board, an issue tracker and a FAQ file at the repository root.

The honest framing is that CoolProp is a comparable tool with a different licensing and a different fluid coverage, not a clone of everything REFPROP does. The README does not enumerate a fluid list, so the practical question of whether the substance and state range you need is covered is one you answer by trying it, not by reading the front page.

One install path for Python, another for the native libraries

There are two distinct ways to get CoolProp, and they serve different users.

For Python, the README points at PyPI.

pip install coolprop

For native builds, binaries are available from SourceForge, and there is also a bleeding edge nightly build of the development version hosted there. The nightly is worth knowing about if you need a fluid or a backend that has not reached a release, and it is worth avoiding if you need reproducible behaviour, because a nightly build changes under you without a version number telling you what changed.

The project classifies itself as Development Status 5, Production/Stable, and the recent release tags are consistent with a stable library: v8.0.0 was published on 2026-06-28 with a matching GUI release the same day, and the last push to the repository was on 2026-10-15.

The packaging metadata is unusually thorough, which tells you the project is used in real pipelines. The Python build requires Python 3.9 or newer and the classifiers list 3.9 through 3.14, and one classifier is for WebAssembly via Emscripten, which means the library can be compiled to run in a browser as a WebAssembly module. The build system uses scikit-build-core, with Cython and nanobind in the build requirements.

The pin on nanobind is a detail with a story. The build file explains that nanobind is pinned to match the stub drift gate, because an isolated build resolving a newer nanobind could produce bindings that drift from the validated stubs. That is the kind of care a library takes when its users run it in CI.

Static and shared libraries installed together, linked never together

The CMake section is where this project is more rigorous than most, and it is worth reading twice before you wire it into a build.

CoolProp can build and install static and shared libraries independently or in the same build.

cmake -S . -B build \
  -DCOOLPROP_STATIC_LIBRARY=ON \
  -DCOOLPROP_SHARED_LIBRARY=ON
cmake --build build --config Release
cmake --install build --config Release --prefix /path/to/prefix

The consumption side uses imported targets, so you do not add include directories or platform libraries by hand.

find_package(CoolProp 8 CONFIG REQUIRED)
target_link_libraries(my_app PRIVATE CoolProp::CoolProp)

Now the constraint. When both variants are configured, the producer side `COOLPROP_DEFAULT_LIBRARY` cache setting decides which variant the `CoolProp::CoolProp` target exports, shared by default, and that choice is recorded in the installed package where a consumer cannot change it. Consumers that need an explicit choice link `CoolProp::Static` or `CoolProp::Shared` directly. Separate consumer targets may pick different variants, but one final binary must not link both.

That last rule is a correctness requirement, not a style preference, since two copies of the same library in one process means two copies of its state and two copies of its tables. The build system prevents it because the failure mode is subtle. On Windows the shared library interface is the C API from `CoolProp/CoolPropLib.h`, while the complete C++ API is only available through the static target, which is a platform constraint you will hit if you try to share the library across a DLL boundary on Windows.

Vendoring Eigen and fmt, or supplying them yourself

The third party dependencies are handled in a way that suits distributors. By default `COOLPROP_VENDOR_THIRD_PARTY=ON` bundles the pinned Eigen and fmt headers and their licences into the relocatable package.

The subtlety is that those sources are fetched even when `CPM_USE_LOCAL_PACKAGES=ON`, because an installed package might not supply the source files needed for vendoring. Explicit `CPM_Eigen_SOURCE` and `CPM_fmt_SOURCE` overrides still work, but they have to point at complete source trees that include the upstream licence files.

For a distributor who wants to avoid shipping vendored copies, `COOLPROP_VENDOR_THIRD_PARTY=OFF` switches to installed `Eigen3` and `fmt` CMake packages, with Eigen 3.4 or newer required. The obligation then moves downstream, since consumers of the package have to provide those packages themselves. The option concerns Eigen and fmt only, not the other build dependencies.

Two path conventions are settled as well. `CMAKE_INSTALL_PREFIX` or `cmake --install --prefix` chooses the install location, and the legacy `COOLPROP_INSTALL_PREFIX` override must not be empty and is ignored in nested builds, which keep their parent's prefix.

For a source tree consumer, the canonical target is available too.

set(COOLPROP_STATIC_LIBRARY ON CACHE BOOL "" FORCE)
add_subdirectory(externals/CoolProp)
target_link_libraries(my_app PRIVATE CoolProp::CoolProp)

Nested builds add no CoolProp install rules by default. A parent project that wants to package CoolProp can turn on `COOLPROP_INSTALL_CMAKE_PACKAGE` and `COOLPROP_INSTALL_LEGACY_LAYOUT` before the `add_subdirectory` call, which keeps an unwanted install step out of a vendored dependency.

Where the source lives, and what the repository layout shows

The repository is large and structured like a serious scientific library rather than a hobby project. The top level contains `include/` and `src/` for the C++ core, `wrappers/` for the language bindings, `externals/` for the vendored third party sources, `cmake/` for the build logic, and a top level `CMakeLists.txt`.

Alongside those sit the files that tell you how the project is operated. `FAQ.md` is the user FAQ the README points to, `THIRD_PARTY_NOTICES.md` records the third party obligations that come with the vendored Eigen and fmt, `CITATION.bib` and `CoolPropBibTeXLibrary.bib` exist so that published work can cite the software, and `TTD.txt` is present in the root. There is a `Web/` directory, a `doc/` directory, a `docs/` directory and a `dev/` directory.

The tooling is visible too. `.clang-format`, `.clang-tidy`, `.cmake-format.yaml` and `.editorconfig` cover formatting across C++, CMake and general files, `.pre-commit-config.yaml` runs the checks before a commit, and `.semgrep/` holds static analysis rules. `AGENTS.md` and `CLAUDE.md` sit at the root, which tells you the project has been developed with AI coding assistants in the loop and has written down rules for them.

A `.beads/` directory and a `.coderabbit.yaml` point to an automated code review workflow. For a project that computes physical properties, the interesting detail is that all of this is about correctness discipline: formatting, linting, static analysis and review bots are the tools that keep a large numerical codebase from drifting.

Nightly builds, a stable release line and a cost of upgrading

The release history is a good indicator of the project's shape. The most recent tags are gui-v8.0.0 and v8.0.0, both dated 2026-06-28, and before that gui-v7.2.1-alpha.2 from 2026-04-28. The GUI carries its own version line, which tells you the graphical interface moves independently of the property library, and the alpha suffix in the GUI tags shows pre-releases are part of the normal process.

For a user, the practical decision is which of three sources to pin. The PyPI release and the SourceForge binaries are the stable choice, the nightly is for development, and the sources on the repository are for building it yourself. A simulation pipeline that has to reproduce results months later needs a pinned version, and the CITATION files suggest the project expects to be cited in published work, which is a good reason to record the exact version you used.

The upgrade cost for a C++ consumer is the one to think about. The CMake package requires `find_package(CoolProp 8 CONFIG REQUIRED)`, so a major version bump is a visible change in your build files rather than a silent one, which is good design. The behaviour risk is the other side of it: a property backend is a numerical model, and a release that adds a fluid or refines a correlation changes the numbers your model produces, with no compile error to tell you.

The licensing position is settled for the code. The property data itself carries the obligation to check the accuracy of any specific fluid and state range you depend on, and the project does not position itself as a certified reference implementation.

Editorial conclusion

Adopt CoolProp if you need property data for a fluid in your own code, you want an MIT licence that is free of commercial restrictions, and you can accept that the fluid list is limited to what the project supports rather than everything a paid reference covers. Do not adopt it as a drop-in replacement for a licensed reference implementation in a regulated design workflow without checking the accuracy of the specific fluid and property you need. Verify first that the fluid you care about is in the database, that your call stays inside the valid state range where the backend is trusted, and that the wrapper you pick matches the language and the deployment constraints of your application.

Frequently asked questions

Official sources

1. CoolProp/CoolProp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases