www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: Apache's LGPL Policy
Date Thu, 11 Aug 2005 02:28:48 GMT
On 8/10/05, Dan Diephouse <dan@envoisolutions.com> wrote:
> Ralph Goers wrote:
> 
> > Martin Cooper wrote:
> >
> >> On Wed, 10 Aug 2005, Ralph Goers wrote:
> >>
> >>> I don't agree with this.  I believe Apache should be consistent
> >>> across the board and I don't think that hard dependencies on an
> >>> LGPL'd component should be allowed.  I hate to harp on this, but as
> >>> an example Apache Agila (at least when I looked at it last month)
> >>> would not function without Hibernate. Frankly, I think this should
> >>> prohibit the project from making it out of incubator.  On the other
> >>> hand, providing support for or allowing a framework such as Agila to
> >>> be able to use Hibernate is a very good thing as many of its
> >>> customers will want that.

I'm going to sort-of agree with Martin, but from a different
perspective.  I think trying to draw a distinction between "hard" and
"soft" dependencies is guaranteed to be a disaster.  Besides creating
an opportunity for confusion of Apache developers (who might come to
different conclusions about whether a particular use case is a hard or
soft dependency), it's guaranteed to confuse the users of Apache
software.

To a couple of Dan's points, more comments below.

> >>
> >>
> >>
> >> While I think this would be good in theory, I don't believe it's
> >> practical or realistic. The problem is that this becomes a
> >> significant make-work item for ASF projects. In the particular case
> >> of Hibernate, that is well on its way to being a de facto standard
> >> for persistence, and businesses are standardising on it. Therefore it
> >> makes sense for ASF projects to depend on it. If the policy is that
> >> ASF projects cannot do that, then the developers are forced to do
> >> perhaps significant extra development just to meet the policy, when
> >> the users of the project's software will in large part ignore all
> >> that extra work and use Hibernate anyway.
> >>
> > The policy in place today is no LGPL'd code in Apache stuff.  Now I
> > appreciate that Hibernate is really useful, and while I'd like to make
> > use of it in Cocoon to help out those who are going to use it, I just
> > cannot agree that allowing hard dependencies on LGPL'd code is
> > acceptable.  In effect, you might as well put the project in question
> > under the LGPL as well.  What this will do is cause companies who
> > today allow anything from Apache, because they know it only require
> > stuff under the ASL, to having to make allow/disallow decisions on a
> > project by project basis.
> 
> I think you're going a little far - having the project ASL'd is still
> very worthwhile. First, the ASF project can still be repackaged and used
> commercially. They just can't relicense the LGPL library or sell JUST
> the LGPL library for profit.  Second, portions of the code in the ASF
> project might be reused in another proejct.  Third, at some later date
> it might make sense to rip out the dependency and replace it with
> another one which is more in line with the ASF line of thinking. That
> just won't happen until it becomes worth it for the parties involved to
> do so. Creating a policy which dictates otherwise forces unnecessary
> cost on the project.
> 
> W.r.t companies which only allow anything from Apache:
> 1. IMO, they should develop a more comprehensive IP policy stating if
> the LGPL is allowed

I know of more than a few companies for which this answer is "no" in
the general case (although some allow exceptions for certain uses).

> 2. I don't think its as big of an issue as you make it out to be.
> Companies are much more familiar and comfortable with open source these
> days.

If a company that is familiar with open source licenses decides to
take the "no" position on LGPL, what are they to make of an Apache
project that has a dependency on that package?  From my experience,
the tendency (especially from the legal staff) will be towards "that's
more of the same, therefore the answer is no" ... without even trying
to quibble over whether the dependency is "hard" or "soft".

We either need to believe that the LPGL is OK and are ready to educate
the world about that, or we need to believe that the LGPL is not OK
and are ready to educate the world about that.  Equivocating here
seems like a very un-Apache thing to do.

> 3. IF an LGPL library is included as a hard dependency we could create a
> click-through acknowledgement on the download page so people would be
> aware. In addition there should probably be a FAQ entry describing the
> extra terms imposed by this library. (I will of course volunteer to help
> in this area)

Personally, I cannot *believe* anyone at Apache would ever consider a
click-through license on our own software.  Kinda defeats the whole
point of a BSD-ish license, doesn't it?

> 
> > Now, I don't know who gets to vote on this policy change, but I know
> > if my vote counted I would vote -1 on allowing hard dependencies on
> > LGPL. I would prefer no LGPL as it is today to that.
> >
> > As far as the amount of work goes, today LGPL'd software cannot be
> > used in Apache projects at all. So what I am suggesting is far less
> > work than is required today.
> > So while you may not consider it realistic or practical, it is far
> > better than where we are today and yet continues to maintain how
> > Apache is viewed by the outside world.  I consider that far more
> > important.
> 
> I really don't like outside world benchmarks. If you're so concerned
> about the outside world, there is a good portion of it that would
> consider Apache ridiculous because projects can't use Hibernate.
> Instead, we should go by what we determine to be legally sound and
> reasonable.
> 
> - Dan

Craig McClanahan

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message