Hacker News Reader

Comment by cfn | Hacker News Reader

It is a pity that the article does not explain why the change. I assume that the MIT license is more permissive than an LGPL license but since LGPL allows use in closed source projects what else does MIT brings to the table?

View on HN

LGPL doesn't allow use in closed source projects, it allows use with them. So you can use LGPL dynamically linked library with a closed program (that's what LGPL was made for), but you can't just embed LGPL library with no source and way to replace it like you can with more permissive licenses.

It indeed would be interesting to hear their reasons. One thing I know that business world is using a lot of open source software, and GPL and to some extent LGPL has some negative reputation there due to legal issues its usage may bring. Especially with something like PHP library, where concepts of derivative works for bigger application that is distributed together with Doctrine may be less than clear. So I can see how that can be a limiting factor for them and a plausible reason for the change.

This doesn't really apply to the project in question here, but one good reason to switch from LGPL to MIT or another similar license is for libraries one might use on platforms where dynamic linking to libraries is basically impossible (eg. a non-jailbroken iPhone). On platforms where static linking is your only option, the LGPL basically becomes the GPL in practical terms.

The main difference between LGPL and MIT is that, in both, third-party programs that use the library can be non-free, but with the MIT license, modifications to the original library can be non-free as well. (LGPL requires that those modifications to the original library be relicensed under the LGPL as well).

Not sure what that translated to in the context of this project, but presumably they believe people want to be able to extend the library itself while keeping their modifications proprietary.

Reply on news.ycombinator.com