GTK3 is now the default widgetset on Linux

[zeljko]

Hello everyone,

I would like to inform you that the default Linux widgetset in Lazarus trunk has been changed from GTK2 to GTK3.
GTK2 has served Lazarus extremely well for many years, but it has reached the point where it is no longer a practical default choice. It is no longer actively maintained, modern Linux distributions are gradually removing it from their repositories, and it lacks support for today's desktop technologies such as Wayland.

GTK3 is now mature, stable, and well tested in Lazarus. Making it the default Linux widgetset is an important step towards Lazarus 5.0 and ensures that new users get the best out-of-the-box experience on current Linux distributions.

What this means:

* New Lazarus builds on Linux will use GTK3 by default.
* Existing GTK2 applications can still be built by explicitly selecting the GTK2 widgetset, provided the required GTK2 development libraries are installed.
* Users are encouraged to test their applications with GTK3 and report any remaining issues.

This change would not have been possible without years of testing, bug reports, patches, and feedback from many members of the Lazarus community. Thank you to everyone who helped improve the GTK3 widgetset over the years. Although GTK2 is no longer the default,
it is not being removed at this time. It will remain available for users who still depend on it while they migrate their applications.

Please continue reporting GTK3-specific issues in the bug tracker so we can further improve the experience before the Lazarus 5.0 release.

Thank you for your continued support of Lazarus.

Best regards,

Željan Rikalo
Lazarus Team

[marcov]

Why GTK3, and not some QT ?

[zeljko]

1. gtk3 is trully open source and qt is not - owned by company.
2. Ppl already complained that qt is not good choice because of C bindings library.
3. We can switch to qt6 at some point - not up to me, I even use qt for my work.

[Thaddy]

@zeljko

All the right reasons. Thanks.
Although I mostly use Qt6, GTK3 is a better choice to avoid licensing issues when using Qt6 professionally.
I might add:
4. protecting the average Lazarus user from running into licensing issues when they distribute their application in binary form only. (and becomes a success!!)

GTK (any) is LGPL'd:
https://www.gnu.org/licenses/lgpl-3.0.html#license-text
In practice, that means that you mention its use somewhere in your documentation or about box and point to or include the LGPL license..(Even Microsoft, Oracle, Google, do this)
You are not required to reveal any sourcecode.

@Marcov
Not many Qt users actually read their license requirements:
https://www.qt.io/development/qt-framework/qt-licensing
Note there that several Qt components from Qt itself, not Lazarus, are - when unlicensed - GPL, not LGPL. GPL is very restrictive and needs all sourcecode to be publicly available and that includes third-party sourcecode that is used which may have a different license.....
(Blame Richard Stallman)

Publicly available doesn't mean available for free: GPL allows to ask a fee, but when requested and the fee is payed all sourcecode must be revealed. This is a excruciatingly common misunderstanding about GPL.
(Blame Richard Stallman again)

[robert rozee]

(this may not be the right place to pose this question, i am putting it here simply because this is the thread from which half of the material i am asking about originated; a moderator may feel that the question should be moved to a more appropriate location on the forums)

Thaddy writes:

[...] LGPL'd:
https://www.gnu.org/licenses/lgpl-3.0.html#license-text
In practice, that means that you mention its use somewhere in your documentation or about box and point to or include the LGPL license..(Even Microsoft, Oracle, Google, do this)
You are not required to reveal any sourcecode.

while PascalDragon wrote in another thread:

[..]  being licensed as LGPL, this prohibits [...] use with a proprietary, closed source application (at least if you want to distribute it as a precompiled binary).

see portions above marked out in bold red.

i am trying to reconcile these two accounts of the LGPL as it applies to the case of: i have an application written by myself in Pascal that incorporates a chunk of source code that the original author (of said chunk) has released under the LGPL, where i am releasing an ELF binary of my application, and may (or may not) also be releasing a complete set of source code such that said set of source code can be built into a functionally equivalent ELF binary using Lazarus+FPC.


in other words, who is right in their interpretation of the LGPL: Thaddy or PascalDragon?  or both, or neither?!


cheers,
rob   :-)

[Thaddy]

