The following logging dependencies are present in the SDK library (version 2.0.2):

compile commons-logging:commons-logging:1.1.1
compile org.apache.logging.log4j:log4j-jcl:2.13.3
compile org.apache.logging.log4j:log4j-api:2.13.3
compile org.apache.logging.log4j:log4j-core:2.13.3
compile org.apache.logging.log4j:log4j-1.2-api:2.13.3

This is a problem because it imposes a specific logging setup (based on Log4j 2) on projects using the SDK.
However, the decision on how to set up the logging is that of the project using the SDK.

The proper way to handle this situation in SDK would be to:

1. Have just one compile scope dependency on a logging API of your choice (it can be log4j-api, or commons-logging if choosing from existing ones; SLF4J 1.7.x is also a common choice).
2. Have other logging dependencies with test scope, if you want logging to work in your test code

And then the project that is using the SDK can decide where to redirect the logging.

For example, let's say you choose Log4j 2 API as the one logging API for this SDK.
Let's say I also depend on another library that logs to SLF4J API and in my app for some reason I must use Log4j 1.2 as the logging implementation.
Then I can simply configure the required adapters and bridges (Log4j2 to SLF4J, SLF4J to Log4j 1.2), and not have to exclude a bunch of transitive dependencies I do not need.