Licensing Your TouchDesigner Work

All of the TouchDesigner developers I know are always working on tools. These tools may be for personal experimentation or critical tooling for your company projects. Either way, you may come to a point where you want to share your work. It may be for financial gains if you want to sell an amazing and useful tool you’ve made, it may be for educational purposes where you’d like to teach the community how you do something awesome, or it may be to harness the power of the community to collaborate on a general usage tool that the community can use for years to come. But how do you approach releasing it? What processes do you need in place? What kind of attribution would you like? Can companies make money from the tool? These are all questions you need to ask yourself so you can decide on how you want to license the work you’re releasing. Let’s dive in!

NOTE: I am not a lawyer, these are my opinions based on my knowledge. Don’t take this as legal advice and I advise you talk to a copyright or intellectual property lawyer if you’re working on a serious project.

Proprietary

A lot of people want to take their components and sell them to create a source of revenue out of them. One avenue is to go the proprietary route. This means that you’re selling someone the ability to use your product but keeps the intellectual property in your ownership. You might consider a proprietary setup if you want to restrict the customer’s ability to either learn your secret techniques or maybe you don’t want them to be able to re-package and sell your work under a different name. Either way, there are different ways to approach proprietary tools.

Going Fully Locked

This starts with locking your component using a Pro TouchDesigner license. That way users can never get inside and steal your secret techniques or mess with your working product. In this case, you may want to even build your own licensing system inside of the component that can do certain types of checks such as:

• Has the user actually purchased this product?
• Is the user currently subscribed to your subscription-based product?
• How many times has the user activated this product?
• When did the user purchase the product

These questions are important ones to ask because you have to ultimate decide what’s fair usage of your tool. Can the user buy it once and activate it on 3 computers? Does the user need to keep an active monthly subscription to continue using your tool? You’ll have to decide what works for your tool.

The common route for these licensing setups is to use a payment provider that has a built-in licensing web server that handles license key generation and keeps track of usages of those keys. Examples include Gumroad and Paddle Payments. These payment platforms have their own web server that keeps track of customer’s information that you can do API calls to. In this workflow, whenever your tool is launched or the project file opens, your tool would do a web request to the licensing server of your payment platform with the information the user provided, and it could make decisions based on the information you receive from the server. You can unlock certain functionality in the product based on payment status or you may lock the functionality if their subscription isn’t active anymore.

This works both for single-time purchase products as well as subscription-based purchases. The idea behind this whole model is that you’ve created something special that you don’t want to be copied by others. It unfortunately prevents others from learning from your work, but sometimes it’d a trade off that needs to be made so that you can make some money off your work.

Buy-it-once / unlocked

If you want to make money but aren’t too concerned about people sharing your tool with others, you can use a traditional online store front that can manage payments and deliver your unlocked components to the user. You could use platform such as Gumroad, Etsy, Shopify, Squarepsace, or any modern online web store platform. The big thing to note is that you probably won’t get organic traffic from those particular sites, so don’t pick a platform just because it claims to have a lot of people on it. Pick a platform that you feel comfortable using and has easy way to deliver digital downloads.

In this scenario, it can be really hard if not impossible to actually enforce the usage terms that you’ve laid out and you have to go on the honour system. This is because no matter what type of system check or web server request you want to do, ultimately the user could just go into your component and delete those system checks.

License choice

The most straightforward thing to do for your components you’re selling commercially that you don’t want people modifying or re-distributing is to ship them alongside a standard software EULA. A EULA is an End User License Agreement. Every time you’ve bought software in the past, you’ve agreed to that software’s EULA when you install it. This document ships alongside your tools and outlines the legal boundaries for usage of that tool that you’ve sold. There are tons of resources online if you do a web search for “software eula template” or “software eula generator.” In many of them, you get to make choices that you want in terms of modifications and redistribution, and the generator will make you a generic EULA that you can use.

Open Source

If you’re less worried about the commercial side of things, you don’t need to worry too much about locking your component or setting up licensing workflows. That doesn’t mean that open source has less decisions. I’d argue there are an equal number of decisions as there are tons of different open source licenses! You can basically host your tool anywhere like your own website, GitHub, GitLab, the Derivative website, or anywhere else you can shove a file. The real decisions come in the form of license you attach to your tool or software.

100% Open

Starting from releasing your tool as open as possible, the two common options you’ll find are to release your tool as Public Domain or using the CC0 (Creative Commons Zero) license. These two licenses are basically a free pass. The user can do anything they absolutely want with your software. They can learn from it, contribute back to it, use it commercially and personally, choose not to attribute you, and they can even take your software and sell it under a new name (yup that’s allowed in Public Domain). Public Domain is an actual legal definition of a state of a work, which may actually vary by country. This is why CC0 was created to be an absolutely restriction-free way of licensing software that wasn’t tied into differing legal definitions that Public Domain might have in different countries. This is a good choice if you absolutely don’t care what a user does with your work. You’re essentially donating knowledge back into the public pool of knowledge.

Permissive Licenses

A slight step above Public Domain/CC0 are the group of “permissive licenses.” These include licenses such as MIT license, Apache license, BSD license, and all of their different variations. Permissive licenses are pretty common in open sourced software because they still allow folks to do a lot of things with your software, but they do impose some slight restrictions that are thought to be good long term choices for the development of the software. Sometimes these light restrictions might just be that people have to attribute you in some way, or that they can do anything they like but maybe they can’t patent or trademark the work, or that they can do whatever they like but have to state changes they’re making to the code. As mentioned, these are very common and MIT license is probably the one you see on a lot of GitHub repos if you’ve browsed there before. These are good for sharing work if you don’t mind it being used commercially but maybe you’d just like attribution or the ability to patent the work yourself later.

Copyleft licenses

Stepping quite a bit above the permission licenses are the copyleft licenses. This group of licenses have many different restrictions that can be imposed based on your needs. For example, you could share your software but restrict it from legally being used commercially. Or you can release your software in a way where any change or upgrade made by a company to the software has to then be released and shared back to the community (ensuring growth of the software even if a company latches on). Common copyleft licenses are the GNU GPL and their derivatives, IBM licenses, MPL 2.0, and many of the Creative Commons licenses (such as the CC BY-NC-ND 4.0). These licenses are useful in the scenarios where you want to share your work as educational materials or samples, but don’t want companies or other people from running away with your code (not that you can ever 100% stop that) and making tons of money from it. They can also be useful to ensure that the knowledge you’re donating into the community forever stays open to the community by not allowing a company to develop something out of your code without them also sharing their code. There are many variants of each to match your needs, but they’re all essentially “open-but-there-are-restrictions” types of licenses.

Further resources

There are many great resources online that can help you choose a license for your next project. A few I recommend are:

• Creative Commons Website: https://creativecommons.org/choose/
• Choose a License Website: https://choosealicense.com/
• Wikipedia page comparing free/open source licenses: https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
• EULA Generator (make sure you read the list of bullet points and either agree with them or edit them as you need): https://www.eulatemplate.com/eula-generator

Wrap up

Unfortunately there’s no catch-all solution that will work for every situation. You really need to start by thinking of your must-have needs/features/restrictions, and then explore the options that respect those. Hopefully between the options I’ve outlined above and the resources you can use to help research further, you’ll be able to choose a license or workflow that meets your needs. If nothing else, hopefully you’ll be pointed in the right direction. Enjoy!