In this case PascalDragon made a typo mistake and that can be derived from what he intended to write.
You can check my answer - in full please, no excerpts - against any other reliable source including AI driven ones..
Three remarks that I was not quite clear in:
- regarding GPL: technically you can only charge for the distribution medium, not for the sourcecode itself, but that includes a charge for over the line distribution (the act itself is not specified in the license). Sourcecode MUST be revealed on request withoiut charge, but <sic> the act of revealing can be charged.
- Some parts of Qt are GPL-v3 (w/o commercial license) which is even more strict than the older ones.
- Some dispute about statically linking and dynamically linking is still not resolved for LGPL unless there is a linker exception. For that part PascalDragon is right.

[dbannon]

I certainly consider congratulations are in order here, its been a huge effort and very well done.

However, I consider, for most user, the Qtx version of Lazarus would be a better choice for anyone using a Wayland system. And, sadly, that is already a good majority of new users and its only going to get worse.

But putting that aside, my own app, tomboy-ng, appears to now work flawlessly and there will be a gtk3 version in the next release !

Davo

[robert rozee]

[...] Some dispute about statically linking and dynamically linking is still not resolved for LGPL unless there is a linker exception [...]

Thaddy: many thanks for your reply, i am slowly getting the complexities of the licensing sorted out in my mind!

i think where we are at is now:

1. there is no programmatic reason why LibQt5Pas et al should not be statically linked into the ELF binary of a GUI FPC application. see quote below from zeljko...

[...] tested if that could be done, but had problems with plugins, few months later I fix plugins problem too, so it is possible to have statically built dll or so for qt5 and qt6.

2. in the copyright file of LibQt5Pas located at https://github.com/davidbannon/libqt5pas/blob/master/cbindings/package/copyright we find the following...
"As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent modules, and
to copy and distribute the resulting executable under terms of your choice,
provided that you also meet, for each linked independent module, the terms and
conditions of the license of that module."

to me, the above seems to constitute permission to statically link with LibQt5Pas without need to release source code, where "independent modules" is the user's FPC GUI application, and "an executable" is the resulting runnable ELF binary. am i right here?

this same copyright file also names Jan Van Hijfte and Željan Rikalo as the copyright holders of LibQt5Pas, so if there were a need to modify the copyright then at least one of them is probably reading this!

3. there still remains the issue of how the folks at Qt Company would react to seeing such an ELF binary released into the wild, and if they may subsequently decide to take a dim view of LibQt5Pas having (what appears to be) an exception allowing linking.


do the above points seem reasonable?


cheers,
rob   :-)

[Thaddy]

Yes, but I'd like to clarify one thing in so far as I was not clear:
Some of the modules from Qt are GPL3 and that means literally:
"provided that you also meet, for each linked independent module, the terms and
conditions of the license of that module."
And if that Module happens to be licensed as GPL3 you are screwed, whatever the preceding statement states....
Because it requires to reveal ALL sourcecode when statically linked....
See, dynamic linking is OK, since it is a separate, self contained binary, so for that only its license applies.
When you statically link it is not a self contained library anymore and your binary will inherit GPL3 because of that!!!!!
As long as you link dynamic there are no licensing issues, apart from mentioning and providing a link to the sourcecode and the GTK3 license for that module you are using. So there is still work involved and you can NOT distribute your application without mentioning that license and providing a link to that sourcecode.
Static linking means your program becomes GTK3 automatically and all sources need to be provided.

That is also the reason that Freepascal's libraries - not the compiler, that is GPL'd - are distributed as LGPL with linker exception (monoliths allowed without further ado), but Qt is NOT!!

And even with Freepascal you need to be careful when FPC provides bindings (which are either licensed lgpl+linker exception or with a more liberal license like M.I.T. or Apache) and the licenses of the binaries for which these bindings are for...(like Qt )

But you only run into that if a program becomes really successful and then it should be no problem to pay licensing fees. Which your company lawyer or compliance officer will happily advise you to do..
(If you can pay those two, just shy of $500.000... well... then it is a success)

[robert rozee]

Yes, but I'd like to clarify one thing in so far as I was not clear:
Some of the modules from Qt are GPL3 [...]

bear in mind that i am only talking about statically linking the single LibQt5Pas library; all links to Qt would still be dynamic. will the "dynamic" barrier between our ELF binary and the Qt libraries not provide protection against contamination from Qt's licensing?

btw, what happens if someone writes a C++ application that, without any need for a shim, makes use of Qt - do they have to buy a license from the Qt Company? or do C++ programmers strictly stick to the safe waters of gnome's GTK?


cheers,
rob   :-)

[Thaddy]

