At 13:16 18/03/2005, you wrote:
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).
Actually, there are some advances behind the doors because there's a strong demand from the ASF and LGPL projects themselves. The LGPL ban
is not
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.
Not really, when you get a package under a given licence, you get a copy
of the licence and that can't be retroactively changed later on, although you can be prevented from using an updated version of the package due a licence change. If this is licence is written as LGPL+
additional project specific clauses then that's what is enforceable and
not what the FSF decides.
Ultimately, licencing terms are decided by copyright holders not the
foundation that provides the "standard" OSS licences.
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? ;-)
Changing from LGPL to ASL is a significant business decision...
-- Rapha�l Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/
