Baloo Framework - License Exception

Ivan Čukić ivan.cukic at kde.org
Mon Dec 15 09:11:30 UTC 2014


> not. If there is baloo internal an abstraction allowing to easily

> swap out Xapian by something different I would say it's not

> derived work. But if Xapian is deeply wired into Baloo I would say

> it's derived work.


>From "Why you shouldn't use the Lesser GPL for your next library", a
document talking about why new libraries should use GPL instead of LGPL [1]:


> Proprietary software developers have the advantage of money;

> free software developers need to make advantages for each other.

> Using the ordinary GPL for a library gives free software developers

> an advantage over proprietary developers: a library that they can

> use, while proprietary developers cannot use it.


In this case, I think that anything non-GPL is 'proprietary' in the eyes of
GPL.


Otherwise, you'd always be able to wrap GPL code via abstraction (claiming
that it is a generic wrapper, and that the undrlying code is not important)
into LGPL library, and use it in non-free software.


Albert's idea that Baloo can be LGPL, and only when distributed becomes GPL
might be possible to pull off, but I do not think it makes any difference
for baloo clients. Distributing Baloo with would make it GPL, and further,
anyone who uses libbaloo would need to distribute the code under GPL.


The point of KF5 is to be LGPL because non-free programs ought to be able
to use them, not because we like writing the word Lesser in the comment
header. :)


Cheers,

Ivan


[1] https://www.gnu.org/philosophy/why-not-lgpl.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20141215/00e99d59/attachment.html>


More information about the Kde-frameworks-devel mailing list