When most people think about software licensing, they probably think about a license key as a string of characters that gets entered into a plugin, checked by a server and that determines whether the software can be used.
For an audio plugin developer, though, a license is much more than that. A license represents a relationship between a developer, their product and their customer. It tells the developer what has been purchased, who is entitled to use it, when it was activated and, potentially, what happens to that entitlement over time. The license key is really just the visible part of a much bigger system.
The license lifecycle
Creating a license might be relatively straightforward but the more interesting challenge is everything that happens afterwards. A license needs to be associated with a product and a customer, it may need to be activated on different machines, deactivated, renewed, upgraded or transferred. A customer may install a new version of a plugin or contact support because something isn't working as expected.
All of these things form part of the license lifecycle.
This is one of the reasons licensing can become more complicated than it initially appears. What starts as a simple mechanism for protecting a plugin can quickly become an important part of the infrastructure supporting the whole product.
Licensing also sits across a number of different parts of an audio business; it connects the product with the website, the checkout, the customer, customer support and, increasingly, the data generated by all of those interactions.
When those systems aren't connected properly, licensing can become another source of technical and operational complexity. Developers can end up building workarounds, maintaining different systems and spending time trying to understand what is happening across their customer base.
The data
There is another aspect that we think is particularly interesting: the data.
Every license interaction creates information, a product has been purchased, a license has been activated, a customer has installed a particular version, a license may have become inactive or a customer may have upgraded from one product to another.
This isn't about collecting unnecessary information about customers, it is about making better use of the operational data that naturally exists within the licensing process. Undertaken properly, licensing can give developers a much clearer picture of how their products are being used and where customers are in the product lifecycle.
Invisible to the customer
For the musician or producer buying a plugin, licensing should ideally be almost invisible, they want to buy the product, install it, activate it and get on with making music. They shouldn't have to understand how the licensing infrastructure works, and they certainly shouldn't experience any friction with licensing every time they install a plugin or change device. The complexity should sit behind the scenes.
The way audio products are sold is also changing, perpetual licenses, subscriptions, upgrades, bundles, transfers and potentially secondary markets all create different requirements for licensing. The infrastructure needs to be flexible enough to support those changes rather than forcing developers to rethink their licensing architecture every time their business model evolves.
What we're building
This is what we're trying to address with Polaris.
We don't see Polaris as simply a system for generating license keys, we see licensing as infrastructure that should be straightforward for developers to integrate, reliable for customers to use and flexible enough to support the way audio businesses evolve.
We're building Polaris specifically around audio plugins because we believe the needs of audio developers are worth understanding properly. The licensing system should fit around the product and the business, rather than becoming another technical problem that the developer has to solve.
A license may look like a key to the customer, but behind that key is a much bigger system of products, customers, permissions, activations, transactions and data.
We think that infrastructure should be something audio developers can rely on.