Summary
The org.rocksdb:rocksdbjni fat JAR appears to omit the license texts and attribution notices applicable to RocksDB, LevelDB-derived code, and statically linked native dependencies.
I verified this against:
rocksdbjni:9.8.4 (version brought transitively to my project by the Spark version I am using)rocksdbjni:10.10.1, which Maven Central metadata currently identifies as the latest/release version; and- the JNI build and packaging definitions in the latest upstream RocksDB release,
v11.8.1.
The published 10.10.1 JAR contains native binaries for multiple platforms but no LICENSE, NOTICE, COPYING, DEPENDENCIES, or third-party notice material.
The current v11.8.1 source still uses the same packaging approach, so the problem appears to remain present in the latest upstream build definition.
No separate Maven Central license bundle
The Maven Central directory for 10.10.1 does not seem to provide a separate LICENSE, NOTICE, COPYING, third-party notices file, or legal-material classifier or bundle.
The sources classifier also contains no license- or notice-named entry.
The POM declares RocksDB's Apache License 2.0 and GPLv2 options using URLs. However, it does not include:
- The actual license texts
LICENSE.leveldb- Copyright notices and disclaimers for LevelDB-derived code
- License and attribution information for statically linked native dependencies
Current build evidence
Both the v10.10.1 and v11.8.1 Makefiles build the JNI native library with these static compression libraries:
JAVA_COMPRESSIONS = libz.a libbz2.a libsnappy.a liblz4.a libzstd.a
In v11.8.1, the configured versions are:
| Library |
Version |
| zlib |
1.3.1 |
| bzip2 |
1.0.8 |
| Snappy |
1.2.2 |
| LZ4 |
1.10.0 |
| Zstd |
1.5.7 |
The release-JAR targets add history files, native libraries, and Java classes, but do not add any of the project or dependency license files.
Why this matters
rocksdbjni redistributes compiled native implementations for several platforms, including statically linked third-party code.
RocksDB's Apache-2.0 option and several applicable BSD-style licenses contain redistribution conditions involving the provision or reproduction of license, copyright, conditions, and disclaimer material.
Because neither the binary JAR nor a companion Maven artifact supplies that material, downstream projects cannot simply preserve and redistribute the upstream legal files. Each downstream distributor must independently reconstruct the applicable license and notice set. This makes compliant binary redistribution unnecessarily difficult and creates a risk that applications embedding the fat JAR will omit required materials.
Expected result
The published binary JARs should contain an authoritative legal-material set, for example:
META-INF/LICENSE
META-INF/NOTICE
META-INF/licenses/LICENSE.rocksdb-apache-2.0
META-INF/licenses/LICENSE.leveldb
META-INF/licenses/LICENSE.zlib
META-INF/licenses/LICENSE.bzip2
META-INF/licenses/LICENSE.snappy
META-INF/licenses/LICENSE.lz4
META-INF/licenses/LICENSE.zstd
META-INF/THIRD-PARTY-NOTICES
The exact names and contents should be determined by the maintainers' license review.
Alternatively, an official license and notice bundle could be published alongside each Maven release and clearly referenced from the POM. Embedding the materials in every binary JAR would generally be more reliable for downstream redistribution.
Related issues
I searched the public issue tracker and did not find an issue specifically covering omitted legal materials from the Maven rocksdbjni artifacts.
Related but distinct issues include:
Summary
The
org.rocksdb:rocksdbjnifat JAR appears to omit the license texts and attribution notices applicable to RocksDB, LevelDB-derived code, and statically linked native dependencies.I verified this against:
rocksdbjni:9.8.4(version brought transitively to my project by the Spark version I am using)rocksdbjni:10.10.1, which Maven Central metadata currently identifies as the latest/release version; andv11.8.1.The published
10.10.1JAR contains native binaries for multiple platforms but noLICENSE,NOTICE,COPYING,DEPENDENCIES, or third-party notice material.The current
v11.8.1source still uses the same packaging approach, so the problem appears to remain present in the latest upstream build definition.No separate Maven Central license bundle
The Maven Central directory for
10.10.1does not seem to provide a separateLICENSE,NOTICE,COPYING, third-party notices file, or legal-material classifier or bundle.The sources classifier also contains no license- or notice-named entry.
The POM declares RocksDB's Apache License 2.0 and GPLv2 options using URLs. However, it does not include:
LICENSE.leveldbCurrent build evidence
Both the
v10.10.1andv11.8.1Makefiles build the JNI native library with these static compression libraries:JAVA_COMPRESSIONS = libz.a libbz2.a libsnappy.a liblz4.a libzstd.aIn
v11.8.1, the configured versions are:The release-JAR targets add history files, native libraries, and Java classes, but do not add any of the project or dependency license files.
Why this matters
rocksdbjniredistributes compiled native implementations for several platforms, including statically linked third-party code.RocksDB's Apache-2.0 option and several applicable BSD-style licenses contain redistribution conditions involving the provision or reproduction of license, copyright, conditions, and disclaimer material.
Because neither the binary JAR nor a companion Maven artifact supplies that material, downstream projects cannot simply preserve and redistribute the upstream legal files. Each downstream distributor must independently reconstruct the applicable license and notice set. This makes compliant binary redistribution unnecessarily difficult and creates a risk that applications embedding the fat JAR will omit required materials.
Expected result
The published binary JARs should contain an authoritative legal-material set, for example:
The exact names and contents should be determined by the maintainers' license review.
Alternatively, an official license and notice bundle could be published alongside each Maven release and clearly referenced from the POM. Embedding the materials in every binary JAR would generally be more reliable for downstream redistribution.
Related issues
I searched the public issue tracker and did not find an issue specifically covering omitted legal materials from the Maven
rocksdbjniartifacts.Related but distinct issues include: