Account Links: Cart | Register | Log In

Skip to content

Best Practices: Legal and Intellectual Property
by Mark Webbink, SVP, General Counsel and Secretary


What are some best practices for the corporate legal organization with respect to software?

As with any form of intellectual property, there are risks associated with licensing the use of software. Some of those risks may relate specifically to open source software, but most often they relate to all software, regardless of the form of license. Following are a series of best practices every corporate legal organization should implement across its company:

  1. Do not permit the uncontrolled importation of software onto company computers. Do not permit employees to download freeware, shareware, or open source software onto company computers without first clearing the license terms with the legal department. At the same time, bar the use of proprietary software except to the extent that the company can account for the permitted licenses. In other words, know what you are putting on your machines--to do otherwise exposes your company to risk.
  2. Deal with reputable software vendors with financial staying power. One of the biggest risks a company takes is adopting software that has no future. Equally true is licensing software from a company without the financial wherewithal to maintain and protect that software. Know your vendors. Know their financial strength, know their policies on licensing, know their responsiveness, and know that their software is reliable.
  3. Know how the software will be used. It's one thing if open source software is to be used as an operating system on a back-office server, it is something altogether different if that same open source software is to be modified and embedded in a product. The former is not problematic; the latter may be. At the same time, make sure your IT folks are well aware of the typical proprietary restrictions that prohibit reverse engineering or modification. While some proprietary vendors may permit such activities under a special development license or a community source code license, they do not generally permit the activities under their general commercial licenses. It may be worthwhile to categorize each item of software and its permitted uses, e.g., approved for general use in executable form only, approved for use at the source code level in specialized applications or modified applications, and not approved for any use. Finally, nature of use is important in knowing whether the software will be distributed outside the company, potentially triggering open source licensing restrictions.
  4. Have a means for documenting what software, and what version of that software, is in use. Knowing this information and having ready access to it will help assure licensing compliance and at the same time permit IT managers the ability to manage the IT architecture and its advancement.
  5. Require documentation of all internal software development projects. This includes modification of open source software. Such documentation should indicate the source of any base software that is modified, all of the authors of the developed software, prior projects (both internal and with prior employers) on which such developers worked, and the identification of any known related intellectual property, particularly patents.

How does Red Hat take reasonable care to ensure that they are not infringing on IP rights of others?

There are those who like to paint the open source community as a bunch of ragtag geeks with no discipline and no respect for the intellectual property of others. At Red Hat, experience has shown this to be anything but the truth. Open source developers are some of the most disciplined around. They understand that, for open source code to be worthwhile, it must be well documented. They understand that for others to build on that code, it is important to maintain historical change logs. And they understand that proprietary rights must be respected. As a consequence, Red Hat's intellectual property review procedures start with our developers.

Before a new project is undertaken, participants educate themselves in the known prior art, at least to the extent it is available. Obviously, they don't have access to proprietary source code, even where that source code has been submitted for registration with the U.S. Copyright Office (filing requirements with the USCO do not require the a filing party to submit a full copy of the source code, only a smattering of pages that define the beginning and the end of the claimed code). Likewise, they have no access to unpublished patent applications. These facts are true whether one is dealing with proprietary software or open source software, so a (not insignificant) portion of the development process is always going to be working in the blind, not knowing what rights are claimed but not known publicly. Despite these handicaps, due care is taken.

A second level of care within the software engineering environment occurs with the avoidance of contamination. Contamination is the term used when a programmer (whether open source or proprietary) is exposed to the proprietary source code of another party such that they will have potentially gained knowledge of that source code. Red Hat's developers go to great pains to avoid such contamination, thus increasing the assurance that code they develop is developed independently.

When a possible intellectual property concern arises, it is raised to Red Hat's legal department. There it is reviewed and, based on the best public information available, a determination is made whether to include the code or whether it exposes the distribution to potential material claims. In addition, licensing terms are reviewed to assure that open source rights to the new code may be properly extended to others.

In summary, many of the same intellectual property review practices observed in proprietary software companies are observed by Red Hat.