Horde3D

Hi all,

I'm just wondering what your thoughts on this are.

I'm currently using Ogre for my game as the render interface. But I'm just getting more and more annoyed by the LGPL licensing that comes with so much baggage if you want to commercially sell your game.

I've been looking for an engine with a nicer tools pipeline than Ogre (i.e. I'm basically looking for Collada support). My choice seems to be either to write my own renderer (not my preferred option), use C4, or use Horde, but I'm stuck again with the LGPL crapness.

Let me be clear, I'm not saying LGPL is bad. I'm saying its bad for commercial usage. Because essentially any code that is statically linked (did I mention I hate DLL's too?) therefore comes under the "open your source" terms and means that the only way to use code is to use DLL's. I'd much prefer a license that actually allows static linkage free for commercial use, like the BSD or MIT licenses.

So my round about questions are: Is the LGPL thing set in stone? Why LGPL (which basically means you are tied to the dreaded DLL's) over a better license like MIT or BSD? Is there an option to license the engine under different terms for commercial usage?

The fact is, while I dont mind releasing parts of my code, or changes to the render engine. I just dislike the idea of dynamic linking and it just feels like the LGPL thing infects all subsequent development. I've managed to steer clear of some licensing issues in other libraries I'm using but the render engine is a pretty core part of the game.

Before going further into detail: Have you already read this thread?

Nope, sorry, I just assumed because the website has LGPL on it that the license was set in stone a bit.

Although the thread itself didnt really come to any conclusions.

Seriously though, the LGPL license is REALLY becoming irksome to me using Ogre right now. Mainly because of all the DLL versioning issues (I teach game dev at a university and my students use Ogre in thier projects for instance). DLL's frankly are a pain in the arse and dont help when trying to port to a new platform (i.e. thinking of doing a port to iPhone? erm.. DLL's dont work!).

The question really is "what is the purpose of the engine". If its to create a group based development activity, then does having a more formal open license with commercial usage like MIT or BSD really hurt that? Sure someone could use the code commercially and not release anything, but frankly thats going to happen anyway (i.e. they'll simply go with another renderer instead if you dont let em).

I think youre more likely to get a few more professional developers using the engine if you use a different license. Which while it may not help if they dont release code (which may or may not happen), at least you'll have some more convincing demo's to put up as screenshots.

As an indie developer, I have a love of open source stuff. But open source that is really that.. open to commercial usage. I guess its just the concept of wether you care if someone uses your work to create profit. I'm happy to do that kind of thing myself (I'm going to release my Behaviour Tree pipeline as part of the next AI Wisdom book if they accept my submission), because I dont really care if someone else gets ahead based on my work. But I can see its an issue that needs to be decided by each person.

So I'd be interested to hear if there will be a switch to a friendlier license. Right now i'll continue using Ogre and work on the game engine code, but eventually I'll have to decide to switch (to be honest, its mainly just to render animated characters right now, so rolling my own wouldnt be so bad). I'd prefer to get involved with the H3D community and contribute to parts of the renderer when I get time, but that will really depend on the license.

BTW: I've used a lot of engines, commercial and open source. Nothing is EVER perfect

I won't discuss the license issue here further, because I think I did that already in the other thread. But apart from perhaps XBOX , I don't agree with you concerning the DLLs. I haven't develeped applications for the Iphone yet, but I can't imagine that Objective C doesn't support shared libraries. And for example on the Android platform, the shared library concept fits quite well into the application development because you can easily load Horde3D using JNI into your Java based application.

[edit] just googled a bit, and it seems like the Iphone indeed does not support loading of shared libraries in external applications, but I still vote for licensing Horde3D under the LGPL.

It wouldnt be so bad if there was a single unified way of supporting dynamic linking, but there isnt. So in essence for any new platform you'll have to figure out how to comply with the LGPL license as a code issue, which to my mind is simply rediculous.

Frankly, I dont see what purpose is served by having this fixation on dynamic linking anyway. What exactly does it offer as a benefit?

I think one reason behind the LGPL's DLL restriction is that it forces you to draw a line between (open) library and (closed) application.

With a static lib, it's easier to extend the open source portion of the code on the application side, giving you a loophole to not release your source.

I think LGPL would be much less annoying if you were allowed to static link, as long as you did it the same way as a dynamic link (e.g. if dynamic linking is possible, your code will function the same with static or dynamic linking). Then the same protection is afforded, but the programmer is free to bundle the binaries as they wish).

However, another reason they chose to enforce dynamic linking, is because the open-source people want the end-user (customer) to be free to re-write/re-compile the LGPL-based portion of the code as they wish.

If you statically link the LGPL-code into your app, then the end-user can't upgrade it any more, whereas theoretically with a DLL, the end-user can recompile the DLL themselves and extend your application.

In reality though, in almost all non trivial cases that isnt likely to happen. So you fragment the user base by requiring the horrible use of DLL's in order to create some theoretical case that will hardly ever happen.

Honestly, look at how many user made modifications are made to the Torque engine codebase and thats completely NOT open source. This insistance on LGPL I think does a lot more harm than good. Not least because actually getting something to link DLL's is a pain in the arse for beginner programmers.

