The choice of MIT is not an arbitrary one:
The GPL is good for forcing people who make changes to the source to contribute back. This would be okay if you were developing a program, but never ideal for libraries or operating systems, because the GPL forces any code that even remotely uses or links to the GPL'd source, to become GPL'd.
Since operating systems are such an integrated part of our lives, we want as little restriction as possible. Restrictive licenses are quite a big disadvantage for OS projects. The MIT license opens up a lot of possibilities, which are simply not plausible with, say, the GPL.
The GPL is upstream-centric, the MIT license is downstream-centric. We happen to prioritize downstream more than upstream, since downstream is what really matters: the userbase, the community, the availability.
We wanted to encourage the use, modification, and packaging of Redox in absolutely all realms. Open source should be open, for everyone. There's absolutely no reason for limiting the usage of the software. Therefore, MIT was the license of choice.
But what if someone "steals" the source code?
We wouldn't mind if somebody did that. In order to successfully steal a project, you'd have to make some improvements over the upstream version. You can't sell an apple for $2, if another person stands right next to you, giving them away for free. For this reason, making a (potentially proprietary) fork interesting requires putting some time and money into it.
There is nothing wrong with building on top of Redox. You can't unfairly steal a project. That's simply not possible. For a fork to gain interest, you will have to put effort into it no matter what.
Building on top of Redox, whether it gets to upstream or not, is a thing we appreciate.
We like to have a decentralized structure of the project, allowing people to do whatever they want, no matter how they intend to share it.