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

Relicense under dual MIT/Apache-2.0 #55

Closed
robo9k opened this issue Aug 18, 2022 · 4 comments
Closed

Relicense under dual MIT/Apache-2.0 #55

robo9k opened this issue Aug 18, 2022 · 4 comments

Comments

@robo9k
Copy link
Owner

robo9k commented Aug 18, 2022

In the spirit of robo9k/rust-magic-sys#8 this repo here should be dual licensed under both the MIT and the Apache-2.0 licenses.

Previous license related issues: #1 #3 #12 #25 #41 #42 #44

Currently the license is only MIT, not Apache-2.0

Requirement for a relicense like this in future versions is that all contributors of the current files agree with the change.

However I went through git blame of all the files currently present in main (dc3dbc5) and determined that I, @robo9k , am the author of all files or non-whitespace / non-trivial lines in text files.
As such while IANAL I believe my agreement is sufficient for this license change.

Documentation for contributors should state that future contributions will be dual-licensed as described above.

@robo9k
Copy link
Owner Author

robo9k commented Aug 18, 2022

Some NOTEs on licensing:

  • There's a difference between the source form (i.e. this Git repo here) and the distribution form (i.e. .crate files on crates.io).
    I believe it's fine to have e.g. License of Rust logo test file #12 or [dev-dependencies] as long as users of the magic Rust crate don't need to concern themselves with such details.
  • [dependencies] used by the distribution form should be MIT OR Apache-2.0 as well.
  • Since this is a binding crate, documentation is partially copied from file / libmagic which has a custom, BSD-ish license.
    I think this is not an issue, but the documentation could be replaced / improved anyways.

@robo9k
Copy link
Owner Author

robo9k commented Aug 18, 2022

Given that this adds another license choice, it should be a semver compatible change.
Either way, people should automatically use the license key from Cargo.toml and not just eyeball a README or such once.

@robo9k
Copy link
Owner Author

robo9k commented May 7, 2023

License is also part of the OpenSSF best practice, see #48

@robo9k
Copy link
Owner Author

robo9k commented Oct 3, 2023

License should've been updated inside the repo and outside of it.

@robo9k robo9k closed this as completed Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant