Crytek Open-Sources Their 'Renderdoc' 3D Debugger 20
An anonymous reader writes "Game studios now seem to be forming a habit out of opening up their debugger / development utilities. After Valve's notable VOGL debugger, Crytek has now decided to open source their Renderdoc debugger. Renderdoc had been available for free use since earlier in the year but now they have posted an MIT-licensed version of the code to GitHub. Renderdoc builds on both Windows and Linux but for now just targets the Direct3D 11 graphics API while OpenGL support is being expected later."
Re: (Score:1)
Re: (Score:1)
Because GPL-nazi.
NO THIS ISN'T A FLAMEBAIT. It's the freaking truth.
Re: (Score:2)
Re: (Score:2)
A lot of AAA development houses (including the one I work for) have a no-GPL policy for game engine code (you can only use in tools and then you still have to be careful).
And this is a debugger. So what are you on about? Do you normally ship the debugger with your game?
have a no-GPL policy for game engine code
Well duh. If you don't want to release a GPL product, you don't want to incorporate GPL code in it since you don't have permission to release it under a proprietary license.
But that's true of all 3rd p
Re: (Score:2)
I think the OP is talking about using GPL code in in-house-developed tools used in creating the game (level editors etc)
Re: (Score:2)
A lot of places are very wary of the GPL. Especially GPLv3.
One place I work now audits all the open-source/free-software code that enters the codebase. If it has a hint of GPL, it's almost always auto-rejected.
Oh, and by codebase, that includes the tools as well. Because some tools emit code, or otherwise touch code, and it's better to be safe than sorry.
Some GPL programs were allowed - e.g., gcc, but only the
Re: (Score:2)
A lot of places are very wary of the GPL. Especially GPLv3.
And the wariness is unfounded ignorant FUD. That's my point. I don't disagree with you that many places are very wary, but its generally ridiculous.
Other licenses, like BSD, Apache, MIT, no problem - those tend to sail through the legal license audit easily. They even went out to say no new GPL code would be accepted - look for alternatives.
For code going into anything you are going to release as proprietary this makes perfect sense. The GPL stuff w
Re: (Score:3)
I seriously doubt the AGPL is legally enforceable. It's a copyright license (so you can still use the software), not a "conveyance license", not to mention the output of a computer program isn't copyrightable.
Re: (Score:1)
Firstly, not being able to release in-house tools is a complete non-issue.
Secondly, if the programs are loosely coupled, the GPL, especially GPLv2, is very forgiving of proprietary code and GPLed code working together. You just have to mind your manners and know the rules. For the GPLv3, here are some basic rules from the GPL FAQ [gnu.org]:
For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
Furthermore, the system library exception may prove useful sometimes as well, though that is less common.
In conclusion then, while there is a kernel of truth hiding very, very well
Re: (Score:1)
Working as intended. If you use something that is GPL, you have to be sure to give it back, usually for free. When your business model depends on not giving up the entirety of what you made for free, the GPL is dangerous. Now the GPL is by no means an insurmountable obstacle to building non-free-as-in-beer software, but you have to watch your step. This is intended and necessary for what the GPL tries to do. I *like* the GPL because it prevents my code from being supplanted by proprietary derivative code. I
Re: (Score:2)
Interesting (Score:1)