Return-Path: Delivered-To: apmail-jakarta-log4j-dev-archive@apache.org Received: (qmail 69040 invoked from network); 19 May 2003 17:26:54 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 19 May 2003 17:26:54 -0000 Received: (qmail 16598 invoked by uid 97); 19 May 2003 17:29:04 -0000 Delivered-To: qmlist-jakarta-archive-log4j-dev@nagoya.betaversion.org Received: (qmail 16590 invoked from network); 19 May 2003 17:29:04 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 19 May 2003 17:29:04 -0000 Received: (qmail 68831 invoked by uid 500); 19 May 2003 17:26:52 -0000 Mailing-List: contact log4j-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@jakarta.apache.org Received: (qmail 68817 invoked from network); 19 May 2003 17:26:51 -0000 Received: from unknown (HELO exchange.bevocal.com) (66.147.154.130) by daedalus.apache.org with SMTP; 19 May 2003 17:26:51 -0000 Received: by exchange.bevocal.com with Internet Mail Service (5.5.2656.59) id ; Mon, 19 May 2003 10:26:55 -0700 Message-ID: From: Mark Womack To: 'Log4J Developers List' Subject: RE: ConfiguraionServlet Date: Mon, 19 May 2003 10:26:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N It all depends on what you want to get out of it. > re: licensing, the short answer is that I'm not sure. This > is what I'm > thinking at the moment. > > 1) I'd like to retain control over the development at least > until it is > completed. I'm in the process of writing a functional spec > that defines > what I think the completed app should include. Well, you could maintain a level of control in the log4j-sandbox, but obviously other sandbox participants will be able to apply changes as well. That is the nature of a collaborative open source project. I think everyone would like to discuss and execute against good game plan in regards to this functionality. There is always the decision to "accept" the code into the log4j-core release, made by the log4j-core committers at the time. But, if the functionality fills a need and the code and participation is strong enough, I can't imagine that it would not be accepted. There has been strong interest in working on this area configuration. > 2) I'd like the app to be freely available and accessible to as many > people as possible. It doesn't get much more freely available and accessible than Apache open source. IMHO. > 3) Not being entirely selfless I'd like to get credit for > developing the > app. Of course. All credit is attached for submitted classes, etc. But, it is part of the larger whole. > So, by having the app closed source is keeping my options as open as > possible. for the moment at least. > > what do you think? You can always do your development closed and then release the source as part of the release. There are examples of other log4j components that do something similar. But they are not part of the log4j release (though they are referenced from the log4j web pages). Exploring it as part of the log4j project gives some more exposure to the component and provides some community interaction, and hopefully a better overall product/tool. But, you should do what you are comfortable with. As Ceki says, the one doing the work is the one that gets to make the decisions. I am looking forward to seeing what you come up with. thanks, -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: log4j-dev-help@jakarta.apache.org