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 #27

Open
5 of 8 tasks
emberian opened this issue Jan 8, 2016 · 10 comments
Open
5 of 8 tasks

Relicense under dual MIT/Apache-2.0 #27

emberian opened this issue Jan 8, 2016 · 10 comments

Comments

@emberian
Copy link

emberian commented Jan 8, 2016

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback, and has protections from
patent trolls and an explicit contribution licensing clause. However, the
Apache license is incompatible with GPLv2. This is why Rust is dual-licensed as
MIT/Apache (the "primary" license being Apache, MIT only for GPLv2 compat), and
doing so would be wise for this project. This also makes this crate suitable
for inclusion in the Rust standard distribution and other project using dual
MIT/Apache.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright) and then add the following to
your README:

## License

Licensed under either of
 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, use the following boilerplate (based on that used in Rust):

// Copyright (c) 2015 t developers
// Licensed under the Apache License, Version 2.0
// <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT
// license <LICENSE-MIT or http://opensource.org/licenses/MIT>,
// at your option. All files in the project carrying such
// notice may not be copied, modified, or distributed except
// according to those terms.

And don't forget to update the license metadata in your Cargo.toml!

Contributor checkoff

@untitaker
Copy link
Contributor

The MIT license requires reproducing countless copies of the same copyright header with different names in the copyright field, for every MIT library in use.

I have "Copyright XXXX, the project authors, see AUTHORS file" in my project's LICENSE files.

@emberian
Copy link
Author

emberian commented Jan 8, 2016

@untitaker one needs to reproduce that copyright header from each project that one includes code from, the issue isn't the copyright notice from a single project. It's not unreasonable for projects to have dozens of depdenencies (see many google android apps with long lists of MIT attributions). The strongest reason is the ability to freely share code with the rest of the MIT/Apache-2.0 Rust ecosystem, especially the standard distribution.

@untitaker
Copy link
Contributor

The MIT license has:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

So if I vendor my dependencies in my source distributions, the copyright notice is automatically included in the vendored versions. If I don't, then I don't really provide a copy of the dependency to the user. Is this about static binaries, and if yes, can those be called a copy of the source code?

@emberian
Copy link
Author

emberian commented Jan 8, 2016

@untitaker Google's lawyers seem to think so, yes. See also this, which agree with this interpretation.

@untitaker
Copy link
Contributor

IDK and I don't care. Have my approval for checkoff.

@leoyvens
Copy link
Contributor

leoyvens commented Jan 9, 2016

I approve this and any future relicensing which may require approval.

@cydrobolt
Copy link
Contributor

This looks fine to me.

@untitaker
Copy link
Contributor

@cmr You didn't mention that those concerns were theoretical, I thought that there was a concrete use case (the Rust standard distribution).

@emberian
Copy link
Author

emberian commented Jan 9, 2016

@untitaker it's a potential usecase, I'm not proposing it be added to the standard distribution at this time (although I do love iron and handlebars!)

@mvdnes
Copy link
Contributor

mvdnes commented Jan 9, 2016

I approve 👍

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

5 participants