The Journal of The DuPage County Bar Association

Back Issues > Vol. 18 (2005-06)

Open Source – Friend or Foe?
By Kevin M. Gard and Jen Salyers

Software is often derived from a number of sources. Over the last decade, the use of something called "open source" has gained popularity. However, without a clear understanding of what open source is and the various rights and restrictions associated with its usage, it is possible to unintentionally take on additional risk and in some cases give up valuable intellectual property rights in software developed with open source.

Consider Robert, the owner of a local inventory-consulting firm, who enters your office seeking counsel. Robert is very excited about an innovative new automated inventory ordering software program his firm has just completed developing. Robert is anxious to beta test the program with several of his clients, but thought it best to obtain your services to make sure he had covered his bases.

Robert goes on to explain how his firm, through tightly managing his development budget and savvy cost saving initiatives was able to (a) take advantage of his firm’s existing software as a foundation for the new software; (b) obtain several of the new software’s components through shrewd negotiations with third party licenses; (c) retain the cheap the labor of college students for basic coding, and; (d) picked up several "free" applications off the internet that were easily integrated into the new software.

Being quite impressed with his success thus far, it may be your number one job to let Robert know he must put the brakes on his project or potentially risk losing all rights to his new software and put his investment thus far in jeopardy.

Delicately, you let Robert know that in addition to the typical due diligence necessary to evaluate all developer’s contributions to the new software and the potential risks they present to the life cycle of the new software (which is beyond the scope of this article), you inform Robert that the "free" applications found on the internet and integrated into his firm’s new software will require specific attention.

You explain to Robert that the term "free" is only meant to relate to actual price to use the downloaded software. Free software, or more commonly referred to as "open source" software may come without an actual licensing or distribution price tag, but it can be far from free. The miss-application of open source software can inadvertently place the new software in the public domain and expose Robert to claims from the open source authors for violations of the underlying license terms. At this juncture, you deem it a valuable education to share with Robert a bit of the history, benefits and challenges commercial businesses encounter when integrating open source software into their products.

Then, Robert asks, what exactly is open source? In your response, you explain that open source licensing refers to making the source code for a software program openly available at no charge for the public to work with it. Typically, a community of developers works with the source code, creating enhancements and extensions and improvements, which are in turn freely shared back with the community and further enhanced, extended and improved.1  "Open" means open access to source code and peer-review by an open community of developers. Robert may think this is describing his firm’s use, but there’s more. You explain that around 1989, the free or open software movement began as a reaction to proprietary (closed source) software that was available for a fee and only in object code (machine readable version) form. As a means of nurturing the technical community’s desire to "see how it works" and "make it better", the open source movement began. About the same time, the Open Source Initiative (OSI)2  was organized to promote a pragmatic approach to commercial use of open source software. The OSI has established criteria for a software license to qualify as an open source licenses based upon conditions that that assure the software intended to be governed by the OSI open source license maintain the original principles of open use by the community.3 

Robert interjects that he’s not so sure about this "open access to all" concept, but he does know that his development time has been greatly reduced by utilizing open source code, that from what he can tell, several respected developers contributed to the open source’s development giving him confidence of its integrity and adherence to industry standards, and the bottom line is the huge cost saving of not having to reinvent the wheel.4  All of Robert’s asserted benefits of utilizing open source code in a commercial product are accurate; however, he must also acknowledge the challenges of using open source.

It is very important for Robert to weigh the potential benefits against the potential risks and obligations relative to integrating open source software into his firm’s new software. A few risks include:

No intellectual property protection. Typically open source software is offered without intellectual property indemnity or any warranty language of any kind. Accordingly, if ever Robert receives a claim alleging the open source code infringes upon another’s intellectual property; his firm is left holding the bag. In addition, several open source licenses (ex. MPL or IBM-CPL) revoke the imbedded open source license granted in the event the user/distributor (like Robert’s firm) brings patent infringement action against the grantor. Therefore, it is imperative for Robert to attempt to perform his due diligence in evaluating the infringement potential. Other newer open source licenses (CDDL) actually do provide patent protection.

