Thanks, Ceki. Although the Apache license certainly allows copying code to anything it is against ASF policy to take code against their author’s wishes.
That said, we have not incorporated anything into log4j-1.2-api that we believe may have security issues and won’t until we resolve them. Even if we cannot copy the code that still doesn’t preclude us from coming up with a compatible solution should we choose to do so. Ralph > On Jan 27, 2022, at 1:34 PM, Ceki Gülcü <[email protected]> wrote: > > > Ralph, > > I would like to observe that Vlardimir's JDBCAppender contribution was > made outside Apache. While the code in question is licensed under the > ASL, it has not been contributed to the Apache Foundation. Unless the > foundations rules have changed, you cannot copy the changes without > Vladimir's permission or mine for that matter. As a person who served in > the foundation's IP committee, you probably already knew that and it had > slipped your mind. > > In any case and perhaps also in light of the above, the comparison of a > colleague with a noxious insect in a public mailing list was probably > not an optimal choice of words. > > As for relocating log4j:log4j to log4j12-api, I do not know the exact > details of the level of compatibility offered by log4j12-api so I will > refrain from commenting further and risk making a fool of myself. > > Best regards, > > On 1/27/2022 8:07 PM, Ralph Goers wrote: >> >> >>> On Jan 27, 2022, at 11:41 AM, Vladimir Sitnikov >>> <[email protected]> wrote: >>> >>>> 1. It is an exact copy of log4j-1.2-api with the binary, source, and >>> javadoc jars renamed to log4j:log4j. >>>> 2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty. >>> >>> The options are bad as log4j-1.2-api misses several classes that are used a >>> lot in log4j 1.x deployments. >>> For instance, org.apache.log4j.jdbc.JDBCAppender. >> >> That would put it on par with reload4j 2.18.1. That said, if the >> JDBCAppender was fixed in >> reload4j we can either copy it into log4j-1.2-api as a log4j 1.x appender or >> reimplement >> it as a log4j 2 appender. >> >> If there are other classes that are required you are invited to submit PRs >> to address them. >> >>> >>> If you release that as log4j:log4j:2.x, then you trigger a lot of >>> non-workable update suggestions. >>> >>> ---- >>> >>> Then, if you think log4j-1.2-api:2.x is good enough to replace >>> log4j:log4j:1.x, then you basically say >>> "all the issues in 1.x can be solved without breaking backward >>> compatibility". >>> I am afraid that contradicts Ron's message: >>> https://lists.apache.org/thread/dlz8nyrsvffmgq29d354s0l484lfc83w >> >> It absolutely does not. The issues in Log4j 1.x are in the core of how it >> processes log >> events. Log4j 2 doesn’t suffer from any of those issues. >> >> Instead of continuing to be a gnat and arguing against Log4j2 you could >> start being part >> of the solution and work to improve the bridge. >> >> This thread is not about discussing why reload4j is better than >> log4j-1.2-api. That >> discussion is over. If you continue on that path you will be put into >> moderation. >> However, if you can provide a better way to let users migrate to Log4j2 we >> will be >> happy to hear it. >> >> Ralph > > -- > Ceki Gülcü > > Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
