Could Bullet consider moving to the Eigen SIMD library?

[Panajev]

http://eigen.tuxfamily.org/index.php?title=FAQ

It seems to have a quite permissive license and support for vectorization on many platforms (x86, x86-64, PowerPC, ARMv7, etc...) including support for NEON SIMD vectorization on platforms like the iPhone and the iPad which use an ARMv7 based processor with NEON SIMD unit.

Bullet's been widely used on lots of mobile platform that are based on ARM and support for the NEON SIMD unit seems to be growing (Qualcomm's Snapdragon has an even beefier NEON co-processor compared to the standard one found in the Cortex-A8, twice the SIMD width IIRC), but while it has SIMD optimizations for the PC and PS3 backends... it does not have any on portable platforms (not officially) and considering that maximizing resources usage and efficiency are even more of an imperative there, it seems that it is an area where Bullet could improve and many games along with it. Given how many people are using Bullet to push out million of apps on iPhone (or ARMv7 CPU's in general) that there is so little support for what that CPU can do...

The big problem I see with Eigen is that it does not seem to have an SPU back-end, but the current SPU codepath might still be used. Eigen could work for standard VMX, SSEx, and NEON code.

[Erwin Coumans]

Eigen is licensed under the (L)GPL license, which is unacceptible: we only deal with ZLib (or possible BSD or MIT licensed software), no viral licenses such as (L)GPL.

We will likely add NEON optimizations to our vectormath library (see Bullet/src/vectormath)
Thanks,
Erwin

[Dragonlord]

Eigen is licensed under the (L)GPL license, which is unacceptible: we only deal with ZLib (or possible BSD or MIT licensed software), no viral licenses such as (L)GPL.

The GPL is not viral...

[Erwin Coumans]

The (L)GPL is a viral license and the logic in that previous link is flawed.

Regardless, only software under permissive licenses such as the ZLib, BSD or MIT are acceptable for the Bullet physics library.
Thanks,
Erwin

[Panajev]

The (L)GPL is a viral license and the logic in that previous link is flawed.

Regardless, only software under permissive licenses such as the ZLib, BSD or MIT are acceptable for the Bullet physics library.
Thanks,
Erwin

http://eigen.tuxfamily.org/index.php?ti ... ensing_FAQ

Thank you for the reassurance about NEON optimizations , I am glad to hear that.

Still, as mentioned in that link about Eigen's licensing, the kind of LGPL license they chose seems compatible with BSD style licenses (given the fact that it is a header only library):

Using Eigen in BSD-licensed software

In this section we discuss usage of Eigen in BSD-licensed software. Of course, the same applies to MIT-licensed software and other similar licenses.

Examples of BSD-licensed projects using Eigen
There are many examples of BSD-licensed projects that use Eigen under LGPL license. Here are a few inspiring ones.

The Robotic Operating System (ROS) developed by Willow Garage. It uses Eigen in 39 of its packages.
Libmv, a structure-from-motion library.

The LGPL license is too complex to even read!
In the case of Eigen, the LGPL is actually very simple, as we explain above! The key here is that Eigen is a headers-only library, so the only section of the LGPL that governs the usage of Eigen is Section 3, and it is very simple!

The LGPL's reputation for complexity comes from Sections 4-5, which just don't apply to Eigen.

Of course, even in the case of Eigen's case, the LGPL is still not quite as simple as the BSD license, but very few licenses are.

So what does the LGPL require when distributing software that uses Eigen?
See our answer above. It's pretty much the same as if Eigen were BSD-licensed.

So, in the case of Eigen, how is the LGPL different from the BSD license?
As we explained above, the LGPL puts an important requirements on forks of Eigen. See our section on that topic. Namely, if one forks Eigen and distributes software based on the forked Eigen, then one must distribute the forked Eigen under the LGPL.

Note that this does not at all propagate to your own project. If you develop a library that uses Eigen, and you distribute your library under the BSD license, people will be able to create proprietary forks of your library, as allowed by the BSD license. The only thing that will not be allowed is a proprietary fork of Eigen itself. If people fork both your library and Eigen, the LGPL will still apply only to their fork of Eigen, not to their fork of your library.

I'm developing a BSD-licensed library and I don't want to pass on LGPL requirements to my users!
Don't worry! The only LGPL requirements that you might be passing to users are the 2 clauses described above, which are very similar to the 2 clauses of the BSD license itself.
Concerning the interdiction of proprietary forks, as we just explained, it will only apply to Eigen, not to your own code.

How about static linking?
This has been discussed above.

Also, as we explained there, if you develop a BSD-licensed library using Eigen, then your users can statically link to your library without the LGPL applying at all.

Are there big forking concerns for Bullet?
That page seems to state that unless Bullet needed to fork Eigen that it would be the same as using a BSD license... licensing can be very confusing...

Thanks again for replying to this post .

My Best Regards,

Panajev

[Erwin Coumans]

It is best to stop wasting our time on (L)GPL licenses on these forums..

If the Eigen developers cannot make up their mind to choose between (L)GPL and BSD, that is their problem. Most game and movie companies and publishers don't want to waste money on lawyers to investigate licenses that are long, vague or contain exceptions, and (L)GPL is generally avoided in professional game engines.
Again, for the core Bullet Physics SDK only the ZLib, BSD or MIT license is acceptable. No exceptions.

Aside from the Eigen license issues, we have no plans to switch the underlying vectormath library of Bullet.
Thanks,
Erwin

[Panajev]

It is best to stop wasting our time on (L)GPL licenses on these forums..

If the Eigen developers cannot make up their mind to choose between (L)GPL and BSD, that is their problem. Most game and movie companies and publishers don't want to waste money on lawyers to investigate licenses that are long, vague or contain exceptions, and (L)GPL is generally avoided in professional game engines.
Again, for the core Bullet Physics SDK only the ZLib, BSD or MIT license is acceptable. No exceptions.

Aside from the Eigen license issues, we have no plans to switch the underlying vectormath library of Bullet.
Thanks,
Erwin

Thanks for your clarification about the licensing issue. I guess that leaves improving the current ARMv7 performance of Bullet to developers willing to extend and optimize the current vectormath library (code from oolong's vector math library can be used in Bullet's vectormath library, can't it?).

Have a good weekend ,

Panajev

[JarkkoL]

LGPL means, while you don't have to make your source code necessarily open source (like with GPL), you must have option to change the library for published applications (either by providing the library as DLL or providing static libraries of your app that can be linked). Now, this is completely unacceptable when developing for closed platforms such as Xbox360 & PS3 thus LGPL is not an option for console projects.