blueprintrandom
[Apologies in advance: Jed touched on multiple issues that I wanted to respond to and they were lengthy… wall of text incoming!]
Theoretically possible, but not quite true in practice. My personal project has been working out ways to add a native code plugin interface to Blender that allows for proprietary plugins legally. Whilst I am not aware of any major court cases on the matter (nor were the lawyers I’ve consulted over the years), there is a pretty clear agreement on how one can allow the loading of native libraries… and it means including no non-GPL compatible headers or libraries (outside those needed for system features &/or standard C/C++ libraries as per the license).
The Splice API is not BSD/MIT or anywhere near GPL-compatible, which means the code to be included into Blender cannot use it. In order to write the plugin you are discussing, one would need to write a plugin host API that provides all the features of the Splice API, yet isn’t actually using any FabricEngine headers or function prototypes. That’ll be licensed under something like BSD/MIT. Let’s call that GenericAPI.
In order to do this without threat of legal issues, it would need to be a cleanroom implementation, with example plugins demonstrating it’s use as something other than a copyright workaround to both the GPL & Splice license restrictions. This is a @#$%ing huge task - trust me, I’m working on the job WITHOUT the added difficulty of having all of Splice’s functionality!
Then you would need to write a GenericAPI-to-SpliceAPI plugin, with the added overhead of transforming all inputs from the host software to GenericAPI data structures and then, from there, to SpliceAPI data structures. At that point, after two layers of memory read/write, FabricEngine can do it’s thing. Remember, FabricEngine 2 involves two-way communication for features like the renderer and what-not, so you’ve got to make that communication path efficient - even through that extra layer of data conversion.
So yes, it’s possible, but who in their right mind would do that? Two layers to push the data through simply to convert it from an internal format, to a GenericAPI “thunk” format, only to convert it again to a Splice format? Who wants to manage that going forward? Given the Blender Foundation’s ambivalence to animosity on commercial plugins & proprietary code workarounds (depending on who you talk to on which day of the week) - they’re not going to merge it into trunk.
I’d be more than happy for someone to have a means to use FabricEngine merged into Blender. It’d save me a lot of time and bring with it some of the awesome already in FE2. I just don’t see it practically occurring because of both license restrictions (in Blender & FE) and BF issues with allowing workarounds to said license restrictions.
This is the angle I am most interested in. A market for 3D plugins much like there is for Photoshop… except it can be used by all the platforms? That’s something I’d be very happy to have access to.
That’s not to say there aren’t (huge) advantages to the Technical Directors and the like in large studios, but I think any mass market appeal will come from being able to use that same deformer plugin you saw Artist X use in Maya in your installation of Max. Game engines being able to write an exporter that works in ALL the major DCC software. And so on.
The CPU/GPU thing does depend on the KL code itself (& what functionality it uss). I don’t personally put a huge amount of weight into that particular side of it because all it takes is one bad call, compilation going one GPU program instruction over an internal limit, etc and the KL script goes from GPU execution speeds to CPU speeds.
What isn’t mentioned here and where KL has a huge leg up over the Gaffer/OpenAlea libraries is that KL is truly threadable. Python has threading capabilities but, in practice, only one thread can run Python code at a time. The GIL has been around forever and there isn’t much in the way of plans to get rid of it (at least in CPython). FabricEngine can run KL code on multiple threads at the same time, meaning complex but separate DAG’s can be evaluated simultaneously on today’s multi-core machines. More cores active on a render-farm node means faster renders 
I would think you could just create a commercial plugin for Blender, could you not? Then you sell it separately. And as long as you are not redistributing it as Blender, it can be any license you desire and pick one that allows you to conform to the Fabric license.
I believe this is how Octane plugin is sold. Maybe something I am missing in there. But it seems perfectly legal to go that way.
yar, if I sell my game using system A. distributed elsewhere, I can sell my game right without GPL ?
there is no binding done on my end or bundling right? the GPL applies when distributed, not to what the end user does?
(I am selling wrectified GPL however I am making more then just Wrectified)
BPR; Please read the thread again, this isn’t even remotely related to actual game creation, game publishing, or the BGE (but about a general purpose application-agnostic tool creator for general 3D work).
"I would think you could just create a commercial plugin for Blender, could you not? Then you sell it separately. And as long as you are not redistributing it as Blender, it can be any license you desire and pick one that allows you to conform to the Fabric license.
I believe this is how Octane plugin is sold. Maybe something I am missing in there. But it seems perfectly legal to go that way."
Dis is good
Yes, that is exactly what we’re talking about. However I think you are missing the fact that the “hooks” into Blender (i.e. the code that takes a Blender mesh, animation, etc and passes it over to FabricEngine) need to be GPL-compatible.
You need to add new code to Blender to load your commercial plugin and that new code needs to be licensed in such a way that both GPL applications can use it as well as proprietary applications. Otherwise you cannot distribute the new Blender executable and
As I understand it, Octane have customised Blender with GPL-compatible code in the way I describe above. They have added code to Blender 2.68 that they have copyright to (releasing it under a GPL-compatible license) called “Blender OctaneRender Edition”. This customised Blender loads the Octane libraries at runtime (which are distributed separately to their Blender executable) allowing it to use their commercial/proprietary engine.
The key here is the customisation of Blender & the license of those customisations. OToy have customised a version of Blender 2.68 with their own code. We can request a copy of that code if we want and they are obliged to give it to us. We’re also free to pass that code on. FabricEngine’s API/SDK is not licensed in that way. If we want to do the same with FabricEngine as was done with Octane, we need to write our own code that duplicates the FabricEngine API, integrate it into Blender, and license the code such that everyone is allowed to request it and pass it on in a GPL-compliant fashion. Duplicating API’s is a treacherous road legally (see Oracle v Google), so whilst technically possible - without support/permission from FabricEngine, it’s a non-starter.
@BPR: Please, for the love of god and all that’s decent, stop trying to mix BGE into this. This thread has nothing whatsoever to do with the BGE. Zero, nada, bubkus, zilch.
Yes, we know you’re obsessed with the bloody thing, but at least have the decency to keep it to threads even barely relevant.
Yeah, that goes for plug ins as well right?
if I were to publish something that the end user then bound to blender, how does that fall under GPL?
Can blender expose pathways for the program to edit in a generic way?
grab data, put back data , no hands no about the other?
like a game loop?
Yes. When you find me talking about plugins in a thread where someone else hasn’t brought up the subject, feel free to let me know it’s off-topic. This thread, however, is about the FabricEngine which is an SDK for plugins and others have raised the possibility of writing a plugin to integrate it.
Discussing the development of plugins in a thread about a plugin SDK and where people are discussing development of a plugin to use it is perfectly on-topic. The BGE is not. Take it elsewhere because you’re back to spamming threads and it’s @#$%ing annoying.
Depends on what that something is and what it relies on to run. If, like scripts in a BGE game, it uses GPL’ed functions and/or GPL’ed interfaces - that’s going to require the published work to be released under a GPL-compliant license.
Yes it can. However, it currently does not. Kind of the point I’ve been making.
I am blender, when you do a command
I edit data
this data is in the ram and cache and videoram
I pause after each edit, and wait to be turned on when in plug in mode
I am a addon, I read through the cache, and read tags, model 1, has 4 modifiers
this can be applied to blender and 1 other application using the same tags.
I pass the torch to blender, by sending a message that is gpl for all plugins?
something along these lines?
this way the program is editing data, on its own not using an API correct?
No idea what you are talking about, BPR.
Fact of the matter is, and both the Blender Foundation & Free Software Foundation will back this up, that if you are using plugins, add-ons, or scripts that call functions specified and implemented in code published using the GPL - the script can only be published under a GPL-compliant license. Period.
OK regarding Octane, yep I failed to notice that. Is that the case though with every such plugin? Would you absolutely have to modify Blender to make Fabric work?
a blender,
get
set
plugin,
get
set
blender
get
set
plugin
game loop.
a external editor manipulating data
that is then reinitialized by blender?
At this point, yes.
Firstly, the Blender DAG / nodes refactor would need to be finished. FabricEngine is very node-centric and I don’t think Blender can fully utilise what FE offers without fixing up the graph.
Secondly, there would need to be an interface layer added to Blender such that it can pass information into (& get information out of) FabricEngine. This would likely be more work than the Octane port of Blender because FabricEngine is not just an output for final gemoetry & shaders. This interface layer would need to be GPL-compliant (being compiled into & distributed with Blender itself) and, if implementing a full interface, would need (at the very least) permission to duplicate much of the FabricEngine API or for the owners to relicense the API in such a way it can be used in GPL code (i.e. relicense the FabricEngine headers under a permissive license like BSD, MIT, or Apache).
@BPR: You’re talking gibberish. More importantly, you are specifically talking game loop gibberish which is off-topic. Take it elsewhere.
If blender saves a blend, and a external editor opens it, and changes something,
that program has to be gpl?
what if blender marked what data was what?
here is a mesh, (in the .blend)
Program 2 reads the mesh, and changes it, and saves it,
a mesh is just a list right?
I would love to see any credible source that follows BTolputt’s interpretation of the GPL allowing a “generic intermediate” API. The issue isn’t using any headers or function prototypes, it’s whether the GPL program and the “other” program form a combined work or not. Linking against code that links against other code creates a combined work.
If you create a wrapper that links against Fabric, and Blender links against that wrapper, a combined work is formed.
If you create a wrapper that links against Fabric, and that wrapper links against Blender, a combined work is formed.
Even if you completely defer this linkage to runtime, the combined work would still be formed on the user’s machine. (At that point you could argue this sort of GPL violation doesn’t matter, but then you don’t necessarily need a wrapper either)
The way Octane deals with this is not to create a wrapper API, it’s to avoid the combined work. The GPL FAQ allows inter-process communication via files/pipes or networking and that’s what Octane uses. If what BTolputt claims was true, the GPL could be effectively circumvented by just providing a wrapper layer.
OK regarding Octane, yep I failed to notice that. Is that the case though with every such plugin? Would you absolutely have to modify Blender to make Fabric work?
For all I remember, Octane didn’t modify Blender for licensing reasons, but for performance reasons (and to implement some custom UI stuff).
Copyright law cannot control how an end-user uses software, that is what end-user license agreements are for. GPL is not an end-user license agreement - it is a copyright license. It outlines the conditions under which one is allowed to distribute code licensed to you by the GPL.
If I write BSD-licensed DLL that then loads other arbitrary DLL’s (say from an INI file), you don’t get to force the GPL onto the other people’s libraries it loads just because you linked my code to your GPL application. Copyright law doesn’t allow that and the GPL is only a license, not a contract.
You are still missing the point. The GPL cannot & does not cover the “unions” you make on your computer. It covers the unions you distribute. It is a copyright license. It can only go as far as copyright allows and copyright in no way stops you from linking your application to other libraries (proprietary or otherwise), it only restricts what you can copy & distribute to others.
Any code that is compiled into and/or distributed with Blender must be GPL-compatible. Any libraries not compiled into Blender and not distributed with Blender cannot have the GPL applied to them because there is no way copyright law extends to them via the Blender distribution in question.
Proof can be obtained by simply looking to the Nvidia drivers in Linux. They are, without question, a proprietary library. They are, without question, being linked into GPL software on the end-user’s machine. They are, without question, not made GPL by dint of that fact. It doesn’t matter that they exist in a “union” with GPL software on the end-users machine as long as they are not distributed as a union with the GPL software.
–
[SUP][SUB]* Yeah, I accidentally viewed one of the blocked posters. That’s what happens when you’re browsing Google News in an anonymous session and click on a link showing BPR’s post in your email. Live and learn.[/SUB][/SUP]
Meshes aren’t covered by Blender’s GPL. Scripts, addons, and plugins are. A mesh exists as something that doesn’t need Blender to work (and is therefore not derivative or it). A script, addon, or plugin needs Blender’s API’s to function and are therefore derivative of those API’s. Derivative works fall under the GPL.