105

My understanding is that:

  • MIT-licensed projects can be used/redistributed in BSD-licensed projects.
  • BSD-licensed projects can be used/redistributed in MIT-licensed projects.
  • The MIT and the BSD 2-clause licenses are essentially identical.
  • BSD 3-clause = BSD 2-clause + the "no endorsement" clause
  • Issuing a dual license allows users to choose from those licenses—not be bound to both.

If all of the above is correct, then what is the point of using a dual MIT/BSD license? Even if the BSD refers to the 3-clause version, then can't a user legally choose to only abide by the MIT license?

It seems that if you really want the "no endorsement" clause to apply then you have to license it as just BSD (not dual). If you don't care about the "no endorsement" clause, then MIT alone is sufficient and MIT/BSD is redundant.

Similarly, since the MIT and BSD licenses are both "GPL-compatible" and can be redistributed in GPL-licensed projects, then dual licensing MIT/GPL also seems redundant.

5
  • 1
    Can you provide an MIT + BSD licenses example? It's usually redundant to dual license under two similarly permissive licenses, but I've seen dual licensing abused as a way to explicitly state that code could be redistributed under each one of the licenses.
    – yannis
    Commented Nov 28, 2011 at 2:20
  • @Yannis Yea I wondered if people dual-licensed them just to be more explicit for people who don't know. But I think it just makes it more confusing for them.
    – ryanve
    Commented Nov 28, 2011 at 2:56
  • Interesting read: tomhull.com/ocston/docs/mozgpl.html Commented Dec 16, 2011 at 4:46
  • related: How can I compare and contrast open source licenses?
    – gnat
    Commented Sep 12, 2014 at 10:54
  • 1
    In my experience people mainly use dual licensing for incompatible licenses. e.g. MPL+(L)GPL or a paid license with no copyleft together with (A)GPL. Commented Jul 28, 2016 at 7:47

2 Answers 2

71

My understanding is that:

  1. MIT-licensed projects can be used/redistributed in BSD-licensed projects.

True (but unless there are modifications, the users can get it from the sources also.

  1. BSD-licensed projects can be used/redistributed in MIT-licensed projects.

False The BSD 3-clause places additional restrictions on redistribution.

  1. The MIT and the BSD 2-clause licenses are essentially identical.

True Although there is some ambiguity around whether some parts of the MIT license apply to binaries.

  1. BSD 3-clause = BSD 2-clause + the "no endorsement" clause

True.

  1. Issuing a dual license allows users to choose from those licenses—not be bound to both.

True.

Similarly, since the MIT and BSD licenses are both "GPL-compatible" and can be redistributed in GPL-licensed projects, then dual-licensing MIT/GPL also seems redundant.

No. Here is a major difference. MIT license and Apache License only requires that you give credit to original copyright holders. If you choose, you can redistribute source; but if you choose you can keep your new derived product without opening code. Hence, it is possible to use code developed under MIT and Apache—under a commercial license.

If you ever use code with GPL-based license and happen to modify it, you must distribute your modified code as well under GPL. In other words, once any GPL codebase is used under a project, and if you want to publish that as a product, it has to be published with the source code and it has to be published under GPL. It cannot ever be a commercial license or closed source, and it cannot be any other license which is less strict than GPL.

An example can take MIT, Apache or BSD license code, modified and distributed under GPL. Once a codebase is distributed as GPL, its further derived versions cannot be distributed under MIT, Apache or BSD license but must be GPL only.

Edit:

An example case of dual license: Suppose Nice Office is released under dual license—MIT and GPL. It has two possibilities. Some people can create NicePro Office, which can be commercial and sell. Whereas some other open source community creates a fork NiceOpen Office. In this case, it can enforce upon GPL distribution (of the original Nice Office as well as NiceOpen Office version) hence if you start with NiceOpen Office, you must comply to GPL only and not MIT license.

The point is in case of dual license the first person who derives a license has a choice. He can choose either way - however, the second person needs to adhere to the choice the first person made. He/She cannot override the original rights of either generation and cannot in any way reduce the obligation of the applicable license.

EDIT 2

Adding an interesting read - GPL and MPL Licenses has a serious conflict. Read this.

12
  • 5
    @Dipan If a project is dual licensed under MIT/GPL, then it can be used in a proprietary project b/c the user can choose to follow only the MIT. If a project holds only the MIT license, then it can be redistributed under others licenses including the GPL. That's what I meant by redundant.
    – ryanve
    Commented Nov 28, 2011 at 8:13
  • 12
    @DipanMehta What do you mean by "contribution credits" in #2? It sounds like you're referring to the BSD 4-clause license, which is not verified by the FSF like the 3-clause and 2-clause are. I'm talking about the 3-clause and the 2-clause ones, in which case I'm pretty sure that all five statements are true.
    – ryanve
    Commented Nov 28, 2011 at 8:20
  • 5
    You can use BSD-licensed code in conjunction with MIT-licensed code; you just have to mention in the project's materials that "BazApp uses libfoobar, which is distributed under a BSD license" or something like that. The BSD and MIT licenses are applied on a per-file, rather than per-project, level.
    – mipadi
    Commented Nov 28, 2011 at 15:51
  • 10
    @Dipan_Mehta As ryanve already told you, you're talking about the original 4-clause BSD license, while the OP is talking about the revised 3- and 2-clause BSD licenses. The 2-clause BSD license is actually equivalent to the MIT one. Even the OSI page states so.
    – user54062
    Commented May 15, 2012 at 10:15
  • 21
    Point #2 (BSD code cannot be included in MIT code) runs contrary to every piece of information I've ever read about 3-clause and 2-clause BSD. Point #2 would be true about the (now-ancient and forgotten) 4-clause BSD, but the OP has made it clear this question is not about the 4-clause BSD. It seems quite harmful to have such a hugely misleading piece of information in an otherwise very good and credible answer.
    – apsillers
    Commented Apr 2, 2015 at 22:13
6

Your five points are all true.

The other answer seems to be assuming you are including the older, rarely used 4 clause BSD license.

If you interpret "BSD licenses" as referring to the more commonly used 3-clause or 2-clause variants of the BSD license, all five claims in the question are true.

If all of the above is correct, then what is the point of using a dual MIT/BSD license?

Technically there should be no need for it. Either can be used in the same situations.

Even if the BSD refers to the 3-clause version, then can't a user legally choose to only abide by the MIT license?

That sounds correct.

It seems that if you really want the "no endorsement" clause to apply then you have to license it as just BSD (not dual). If you don't care about the "no endorsement" clause, then MIT alone is sufficient and MIT/BSD is redundant.

That's right. If you care about that particular clause it wouldn't make sense to also license the same work under licenses without that clause.

Similarly, since the MIT and BSD licenses are both "GPL-compatible" and can be redistributed in GPL-licensed projects, then dual licensing MIT/GPL also seems redundant.

Yes.

Though, sometimes a software product will claim to be dual licensed as MIT and GPL (or some permissive license and GPL), but in reality they are referring to two different versions of the software.

For example, some software can be compiled and distributed with a permissive license like BSD or MIT, but if you omit some libraries and therefore some functionality, it can be distributed as GPL. The omitted libraries will usually be third party libraries that are not GPL compatible but could still otherwise be distributed.

Not the answer you're looking for? Browse other questions tagged or ask your own question.