Slashdot Mirror
Havok Releases Free Version For PC Developers
An anonymous reader writes "Havok has released the free version of its widely-used physics and animation engine (but without source code), including tools that integrate with Autodesk 3ds Max and Maya. Developers may use Havok for free for non-commercial games, middleware, and academic projects. Here are the SDK and tools."
not free.
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
gonna render a babe for this saturday night!
Havok wasn't obligated to do this. It is a kind (and perhaps savvy) gesture. I can't wait to see all the open-source Linux shooters integrate Havok. How long before it is in Ogre 3D and common engines like that?
I think it might be savvy, that if physics become common even in free games, that consumers won't want to pay for a commercial game unless it features physics as well.
I recall a while back someone was trying to create a homebrew engine that would play Jedi Knight levels, and it was a fairly impressive engine, except they couldn't finish it because they couldn't find a coder who could integrate even basic physics stuff. People looked and looked on all the usual sites, but it seems not many people know that stuff.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Although, when they said May I didn't think they would release it with only an hour to spare..
The truly free ones include: ODE, Bullet, Tokamak and Newton(IIRC)
From the Terms and Conditions (http://tryhavok.intel.com/terms.php), it seems as though:
You can distribute a Havok-enabled game, as long as Havok cannot be separated from it by the end user.
You can distribute game middleware/game engines/game tools as long as Havok is not included in them at all (I guess the end user will have to get their own license)
Where game mods fit into this I am not sure.
I'm not a lawyer, blah blah blah
The above sentence is self-contradicting)
Why would OSS want Havok? We already have Bullet, it's actually Free Software, and widely integrated. This release of Havok is due to the Free Software physics libraries gaining traction in the commercial game development world and eating into Havok's market.
I don't know that the GPL expressely forbids linking to non-GPL libraries. However, there is definitely a license conflict between Havok and the GPL. . .
From the Havok license:
"i. publicly demonstrate, and publicly distribute a Havok-enabled non-commercial end-user compiled, binary executable software application or game for the Windows PC Platform, in which the Software is compiled and distributed within the software application or game in an integral, non-separable way, for no direct or indirect commercial value;". Notice, particularly, "compiled, binary executable. .
From the GPL v3 (GPL v2 is basically identical in this regard): See section 6 (not copied here because it's fairly long). In a nutshell, if you distribute binary/object code of the GPL'ed work, you MUST offer recipients access to the source code. So, if you honor the terms of the Havok license, you violate the GPL, or vice-versa.
Also from the GPL v3: See section 5, wherein the user is given permission to modify the work and distribute copies, but those copies MUST be licensed with the GPL (and so the user gets permission to modify the work). Access to the source code, and the right to modify it, means that end users could seperate Havok from the GPL'ed software. So, again, you would have to either violate the Havok license (by providing users access to the source and the right to modify it), or violate the GPL.
There's absolutely no way you can simultaneously abide by the terms of both the Havok license and the GPL.
The thing is, the Havok free license requires you to distribute your whole software package as binary only. That's incredibly un-friendly to Open Source. Sure, there could potentially be an open source license which doesn't require shared libraries you link to be open source as well (actually, in reading the GPL, I think you could make the case that you could even distribute your software under the GPL if it links to proprietary libraries, because in as much as those libraries are not really part of your program, they wouldn't have to be covered by the GPL), but even if you used such a license for your software, you STILL couldn't link your software with Havok, because the Havok license *requires* you to NOT distribute source code to people. The Havok license is FAR, FAR more restrictive and obnoxious than the GPL ever was or will be.
It does not support Visual Studio 2008. Only 2003 and 2005. Boo!
It does seem to be more than a physics engine, though. It comes with an asset manager with plugins for 3DS, Maya and XSI to ease conversion of scenes into Havok. This could be seen as additional features or bloat depending your point of view.
What I want to know is: how does it compare to the existing Open Source physics libraries, such as Bullet (which was made by an ex-Havok developer)?
Open source software can integrate Havok. I can write a program and release its source and not be GPL.
> I think it might be savvy, that if physics become common even in free games,
> that consumers won't want to pay for a commercial game unless it features physics as well.
Very large numbers of extremely popular games don't need any physics, e.g. Puzzle Quest. And the majority of the game-buying public neither knows nor cares anything about physics or the engine that runs the game.
Consumers will pay for what they enjoy. Physics, presence or absence thereof, doesn't enter into their buying decisions.
I piss off bigots.
Given that no closed source game is going to GPL themselves instead of pay for a license why didnt they just GPL the thing and let open source games benefit? I'm no Stalmanist but in this case there is no down-side to GPLing it only extra geek credit.
IranAir Flight 655 never forget!
NVIDIA's PhysX library is free to use and will soon have hardware physics support on Geforce 8+ cards. The days of pay-for physics middleware is over.
Is this for PC? (Windows, Gnu/Linux, OSX, Solaris, PS3, Xbox360, etc users..) or just for Windows?
:P
If it's just for Windows then why does it say PC?
You know that PC != Windows...
-Seeing the problem is ½ of solution-
It seems to be a bit of a murky area, but here is my interpretation of the matter. Please note: IANAL. The quotes are taken from the GPLv3; as far as I can tell, the GPLv2 says much the same thing, albeit less explicitly.
From section 1, "Source code":
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.I would say an application which makes use of the Havok SDK is "specifically designed" to require it. I don't think one could get away with saying it's a "System Library", either (a System Library being defined earlier as, in essence, something which interfaces with parts of an application's host OS, if any). Hence, the source code of the Havok SDK is Corresponding Source, IMHO.
So, what requirements does the GPLv3 place on Corresponding Source?
Sections 4 and 5, "Conveying Verbatim Copies" [of the program's source code] and "Conveying Modified Source Versions", do not mention Corresponding Source at all. From this, I would draw the conclusion that provided you are distributing your application in source code form, you do not have to re-distribute Corresponding Source.
However, from Section 6, "Conveying Non-source Forms":
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this LicenseSo, if you are distributing binaries, you must distribute Corresponding Source, which obviously requires you to have access to it. In the case of the Havok SDK, this is clearly not the case.
This requirement is, in my opinion, linked in with the "anti-Tivoisation" measures incorporated into GPLv3; however it also has some importance when considering continued access to - and historical preservation of - useful software. It means that something licensed under the GPLv3 and distributed in binary form cannot be specifically designed (think "modified by Corporation X") to require closed-source components which do not qualify as System Libraries or Major Components of an OS. It also means that if a third-party library falls out of maintenance, it can still be fixed and updated as required to enable applications requiring it to keep working.
So, to summarise:
Please note that I have not read the Havok SDK's license. It may or may not lay out requirements of its own for programs which prevent the scenario under discussion, but AFAICT, the GPLv3 itself doesn't prevent usage of closed-source libraries per se, provided you stick to only giving out source.
* Similar - but by no means identical - to the provisions in the Mozilla license which require distribution of binaries compiled by third parties to have all Mozilla-related trademarks removed. Debian et al. rebrand Firefox as a result; source-based distributions such as Gentoo don't innately prevent usage of official branding because they only distribute source code, but make doing so optional, and make it clear that doing so means you can't re-distribute your own binaries after compilation.
I know it's incredibly bad form to keep replying to my own posts, but I think this is an important subject. :) Please see also http://www.fsf.org/licensing/licenses/gpl-faq.html#FSWithNFLibs and http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs. These seem to largely agree with my viewpoint that it isn't inherently prohibited, but there may be legal problems, and you should consider adding exceptions to your program's license to explicitly allow linking with required non-free libraries.
However, their arguments seem to rely on the concept of linking - including static linking - being some sort of "magic" that results in a derived work. Not everyone agrees with this concept, provided that what you're linking with isn't modified. For example, see this LKML post by Linus Torvalds: http://lkml.org/lkml/2006/12/17/79. His views basically boil down to static linking being a form of aggregation, and dynamic linking of separate works having even less bearing since it doesn't necessarily require distribution of both works. Both, however, having bearing on whether or not two works are independent.
Wikipedia claims that it supports linux but on their site there are no downloads for linux. only for win32. So it is better to use AGEIA PhysX for free crossplatform apps in case you dont want an opensource physics engine.