© 2008 Hospitality Upgrade. No reproduction without written permission.
With continuing pressure to leverage all possible corporate assets, many organizations inventory their assets and discover potentially valuable, though overlooked, non-core in-house developed software. This software may have been developed to support the organization’s core business or may have been developed incidentally. It may have been acquired as an afterthought in an asset purchase or merger transaction, it may simply be the result of a now-terminated organizational project, or it may be the hitherto unsupported side project of the organization’s IT department. Regardless, when a “new” asset is discovered, there are several key legal concerns the organization should consider in evaluating whether to commercialize that software.
Provenance
Confirming What You Own
A key first step in commercializing any in-house software is determining its provenance, i.e., who owns the software.
Organizations need to be aware of how the work-made-for-hire doctrine might apply to this particular software. While an employer will own the copyrighted software produced by its employees, it is generally good practice to have in place development agreements with employees, particularly to address the right of the employer to file for patents. Such agreements are critical when using independent contractors.
Another pitfall in determining ownership of developed software relates to open source code and the licenses used in distributing it. While many developers like open source code due to its ready availability and high quality, certain open source licenses may require, for example, that any software incorporating the open source code be made available without cost and that the source code for that product also be freely available. Moreover, due to its nature, there can be no guarantee that any open source software does not violate third parties’ intellectual property rights. Incorporation of source code violating third parties’ intellectual property rights could subject the commercializing organization to extensive liability for infringement claims.
Protection
Intellectual Property Protection for the Software
Once the organization establishes what it owns, the organization must consider how to protect its software.
Traditionally, software companies have relied upon a combination of copyright law (which precludes direct copying of the asset, but does not protect the underlying idea) and trade secret law (which prohibits parties from appropriating trade secret information so long as the disclosing party puts in place adequate safeguards, such as licenses restricting the ability of licensors to disassemble source code in a product). In more limited cases, patent protection may be available for software processes. Though patent protection is far more costly and time consuming to obtain, strong patent protection can more completely prevent others from exploiting the patented software product and its processes. Even if patent protection is not ultimately pursued, an organization should consider an evaluation of existing patents in the field. Such a search might identify patents that could cause problems for the commercialization of the organization’s software product.
Another consideration is whether to obtain trademark protection in conjunction with the proposed marketing of the software product. Before substantial investment is made in any name for the proposed product, an organization should undertake an evaluation of that name from a trademark perspective. The recent Cisco v. Apple iPhone trademark dispute is a high profile example of problems to avoid.
Structure
Models for Commercializing
The next step for commercializing in-house software is to consider how to make it available to potential licensees.
In order to identify the appropriate type of licensing model, the organization should consider the following questions:
- How much support does the organization desire to expend on this product?
- Will there be a support organization in place to answer customers’ concerns?
- Will the organization continue to update the product and provide solutions for problems as they are discovered?
- Does the organization wish to control the product and simply provide access for use by third parties?
- Does the organization want to host the application?
The two most common models are the traditional software license model and the application service provider (software as a service) model. In the traditional license model, the organization has much less direct control over how the software is used, however, the organization can structure the license to limit its responsibility to the licensee altogether, for example, not providing warranties for the product and not providing maintenance and support of the product (though this would certainly impact the economic return the organization could expect to realize). Conversely, the ASP model gives greater control of how the software is used, allowing the organization to manage updates to the product and use of the product by its customers. However, this necessarily requires much greater support by the organization on an ongoing basis, including having infrastructure in place to run the software for customers.
As non-core in-house developed software is, by definition, not a part of the organization’s primary business, the organization should consider setting up a separate legal entity or partnering with others and supporting and operating the software business through such entity in order to limit the parent organization’s liability and to access marketing, support and other competencies that may not be available within the organization. In addition, understanding how the organization plans to view its relationship with its customers (either on a one-time basis or as a continuous one) will influence the terms both that the organization should be prepared to give to its customers, and that its customers will likely demand as to warranties for the software product, intellectual property indemnification and the overall limitation of liability for the organization.
The information provided is general and educational and not legal advice. Software commercialization and resorts and hospitality are among many of the areas supported by the law firm McGuireWoods. Co authors are Derek Roach, Stephen Gold and Michael Hepburn. Michael Hepburn can be reached for comment at mhepburn@mcguirewoods.