On Tuesday 06 January 2015 11:01:19 David Faure wrote: > Well, that's interesting, I didn't expect you would reply that :-)
You probably picture me as wanting KF to grow wide and large as much as possible. That'd be wrong. I actually have this concern that we might reach a point of "too much stuff in there". > > That's assuming people will look for those details. I'm unsure they will. > > My suggestion is to make this fact as pro-eminent as possible. > > If the framework code itself was GPL, I would advocate calling the framework > baloo-gpl. I think this should appease fears of the "slippery slope", > because if one day we want to have a real GPL framework, we can make it > part of the name everywhere (not just the git repo, but really everywhere, > cmake targets etc.) Let's not violate our own licensing policy for a start. ;-) > With baloo it's a bit more tricky, since it's only "effectively GPL" and we > surely want to keep the possibility to make it really LGPL. > Still, I'm sure we can plaster the documentation, README, header files etc. > with "this code is GPL!!!". > > You know, the same issue exists even if it's not released as part of KF5. > On most distros it will be "just another package" whichever way we release > it on our side. > https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable-daily has > attica-kf5 and baloo-kf5. From there you can't really tell that it's not a > framework, or that it's not LGPL... Sure, but it's not our responsibility then. :-) > But what will people do as soon as they > start using a lib and writing code that uses it? Opening the api docs. So > let's make it very clear there. This is needed, whether or not baloo is > released with KF5 or separately. Agreed. > > KDE app developers, not third parties... which actually begs the question: > > does Baloo provide any value outside of the KDE community? if not there's > > no rush to put it in KF5 as sebas highlighted. > > The problem (and the reason I talk about shooting ourselves in the foot) is > ... what do we do instead, then, to solve the KDE issue? > We need to be able to use baloo in both "KDE Workspace" and "KDE > applications", which are released separately and cannot depend on each > other. > > In fact, this is just like the portingAids subdir of the frameworks > releases. It's stuff that we release "as part of frameworks" but that is > not intended for the outside world (= outside the KDE community). Yep, it smells a lot like it indeed. > Can we have a similar section for "GPL" frameworks? > I completely agree that the goal is to "hide" it from the outside world, but > we still need to release it so that we can use it, for our own purposes. I wouldn't draw the line on the license to be honest. It's "stuff we keep for ourselves for whatever reason, be warned!". It's "private" to the community. > > Bottom line: since there's the possibility of a non-xapian backend making > > Baloo effectively LGPL and not effectively GPL, I'd be in favor of waiting > > for it to be reality. > > We need a much shorter term solution than that, for practical purposes. And that bothers me to be honest... How come suddenly it *has* to be part of KF? Especially when it is said that a) there's a license problem because of Xapian and b) we have other problems because of Xapian so we'll switch and it will be a larger change. IOW: If it's not ready... it's not ready. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel