Octane Not Worth the Grief

To any of you considering the move to Octane, do yourself a favor and reconsider it. After years of limping along with beta versions, they finally released a real version (not really - still beta level of reliability) .

Then, after promising a reliable Blender plug-in for two months, they finally respond with “we’re a couple of weeks from an ETA”. Not a couple of weeks from a release. A couple of weeks from an announcement regarding release date. All the while, many other plug-ins have seen more than five releases in the same time period. It really appears that they do not accept Blender as a serious platform.

As an avid Blender user for six years and a software developer for quite some time, I feel confident in saying this is something that should be avoided. The time has come for the Blender community to be taken seriously by third party developers.

Yeah, its not like they have to worry about custom versions of Blender and workarounds in regards to the GPL status of Blender… oh wait they do. Give them some credit for even bothering to begin with because they clearly went in knowing it wouldnt be easy to work around the unique limitations/obstacles tied to Blender. If it was much easier to put this stuff on Blender, you would see far more consumer grade options.

In which case the time has come for third party developers to be taken seriously by the Blender community (both developing & user). In cas you’ve missed the many discussions on the matter, Blender’s GPL license poses problems for anyone wanting to develop & distribute commercial code that Blender loads as a library.

As the plugin API is (currently) build completely around Blender’s internal code requirements, it must be license as GPL… meaning anything using it must also be licensed under the GPL. It might strike some people as odd, but not every develop can release the source code to their software for anyone to use as they see fit. Contrary to Stallman’s utopian vision of the world, making money from services around software doesn’t work for everything - especially renderers like Octane :wink:

I guess I just don’t get this license thing people go on and on about.

You can write your own exporter and do what you want…right?

There are no limitations to anyone personally writing code that connects Blender to another software package?

Exporter, yes. Integrated renderer ala Cycles? Not without having to comply with the GPL at this point in time.

Actually there are provided the code uses Blender API’s & one wants to distribute it beyond their own personal machine. The code using Blender API’s must be licensed in a GPL compliant manner. This prohibits the code from being proprietary unless you never distribute it (i.e. sell it). Given the nature of the third party development market in 3D software, making it a requirement that your plug-ins & add-ons are open-source for anyone to use for free is going to kill most projects before they even start.

There are ways & means around this, but they require focus from the Blender Foundation developers and it is a large chunk of work. I don’t see it happening outside Pixar or someone similar in size jumping on board.

That was an interesting post I just wish you didn’t stop were you did. In what ways could an integrated commercial render engines be possible with Blender, could a render API with a different license work?

So if I make an exporter I can not sell it on the Blender Market?

What is the point of the market?
The Blender Cookie guys are selling their re-topo tool.

What about Mocha Blend, it’s not free?

You can certainly sell it, the problem is, you also need to release the source code. If the source code is running free in the wild, then there is a large group of people who might take advantage of freely available addons, without paying. This isn’t as big a deal for the blender market, as the prices are fairly low. But if you want to release a high-end addon or renderer that demands a high price, then the developers have a lot more to lose.

As I wrote in the past, socket-based API for communicating between different processes while mantaing BSL-4 protection against Ebo… sorry, worse, GPL.

Let me see if I understand this:

The Octane renderer, like many others, is a closed-source application that exists outside the core 3D app. In order for the 3D app to send data to the external renderer, you need to write an exporter plugin. For Blender, that exporter plugin must be open-source. But the renderer itself can still be closed-source, right?

Blender (GPL) --> Plugin (GPL) --> External Render Engine (Proprietary)

So, how is this a problem at all for the external renderer devs? They’re still selling the renderer- their actual product- as a proprietary application, so why would they care if the exporter plugin has to be GPL compliant? The plugin is still worthless without the proprietary render engine, so they’re not forfeiting any revenue by releasing the source for just the plugin. And it can only benefit them to open the source for the plugin, as the Blender community can also contribute to its ongoing development. What am I getting wrong here?

It’s ok if the non-gpl stuff runs in a different process space than the gpl stuff. Thus, you need some form of inter proces communication between blender and the commercial third party plugin. This could for instance be sockets. In the case of a commercial renderer wanting to make a blender plugin, this wouldn’t even be such a big deal, because the communication is mostly one way (that is, at the beginning the mesh and such get send and a long time after that, the rendered image comes back) as it is when communicating with the GPU. However, when a commercial plugin is used to do something magical with the mesh, it is not so easy.

I once wrote a system where a server exposes the entire API to control an expensive piece of hardware to a client on a different computer. This is quite a bit of work. Consider the amount of work to do something similar for the Python API in blender, which is massive!

Of course you can. The thing is that the first person that buys it has the legal right to distribute it himself for whatever cost he chooses, including (and most often) “free”.

Most retail software incurs a large upfront development cost that needs to be paid for. You either have a client paying for that cost upfront (generally quite a large sum) or you amortise it over selling it to multiple people for a lesser sum. The more higher the cost of development the higher the upfront cost, the higher the per seat/customer cost, and/or the more people you have to sell it to in order to recoup your investment of time/resources.

When your customers are legally entitled to share your software code with anyone they like, you cannot rely on selling it to many people any longer so the software must be paid for upfront (i.e. how the community purchased Blender from NaN) or you find a completely different means of making money (i.e. keep the configuration less than user-friendly and have customers pay you for services).

