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
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
