>So I think the application where these classes are included (eg
>MMBase-core) needs to follow section 6.
I agree with that, but that doesn't pose a challenge, because the
requirements are not that difficult to fullfill.
>The problem isn't we can't comply to the LGPL, but the problem is if
we
>allow LGPL code inside the core, we are forcing our users to also
comply
>with the LGPL and we once choose MPL for a reason, so I think we must
I don't understand this, it isn't mentioned anywhere that you need
to change the license of your code. It even says:
-----
FSF's position has remained constant throughout: the LGPL works as
intended with all known programming languages, including Java. Applications
which link to LGPL libraries need not be released under the LGPL. Applications
need only follow the requirements in section 6 of the LGPL: allow new versions
of the library to be linked with the application; and allow reverse engineering
to debug this.
-----
So where does this requirement to change our license come from ?
As far as I see we only need to comply to section 6, which requires
us as said above to allow new verions and reverse engineering of
our code to make it work (which is easy as we provide source).
>Besides that there is a lot that is unclear about the LGPL, that's the
>main reason why eg the Apache Software Foundation doesn't allow LGPL
>code in their projects.
I have read that, oddly enough OpenSymphony's oscache, which uses APL,
does ship with jgroups support built in. Apparentley they don't think
it is a problem.
GrtX. Rico
<<winmail.dat>>
_______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
