A kdepimlibs-gpl module? (Was: KDE/kdepim/libkleo)

Allen Winter winter at kde.org
Sat Jul 14 14:54:02 BST 2007


On Sunday 24 June 2007 7:25:58 pm Allen Winter wrote:
> On Saturday 23 June 2007 11:18:57 am Charles Connell wrote:
> > Hey guys,
> > 
> > I was going to use Kleo::EncryptionKeyRequester in the Cryptography plugin 
> > preferences page to ask for the user's secret key. Right now there is code 
> > taken from KGpg, and writing something twice is not good. I figured that for 
> > the time being it would be best to make the plugin (not all of kdenetwork) 
> > need kdepim. Of course, the best thing in the end would be to move libkleo to 
> > kdepimlibs so that it can be properly used like a library.
> > 
> > - Charles
> > 
> > PS. I can hold onto this until after they branch for KDE 4 releases, to keep 
> > things how they are for now. Just tell me what you think.
> > 
> 
Update:
 the kleo lib was moved into the kdepimlibs library yesterday.
 so now kopete (kdenetwork) can depend on kdepimlibs, which is fine.

 kleo will retain the GPL license and will be installed as libkleo-gpl.so

> Status Update:
> The kleo library will not be relicensed to the LGPL.
> So, the kleo library will not be relocated to the kdepimlibs module.
> 
> Several options are floating around now:
>  1. create a new kdepimlibs-gpl module for libkleo and a few other
>      useful libraries that must remain GPL for various reasons.
>  2. keep libkleo and its dependencies in kdepim and have
>      kopete (i.e. kdenetwork) depend on kdepim
>  3. move kopete into kdepim
>  4. ??
> 
> This same issue affects mailody.  And we don't want two MUAs in kdepim. 
> So, that basically eliminates #3 as a good solution.
> 
> Option #2 also is ugly.
> 
> Most people I've heard from are pushing for option #1.
> 
> Comments?
> 
> -Allen
> 
>




More information about the kde-core-devel mailing list