It occurred to me that any custom Appenders written for Logback must be licensed under the LGPL since they have to extend Logback base classes. Is it possible to change the license for Appender, AppenderBase and UnsynchronizedAppenderBase to something more liberal? I know my employer wouldn't be too thrilled to have to distribute the source for Appenders along with their product.
Hello Ralph, The copyleft clauses of the LGPL mandate that classes derived from Appender need to be distributed under the LGPL. However, I don't see why your employer needs to distribute the source code for the appenders it developed within their product. It could be distributed in a multitude of other ways. You could create an open source project on source forge, you could contribute the new appenders to the logback project, heck, you could create a single web-page on a server. I am sure that at this time and age, one can find an economical way to distribute software. While the liberal ethos of weak licenses have their appeal, the copyleft has merits of its own. I mean it doesn't need to be always take take take. Ralph Goers wrote:
It occurred to me that any custom Appenders written for Logback must be licensed under the LGPL since they have to extend Logback base classes. Is it possible to change the license for Appender, AppenderBase and UnsynchronizedAppenderBase to something more liberal? I know my employer wouldn't be too thrilled to have to distribute the source for Appenders along with their product.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki, There are an infinite number of cases where no one outside of a particular company, or even a business unit of a company, would have any interest in some of these Appenders. Customers might not even want them when the product is sold externally. But to avoid having to go through the hassle of what you describe below, but still be in compliance with the license, all the LGPL'd code would need to by physically kept separate from all the other code to avoid it being distributed. This is just painful to manage. Setting up servers or creating code bases to manage tiny bits of code is almost nonsensical in its practically. The cost of the hardware, software and people time to manage just isn't worth the effort and is even less appealing than separating the code. This isn't about proprietary code. I simply guarantee you that you would not be interested in accepting the Appenders in these cases, as they have no value to the general public. For example, in some cases database appenders might be written to log to some pre-existing database schema. Why would the community want that? In my case, we have an Appender that I wrote and hate, but can't kill because it interacts with our legacy system. I would never distribute it, but for simplicity it is packaged with other general purpose stuff, none of which has the LGPL distribution restrictions. To manage this I will have to create a new isolated project with this single class just to avoid this issue. While the intent of the LGPL is fine - and I agree with it for the core of Logback, Appenders should be considered to be like plug-ins that can act as adapters to other systems. In that sense it is better for them to use the license of the system they are adapting with, not the LGPL. This is very similar to the reason why the Application using Logback needs to be free to use whatever license it wants. This isn't really an extension of Logback but simply a case of wanting to be able to plug it into an existing system. Ralph On Jun 11, 2009, at 12:51 AM, Ceki Gulcu wrote:
Hello Ralph,
The copyleft clauses of the LGPL mandate that classes derived from Appender need to be distributed under the LGPL. However, I don't see why your employer needs to distribute the source code for the appenders it developed within their product. It could be distributed in a multitude of other ways. You could create an open source project on source forge, you could contribute the new appenders to the logback project, heck, you could create a single web-page on a server. I am sure that at this time and age, one can find an economical way to distribute software.
While the liberal ethos of weak licenses have their appeal, the copyleft has merits of its own. I mean it doesn't need to be always take take take.
Ralph Goers wrote:
It occurred to me that any custom Appenders written for Logback must be licensed under the LGPL since they have to extend Logback base classes. Is it possible to change the license for Appender, AppenderBase and UnsynchronizedAppenderBase to something more liberal? I know my employer wouldn't be too thrilled to have to distribute the source for Appenders along with their product.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
Ralph, First, thank you for sharing your perspective with us. I appreciate the new perspective on this topic. Ralph Goers wrote:
Ceki,
There are an infinite number of cases where no one outside of a particular company, or even a business unit of a company, would have any interest in some of these Appenders. Customers might not even want them when the product is sold externally. But to avoid having to go through the hassle of what you describe below, but still be in compliance with the license, all the LGPL'd code would need to by physically kept separate from all the other code to avoid it being distributed. This is just painful to manage.
You mean that if the work derived from the LPGLed library were distributed, then you would need to comply with provision 4 of LGPL 2.1 which mandates that the derived work must be available in source code? Is there any other provision causing you trouble? Instead of separating the LGPLed code, why don't you just add the source code of the LGPLed code in addition to the object form within your existing distribution? If you already want to include or have included the object form, adding the source code form should not be difficult. No?
Setting up servers or creating code bases to manage tiny bits of code is almost nonsensical in its practically. The cost of the hardware, software and people time to manage just isn't worth the effort and is even less appealing than separating the code.
When I said that the source code had to be available and listed the options available, I did not imply that the said code had to be supported. I think that you can just dump it on your blog, some web-page, or send it as a zip file on a publicly available mailing list. However, you also have the option of adding the source code to your existing distribution, which is probably the easiest approach.
This isn't about proprietary code. I simply guarantee you that you would not be interested in accepting the Appenders in these cases, as they have no value to the general public. For example, in some cases database appenders might be written to log to some pre-existing database schema. Why would the community want that? In my case, we have an Appender that I wrote and hate, but can't kill because it interacts with our legacy system. I would never distribute it, but for simplicity it is packaged with other general purpose stuff, none of which has the LGPL distribution restrictions. To manage this I will have to create a new isolated project with this single class just to avoid this issue.
You don't need to create an isolated project. Just aggregate the one or two classes involved in a zip file and dump it someplace. Note that you only need to take action if the said classes are distributed with you product. If the said classes are used within your company without outside distribution, you don't have to take any particular action. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki, I think you are missing the point. All of the solutions you have suggested involve work that a typical corporation would want to avoid having to do. They won't want to set up blogs, or distribute a special zip file and then have to document where it is. It is already hard enough to build a product to be distributed. Rather than deal with it the corporate attorneys will typically tell you not to use the LGPL'd work. Generally, we will get legal approval for LGPL'd works when they don't cause our code to be "infected" and they are disallowed otherwise. As I said, most companies these days would prefer to use off the shelf stuff that is distributed with the framework they chose, so if they need to write a custom appender they would prefer it be donated back to the project. This is regardless of the license (and the LGPL doesn't compel one to do this anyway). But I'd venture a guess that most Appenders that get written that are not requested to be added to Logback are as I described - stuff that is unique to a specific environment that isn't generally useful. So in the end, the LGPL isn't really accomplishing much except making it more difficult for your users to use Logback. Ralph On Jun 12, 2009, at 2:22 AM, Ceki Gulcu wrote:
Ralph,
First, thank you for sharing your perspective with us. I appreciate the new perspective on this topic.
Ralph Goers wrote:
Ceki, There are an infinite number of cases where no one outside of a particular company, or even a business unit of a company, would have any interest in some of these Appenders. Customers might not even want them when the product is sold externally. But to avoid having to go through the hassle of what you describe below, but still be in compliance with the license, all the LGPL'd code would need to by physically kept separate from all the other code to avoid it being distributed. This is just painful to manage.
You mean that if the work derived from the LPGLed library were distributed, then you would need to comply with provision 4 of LGPL 2.1 which mandates that the derived work must be available in source code? Is there any other provision causing you trouble?
Instead of separating the LGPLed code, why don't you just add the source code of the LGPLed code in addition to the object form within your existing distribution? If you already want to include or have included the object form, adding the source code form should not be difficult. No?
Setting up servers or creating code bases to manage tiny bits of code is almost nonsensical in its practically. The cost of the hardware, software and people time to manage just isn't worth the effort and is even less appealing than separating the code.
When I said that the source code had to be available and listed the options available, I did not imply that the said code had to be supported. I think that you can just dump it on your blog, some web-page, or send it as a zip file on a publicly available mailing list. However, you also have the option of adding the source code to your existing distribution, which is probably the easiest approach.
This isn't about proprietary code. I simply guarantee you that you would not be interested in accepting the Appenders in these cases, as they have no value to the general public. For example, in some cases database appenders might be written to log to some pre- existing database schema. Why would the community want that? In my case, we have an Appender that I wrote and hate, but can't kill because it interacts with our legacy system. I would never distribute it, but for simplicity it is packaged with other general purpose stuff, none of which has the LGPL distribution restrictions. To manage this I will have to create a new isolated project with this single class just to avoid this issue.
You don't need to create an isolated project. Just aggregate the one or two classes involved in a zip file and dump it someplace. Note that you only need to take action if the said classes are distributed with you product. If the said classes are used within your company without outside distribution, you don't have to take any particular action.
participants (2)
-
Ceki Gulcu -
Ralph Goers