In the fourth blog in our series of five, we’ll examine how dependencies on software outside OpenTAP and beyond your plugin itself can impact your choice of license. We’ll also pose some important questions for you and your organization regarding the status of the intellectual property in your plugin.
Dependencies on Other Software
No man is an island, and no software exists in a technical vacuum.
All types of software, even when presumably written from scratch, have dependencies on other software components. OpenTAP plugins can have dependencies upon
Existing plugins or templates used as starting points for your new plugin
OpenTAP core engine APIs and .NET APIs
Language run-time libraries (for OpenTAP, usually C# libraries)
Existing plugins that your plugin may call to implement needed functionality
Libraries that you may create to support multiple plugins or other software projects
Other third-party libraries from SDKs, open source projects, etc.
Nested dependencies, from the above-listed code upon yet other software components
To enumerate the dependencies for a plugin, you will need to review code and API usage in the plugin. Such a review can occur manually or preferably using Software Composition Analysis (SCA) tools that cross check against knowledge bases of open source project code. Some of those tools will also check for “snippets” – code fragments copied from open source projects or articles and pasted inline into your plugin.
Dependencies among packages hosted on OpenTAP.io appear as part of package metadata:
If there are dependencies upon open source code, you will need to examine the licenses for those dependencies. Broadly speaking, “liberal” licenses – Apache, BSD, MIT, Mozilla and similar licenses – will require minimal compliance effort when distributing derived works. “Reciprocal” licenses, especially those in the GNU Public License family (GPL et al.) may require that you disclose part or all the source code to your plugin and/or license it under the same or a similar restrictive license.
Status of Intellectual Property
You and your organization will need to consider the status any intellectual property embodied in your plugins. In particular . . .
Does your plugin contain closely-held / proprietary intellectual property (IP)?
If your plugin contains closely-help IP – trade secrets, software patents and code implementing methods patents – you will need to work in concert with your legal department in advance of releasing. Issues include
You may want to protect that IP by releasing the plugin as proprietary software or as the proprietary portion of an “open core” deliverable, wherein the commodity functionality is open source while the value-added portion is not,
If your plugin contains patented material, you should consider making a patent grant or license for use of that IP in the context of an OpenTAP plugin license. Alternately, you should warn potential users of such patented technical material that your organization will require negotiation of a patent license for its use.
Do you intend to keep the source code proprietary within your company?
Even if the underlying OpenTAP platform is open source, there is no requirement for plugins to be released to any third parties.
Next Time
In the last blog in this series, we’ll look options for hosting your plugin and plugin distribution strategies.
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