May I try to point out the elephant in the room? Most KDE applications and libraries are copyleft, with tremendous effort and contributions from a wide range of people. Since most of them belong to more than one author, it is not possible for a maintainer to simply re-licence an existing piece of software from copyleft to permissive style license; that requires getting all previous contributors on board and getting their explicit permission. However, if anyone is working on a new project based solely on permissive style licenses, the developer(s) are free to also release their new project in a permissive style license. I hope I did not digress. Best, Hörmet ======================== He who is worthy to receive his days and nights is worthy to receive all else from you (and me). -- The Prophet, Gibran Kahlil
On Wed, Aug 19, 2020 at 3:24 PM Sandro Andrade <sandroandr...@kde.org> wrote: > On Wed, Aug 19, 2020 at 2:27 PM Roman Gilg <subd...@gmail.com> wrote: > > > > On Wed, Aug 19, 2020 at 6:01 PM Sandro Andrade <sandroandr...@kde.org> > wrote: > > > > > > On Sun, Aug 16, 2020 at 5:11 AM Roman Gilg <subd...@gmail.com> wrote: > > > > > > > > Hi, > > > > > > Hi Roman, > > > > > > > * Proprietary code static linking LGPL code is not practically > doable. > > > > [5] See also above ZeroMQ exception. > > > > > > This is a topic every now and then pops around when discussing > > > licensing issues. The FSF is pretty clear in stating the providing > > > object files are enough to enable users to relink with different > > > versions of the LGPL library. I see some projects using LGPL + static > > > linking exceptions and I've read all the things regarding "work based > > > on the library" vs "work which uses the library", header dependencies, > > > and so on but such LGPL exceptions look more like a clarification > > > point than a thing not already covered by LGPL. > > > > > > I really don't see the point of comments like "If you statically link > > > a LGPL library, then the application itself must be LGPL. We have had > > > our lawyer double-check on this in the past. Dynamically linking to a > > > LGPL library is the only way to avoid becoming LGPL", presented in the > > > stackoverflow link [5] you provided. > > > > > > Could you elaborate a bit why this is not practically doable or > > > legally incorrect? > > > > Hi Sandro, > > > > no I can't. I was just rephrasing what I read in some sources online > > and asking here for educated opinions on if this interpretation is > > right or wrong. Thanks for taking the time to "debunk" some of the > > myths floating around. > > > > Do you see it the same way in regards to the usage of templates in C++ > > libraries licensed under the LGPL? Is this also a "non-issue" in the > > end? > > AFAIK, and with all due IANAL disclaimer, this has been specifically > addressed at Section 3 (Object Code Incorporating Material from > Library Header Files) of LGPLv3. For LGPLv2'ed applications, expanding > inline functions and templates inside an application's object would > render LGPLv2 equivalent to the GPL. As stated in LGPLv3, even if the > application's object incorporate header elements which "are not > limited to numerical parameters, data structure layouts and accessors, > or small macros, inline functions and templates (ten or fewer lines in > length)" you may convey such object code under terms of your choice as > long as: > > " > a) Give prominent notice with each copy of the object code that the > Library is used in it and that the Library and its use are covered by > this License. > b) Accompany the object code with a copy of the GNU GPL and this > license (LGPLv3) document. > " > > Cheers, > Sandro > > > > > > Cheers, > > > Sandro >