Re: MPL2 instead of LGPL
Hello, > On 20. Aug 2020, at 01:25, Hörmetjan Yiltiz wrote: > > 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. No, you did not. This is a fair and probably the crucial point when discussing a license change: How can you get agreement from all relevant contributors? There are two hurdles in that process: a) getting everybody to agree that License X is the choice of the future, and then b) getting everybody down to the last person to sign off on it. The limitations and the age of the (L)GPL are clearly showing. I agree with Martin that the technical intricacies usually get lost in legal assessments or courts. The difference between states and dynamic linking is also blurry. When I teach licensing, I teach intent: “You can use my code even in proprietary applications, but if you have modifications to my code, you should publish them under the same license.” This is very close to the understanding in the legal discussions, and disconnected from the technical details the nerds (me included) usually focus on. Best, MIrko.
Re: MPL2 instead of LGPL
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 wrote: > On Wed, Aug 19, 2020 at 2:27 PM Roman Gilg wrote: > > > > On Wed, Aug 19, 2020 at 6:01 PM Sandro Andrade > wrote: > > > > > > On Sun, Aug 16, 2020 at 5:11 AM Roman Gilg 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 >
Re: MPL2 instead of LGPL
On Wed, Aug 19, 2020 at 2:27 PM Roman Gilg wrote: > > On Wed, Aug 19, 2020 at 6:01 PM Sandro Andrade wrote: > > > > On Sun, Aug 16, 2020 at 5:11 AM Roman Gilg 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
Re: MPL2 instead of LGPL
Am 19. August 2020 19:27:09 MESZ schrieb Roman Gilg : On Wed, Aug 19, 2020 at 6:01 PM Sandro Andrade wrote: On Sun, Aug 16, 2020 at 5:11 AM Roman Gilg 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? I think all of this is pretty much a non issue. You are looking at this from the position of an engineer. But licenses are legal-speech and would be interpreted by a judge. Most likely a judge does not have the technical knowledge to understand the differences. It is very unlikely that a judge would understand the implications of different linker flags (static vs. dynamic linking). Anybody without a high technical background won't understand that. What matters more is the intention of the license. And that is clear. It's the "lesser" gpl. And it would be interpreted like that. The (l)gpl was written with C in mind. Adapting it to other languages is difficult for us, but probably not for a legal person. A template library is a library. That it is kind of static linking is an implementation detail. And here the intention matters: if one would have wanted the gpl restrictions one would choose gpl as license. But using lgpl clearly states that one doesn't want the gpl restrictions to hold. Granted all of that has not been tested in a court. Thus if one wants to be clear it might make sense to dual license or use class path exceptions, etc. But for our frameworks it's a non issue as we always stated the intention: allow users of Qt's commercial license to use our libraries. If a copyright holder would turn into a McHardy he would hopefully lose at court, especially if we as the community would contradict the claims. Cheers and IANAL Martin
Re: MPL2 instead of LGPL
On Wed, Aug 19, 2020 at 6:01 PM Sandro Andrade wrote: > > On Sun, Aug 16, 2020 at 5:11 AM Roman Gilg 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? > Cheers, > Sandro
Re: MPL2 instead of LGPL
On Mon, Aug 17, 2020 at 6:32 PM Christoph Cullmann wrote: > > On 2020-08-17 17:47, Ivan Čukić wrote: > >> > I've read now multiple times about projects replacing their use of > >> > LGPLv3 [1] with MPL2 [2]. I would be interested in what people in the > >> > KDE community think about that. > > > > Maybe an alternative to MPL could be these: > > 1) GPL with runtime exception (if GCC's standard library can use it, I > > guess > > we can as well) > > https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html > > 2) Boost license as it is also created for a set of template-heavy C++ > > libraries > > > >> If one wants to write a modern C++ library that makes heavy use of > >> templates in the API and which proprietary consumers should be able to > >> use is this clause alone reason to prefer the MPL2 over the LGPL or is > >> my concern unfounded? > > > > Now, if you don't want to sue anyone, the "10 lines" thing is not a > > problem. > > :) > > > > You can ask around people that have C++ libraries published under LGPL > > if they had clients confused about the licensing. There is quote a lot > > of FUD > > about (L)GPL often created by companies with dual-licensing models (not > > gonna > > mention any names here) so I could see a company being afraid of using > > an LGPL > > library. But, on the other hand, if you clearly explain what LGPL means > > in the > > context of your library, I'd say LGPL will not be a problem. > Hi, > > for KSyntaxHighlighting we did choose to go with MIT licensing instead > of LGPLvX. > > That allows all kind of integration for proprietary software, > but will allow people to keep their changes, too, > which might be not what all people like. Hi Christoph, I don't want to go full permissive license. I haven't looked in depth on the technical, economical and social impact of permissive vs copyleft licenses but I feel that permissive licenses give too much away. In this regard for a personal journey and practical take on it (that at the end becomes suddenly intensely political though) I like an old blog post of Drew about MIT vs GPL at [1]. But it depends on the project size and what kind of integration is planned for sure. So I can follow you on why you chose MIT for KSyntaxHighlighting and I think showing flexibility in licensing questions is recommendable. >From the stuff I read it just feels the MPL2 could be a good middle ground between permissive and copyleft [2]. I'm just wondering why it's not used more often. That could be just momentum though. [1] https://drewdevault.com/2019/06/13/My-journey-from-MIT-to-GPL.html [2] http://veldstra.org/2016/12/09/you-should-choose-mpl2-for-your-opensource-project.html > Greetings > Christoph > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org
Re: MPL2 instead of LGPL
On 2020-08-17 17:47, Ivan Čukić wrote: > I've read now multiple times about projects replacing their use of > LGPLv3 [1] with MPL2 [2]. I would be interested in what people in the > KDE community think about that. Maybe an alternative to MPL could be these: 1) GPL with runtime exception (if GCC's standard library can use it, I guess we can as well) https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html 2) Boost license as it is also created for a set of template-heavy C++ libraries If one wants to write a modern C++ library that makes heavy use of templates in the API and which proprietary consumers should be able to use is this clause alone reason to prefer the MPL2 over the LGPL or is my concern unfounded? Now, if you don't want to sue anyone, the "10 lines" thing is not a problem. :) You can ask around people that have C++ libraries published under LGPL if they had clients confused about the licensing. There is quote a lot of FUD about (L)GPL often created by companies with dual-licensing models (not gonna mention any names here) so I could see a company being afraid of using an LGPL library. But, on the other hand, if you clearly explain what LGPL means in the context of your library, I'd say LGPL will not be a problem. Hi, for KSyntaxHighlighting we did choose to go with MIT licensing instead of LGPLvX. That allows all kind of integration for proprietary software, but will allow people to keep their changes, too, which might be not what all people like. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: MPL2 instead of LGPL
> > I've read now multiple times about projects replacing their use of > > LGPLv3 [1] with MPL2 [2]. I would be interested in what people in the > > KDE community think about that. Maybe an alternative to MPL could be these: 1) GPL with runtime exception (if GCC's standard library can use it, I guess we can as well) https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html 2) Boost license as it is also created for a set of template-heavy C++ libraries > If one wants to write a modern C++ library that makes heavy use of > templates in the API and which proprietary consumers should be able to > use is this clause alone reason to prefer the MPL2 over the LGPL or is > my concern unfounded? Now, if you don't want to sue anyone, the "10 lines" thing is not a problem. :) You can ask around people that have C++ libraries published under LGPL if they had clients confused about the licensing. There is quote a lot of FUD about (L)GPL often created by companies with dual-licensing models (not gonna mention any names here) so I could see a company being afraid of using an LGPL library. But, on the other hand, if you clearly explain what LGPL means in the context of your library, I'd say LGPL will not be a problem. Cheers, Ivan -- dr Ivan Čukić i...@cukic.co, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
Re: MPL2 instead of LGPL
On Sun, Aug 16, 2020 at 10:10 AM Roman Gilg wrote: > > Hi, > > I've read now multiple times about projects replacing their use of > LGPLv3 [1] with MPL2 [2]. I would be interested in what people in the > KDE community think about that. > > Examples of such projects are: > * http://wiki.zeromq.org/area:licensing - LGPL v3 with special > exception for static linking (why do KDE frameworks not need this?) > * http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ - was > GPL2/LGPL3 dual licensed > > The disadvantages of LGPL are to my knowledge: > * LGPLv3 code not copyable to GPL code. [3] > * Usage of C++ templates licensed under LGPLv2.1 not possible or grey > area(?) in proprietary code. [4] That template weirdness is what worries me the most btw. I want to use static inheritance in libraries I write more often in the future and LGPLv3 has a weird and arbitrary "up to 10 lines are allowed" clause in it. If one wants to write a modern C++ library that makes heavy use of templates in the API and which proprietary consumers should be able to use is this clause alone reason to prefer the MPL2 over the LGPL or is my concern unfounded? > * Proprietary code static linking LGPL code is not practically doable. > [5] See also above ZeroMQ exception. > > Now one would think with KDE Frameworks double-licensed under LGPLv2.2 > and LGPLv3 at least the first and second disadvantages are eliminated. > But then why did Eigen not make use of this? And what about the static > linking exception? Is this not relevant to KDE Frameworks? And what > other important advantages/disadvantages of LGPL in comparison to MPL2 > are there? > > Best > Roman > > [1] https://www.gnu.org/licenses/lgpl-3.0.html > [2] https://www.mozilla.org/en-US/MPL/2.0/FAQ/ > [3] https://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibility > [4] > http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ=1117#But_doesn.27t_the_LGPL_have_issues_with_code_that_is_in_header_files.2C_and_template_libraries.3F > [5] https://stackoverflow.com/q/10130143
MPL2 instead of LGPL
Hi, I've read now multiple times about projects replacing their use of LGPLv3 [1] with MPL2 [2]. I would be interested in what people in the KDE community think about that. Examples of such projects are: * http://wiki.zeromq.org/area:licensing - LGPL v3 with special exception for static linking (why do KDE frameworks not need this?) * http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ - was GPL2/LGPL3 dual licensed The disadvantages of LGPL are to my knowledge: * LGPLv3 code not copyable to GPL code. [3] * Usage of C++ templates licensed under LGPLv2.1 not possible or grey area(?) in proprietary code. [4] * Proprietary code static linking LGPL code is not practically doable. [5] See also above ZeroMQ exception. Now one would think with KDE Frameworks double-licensed under LGPLv2.2 and LGPLv3 at least the first and second disadvantages are eliminated. But then why did Eigen not make use of this? And what about the static linking exception? Is this not relevant to KDE Frameworks? And what other important advantages/disadvantages of LGPL in comparison to MPL2 are there? Best Roman [1] https://www.gnu.org/licenses/lgpl-3.0.html [2] https://www.mozilla.org/en-US/MPL/2.0/FAQ/ [3] https://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibility [4] http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ=1117#But_doesn.27t_the_LGPL_have_issues_with_code_that_is_in_header_files.2C_and_template_libraries.3F [5] https://stackoverflow.com/q/10130143