You are getting nothing wrong. If the plugin communicates with the external render engine, which runs in a different process space, there is no problem with the GPL and also not with the revenue of the company. And for a render engine, the performance hit one gets from this whole process is also not a big deal as the rendering itself will take long anyone.

The thing is that the first person that buys it has the legal right to distribute it himself for whatever cost he chooses, including (and most often) “free”.

Are you sure about that?

That seems to undermine the entire Blender Market place. Isn’t there an agreement when you signup that you won’t do that?

I’ve run through this before in other threads, but I’ll outline it again.

The first, slower, and generally too-messy-to-bother solution is as outlined by PhysicsGuy. Namely the “out-of-process communication method”. You run a process that you can communicate through TCP/IP, UDP, etc and the GPL program connects to it and the two communicate over generic protocol. As ANY application can communicate with the TCP/IP program & there is no required linkage - it is not “derived from” GPL code and therfore need not be GPL licensed. The downside is that the applications are in two completely different processes and so embedded render windows and the like (ala Cycles) are incredibly difficult to the point of impracticality.

The second method is faster at runtime but requires alot more effort to develop upfront. To understand the legality, one needs to recognise and accept that the GPL only applies when distributing GPL licensed works. It does not, and legally cannot, apply in regards to USE of the work once installed as it is a copyright license not a contract. In other words, there are things the user can do once they’ve installed GPL software on their computer that seem counter to the restrictions on who they downloaded it from.

In a nutshell, the second method involves the creation & use of a generic plugin library that can be used by pretty much any host application or client add-on. The generic plugin library is licensed using an MIT/BSD style license (compatible with both proprietary & GPL applications) and is used by Blender for loading generic plugins and by generic plugins for use by any host applications that wish to utilise the plugin functionality. This library, for purposes of clean-room implementation, would most likely need to be developed by folks outside the Blender Foundation and would (by it’s very nature as a generic plugin library for 3D applications) sacrifice flexibility for the capability of being used by multiple host applications.

The reason this works is that whilst it is against the GPL for someone to distribute a proprietary library together with a host GPL application it is being used by, it is not against the GPL for the end-user to copy a proprietary library into his plugin directory and have the GPL host application load it by default along with any other ones there. Referring back to what I said earlier, the GPL only applies to distribution & copying, so as long as there is no GPL code in the plugin itself AND the plugin can reasonably be expected to run in another application - the end user is free to copy it wherever they like… including into a directory Blender might be looking for plugins with a given generic interface. :wink:

Thing is, it’s a lot of work & it would sacrifice flexibility, speed, and memory efficiency over a solution that can just plug straight into Blender API’s. Also, the plugin library used by native add-ons & Blender would need to be honestly generic, not just have the “generic” label applied. If it can be shown that the plugin library only really operates for/with Blender, there is a strong legal argument to be made that it is derived from Blender and therefore the GPL applies to any software using the library. If, however, a plugin can be hosted by Blender and (for instance) Modo - that argument loses traction outside the die hard “everything must be GPL” crowd.

For GPL and Creative Commons licensed items this is correct. The buyer is fully within their legal right to redistribute. In my experience, though, this very seldom plays out this way. It’s the same way in the Wordpress world. Most commercial themes and plugins are licensed as GPL and yet there’s a thriving commercial ecosystem.

So far as the Octane exporter is concerned I’m with Rocketman. I simply don’t see the issue and feel that development is likely being stymied by a fear of the GPL (and the loss of redistribution), when in reality that fear is probably unfounded. We surely haven’t had an issue with selling Contours while being GPL.

Do you fail to see the irony in saying that the Blender community needs to be taken seriously by the rest of the CG industry, while this sort of immature, on-and-on complaining is what this very “Blender community” is famous for?

If the Blender community consists primarily of users on this forum, then it has virtually no right whatsoever to demand that it be taken seriously. Instead of an unnecessary, subjective rant about how the Octane integration isn’t up to par, do something productive like souping up the existing Octane exporter. You are a software developer; it really doesn’t take much. That sort of initiative is what people used have, and it’s the only thing that ever gets anybody to be taken seriously.

Absolutely 100% positive. It’s been discussed before with the Blender Marketplace founders and you can actually check the license of the software they sell yourself if you like :wink:

No and, legally speaking, any such agreement would be null & void. The GPL does not allow extra restrictions placed on top of it - you have to give the “freedoms” (i.e. obey it’s restrictions) it requires or you are in breach of it yourself. The Blender Marketplace cannot add extra restrictions onto GPL software it sells; it is on the people that buy from the website as to whether they abide by the voluntary practice of keeping the purchased code a secret. They are not obliged to at all.

I don’t see what licenses have to do with any of this anyway.

The OP is suggesting that Blender artists not buy Octane, because Otoy is taking their sweet time updating a plug-in they promised to update (in addition to some other problems apparently). That’s all on Otoy. If Otoy wants artists using Blender as customers, the responsibility is on them to make Octane a worth-while purchase for them. It isn’t Blender’s responsibility to make Octane a satisfactory product for its customers.

Sorry, I went a little off topic but this related to Render exporters.

I am working on a render exporter now that exports directly from Blender and does not use any sockets or “tricks” to obfuscate legalities or complicate export.

So I can’t sell my AddOn in a complied state on the Blender Market then?