Third-Party Libraries Used

The list of third-party libraries:

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.