I'd go for open source projects. They usually have bigger code bases and good practices, that they enforce on their contributors with code reviews and such.
It's a good way to get feedback on your code, something miss out on personal projects and get much less of in university and corporate projects.
GPL effects "derived works". So if your code is derived from proprietary code, you can not use GPL, as you would need to re-license the proprietary code and you can't do that (assuming you do not hold the copyright for the proprietary code). LGPL and permissive licenses are probably fine though.
Now what exactly is a "derived work"? That is unfortunate up to interpretation and different organizations draw the line in slightly different places. We'd need people to go to court to get that line nailed down more firmly.
The quote above covered exactly what you just said: "yet were also more likely to rate their insecure answers as secure compared to those in our control group" at work :-)
Censorship is about you being limited in the actions you can take to express yourself. It is not about cushioning you from the consequences of those actions from the people around you.
You obviously were allowed to take action: The contents was apparent upon on a forum and here as well. People reacted to your actions: Admins removed your contents and blocked you and I am telling you that your understanding of wayland as well as politics is limited.
Deal with it.
Why would he? It never was an issue.
Everybody needs just a small subset of that excel does, but everybody needs a different subset.
If you do not have all the features, most of your users will be missing something that is critical to their use case.
Build everything you use and ackage it in flatpak?
It's not even that hard to build your own gentoo-based runtimes and install stuff on top of that. Fedora does offer that, too, offering fatpaks based on their own fedora based runtime + rpms.
None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there. Thatbis a design decision eachnofnthese made.
So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features. Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.
Systemd moved the goal posts for what a Linux init system needs to do. I doubt any generic Unix init system can compete.
supply chain attacks are a serious problem that needs addressing.
Last I checked: I am not a supplier. So I will not invest effort to secure some supply chain for people that I do not have any obligations to: The license clearly states "no warranty" for a reason. I do those projects for fun, not to bother me with security stuff, notifications about security problems some automatic thing "found" that do not really effect my code and bogus merge requests to upgrade dependencies for no reason... this are all cool things if you are a supplier, do not get me wrong, but I am not. No, I will not invest hours of my free time to sign binaries nobody uses either or to fill out security surveys for badges I can display on github.
If you want me to act like a supplier: Pay me like all the other suppliers you have. I doubt there is any interest to do so for the projects I have on my private github :-)
For your own projects, it might be worth considering a move away from GitHub. (I've been thinking about it since Microsoft bought them.) Codeberg looks like a good alternative.
That also has associated costs: Your project gets instantly much less visible, so you need to keep a mirror on github for visibility. Unfortunately that also means that you will also get interactions on github, so you will need to log in occasionally to not make people think the project is dead.
Maybe you are running Wayland and not X11?
Not at all: I listed the arguments you will get for that question of yours. They all are bogus, as I tried to explain between the parens.
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.