Re: MPL2 instead of LGPL

[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?

> Cheers,
> Sandro

Re: MPL2 instead of LGPL

[Roman Gilg]

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

[Roman Gilg]

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

[Roman Gilg]

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

Contributor training feedback data

[Roman Gilg]

Hi,

last Akademy there were some contributor trainings going on. And
afterwards there was a poll on how people liked it.

It this poll data available somewhere? And what trainings are planned
for Akademy 2019?

Thanks in advance.

Roman

Re: Replacement of KDE Identity

[Roman Gilg]

For the future a KDE owned online service for users to backup and sync
their KDE Apps / Plasma Workspace settings on multiple devices through
this new online identity system would be nice. Not sure how this
affects the requirements of this identity system.

Cheers,
Roman

On Fri, Apr 6, 2018 at 12:25 PM, Ben Cooksley  wrote:
> Hi all,
>
> For sometime now it has been becoming increasingly apparent that our
> existing system for universal login, KDE Identity, has been reaching
> the end of it's life.
>
> Replacing it however is no easy feat, and unfortunately no existing
> solution is able to meet our requirements. To that end we've now
> published a task detailing what is required of a replacement to KDE
> Identity (https://phabricator.kde.org/T8449)
>
> Should anyone be interested (or know anyone who could potentially be
> interested) in working on this, it would be appreciated if you could
> please contact us.
>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Re: List for job offers

[Roman Gilg]

If this is not the right list for such offers, is there then another
mailing list or some other place in KDE for it? If not, would it be a
good idea to create such a place?

On Mon, Feb 19, 2018 at 3:12 PM, Aleix Pol <aleix...@kde.org> wrote:
> On Sun, Feb 18, 2018 at 9:54 PM, Albert Astals Cid <aa...@kde.org> wrote:
>> El diumenge, 18 de febrer de 2018, a les 21:01:40 CET, Nicolás Alvarez va
>> escriure:
>>> 2018-02-18 9:57 GMT-03:00 Roman Gilg <subd...@gmail.com>:
>>> > I received last week a job offer for a project involving
>>> > C++/Linux/Qt/QML via LinkedIn. I told the headhunter to write a mail
>>> > to the kde-community list so other people in our community who are
>>> > currently looking for such an opportunity could apply.
>>> >
>>> > He said that he sent a mail, but I didn't spot it in the list. Was the
>>> > mail maybe rejected by the list admin because such job offers are not
>>> > allowed on the kde-community list?
>>>
>>> The message is still in the moderation queue, it has been neither
>>> accepted nor rejected. Sometimes I login with the global-admin
>>> password and reject obvious spam, but since I don't know if this is
>>> allowed or not, I left that message untouched for the actual
>>> moderators to decide.
>>>
>>> But considering it has been queued for a week or two, maybe I should
>>> just accept it, and if it's not welcome, people can complain later :)
>>
>> Honestly, unless it's "KDE related" personally i don't see what a random job
>> offer for a C++/Qt developer has to do with this list.
>
> +1, my thoughts exactly.

List for job offers

[Roman Gilg]

Hi,

I received last week a job offer for a project involving
C++/Linux/Qt/QML via LinkedIn. I told the headhunter to write a mail
to the kde-community list so other people in our community who are
currently looking for such an opportunity could apply.

He said that he sent a mail, but I didn't spot it in the list. Was the
mail maybe rejected by the list admin because such job offers are not
allowed on the kde-community list?

If they are not allowed, do we have another spot for such offers to be
communicated to the KDE community? Would it make sense to have a
separate mailing list to facilitate such agency between community
members and companies?

Cheers
Roman

Re: Status of Wayland implementation on nVidia graphics cards

[Roman Gilg]

Hi Christian,

you find a log in "~/.local/share/sddm/wayland-session.log".

After your session doesn't react anymore reboot and log into X session,
where you can read the log out then (in X session it will log to "~/
.local/share/sddm/xorg-session.log").

Before asking again for help you may find a solution already by looking at
the log yourself. I suspect an update of kernel or mesa might already help
you. Also make sure you're using the HWE stack of Ubuntu 16.04 with updated
X.Org.

When this helps, please let us know. When this doesn't help feel free to
ask again in a reply (with the log attached).

Cheers,
Roman


On Thu, Sep 21, 2017 at 11:45 PM, Christian Ohrfandl <
christian.ohrfa...@gmail.com> wrote:

> Hello Martin,
>
> thank you for the link and the quick reply!
>
> I definitely use Nouveau:
>
> lspci -k | grep -EA3 'VGA|3D|Display'
>
> 01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX
> 760] (rev a1)
> Subsystem: Micro-Star International Co., Ltd. [MSI] GK104 [GeForce GTX 760]
> Kernel driver in use: nouveau
> Kernel modules: nvidiafb, nouveau
>
> When choosing the wayland session and logging in, only black background
> (on the other monitor the chosen wallpaper and some desktop icons) and a
> bigger cursor loads (c.f. attached picture); no interaction with system
> possible (tried this several times; sometimes the background one the other
> monitor does not even load). I have made a video I could share with you, if
> you want to...
>
> Are there any logs I may view in order to resolve the issue after turning
> the PC off and on again? Shall I file a bug report?
>
>
> Cheers,
> Christian
>
>
>
> On 9/21/17 5:20 PM, Martin Flöser wrote:
>
>> Am 2017-09-20 20:22, schrieb Christian Ohrfandl:
>>
>>> Dear KDE community,
>>>
>>> I just installed KDE Neon Git unstable from September 19th 2017 on may
>>> main computer. I want to use Wayland (because of testing and
>>> submitting potential bug reports), but I can't (after user login,
>>> screen is black with a big cursor, but I can not interact with the
>>> session; most probably because of my nVidia Geforce 760 graphics
>>> card).
>>>
>>> Therfore, I want to ask how mature Wayland/nVidia implementation is?
>>> Does it work in general? If so, which driver (nouveau or proprietary)?
>>> Is there a (bug)tracker?
>>>
>>
>> NVIDIA has an own implementation (EGLStreams) which we do not support and
>> do not plan to support (more information in my blog at [1]).
>>
>> Nouveau should work, though I haven't tested it yet.
>>
>> Cheers,
>> Martin
>>
>> [1] https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/
>>
>