-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 23, 2008, at 1:31 AM, Egon Willighagen wrote:
> 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/.
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?
> 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? My worry is
that some core, or close to core, features become GPL'ed.
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.
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
> 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.
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.
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?
- -------------------------------------------------------------------
Rajarshi Guha <[EMAIL PROTECTED]>
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
- -------------------------------------------------------------------
Gods are fragile things; they may be killed by a whiff of
science or a dose of common sense.
-- Chapman Cohen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkfANhQACgkQZqGSLFHnnoTxKACgrsRwf9SUF2tlO62z5dyZG/3k
EpIAoI9RA+/8gylq1xF8bFSL1G9oARS7
=zaQA
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
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
