Part I: IP issues to consider in early-stage software development

Taking the right steps now will go a long way toward precluding problems tomorrow

Congratulations! You have a great idea for a new software product that’s going to change the world. You’ve worked with a lawyer to set up a corporate entity. You’ve mortgaged the house, hit up some friends, and tended some bar to gather seed money. You’ve hired some great folks to help develop requirements, code the product, and verify functionality. And you are talking to customers.

Right now, you’re not particularly worried about intellectual property rights issues.

But guess what? Now is the time to think about them. After all, your primary business assets are by their nature (and in their essence) intellectual property. It only makes sense to protect your rights in the IP you are creating, and to reduce the risk of unintended infringement of the rights of others.

Taking the right steps now will go a long way toward precluding problems tomorrow. The old saw “an ounce of prevention is worth a pound of cure” applies here, in spades.

This is the first of two articles that will briefly discuss key IP issues to consider. In this article we’ll focus on IP ownership and open source software. In the next article, we’ll take a look at the use of third-party proprietary code and tools, protection of IP rights, product clearance, and product licenses/service engagements.

Ownership

First, you should take steps to ensure your company has retained ownership over any and all code and related information created for the product you are developing. This includes code and information created by employees or contractors on your behalf, as well as the right to use insights customers may provide during development.

Specifically, your employment agreements should:

 • Preserve the company’s ownership interests in materials developed for the company in the course of employment

 • Obligate the employee to protect the company’s confidential information (as well as the confidential information of its vendors and customers)

 • Preclude the employee from participating in other work that is competitive to your present business as well as how it can be reasonably expected to evolve, at least during the time you employ the employee.

Your supplier/contractor agreements should adequately address ownership and confidentiality issues. Do not rely on “shop right” or “work for hire” theories to convey ownership for new works created by contractors – do it by contract.

Agreements with customers who may gain access to your code in various stages of development should preserve confidentiality, and authorize you to use/incorporate any feedback received.

Open Source

“Open Source” code is code that is distributed under an “open source” license agreement that, amongst other things, permits the code to be copied and redistributed on a royalty-free basis.

For example, many current open source software packages are subject to the terms of the GNU General Public License (GPL) Version 2, or “GPLv2.” Under the GPLv2, any code you create that is derived from the GPLv2 code:

 • May only be relicensed under the GPLv2

 • May not preclude creation of derivatives

 • The source code of the derived code must be disclosed to licensees upon request

The Software Freedom Law Center (SFLC) takes the position that the GPLv2 license applies to any product that includes the associated open source code, whether or not the code you wrote is “derived” from the code subject to a GPLv2 license.

In other words, SFLC believes any proprietary code that is distributed with GPLv2 code, as part of a single product package, is itself subject to GPLv2 license terms. While this interpretation of the GPLv2 has not been affirmed by a court ruling, from a planning/development standpoint it may be wise to carefully consider what product code is and is not included with open source code subject to a GPLv2 license.

In addition to GPLv2, other open source licenses have terms that could lead to required disclosure of product source code. For example, there is at least one version of GPL terms that specifically applies to hosted services (GNU Affero GPL).

To be clear, there is nothing inherently wrong with using open source code in your product. But there IS something inherently wrong with using such code without ensuring the related open source license terms are understood and complied with, and ensuring such terms do not impede your business objectives for the product.

Mark Chadurjian, a former senior leader in IBM’s intellectual property law department, is of counsel to Downs Rachlin Martin PLLC, with offices in Lebanon, NH, and Vermont.