slf4j bundles and compiles Java class sources from other logging libraries. For log4j-over-slf4j-0:1.7.7-1.fc21.noarch, the file /usr/share/java/slf4j/log4j-over-slf4j.jar includes the class org/apache/log4j/spi/HierarchyEventListener, which is also available from log4j-0:1.2.17-16.fc21.noarch. For jcl-over-slf4j-0:1.7.7-1.fc21.noarch, /usr/share/java/slf4j/jcl-over-slf4j.jar includes the class org/apache/commons/logging/Log, which is also available from apache-commons-logging-1.1.3-11.fc21.noarch. I have not checked whether the class files are copied from the compiled versions in the build tree, or from the build dependencies. Either approach is problematic as far as the Fedora guidelines against bundled libraries are concerned.
The mentioned classes are part of the source and most of them are not copies of anything, they are another implementations that share the same name and package in order to provide replacement for corresponding functionality in log4j/commons-logging. There are some classes and interfaces that look like a copy, but I'm not sure whether they could be unbundled because having original log4j/commons-logging would then create name clashes with the reimplemented ones. And if a package provides a replacement implementation of something, it probably shouldn't pull in the thing it is trying to replace.
Thanks for explaining what is going on. It is surprising that five classes end up being binary identical. How is this supposed to work when two different libraries put slf4j and another logging framework on the classpath? Is such redefinition of classes from other libraries a common occurrence in Fedora Java packages? With the advent of default methods in Java 8, such a reliance on unchanging interfaces seems rather problematic.
FWIW, each logging framework claims to be the best one and provdes adapters implementing other APIs for easier migration. These adapters are not supposed to be used together with libs they are replacing.