Hacker News Reader

Comment by reedlaw | Hacker News Reader

Although I'm happy to hear this news, it highlights the importance of Blender's choice of GPL as its license. If it weren't for the GPL, Valve would be free to modify Blender and then sell it without contributing anything back to Blender. Blender is an amazing app that I've enjoyed using for many years. It's definitely in my top 10 ten list of best open source projects. Hopefully the increased exposure through Steam will only help the Blender Foundation continue to provide incredible free software.

View on HN

That's a strange conclusion to reach. The GPL license is actually a major problem with Blender. Importing and exporting content from artist tools is a huge headache. The Autodesk FBX file format and SDK have largely solved those issues. It's a phenominal interchange format and most professional tools support it out of the box. Just drag and drop. It's wonderful.

Blender does not and will not have official FBX support because of the GPL. That's unfortunate and actively harms users. Providing support for user generated content is a lot of work. Trying to support Blender is extremely painful and adds to that pile of work.

I'd argue that one of the single biggest issues with Blender right now is it's GPL license.

http://wiki.blender.org/index.php/User:Ton/Autodesk_FBX_EULA

I wouldn't say in this case that the problem lies with Blender's choice of the GPL, but rather with Autodesk's FBX license. The FBX license is much more restrictive and onerous than the GPL. Whether GPL is freer than BSD-style licenses or not is debatable, but it certainly respects the user's freedom far more than Autodesk's "Evaluation License" with "Permitted Number equal to one".

Yeah. "Releasing" a file format as a restrictive binary SDK rather than actually documenting the format is a really weird and aggressive thing to do, and is very much Autodesk's fault rather than Blender's, even if you ignore the issues with platforms for which the binary might not be available.

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.

Blame whichever license you want. It doesn't matter.

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.

"Blame the gun or the guy who died for not having a steel skeleton, it doesn't matter. The guy is the one who's dead, the gun is fine. The onus is on guys to not die."

If we're going to make this analogy work, the guy who died could have easily worn a bullet-proof vest or avoided getting in the fight at all.

Or he could have picked a different software license.

lol

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.

What does "awesome format to work with" mean? You're not working with the format.

even LGPL would have been preferable.

Oh, and licenseless download-and-"what license?"-type warez seems to be the most wholeheartedly welcomed option with the general crowd.

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

http://code.blender.org/index.php/2013/08/fbx-binary-file-fo...

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

If that's all the docs they have, they might have a long way to go. FBX is a pretty huge spec. I find it hard enough understanding the SDK docs.

"The Autodesk FBX file format and SDK have largely solved those issues. It's a phenominal interchange format and most professional tools support it out of the box. Just drag and drop. It's wonderful."

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)

Someone please correct me, but isn't the FBX SDK a proprietary licensed software?

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.

Why can't they make the user download it?

And possibly adjust how the linking works to avoid issues.

I don't understand what your GPL comment has to do with this situation at all. Nobody is even talking about modifying blender in the first place, let alone improving it in ways that could be contributed back, let alone would they have any reason not to contribute back.

This is just asking the blender community what they think about some distribution and upload scripts.

"We'd hope that this will get enough of our users exposed to and interested in Blender so they will be inclined to work on Blender plugins that would talk to Steam's backend services such as Workshop."

doesn't sound like a modification to you?

'make a plugin for' doesn't sound like a modification of the original, no.

And even if it was, I don't see why BSD changes wouldn't get shared back here.

Doesn't sound like, but (probably) is. http://www.gnu.org/licenses/gpl-faq.html

"If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in? (#GPLAndPlugins) It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

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."

http://www.blender.org/education-help/faq/gpl-for-artists/#c...

"Can I sell plug-ins for Blender?

Yes you can, but only if you provide the plug-in and the sources to your clients under the GNU GPL license. The client then benefits from all rights the GPL offers; free to use it, or even distribute it when they wish.

Only if the plug-in doesn't work within Blender as "acting as a single program" (like using fork or pipe; by only transferring data and not using each others program code) you have the full freedom to license the plug-in as you wish."

What process the code runs in is a complete distraction, I'm going to ignore that part. It has nothing at all to do with linking or derivation.

Anyway, we're talking about plugins that upload files to steam with a simple interface, so they could easily be independent code, sharing no internal data structures.

I'm not ad-libbing, you're arbitrarily deciding to ignore the GPL, with no justification. It's not a distraction, it's the whole point.

If Blender is GPL but the plug-in interface is Python and thus only GPL-Compatible, why can't the plugin be GPL-Compatible and thus not require providing sources?

Because the critical point isn't the use of python. The critical point is that your plugin code is running in the same O/S process as the parent application.

Also I don't think that's how "GPL Compatible" works.

At this point there is no talk of modification, but if Blender became a large part of Valve's modification ecosystem there would surely be some back-and-forth source modification going on.

While Valve wouldn't be able to rerelease blender with new changes unless the changes themselves are released under the GPL in some form, there's nothing stopping them from making changes and using them internally. If they want to make tools available to their community and cannot do so under the GPL, they can aways use a dual-licensing scheme.

You can't dual licence someone else's GPL code. That's why companies that want to do this need contributers to assign copyright. For existing projects this would often be too much work to be worth the bother (though not impossible, I believe x 264 did this, and Firefox has done similar things in the past).

Couldn't they dual-license just their own modifications?

As a big fan of the GPL, ...I'm skeptical. I don't think Valve would benefit from keeping any potential modifications (or even plugins) secret, given that these would be far removed from its bread-and-butter.

A friend once suggested that outside of licensing pressure, maintainership is a huge driving force behind open-source contributions: you find something that does almost what you need, then you make the changes you require, and if you get these accepted upstream, they're maintained for you for free, pretty much forever. In many situations, that's far more important than any IP you're trying to conceal.

Because it's far easier for a manager to say "no" than to say "yes". By not releasing code, he's running less risk than by releasing code. There might be a chance that he missed something and violated copyright somewhere, accidentally leaked some company secret, or accidentally gave competitors an advantage. Saying "no" is the easier choice.

In case you missed it, there aren't any managers at Valve... http://news.ycombinator.com/item?id=3871463 http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...

Why do you assume that?

The SDL developer works at Valve, and he just released 2.0. I don't see why they would do such a move on Blender...

Are you describing copyright? ("Valve would be free to modify Blender and then sell it without contributing anything back to Blender.")

Reply on news.ycombinator.com