Encumbrances. In some cases, the open source licenses may require the modified or linked code to be cross-licensed or contributed back to the community. The "General Public License" ("GPL") is an open source license that does just this. The GPL requires the user to cause any work that it distributes or publishes, that in whole or in part contains or is derived from the GPL licensed program, or any part thereof, to be licensed as a whole at no charge to all comers under the same terms as the original GPL license. The goal of the GPL license is to prevent anyone from taking the original open source or any derivative thereof and making it private.5  This is known as a "copyleft" provision. Violations of the GPL can include substantial monetary damages and injunctions which could stop shipment and/or mandate the release of code. While the copyright to the modifications to the GPL will be held by the party creating the modifications, once distributed, the normal ownership rights are degraded significantly by the requirements of the GPL. For example, if distributed, the party must also provide the source code to the software and allow for copying, modification, and redistribution, all without compensation to the author. Strategically, if a developer can separate identifiable sections of his work that are not derived from the open source program, and they can be reasonably considered independent and separate works in themselves, then the GPL license terms would not apply to that code. Therefore, on the same distributed disk, there may be portions of the new software proprietarily protected by Robert’s end user license, and other portions rightfully governed by the GPL license.

Restrictive or ambiguous license terms. Some open source licenses are poorly worded so the terms are restrictive or ambiguous, thus raising serious interpretation issues. This is common when a developer tires to create his own open source license crudely based upon an existing approved OSI license and does not rely on existing OSI certified open source licenses or OSI certification of his newly created version.

Support costs. Although the open source code may seem to be "free" initially because there is no license fee or royalty attached to use, there may be downstream support costs that must be considered. Is Robert’s firm capable and/or competent to address these support needs of forthcoming customers if issues arise? Are support resources available via the original open source developers? This may be either a hidden revenue generator for Robert or a major problem depending upon the availability of support resources for the open source.

Unclear Ownership. The origin and ownership of the open source code may be unclear. Little may be known about the author or contributors. Did they originate the code, or was it wrongly lifted from others’ code? Acknowledging the lack of intellectual property indemnification, without a clear chain of authorship, Robert’s firm runs the risk of undisclosed authors later appearing threatening to halt distribution and/or seeking damages for wrongful use.

Cumbersome attribution requirements. The open source license may include cumbersome notice and attribution requirements that must be followed and will require Robert’s firm to clearly spell out in either header files or introductory screens of his firm’s new software the origins and attributes of the open source code. This gives credit where credit is due, but can be cumbersome and distracting when presented in a commercial product.

Impact on current or future business objectives or strategy. The impact on Robert’s firm’s current and future business strategies must be considered. Robert needs to make sure that a short-term solution to development schedule pressures does not become a long-term headache for his firm. Robert’s use of open source may also raise concerns for customers considering the use of Robert’s product. While Robert’s firm’s use of open source may not be surprising to a licensee, savvy customers will expect Robert’s firm to stand behind the open source in the same way it stands behind the rest of the product, with the same warranties, indemnification from third-party intellectual property claims, and maintenance and support. Furthermore, if Robert’s firm’s product is one that can be integrated with any of its customer’s software, this could also raise concerns for Robert’s customers. Those customers will want to understand if the use of the open source in Robert’s firm’s product with the customer’s software could jeopardize any intellectual property rights the customer has in its software. If so, Robert may find that customers are reluctant to purchase his firm’s product.

Any of the above referenced issues coming to fruition could result in negative publicity and/or lawsuits for Robert’s firm. In addition, watchdog groups and courts are becoming more active in enforcing open source licenses in the commercial arena. In April 2005, a Munich court ruled that a British software company must stop selling and distributing products that incorporate open source software unless those products comply with the terms of the incorporated open source license (GNU General Public License).6 

Common OSI approved open source licenses include the BSD, GPL, LGPL, Apache, MIT, MPL and CDDL. OSI maintains a list of approved open source licenses that conform to the open source definition, have been through public scrutiny, and have received their approval. These open source licenses run the gamut regarding their integration friendliness in commercial products, but to their credit do give the reader familiarity and comfort relative to the consistency of their identical content – good or bad. Therefore, prior to committing to using any license as part of the new software, each component’s license should be carefully reviewed. However, it should be noted that many open source licenses are not OSI approved, may be derivatives of certified open source licenses, or simply piece-meal constructed by the author/developer, thus requiring a scrutinizing eye by the reviewer. Furthermore, use of non-OSI approved licenses in commercial products may lead to additional concerns from customers who are unfamiliar with the license terms. Customers considering purchasing such products need to understand if incorporating the product into their environment could impact the intellectual property rights in anything integrated. For a stand-a-lone commercial product this is less of a concern.

