Reverted logback license back to LGPL
Hello all, I have reverted the logback license from GPL+classpath exception to the original LGPL. Given that GPL+classpath exception proved as controversial as the original LGPL, there is no point in changing for more of the same. Note that the previous license (GPL+classpath) was introduced in SVN on April the 8th, 2008 and was marked as tentative. Moreover, GPL+classpath was never used in a logback distribution. Just cleaning up... -- Ceki Gülcü
Hi Ceki, might I suggest to change the license from LGPL V2 to LGPL V3? The Apache Software License 2.0 isn't compatible with GPL2, only with GPL3, so software distributed using Apache Software License probably wouldn't be allowed to use logback. http://www.apache.org/licenses/GPL-compatibility.html http://www.fsf.org/licensing/licenses/#apache2 While LGPL allows the use of a later version as an option in its license text, I'm not really sure if this is sufficient to use it with ASL... Common sense indicates yes but the above link indicates no. I'm not sure about LGPL anyway because there only seems to be a problem with GPL. So if you don't see a problem with V3 it would be nice to just be explicit about it. Just to get rid of the uncertainty :) IANAL, Joern. On 09.08.2008, at 17:20, Ceki Gulcu wrote:
Hello all,
I have reverted the logback license from GPL+classpath exception to the original LGPL. Given that GPL+classpath exception proved as controversial as the original LGPL, there is no point in changing for more of the same.
Note that the previous license (GPL+classpath) was introduced in SVN on April the 8th, 2008 and was marked as tentative. Moreover, GPL+classpath was never used in a logback distribution.
Just cleaning up...
-- Ceki Gülcü _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
Hi Joern, The licensing questions are extremely complex. It's one area I would not want to get too creative. Most of the major project which use LGPL use v2.1, e.g. Hibernate. Moreover, if someone is more comfortable with LGPL v3, they can just use it, as the logback license reads: <quote> This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. </quote> So, there is no uncertainty, or considering the OSS licensing mess, there is nothing but uncertainty as soon as you look into the subject carefully. IANAL, Joern Huxhorn wrote:
Hi Ceki,
might I suggest to change the license from LGPL V2 to LGPL V3?
The Apache Software License 2.0 isn't compatible with GPL2, only with GPL3, so software distributed using Apache Software License probably wouldn't be allowed to use logback.
http://www.apache.org/licenses/GPL-compatibility.html http://www.fsf.org/licensing/licenses/#apache2
While LGPL allows the use of a later version as an option in its license text, I'm not really sure if this is sufficient to use it with ASL...
Common sense indicates yes but the above link indicates no.
I'm not sure about LGPL anyway because there only seems to be a problem with GPL.
So if you don't see a problem with V3 it would be nice to just be explicit about it. Just to get rid of the uncertainty :)
IANAL, Joern.
-- Ceki Gülcü
Frankly, I'm not sure why you prefer LGPL over the Apache License. Are you concerned that Log4j will take parts of Logback? Ceki Gulcu wrote:
Hi Joern,
The licensing questions are extremely complex. It's one area I would not want to get too creative. Most of the major project which use LGPL use v2.1, e.g. Hibernate. Moreover, if someone is more comfortable with LGPL v3, they can just use it, as the logback license reads:
<quote> This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. </quote>
So, there is no uncertainty, or considering the OSS licensing mess, there is nothing but uncertainty as soon as you look into the subject carefully.
IANAL,
Joern Huxhorn wrote:
Hi Ceki,
might I suggest to change the license from LGPL V2 to LGPL V3?
The Apache Software License 2.0 isn't compatible with GPL2, only with GPL3, so software distributed using Apache Software License probably wouldn't be allowed to use logback.
http://www.apache.org/licenses/GPL-compatibility.html http://www.fsf.org/licensing/licenses/#apache2
While LGPL allows the use of a later version as an option in its license text, I'm not really sure if this is sufficient to use it with ASL...
Common sense indicates yes but the above link indicates no.
I'm not sure about LGPL anyway because there only seems to be a problem with GPL.
So if you don't see a problem with V3 it would be nice to just be explicit about it. Just to get rid of the uncertainty :)
IANAL, Joern.
Hello Ralph, The different license emphasizes the fact that logback is a different project than log4j. At this stage, developers who wish to contribute to logback can and do contribute. In other words, although the Apache license could potentially facilitate the adoption of logback, the project is doing fine as it is. It may be that I am in denial and that LGPL is hurting the project. When and if that becomes apparent, the license may be changed. In practice, LGPL is preventing the adoption of logback by one major actor, namely the ASF. Now, since Java 7 is licensed under GPL, I think the position of the foundation, that is rejecting (L)GPL wholesale, is simply untenable. I might be misreading the situation. By the way, there should be a FAQ entry for this question. Ralph Goers wrote:
You shouldn't. That is why I'm wondering why the LPGL instead of the Apache license.
-- Ceki Gülcü
Actually, Apache wouldn't have a problem with Logback under the LGPL. It just can't distribute it or host it. As you know, many projects are already using SLF4J. Obviously, it is very easy to tell users what to do to use Logback. The legal committee allows the use of LGPL'd software in exactly these kinds of circumstances. Since users are free to choose from multiple implementations there isn't any restriction that Logback can't be one of them. This discussion has come up many times. The LGPL is not really a problem where the use of the component is optional. The point of the GPL and LGPL is that users who use the library and make modifications must publish those modifications if they wish to distribute their work. This is really more of an impact in a commercial setting than in the ASF. Even then there are a lot of cases where it isn't a problem. But some companies simply won't allow or don't want the "hassle" of making whatever custom filters, appenders, etc they have created available to their customers. Those are the people you will lose out on. I doubt anyone would seriously consider forking the Logback project and then supporting it themselves, even if it was licensed under something like the MIT license. It just doesn't make sense to do that to a project that is actively being maintained, such as Logback is. I work with the Liferay portal, which is licensed under the MIT license. They are doing quite well. In fact, Sun is now partnering with them to jointly develop the code. Sun certainly had the option of taking Liferay's code and then forking it, but it just made no business sense to do that. The bottom line here is that you choose the license you want for a reason. I'm trying to understand how the LGPL provides more benefit to you vs any other license you could pick. You've not really answered that question. Ralph Ceki Gulcu wrote:
Hello Ralph,
The different license emphasizes the fact that logback is a different project than log4j. At this stage, developers who wish to contribute to logback can and do contribute. In other words, although the Apache license could potentially facilitate the adoption of logback, the project is doing fine as it is. It may be that I am in denial and that LGPL is hurting the project. When and if that becomes apparent, the license may be changed.
In practice, LGPL is preventing the adoption of logback by one major actor, namely the ASF. Now, since Java 7 is licensed under GPL, I think the position of the foundation, that is rejecting (L)GPL wholesale, is simply untenable. I might be misreading the situation.
By the way, there should be a FAQ entry for this question.
Ralph Goers wrote:
You shouldn't. That is why I'm wondering why the LPGL instead of the Apache license.
Ralph Goers wrote:
Actually, Apache wouldn't have a problem with Logback under the LGPL. It just can't distribute it or host it. As you know, many projects are already using SLF4J. Obviously, it is very easy to tell users what to do to use Logback. The legal committee allows the use of LGPL'd software in exactly these kinds of circumstances. Since users are free to choose from multiple implementations there isn't any restriction that Logback can't be one of them. This discussion has come up many times. The LGPL is not really a problem where the use of the component is optional.
"Can't distribute and host it" is pretty restrictive isn't it? If you can't distribute it, this implies that you cannot depend on it, right? I was also under the impression that the ASF was queasy about such indirect dependencies...
The point of the GPL and LGPL is that users who use the library and make modifications must publish those modifications if they wish to distribute their work. This is really more of an impact in a commercial setting than in the ASF. Even then there are a lot of cases where it isn't a problem. But some companies simply won't allow or don't want the "hassle" of making whatever custom filters, appenders, etc they have created available to their customers. Those are the people you will lose out on.
Does this apply to your company by any chance?
I doubt anyone would seriously consider forking the Logback project and then supporting it themselves, even if it was licensed under something like the MIT license. It just doesn't make sense to do that to a project that is actively being maintained, such as Logback is. I work with the Liferay portal, which is licensed under the MIT license. They are doing quite well. In fact, Sun is now partnering with them to jointly develop the code. Sun certainly had the option of taking Liferay's code and then forking it, but it just made no business sense to do that.
The bottom line here is that you choose the license you want for a reason. I'm trying to understand how the LGPL provides more benefit to you vs any other license you could pick. You've not really answered that question.
LGPL is just a different and widely-accepted license, that's all.
Ralph
-- Ceki Gülcü
Ceki Gulcu wrote:
Ralph Goers wrote:
Actually, Apache wouldn't have a problem with Logback under the LGPL. It just can't distribute it or host it. As you know, many projects are already using SLF4J. Obviously, it is very easy to tell users what to do to use Logback. The legal committee allows the use of LGPL'd software in exactly these kinds of circumstances. Since users are free to choose from multiple implementations there isn't any restriction that Logback can't be one of them. This discussion has come up many times. The LGPL is not really a problem where the use of the component is optional.
"Can't distribute and host it" is pretty restrictive isn't it? If you can't distribute it, this implies that you cannot depend on it, right?
No. A project can list it as a maven dependency. In the case of Logback vs Log4j this could be handled using profiles.
I was also under the impression that the ASF was queasy about such indirect dependencies...
Not really. It just depends on the circumstances.
The point of the GPL and LGPL is that users who use the library and make modifications must publish those modifications if they wish to distribute their work. This is really more of an impact in a commercial setting than in the ASF. Even then there are a lot of cases where it isn't a problem. But some companies simply won't allow or don't want the "hassle" of making whatever custom filters, appenders, etc they have created available to their customers. Those are the people you will lose out on.
Does this apply to your company by any chance?
No. But it is one of the reasons I submit my enhancements back to you. We don't distribute the software the software using logback so it isn't really a problem in any case.
I doubt anyone would seriously consider forking the Logback project and then supporting it themselves, even if it was licensed under something like the MIT license. It just doesn't make sense to do that to a project that is actively being maintained, such as Logback is. I work with the Liferay portal, which is licensed under the MIT license. They are doing quite well. In fact, Sun is now partnering with them to jointly develop the code. Sun certainly had the option of taking Liferay's code and then forking it, but it just made no business sense to do that.
The bottom line here is that you choose the license you want for a reason. I'm trying to understand how the LGPL provides more benefit to you vs any other license you could pick. You've not really answered that question.
LGPL is just a different and widely-accepted license, that's all.
So are MIT, Apache, BSD, etc. Yet you didn't choose one of them or one of many other licenses listed at the open source initiatives site. Surely you had more of a reason than that. Ralph
Ralph Goers wrote:
Ceki Gulcu wrote:
LGPL is just a different and widely-accepted license, that's all.
So are MIT, Apache, BSD, etc. Yet you didn't choose one of them or one of many other licenses listed at the open source initiatives site. Surely you had more of a reason than that.
MIT and BSD like Apache, except shorter. The LGPL is more assertive. I also find it morally acceptable and depending on the circumstance even desirable to propagate LGPL to logback extensions. The ASF point of view, i.e no license propagation, is also reasonable. I really wish the ASF and FSF could reach some sort of agreement and then declare their licenses mutually compatible. The FSF has done that. The ASF has not. Given that it has taken over two years to settle on the patent clauses of the Apache license, I am not holding my breath. -- Ceki Gülcü
Ceki Gulcu wrote:
Ralph Goers wrote:
Ceki Gulcu wrote:
LGPL is just a different and widely-accepted license, that's all.
So are MIT, Apache, BSD, etc. Yet you didn't choose one of them or one of many other licenses listed at the open source initiatives site. Surely you had more of a reason than that.
MIT and BSD like Apache, except shorter. The LGPL is more assertive. I also find it morally acceptable and depending on the circumstance even desirable to propagate LGPL to logback extensions. The ASF point of view, i.e no license propagation, is also reasonable.
I really wish the ASF and FSF could reach some sort of agreement and then declare their licenses mutually compatible. The FSF has done that. The ASF has not. Given that it has taken over two years to settle on the patent clauses of the Apache license, I am not holding my breath.
I'm not exactly an expert, in fact far from it (and most of the code I work on is closed) but - Why not simply dual-license? LGPL + Apache? Greetings, Lilianne
Hi Lilianne, Dealing with a single license is already very complicated. Dual licensing, in particular contradictions between the two licenses, just makes dual licensing unbearably complex. Other than that, it's a good idea. :-) Lilianne E. Blaze wrote:
I'm not exactly an expert, in fact far from it (and most of the code I work on is closed) but -
Why not simply dual-license? LGPL + Apache?
Greetings, Lilianne
-- Ceki Gülcü
I just discovered that Glassfish is distributed under a dual-license, CDDL or GPL. Interesting... Ceki Gulcu wrote:
Hi Lilianne,
Dealing with a single license is already very complicated. Dual licensing, in particular contradictions between the two licenses, just makes dual licensing unbearably complex.
Other than that, it's a good idea. :-)
Lilianne E. Blaze wrote:
I'm not exactly an expert, in fact far from it (and most of the code I work on is closed) but -
Why not simply dual-license? LGPL + Apache?
Greetings, Lilianne
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu skrev den 29-08-2008 18:11:
I just discovered that Glassfish is distributed under a dual-license, CDDL or GPL. Interesting...
I believe that Sun has finaly recognized that they want open source marked penetration instead of absolute control of their software, and that the Linux distributions liked the CDDL as little as Sun liked the GPL. The choice of license is political IMHO. Personally the GPL agrees best with me, but in the case of logback where you try to penetrate on a marked which is already filled this is most likely a disadvantage as it will prohibit the uptake in long running commercial applications (I work in an environment where code literaly live forever, you just upgrade the hardware so code licenses are important also for supportive libraries). I think that adapting a suitable dual or even triple license would be reasonable for this very basic functionality. -- Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
participants (5)
-
Ceki Gulcu -
Joern Huxhorn -
Lilianne E. Blaze -
Ralph Goers -
Thorbjørn Ravn Andersen