For C++ or any other language that is used to produce a monolithic binary the same applies.
So yes, even then you will need a license.
If you use the shim (lgpl'd+ linker exception) the shim is free, but statically linked in ANY language if a module is used that is GPL3 you are screwed and all sourcecode must be automatically provided.

[robert rozee]

alas, i still don't understand.

if i have an ELF binary that makes a call to one of Qt's .so files, how can the Qt Company then have any right to make demands on how my ELF binary was produced or what i do with my source code?

it is a bit like me installing a park bench in a public place, and attaching a sign to it saying "this park bench may only be used by people whose annual income is less than $10,000". i can certainly attach the aforementioned sign, but no court of law would entertain me trying to sue any rich people who break the terms i attempt to impose.

i am really struggling to see how the license conditions of a freely distributed .so file can contaminate an ELF binary that makes a call to it.

cheers,
rob   :-)

[Thaddy]

so files are DYNAMIC libraries, so that is fine.
But be warned that open sources licenses are littered with issues when deploying commercial applications.

Do not deploy the Qt binaries yourself with your application, for one, let the user install Qt from the repository of the distribution or provide an install script - yes, that means the user has to go online, which is not what you want.

You still have to mention and provide a link to Qt's licensing.
But you do not need to provide sourcecode.

If you do not do that, your customers are at risk of license violation by merely using your software.....
..... guess where they will claim their legal fees back:...
If that is not clear I don't know what is.

GTK3 has none of those issues.
Deploying a monolith without Qt installed is possible, but always requires a license.
And if that is not a commercial license you have to reveal all sourcecode if you use a component that carries GPL3.

[robert rozee]

[...] Do not deploy the Qt binaries yourself with your application [...]

i have no intention of doing that, never have. pretty much all linux desktop distros come bundled with some flavour of Qt and/or GTK anyway, so there would be no point in doing so.

You still have to mention and provide a link to Qt's licensing.
But you do not need to provide sourcecode.

1. if the end user's linux install already has Qt installed, then they will already have copies of Qt's licenses present. i already advertise in most applications i create what widgetset is being used.
2. are you now saying that i do not need to supply sourcecode to my application?!

If you do not do that, your customers are at risk of license violation by merely using your software [...]

hmmm... we may need to agree to disagree on that point for the moment.

[...] Deploying a monolith without Qt installed is possible, but always requires a license [...]

again, was never suggesting that.

ALL i am wanting to do is take a GUI application, created using Lazarus and to be compiled with FPC, and combine it with (unmodified) LibQt5Pas into a single ELF binary that can (potentially) be distributed without need for including source code. i am happy for the GUI application to acknowledge (a) Lazarus, (b) FPC, (c) LibQt5Pas (with link to the source code of LibQt5Pas), and (d) that the distribution of Qt already present on the machine it is being run on.

does this make sense?


cheers,
rob   :-)

[PascalDragon]

(this may not be the right place to pose this question, i am putting it here simply because this is the thread from which half of the material i am asking about originated; a moderator may feel that the question should be moved to a more appropriate location on the forums)

Thaddy writes:

[...] LGPL'd:
https://www.gnu.org/licenses/lgpl-3.0.html#license-text
In practice, that means that you mention its use somewhere in your documentation or about box and point to or include the LGPL license..(Even Microsoft, Oracle, Google, do this)
You are not required to reveal any sourcecode.

while PascalDragon wrote in another thread:

[..]  being licensed as LGPL, this prohibits [...] use with a proprietary, closed source application (at least if you want to distribute it as a precompiled binary).

see portions above marked out in bold red.

i am trying to reconcile these two accounts of the LGPL as it applies to the case of: i have an application written by myself in Pascal that incorporates a chunk of source code that the original author (of said chunk) has released under the LGPL, where i am releasing an ELF binary of my application, and may (or may not) also be releasing a complete set of source code such that said set of source code can be built into a functionally equivalent ELF binary using Lazarus+FPC.


in other words, who is right in their interpretation of the LGPL: Thaddy or PascalDragon?  or both, or neither?!

Both, because Thaddy talked about the usual dynamic linking case due to linking against GTK3. I talked about the static linking case due to your interest in the statically linked libqt6pas. And for the later case distributing a single binary without source would be against the LGPL.

However as you pointed out, there's the linking exception as part of the libqtXpas library licenses (and I did in fact miss that ). In that case it's indeed not a problem to statically link against libqtXpas.