On Jun 15, 2012, at 11:19 AM, Les Hazlewood wrote:

Hi all,

Please see my comments inline.

On Fri, Jun 15, 2012 at 2:12 AM, ceki <ceki@qos.ch> wrote:
My apologies for not clarifying this before. As you are probably
aware, the CLA [1] assigns copyright of your contributors to QOS.ch
(see section 2).

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 (http://www.wicketframework.org/wicket-extensions/index.html) and others like it.

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).

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.

*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.

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.

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'.

Legal stuff is important. Not having a CLA or some other vetting process opens up a whole can of worms where people can start committing stuff that they have no right to. By having a CLA you are at least saying that everyone who has committed stuff understand the rules and will abide by them.

Thus, it makes sense to state QOS.ch as the copyright
holder and not each individual contributor.

Ceki already covered this, but the individual contributor should hold their copyright.

Actually, the individual contributor always holds their copyright unless they explicitly give it up. No one should ever sign a CLA where they are forced to do that.

To be blunt, QOS.ch cannot
release software for which it does not hold copyright.

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.

So who does? Or are releases ever made? Getting stuff into maven central from QOS is going to be a bit easier than just some random project.

to

* Copyright (C) 2012, QOS.ch. All rights reserved.

Instead I would prefer what Spring and Amazon AWS (and many others) do for their Open Source copyrights:

Copyright (C) 2012, QOS.ch and original contributor(s). All rights reserved.

While clearer, this is actually the same as the preceding. Neither one is actually required to preserve copyright.

This keeps the copyright static and is a sufficient attribution clause, coupled with @author JavaDoc statements.

The Apache License is OK for the moment although we should one day
settle for either Apache or LGPL+EPL for *both* logback and
logback-extensions. Having two separate licenses for two closely
related projects is a little incoherent.

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.

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.

I guess you missed the discussion where Ceki decided to dual license Logback under the LGPL and EPL just so you could do this. You can use Logback for unit tests at the ASF. That said, I'd prefer you to use Log4j 2.0.

Ralph