Windows-rs: Lack of Apache-2.0 license option prevents this from being used by the standard library

[Lokathor]

The current crate license is MIT only, with no option for Apache-2.0

However, for a crate to become a dependency of the standard library it has to have Apache-2.0 OR MIT as the license (plus possibly other license options, if any).

So, this crate can't become an eventual part of the standard library if the Apache-2.0 license isn't added as an option.

(If that's _not_ a goal of this crate that's fine, but if so that should probably be affirmed somewhere, because if that's the case then winapi will need to continue to be used by the standard library)

[kennykerr]

That's certainly a goal.

I had a quick look and it seems we can probably offer Apache License 2.0 as well - I'm just not sure how to add that to the existing MIT license.

[ForNeVeR]

IMNAL, but, according to my understanding, Apache 2.0 has more grants than MIT (_at least_ w.r.t. "grant of patent license"), so, in general, software licensed under MIT cannot be freely relicensed/reused under Apache 2.0.

[DK26]

IMNAL.

It seems the rational behind licensing MIT or Apache 2.0 is that everything is licensed as Apache 2.0 first (the more restrictive license), and if Apache 2.0 is not compatible, then the less restrictive MIT is opted. This was originally created with the goal of using Apache 2.0 as license however still wanting to be usable/compatible with GPLv2.

Source:
https://internals.rust-lang.org/t/rationale-of-apache-dual-licensing/8952

josh said:

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.

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.

I checked the official rust repository, it doesn't seem like there is an explicit condition that says that Apache 2.0 is first in priority so my best guess is that it is implicit by the order from most restrictive to less restrictive license, where the first compatible license is automatically opted, but I'm not sure that this is indeed correct or legally correct, IMNAL.

I may be wrong about this but if so then can I get sued for violating an Apache 2.0 term or condition, and just claim at court as my defense that I opted for the MIT license, skipping the whole Apache 2.0 term and conditions entirely?

Other than that, the rust repository seem to contain a copy of each license: LICENSE-APACHE , LICENSE-MIT and COPYRIGHT file to make it MIT or Apache 2.0

https://github.com/rust-lang/rust/blob/master/COPYRIGHT

Short version for non-lawyers:

The Rust Project is dual-licensed under Apache 2.0 and MIT
terms.

Longer version:

Copyrights in the Rust project are retained by their contributors. No
copyright assignment is required to contribute to the Rust project.

Some files include explicit copyright notices and/or license notices.
For full authorship information, see the version control history or
https://thanks.rust-lang.org

Except as otherwise noted (below and/or in individual files), Rust is
licensed under the Apache License, Version 2.0 or
http://www.apache.org/licenses/LICENSE-2.0 or the MIT license
or http://opensource.org/licenses/MIT, at your option.

[Lokathor]

It's an OR, the license order listed doesn't matter. The end user makes the choice based on whatever criteria they want.

Some crates list "MIT or Apache", some list "Apache or MIT".

I think "Apache or MIT" is more common just for alphabetical reasons.

(not a lawyer)

[kennykerr]

I did a bit more digging. According to our open source team (source):

The default license preferred by Microsoft for releasing our own code is the MIT License. The MIT license is compatible with other open source licenses, it can be easily used by our customers, and it is rising in use across the industry. Therefore, when we are releasing our own code as OSS, we use the MIT license absent a compelling business reason to do otherwise.

So I'm hoping MIT will be sufficient. If not, I can reach out to our legal folks to see whether we can get an exception.

[Lokathor]

I am not on the teams that make this approval.

However, I can say what happened with me: when I had a project that was even more permissively licensed than MIT (it was using the Zlib license), this came up. It was requested that the project (tinyvec) move to having an MIT OR Apache2 option if I wanted to stay as part of the rust standard library dependency pile in the long term.

[DK26]

BTW, found a detailed article/comment explaining both the rational and HOW-TO:

https://github.com/sfackler/rust-postgres-macros/issues/19

[DK26]

IMNAL, but, according to my understanding, Apache 2.0 has more grants than MIT (_at least_ w.r.t. "grant of patent license"), so, in general, software licensed under MIT cannot be freely relicensed/reused under Apache 2.0.

I don't know about relicensed (depend on our definition for this term?), but you can mix them, they don't contradict. A grant is OK as long as it's not violating an existing restriction.

Again, IMNAL.

[kennykerr]

Thanks for the feedback - I received approval and we are now dual licensed.