By David H. Levitt

When a customer contracts with a software vendor to license software and support services, it is not always true that only the vendor provides intellectual capital to the project. Often the customer provides significant value; sometimes the customer creates niche solutions that have potential market value in the community. We have seen occasions where the vendor has used the solutions that it developed for, and in conjunction with, a customer and is marketing those solutions to others in the customer’s industry.

Customers should have a better understanding of the intellectual property issues presented in such situations. While, in the end, they may not be interested in owning the IP rights, they should know what their options are, including: a hierarchy of rights/terms that can be negotiated; boilerplate language that can be used in RFPs and contracts with technology vendors; and strategies for deriving economic value from the significant intellectual capital that the customer puts into each project (whether through royalties, licensing agreements, obtaining patents or simply obtaining a reduced price from the vendor due to the vendor’s potential revenue on other projects).

The primary, but not the sole, IP most likely to be at issue is copyright. On occasion, potential patent rights might also be implicated. Also, depending on the project (e.g., financial software), there might be trade secret issues involved from time to time as well.

The remainder of this article sets forth the issues to consider.

Ownership of Intellectual Property

In general, the creator/inventor is the owner.
In patent law, the owner of the work is the inventor. In copyright law, which generally is most applicable to software projects such as those under consideration, the person who fixes the expression in a tangible medium is the creator of the work – and the owner of the copyright.

So, for example, if someone hires an architect and provides him or her with their plans for a dream house – all of the specifications, specific features desired, etc., -- and is involved every step of the way in approving plans (suggesting ideas and changes, etc.), which the architect then uses to create architectural drawings for the house, most of the case law holds that the architect, not the home owner who hired the architect, owns the copyright to the house.

Sometimes, an issue arises regarding who is the creator. The Copyright Act says that the owner is person who created the work “by or under the authority of the author.” Courts have held that the “under the authority” language applies where the author authorizes someone else to embody the work. However, this doctrine is limited for the most part. The process must be a “rote or mechanical transcription that does not require intellectual modification or highly technical enhancement.” Andrien v. Southern Ocean County Chamber of Commerce, 927 F.2d 132 (3d Cir. 1991).

Application of this principle to independent contractor software vendors usually will mean that the vendor, not the customer, will own the copyright to software that the vendor creates at the customer’s instructions. Creation of software usually involves highly technical enhancement.

Joint Authorship
Often, customers may have significant involvement in the creation of the expression. Customer personnel might create some of the computer code, or might at least review the code prepared by the vendor and suggest modifications/changes. There is, then, a possibility that the customer could be considered a “joint author” with the vendor in the IP rights (particularly the copyright) of the finished work. Joint authors each have the right to exploit the work however they see fit, without the permission of the other. So the customer can use the work as it wants without approval from the vendor; the vendor can do the same.

However, courts generally do not find joint authorship and have strictly construed it. Section 101 of the Copyright Act defines a “joint work” as one “prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole.” “Intention” has been italicized for emphasis because the courts most often rely upon the intention in deciding this question. They use it most often to find that there is no such intention, and therefore no joint authorship.

To protect one’s rights in ownership of IP, it is best not to rely upon interpretations of the Copyright Act. Rather, in contracting with vendors for software, specific provisions for ownership should be considered, negotiated and included in the contract.

Works Made for Hire/Assignments
This is one of the most misunderstood areas of intellectual property law. It should first be noted that the “works made for hire” principle applies only to copyright law. When other types of IP are at issue, this doctrine is not applicable.

“Works made for hire” is defined in Section 101 of the Copyright Act. It provides that works by employees in the scope of employment are automatically works made for hire, and that the employer, not the employee, owns them from the time that they are fixed in a tangible medium.

Again, note that this does not apply to other IP rights, such as patent rights. That is why employment agreements with employees, in which employees agree to assign their inventions to employers, are needed and recommended. Although, such agreements must comply with the Illinois Employee Patent Act, which is beyond the scope of this paper, but should be noted for the sake of awareness and completeness.

When the work is not created by an employee, but instead by an outside contractor/vendor, there is no automatic transfer of copyright ownership to the purchaser. To the extent that the work made for hire doctrine applies at all, it can only apply where the work is specially ordered or commissioned; expressly agreed in writing to be a work made for hire; and falls within one of nine specific categories, such as a translation, an instructional text, a test, and others. In general, the software projects under consideration here would not fall within any of these nine categories. So, even if there is a written agreement that expressly refers to the work as a work made for hire, it still would not be one and ownership would not be in the customer.

That is why, when ownership is desired, the contract with the vendor should also provide that the vendor assigns ownership of the work to the customer. This transfer of ownership clears up any ambiguities. Moreover, unlike the work made for hire doctrine, an assignment need not be limited to copyright IP ownership.

