02-18-2019, 09:06 PM
Release 2.2.0 changes the open source license to the more permissive Mozilla Public License 2.0, discarding previous LGPL 2.1 used from release 2.0 up to 2.1.2
Why?
Prior LGPL allows integration of a library inside any bigger project that uses it, but requires that the host project can use a modified version of the library. It's not a problem with shared (dinamically loaded) libraries, but in case of static libraries it does require the host program to be rebuilt. Console SDKs use static libraries, and requiring the end user to rebuild the main program at any time to comply with the license is against the closed environment of console development. This has blocked the usage of Tilengine in some situations where it was being evaluated for a commercial game.
Why MPL 2.0?
Unlike LGPL, MPL works at the source-code level, not at the binary-distributed level. That means that you can take Tilengine source, build a static library with it or put their sources directly inside your main application build, whatever your toolchain requires, without affecting the license of the host application. This feature makes it possible to develop for consoles without licensing issues.
Why not just MIT?
MIT license is a popular choice for open source projects, but it is so permissive that it allows anyone to grab a MIT-licensed project, modify it, and start selling those modifications as a new proprietary product without giving anything back to the community that created the original project in the first place. I think that this right is not fair at all. What LGPL and MPL have in common is that they both require that any modifications to the original project must be publicly released under the same source license, thus preventing anyone to make money modifying something he or she received for free.
Why?
Prior LGPL allows integration of a library inside any bigger project that uses it, but requires that the host project can use a modified version of the library. It's not a problem with shared (dinamically loaded) libraries, but in case of static libraries it does require the host program to be rebuilt. Console SDKs use static libraries, and requiring the end user to rebuild the main program at any time to comply with the license is against the closed environment of console development. This has blocked the usage of Tilengine in some situations where it was being evaluated for a commercial game.
Why MPL 2.0?
Unlike LGPL, MPL works at the source-code level, not at the binary-distributed level. That means that you can take Tilengine source, build a static library with it or put their sources directly inside your main application build, whatever your toolchain requires, without affecting the license of the host application. This feature makes it possible to develop for consoles without licensing issues.
Why not just MIT?
MIT license is a popular choice for open source projects, but it is so permissive that it allows anyone to grab a MIT-licensed project, modify it, and start selling those modifications as a new proprietary product without giving anything back to the community that created the original project in the first place. I think that this right is not fair at all. What LGPL and MPL have in common is that they both require that any modifications to the original project must be publicly released under the same source license, thus preventing anyone to make money modifying something he or she received for free.