Baloo Framework - License Exception

[Kevin Ottens]

Hello,

I've been summoned by CCing, loose all hope! :-)

On Sunday 04 January 2015 11:23:49 David Faure wrote:
> On Tuesday 16 December 2014 14:02:18 Sebastian Kügler wrote:
> > - If it's effectively GPL-licensed, it should not be a proper Framework
> 
> I would like to challenge this reasoning.
> 
> It seems to me that the premise is:
> * we need baloo
> * baloo currently needs Xapian
> * Xapian is GPL
> * the architecture we have now is that libraries coming from the KDE
> community are released together as KDE Frameworks, with an effort (greater
> than before) on making these libraries useful and useable outside the KDE
> community. (BTW that effort is bearing fruit, I'm visiting a company in 2
> weeks who is going to use KIO in an embedded-linux product)
> 
> From these facts, a reasonable (IMHO) conclusion is that:
> * we can release baloo as a framework, as long as we indicate clearly in its
> documentation that baloo is "effectively GPL" due to Xapian.

That's assuming people will look for those details. I'm unsure they will.

> Let me try to make a pro/con list...
> 
> Releasing baloo as a framework:
> + gives it an automatic and painfree release schedule
> + simplifies version numbering ("KMyApp depends on KF 5.7" rather than
> "KMyApp depends on baloo 1.2 and KF 5.7")
> + makes it more consistent with the other frameworks (*apart* from the
> license), in terms of everything (naming, installed files, qmake support,
> etc.). This can be done in "baloo as a separate library" too (in fact that's
> the current situation), but then what do we have? It looks like a
> framework, it smells like a framework, it quacks like a framework, but it's
> released separately? That's a distinction that will not even appear to
> users (app developers).

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.

> Not releasing baloo as a framework:
> + makes it simpler to say "all frameworks can be used under the LGPL"

And for the sake of KDE Frameworks as a product that's IMHO a very important 
point. Allowing exceptions is a slippery slope.

> Are we going to shoot ourselves in the foot (= making our lives more
> complicated, by having a dependency that works differently from the other
> dependencies and has to be released separately) just so that we can say "all
> frameworks are LGPL" ?

Yes? :)

Beside I don't think it's shooting ourselves in the foot at all or making our 
lives that complicated.

> Finally, note that releasing baloo as a framework doesn't contradict
> https://techbase.kde.org/Policies/Licensing_Policy, which says the source
> files [of baloo] should be LGPL. They are. It's Xapian that isn't.

It's a bit unexpected though. :-)

> (What we should avoid is to use baloo from other frameworks, but that's a
> fact whether or not baloo itself is a framework or a separate lib.)

Again that's a slippery slope, we can try to avoid it as much as possible, but 
really it'll likely happen at a few places, or via plugins. People find ways.

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.

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/d2e2072f/attachment.sig>