How to Make Your Blender Addon GPL Compliant

So you’ve coded a Blender add-on and you’re ready to release it out into the wild. Congratulations! It doesn’t matter how complex or simple an add-on is, completing a tool and sharing it with others is no small thing. You’ve done something great and that should be celebrated.

Now, whether you’re putting your add-on on Blender Market or simply making it available on your website for anyone who wants it, there are some final checks that you need to do with respect to licensing. If you’ve read any of the documentation provided by the Blender Foundation, you should know that all Blender add-ons need to be compliant with the GNU General Public License, or GPL for short. The GPL is an open source license that ensures that programs released under it can be freely modified and redistributed by users of that program. There are multiple versions of the GPL, but that’s a topic for a future article. It’s important to note that the GPL does not prevent you from selling your add-on. If you’re curious about the philosophy behind that, you’re welcome to read our article on selling and the GPL.

This post isn’t about that, though. This post is about the nuts and bolts of how you release your add-on in such a way that it’s compliant with the GPL. I’ll get into details further down, but here’s a quick checklist for you:

• Make sure you have permission to share your code
• Add a LICENSE file with the text of the GPL
• Include a license notice at the top of each Python file in your add-on
• Ensure your source code is available

In the next few sections, I’ll go into each of these checklist items in more detail. At this point, I do have to make the standard disclaimer that I am not a lawyer. Although this checklist is based on documentation from the Free Software Foundation (the stewarding organization for the GPL), sometimes things can get complicated where licensing is involved. If you would like to do anything more complicated than this, you may want to seek advice from an actual legal professional.

Ensure you have permission

This point is a big one. You need to be sure that you are actually allowed to distribute your code under the terms of the GPL. If you’ve written all your code yourself, on your own time and equipment, then the solution is simple. It’s your code, so therefore you have the copyright and don’t need permission. However, bigger coding projects often involve more people. These are the situations where you want to make sure you’ve done your due diligence.

The most common scenarios where this comes up is if you’re collaborating with someone, writing the add-on as a part of your job function, or if you’ve pulled in code from somewhere else (like a third-party Python module). These cases are where you should take some additional steps to cover yourself. While these steps can be annoying to do, they’re not overly difficult and they’re the kinds of things that “future you” will thank you for later. The last thing you want is for someone else to say you can’t share your add-on because they own the copyright to part of it.

In the case of a collaborator, you really just need an agreement from the person that they give permission to release it under the terms of the GPL. The agreement doesn’t need to be lengthy, but it should be signed. As an example, you might have something like the following:

Coder Coderson is a collaborator on the Blender add-on “Super Awesome Blender Add-on” (which does some really cool stuff) and gives permission for code contributed to that add-on to be released under the terms of the GPL.

Coder Coderson

That statement should be signed and dated. Also, you should probably be a bit more specific about what the add-on does rather than “some really cool stuff”.

If you wrote the add-on as part of your work function for a company, the best course of action is to get a similar statement, however that one should be a copyright disclaimer, whereby they agree to give up any copyright claims on the add-on. The statement for that could look something like this:

Corporation, Inc. hereby disclaims all copyright interests in the Blender add-on, “Super Awesome Blender Add-on” (which does some really cool stuff), written by Justin Myselferson.

Big Boss Person, President, Corporation, Inc.

Again, this agreement should be signed and dated. In both cases, you should keep this statement for your records in case you need it in the future. Also in both cases, emails count as signed statements. This makes the whole process a lot easier and less intimidating for everyone.

In the third case, where you’ve pulled in code from a third-party source, you need to do a bit of research. The most important thing to find out is the licensing terms for the code you’ve included. If you can’t find the license, stop right there. You don’t have permission to use that code. You either need to contact the original author and get them to give you permission (often in the form of an agreement like the examples above), or you need to replace that code with something else, be it your own code or code that’s under a more GPL-compliant license.

Emails count as signed statements. This makes the whole process a lot easier and less intimidating for everyone.

If you know the license that the code you’re using was released with, you then need to ensure that the code is compatible with the GPL. The Free Software Foundation has a whole article on license compatibility, but the general rule of thumb is that if the code is already under the GPL or one of the more permissive open source licenses (MIT, BSD, Expat) or public domain, then you should be fine, so long as you respect the requirements of those licenses for the code you copied. Those requirements are usually pretty easy—most often it’s to attribute appropriately (give credit where credit is due to the authors of the third-party code) and to ensure people can find the source code—but make sure to read the licenses to verify.