So, how does Robert protect his investment, but not let go of the benefits his new software has received from the integration of the open source code? To limit the risk, Robert should adopt a best-practices approach comprised of appropriate management controls regarding use of open source; education of employees regarding the unique aspects of open source; and enforcement compliance with these controls and policies.7  Such best-practices should include:

ü Due Diligence. All open source licenses utilized should be closely reviewed to identify the contents and requirements of each license, their authors’ identities, likelihood of exposure to liability and license requirements.

ü Bifurcation of Code. As referenced above, if necessary, if technically feasible, it should be considered to separate proprietary code not derived from open source from the actual open source itself. This limits the applicability of the open source licenses to the proprietary code (avoid GPL copyright issues).

ü Notices. Make sure all notices and attributions have been integrated as instructed within the applicable open source licenses.

ü Open Source Technical Support. Confirm a support mechanism is in place in the event any error arises relative to the open source components. This may be a revenue generating opportunity. If Robert’s firm is not able, maybe the original authors provide such a service.

ü EUL Language Clarifiers. Integrate disclaimers in the end user license ("EUL") relative to open source components relating to intellectual property indemnification and no warranties.

ü Inclusion of Open Source Licenses. Provide the related open source licenses in "readme.txt" files or introductory screens as directed by the licenses governing the open source code.

ü Service Provider Alternative. Alternatively, Robert’s firm may consider open sourcing the new software entirely and revise its business model to providing implementation services and code maintenance to end users as a means of generating revenue.

ü Reinvent the Wheel. As a means of avoiding the open source issue entirely, Robert may consider utilizing alternative third party code components or creating them in house. Yes, an additional expense, but such a course of action does minimize risk and provide peace of mind by not having to invest in an open source compliance program.

Conclusion

As described in this article, any use of open source should be carefully evaluated. While the use of open source code can have significant cost and time savings benefits for the developer, its usage, if not properly managed, can also have a serious impact on the ownership and marketability of the resulting product, and may also impact the rights of the end user. While this article’s primary focus is on the developer’s use of open source, end users of products containing open source should also consider what risks they may be assuming and if it’s appropriate for them to assume those risks.

 1 Christian H. Nadan, Open Source Licensing: Virus or Virtue?, 10:249 Texas Intellectual Property Law Journal 352 (2002)

 2http://www.opensource.org/docs/definition.php

 3 Open Source Initiative, The Open Source Definition at http://www.opensource.org/docs/definition.html (visited March 29, 2006) Definition, (a) The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale, (b) The program must include source code, and must allow distribution in source code as well as compiled form, (c) The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software, (d) The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software, (e) The license must not discriminate against persons or groups, (f) The license must not restrict anyone from making use of the program in a specific field of endeavor, (g) The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties, (h) The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution, (i) The license must not place restrictions on other software that is distributed along with the licensed software, and (j) No provision of the license may be predicated on any individual technology or style of interface.

 4 "Open Source Initiative, Advocacy, the Open Source Case for Business, at http://www.opensource.org/advocacy/case_for_business.html (visited March 30, 2006), The foundation of the business case for open source is high reliability. Open source software is peer-reviewed software," proofed and tested by a whole community of developers. By leveraging a community of open source developers, a software program can be written more quickly and more cheaply – in effect one can outsource some of the work to the open source community, which does not charge for its services.

 5Laura A. Majerus, Court Evaluates Meaning of "Derivative Work" in an Open Source License , at http://library.findlaw.com/2003/Jun/16/132811.html (visited March 29, 2006)

 6 Welte v. Forinet UK Limited, Landgericht Muenchen I, No. 21 0 7240/05, 4/12/05,

 7 Open Source’s Pandora’s Box, at http://www.optimizemag.com/issue/027/law.htm (visited March 29, 2006)

Kevin Gard is Assistant General Counsel of Sun Microsystems, Inc. and practices technology licensing and intellectual property law in Itasca, Illinois.

Jen Salyers is a partner in the firm of Bonnabeau, Salyers, Stites, Doe, Andresen in Minneapolis, Minnesota and con-centrates her practice in the representation of corporations acquiring information technology products and services. The firm’s website address is www.bssda.com.


 
 
DCBA Brief