Looks like logback is actually dual-licensed under EPL v1.0 and LGPL. http://logback.qos.ch/license.html <http://logback.qos.ch/license.html>
So technically, the logbook EPL code could be included in object/binary form http://www.apache.org/legal/resolved.html#category-b <http://www.apache.org/legal/resolved.html#category-b> > On Dec 29, 2015, at 10:34 PM, Jake Farrell <jfarr...@apache.org> wrote: > > Logback can not be used as it is LGPL licensed > > -Jake > > On Tue, Dec 29, 2015 at 7:02 PM, Jeff Schroeder <jeffschroe...@computer.org> > wrote: > >> Primarily it is faster, uses less memory, and annotates tracebacks with >> package versions. The last one seems like a winner for debugging user >> issues or operationally. >> >> http://logback.qos.ch/reasonsToSwitch.html >> >> I'm not strongly opinionated either way, but it does seem like a better >> log4j. >> >> On Tuesday, December 29, 2015, Bill Farner <wfar...@apache.org> wrote: >> >>> I don't have a strong opinion about logback vs log4j. Can you summarize >>> some of the tradeoffs? >>> >>> On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder < >>> jeffschroe...@computer.org <javascript:;>> >>> wrote: >>> >>>> What about using logback instead of log4j? It has some interesting >>> benefits >>>> over log4j and we wouldn't be the first large mesos framework to switch >>> to >>>> it. >>>> >>>> Personally, I'd love to see glog burn and die in a fire. >>>> >>>> On Monday, December 28, 2015, Bill Farner <wfar...@apache.org >>> <javascript:;>> wrote: >>>> >>>>> We're currently using some logging scaffolding carried over from >>> Twitter >>>>> commons. I would like to propose that we dismantle some of this in >>> favor >>>>> of more standard java application logging conventions. >>>>> >>>>> Concretely, i propose we remove the following scheduler command line >>>>> arguments: >>>>> -logtostderr >>>>> -alsologtostderr >>>>> -vlog >>>>> -vmodule >>>>> -use_glog_formatter >>>>> >>>>> Instead of these, we can allow users to customize logging via >> standard >>>>> java.util.logging inputs (e.g. logging.properties). We could explore >>>> using >>>>> an alternative to java.util.logging, but i suggest we retain that >>> backend >>>>> for now (since it's what we're currently using). >>>>> >>>> >>>> >>>> -- >>>> Text by Jeff, typos by iPhone >>>> >>> >> >> >> -- >> Text by Jeff, typos by iPhone >>
