Baloo Framework - License Exception
ervin at kde.org
Tue Jan 6 17:47:35 UTC 2015
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.
> > 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
> 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.
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part.
More information about the Kde-frameworks-devel