On the other hand, the format does not appear to actually be that complicated, so integrating the SDK probably wouldn't save that much programming time compared to just reimplementing it.

Let's say it is Autodesk's fault and they don't care. Now what? Blender is the tool that's a pain in the ass to use so the onus is on them to make their tool not suck. Meanwhile the rest of the world will continue to use FBX because it's an awesome format to work with.

You are the one who was all "GPL hurtz dem users!!"

You're probably right with your assumption that FBX is awesome, but this wasn't part of the debate.

Free Software's there for a reason. Let's not forget that. And if we stick to that (i.e. not trade freedom to whatever feels comfortable at the moment), there's a good reason to not use LGPL instead of GPL: http://www.gnu.org/philosophy/why-not-lgpl.html

Blender’s next release (2.69) will support binary FBX file reading as well.

Really? To me it looks like what Autodesk have managed to do is convince loads of people make their software depend on Autodesk's proprietary binary blob, which is a genius move on their part.

(bet you've never seen your wonderful "just drag and drop" work on anything non-x86)

If blender want to redistribute Autodesk software, they would need a license. The FBX SDK looks to be under a restrictive, individual, non-transferable and non-shareable license which also expires after 30 days. That would make any redistributing of said Autodesk software a crime (copyright infringement).

The only way blender could legally give users access to the proprietary FBX SDK, is to provide a download mechanism where users themselves download and agrees to the license, and then have their software being disabled after 30 days.

So I must ask, what does this have to do with GPL? It would still be equally impossible under BSD, MIT, or add-your-own-license-here license.

And possibly adjust how the linking works to avoid issues.