5 Things to Know About Licensing Plug-ins

Licensable software comes in all shapes and sizes. Standalone desktop applications and web applications are two common examples, but there is also a large market of software that runs as "add-ins" or "plug-ins" inside a larger desktop or web application. These components extend the functionality of the host software they run under. Common examples include Adobe Creative Cloud products, stock market trading software with plug-ins for indicators, and Computer Aided Design (CAD) applications.

Because plug-ins are not standalone applications and are instead loaded by the vendor's application, they present some unique challenges and options for licensing. This article explains how licensing works in these environments and the key considerations for your license management integration.

How Plug-ins Work

The way add-ins or plug-ins (we will use "plug-ins" from here on) behave can change based on the hosting application that loads them. The host application typically has its own unique hooks that plug-ins use to interact with it. For this reason, the host application's vendor will usually publish documentation that you should refer to for information on how plug-ins work and for best practices around plug-in development.

In most cases, the host is a desktop application, and the plug-in itself is either a Dynamic Link Library (DLL) or a .NET assembly that the host loads. There are two common ways these applications use plug-ins at run-time:

1. Load and unload. The host loads the plug-in to perform an operation or action, then unloads it when done. Adobe products such as Photoshop are an example of this approach.
2. Keep loaded. The host loads the plug-in once for the duration of the process (or for as long as it is open), often when the application is first launched. Microsoft Office applications such as Outlook are an example of this approach.

Each approach has its own advantages and disadvantages, which often require further plug-in design considerations with regard to performance and security.

Licensing Web Application Plug-ins

If you are developing one or more plug-ins for a web application, the considerations for licensing web applications also apply. Review your host application's documentation for how plug-ins are loaded and how they interact with the web application before deciding where to place your license checks.

5 Tips for Licensing Plug-ins

Here are some points drawn from real experience with licensed plug-ins.

1. Sometimes it is best to validate when the plug-in is loaded

In some cases it is best to validate your plug-in's license when it is initially loaded, such as when:

• The application provides hooks that give your plug-in a chance to initialize itself and report back whether its features should be made available to the user.
• The plug-in is loaded only once by the application and can then be run repeatedly (especially if it can run as part of a "batch" or bulk processing feature).
• The core logic that makes up your intellectual property runs rapidly, frequently, and/or concurrently.

2. Sometimes it is best to validate when a feature runs

In other cases it may be best to validate the license when one of the plug-in's core features is run, such as when:

• The application has a hook that lets the user request a particular plug-in feature, along with a means to indicate why it might not be available (for example, displaying an informative message to the user when license validation fails).
• The plug-in's feature typically takes a long time to run or process.
• The plug-in's feature is not normally run as part of a larger batch or bulk processing function. The one exception is when you can cache the license validation result, so your plug-in can reduce license validation overhead when run as part of a batch process.

3. Account for sandboxing limits

Some applications that support plug-ins also use "sandboxing" for security purposes, which can impose limits on what you can do with licensing. For example, plug-ins for Microsoft Office applications should generally be licensed and activated once for each user on a computer. The sandboxing mechanism used by Microsoft Office applications (known as Click2Run) makes it very difficult to apply a single license activation to all users on a computer.

4. Watch for online validation appearing unresponsive

Online validation has the potential to make the host application appear unresponsive, depending on how the application interacts with the plug-in while validation is in progress. Keep this in mind when configuring how frequently a licensed plug-in phones home to the central licensing server to verify the state of its license, especially when batch operations are a factor.

5. Consider the impact of disruption on validation failure

When implementing licensing for a plug-in, always consider how disruptive a license validation failure will be. If the plug-in is used for mission-critical processes, it may be best to first notify users of validation failures before making the plug-in or its features completely unavailable. A plug-in used as part of a mass manufacturing process is one example where an abrupt failure could be very costly.

Summary

There are always many things to consider when licensing applications, and licensing plug-ins for other applications adds to that list. Decide where to validate the license (at load time or at feature run time) based on how the host loads and uses your plug-in, account for sandboxing and performance, and plan a graceful response to validation failures so legitimate users are not unexpectedly blocked.

If you are using or considering the SoftwareKey System and have questions about licensing a plug-in with it, please contact our team.