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