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
______________________________________________________________

Reply via email to