Re: kdepimlibs Licensing
On Wednesday 19 November 2008 5:14:17 am Dirk Mueller wrote: > On Friday 07 November 2008, Allen Winter wrote: > > > Unless there are objections, I'd like to go ahead with this new plan. > > I would object unless BC/API has been reviewed > Glad we procrastinated then. Let's discuss this issue later. Too much going on right now. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
Op woensdag 19 november 2008 11:14 schreef u: > mailody can depend on kdepim, given that it will ultimatively merge or move > into kdepim (or so I heard). Where did you hear that? Mailody can not depend on kdepim and will not move into kdepim. > besides the licensing issue (where I think the pragmatic solution is not a > good idea, I would rather create a different toplevel module for that or > completely rip out code that cannot be relicensed), You miss the point that there is nobody that wishes to go ahead with the relicensing to LGPL. Why would *we* make an effort to make a library that can be used in closed source applications? If someone wants to make such an application, they have to invest time in the relicensing. It is a bit weird that for libs we require at least two applications, but we need to have it relicensened to LGPL because there might come a closed source application in the future that wants to use it. GPL is fine for all our needs and for some libraries it can even give the open source world an competitive advantage. > I would object unless BC/API has been reviewed We have extensive API reviews during the meetings, as soon as it is a lib we review it and make adjustments. Good example is the recent move from the dictionarycombobox to kdelibs, we decided that the complete api was a mess and rewritten the whole think to make sense again. (I.o.w.: you are right, we need to review the apis, as usual). Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
On Friday 07 November 2008, Allen Winter wrote: > > > > > > libkholidays could provide holiday info for calendar plasmoids perhaps we can split that part out into a LGPLed lib? > > > > > > libksieve could allow Mailody to implement IMAP sieve filters mailody can depend on kdepim, given that it will ultimatively merge or move into kdepim (or so I heard). > > > > > > kgantt would allow KOffice Gantt charts without having to use the > > > > > > current svn external etc. thats not a good reason. kdgantt being used via external also hides public API from BC concerns. > So updated plan: > - put the source into kdepimlibs/gpl. > - make sure the doxygen main pages say GPL on them > - clearly state in the kdepimlibs/README and kdepimlibs/POLICIES file > that there is GPL code in here > - install a _gpl suffix to the installed libs, i.e. libfoo_gpl.so besides the licensing issue (where I think the pragmatic solution is not a good idea, I would rather create a different toplevel module for that or completely rip out code that cannot be relicensed), I've also not seen a statement about the stability / API review of the affected libraries regarding maintainability and BC. > Unless there are objections, I'd like to go ahead with this new plan. I would object unless BC/API has been reviewed Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
On Friday 07 November 2008 4:35:31 pm Cyrille Berger wrote: > On Friday 07 November 2008, Allen Winter wrote: > > Unless there are objections, I'd like to go ahead with this new plan. > > Probably start moving stuff for next Monday. > > Just in case, KOffice/trunk/2.0 minimal requirement is 4.1.x so the > svn:external need to remain in place, but of course if kdepimlibs 4.2 is > found on the system it should use the kdgant_gpl from kdepimlibs. > toma and I decided we didn't have the time to make this happen for 4.2. So we shall try again for 4.3. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
On Friday 07 November 2008, Allen Winter wrote: > Unless there are objections, I'd like to go ahead with this new plan. > Probably start moving stuff for next Monday. Just in case, KOffice/trunk/2.0 minimal requirement is 4.1.x so the svn:external need to remain in place, but of course if kdepimlibs 4.2 is found on the system it should use the kdgant_gpl from kdepimlibs. -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
On Friday 07 November 2008 3:43:43 pm David Faure wrote: > On Friday 07 November 2008, Albert Astals Cid wrote: > > A Divendres 07 Novembre 2008, Tom Albers va escriure: > > > Op vrijdag 07 november 2008 00:50 schreef u: > > > > A Divendres 07 Novembre 2008, Allen Winter va escriure: > > > > > Howdy, > > > > > > > > > > Would it be possible to relax the licensing requirements in kdepimlibs > > > > > to permit GPL code? Currently, kdepimlibs requirements are the same as > > > > > kdelibs; i.e. only LGPL, BSD, X11. > > > > > > > > > > There are at least 4 GPL libraries in kdepim (libkholidays, libksieve, > > > > > kdgantt, libkleo) that would be very useful for kdebase, KOffice and > > > > > extragear. > > > > > > > > > > For example: > > > > > libkholidays could provide holiday info for calendar plasmoids > > > > > libksieve could allow Mailody to implement IMAP sieve filters > > > > > kgantt would allow KOffice Gantt charts without having to use the > > > > > current svn external etc. > > > > > > > > > > Attempts at relicensing these libraries has failed or is very > > > > > difficult. We have tried. > > > > > > > > > > I've been told that there was agreement at the last Akademy to allow > > > > > kdepimlibs to have GPL code?? If wasn't there so this is 3rd hand > > > > > info. > > > > > > > > > > I'd like an official answer. Or another suggestion. > > > > > > > > > > Comments? > > > > > > > > I'm not at all involved in kdepimlibs besides roaming const & fixes :D > > > > But this is my advice, if you are going to accept GPL libraries in > > > > kdepimlibs adding a _gpl suffix to them seems a good idea so people > > > > linking know they are linking to a GPL library. > > > > > > > > Albert > > > > > > dfaure pointed out that that would break bc... > > > > Why? Those libraries that would get the gpl suffix are not public at the > > moment, so there's no bc to maintain, right? > > Yeah I don't know the context. If no third party plugin/part/app relies on > these libs > then indeed there is no bc issue. > Come to think of it... yeah, why would 3rd party stuff try to link to kdepim libraries? I can't know for sure. But really they shouldn't be doing that. So updated plan: - put the source into kdepimlibs/gpl. - make sure the doxygen main pages say GPL on them - clearly state in the kdepimlibs/README and kdepimlibs/POLICIES file that there is GPL code in here - install a _gpl suffix to the installed libs, i.e. libfoo_gpl.so Unless there are objections, I'd like to go ahead with this new plan. Probably start moving stuff for next Monday. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
On Friday 07 November 2008, Albert Astals Cid wrote: > A Divendres 07 Novembre 2008, Tom Albers va escriure: > > Op vrijdag 07 november 2008 00:50 schreef u: > > > A Divendres 07 Novembre 2008, Allen Winter va escriure: > > > > Howdy, > > > > > > > > Would it be possible to relax the licensing requirements in kdepimlibs > > > > to permit GPL code? Currently, kdepimlibs requirements are the same as > > > > kdelibs; i.e. only LGPL, BSD, X11. > > > > > > > > There are at least 4 GPL libraries in kdepim (libkholidays, libksieve, > > > > kdgantt, libkleo) that would be very useful for kdebase, KOffice and > > > > extragear. > > > > > > > > For example: > > > > libkholidays could provide holiday info for calendar plasmoids > > > > libksieve could allow Mailody to implement IMAP sieve filters > > > > kgantt would allow KOffice Gantt charts without having to use the > > > > current svn external etc. > > > > > > > > Attempts at relicensing these libraries has failed or is very > > > > difficult. We have tried. > > > > > > > > I've been told that there was agreement at the last Akademy to allow > > > > kdepimlibs to have GPL code?? If wasn't there so this is 3rd hand info. > > > > > > > > I'd like an official answer. Or another suggestion. > > > > > > > > Comments? > > > > > > I'm not at all involved in kdepimlibs besides roaming const & fixes :D > > > But this is my advice, if you are going to accept GPL libraries in > > > kdepimlibs adding a _gpl suffix to them seems a good idea so people > > > linking know they are linking to a GPL library. > > > > > > Albert > > > > dfaure pointed out that that would break bc... > > Why? Those libraries that would get the gpl suffix are not public at the > moment, so there's no bc to maintain, right? Yeah I don't know the context. If no third party plugin/part/app relies on these libs then indeed there is no bc issue. -- David Faure, [EMAIL PROTECTED], sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
A Divendres 07 Novembre 2008, Tom Albers va escriure: > Op vrijdag 07 november 2008 00:50 schreef u: > > A Divendres 07 Novembre 2008, Allen Winter va escriure: > > > Howdy, > > > > > > Would it be possible to relax the licensing requirements in kdepimlibs > > > to permit GPL code? Currently, kdepimlibs requirements are the same as > > > kdelibs; i.e. only LGPL, BSD, X11. > > > > > > There are at least 4 GPL libraries in kdepim (libkholidays, libksieve, > > > kdgantt, libkleo) that would be very useful for kdebase, KOffice and > > > extragear. > > > > > > For example: > > > libkholidays could provide holiday info for calendar plasmoids > > > libksieve could allow Mailody to implement IMAP sieve filters > > > kgantt would allow KOffice Gantt charts without having to use the > > > current svn external etc. > > > > > > Attempts at relicensing these libraries has failed or is very > > > difficult. We have tried. > > > > > > I've been told that there was agreement at the last Akademy to allow > > > kdepimlibs to have GPL code?? If wasn't there so this is 3rd hand info. > > > > > > I'd like an official answer. Or another suggestion. > > > > > > Comments? > > > > I'm not at all involved in kdepimlibs besides roaming const & fixes :D > > But this is my advice, if you are going to accept GPL libraries in > > kdepimlibs adding a _gpl suffix to them seems a good idea so people > > linking know they are linking to a GPL library. > > > > Albert > > dfaure pointed out that that would break bc... Why? Those libraries that would get the gpl suffix are not public at the moment, so there's no bc to maintain, right? Albert > > Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
On Friday 07 November 2008, Allen Winter wrote: > > So the next best idea we have so far is: > > - put the source into kdepimlibs/gpl. > > - make sure the doxygen main pages say GPL on them > > - clearly state in the kdepimlibs/README and kdepimlibs/POLICIES file > >that there is GPL code in here All good ideas IMHO. > Another possibility is to create a new module called kdepimlibs-gpl > Reading back through the archives, I know that Ingo was a strong advocate of > this solution. And I'm strongly against it. * All our developers and users who compile from source will have to learn that they need yet another module, just for a stupid licensing issue they don't care about. * All documentation, release/snapshot scripts, build scripts, (and the setup of some services I think) etc. will need to be updated for yet another toplevel module. This is just making everyone's life more complicated for no good purpose, other than one that can easily be solved by having proper documentation. -- David Faure, [EMAIL PROTECTED], sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
On Friday 07 November 2008 10:46:49 am Allen Winter wrote: > On Friday 07 November 2008 6:26:35 am Tom Albers wrote: > > Op vrijdag 07 november 2008 00:50 schreef u: > > > A Divendres 07 Novembre 2008, Allen Winter va escriure: > > > > Howdy, > > > > > > > > Would it be possible to relax the licensing requirements in kdepimlibs > > > > to > > > > permit GPL code? Currently, kdepimlibs requirements are the same as > > > > kdelibs; i.e. only LGPL, BSD, X11. > > > > > > > > There are at least 4 GPL libraries in kdepim (libkholidays, libksieve, > > > > kdgantt, libkleo) that would be very useful for kdebase, KOffice and > > > > extragear. > > > > > > > > For example: > > > > libkholidays could provide holiday info for calendar plasmoids > > > > libksieve could allow Mailody to implement IMAP sieve filters > > > > kgantt would allow KOffice Gantt charts without having to use the > > > > current > > > > svn external etc. > > > > > > > > Attempts at relicensing these libraries has failed or is very difficult. > > > > We have tried. > > > > > > > > I've been told that there was agreement at the last Akademy to allow > > > > kdepimlibs to have GPL code?? If wasn't there so this is 3rd hand info. > > > > > > > > I'd like an official answer. Or another suggestion. > > > > > > > > Comments? > > > > > > I'm not at all involved in kdepimlibs besides roaming const & fixes :D > > > But > > > this is my advice, if you are going to accept GPL libraries in kdepimlibs > > > adding a _gpl suffix to them seems a good idea so people linking know > > > they > > > are linking to a GPL library. > > > > > > Albert > > > > dfaure pointed out that that would break bc... > > > Yep. > So the next best idea we have so far is: > - put the source into kdepimlibs/gpl. > - make sure the doxygen main pages say GPL on them > - clearly state in the kdepimlibs/README and kdepimlibs/POLICIES file >that there is GPL code in here > - ?? > Another possibility is to create a new module called kdepimlibs-gpl Reading back through the archives, I know that Ingo was a strong advocate of this solution. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
On Friday 07 November 2008 6:26:35 am Tom Albers wrote: > Op vrijdag 07 november 2008 00:50 schreef u: > > A Divendres 07 Novembre 2008, Allen Winter va escriure: > > > Howdy, > > > > > > Would it be possible to relax the licensing requirements in kdepimlibs to > > > permit GPL code? Currently, kdepimlibs requirements are the same as > > > kdelibs; i.e. only LGPL, BSD, X11. > > > > > > There are at least 4 GPL libraries in kdepim (libkholidays, libksieve, > > > kdgantt, libkleo) that would be very useful for kdebase, KOffice and > > > extragear. > > > > > > For example: > > > libkholidays could provide holiday info for calendar plasmoids > > > libksieve could allow Mailody to implement IMAP sieve filters > > > kgantt would allow KOffice Gantt charts without having to use the current > > > svn external etc. > > > > > > Attempts at relicensing these libraries has failed or is very difficult. > > > We have tried. > > > > > > I've been told that there was agreement at the last Akademy to allow > > > kdepimlibs to have GPL code?? If wasn't there so this is 3rd hand info. > > > > > > I'd like an official answer. Or another suggestion. > > > > > > Comments? > > > > I'm not at all involved in kdepimlibs besides roaming const & fixes :D But > > this is my advice, if you are going to accept GPL libraries in kdepimlibs > > adding a _gpl suffix to them seems a good idea so people linking know they > > are linking to a GPL library. > > > > Albert > > dfaure pointed out that that would break bc... > Yep. So the next best idea we have so far is: - put the source into kdepimlibs/gpl. - make sure the doxygen main pages say GPL on them - clearly state in the kdepimlibs/README and kdepimlibs/POLICIES file that there is GPL code in here - ?? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
Op vrijdag 07 november 2008 00:50 schreef u: > A Divendres 07 Novembre 2008, Allen Winter va escriure: > > Howdy, > > > > Would it be possible to relax the licensing requirements in kdepimlibs to > > permit GPL code? Currently, kdepimlibs requirements are the same as > > kdelibs; i.e. only LGPL, BSD, X11. > > > > There are at least 4 GPL libraries in kdepim (libkholidays, libksieve, > > kdgantt, libkleo) that would be very useful for kdebase, KOffice and > > extragear. > > > > For example: > > libkholidays could provide holiday info for calendar plasmoids > > libksieve could allow Mailody to implement IMAP sieve filters > > kgantt would allow KOffice Gantt charts without having to use the current > > svn external etc. > > > > Attempts at relicensing these libraries has failed or is very difficult. > > We have tried. > > > > I've been told that there was agreement at the last Akademy to allow > > kdepimlibs to have GPL code?? If wasn't there so this is 3rd hand info. > > > > I'd like an official answer. Or another suggestion. > > > > Comments? > > I'm not at all involved in kdepimlibs besides roaming const & fixes :D But > this is my advice, if you are going to accept GPL libraries in kdepimlibs > adding a _gpl suffix to them seems a good idea so people linking know they > are linking to a GPL library. > > Albert dfaure pointed out that that would break bc... Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepimlibs Licensing
A Divendres 07 Novembre 2008, Allen Winter va escriure: > Howdy, > > Would it be possible to relax the licensing requirements in kdepimlibs to > permit GPL code? Currently, kdepimlibs requirements are the same as > kdelibs; i.e. only LGPL, BSD, X11. > > There are at least 4 GPL libraries in kdepim (libkholidays, libksieve, > kdgantt, libkleo) that would be very useful for kdebase, KOffice and > extragear. > > For example: > libkholidays could provide holiday info for calendar plasmoids > libksieve could allow Mailody to implement IMAP sieve filters > kgantt would allow KOffice Gantt charts without having to use the current > svn external etc. > > Attempts at relicensing these libraries has failed or is very difficult. > We have tried. > > I've been told that there was agreement at the last Akademy to allow > kdepimlibs to have GPL code?? If wasn't there so this is 3rd hand info. > > I'd like an official answer. Or another suggestion. > > Comments? I'm not at all involved in kdepimlibs besides roaming const & fixes :D But this is my advice, if you are going to accept GPL libraries in kdepimlibs adding a _gpl suffix to them seems a good idea so people linking know they are linking to a GPL library. Albert > -Allen > > > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
kdepimlibs Licensing
Howdy, Would it be possible to relax the licensing requirements in kdepimlibs to permit GPL code? Currently, kdepimlibs requirements are the same as kdelibs; i.e. only LGPL, BSD, X11. There are at least 4 GPL libraries in kdepim (libkholidays, libksieve, kdgantt, libkleo) that would be very useful for kdebase, KOffice and extragear. For example: libkholidays could provide holiday info for calendar plasmoids libksieve could allow Mailody to implement IMAP sieve filters kgantt would allow KOffice Gantt charts without having to use the current svn external etc. Attempts at relicensing these libraries has failed or is very difficult. We have tried. I've been told that there was agreement at the last Akademy to allow kdepimlibs to have GPL code?? If wasn't there so this is 3rd hand info. I'd like an official answer. Or another suggestion. Comments? -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
