Horde3D

First I would like to mention how much I like the Horde Engine. The code is absolutely amazing. It is very clean, understandable and well documented.
Now there is my license question. Just to make it clear right now: I know that I am not in the position to ask for a license change, this is meant to be a constructive idea, that may just be wrong for you.
I don't like the LGPL. The advantage of it is certainly that the used code has to be available and could be integrated in the original code base.
What I would prefer is a BSD like license. I certainly understand that there is a huge difference between the LGPL and BSD like licenses. But in my opinion the result of using a BSD like license may be to get a bigger community with more contributions. I should make that point clear I think:
If you have a look at the potential users of Horde, there are open source developers, smaller companies and a few others. I don't think a big company would use it. You can be sure that open source developers would share the modifications. Small companies would probably do the same, as they don't have a budget to maintain their own branch. It would be a huge amount of work to have such a branch and try to get the newest changes from Horde into it. So they probably try to contribute at least certain modifications back to the community. There seem to be many companies that don't use LGPL'd code and prefer BSD or comparable ones. That would make Horde more attractive in my opinion. That's actually the central point I would like to highlight. In my opinion, it would make Horde more attractive and would - from my point of view - be used by more people. The advantage would possibly be that it may be used in more commercial projects and thus there would be more contributions - as just explained.
I suggest you that as there seem to be more and more possible contributions now and such a license change would be needed before significant contributions take place in Horde.
As I said, it is just meant as a constructive idea you may negotiate.

Regards,
Daniel

Personally I don't like the idea to much. Since Horde is a well capsulated module, that can be used from nearly every programming language using it's C Interface it shouldn't be a problem to link dynamically to a complex closed source commercial application (of course there might be cases where you can't link dynamically). Shaders are also not part of the engine itself so you don't have to share your shader code if you don't want to. And if there are contributions to the core DLL then I think it's just fair that those will be released to the community.
Neither Marciano nor I get payed for all the time we are working on this project, so why should I spent time for a project that let others people earn money without having to publish improvements and contributions to our work?
I think if someone wants to use Horde3D for a closed source application, he/she/them can either spent some time to create a plugin mechanism to load extensions dynamically so they won't have to be published under the LGPL or just stick to the interface we already have and create all other modules outside of the core DLL.
I don't see any benefit if only more people are using Horde3D when none of them are contributing to the project and I doubt that there are so much companies that will use a BSD version of Horde3D and publish their modifications just because they might have not the resources to manage their own branch.

Maybe some day if we don't work on this project ourselfs anymore and don't have the time to improve it further we could change the license to BSD or ZLib if all contibuters until this point agree.

Just my two cents, I won't be the license change blocker if marciano decides to change it. But I personally find the LGPL just fair.

To be honest, I that it would make any difference. There is at least one other major open-source engine (OGRE) under the LGPL, and they see no shortage of contributions. Although Horde's community is relatively small, that is mainly a function of age - we are just hitting version 1.0, whereas Ogre/IrrLicht/etc. mostly are up in the double digits.

The LGPL lets you write commercial or or open-source software, and provides a solid guarantee that everyone contributes back. While I would like to see a exception for extenson modules, I think the LGPL is a pretty good match.

_________________
Tristam MacDonald - [swiftcoding]

Thanks for your replies

@Volker
I totally understand what you mean.
I actually doubt it will be possible to change to a BSD or zLib license as soon as there are further contributions from others. So I didn't want to miss that opportunity now as long as a change is manageable.
Again, it is absolutely understandable if you don't want to change the license.

@swiftcoder
I also think it is very important that there are contributions back to the community. My opinion is that it would also happen with BSD like licenses, just to stay compatible with the community code base. It may work with such licenses and it will work with the LGPL that's clear.
There are a few commercial titles using OGRE, even if it is LGPL'd. I know that. Still, I would prefer BSD. But it is certainly not my decision, it's just an idea.

Far larger projects have relicensed at a late stage (Mozzila, Apache, etc.), so while it would be a hassle, I don't see any real issue with changing it later if it becomes necessary.

