So not under investigation. Thanks 
Because 3-4 people for 2-3 years are 6-12 man years, which, at 50-100K$ per man/yr, total 300-1200 K$. Any buy solution, even The Foundry programs, is dirty cheap in comparison.
Only in the Penguin Zone programmer’s time is a cheap resource.
But the addon was not GPL or the dev would have chosen any license that makes it legal. And as I understand licenses only the final linked addon is problematic, distributing the source code should not be a problem. And if you let users download the SDK themselves you have no problems with the Eula. In the worst case you create a download page where the user has to accept the Eula and tell him he cannot redistribute the binary (distributing the source is no problem).
I think nobody would have cared, neither the users nor autodesk. It could help blender to allow addons to link to proprietary stuff without having to do IPC trickery.
Theoretically, would it be possible to create a Blender “CORE” which would contain only wieport drawing code and such and license it under MIT or some other permissive license that works with GPL and then separate the rest of Blender into different “modules” (like a fluid simulation module, a render engine module, etc)
Basically (if I understand this correctly) you would create new solid API that you can just connect other modules to. Would it then be possible to have a plugin (say FumeFX) replace the fluid simulation module and have it send data between the “BlenderCORE” and the plugin without it touching the other parts of Blender which are GPL licensed?
you guys do know that the big studios that want to use blender do this:
eg: from max to blender & back to max.
from the max side you write an exporter/importer in max script to a custom format similar to collada or fbx. (Max Licensed)
from the blender side you write a compatible import/export script. (GPL)
It works a treat. I’ve tested this method in the past & it worked far better than any traditional i/o because it was designed for this specific task. whole scenes with lighting set up & animations in & out.
Rather than argue about the merits of gpl or this or that. realize that the big studios can do this at any stage & often the mid range studios use this exact workflow. It doesn’t really matter which program your using, max. maya, lightwave or whatever the program may be.
write a custom i/o to & fro blender & your good to go.
new feature added to blender or x program, rather than cry & scream, you change a few lines of code each way to fix & move forward, or as most sensible studios do, finish your current projects then once you’ve updated your i/o update the program/s version for your next project.
It’s not a professional studios workflow to change software mid project. regardless of which program updated or changed.
So this GPL vs the world issue for studios is nothing but ill informed people yelling & screaming about things that matter little in the reality of big business, by many people who are not involved with it & whom most likely don’t want to pay for it either.
My hacked version of max doesn’t work with blender rings a bell.
@Meta-Androcto what does it matter for big studios to comply with the GPL license. They are never going to release their binaries anyway so why even care? The GPL issue is mainly for plugin developers who would like to keep their source code locked but still distribute their plugins.
NinthJake, yes that’s true in some respect.
my round about point, whilst trying to kill off several points in this thread is this:
Write an import export script in you native programs coding language & sell it for as much as you can & licence it however the ‘host program’ allows. After all, it’s only being used in the host program & if the host program’s license permits pay for scripts, sell it & it’s protected by law.
The script would write to a custom format readable by blender, created by the proprietary script.
From Blender’s side, the Author of the proprietary script should then release a gpl import export that allows blender to import then export the custom format. It would be the Author of the proprietary scripts responsibility to keep the gpl script working. The Author would also distribute the scripts at his/her price. Both scripts could be shipped together.
The main difference here would be the gpl script could be redistributed by the customer. The proprietary format i/o script could not unless illegally. neither script is dependent on each other. after all, they just export to a file & can import that file independent of each other.
Also note that it is not illegal to provide a proprietary piece of software that plugs-into, and thereby enhances (in the mind of whatever buyer you are hoping to attract) the behavior of, a GPL product. Blender’s API interfaces are public. As long as they implement their interface using a Python script, the script and the library that it references belongs, unquestionably, to them. They’re free to sell it if they can.
Blender was created under a GPL license, and so, anyone and everyone who contributed anything to it … licensed their own contributions to the project under those terms. They did so, because they knew that the terms could not be changed. Once a piece of software becomes “cooperatively developed,” one of the rules of the game (binding under the law) is that it must remain that way. You can’t wait until a product grows-up on the efforts of others, then buy it for yourself and put up a toll-booth. Sorry.
Blender isn’t proprietary, and that’s a key reason why it has had the industry impact that it does. Certainly, other companies can try to sell proprietary extensions to it … although I have serious doubts as to whether they would actually be successful.
The problem with the GPL is that it prevents the development/port of powerful plugins which are available for other applications (e.g. the mighty MeshFusion for Modo), plugins for which a Python interface is unusable or too slow.
@Meta-androcto indeed, making an import-export plugin for Blender is not too hard. The problem is that for large data-transfers between applications I/O is simply too slow. Take for example interactive rendering, if you could send data from Blender to the renderer and send the result back to blender several times per second then it wouldn’t be a problem. Then Octane and Vray wouldn’t have to go through all the hassle just to get a working plugin for Blender. Same thing for basically anything.
However for exchanging scene data from one 3D application to another (for example exporting a scene from Blender to Max or vice-versa) then I/O works just fine.
I am not arguing against you. I’m just saying that we are talking about different usercases and for the one I’m speaking of, GPL is still a problem.
But, were it not for GPL, the “object of interest” would not exist. It would have died with “NaN, Inc.,” all those many years ago.
Hardly, it wasnt a GPL or nothing kind of situation if I remember correctly. Dont forget there are now many different types of open source friendly licensing… Cycles for example is Apache.
There is always Wings3D, which is BSD licensed. Even with a more commercial friendly license it never seems to attract the users or developers Blender does. It’s a pretty good little modeler though.
Wings3D is an example of a program with limited options and if the program has some esoteric way to do things it will not be good for everyone. In a way Blender also suffers from this, but it has better options to tweak user interface which is one of the main reasons why Blender is (has become) popular. It’s amazing how some of those developers don’t get it. They just don’t realize that they should include more or less standard user interface or at least options for that.
I have actually heard of quite a few game artist who made use of Wings 3d on the side, it was either that or Silo for a period of time. With a lot of 3d suits getting better modeling tools though, the usage went down a bit.
I never mentioned specifically that adding exceptions would be easy, I always assumed that editing the GPL terms required the same process.
Also, no one is advocating that Blender become closed source, just that I thought for example that Blender is good enough to pay for if it ever happened (but very unlikely, even after a potential license change as making Blender pay-for software, even if it gave you source code access, goes completely against the BF’s preference that Blender is always free to use and develop for).
Wings3D shows stoppers are:
- being written in an obscure (functional to add insult to injury) language (Erlang);
- relying upon the winged edge data structure, which severely limits the kind of operations you can do
Even a sensible license (BSD) can not fix those show stoppers.
Right, The code on its own is re-distributable, just not combined with the FBX and Blender in one bundle.
Theres Seamless3d - written in C++, permissive license, animation, nurbs, javascript-style-scripting & nodes.
Buying off the shelf software is almost always cheaper short term, but its not that simple - companies still develop in-house software (as dreamworks, pixar, r&h).
It wasn’t. Initially, Blender was “technically” available under two licenses - GPL and a Blender Foundation commercial one. I do say “technically” because I tried to get details on the requirements back when it was supposed to be available and despite repeated polite emails & discussion on the matter, Ton remained incredibly vague about the conditions & cost of such a license then angrily dismissed me (& the people I was working for at the time) when I pointed this out.
To my knowledge, no-one was able to take up the Blender Foundation on the commercial license option which, I personally believe, lends credence to the idea Ton doesn’t want & didn’t want that option exercised. Opinion isn’t fact and all, but on this one I can refer to personal experience on the matter. shrug
Wings is written in Erlang. I can count the number of people I’ve met in the field who can write in Erlang on one hand. Only one of them would I consider proficient at it. Wings is a fantastic little modeller and the language they chose has some really cool upsides… it also has a major downside to it as well and that is the esoteric language is not very well known.
That’s great AD, and when I want to accuse you specifically of something, I think I’ve shown I have no hassles doing so. Innuendo and passive-aggressive BS might be accepted as an OK means of communicating by others, but I simply can’t stand it. If I haven’t said I think you’re to blame for something, it’s not because I’m implying it - I’m just not saying it at all.
I never said anyone was advocating for a closed source Blender. I was making a point by telling people that the “GPL with exceptions” requires exactly the same copyright waivers/assignment as a closed source version. There seems to be a belief that “GPL with exception” is somehow less work because the GPL still makes up the majority of the conditions. The law, however, doesn’t give a flying fruitbat about how close it is. “GPL to almost GPL” is a change that requires the same things as “GPL to nothing like GPL”. Assuming there is the will to consider such changes in the Blender Foundation (and outside Campbell’s occasional musings, I’ve seen nothing to suggest that) - there is no less work (& therefore no extra power to convince BF it’s worthwhile doing) in the “GPL with exceptions” route as any other option.
I wonder If people would actually prefer to have a non-copyleft license for blender.
You do have problems when you want to do proprietary plugins/add-ons but it’s a tradeof for having truly fee software.
Personally, I don’t have big problems with closed source software, but it’s important to have copyleft alternatives, this blogpost comes to mind.