In the third blog in our series of five, we’ll lay out key business and technical considerations for choosing a license.
Licensing Considerations
Choosing a license for your OpenTAP plugin should not be a daunting task. However, there are key considerations you need to address regarding your plugin itself and your business and technical goals in creating and distributing it.
These considerations include
Business goals
Technical goals
Dependencies on other software
Status of the intellectual property involved
Some of these considerations are actually interlinked, requiring extra attention, and most cascade into sub-considerations.
Let’s examine them one by one.
Business Goals
Let’s start by determining how your plugin will support your business.
Internal use only
End-users of OpenTAP typically develop plugins to contain test steps, describe devices under test (DUTs) and support legacy test equipment. If you don’t plan to share your plugin with third-parties, you have maximum freedom in choosing a license and may elect only to make copyright claims for it. By keeping the plugin as internal-only, however, you will lose the opportunity for community collaboration around support and enhancement. The entire technical burden will lie with you and your organization.
Accompany/support another product, e.g., an instrument, device or another plugin
Instrument suppliers and device manufacturers who want to encourage use and ease integration of their hardware will want to supply OpenTAP plugins to their customers and partners, usually shipped together with their products or on their company web sites. For these use cases, plugin publishers have the greatest flexibility in choosing a license. However, if the immediate recipient of your plugin is also likely to redistribute it “downstream”, you will either need to craft a proprietary license allowing such redistribution or choose a compatible open source license.
Sell as shrink-wrap software
You may create a high-value standalone plugin, e.g., a rich result listener or an instrument interface for legacy test equipment that you would like to monetize. The most obvious path is to distribute such software under a perpetual EULA, but there is nothing preventing you from creating and marketing commercial plugin software under a renewable subscription or an open source license.
Technical Goals
The most common technical goals are aligned with the business goals above – enabling product test automation and interfacing to test equipment and/or other plugins. Following are some additional, primarily technical goals for creating and distributing a plugin.
Addressing new test instruments
Both end-users and instrument manufacturers may wish to integrate support for new test equipment that is not currently supported by OpenTAP and existing plugins.
Extending functionality of an existing plugin
You and your organization may need to enhance or re-architect an existing plugin to meet your technical needs. Another scenario might be rehosting a plugin to a different execution platform, e.g., from Windows to MacOS or Linux. If the existing plugin is open source, you will be best served by enhancing that plugin through project contributions, or you can fork it wholesale and create a new plugin. But not all plugins are open source. Alternately, the plugin of interest may be open source but published under a license not approved by your legal department. In either of these cases, your best strategy may be to create a new plugin.
Adding completely new capabilities to OpenTAP
The OpenTAP architecture is highly flexible, with plugins the main path to extending functionality (vs. modifying the core engine). Possible new capabilities implemented as plugins include adding new language support (e.g., for GO or Rust), creating integrations with other software frameworks (e.g., Jenkins, or SCM and SCA systems or inhouse enterprise software) – the sky’s the limit!
Fixing bugs in existing plugins
If you find bugs in an existing plugin, the easiest path is to report the bug to the plugin author or maintainer – this method applies to both proprietary and open source plugins. For open source plugins, it may be faster, to fork the plugin and create your own fix. Note though, that even if you also create a pull request, your patch may not be accepted, and you can find yourself maintaining that fork for the remainder of its life.
With both private and community forks, your organization must be comfortable with the existing plugin license, especially if you need to redistribute it.
Next Time
Next time we’ll examine how dependencies on software outside OpenTAP and beyond your plugin itself can impact your choice of license and your plugin distribution strategy.
Enriching the OpenTAP Ecosystem
The OpenTAP ecosystem spans the gamut of end-users to integrators to test equipment manufacturers and beyond. New and incremental functionality from plugins is a key factor for making the OpenTAP platform attractive and helping test automation address the highly dynamic technology marketplace.
Take the first step.
Visit OpenTAP.io and join the OpenTAP Community.
· Learn about how to write and package plugins – Video: Creating OpenTAP Packages
· Check out a template for building plugins
· Explore the OpenTAP Project on GitHub