I'm not a Lawyer, but if I add the necessary code in egExtensions.cpp to register my extension in Horde3D, does it become a non splittable part of the engine because I can't compile it anymore without having the extension? Of course that's not what we intend to have.
I was going to suggest that we boost the extension registration up to the application layer, create a Horde3D::RegisterExtension(), which is called by Horde3DTerrain::RegisterSelf(), which can be called by the application if they want the terrain extension.
I would add to your list that a project needs to clearly state that it uses Horde3D but that's a small thing.
Good point - though we want to be careful of the BSD trap
The open question is: which modifications should go back to the engine. We can either just say solely extensions can be linked statically without having to release their source (could be LGPL with your exception from the Starfall thread) or we can make it more open and say that only existing files that were modified need to be given back (that's my custom license proposal). The second option would allow any static linking. For example, the difference would be: a new D3D10 renderer that someone implements in Horde would need to be open sourced with the first option (LGPL + extension exception) while it usually could stay closed with the second one. With the extension exception we can exactly control which things need to be given back (hence the things which do not go through our extension mechanism). I don't know yet which license would be better.
My inclination is that something as fundamental as a renderer back-end should be released as part of the core - it would be of massive benefit to the whole community.
The extensions on the other hand need to have the possibility of being closed source (although I expect most to be released anyway) - imagine if someone wants to write a SpeedTree extension.
So my preliminary though is that we need a limited attribution, weak copyleft license with an exception for extension modules?