Hi. What if Blender Foundation develops along with Blender 2.8 a new app that allows non-GPL plugins to be compatible ? The app could include the new Blender viewport licensed as Apache, as well as an importer for .blend files. If you have the app on your PC, Blender could open it automatically when you have to export something such as a .fbx file. In this way, Blender can indirectly make use of proprietary technologies like Substance, Nvidia Hairworks and more.
The new viewport isn’t something you can just “take out”, it can’t work without a platform - that platform is GPL-licensed Blender. You’d have to create a new platform application.
Blend files don’t really work without Blender, either. To make sense of all the data, you basically need Blender. If you want to support only a subset of the features, a different (exchange) format would be better.
Either way, Blender can already indirectly make use of non-GPL compatible software, by invoking it through the filesystem or the network. This requires application-specific glue code, but it’s doable and it has been done.
Now for the question of “what if the Blender Foundation did…” - who cares? They’re not doing it. They could’ve provided an FBX workflow using a separate application, but they didn’t because they don’t want to.
I can’t find a source right now, but I remember that Ton opined on the mailing list (in a similar context) that he doesn’t want Blender to become a host for commercial plugins.
What the userbase can do is take care of these things themselves, instead of waiting for the BF to fix all their problems. This means funding independent development, which means taking up risk. The unwillingness to take up risk (next to the lack of money) is probably the biggest hindrance. The users always want the BF blessing for everything.
It’s about principle about that. They are a foundation for creating the best open source 3d application. FBX is not open source and it would not make sense to spend time and money on something that is owned by a private company. Ton is pushing for an open standard.
I don’t disagree with what you are saying, about principle and that. But I also don’t disagree what Beerbaron said neither. Unfortunately BF is in a dilemma; they want to create an open source solution for both hobbyists and studios. We know this because Ton also has some ambition for cgi movies (open or commercial). They also acknowledge that they can’t do everything themselves and or make a perfect tool set all at once.
So multiple business owners and the experienced people in the industry said a bunch of times that Blender can only be popular and in demand if its integrated into existing pipelines. If it can be integrated easily then it would be in use in pipelines thus allowing more exposure to developers or technical artists which then more studios would be willing to tackle issues or help with development; or support the development fund.
But even in essential issues like FBX, this “principal approach” is blocking the way forward. I personally think BF lost at least couple of years during 2.5 era just because of this issue and it is still “an issue”.
Why not do parallelism? We all know fbx sucks, just integrate it (with the sdk) and move on, nobody who needs fbx in their pipeline would object to installing the sdk. And while that problem is solved, create or integrate another format like glTF or USD. Meanwhile you can also do your lobbying against FBX to the studios who use blender in their pipelines.
Same goes for substance… people use it, people want it. It doesn’t matter that you can do the same thing with cycles nodes, using substance tools is convenient. People have libraries of substances, all other 3d packages support it, all but blender that is.
Blender is tackling some of the problems itself creates…
I understand what you are saying. But the licensing of Blender and even the laws about foundations makes it practically impossible to make this happen. You can’t even look into the source code of FBX to make an open source exporter, because the code is owned by autodesk.
The FBX exporter blender has was made from scratch to not have a single code snippet from autodesk version of fbx exporter.
Meanwhile there are other standards that almost are the same but are not good enough, epics unreal engine guy told Ton that the problem was that there are many open source like FBX but there is no standard between all the applications.
If the industry said “let’s use this open standard for exporting” and they implemented it then FBX is gone. But why should they waste time changing on something that just works.
Cool story, but that solves nothing and it’s really damaging to adoption. Yeah, Blender is resisting that evil monopolistic corporation by not properly supporting its proprietary file format. Who cares? People just need FBX to work, not a Don Quixote tale.
Which users buy into that whole ideological approach anyway? If there really were so many people interested in getting rid of FBX, why isn’t there a replacement format being worked on? The reality is that FBX works well enough and only Blender has this problem. The world isn’t going to bend over backwards to support it.
That is not true. To support FBX, you don’t have to look at source code or the file format at all, you use the FBX SDK. The Blender program itself can’t use this SDK, because it’s non-free software and the GPL won’t allow such a combined work. However, anybody (including the BF/BI) could create a separate program that converts FBX into Blender-compatible data.
There’s no “foundation law” that prevents this either. They just don’t want to do it. They don’t want to license Autodesk software and agree to Autodesk EULAs. That’s completely understandable and probably a good idea from a legal standpoint, just to be safe. On the other hand, reverse-engineering the format probably isn’t a good idea, from a legal standpoint.
What also could’ve been done is to support a third party to provide this conversion tool and have facilities on Blender’s side (i.e. a serialization format that isn’t unusable like .blend) to make this exchange efficient and relatively painless.
Meanwhile there are other standards that almost are the same but are not good enough
Not really. The closest is COLLADA, for which support sucks everywhere.
First of all (as the last paragraph admits) this whole issue is moot since the GPL doesn’t allow using the SDK anyway. As I described, there needs to be a second program that is distributed under a different license.
Also, what this page seems to claim (it’s not quite clear) is that you must license a program using the FBX SDK under any of the licenses shown in “Exhibit B”. The LSA doesn’t actually say that, it says you must license “without warranty” (a standard clause, also part of the GPL).
This seems to be a misunderstanding due to poor formatting. The FBX-SDK specific parts have been pasted right into what is a section of the standard Autodesk license agreement. The license types described in “Exhibit B” apply to Autodesk software, not applications using the SDK.
For comparison:
FBX SDK (FBX-specific parts in bold)
1.1 License Grant. Subject to and conditioned on Licensee’s continuous compliance with this Agreement and payment of the applicable fees, Autodesk grants Licensee a nonexclusive, nonsublicensable, nontransferable, limited license to Install and Access the Licensed Materials, in each case solely (a) in the Territory, (b) within the scope of the License Type and Permitted Number specified in the applicable License Identification, (c) in accordance with the other terms of this Agreement, and (d) specifically as follows:
1.1.1 (a) use the SDK for development, research, internal, educational, or commercial purposes:
(i) to create a software product with the capability to read and/or write and/or translate Licensee files, which software product links to the Library (“Developed Software”); and/or
(ii) to modify the Sample Code(s) solely to create an object code version(s) (“Modified Code(s)”); and/or
(b) reproduce the Library to link to the Developed Software.
1.1.2 (a) incorporate the executable version of the Developed Software into; and/or
(b) incorporate the Modified Code(s) into; and/or
(c) link the Library, in binary code form to;
software products developed by Licensee (“Licensee Product(s)”) for Licensee’s Internal Business Needs
1.1.3 reproduce, distribute and sublicense free of charge or for a fee Licensee Product(s) provided that Licensee must sublicense the Software, the Developed Software, the Library, the Sample Code(s) and the Modified Code(s) “as is”, without warranty of any kind.
Various License Types are described in Exhibit B. In any case where the License Identification does not specify a License Type or Permitted Number, or there is no License Identification, the License Type will, by default, be the Evaluation License and the Permitted Number will, by default, be one (1).
Autodesk LSA
1.1 License Grant. Subject to and conditioned on Licensee’s continuous compliance with this Agreement and payment of the applicable fees, Autodesk grants Licensee a nonexclusive, nonsublicensable, nontransferable, limited license to Install and Access the Licensed Materials, in each case solely (a) in the Territory, (b) within the scope of the License Type and Permitted Number specified in the applicable License Identification, and (c) in accordance with the other terms of this Agreement. Various License Types are described in Exhibit B. In any case where the License Identification does not specify a License Type or Permitted Number, or there is no License Identification, the License Type will, by default, be the Evaluation License and the Permitted Number will, by default, be one (1).
Being forced into a license model outlined in “Exhibit B” would be completely unacceptable for many FBX SDK users (such as Unreal Engine), not just FOSS software.
Either way. I agree with Ton on this. If it’s that safe to implement FBX support then why doesn’t Autodesk make it open? Autodesk has nothing to lose on that, or atleast make it less “licensy diffuse”.
I think this is mora a fail safe from Autodesk. If for some reason Blender takes over some of their buisness they can send lawyers to stop their sdk working with blender.
Unreal is not their competitor. Blender could be.
Why are you asking me? I’m not sure they have nothing to lose. Maybe they just don’t care. Again, only Blender (or rather only GPL software) has this problem.
Having read the license, I don’t see anything directed particularly against FOSS, the section concerning “Open Source” is standard stuff for proprietary software. It should work with a FOSS program licensed permissively (but don’t take my word for it).
I think this is mora a fail safe from Autodesk. If for some reason Blender takes over some of their buisness they can send lawyers to stop their sdk working with blender.
Unreal is not their competitor. Blender could be.
There’s about five 3D applications that are competing with Autodesk before Blender comes into the picture, most of which I believe are using their SDK.
If Autodesk wanted to send their lawyers, they could probably send them just for the reverse engineering part or for using the registered trademark “FBX”. Some would argue that reverse engineering of a file format is entirely legal, but that doesn’t protect you from a lawsuit.
Blender is already their competition, I already know many people that is shifting towards Blender, wich will attract more money to Blender, and they will abandon Autodesk software, and the first one I know it’s my self, I’ve been a teacher of max for some years, a good max follower XD and a good “evangelist”, but I was all that when they worked for me and for the software, at the very moment they started forgeting about evolution and started thinking in just drain customers, I started to shift towards other packages, Maya was my first choice, but it was also Autodesk, then I started studying several options, and the one I liked the most was Blender, not because it was free, but because the software it self, but it lacked some tools for production and interoperabiltiy, like Alembic, and the cycles lacked some things, like a shadow catcher, those were basic to our workflow for offline productions, right now we are working in offline and real time productions and we’ve not been using Autodesk software so far, just for old projects, so we can extract part of the old material, and I don’t miss a thing.
I’ll start another thread so I ask about what do FBX lacks in Blender, because apart from some small things that I don’t care too much, I can’t find much problem with it, but…
… and this is a big but…
… USD is being developed inside UE, it will probably come also to Unity (even when we don’t use Unity anymore because their shift towards rental only) and it is open source… why should we still rely in FBX? What we need is a development over USD wich is open source, or an evolution of Alembic, wich is also pretty usable, even with bones and animations (I’m not sure if Alembic in UE just picks Mesh Deformation or if it works like FBX, but I’ll test it)
So again, FBX is a thing from the past, IMHO it should be left as it is, and development should be done towards more modern and open source standards like USD, I hope this is possible 
Cheers!
Blender is already their competition, I already know many people that is shifting towards Blender, wich will attract more money to Blender, and they will abandon Autodesk software…
2017 - Year of the Linux Desktop
… USD is being developed inside UE, it will probably come also to Unity (even when we don’t use Unity anymore because their shift towards rental only) and it is open source… why should we still rely in FBX?
People will need FBX until USD is adopted widely, which might never happen.
What we need is a development over USD wich is open source, or an evolution of Alembic, wich is also pretty usable, even with bones and animations (I’m not sure if Alembic in UE just picks Mesh Deformation or if it works like FBX, but I’ll test it)
Alembic is not an exchange format and doesn’t want to be. Integrating an exchange format (especially one the size of USD) is a large amount of work.
So again, FBX is a thing from the past
FBX is a thing of the now.
As someone who works in software development outside of 3d, I can’t fathom how the 3d world is still ok with relying on proprietary formats like FBX, everywhere else I see an ever increasing embracing of open formats (almost always accompanied by functional reference source code) and proprietary formats being a total no-go.
I guess I have to chalk it up to the massive grip Autodesk has on the 3d market.
Where are you looking? Most developers never get to see outside their own industry. I’d say proprietary formats are alive and well. Or are you talking about the serialization format, e.g. JSON and XML? Those are indeed common, but just because you can “read” the data doesn’t mean you can make effective use of it. FBX also has a very readable textual format.
video, audio, image, general data compression, documents, spreadsheet, hot-right-now technologies like containers, etc, heck even Microsoft is increasingly open sourcing large parts of their stack.
Basically everywhere outside of the 3d world, or am I missing something ?
I often get the impression that people use or implement FBX in their pipeline because they don’t want to lock their resources in managing and maintaining a whole branch of custom formats. Here is an example. The firm I use to work for used/uses a custom format, it is basically a text file written in streams of data that contains floating point numbers and strings for vertices, UVs, materials, bones, and bone rotations. It was first made to work with a custom branch of Blender 2.4* (a python script) however when the firm hired an professional artist he prefered 3dsMax so based on the format specs an exporter script was written for max. When I started there were 5 artists around and we used this version… after I left the firm, they hired some more artists and some of them used Maya, even though they had their own format and had a working 3dsMax script (which was updated regularly) the lead programmer chose not to write a plugin for Maya and implemented FBX to the custom game engine instead. Now you might call this lazy, but implementing a new format to the engine is more work than writing a export script for maya. I wasn’t able to ask why they did this (supporting both custom format and FBX), but I think it is because the engine/graphics team had their hands full as is and didn’t want to maintain other scripts for yet another 3d package (which might have different workings than max).
So firms might depend on Autodesk to maintain and manage of exchange format, rather than dealing with it themselves. Maybe USD and Pixar can break this cycle. Since Pixar is not a small player and might ensure firms trust to try and use that format.
Let me take a guess: You’re a DevOps dealing mostly with software about other software, plus whatever you deal with as a hobby.
Basically everywhere outside of the 3d world, or am I missing something ?
There’s a whole galaxy of software products you probably never heard of (take a look here).
Yes it is really weird.
Maybe leassons learned making the new open 3MF 3d printing format (done in a open industry consortium), will make it easier to get going with developing a open general 3d format with industry backing. One can only hope.
Unless someone steps up to actually write the code or pay someone to do it, such a BlendLink is a pipe dream anyway. It’s not going to write itself, and there is no incentive for the existing Blender developers to do it.