Skip to main content

Third-Party Libraries Used

The list of third-party libraries:

Library nameLicense type
abseil-cppApache
AMQP-CPPApache
arrowApache
avroApache
awsApache
aws-c-commonApache
aws-c-event-streamApache
aws-checksumsApache
base64BSD 2-clause
boostBoost
boringsslBSD
brotliMIT
capnprotoMIT
cassandraApache
cctzApache
cityhash102MIT
cppkafkaBSD 2-clause
croaringApache
curlApache
cyrus-saslBSD 2-clause
double-conversionBSD 3-clause
dragonboxApache
fast_floatApache
fastopsMIT
flatbuffersApache
fmtlibUnknown
gcemApache
googletestBSD 3-clause
grpcApache
h3Apache
hyperscanBoost
icuPublic Domain
icudataPublic Domain
jemallocBSD 2-clause
krb5MIT
libc-headersLGPL
libcpuidBSD 2-clause
libcxxApache
libcxxabiApache
libdividezLib
libfarmhashMIT
libgsaslLGPL
libhdfs3Apache
libmetrohashApache
libpqUnknown
libpqxxBSD 3-clause
librdkafkaMIT
libunwindApache
libuvBSD
llvmApache
lz4BSD
mariadb-connector-cLGPL
miniselectBoost
msgpack-cBoost
murmurhashPublic Domain
NuRaftApache
openldapUnknown
orcApache
pocoBoost
protobufBSD 3-clause
rapidjsonMIT
re2BSD 3-clause
replxxBSD 3-clause
rocksdbBSD 3-clause
s2geometryApache
sentry-nativeMIT
simdjsonApache
snappyPublic Domain
sparsehash-c11BSD 3-clause
statsApache
thriftApache
unixodbcLGPL
xzPublic Domain
zlib-ngzLib
zstdBSD

The list of third-party libraries can be obtained by the following query:

SELECT library_name, license_type, license_path FROM system.licenses ORDER BY library_name COLLATE 'en';

Example

Adding new third-party libraries and maintaining patches in third-party libraries

  1. Each third-party libary must reside in a dedicated directory under the contrib/ directory of the ClickHouse repository. Avoid dumps/copies of external code, instead use Git's submodule feature to pull third-party code from an external upstream repository.
  2. Submodules are listed in .gitmodule. If the external library can be used as-is, you may reference the upstream repository directly. Otherwise, i.e. the external libary requires patching/customization, create a fork of the official repository in the Clickhouse organization in GitHub.
  3. In the latter case, create a branch with clickhouse/ prefix from the branch you want to integrate, e.g. clickhouse/master (for master) or clickhouse/release/vX.Y.Z (for a release/vX.Y.Z tag). The purpose of this branch is to isolate customization of the library from upstream work. For example, pulls from the upstream repository into the fork will leave all clickhouse/ branches unaffected. Submodules in contrib/ must only track clickhouse/ branches of forked third-party repositories.
  4. To patch a fork of a third-party library, create a dedicated branch with clickhouse/ prefix in the fork, e.g. clickhouse/fix-some-desaster. Finally, merge the patch branch into the custom tracking branch (e.g. clickhouse/master or clickhouse/release/vX.Y.Z) using a PR.
  5. Always create patches of third-party libraries with the official repository in mind. Once a PR of a patch branch to the clickhouse/ branch in the fork repository is done and the submodule version in ClickHouse's official repository is bumped, consider opening another PR from the patch branch to the upstream library repository. This ensures, that 1) the contribution has more than a single use case and importance, 2) others will also benefit from it, 3) the change will not remain a maintenance burden solely on ClickHouse developers.
  6. To update a submodule with changes in the upstream repository, first merge upstream master (or a new versionX.Y.Z tag) into the clickhouse-tracking branch in the fork repository. Conflicts with patches/customization will need to be resolved in this merge (see Step 4.). Once the merge is done, bump the submodule in ClickHouse to point to the new hash in the fork.