It’s not just the implementation time. Someone also has to maintain it (to “own” it, if you will) and keep it up to date with the various (and numerous) changes and additions under the hood within Blender. And of course, this loops back around to the continuing debate on stable APIs (occasionally, but more frequently than most would like, Python API changes mirror changes in Blender’s source… and there’s no real notion of API versioning or deprecation).
You think add-on developers have a hard time keeping up with the Python API (which, again, is already quite closely married to changes in Blender)? Plug-in developers are likely to have an even harder time unless Blender’s development seriously slows down or there’s incredible forethought in the C/C++ API’s design.
And yet, as already stated a huge chunk of features and their maintenance could be offloaded to third party by having a C/C++ API. Abandoned fluid syms come to mind for one. Could cut down on questions why one could only have one fluid domain per scene right?
You really want suits behind Blender making decisions? You know that a user community has a big advantage in using open source and free software like Blender right?
For users, there’s no advantage in having a platform only work in a strict copyleft environment. The MIT license is just as “free” and “open-source” as the GPL, but it doesn’t force that requirement on any code that merely touches it.
Imagine an operating system that couldn’t “legally” run proprietary code at all. Almost nobody would use it. That’s why the GPL sets a boundary here, allowing programs to talk to each other through means like os pipes. This was sufficient in the environment that the GPL was designed under, where people would commonly combine smaller programs to solve more complicated tasks through scripts.
However, the GPL considers programs sharing address space to form a unity that requires them to be “free software”. It’s a somewhat arbitrary distinction that only serves to make interoperation more cumbersome and less efficient, but it doesn’t prevent it.
The “we use the GPL so Blender stays free” is a bit of a disingenious claim. An MIT-licensed Blender release will also stay free forever. Companies that decided to “exploit” Blender by releasing proprietary versions would have to create compelling features. In the end, there would only be more options for Blender users, not less.
On the other hand, preventing proprietary plugins of any kind isn’t going to magically make free implementations appear. There will be less options, not more.
Changing the license for Blender would mean jettisoning every contribution made to Blender under the GPL license unless you could get the person who made the contribution to agree to the license change, wouldn’t it? I mean ethically. I’m sure there are sharky ways to manage it, like saying if you don’t respond to this notice by this time your code will be republished under a different license. It’s for reasons like this that the GPL license is so exact and complicated!
Nope. The best way to think about it is to replace their code contribution with a piece of prose or music. Try sending an email to a recording artist that says “if you don’t respond to me by this time your song will be republished as open source”. You’d be laughed at. It is their license, not yours.
Changing from the GPL license would also mean the possibility that we lose a few developers as well because they will not work under a different license.
Now if you don’t think that’s a big deal, one of the people who only work with GPL’d code is also the biggest contributor (Campbell Barton), if we were forced to jettison his contributions, we will lose a lot of functionality (which might even include the Bmesh system along with most of the modeling tools and a major chunk of the Python API).
Simply put, as attractive as booting the GPL (and likewise any affiliation with the Free Software Foundation) might be to some (perhaps some going as far to try to convince Ton that he might be too set in his ways to lead the project), we might end up with a crippled Blender that few would want to contribute to and no professional would dare use.
Well, creating a plugin that links to the C API of a GPL program would require that plugin be licensed to GPL. As they say, most companies have a strong distaste for anything GPL so I don’t know how much of a help it’ll be in terms of commercialization. Who knows, maybe one day a company will find it worth to invest in developing a C API for Blender, for their plugin. Until then, we just have to wait until the difference between Python and C is similar to the difference between C and Assembly i.e. the speed gain is negligible compared to productivity/maintainability. If this be the case, hopefully PyPy (JIT) can help close the gap; the initial delay associated with JIT is a speed bump.
I think every programming language has a limit at which it becomes unpractical for the majority of demands. Idk if C has reached that point. FWIW, Linux had some concerns with the growing complexity of the Linux Kernel (IMHO Linux will inevitablty reach EOL like any other). Every language abstracts features of previous lower-languages (form of automation) since this reduces redundancy, and of course as the language becomes higher-level, abstractions build upon abstractions, etc. until ?. I mean it took C about 25-30 years to become dominant over ASM. Python’s been around since early 90s so give it another 5-10 years
As for licensing, I’m pretty sure Blender will always be GPL. The only real way for Blender to be permissive is to rewrite it completely which will probably never happen. There’s always Wings3D (BSD)…
This thread is not about the GPL. If that was a problem then why does anyone make python addons for blender???
I know I have a number of different builds of blender installed, they have different features (like an exporter or something). Obviously it is silly.
Just because developers have other things to do and this feature requires heaps of work does not mean we should not look to be something like this in the future.
Actually not doing like this would be really dumb. There is a reason why the Blender C API never really took off. Maintainability.
In other 3d Apps which are commercial and are not open source, you build a plugin for the app in C/C++ and maintain it so people keep using it.
In blender you have the ability to integrate your changes directly to the source. Now why you would want that if that means you have to recompile the entire blender.
Two reasons :
a) Power - No blender C API , no plugin system , will ever gave you the power of actually modifying the source. This is why open source is so popular nowdays anyway, the ability to go inside the source of the app and change even finer details. Opens a universe of possibilities.
b) Maintainability - When you integrate your source inside Blender source, you can ask the developers to integrate your source code inside blender standard repository. Meaning that your code will come as part of Blender standard download. This means that even when you are no longer able to work on the project because of lack of free time Blender developers will keep making sure your code will continue to work for future versions of Blender because its part of Blender.
So in the end there is going to a be a minority of developers that would choose (if none) the plugin route. And since GPL forces you to open source your code the moment you link it with Blender it makes little sense to want to distribute it as a plugin.
I am no huge fan of GPL (I prefer MIT), but I must say I also kinda like the fact that it forces you to open source.
In order to change the licence, Blender developers will have to track down every single developer that was contributed to Blender and ask for his permission to modify the license. Good luck with that.
In any case I seriously doubt that changing from GPL to more free licence it would substantially benefit Blender, so my final verdict on the subject is :
Your point of view can be seen from the opposite part.
If you want to put your modification in the trunk,you HAVE to ask.
If Blender developers don’t want your modification inside Blender the code effort will be wasted.
The development is mainly centralized.
Do you remember how many time people asked for the possibility to control wireframe colors?
If,for example,someone creates a muscle/deformation system based on metaballs,blender main coders can say"we don’t like it,we want a muscle system based on tissue simulation",and reject the patch.
So at the end,individual coding contribution is discouraged,what encouraged is becoming part of the crew.
I understand the reasons and I accept it,but we can’t hide that from an user point of view,things could be better with a plugin system.
There are 2 reason why Blender devs would not want to include your code in the trunk
a) Not many people find your code that useful
b) your code is very messy aka does not follow Blender code guidelines
The important thing to note here is both of these reason are fixable. Blender developers prefer code in trunk than forking blender or having thousands of plugins. Hell they even prefer addons to be added inside Blender if people really use them. Nothing thats really useful to the community is truly left out.
But in then end of the day it comes down to this question “Who would not want an addition that makes Blender better or more flexible” , you can count that the answer is really “close to none”.
So instead of leaving in fear about your code get rejected , discuss with the devs , ask their opinion. I remember when I started my project (which was in python not C) , Ton (the big boss asked me why I bother implementing a secondary GUI for Blender. I replied that I though a truly custom GUI for blender would benefit users who wants custom widgets for rigging , modeling and animation. He replied back that he was working on such widgets in C and he was hopping to make them available to a future Blender version.
So inside discussions you can find a lot of common grounds and create code that you like, blender developers like and most importantly your users like. Even if Blender developers dont believe in your code, if you have the backing of users and users ask for that functionality and your code is clean readable and follow Blender code guidelines then there is extremely low chance your code will not be included.
I don’t think that would happen. You don’t have to change to a permissive license, you can still have a copyleft license that isn’t the GPL, but is more friendly towards linking.
It was a mistake to pick the GPL in the first place and it was a mistake not to ask contributors to hand over copyright to the BF (as some other projects require). The situation makes changing the license highly impractical (albeit not impossible). As it is, I don’t even see the acknowledgement that using the GPL is a problem, at all. So, it’s not going to happen. I’d still like to clear up some misconceptions about the nature of the GPL.
Now if you don’t think that’s a big deal, one of the people who only work with GPL’d code is also the biggest contributor (Campbell Barton), if we were forced to jettison his contributions, we will lose a lot of functionality (which might even include the Bmesh system along with most of the modeling tools and a major chunk of the Python API).
He didn’t say that, he said he would have concerns about contributing to a non-copyleft project. Should Blender change to a more “friendly” copyleft license, I don’t think he would stand in the way.
What are you trying to say with that? This thread is also about how Blender would be “left in the dust” without commercial plugin support. The GPL affects Python addons just the same, so you won’t see any proprietary plugins here, either.
Most commercial addons would expect a C or C++ interface, however you can also link C plugins through Python. The real problem is efficiency.
If that was the only reasons, there wouldn’t have been so many patches sitting in the tracker without even as much as a comment (although things are improving here).
The main reason is that they don’t have the manpower to review all the stuff. For the same reason, there is no C API, no modifier plugins, no compositor plugins, etc. Somebody has to work on it. It’s not that anybody is against it philosophically.
We can reiterate the pros and cons of monolithic vs. modular design here, but that’s pointless. We need a more efficient API so that you can ship addons that do cool stuff. We don’t need ultimate power.