Add a LICENSE file

Of all the steps in the checklist, this one is probably the easiest. Along with the other files in your add-on, you should include one named LICENSE. The Free Software Foundation uses the convention of naming the file COPYING, but the more common practice for Blender add-ons is the name LICENSE. Whatever the name, the content of the file should be the entire text of the GPL. For your convenience, here’s a link to the text of the the GPL, version 3, that you can copy and paste into your file.

If your add-on is only a single Python file, then you have a couple options for how you handle this. The easiest would be to just include the LICENSE file in the same compressed package (typically in ZIP format) as your Python file.

Of course, if you have a very simple add-on that’s packed into a single Python file, all of this effort may seem like a bunch of additional work. Technically, you can rely on just having a license notice in the header (see the next section), but this approach is not best practice and it breaks a lot of infrastructure that can help automate license checks. The best thing to do is pack your add-on into a folder. That way, you can include a proper LICENSEREADME and other helpful files and gives you a cleaner way to expand or improve your add-on in the future. Multi-file add-ons in Blender are a bit more complex to set up (you need to create an __init__.py file with proper structure), but the benefits of doing things correctly are absolutely worth it.

Include a license notice in each file

In addition to the LICENSE file that comes along with your add-on, every Python file in your add-on should also include a license notice at the top of the file. The license notice is a brief statement that stipulates you (and your collaborators, if you have any) as the copyright owners and that you’re releasing your code under the terms of the GPL. As an example, here’s the license notice that’s used in the Export to .blend add-on:

For your add-on you’d need to update the copyright information at the top and then substitute the name of your add-on in the body of the license notice. And yes, this text should go at the top of every Python file in your add-on, even the small files that only hold a couple global variables. Yes, it can possibly make your add-on a couple kilobytes larger, but this is a necessary step to ensure that you’re compliant with the GPL.

Ensure your source code is available

Most of the time, there’s not much that you have to do for this step. Python is a scripting language that’s interpreted at runtime. This means that under normal circumstances, if someone has your add-on, they also have all of your source code.

That said, you may want to make it easier for your users to report bugs, test new features, or even collaborate with you to improve your add-on. For that, you may want to host your code on a code forge like GitLab or GitHub (you are using version control, aren’t you?). The exact steps for doing that are a bit out of scope for this article, but those sites have pretty good documentation to help you get started down that road.

Do I have to share my source with everyone?

A common question that comes up when it comes to open source software in general, and GPL-licensed software specifically, is whether you need to share your source code with everyone in the whole world. If you’ve created a repository for your add-on on GitHub, for example, do you have to make that repository public.

The short answer to this is no. You don’t.

The terms of the GPL are only activated upon distribution of your add-on. That is, if you give someone your add-on, then you are required to ensure they can get their hands on the source code. Functionally, this means that if you’re selling your add-on, you can keep your code repository private and only provide access to the people whom you’ve sold to. Practically, it might be easier to just leave it all public.

But what if I have code that I don’t want to share?

The other common question that people ask is usually some variation of, “How can I get around the terms of the GPL?” The short answer to this is no. However with a lot of effort you can have proprietary code site alongside your GPL-licensed code. That said, it’s rare that this is necessary and even more rare that it’s worth the time and considerable expense to do correctly.

That said, although it’s rare, there have been some add-ons that incorporate proprietary code the “right” way. This is sometimes required when using a library that isn’t GPL-compliant. For instance, the license to the official SDK for Autodesk’s FBX format is not at all friend to the GPL. However, the Better Fbx Importer & Exporter add-on makes use of this SDK. In order to do that, though, the author had to create a completely separate intermediary file format. The Python (and GPL licensed) part of the add-on imports and exports to that format, while a separate, non-GPL program handles converting between that format and FBX. This approach does allow the use of the official FBX SDK for getting files in and out of Blender without running afoul of either Autodesk’s license or the GPL, but this is a rare circumstance where it makes sense, and even then, doing so required a substantial amount of effort

Conclusion

So there you have it, your checklist for making your add-on GPL compliant:

• Make sure you have permission to share your code
• Add a LICENSE file with the text of the GPL
• Include a license notice at the top of each Python file in your add-on
• Ensure your source code is available

Have fun!

Originally published by friend and colleague, Jason van Gumster on Orange Turbine