The MIT license was and still is the simplest, best-known liberal license. It's way too late to change the license now and there's no compelling reason to do so. We'd have to get permission from the 400+ people who have made contributions to Julia. For what benefit? A license that has the same practical effect that is less well-known?
There are no known (to me) patents that apply to anything in Julia. Since we don't have any Julia-related patents, granting them doesn't accomplish anything. While I understand the motivation for patent retribution clauses like the one in the Apache License, it just rubs me the wrong way. On Monday, November 2, 2015, Páll Haraldsson <[email protected]> wrote: > > First a question in the current [main] license: > > A. Is there some reason the MIT [Expat] license was used (other than maybe > just the default for MIT people)? > > > B. If it is just to be short and uncomplicated, the Universal Permissive > License, I've just become aware of, also seems to fit the bill: > > http://www.gnu.org/licenses/license-list.en.html#UPL > > > The FSF just added it to their list in September: > > > https://www.fsf.org/blogs/licensing/universal-permissive-license-added-to-license-list > "we still recommend using Apache 2.0 for simple programs".. > > > It is also OSI compliant: > > http://opensource.org/licenses/UPL > > > I've seen languages use MPL [2.0], a long license, without problems > (expect the length..). If I recall Apache 2.0 has also been used, also > long, and while the FSF says ok, note they say only compatible with GPL v3, > not v2. > > > C. Some projects have a PATENT grant file, I'm not aware of any patents, > and I assume there are no submarine patents.. Maybe we would want the UPL > to make it explicit? Dual license with MIT? > > -- > Palli. > >
