Niclas Hedhman wrote:
On Friday 01 September 2006 15:47, Nektarios K. Papadopoulos wrote:
Since FSF is still considering Java to trigger the viral behavior of LGPL
when you have a dependency through an import statement, ASF plays safe
and do not allow projects to have a direct binary dependency.
IANAL, but according to http://www.gnu.org/licenses/lgpl-java.html it is
safe to have a dependency through an import statement. The problem would
be to link to GPL, *not* LGPL.
Nevertheless, indeed ASF do not allow this, with the exceptions
described in the link provided by Upayavira
Mr Turner's statement is of course both accurate and misleading.
I guess I fall in the misleading part ;-)
Though the derived work may not be required to be LGPL'd, the LGPL requires
concession's in the downstream licenses that are not acceptable by the ASF,
i.e. someone making a commercial version of Felix and its constituents must
not be required to allow reverse-engineering of the codebase, which LGPL
require us to enforce on our downstream users. Hence the virality...
I took the time to look closer into the #6 clause of LGPL and -despite
Mr.Turner's statement- reverse-engineering of the codebase is required.
Thanks for pointing out.
Therefor LGPL is listed as Excluded Licenses.
I understand.
<quote source="Cliff Schmidt" >
Inclusion within the product
YOU MUST NOT include any portion of a prohibited work within the Apache
product, whether or not that work is considered required or optional.
YOU MAY include code within the Apache product necessary to achieve
compatibility with a prohibited work through the use of API calls, "bridge
code", or protocols, provided that the compatibility code was contributed
under a CLA. However, any such code used for compatibility with a
third-party work that is licensed under terms that violate criterion #2
("must not place restrictions on the distribution of independent works that
simply use or contain the covered work."), such as the GPL, requires review
and explicit approval of both the PMC chair and the Legal Affairs officer.
This review will ensure that the Apache product takes only the necessary
steps to achieve compatibility.
YOU MAY ALSO include a feature within an Apache product that allows the
user to explicitly choose to download an optional third-party add-on, as
long as that feature also alerts the user of the associated license.
</quote>
I interpret this as;
If JMood (I haven't checked) uses LGPL code that part shall not be part of the
Felix project, irregardless if it is optional or not. And to be safe, the
Facade API reside in Felix (without the linking prohibited code) and the
implementation of that Facade resides elsewhere, e.g. SF.
Well, this part is covered by the replies from Upayavira[1] (this was my
understanding of the whole issue) and Manuel Santillán [2].
[1]http://www.mail-archive.com/felix-dev@incubator.apache.org/msg02241.html
[2]http://www.mail-archive.com/felix-dev@incubator.apache.org/msg02242.html
Any other use, I guess Cliff wants a say about it...
Cheers
Niclas
Cheers
Nek
--
______________________________________________________________
Nektarios K. Papadopoulos
Senior Engineer
Software Engineering Group
inAccess Networks
95A Pentelis Avenue. Tel : +30-210-6837640
152 34 Halandri Athens Fax : +30-210-6899504
______________________________________________________________