Hi all,<div><br></div><div>Please see my comments inline.<br clear="all">
<div><br></div><div class="gmail_quote">On Fri, Jun 15, 2012 at 2:12 AM, ceki <span dir="ltr"><<a href="mailto:ceki@qos.ch" target="_blank">ceki@qos.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

My apologies for not clarifying this before. As you are probably<br>
aware, the CLA [1] assigns copyright of your contributors to QOS.ch<br>
(see section 2). </blockquote><div><br></div><div>When I created the Logback Extensions project, I did so in the spirit of most of the *Extensions projects with which I have had experience, e.g. Wicket Extensions (<a href="http://www.wicketframework.org/wicket-extensions/index.html" target="_blank">http://www.wicketframework.org/wicket-extensions/index.html</a>) and others like it.</div>

<div><br></div><div>The idea of these extensions projects (and my original intent of Logback Extensions) is that, with the advent of things like Github, modern Open Source has changed: people (and many companies) don't want _any_ barriers to committing to and adopting Open Source projects.  They want to submit patches, check out, fork, submit pull requests, make additions and do whatever they need to Get Their Job Done(tm).</div>

<div><br></div><div>So, whereas Apache (and Logback core) require CLAs for legal measures, various *Extensions projects allow the community to contribute and maintain code as they see fit, without any bureaucracy whatsoever.  People just don't want to deal with this stuff anymore, and *Extensions projects make things easier.</div>

<div><br></div><div>*Extensions projects also act as a buffer to the core projects - things that the core development team may not want to support (either they don't have the time, or the knowledge of a particular module, or the resources, etc), they don't need to 'Officially' support them.  Indeed, a *Extensions project should be used assuming zero support whatsoever.  They exist as a convenience.</div>

<div><br></div><div>Additionally *Extensions projects often act as funnels - as new innovation is made, and as adoption grows of a particular feature and/or module, it can be incorporated into the core project, with all of the legal and support implications therein.</div>
<div><br></div><div>This last point is especially important for Ceki and QOS.ch: as features and/or modules should be incorporated into logback core, only then is the CLA process necessary.  Otherwise it is a burden to adoption/submissions.  If Logback's build environment adopts the same Maven structure as Logback-Extensions, it will be trivial to move modules into Logback core as Ceki et. al. elect to include them as 'Officially Supported'.</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thus, it makes sense to state QOS.ch as the copyright<br>
holder and not each individual contributor. </blockquote><div><br></div><div>Ceki already covered this, but the individual contributor should hold their copyright.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

To be blunt, QOS.ch cannot<br>
release software for which it does not hold copyright. </blockquote><div><br></div><div>Again, QOS.ch would probably not be releasing logback-extensions.  Ceki et. al. could/should certainly lead its releases, but it doesn't need to be officially attributed to QOS.ch.  This eliminates any possibility of legal repercussions.  This also goes back to being new/modern/nimble/anti-bureaucracy.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">to<br>
<br>
 * Copyright (C) 2012, QOS.ch. All rights reserved.<br></blockquote><div><br></div><div>Instead I would prefer what Spring and Amazon AWS (and many others) do for their Open Source copyrights:</div><div><br></div><div>Copyright (C) 2012, QOS.ch and original contributor(s).  All rights reserved.</div>

<div><br></div><div>This keeps the copyright static and is a sufficient attribution clause, coupled with @author JavaDoc statements.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


The Apache License is OK for the moment although we should one day<br>
settle for either Apache or LGPL+EPL for *both* logback and<br>
logback-extensions. Having two separate licenses for two closely<br>
related projects is a little incoherent.<br></blockquote><div><br></div><div>I didn't even think about this when I created the initial project.  I just defaulted to Apache 2.0 because I do this for all of my projects.  Apache 2.0 (for better or worse) is almost universally accepted in legal departments for organizations and corporations worldwide as it is the most understood.  It is very 'business friendly', so almost all organizations can use it, which is best for adoption.</div>

<div><br></div><div>For example, one of my (minor) gripes with Logback is that I can't use it in Apache Shiro for test cases because of the LGPL license.  If it were Apache 2.0 licensed, I could have used it.  Instead I'm stuck with Log4J for my tests.  Granted, this is a minor point for Shiro, but it serves as an example of how adoption can be affected.</div>

<div><br></div><div>Dual licenses are fine, but Apache 2.0 should be one of them (if not the only one) IMO.</div><div><br></div><div>Finally, these are my views on the open-source world and how things have changed, and how I think projects should facilitate this change.  Hopefully this provides a backstory for my motivations/opinions.</div>
<div><br></div><div>Respectfully,</div><div><br></div><div><div>--</div><div>Les Hazlewood</div><div>CTO, Stormpath | <a href="http://www.stormpath.com/" target="_blank">http://stormpath.com</a> | 888.391.5282</div><div>PMC Chair, Apache Shiro | <a href="http://shiro.apache.org/" target="_blank">http://shiro.apache.org</a></div>
<div>twitter: @lhazlewood | <a href="http://twitter.com/lhazlewood" target="_blank">http://twitter.com/lhazlewood</a></div><div>blog: <a href="http://leshazlewood.com/" target="_blank">http://leshazlewood.com</a></div><div>
stormpath blog: <a href="http://www.stormpath.com/blog/index" target="_blank">http://stormpath.com/blog/index</a></div></div></div></div>