Hey, first of all, thanks for for sharing and I do appreciate both Slint existing and you being able to do software that’s usable by both businesses and, to some extend, open-source projects! (The latter depends on whether you consider contributing to the underlying libraries as a requirement for development, and if you’re then fine with contributing with these MIT/non-MIT specifics.)
When you contribute to any MIT license project you are in the same situation
I would disagree here. If you’re speaking about any MIT project, then many of them would be simply MIT. You contribute like MIT and you can use the code as MIT. Slint is not licensed as MIT-0 though. It’s licensed as written here: https://github.com/slint-ui/slint?tab=readme-ov-file#license, and only your contributions are taken as MIT. This does set Slint apart.
It’s a fair model though, if the developers are sufficiently aware of the deal. And it’s a very sensible business model. I have nothing against it, and I only wish to make the exact deal more explicit. As you see around, I don’t think it’s 100% clear from the first glance.
You contribute code to slint under MIT and you can also use that contributed code under MIT or any other license of your choosing, it stays your code after all. You can not use other peoples code from the slint repo under MIT though, that is correct. The royalty free license tries to get as close to MIT as we can while limiting the use on embedded… but with that limitation in place it is of course not an open source license.
Contributing back to Slint is in no way required, so if you do not like our contribution terms, then you are free to not do so. Ypu are also free to use something else if you do not like our license terms.
We try to make all of the terms as clear as possible. We rewrote the Slint licensing page several times, often with extensive community feedback, to get it as clear as it is right now. If you have ideas on how we can improve, I am all ears.
The royalty free license tries to get as close to MIT as we can while limiting the use on embedded…
I think I understand that perspective. But please also understand the other perspective: how a user has the right to see it, when they are not connected to the company.
If you are such a user, then you need open-source software for your daily life. And you use it. At the same time, you see:
IntelliJ Idea taking its MIT-licensed Rust plugin and deciding that it’ll be more profitable for them to close-source it, so you won’t have it anymore. And of course nobody forked the plugin. The idea is clear, the company wants you to use Rust Rover.
Apple’s OS, being historically based on 4.4BSD-Lite2 and FreeBSD, and being the second-highest valued company in the world (!), is happily living with all and any of that MIT-licensed code, while BSD itself is stagnating. It’s not Apple’s fault of course, Apple is not a bad actor here. It’s just not very smart or future-proof to spend a lot of time binding yourself to a system that can easily turn into stagnation.
On the other hand, GPL-licensed projects protect themselves very well. When things don’t go well, you see successful foks (such as Forjeo, LibreOffice, MariaDB). When things go well, you just see it thriving (such as Linux, most userland software).
We try to make all of the terms as clear as possible. We rewrote the Slint licensing page several times,…
To answer this and to conclude, for me personally, it’s not about how to write something. It’s about what is written. The fact that Slint aims to be good for a for-profit company, does not and will never nullify that MIT contributions are re-licensed as GPL or proprietary. It will come up, and it’s fair when it does… as I see it, at least.
Hey, first of all, thanks for for sharing and I do appreciate both Slint existing and you being able to do software that’s usable by both businesses and, to some extend, open-source projects! (The latter depends on whether you consider contributing to the underlying libraries as a requirement for development, and if you’re then fine with contributing with these MIT/non-MIT specifics.)
I would disagree here. If you’re speaking about any MIT project, then many of them would be simply MIT. You contribute like MIT and you can use the code as MIT. Slint is not licensed as MIT-0 though. It’s licensed as written here: https://github.com/slint-ui/slint?tab=readme-ov-file#license, and only your contributions are taken as MIT. This does set Slint apart.
It’s a fair model though, if the developers are sufficiently aware of the deal. And it’s a very sensible business model. I have nothing against it, and I only wish to make the exact deal more explicit. As you see around, I don’t think it’s 100% clear from the first glance.
You contribute code to slint under MIT and you can also use that contributed code under MIT or any other license of your choosing, it stays your code after all. You can not use other peoples code from the slint repo under MIT though, that is correct. The royalty free license tries to get as close to MIT as we can while limiting the use on embedded… but with that limitation in place it is of course not an open source license.
Contributing back to Slint is in no way required, so if you do not like our contribution terms, then you are free to not do so. Ypu are also free to use something else if you do not like our license terms.
We try to make all of the terms as clear as possible. We rewrote the Slint licensing page several times, often with extensive community feedback, to get it as clear as it is right now. If you have ideas on how we can improve, I am all ears.
Sorry for the late reply.
I think I understand that perspective. But please also understand the other perspective: how a user has the right to see it, when they are not connected to the company.
If you are such a user, then you need open-source software for your daily life. And you use it. At the same time, you see:
IntelliJ Idea taking its MIT-licensed Rust plugin and deciding that it’ll be more profitable for them to close-source it, so you won’t have it anymore. And of course nobody forked the plugin. The idea is clear, the company wants you to use Rust Rover.
Apple’s OS, being historically based on 4.4BSD-Lite2 and FreeBSD, and being the second-highest valued company in the world (!), is happily living with all and any of that MIT-licensed code, while BSD itself is stagnating. It’s not Apple’s fault of course, Apple is not a bad actor here. It’s just not very smart or future-proof to spend a lot of time binding yourself to a system that can easily turn into stagnation.
On the other hand, GPL-licensed projects protect themselves very well. When things don’t go well, you see successful foks (such as Forjeo, LibreOffice, MariaDB). When things go well, you just see it thriving (such as Linux, most userland software).
To answer this and to conclude, for me personally, it’s not about how to write something. It’s about what is written. The fact that Slint aims to be good for a for-profit company, does not and will never nullify that MIT contributions are re-licensed as GPL or proprietary. It will come up, and it’s fair when it does… as I see it, at least.