Because these classes are compiled against the jgroups jar, these classes have to follow section 6 of the lgpl <http://www.fsf.org/licensing/licenses/lgpl.html>.
Are you sure ?, the lgpl speaks about libraries and applications that are linked to each other, not individual class files.
From <http://www.gnu.org/licenses/lgpl-java.html>:
"The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's "import" functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is a then generally a derivative work of the library."
So I think the application where these classes are included (eg MMBase-core) needs to follow section 6.
If we include these classes in MMBase-core, MMBase-core needs to follow this section also, and the license for MMBase will not be only MPL, but also partly LGPL. Therefore I'd like to see these changes as a seperate (downloadable) module and not included in the core. Also if we want to distribute the jgroups lib inside the MMBase distro, we have to include the jgroups source also in the MMBase src distro.
http://www.jgroups.org/javagroupsnew/docs/license.html
Here they say themserlves that commerical applications have no problem
linking and using their library, how would it be possible that an opensource
package does have a problem ?
http://www.gnu.org/licenses/lgpl-java.html
Says:
If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that -- people who modify the library are responsible for making it work. -----
As far as I know we allow modification (we are MPL code) so this shouldn't be a problem either.
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 only redistribute libraries using the same kind of license (MPL/APL/BSD/etc).
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.
Gerard _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
