Horde3D

Yeah, I have seen that. But honestly, after all the license research, I do not really think that this exception is safe.
We need to do a final review but I still think the EPL is suitable for us.

Certainly - I agree. Interesting that they found the LGPL too restrictive as well, though.

_________________
Tristam MacDonald - [swiftcoding]

I did a final review of the EPL now and among the (rather limited) choice of sane licenses, I think this is the best option.

The EPL is less restrictive than the LGPL (it allows static linking) and it is not viral, so it does not hog your whole application. It is also no problem to create statically linked closed-source extensions which is important due to the way Horde is structured. In fact, a major intention of the EPL is to enable the creation of proprietary plugins for Eclipse. This is not so different from our extension requirements.

However, besides being less restrictive, there is still a weak copyleft covering modifications to existing code (mainly optimizations, bug fixes and refactorings) which helps Horde to evolve. I think this is the best compromise between liberality for the user and progress for the project.

The only real issue is compatibility with the GPL. It is ok to use EPL with LGPL but not with GPL. However, I think that's not much of a problem for us. I'm not aware of any game middleware that is GPL-only. And if you want to release your own game code under the GPL, you have the option to add a special EPL linking exception to the GPL. This is legal and in fact common practice. We will also need to do something like that for the Horde Editor.

So I think it is quite clear that we will switch from the LGPL to the EPL for Beta4.

Sounds like a reasonable decision to me.

Would this also allow changing Horde's extension mechanism from statically linked to dynamically linked extensions?

The dynamically linked extensions are more of a technical issue. The problem is that the extensions would need access to the internal classes of the horde core which would have to be exported from the DLL. However, exporting classes from DLLs has several problems.

This is a nice article covering binary DLL compatibility: http://chadaustin.me/cppinterface.html

And why would you need dynamically linked extensions? Horde is not an application like Photoshop where plugins have a completely different use. You have to know what extensions your game needs at compile time. Extensions are not independent of the rest of the game, like a photoshop file loading plugin.

But this should be discussed in a different thread (I think we did that already), not here.

We have finally realized the license change. Starting with Beta4, Horde is officially under the EPL from now on.

Yay!

Do I have to do anything special re a closed-source extension module?

_________________
Tristam MacDonald - [swiftcoding]

No, there is nothing special to consider for a closed-source extension.

The point is that you can link any code against Horde now and have that code under your own license as long as it is independent. Only if your code contains parts of the Horde code, it is still covered by the EPL. Let's take the math library as a practical example:

If you add a new class Matrix34 to utMath.h or derive a class MyVec3f from Vec3f which is using the Vec3f interface, you can have that code under your own license. However, if you optimize the matrix multiplication routine, your new multiplication method will probably contain code from the original method, so it is still covered by the EPL. If you refactor the multiplication method and copy parts of the original method to your refactored one, it is covered by the EPL as well. That's how I see things and I think that makes sense.

So if you just create new files for your extension and don't copy any code from the original Horde source, you are definitely on the safe side. Just having Horde function signatures in your code, i.e. calling a Horde function or subclassing an existing class, does not make your work to be covered by the EPL.

One thing just occurred to me:

Doing a platform specific port for one of the closed source platforms would require me to release the code, but would be incompatible with the closed source license. Is there any way around that?

Say for example, I wanted to port to PS3 or Wiiware, or 360. What would happen to the license then? I mean of course the H3D core could would have to be modified. So you would then be obliged to release the changes. Only the changes wouldnt be releasable under the closed source licences of the platform holder.

Any way of squaring that circle?

I don't see a problem with that. All platform specific code can be in separate classes that you don't have to release then.

Ideally you would use the graphics API abstraction layer and just write a new backend. This backend just implements the RendererBase interface, and if you don't copy&paste any implementation code from the original Horde, there is no need to have it under the EPL. However, the abstraction layer is not yet complete but we will gradually extend it. The ultimate goal is that there will not be a single GL call left in the renderer class.

What will happen to the community repository - that is still LGPL afaik?

The community repository is still on Beta 3, which was before the license change. I assume that once the repository is upgraded to Beta 4, it will fall under the EPL.

_________________
Tristam MacDonald - [swiftcoding]

Whats in the community repository btw?

Beta3, a bunch of fixes a few of us have contributed, and various 3rd-party extensions. Volker and Marciano have been merging our fixes back into the main SVN every now and then, and at some point will refresh the community branch from the Beta4 in main.

_________________
Tristam MacDonald - [swiftcoding]

It would be so much easier to manage branches if we used something like mercurial or git for source control... oh well.