Modifications happen no matter what. Its allowing people to generate revenue that I think will long-term help out a community effort. But then thats only my opinion

I am working in the games industry myself so I understand quite well your concerns. For professional development a pure LGPL can be too restrictive in some cases (especially when interfacing 3rd party libraries). On the other hand I feel that a plain BSD license is just not fair enough, we just give a lot to people and don't get anything back.

What I want is something in-between. A license where you need to share the modifcations that you did directly to the existing code (bugfixes, optimizations, smaller interface improvements) but that does not require you to give away the code for your extensions (completely new features). I had another look at open source licenses and it seems that the Eclipse Public License is very close to that. On the other hand, I would prefer sticking to a more common license.

What about adding a static linking exception to the LGPL? So everyone could add new features by deriving from the existing classes and would not have to release their code. Of course you could also avoid using DLLs, although I don't understand your aversion against them. Could that make you happy?

Unfortunately thats the route that Ogre has taken and to me at least, it still has issues. Basically the GPL wants everything to be free, including every and all code. If you read the LGPL license website you get the feeling that they really dislike the idea of anyone making money from software.

The LGPL with exceptions still has far too much baggage as a license for future codebases built on top of a library that I'd feel unhappy doing that.

I'm no lawyer of course, but frankly anything with the GPL touch on it spell doom for me.

Incidentally, google made its webkit code available under BSD. So does yahoo for its UI toolkit and a few others. Basically I think BSD is a pretty well respected license. How about MIT? I havent looked at it for a while, but it felt bsd-like but might offer a bit more restriction.

At the end of the day, I think you lose out more not getting really experience people to use the engine by requiring the GPL than you do losing out by someone profiting from your work by using a BSD license. Clearly google think so and I'm kind of with them. I'd rather people release updates and feature upgrades because they enjoy working with the codebase and want to contribute rather than trying to hog-tie them up with some funky license. As I said, Torque (which is not open source) gets plenty of user contribution into the codebase, but people still make money with it. Some things are open, some are closed source, but at least there's a bunch of contributions.

I've had a look at a good number of engines during my time as an indie and it seems to me that the key to expanding the codebase with user contributions is due more to the organisation of the contribution mechanism than it is to the license.

Incidentally, I know I'm being a bit freaky about this, but I spent almost a year as an expert witness in a software copyright litigation case and the whole legal process scares the bejesus out of me. So I'm probably overly concerned with this which probably isnt important until you ship and then start getting sued all over

If we're looking at adding exceptions/extensions to the LGPL, would it also be possible to add an extension to the BSD asking for all fixes/optimisations to be publicly contributed?
Linking to any kind of library is a pain in the arse for beginners Yeah most of the current community would probably release back their improvements whether Horde was LGPL or BSD/etc. The kind of users who want to keep their changes private are also the kind of users that would not use an LGPL-based project.

As an example, lets guess that BSD doubles the size of the user base, but half of all users want to keep their changes private now.
If you double the users, but then halve the contributors, then basically you haven't lost or gained anything - you've still got the same amount of contributions. The people who are taking but not giving wouldn't have been a Horde user in the first place - so their selfishness hasn't really cost the project anything, but it has increased the project's popularity...

That goes in the direction of the custom license that I proposed in the other thread. If we find a good formulation for the copyleft clause I would be fine with offering this license as a dual license besides the LGPL. Do you have a proposal for the wording of that clause?

"That any subsequent modifications which affect the functionality of the source code must be made freely available to the public upon request under this license and that this facility must be documented both within the modified work and in any documentation supplied with the modified work"

Thats my take on it anyway.

Incidentally, I had a look at a load of the licenses on opensource.org and some of them are really rediculous. I guess its a throwback to the old bedroom programmer days or partly tied in with academics and such, but honestly, if youre an indie trying to make a living using open source, you'd be screwed

Yeah, I also searched through the list of existing licenses and couldn't find any that I liked.

Your copyleft clause sounds quite good but I would prefer that the modifications are not just available upon request. What about this formulation?


The important part is "the functionality provided by this software". As a rule of thumb that would mean that modifications to existing classes, both the implementation and the interface ("provided functionality"), need to be shared while implementing a new class (that can inherit from the existing interfaces) does not need to be released since it is new/extended/additional functionality.

Does everyone think that this is understandable from the wording?
Another thing, since I am not a English native speaker: is facility the correct term here?

Actually, I think you could remove "facility" and it would still read correctly.

Another possibly viable approach would be dual licensing. The basic idea is to provide a somewhat restrictive (often GPL but sometimes a weaker license like LGPL) version for free and to sell sources under a more liberal license (BSD/MIT or custom commerical license). MySQL and Qt are pretty good examples of successful dual-licensing. This allows to keep an active and healthy open source community and opens the door to serious commercial users.

Of course this scheme fits better in the case of a company than a team of developers but I'm sure if serious customers showed up the funds could be easily be allocated without nasty side effects (think hosting exepenses, artwork contests, bugfix bounties, hackatons, release parties, ...)


Well, making a living out of software is hard, OSS or not. Yet I won more than 2k euros by dual-licensing a small library while I did not even expect it to be used by other OSS projects (it was a "module" for another OSS project of mine) so there are still opportunities.