Dear all, with this email I would like to announce a new CDK subproject, CDK-GPL [0]. Before explaining what it is, I'll first say with it is not.
1) CDK-GPL is *not* a replacement for the current CDK; it is an extension. 2) CDK-GPL does *not* mean that the CDK changed its license policy. CDK will be kept licensed LGPL. LGPL is the license the project uses, and this does not change. All new CDK must be LGPL. 2) CDK-GPL does *not* set a precedence, but cleans up our current repository. Instead, it is needed to clean up license issues recently found. == The Details == The current situation is that the CDK project did write code that interfaces or even depends on third-party libraries that are GPL. Most of the code does not, but there are a few tainted bits. The recent work on a CDK Debian package [1] made this problem more clear. Code that is GPL in our tree, for example, involves the qsarweka module. But the Convertor class to interface to JOELib might be affected too. Nothing much that worried me, because these blobs are extending the main CDK library, but point taken that the situation is unclear, and legally unproven. I'll take advice from our Debian friends, and removed the weka-depending code from the 1.0.2 pre-releases, and will do the same for trunk/. 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. It will contain the GPL-ed code we currently have in the main CDK repository, and make it clear that the CDK itself is *LGPL* and that its optional dependencies do not conflict with that. This new module, obviously, is GPL, and hence the name. Things we should consider, going from here: 1. should we set up a CDK-GPL project separately? E.g. cdkgpl.sf.net? 2. should we bring CDK-GPL to a higher level, and start merging with JOELib? I find the second option rather attractive. JOELib still has some functionality that the CDK does not have. Such as a number of QSAR descriptors. The CDK-GPL project could adopt this JOELib code and rewrite it based on the CDK interfaces. Comments on these issues much appreciated. From both a user point of view, as well as a developers point of view. Egon 0.http://cdk.svn.sourceforge.net/viewvc/cdk/trunk/cdk-gpl/ 1.http://chem-bla-ics.blogspot.com/2008/02/cdk-close-to-entering-debian.html 2.http://cheminfo.informatics.indiana.edu/~rguha/code/java/nightly/api/org/openscience/cdk/qsar/model/weka/package-frame.html -- ---- 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
