We are developing UI in slint-rs for our product. Our eventiual target is IoT devices (cyber defense) though we are starting with desktops. We are a young startup and our experience is very limited in UI space so please take all of it with a pinch of salt.

One of our intern got the UI working with Slint in a few days and since then we didn't feel a strong need to move away from it. We found a few missing features: it was not possible to tell if a Windows is hidden or not. We ended up sending a few patches.

So far our experience has been pretty good with slint-ui. We are not tested the UI on OSX and Linux yet, only windows. On AWS machines with Windows server, the UI fails to launch sometimes because of some missing GL libraries. Also note the licensing of Slint-UI https://github.com/slint-ui/slint/discussions/379.

Wow the maintainer is being really disingenuous on that licensing thread.

Maintainer here :-). Would you like to elaborate?

Well the repeated obfuscation between 'product' and 'code' when someone asked you how an open source project with an Apache License can depend on your project. Realistically, there's no way a project with a fully permissive license like Apache/MIT can use your project.

You say:

> The GPL is a good fit for open source users

As the thread tells you, it's clearly not for the many Apache/MIT licensed Rust that cannot use your GPL licensed code.

Again you say:

> With the GPL, we are happy to let open source users use the library for free. Commercial users still will be able to use the library because of the escape hatch of the dual license.

You make this differentiation between commercial and open source users while conveniently ignoring that the most permissively open source projects (Apache/MIT) are practically prevented from using your software.

At least with BSL, projects are honest about what they're doing. Don't play both sides.

I stand by what I said Because Apache/MIT is compatible with the GPL, it is totally fine for people who like to license their code in Apache/MIT to do so.

An example of that is KHTML, the web engine: KHTML was licensed under LGPL, despite it was based on Qt in very deep ways (usage of core feature such as QString, QList, all over the place). Qt was GPL at the time. Even then, Apple was able to take KHTML, and remove the Qt dependency, in order to create WebKit which is fully LGPL.

One can totally make a "more permissive" product based on Slint. If someone wants to use the extra permissions that are not granted by the GPL, they still have the option to do so by purchasing a license, or using the free Slint license, or (worst case) porting away from Slint.

I think the confusing part to the parent comment is that they don't understand that your GPL license infects their project, but not the code they write for that project (which can be MIT or Apache).

Personally, I'm not a big fan of licenses like GPL and BSL, but you do you. I just won't use your product.

If the project is licensed under the GPL, all the code in it is licensed under the GPL. The author is not precluded from later relicensing the non-GPL portions of the project under a different license - it's their code, they can release it under whatever license they want - but there will always be a version of that code that is under the GPL.

This is true, but if you dual license like this, your code will also carry another more permissive license, like Apache, BSD, or MIT, without an explicit re-licensing at a later date. It (that code only) can then be used under the more permissive license straight from the GPL-marked project. To convert from a GPL-licensed project, the user would only have to replace the GPL-licensed components.

From what I understand, if I have a project licensed under the Apache license, I cannot use Slint in the project. I'm no expert about this stuff, but here is what the Apache foundation has:

> Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

> This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0.

> We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. We want to honor their license. Unless GPLv3 licensors relax this interpretation of their own license regarding linking, our licensing philosophies are fundamentally incompatible. This is an identical issue for both GPLv2 and GPLv3.

https://www.apache.org/licenses/GPL-compatibility

Am I missing something?

I think the distinction that you may be missing is between software generally licensed under the Apache license and software that is part of the Apache project and governed by the Apache Software Foundation. The latter may choose not to include GPLv3 software in their project, but software outside of the ASF umbrella that's licensed under the Apache license can be combined with GPLv3 software.

It is impossible to tell, from this post, whether you mean to say that the teeth can be removed from the GPL by simply licensing a dependent work as LGPL, or whether you mean to say that the GPL does not steal ownership from you and you can adapt it later to be non-GPL.

If the former, this is laughably wrong and displays a complete misunderstanding of open source licensure. The GPL infects the entire project, that's its defining factor, and you cannot set the entire work's license as LGPL any more than you can set it as MIT.

If the latter, this is a fake distinction, and displays dishonesty about the risks. Regardless of what license I can distribute my code under later if I change it, in order to use a GPL-covered library I must license the version of my code that depends on it under the GPL. That version of the code will be GPL-licensed to anyone that has it, for eternity; I cannot retract it, regardless of what changes I make to my own copy.

Either way this is not a reassuring post. I am glad to know Slint is GPL so I can stay far away from it and recommend others do the same.

If I was laughably wrong, why are WebKit and Safari not GPL, despite it is based on KHTML which was using Qt 3.x which was GPL. From your argument, Qt's GPL should have "infected" KHTML's code and so WebKit, and by extension Safari. But Safari is not open source, is it?

This post would indicate that you are talking about the latter case, in which case you were not laughably wrong, but rather dishonest about the risks. You are talking as though people have the ability to be Apple, but everyone you're talking about is not in Apple's position, but in KDE's.

Yes, exactly. My point is that the open source project who wants to be a more liberal license can do it, just like KDE did.

Then if someone wants to take that for proprietary software, they can do it too, like Apple. They don't even need to go as far as Apple and make a fork, they can use Slint's paid, or free as in beer (ambassador) license.

Why do you believe the maintainer is disingenuous? They are very open about their reasons to pick GPL as their license. We don’t have to like it but it’s their code and their right to choose. They’re not pulling some weird kind of bait and switch, they’re upfront about wanting to sell commercial licenses to commercial enterprises - a pretty common business model. The available licenses are prominently displayed in the readme.

Looks all perfectly fine to me.

They are actually very clever about it. There is literally 0 alternative in the Rust world: this is what the "gpl competitive advantage" is about.

We're not trying to be clever, TBH. There are many excellent alternatives out there in the Rust world. Our choice of Rust is primarily a technical choice, and later we found out that it's also a fantastic community to be part of.

Most of us have our roots in the open source world, many (most?) of us learned coding because we were able to look at open source code, make changes to it, recompile and play with it.

We're trying to give back to the open source community and at the same time earn a living by asking the people who use Slint for proprietary apps (i.e. not giving back) to support us by purchasing a license.

Frankly, that's a fantastic use of the GPL. The idea that open source developers should bend over backwards to support the use case of people who can't be assed to give back to the open source community is ridiculous. If a company wants to make proprietary software off the back of open source developers, they can pay for a commercial license. Everyone else is free to use the GPL.

All other so-called "free" licenses are just a way for corporations to co-opt the open source software community.

Wow that linked request is really something. Requesting/Suggesting the change of license is one thing. But this is just another example of a blatant lack of respect towards open source devs and maintainers.

The misinformed GPL hatred displayed there is also ridiculous.

Could you name, specifically, the true things they do not know or the false things that they think they know? Or is 'misinformed' here simply a way of saying that you disagree, and have no such preference for people not requiring you to license your own code a certain way?

It's not about whether it is true or not.

Requesting a license change from a project that you are not a primary maintainer is more than a little rude.

However, continuing to request a license change even after the owners have explained why they chose the license is an astonishing level of entitlement.

If you don't like the license, don't use the project. That's the deal--take it or leave it.

"Misinformed" is, in fact, about whether something is true.

I use GTK3 with Rust for my video acquisition tool [1] and it's been quite pleasant so far. However, from my testing GTK3 & 4 don't play nice with OpenGL drawing areas, so the next project I'm writing (also in Rust) using Dear ImGUI.

[1] https://github.com/GreatAttractor/vidoxide