> Maybe with enough experience you start to realize that it happens close to never that a proprietary fork of an open source project ends up outpacing the original project.
Apple's MacOS uses BSD code. Safari uses WebKit. In terms of audience outreach, I think both have obviously outpaced the original.
My understanding was that Apple's big code dump back to WebKit/KHTML was not useful for the KDE project. Apple is following the OSS spirit in a technical sense but is not succeeding in actually working with community contributions in a meaningful way. Feel free to refute me, I have no evidence, but this was my understanding.
That was the case for the first two releases. After that the KHTML guys complained vocally (it made Slashdot) and Apple started to release diffs, then completely opened the dev process.
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?
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.
Since everyone loves tortured analogies, MIT/BSD is like handing out free pencil sharpeners. "Enjoy! Just don't misrepresent where you got it from." GPL is like handing out free pencil sharpeners but requiring that everyone share everything they write using any pencil that was sharpened with it.
I think a GPL-like extension of a pencil sharpener would be the following. You develop a new pencil sharpener that copies 90% of the original design but includes a sharper blade that makes nicer pencil tips; when you release that product, you must show everyone how your pencil sharpener is designed and definitely must not prevent anyone from seeing how the original (that you started with) was designed.
I don't think that's a very good analogy. It's more like sharing back everything you did to enhance the free pencil sharpener, so the whole project evolves even faster with everyone's enhancements.
I think both GPL and MIT have their place in the open source world. If you want to build something long-term and you want everyone to contribute, then use GPL. If you just care about jumpstarting a solution to a problem, and if you're satisfied if they only use your basic solution at the very least, then use MIT.
You are talking about AGPL here - this is the only GPL version that makes you open almost everything that handled whatever AGPL program produced. I know of one project with that license, and it stopped me from using it (I couldn't relicense the application it would be used for, and personally I see it as a step too far... I think it should have some restrictions as to what it affects, so i would have to open my changes to the AGPLd part but not much more)
Apple's MacOS uses BSD code. Safari uses WebKit. In terms of audience outreach, I think both have obviously outpaced the original.