-
Notifications
You must be signed in to change notification settings - Fork 72
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 other licensing options #112
Comments
#7 was closed because technically my employer owns this project and |
There has been enough precedents of large crates being relicensed (gfx-rs/wgpu#1440, gfx-rs/gfx#847, sfackler/rust-postgres-macros#19, etc.) that I think it would be safe to do what they did and ping all the contributors for permission. If you are okay with relicensing to |
Sounds good to me. I approve the license change to I don't have the time right now to shepard the license change, so if you want to own the PR then I'll support it. |
Ralith noted including the following: ContributionUnless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions. |
This is done now |
Indeed, thanks! 🎉 |
Currently
fontdue
is licensed solely underMIT
. In addition to not being as compatible as it could be with the rest of the ecosystem, most of which uses theMIT OR Apache-2.0
dual license,MIT
is also problematic in that in lacks a patent protection clause and an explicit contribution clause. In fact, Rust itself is only keeping aroundMIT
as a licensing option (instead of using justApache-2.0
) for GPLv2 compat.If this project were to be dual-licensed under
Apache-2.0
andMIT
, contributors would be providing theApache-2.0
patent grant, even though the project will still remain usable with theMIT
license. It will also be more compatible with the rest of the ecosystem. I think this is the ideal option, especially for a crate such asfontdue
that is more likely to end up in someone's dependency tree as an n-layers-deep indirect dependency than a direct one (having to deal with weird different licensing of some dependency of a dependency of a dependency is obviously not fun).I would personally say that while we are at it we may as well also add the
Zlib
license to make it aMIT or Apache-2.0 or Zlib
triple license, which would provide both the extra protection ofApache-2.0
and the extra permissiveness ofZlib
. However, I do remember #7 being closed aswontfix
, so if that had anything to do with you not liking the license, just the dual license above would still be better than what we have now. You closed that issue saying you cannot relicense due to legal reasons; however, that was 2 years ago. Does that still apply/does it also apply toApache-2.0
?Obviously, both
Apache-2.0
andZlib
are OSI-certified and relatively popular in the Rust community.The text was updated successfully, but these errors were encountered: