Licensing Plug-ins for Other Applications: 5 Tips

By Abram P  |  Software Licensing Tips

Posted:  April 23

Blue puzzle piece plugging or fitting into orange puzzle piece.

Many commercial applications allow third-party developers to add new and/or enhanced functionality to them through modules called "add-ins" or "plug-ins." Since these modules are not standalone applications, and instead they are loaded by the vendor's application, they often present some unique challenges and options for licensing. 

The way add-ins or plug-ins (we'll use plug-ins from here on) work can change based on the hosting application that is loading them. The application will typically have its own unique hooks for plug-ins to use for interacting with the application as well. Consequently, the application's vendor will likely have documentation available that you should refer to for information on how plug-ins work and best practices with regards to plug-in development. 

Licensing Web Applications?

If you are developing one or more plug-ins for a web application, then we recommend you also read this related article on licensing web applications, as that is also applicable.

In most cases, the application is a Desktop application that "hosts" the plug-in, and the plug-in itself is either a Dynamic Link Library (DLL) or a .NET assembly that is loaded by the host application. There are two common ways these types of applications use plug-ins during run-time.

  1. Load and Unload:  Load the plug-in to perform an operation/action, and unload the plug-in when done. An example of applications that operate this way includes Adobe products, such as Photoshop. 
  2. Keep Loaded:  Load 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. An example of applications that operate in this fashion includes Microsoft Office applications, such as Outlook. 

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

Here are some points we can share from our own experiences with licensed plug-ins: 

  1. There are some cases in which it is best to validate your plug-in's license when it is initially loaded, such as: 
    • The application provides hooks to give your plug-in a chance to initialize itself and provide feedback to the application as to whether or not its features should be made available to the user. 
    • The plug-in is loaded only once by the application, and can be run repeatedly (especially if it can be run as part of a "batch" or bulk processing feature). 
    • The core logic that makes up your intellectual property is run rapidly, frequently, and/or concurrently. 
  2. There are other cases in which it may be best for your plug-in to validate its license when one of its core features is run: 
    • The application has a hook that allows the user to request running a particular plug-in feature, and a means with which to indicate why it might not be available to a user (e.g. displaying some kind of informative message to the user when license validation fails). 
    • The plug-in's feature is one that typically takes a long time to run or process. 
    • The plug-in's feature is not typically run as part of a larger batch/bulk processing function in the application. The one exception to this could be if there is a means to cache the license validation result so that your plug-in has a way to reduce overhead with license validation when run as part of a batch process. 
  3. Some applications that support plug-ins also use "sandboxing" for security purposes, and this can often impose limits on some things with respect to licensing. For example, plug-ins for Microsoft Office applications should generally be licensed and activated once for each user on a computer, as 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. Online validation has the potential to make things appear to be unresponsive depending on how the application interacts with the plug-in while it is performing its validation. This is just something to keep 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 to consider. 
  5. When implementing licensing for a plug-in, always consider the impact of being disruptive when the license validation fails. For example, if the plug-in itself is used for some mission critical process(es), then it might be best to find a way to at least initially notify users of license validation failures before making the plug-in or its features completely unavailable. An example could include things such as a plug-in that is used as part of a mass manufacturing process. 

There are always many things to consider with regard to licensing applications, and licensing plug-ins for other applications only adds to that list. If you’re currently using or considering using the SoftwareKey System, and you have questions about licensing a plug-in with it, our team is just a click or a call away.

About the Author

Abram Pousada is one of the passionate Software Engineers with SoftwareKey.com. He started his career with SoftwareKey.com when he was in high-school and has been with the company for over a decade. After-hours, the self-proclaimed geek enjoys a variety of engaging hobbies ranging from even more programming to video games and mountain biking.

Abram P


Tags


Related Posts

3 Steps to Validate Software Licensing, Protect Profits, and Keep Customers Happy

3 Steps to Validate Software Licensing, Protect Profits, and Keep Customers Happy
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>