One of the things that we’re seeing more frequently in the Blender community are products that are a mix of code and non-code parts. Sometimes it’s an asset pack that has an add-on integrated to make it more easy to use. Sometimes it’s an add-on that generates assets, but has some base meshes that it uses as starting points. For these kinds of products, the GPL isn’t really sufficient for covering all of the different incorporated parts. In fact, because the GPL is so focused on software, it’s really the wrong license to use for things like 3D models, images, or textures. Those elements are better served with a different class of licenses.
Types of licenses for assets
In truth, there are an infinite number of licenses available for non-code components. By default, everything you make is “all rights reserved”, meaning that no one has the right to use your material without your permission. In order to gain your permission, a person or an organization must abide by whatever terms and conditions you stipulate. Those restrictions are defined in a licensing agreement. As long as they comply with that agreement, they have a license to use your material.
You can define whatever terms and conditions you want in your own license agreement and, in truth, there are whole legal departments in some companies whose whole job is drafting custom licensing agreements with very specific restrictions on use. Most of us don’t have these legal teams at our disposal, though, so just like we’ve done with software licensing, the creative community at large has standardized on a few commonly understood licenses. Here’s a list of some of the most common ones available:
When something is in the public domain, that means that’s free to use by anyone with no restrictions whatsoever. However, technically speaking, you can’t put something in the public domain. That happens automatically after the lifetime of a copyright expires. Many creators don’t want to wait 70+ years for that to happen, though. So they choose a license that is functionally equivalent to being in the public domain. One of the most common licenses of this type is the Creative Commons CC0 license. There’s more on Creative Commons licenses in the next section, but this is one that’s meant to get you as close to releasing to the public domain as possible.
The Creative Commons isn’t actually a single license, but a suite of different licenses (like the aforementioned CC0 license) that grant varying levels of restrictions on the use, modification, and redistribution of creative works. You can see the full list of licenses on the Creative Commons website. The CC0 license described in the previous section is a bit of an exception. For most Creative Commons licenses, it’s easiest to think of it as a base license where you choose to use one or more of the following modifiers:
- BY - This is an attribution requirement. Basically, anyone who uses your material has to give you credit for making it.
- SA - This modifier stipulates a “share alike” requirement, much like the copyleft requirement stipulated by the GPL. People are free to modify your source material, but they have to freely share the source of their changes as well.
- NC - Creative Commons licenses with this tag only allow for non-commercial use of the copyrighted material. That means it can’t be used for anything that makes a profit.
- ND - This requirement is the “no derivatives” condition, meaning that people have no permission to modify and redistribute their changes to your material.
When a license agreement is drafted, one of the conditions that’s often employed is a royalty. A royalty is a fee that is paid to the creator of a work each time the copyrighted material is reused or redistributed. Of course, not everyone can make royalties on their work (or wants to). Having royalties means there has to be a means of accurately tracking use and distribution. In the context of a Blender add-on, that can get very difficult. So many creators will often bundle assets as being “royalty free”. Meaning that they’ve given permission to use their material without users having to pay royalties. There may still be an initial fee (like purchasing the asset pack in the first place), but no costs incurred after that.
Of course, there are plenty of other standard licenses out there besides the ones listed in this article, but these are the most common. Coincidentally, Creative Commons and Royalty Free are license options you can choose for Blender-based products if you happen to be selling on the Blender Market.
How to organize your product for mixed licensing
So you’ve decided how you’re going to license the components of your product. Maybe you’ve chosen the GPL for the add-on parts and Creative Commons ShareAlike (CC-SA) for the assets. Or maybe your assets are Royalty Free and your code is under the MIT license. Now you’ve got to clearly communicate to your users which licenses you’ve chosen and how to tell which license applies to which part of your product.
Of course, as with anything, there are a bunch of ways to go about communicating these things successfully. What’s described here is merely our recommendation, but we feel it’s a pretty good one. Use these steps:
Separate differently-licensed parts of your product into different subfolders within that product. For instance, if you have an asset pack with a bundled add-on for usability, you should have a subfolder called assets and another called src or addon. Your folder structure might look something like this:
Within each subfolder, add a
LICENSEfile should contain the text of the license that you’ve chosen for the material in that folder. In the example where your add-on is GPL and your assets are CC-BY-SA, the text of those licenses belong in their respective
LICENSEfiles within your subfolders. Also, for the add-on, be sure that the rest of your code is GPL-compliant.
In the root of your product’s folder structure, add one more
LICENSEfile. That file should explain that your product has been released under the terms of multiple licenses. It should also say which licenses you’ve chosen and point to their
LICENSEfiles in each of your subfolders.
The text of that main
LICENSE file doesn’t have to be complex. In fact, it’s better if it’s simple and clear. In the example of a product that’s using GPL for code and CC-BY-SA for assets, you may have a
LICENSE file that reads like so:
I might also suggest that you make explicit mention of your chosen licenses in your product’s
README file and possibly your product description. This way, your users know exactly what they’re getting into.
After doing all of this, you may find yourself asking one further thing. There are a number of places where you can sell your Blender product and if they give you an option for listing the license you’ve chosen, they may only give you one of them as being available to choose. In those cases, you may wonder which license you should list. Legally, the terms in your
LICENSE file should supersede anything else, but it’s always a good idea to be as clear with your users as possible.
Your first action is to check with the site that’s selling and see if they have a preference or standard policy that they use for mixed license products. If they don’t have anything like that, then the next best thing is to ask yourself what the primary purpose of your product is. If you’re mainly selling an asset pack and your Blender add-on code is just there to make it a little easier for people to use those assets, then maybe choose the license that’s associated with your assets. On the other hand, if your product is mostly an add-on that uses some base assets to generate more interesting things, then perhaps you should choose the license that’s associated with your add-on.
In either case, the most important thing is to make sure that your licensing terms and conditions are clearly understood by your users… preferably before they give you any money.