My point runs more like this - BSD allows exactly 2 things which are forbidden by the LGPL:
a) make changes to the engine itself without releasing them
b) statically link to the engine
Obviously, point a isn't of any benefit to the engine/community, and b is only an issue in specific cases - and Marciano has already stated (see thread in the General Discussion forum) that he is willing to be flexible on point b, on a case by case basis.

_________________
Tristam MacDonald - [swiftcoding]

Thanks for pointing me to that thread.
So it seams that the license is not that important, as long as it states that changes to the code in released software have to be available. In my opinion that would be an amazing license! I don't know if such a license exists.
It may become difficult to release Horde as LGPL and than having certain exceptions. I am not a lawyer, but if there was such a license, it would probably be better to release it like that.

I was just looking for such a license and found one: http://en.wikipedia.org/wiki/Eiffel_Forum_License.

Funnily I use Eiffel since several years and was not aware of the text in the license.

The Eiffel license does not require (only encourages) changes to be contributed back.

Actually, there is one license exactly like that - the GPL with classpath exception:

"Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version."

This is my license of choice for all open source code. It allows static and dynamic linking in closed source programs, requires changes to be contributed back, and the exception was written by GNU (so their lawyers have thoroughly analysed it). It also avoids all the little problems with the LGPL (templates, pre-processor macros).

_________________
Tristam MacDonald - [swiftcoding]

That license would very good in my opinion.

As a general note, I don't think that it will become too difficult to switch the license in the future. In contrast to other major projects, Horde is intended to be a lightweight and manageable library. It is quite modular, so we hope that a lot of additional funcionality will be created with additonal utility libraries (a layer above Horde) and new extensions. But these are not directly part of Horde, so I think the core will still remain manageable.

Although I was already gently considering a BSD license, I must say that I see things similar as Volker. The BSD license just enables very unfair use of our work. It could help to get a few more reference projects but probably often no insight in how they used the engine or to which degree it is actually still Horde. So I am also against a BSD-style license. On the other hand, we understand that the LGPL is not a perfect fit for Horde. Our integration and extension philosophy collides with the static linking restriction. So we need to find an option in-between.


I don't think the classpath exception can be used with Horde's extensions (neither for static nor dynamic linking). It clearly states that solely independent modules may be linked. The definition of independent is "not based on" and "not derived". But an extension uses the Horde internals, so it is based on Horde and also derived from Horde.

I was thinking about a custom license that can be applied with dual licensing (LGPL and custom Horde license). It would basically be a BSD license with an additional clause which makes the license a weak copyleft one. Here is a quick draft:



The third condition is the most important one, the rest is just a mixture of BSD and zlib. The boundary between Horde code and proprietary code would be the source code files (similar to MPL), not the built binary library (as in LGPL).

Please discuss if you think that the file boundary is appropriate. Maybe it would also be necessary to find a better wording for that clause.

Right, I was referencing classpath with respect to the OP's requirements, not the extension issue.

That still needs an explicit definition of extension modules, or the issue is going to be unclear. My one concern with drafting a custom license is that there are already a profusion of weak copyleft licenses (classpath being one), and we end up with a license which is not OSI certified.

Also I think that the clause "if parts of this source file are merged into others..." would need to be clarified re the preprocessor, linker and template compilation (all of which merge source files together).

_________________
Tristam MacDonald - [swiftcoding]

I looked around but did not find any which would fit our needs. The MPL (Mozilla Public License) was quite interesting but has a lot of smaller annoyances and is not GPL compatible. If we find good licensing terms it woud be possible to get OSI approval.

Can we enumerate the needs? I have a feeling I am missing some. So far, see these needs:
a) modifications must go back to the engine
b) engine must be useable by open-source and commercial projects
c) extensions can be open or closed

_________________
Tristam MacDonald - [swiftcoding]

I would add to your list that a project needs to clearly state that it uses Horde3D but that's a small thing.

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.

Maybe another point would be that not only changes to the core are publicly available, but also additional code that is needed, such that the engine is still usable. One could make a small change to the core and just write an additional, that is directly used by the core. In that situation the additional class becomes a not splittable part of the engine.
I never saw that point in any license.

Edit Marciano, I missed your post. As just written, one may define a term such as not splittable from the core. Extensions could stay closed source, whereas other modifications need to be open.
Those additional parts certainly would need to be released under the same license as Horde.