Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more licensing options #19

Closed
lunabunn opened this issue Jun 1, 2022 · 2 comments
Closed

Add more licensing options #19

lunabunn opened this issue Jun 1, 2022 · 2 comments

Comments

@lunabunn
Copy link

lunabunn commented Jun 1, 2022

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 :-)

For some precedents, see:

@lunabunn
Copy link
Author

lunabunn commented Jun 4, 2022

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?

@nical
Copy link
Owner

nical commented Jun 6, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants