Actually, this may change soon, provided the LGPL-based project is willing to provide a "clarification of intent" like Hibernate which clearly states how they see the LGPL apply in the java context.
IMO, there are better LGPL-alike licenses that can non-ambigously
be applied in the java world (like the Mozilla MPL) but each project
should chose what suits them best. AFAIK, MPL dependencies are OK.
There was such a debate in the Jakarta General mailing list this fall about Hibernate:
http://mail-archives.eu.apache.org/mod_mbox/jakarta-general/200409.mbox/[EMAIL PROTECTED]
But AFAIK the situation has not changed. The LGPL is unclear. The ASF waits that the FSF clarifies the situation and the FSF will not move (at least the launch of the revised GPL version planned for this year I believe).
Finally, a "clean" dependency on Hibernate with some abstraction layers, why not (exactly what we contributed in Jackrabbit with an Hibernate and an OJB persistance layer implementation. Users have the choice to use either a full BSD like license stuff or to take the risk to use Hibernate. But as a company you can based your choice on some LGPL "interpretations" published on a web site (and a web page is so easily modified, especially with a CMS ;-) )... so the original LGPL text is the key.
All code hosted by the ASF needs to be Apache licensed but we can have
dependencies on external code that have compatible licenses even if they are not ASL.
If they are smoothly coupled yes (cf the example above for the peristence layer of Jackrabbit) but in the case of a CMS/Portal integration, can we really speak of loosely coupled link?
But there is an easy solution to this problem: Why Magnolia does not change its license from LGPL to ASL? ;-)
Cheers, St�phane
