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

Guidelines for adding new third-party libraries and maintaining custom changes in them

  1. All external third-party code should reside in the dedicated directories under contrib directory of ClickHouse repo. Prefer Git submodules, when available.
  2. Fork/mirror the official repo in Clickhouse-extras. Prefer official GitHub repos, when available.
  3. Branch from the branch you want to integrate, e.g., master -> clickhouse/master, or release/vX.Y.Z -> clickhouse/release/vX.Y.Z.
  4. All forks in Clickhouse-extras can be automatically synchronized with upstreams. clickhouse/... branches will remain unaffected, since virtually nobody is going to use that naming pattern in their upstream repos.
  5. Add submodules under contrib of ClickHouse repo that refer the above forks/mirrors. Set the submodules to track the corresponding clickhouse/... branches.
  6. Every time the custom changes have to be made in the library code, a dedicated branch should be created, like clickhouse/my-fix. Then this branch should be merged into the branch, that is tracked by the submodule, e.g., clickhouse/master or clickhouse/release/vX.Y.Z.
  7. No code should be pushed in any branch of the forks in Clickhouse-extras, whose names do not follow clickhouse/... pattern.
  8. Always write the custom changes with the official repo in mind. Once the PR is merged from (a feature/fix branch in) your personal fork into the fork in Clickhouse-extras, and the submodule is bumped in ClickHouse repo, consider opening another PR from (a feature/fix branch in) the fork in Clickhouse-extras to the official repo of the library. This will make sure, 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.
  9. When a submodule needs to start using a newer code from the original branch (e.g., master), and since the custom changes might be merged in the branch it is tracking (e.g., clickhouse/master) and so it may diverge from its original counterpart (i.e., master), a careful merge should be carried out first, i.e., master -> clickhouse/master, and only then the submodule can be bumped in ClickHouse.