4 ms·
My personal license choice at the moment is to dual-license my work under both MIT and Apache 2.0. This way the user can decide which license to use. Personall
by eridius 8y ago
My personal license choice at the moment is to dual-license my work under both MIT and Apache 2.0. This way the user can decide which license to use.
Personally, one of my favorite things about Apache 2.0 is the license doesn't include any references to the copyright holder or year, so the exact same license text can be used everywhere, so if you have 20 dependencies all covered by Apache 2.0 you only need 1 copy of the license text rather than 20 nearly-identical copies.
- chandlerc1024 8y agoFWIW, we definitely looked at a dual-license style approach. One thing that I keep pointing out is that the Apache provides a way for the license to be self-executing. This is really cool (although also one source of objections) and IMO super important for an Open Source project like LLVM. It avoids the need for us to force every person who ever posts a patch to sign a legal agreement before we incorporate the patch because the Apache license itself handles those kinds of issues. Unfortunately, we wouldn't get that w/ a dual-license approach. And we would add a lot of complications due to the duality. =/
- eridius 8y agoI didn't actually realize Apache 2.0 was "self-executing". That's pretty neat. My usual tactic is to just have a section in the README that says > 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. immediately after the section for the licenses, though I have no idea if this is remotely enforceable. Though it hardly matters, as while my libraries have users, they don't generally get pull requests.