As you know, the Rust compiler and many of the public crates is under Apache 2.0 + MIT dual licensing. However, it seems that MIT is almost just a weaker counterpart to Apache 2.0, thus I’d like to question the necessity of dual licensing.
The deal seems to have started years ago with reference to patent related protections. As I mentioned above, I don’t think we can enforce such restrictions as long as MIT licensing is allowed. Adding to that, there are known counter arguments against patent retaliation, such as Stallman’s opinion on GPLv3, and the BSD+Patents license had so serious complaints that Facebook abandoned it for React.
Given that deal licensing is slightly confusing, is there any reason that we need it, either for the compiler or for the community crates?
Facebook patent clause for React terminated patent grant if you sued Facebook for patent infringement, even if patent is unrelated to React. It is very different from Apache 2.0; if React used Apache 2.0, patent grant would be terminated only if patent suit was about React.
Requiring both MIT and Apache 2.0 as inbound licenses for contributions means that anyone making a contribution is providing the Apache 2.0 patent grant. And then having MIT and Apache 2.0 as outbound licenses people can use Rust under means that Rust provides widespread compatibility with all sorts of other FOSS licenses, including GPLv2.
Yeah, just to echo @josh here: the MIT is almost a subset of ASL2 but not quite: GPLv2 compatibility is the one weird case that we needed to retain the nearly-redundant MIT for. Otherwise we’d just have gone ASL2.
If we had it to do over again today, I’d suggest the https://opensource.org/licenses/BSDplusPatent license, which is a permissive license with the Apache 2.0 patent grant but retaining GPLv2-compatibility. But that license didn’t exist when Rust was first licensed.
Another option (that also didn’t exist at the time Rust was first licensed) is to use Apache-2.0 with the LLVM exception, which provides explicit GPLv2 compatibility.