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.
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
