Baloo Framework - License Exception

[Kevin Ottens]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150106/b9b795aa/attachment.sig>