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
Re: Feedback on new feature: energy performance settings
On Wed, Aug 12, 2020 at 7:52 PM John Salatas wrote: > It would be good to have a confirmation from more users, before deciding > whether we will expose the governor settings in the GUI or not. # AMD Ryzen 7 4800H (acpi-cpufreq): schedutil/ondemand/conservative: idle at minimum configured frequency, scales up to maximum freq when running `stress -c 16` performance: strangely seems to behave more or less exactly like the scaling governors, might well be a bug in my kernel version as the documentation says it should run at cap. powersave: always at minimum frequency since lower frequency also means lower wattage powersave saves power by keeping the frequency at the lowest configured value (which on this system is 1.4ghz; maximum is 2.9 with boost at 3.0-3.2 or so). 2.2W with screen on standby but wifi on. using schedutil and running stress on all cores for about 5 minutes the discharge rate is at 33W with frequency being at cap + boosted and the fan running like crazy. using powersave and the same stress scenario the discharge rate is at 10W with frequency being locked at configured minimum. # ARM Cortex-A72 on rpi4 (cpufreq-dt): same as ryzen except performance behaves as expected and keeps the cores at the maximum frequency (i.e. as would be expected from kernel docs) # ARM Cortex-A9 MPCore (cpufreq-dt): only seeing performance and schedutil as available governors. behave same as the A72 HTH HS
