This is a very important announcement: from the upcoming new stable version of OGRE, OGRE 1.7 aka “Cthugha”, we will be switching to the MIT License. The MIT license is a simpler and more permissive license than the LGPL, which we have used so far and will continue to apply up to and including all releases of OGRE v1.6. OGRE v1.7 is currently available as a preview from Subversion, but will slowly become the new stable version in the next few months.
We arrived at this licensing decision in the last month, and decided to make the community aware of it in advance so you could incorporate it into your plans. After the jump there are more details of the reasoning for this decision, and answers to some common questions.
We hope this announcement will be received positively by the community, and that the simpler licensing arrangements will provide even more incentive for people to get involved in using and extending OGRE in the future.
Why are we doing this?
The MIT license is short, easy to understand, requiring only that you include (simple) copyright & license declarations in your final applications. We hope using it will make it an even easier choice for people to use OGRE in their projects in future, thus driving even greater adoption of OGRE.
Won’t this mean people can ‘rip off’ OGRE in proprietary software?
The LGPL already allowed OGRE to be used in proprietary software, and this is something we’ve always encouraged. The main difference between the LGPL and the MIT License is that there is no requirement to release modified source code; only to include our copyright and the MIT license text in the final product.
While not requiring modified source to be released might initially seem like giving up an important motivator to contribute code back to the community, we’ve noticed something in recent years: 99% of useful code contributions come from people who are motivated to participate in the project regardless of what the license tells them they have to do. It’s our experience that a certain percentage of the user community will always participate and contribute back, and therefore encouraging adoption via simpler licensing is likely to result in more contributions overall than coersion via complex and restrictive licensing does. In addition, people who are internally motivated to participate tend to provide much higher quality and more usable contributions than those who only do it because they are forced to.
Does using a more permissive license weaken OGRE’s commitment to open source?
This is something of a political question. Here at OGRE we’ve always identified ourselves as ‘open source software’ rather than ‘free software’, reflecting that our primary purpose is to promote an open, active, participatory community around our shared code base. Our goal is not, and has never been, to require others to adopt the same licenses for their own software if they use OGRE – the LGPL has always been a ‘fire break’ to that, albeit quite a complex one. Our goal is to make OGRE the best it can be, and to encourage people to get involved in making it better and building ecosystems around it, and pragmatically we’ve decided the best way to do that is via a simpler, more permissive licensing approach based around voluntary contributions.
What does this mean for the OUL (the alternative commercial license to the LGPL)
The OUL will be phased out from 1.7 onwards. It will continue to apply for OGRE 1.6 and previous versions and will be available on request should people require it.
Can I apply the MIT License to OGRE 1.6 (or previous versions)?
No. OGRE 1.6 is licensed under the LGPL (with static link exclusion). The MIT License will only apply from OGRE 1.7 onwards – this is the clean break point between licensing conditions.