MPL2 instead of LGPL

[Hörmetjan Yiltiz]

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 <sandroandrade at kde.org>
wrote:

> On Wed, Aug 19, 2020 at 2:27 PM Roman Gilg <subdiff at gmail.com> wrote:
> >
> > On Wed, Aug 19, 2020 at 6:01 PM Sandro Andrade <sandroandrade at kde.org>
> wrote:
> > >
> > > On Sun, Aug 16, 2020 at 5:11 AM Roman Gilg <subdiff at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20200819/c4e33905/attachment.htm>