On Sat, Feb 23, 2008 at 4:04 PM, Rajarshi Guha <[EMAIL PROTECTED]> wrote: > I'm not very knowledgable about the details of GPL vs LGPL etc, but > your saying that even if we just 'link' to the Weka library, that > would make the CDK into a GPL project? > Does this mean that some class A, that imports the Weka jar, has > become GPL'ed?
Yes, it does. By 'importing' a class particularly, as you define a strong dependency. Those classes were marked as GPL already, or at least the weka classes by Miguel. Now, the libio-joelib and qsarweka module depend on GPL code, and therefore are GPL too. I was informed that by having that in the same distribution as our other code, is it legally unclear what the state of that code is. I assumes in the past that those two CDK modules are quite independent from the rest, but apparently, legally this is less obvious. Therefore, the split, which makes thing conceptually easier to interpret. CDK is LGPL without any deps on GPL code, and CDK-GPL depending on CDK being LGPL, and GPL code. This clearly separates the CDK code from third party GPL libraries. > > Hence, cdk-gpl. > > > > So, CDK-GPL for now is a new CDK-based project, much like cdk-taverna, > > which uses the CDK library as core third-party library. > > Can you summarize what classes are going to be GPL'ed? As far as I know, just libio-joelib and qsarweka. > My worry is that some core, or close to core, features become GPL'ed. No, don't think so. I have been rather careful with that, and am not aware of core CDK code depending on GPL-ed code. This is one of the reasons why we have a relatively complex building system... dependencies are defined in src/META-INF/*.libdepends... so you can easily check those. > Though technically this is probably not an issue, it sound like a bit > of hassle - especially if cdk-gpl is going to include classes that a > number of other classes depend on. That is currently not the case, and should not anyway. > On the other hand if it's a class that more or less stands on its > own, then I can see it becoming a separate project Right, and that's the current situation. > What JOELib code do you have in mind? From a user point of view I see > this as increasing the barrier to usage as you're going to have to > see what funcitonality is available in the LGPL'd CDK and what is in > the GPL'd portion, maybe having to choose between them or not being > able to choose something etc. Yes, that's why a separate SF project is not a bad idea. The CDK website must only list just the CDK, while a CDK-GPL website would list that functionality. It's important that we make clear that both are different projects. > I don't see much issue on the developer side of things. > > But why not just rewrite/reimplement the GPL'd things? Obviously for > Weka this won't happen. But what about for the stuff you want to use > from JOELib? Possible. Not easy, as you are not allowed to use the JOElib code as example code. It must be a clean room implementation... and you know how informative chemoinformatics literature is in that respect... Egon -- ---- http://chem-bla-ics.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Cdk-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cdk-user
