ClickHouse/docs/en/development/contrib.md

toc_priority	toc_title
71	Third-Party Libraries Used

Third-Party Libraries Used

The list of third-party libraries:

Library name	License type
abseil-cpp	Apache
AMQP-CPP	Apache
arrow	Apache
avro	Apache
aws	Apache
aws-c-common	Apache
aws-c-event-stream	Apache
aws-checksums	Apache
base64	BSD 2-clause
boost	Boost
boringssl	BSD
brotli	MIT
capnproto	MIT
cassandra	Apache
cctz	Apache
cityhash102	MIT
cppkafka	BSD 2-clause
croaring	Apache
curl	Apache
cyrus-sasl	BSD 2-clause
double-conversion	BSD 3-clause
dragonbox	Apache
fast_float	Apache
fastops	MIT
flatbuffers	Apache
fmtlib	Unknown
gcem	Apache
googletest	BSD 3-clause
grpc	Apache
h3	Apache
hyperscan	Boost
icu	Public Domain
icudata	Public Domain
jemalloc	BSD 2-clause
krb5	MIT
libc-headers	LGPL
libcpuid	BSD 2-clause
libcxx	Apache
libcxxabi	Apache
libdivide	zLib
libfarmhash	MIT
libgsasl	LGPL
libhdfs3	Apache
libmetrohash	Apache
libpq	Unknown
libpqxx	BSD 3-clause
librdkafka	MIT
libunwind	Apache
libuv	BSD
llvm	Apache
lz4	BSD
mariadb-connector-c	LGPL
miniselect	Boost
msgpack-c	Boost
murmurhash	Public Domain
NuRaft	Apache
openldap	Unknown
orc	Apache
poco	Boost
protobuf	BSD 3-clause
rapidjson	MIT
re2	BSD 3-clause
replxx	BSD 3-clause
rocksdb	BSD 3-clause
s2geometry	Apache
sentry-native	MIT
simdjson	Apache
snappy	Public Domain
sparsehash-c11	BSD 3-clause
stats	Apache
thrift	Apache
unixodbc	LGPL
xz	Public Domain
zlib-ng	zLib
zstd	BSD

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.