As to copyright, an assignment is not as good as outright initial ownership, because the Copyright Act provides that the original author can revoke the assignment between 35 and 40 years after publication of the work or the assignment, following certain procedures. This is less likely to be important in a software copyright context, given the anticipated useful life of most software, but the customer should be aware that the issue exists.

Suggested Boilerplate Language
Here is some language that a customer might use in RFPs and in contract negotiations as it pertains to ownership. As you’ll see, it initially refers to the work as a “work made for hire,” but then provides that the vendor assigns all IP rights to the customer in any event:

• Ownership of Work. All software, source code and other enhancements of and improvements designed, developed or created by [Vendor] for [Customer] shall be deemed “work made for hire” within the spirit and purpose of the Copyright Act of 1976. The ownership of all right, title and interest, including all patents, copyrights, trade secrets, and any other form of intellectual property, in and to all software and source code and all other aspects of the work developed hereunder, and any derivative or enhancement thereof, shall now and at all times remain the sole and exclusive property of [Customer].
• Without regard to whether or not the work created under this Agreement is considered a “work made for hire,” [Vendor] hereby irrevocably transfers and assigns to [Customer] ownership of all right, title and interest, including all patents, copyrights, trade secrets, and any other form of intellectual property, in and to all software and source code and all other aspects of the work developed hereunder, and any derivative or enhancement thereof, which shall now and at all times remain the sole and exclusive property of [Customer].
  
  

Consequences of Not Owning the IP

IP law gives certain exclusive rights to the owner of the IP. In patent law, the patent owner may prevent others from “practicing” the invention. In copyright law, aside from denying permission to others to make copies of the work, the Copyright Act also gives the copyright owner the right to prevent others from making “derivative works”; that is, works based on the preexisting work.

Limitations on a customer’s use of the work it funded and participated in creating
In the software context, this could be significant. Suppose a vendor creates and owns the IP to a software program it developed for a customer. Later, the customer wants to modify the tool or project – new data has come in, or the customer wants to change the web design, or wants to modify the tool from being PC-based to web-based. In other words, the customer wants to write new code to enhance the existing product or make it more useable. If this is done based on the original software created/owned by the vendor, it could constitute a derivative work. The original vendor could prevent the customer from doing this except on the vendor’s terms (unless the contract with the vendor provides otherwise).

Or suppose that the customer wants to consult with a different vendor about improving the software. To do so, it would have to share with that other vendor the source code provided by the first vendor. To do that, it might be necessary to give the second vendor a copy of the software created/owned by the first vendor. The mere act of making that copy for inspection by the second vendor is a potential copyright infringement.

The same is potentially true if, for example, the customer wants to share its product/process with another industry institution, to improve the industry generally. If the vendor, rather than the customer, is the owner of the IP to the software, then the customer’s act of sharing the work with the other institution is a potential infringement of the vendor’s IP rights.

Even without getting ownership, these types of issues can be dealt with in the contract with the vendor. There could be provisions about what uses the customer can make of the software – the scope of the license. The contract might provide, for example, that the customer gets a royalty free right to create and own derivative works.

Loss of potential revenue stream from licensing work to others
As noted already, vendors sometimes take what they have learned on one customer’s project to market that software to others. In other words, the vendor is attempting to derive revenue from projects in which the customer expended significant intellectual capital as well as funds. However, if the vendor, rather than the customer, is the owner of the IP, then only the vendor has the right to this revenue stream.

Again, the contract can be negotiated to include solutions to this revenue issue. The contract could provide that, for example, the vendor will pay a royalty on each sale of the software to others. It could provide for a reduction in the price that the customer pays for the project based upon the projected income that the vendor will make on the software in the future. This later option may be difficult to negotiate as it is hard to predict at the beginning of a project how much revenue might eventually be derived. This is especially true for a software vendor who is not in the customer’s industry and does not know the marketplace. At the same time, the vendor has an idea of how much manpower/man hours will be expended to complete the project for the customer. Also, a price reduction may not truly reflect the possible economic value of the product/work in the market, so the customer might end up selling it “short.”

Conclusion

There is much more give and take in software contracts than one might expect. Most often, the vendor presents its own form, and many customers assume that the provisions are not subject to negotiation. While each situation – and each provision – is different, vendors are generally willing to be flexible. There are many provisions where such flexibility might be exhibited. Customers should at least be aware of the proposed contract provisions regarding ownership of IP and scope of license so they are in the best position to maximize their use of the software they are acquiring, and their own intellectual capital contributions to the project.

This publication has been prepared by Hinshaw & Culbertson LLP to provide information on recent legal developments of interest to our readers. It is not intended to provide legal advice for a specific situation or to create an attorney-client relationship.