The fork wouldn't be that different from whatever upstream Iced snapshot it last synced with. There are two major, if peripheral, changes still. A renderer for some Wayland special needs, and some integrated accessibility support. At least that was the case until a few weeks ago. I don't think anything significant changed since.
So the Iced API itself is largely the same. However, since this is built on top of Iced. COSMIC apps are more inclined to use abstractions and tools from libcosmic wherever applicable instead of using Iced API directly. But you still see plenty of direct Iced API use.
A conspiracy theory explanation is not necessary as it:
Operates on the idealistic myopic assumption that common people are an altruistic force for good. The reality is that there is plenty of self-servingness going around.
Assumes full collusion, removing the simple possible explanation of useful fools being taken advantage of to the maximum. Note that useful fools can still be motivated by self interest. They are just not necessarily fully aware of how they are being used.
Ties an argument to unprovable points/events.
It doesn't take a conspiracy theory explanation to observe how classic corporate anti-FSFers are very content with social licenses (CoCs) being elevated to a position where they are considered more relevant and have more signal power than the software licenses chosen, or how many new-gen open-source contributors have no problem singing the New Microsoft (and the likes) praises... etc
You can easily guess who is behind such narratives and why.
You would think so. But anti-FSF sentiment comes in different forms nowadays.
My first (and only) visit to the Mastodon world was years ago. Top post (or whatever you call them) was from some micro-celeb (who probably didn't even code) bitching about how Stallmann caused great damage, and how the FSF's biggest achievement was giving decades of "our" free labor to corporations. The microblogtards replying agreed of course. Needless to say, that tab didn't stay open for long.
Social war ultras (big intersection with microblogtards) also don't like Stallman and the FSF.
So, new developers may have chosen non-FSF licenses not only because of copyleft implications. But also because it looks and goes along better with the posturing ethics of the times. The snowball has already gotten large of course, and next-gen devs may just be going along with the choices made by their predecessors or library dependencies without knowing much about the why.
Still, there should probably be more MPLv2 in the Rust ecosystem.
Meh, everyone scaring you into thinking you don't own your own mind.
Assuming your boss is not the dangerous kind (beyond legal threats), and if the goal is to make it FOSS, then do it using an alias first. Do it differently. Use components/libs/algos from other people at first, even if they are not perfect. Make those parts easily pluggable/replaceable which would be good design anyway. The code then wouldn't be wholly yours, not even your alias self.
You can join the project later with your real identity as an interested domain expert (maybe a bit after not working for the same boss). Start contributing. Become a maintainer. And maybe take over after a while. You can start replacing non-optimal components/libs/algos with better ones piecemeal.
Oh, and if Rust wasn't the choice of implementation, use it this time.
Yay. My first ad-masquerading-as-a-genuine-post experience on Lemmy!
Thus, we’ve developed a cargo extension that transparently queries the Phylum API for information about a package before it’s allowed to build.
Only our malware-like behaviour is blessed. Because it's a feature. And research-based. And security-oriented. And commercial! We told you about it beforehand and sold you the idea.
Assuming the malware discovered is not theirs too.
Not based on, but built on top of Iced.
The fork wouldn't be that different from whatever upstream Iced snapshot it last synced with. There are two major, if peripheral, changes still. A renderer for some Wayland special needs, and some integrated accessibility support. At least that was the case until a few weeks ago. I don't think anything significant changed since.
So the Iced API itself is largely the same. However, since this is built on top of Iced. COSMIC apps are more inclined to use abstractions and tools from libcosmic wherever applicable instead of using Iced API directly. But you still see plenty of direct Iced API use.