[logback-dev] Copyright headers

Fri Jun 15 20:19:54 CEST 2012

Hi all,

Please see my comments inline.

On Fri, Jun 15, 2012 at 2:12 AM, ceki <ceki at 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'.

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.

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.

> 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:

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.

Dual licenses are fine, but Apache 2.0 should be one of them (if not the
only one) IMO.

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.

Respectfully,

--
Les Hazlewood
CTO, Stormpath | http://stormpath.com <http://www.stormpath.com/> |
888.391.5282
PMC Chair, Apache Shiro | http://shiro.apache.org
twitter: @lhazlewood | http://twitter.com/lhazlewood
blog: http://leshazlewood.com
stormpath blog:
http://stormpath.com/blog/index<http://www.stormpath.com/blog/index>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-dev/attachments/20120615/e0db6bf1/attachment-0001.html>