With the Blender popularity growing, the number of add-ons created for it by third-party developers is growing too. A lot of high-quality professional add-ons are written for Blender now. Over time, the number of add-ons is becoming more and more. And on this wave aggregators appeared – programs and services independently searching for add-ons and allowing Blender users to install add-ons quickly, many at once, and bypassing add-on distribution channels selected by their authors. What caused a negative reaction of add-on developers.
Let’s try to understand the situation.
Have add-on aggregators the right to exist?
Blender is licensed under the GPL license.
The GPL license is inheritable — it guarantees that users of all derivative programs should get all the same rights as they have with the original program. No one program can be combined from two parts – one under the GPL license, and the other – not (except for compatible). If the program has at least some part under the GPL license – the whole program should be distributed under the GPL license.
So, as soon as the add-on developer writes the
|
1 |
import bpy |
or
|
1 |
from bpy import |
instruction his add-on will be required to be distributed under the GPL license. There are some legal subtleties here, for example, the API is not licensed in some countries, but in general – all Blender add-ons must be distributed under the GPL license.
The GPL license allows you to redistribute downloaded program in any way. The legally obtained add-on can be sold, transferred, donated, distributed to each and everyone, and all of that – absolutely legal. So, add-on aggregators act quite legitimately.
Is it really so bad for the add-on developers?
There is a certain add-on distribution practice in the Blender community – the main resource where developers publish, and users search for the necessary add-ons, is the Blender Market. The current system allows developers to get some reward for their add-ons, allowing them to continue working on current ones and creating new add-ons. Users also have a fairly convenient service for finding the functionality they need. Is it necessary to say that add-on aggregators break the established system?
A very small number of add-ons are designed to provide any service, which according to the GPL license authors mind, should grant their authors with a reward. Most add-ons are the completely finished programs that do not require additional content in any form of extensive documentation, maintenance, lessons or training. Such add-ons are downloaded by the user once, and very rarely users return to the author’s resource to thank him later. Installing such add-ons through an aggregator guaranteed prevents the author from receiving rewards because the user doesn’t even know that there is a place where he can thank the author of the add-on.
Is it so fine for users?
Yes, if you can easily, quickly and free of charge download any add-on, it seems very attractive. The user finds the desired add-on through the aggregator, installs it, gets the result. Wonderful! But everything is so good only for a short period of time. Can we look a little further?
The user downloaded the addon through the aggregator – the author did not receive any reward. Is there any chance that the author will continue to develop, refine and invent new features, and create new add-ons? Hardly. The Blender changes from version to version. Add-ons become outdated, falls with errors and stops working. Where does the user get the new version of the add-on? There are no updates, no corrections, no new functionality from its developer. Not to mention that the user will not receive new add-ons, which can be very useful and necessary.
More
Where do the aggregators themselves take add-ons? Really buy them on “Blender Market”? Most often, aggregators are looking for add-ons in automatic mode. Using the fact that the GPL license requires the author to publish the program source code, aggregators search for resources like GitHub, where the authors upload their add-ons “sources”, and compile and transfer add-ons from them to the user. But such resources are not used by developers as the “showcase” for distributing, and they are not following the purity of the code, the correct configuration settings, and full add-on completeness here. Platforms like GitHub are not intended to distribute add-ons at all. Downloaded in this way add-on may not work correctly and completely, causing both the user and the developer to suffer. The user will not get the required functionality, the author gets the reputational losses, which is even worse than financial ones.
Finally
At first look, add-on aggregators look very attractive to users. But in the future, both developers and users themselves are threatened with losses.
Can we do anything with it?
Besides the obvious – not to make add-ons for Blender, if you don’t intend to distribute them for free?
The developer can protect from distributing his add-ons through aggregators without violating the GPL license.
The simplest way is to publish the source code not on popular repositories like GitHub but somewhere else, for example on the personal developer page. Google can go around the whole Internet, aggregators – can’t. However, in this case, the developer loses a number of convenient code control tools from the official repository.
There is another way to close our add-on code from unwanted distribution continuing to publish it in the public repositories like GitHub. We just need to add a configuration file to our add-on with a parameter that determines the status of the current code: “demo” for publication, and “release” – finished build provided to the user. The add-on will work in the specified mode. In the published on GitHub source code, this parameter can be set to “demo”, and in the add-on provided to the user on the Blender Market – to “release”. In the demo mode, the add-on can show the user a message with a warning and where the user can download a full-featured version of the add-on text. No one aggregator can modify external add-on code automatically and change the value of this parameter.
The configuration file can be in JSON format and look something like this:
|
1 2 3 |
{ "demo_mode": true } |
The “true” value indicates that the add-on is in the development/source-code-publication mode and can not work properly. The “false” value means a fully functional version of the add-on.
For easy access to this parameter from the code, we can use the following class. Save it in a separate “addon.py” file.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
import json import os class Addon: cfg_file_name = 'cfg.json' @staticmethod def demo_mode(): rez = False conf_file_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), __class__.cfg_file_name) if os.path.exists(conf_file_path): with open(conf_file_path) as conf_file: json_data = json.load(conf_file) if 'demo_mode' in json_data and json_data['demo_mode']: rez = True conf_file.close() return rez |
This class has a single “demo_mode()” method that returns the “demo_mode” parameter value from the “cfg.json” configuration file.
Copy these two files (cfg.json and addon.py) to your add-on directory. Now, in the header “__init__.py” file we can easily get the current value of the “demo_mode” parameter and on its basis perform certain actions. For example – display a warning.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
from .addon import Addon import bpy bl_info = { .... } def register(): # warning if Addon.demo_mode(): print('It seems you are trying to use the demo version of the ' + bl_info['name'] + ' add-on. It may work not properly. Please download and use the release version!') # addon running code ... def unregister(): # unregistering addon ... if __name__ == "__main__": register() |
Here, in the “register()” function we check is the add-on in the “demo” or “release” mode. And, in the case of “demo”, a warning is displayed in the console. We can put the add-on executing code under the “else” condition to completely block its execution if the add-on is in the “demo” mode. An only warning message will be displayed.
|
1 2 3 4 5 6 |
def register(): if Addon.demo_mode(): print('It seems ... else: # addon runngin code ... |
This way the add-on can be protected from unwanted distribution from public repositories. And of course, the developer should not forget to change the value of the “demo_mode’ parameter when building the release version of the add-on for distributing through the Blender Market.
I’m not sure that the “import bpy” make your software GPL. If so, tell me how closed source could run on a Linux system, eg an Oracle Database ; at some point, you will use syscalls to GPL library (and not LGPL ones), and this do not make your binary GPL as well.
So, for me, the only reason Blender addons are open source is the way you cannot prevent your Python code to be read or reversed if it was provided only byte-coded.
BR
When you make a request to the database (Oracle or another one) you receive the content, not the source code of this database, so the database license doesn’t use in this case. When you use the “import” command – it is equal to copying the source code from Blender and pasting it to your add-on code, so the Blender license is used here. THat’s the difference.