You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that especially for a small library crate such as this one, which users are most likely to use indirectly through other dependencies in their dependency graph, more liberal and compatible licensing would greatly increase usability.
A big part of the Rust ecosystem (most notably the standard library) uses the MIT OR Apache-2.0 dual license. The MIT license is potentially problematic in a number of ways; it requires the license text/copyright header to be reproduced multiple times, once for every MIT dependency. It also lacks patent protection and an explicit contribution clause. However, the Apache license is incompatible with GPLv2, which is why Rust also keeps the MIT license. For the same reason, it would be best if etagere adopted Apache-2.0 while also keeping MIT. If this project were to be dual-licensed as such, contributors would be providing the Apache-2.0 patent grant, even though the project would still remain usable with the MIT license.
While we're at it, we may as well also add the Zlib license, which is very similar to the MIT license but only encourages (and does not require) attribution or license information in product distributions that do not include the source code. Compared to the current license, this triple license would provide both the extra protection of Apache-2.0 and the extra permissiveness of Zlib.
This hypothetical relicensing to MIT OR Apache-2.0 OR Zlib would not affect existing users of this crate already using it under the MIT license; it would just give them more options. If you (@ nical) would be open to this change, I can take care of creating a PR and pinging other contributors to make sure they are also fine with it. If not, please feel free to close this issue without ceremony :-)
I just realized that the crate is already dual licensed under MIT/Apache-2.0 according to the README. However, the repository currently only contains the MIT license. Is this intentional?
Hi, thanks for filing this. The intent is indeed to have the usual dual mita/apache license, I am not sure why the license file doesn't reflect that, probably because of github's limited options when pre-populating a repository combined with me not thinking about fixing it afterwards.
I think that especially for a small library crate such as this one, which users are most likely to use indirectly through other dependencies in their dependency graph, more liberal and compatible licensing would greatly increase usability.
A big part of the Rust ecosystem (most notably the standard library) uses the
MIT OR Apache-2.0
dual license. The MIT license is potentially problematic in a number of ways; it requires the license text/copyright header to be reproduced multiple times, once for every MIT dependency. It also lacks patent protection and an explicit contribution clause. However, the Apache license is incompatible with GPLv2, which is why Rust also keeps the MIT license. For the same reason, it would be best ifetagere
adoptedApache-2.0
while also keepingMIT
. If this project were to be dual-licensed as such, contributors would be providing theApache-2.0
patent grant, even though the project would still remain usable with theMIT
license.While we're at it, we may as well also add the
Zlib
license, which is very similar to the MIT license but only encourages (and does not require) attribution or license information in product distributions that do not include the source code. Compared to the current license, this triple license would provide both the extra protection of Apache-2.0 and the extra permissiveness of Zlib.This hypothetical relicensing to
MIT OR Apache-2.0 OR Zlib
would not affect existing users of this crate already using it under the MIT license; it would just give them more options. If you (@ nical) would be open to this change, I can take care of creating a PR and pinging other contributors to make sure they are also fine with it. If not, please feel free to close this issue without ceremony :-)For some precedents, see:
The text was updated successfully, but these errors were encountered: