Hello Christian, Joern, Les, Tomasz, Tony, as well all future contributors, I am super thrilled to see the logback-extensions project taking off with contribution flowing in. It makes it all the more important to tackle legal issues as early as possible in order to as to avoid ill-will in the future. No one likes to see the rules change in mid-flight. 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). Thus, it makes sense to state QOS.ch as the copyright holder and not each individual contributor. To be blunt, QOS.ch cannot release software for which it does not hold copyright. Of course, the various @author tags and commit history reveal the actual authors, pursuant the authors' moral rights [2]. More concretely, the headers in [3, 4, 5] need to change from * Copyright 2012 Tomasz Nurkiewicz, Christian Trutz, et. al. * Copyright 2012 Ceki Gulcu, Les Hazlewood, et. al. * Copyright 2012 Ceki Gulcu, Anthony Trinh, et. al. to * Copyright (C) 2012, QOS.ch. All rights reserved. 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. Please let me know if you agree or oppose this change. All comments are most welcome. [1] http://logback.qos.ch/cla.txt [2] http://en.wikipedia.org/wiki/Moral_rights_(copyright_law) [3] http://bit.ly/KyxC3E [4] http://bit.ly/MMIINk [5] http://bit.ly/Lf2DJh -- Ceki http://twitter.com/#!/ceki
On Fri, Jun 15, 2012 at 5:12 AM, ceki <ceki@qos.ch> wrote:
Hello Christian, Joern, Les, Tomasz, Tony, as well all future contributors,
I am super thrilled to see the logback-extensions project taking off with contribution flowing in. It makes it all the more important to tackle legal issues as early as possible in order to as to avoid ill-will in the future. No one likes to see the rules change in mid-flight.
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). Thus, it makes sense to state QOS.ch as the copyright holder and not each individual contributor. To be blunt, QOS.ch cannot release software for which it does not hold copyright. Of course, the various @author tags and commit history reveal the actual authors, pursuant the authors' moral rights [2].
More concretely, the headers in [3, 4, 5] need to change
from
* Copyright 2012 Tomasz Nurkiewicz, Christian Trutz, et. al. * Copyright 2012 Ceki Gulcu, Les Hazlewood, et. al. * Copyright 2012 Ceki Gulcu, Anthony Trinh, et. al.
to
* Copyright (C) 2012, QOS.ch. All rights reserved.
I've updated EclipseLogAppender.java and related files (as that's the only area I've touched in this project). I'm tempted to do a global search+replace, but I'll wait for everyone's input. Or if you're feeling frisky, this command should do it (tested in OSX from the logback-extensions source directory): $ grep -lr 'Copyright 2012' . | xargs gsed -i 's/Copyright.*/Copyright (C) 2012, QOS.ch. All rights reserved./g'
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 agree with your point on the separate licenses and that there should be a common license. I had actually asked Les about this a while ago, and it turns out the license choice was merely an accident. Most of his projects use the Apache license, so his IDE is setup to insert it automatically. He didn't mean to make it different from logback.
On 15.06.2012 12:36, Tony Trinh wrote:
I've updated EclipseLogAppender.java and related files (as that's the only area I've touched in this project). I'm tempted to do a global search+replace, but I'll wait for everyone's input. Or if you're feeling frisky, this command should do it (tested in OSX from the logback-extensions source directory):
Thank you Tony. As for applying a global search and replace, let's wait for input from everyone and iron out disagreements if any.
$ grep -lr 'Copyright 2012' . | xargs gsed -i 's/Copyright.*/Copyright (C) 2012, QOS.ch. All rights reserved./g'
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 agree with your point on the separate licenses and that there should be a common license. I had actually asked Les about this a while ago, and it turns out the license choice was merely an accident. Most of his projects use the Apache license, so his IDE is setup to insert it automatically. He didn't mean to make it different from logback.
Marker hilarious = MarkerFactory.getMarker("hilarious"); for(int i = 1; i <= 100; i++) { if(i % 15 == 0) logger.debug(hilarious, "ha! ha! ha! he! he! he!"); else if(i % 3 == 0) logger.debug(hilarious, "ha! ha! ha!"); else if(i % 5 == 0) logger.debug(hilarious, "he! he! he!"); else logger.trace(hilarious,":-) :-) :-)"); } -- Ceki http://twitter.com/#!/ceki
On 15.06.2012 11:12, ceki 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). Thus, it makes sense to state QOS.ch as the copyright holder and not each individual contributor. To be blunt, QOS.ch cannot release software for which it does not hold copyright. Of course, the various @author tags and commit history reveal the actual authors, pursuant the authors' moral rights [2].
Bertrand Delacretaz correctly pointed out that by signing the logback CLA [1], contributors *grant* copyright to QOS.ch, they do not *assign* it. The difference is subtle but important. The contributor continues to hold his or her previous copyrights to the contributed work. I am sorry for the incorrect wording in my previous message (quoted above). [1] http://logback.qos.ch/cla.txt -- Ceki http://twitter.com/#!/ceki
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'. 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: Copyright (C) 2012, QOS.ch and original contributor(s). All rights reserved. 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>
On 15.06.2012 20:19, Les Hazlewood wrote:
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.
Hi Les, I know you are busy elsewhere, so thank you for taking the time to post. I would like to keep the discussion on project organization separate from the question of which license to use (Apache/EPL/LGPL) for logback. I'll answer your post on project organization in a separate email. You can use logback in Apache Shiro! Logback is dual licensed under LGPL and EPL. The latter is a "Category B: Reciprocal License" in Apache terminology. According to Apache's Third-Party Licensing Policy [1], EPLed software can be consumed by Apache projects. Apache Jackrabbit does, and given the people involved, it is not for lack of knowledge about licensing issues. Or am I missing something? [1] http://www.apache.org/legal/3party.html -- Ceki http://twitter.com/#!/ceki
See comments below 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
On 16.06.2012 01:18, Ralph Goers wrote:
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.
Ironically enough, Les is one of the persons who broached the issue of using logback in Apache projects. (see his email [1] dated September 3rd 2009). On September 9th 2009, Ralph rightly asked me to close LEGAL-63 [2]. In my reply to Ralph [3], I wrote: ..., the theoretical case of an LGPLed library implementing a standard (licensed under a liberal license) remains valuable. It illustrates LGPL's requirements on reverse engineering. For example, Let FooCorp be a company and Frobber be some software developed by FooCorp. Frobber codes against the SLF4J API without ever directly referencing logback. Can FooCorp distribute Frobber with an unmodified version of logback (our LGPLed library). Does the LGPL require FooCorp to allow users to reverse engineer Frobber for their own use? Keep in mind that Frobber usage of logback in Frobber is isolated behind the SLF4J API. The answer to that question is *surprisingly* yes, although with some qualifications too hairy to be mentioned. FooCorp is required to allow reverse engineering of logback in the software license for Frobber. This follows from discussions with Luigi Bai, an FSF volunteer, and is also documented by the Free Software licensing quiz (see http://www.gnu.org/cgi-bin/license-quiz.cgi ), in particular question 8, which reads: Question: FooCorp [a company] distributes Frobber [software developed by FooCord] linked against an unmodified version of LibIdo [an LGPL library]. Does the LGPL require FooCorp to allow users to reverse engineer Frobber for their own use? Correct answer: Yes. I still have my doubts about the applicability of the reverse-engineering clause but the FSF thinks otherwise, as insofar as an organization can think. FSF's interpretation is in turn echoed by defensive measures by others, e.g. the ASF. The LGPL is a little less liberal than what it seems initially. It is what it is, neither good or bad. Nevertheless, the mere fact that the reverse-engineering question is so convoluted and shrouded in layers of gobbledygook, is one of the principal reasons for dual-licensing logback. As I find FSF's interpretation of the LGPL unreasonable (but they are the guardians of LGPL so their interpretation matters), I decided to dual-license logback under LGPL (for backwards legal compatibility) and EPL (a less vindicative/more reasonable reciprocal license). [1] http://tinyurl.com/nsj6wf [2] https://issues.apache.org/jira/browse/LEGAL-63 [3] http://tinyurl.com/cu6hpso
Ralph
-- Ceki http://twitter.com/#!/ceki
On 15.06.2012 20:19, Les Hazlewood wrote:
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).
Hello all, First and foremost, I'd like to express my gratitude to Les for the logback-extensions initiative. It has prompted interest in contributions well beyond expectations. Regarding the CLA, in my experience requesting for CLAs has not been a hindrance. Developers who made contributions or have expressed interest in contributing have always signed the CLA when requested to do so. As a matter of fact, all current members of logback-extensions *already* have CLAs on file, that is all members except Les**. It's an unfortunate mishap attributable entirely to me. I'll contact Les in private for the CLA. ** Les' remarks about the CLA seemed hypothetical until I noticed that he did not have a CLA on file. How embarrassing! Beyond the CLA issue, Les also raises good questions about contribution management. Now is probably a good time to discuss the purpose of the logback-extensions project. As I envision it, logback-extesions will host modules with narrower scope than modules in logback-proper. Hopefully, many of these modules will be on par quality-wise with modules in logback-proper. Experimental modules of lesser reliability should be marked as such, i.e. experimental. Moreover, modules should be able to move in either direction: from logback-extensions to logback-proper and from logback-proper to logback-extensions. In practice however, I'd expect that once a module finds a home, it will tend to stay put. Logback-extensions' adds value because it reduces coupling with logback-proper. As I understand it, developers feel freer working on a particular module without necessarily needing to coordinate with the core project. For example, logback-extensions can have a different release cycle than logback-proper. Certain modules may even choose to live as separate projects with yet a different lifecycle. I've been also implicitly assuming that logback-extensions would be distributed under the QOS.ch banner. For example, it would be released under the ch.qos.logback namespace in Maven central. Similarly, documentation for modules in logback-extensions modules would be hosted under http://logback.qos.ch/. Have I misread the situation? Given the above, my question is: Should logback-extensions be released under the QOS.ch banner? [] Yes, logback-extensions should be released under the QOS.ch banner. [] No, it should be released under a different banner. [] Maybe (please explain) Your comments are welcome. -- Ceki http://twitter.com/#!/ceki
On Jun 16, 2012, at 6:49 AM, ceki wrote:
Given the above, my question is:
Should logback-extensions be released under the QOS.ch banner?
[] Yes, logback-extensions should be released under the QOS.ch banner. [] No, it should be released under a different banner. [] Maybe (please explain)
What would the alternative be? You already have a process in place to get artifacts into Maven Central. How would a separate project do that? Ralph
On 16.06.2012 17:02, Ralph Goers wrote:
On Jun 16, 2012, at 6:49 AM, ceki wrote:
Given the above, my question is:
Should logback-extensions be released under the QOS.ch banner?
[] Yes, logback-extensions should be released under the QOS.ch banner. [] No, it should be released under a different banner. [] Maybe (please explain)
What would the alternative be? You already have a process in place to get artifacts into Maven Central. How would a separate project do that?
Well, I guess one or more volunteers who wanted to manage logback-extensions could publish it under some new name, say http://logback-extensions.org or http://logbackframework.org. Stretching it further, the extensions could be published under an FOSS organization, e.g. FSF, Eclipse or Apache. I certainly do not encourage these venues but they do exist as alternatives.
Ralph
-- Ceki http://twitter.com/#!/ceki
Hi, my opinion is: [x] Yes, logback-extensions should be released under the QOS.ch banner. [] No, it should be released under a different banner. [] Maybe (please explain) logback is also released under QOS.ch banner. It would be very confusing, if logback and logback-extensions will go separate ways. Christian 2012/6/16 Ralph Goers <rgoers@apache.org>
On Jun 16, 2012, at 6:49 AM, ceki wrote:
Given the above, my question is:
Should logback-extensions be released under the QOS.ch banner?
[] Yes, logback-extensions should be released under the QOS.ch banner.
[] No, it should be released under a different banner.
[] Maybe (please explain)
What would the alternative be? You already have a process in place to get artifacts into Maven Central. How would a separate project do that?
Ralph
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
-- Christian Trutz Von-Flotow-Straße 24 D-45772 Marl Festnetz (privat): +49 (0)2365 3840327 E-Mail: christian.trutz@gmail.com
On Sat, Jun 16, 2012 at 4:52 PM, Christian Trutz <christian.trutz@gmail.com>wrote:
Hi,
my opinion is:
[x] Yes, logback-extensions should be released under the QOS.ch banner. [] No, it should be released under a different banner. [] Maybe (please explain)
logback is also released under QOS.ch banner. It would be very confusing, if logback and logback-extensions will go separate ways.
I concur
participants (5)
-
ceki -
Christian Trutz -
Les Hazlewood -
Ralph Goers -
Tony Trinh