On 11/6/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Henri Yandell wrote: > > We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail, > > activation) jars in there. > > > jta and jdbc-stdext are BCL. > > > hibernate is LGPL. > > The BCL files are forbidden by that license to be in source control, and > must be removed. They *are* permitted to be distributed in a package. The > same issue exists for JAMES, Tomcat, and many other packages. At some point > in the future, they should not be an issue, as Sun's new versions will be > under a more open license.
Geronimo have their own implementations (or at least compilable implementations) that can be used for compiling against for probably all 4 of these. Then we just need to figure out how you get the Sun implementation in place for distributions. > MySQL must be the OLD LGPL driver, and is "safe" because it is invoked via > the generic JDBC interface. The new GPL driver is forbidden because our > legal advice to date was that MySQL's "FOSS" exception was flawed and > inadequate. That should be put to Cliff to raise with MySQL, but he doesn't > appear to be around right now. MySQL driver, be it LGPL or GPL, cannot be in our dists or our source repository. The only point where the move from LGPL to GPL has any effect is if we are importing the MySQL driver code directly and not via JDBC. ie) it's fine for us to have code that works with the GPL'd MySQL 3.x, it just can't import com.mysql.*; whereas the LGPL'd version could be imported (based on the newer forthcoming policy). I doubt we even need the MySQL driver in svn. Users should be putting it in the container themselves. That leaves us with ekit, jazzy and Hibernate. ekit and jazzy are both optional features. Hibernate not. With the new policy, which we pretty much need, ekit and jazzy are fine as long as the system works without them (so we need a little bit of magic and the ability for the spell-check button to not show); while we would have a limited time in which to replace Hibernate. Anyone know if there are usable implementations of the new JSR that Hibernate will be working against? It seems to me that we need to do a java.net release of 1.3. ie) a community supported 'fork'; and hold 2.0 back until we get the issues above dealt with. I don't see any reason why we can't do 'internal' releases; namely tagging SVN at special points and having Sun, IBM, JRoller build from those tags (given that it's pretty simple and they're involved with the project anyway). Hen
