Open Source Commands Allure

For any new business, controlling costs can be the most important factor in survival, much less success.

This is all the more true in e-commerce, with its razor-thin profit margins and ease of market entry for potential competitors (see, “Avoiding e-Conomic Insanity When Business Rebounds: A Company Declining with the Economy Is Bad Enough ' Don't Let a Rebounding Economy Kill Your Business with a Ricochet,” in the March 2009 edition of e-Commerce Law & Strategy, at www.ljnonline.com/issues/ljn_ecommerce/25_11/news/151816-1.html).

So, then, the prospect of “free” software, through the open source movement, seems like a CFO's dream come true. After all, why shouldn't a firm get a critical asset at no cost?

In other words, why pay a monthly licensing or maintenance fee when something that appears to work well can possibly be had at no cost online?

Free? Well '

Unfortunately, the real world has taught us all that “free” can be very expensive. We're sure there are few among you who haven't seen ads offering something of apparent value for FREE ' with an asterisk. Yet inevitably, “FREE ' with an asterisk” means that there is some cost to get the “free” product.

For example, “free after rebate” means that not only do you have to invest your own time to submit the rebate application (after not having lost the receipt, and collected all the proofs of purchase and other materials required to be submitted), but you must pay for the product and wait ' and wait ' and hope that you get your money back several months later. Other allegedly free products require you to pay a “nominal” shipping and handling charge ' a profit center for many direct-marketing firms.

It is not surprising, therefore, that many consumer protection agencies routinely warn against the risks of so-called “free” offers. (See, www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt008.shtm and www.ftc.gov/opa/2010/04/freecredit.shtm from the Federal Trade Commission (FTC), and www.csoonline.com/article/682496/ftc-targets-free-trial-offers-from-canadian-entrepreneur from the International Data Group (IDG).)

In the same way that it often “costs a lot to go broke” because of the fees and expenses associated with a formal bankruptcy filing, perhaps users of open source software should stop to consider all the costs of getting a critical asset for “free” ' especially because software licenses have been sold, for cash, for many years, despite the ready availability of seemingly adequate “free” open source alternatives.

Similarly, free “home use” versions of popular software are frequently offered to induce firms to license the paid version (e.g., AVG's security products). Some firms routinely rely on such limited products, despite their (typically) limited functionality, lack of vendor support and uncertain scalability to the needs of a growing business, a scalability and functionality that must be available to customers 24/7 ' and don't notice that the license terms prohibit commercial use, as is typical.

(As noted in prior columns, reading a software license can reveal unexpected ' but legally enforceable ' requirements. See, for example, “I SIGNED WHAT?! The Brutish
World of e-Commerce Terms and Conditions ' or, Why Goliath Sometimes Loses,” in the July 2008 edition of e-Commerce Law & Strategy, at www.ljnonline.com/issues/ljn_ecommerce/25_3/news/150654-1.html.)

Must You Pay Twice?

So can ' or should ' e-commerce firms use open source software to build their business and gain competitive advantage? Or does that just invite future problems, such as when growth outstrips the capacity of the product and, paradoxically, makes the choice of “open source” more expensive than traditional software? It comes down to this: Must the user pay for its software twice ' once to build the site with open source, and again to replace it with traditional code as the limitations of open source reveal themselves?

Perhaps it is not surprising that in the world of corporate cost-cutting that began long before today's recession, consideration of open source has been much discussed for business use. (See, e.g., www.acc.com/legalresources/resource.cfm?show=16485. In fact, Mark Radcliffe, the pro bono general counsel of the Open Source Initiative, publishes a blog on these issues at http://lawandlifesiliconvalley.com/blog.)

Even in 2008, a study by the respected Gartner firm (reported on Radcliffe's blog) concluded that: “By 2012, 90% of enterprises will use open source either direct or embedded,” and that “virtually all of our clients use open source even if they are not aware of it” (http://lawandlifesiliconvalley.blogspot.com/2008/04/open-source-as-borg-resistance-is.html).

More recently, in March 2011, a Harvard Business Review article (by a Gartner researcher) opined that “Open Source Software Hits a Strategic Tipping Point,” because “mainstream adopters of IT solutions across a widening array of market segments are rapidly gaining confidence in the use of open source software, with many now stressing its valuable features more than its risks” (http://blogs.hbr.org/cs/2011/03/open_source_software_hits_a_st.html).

Public.Resource.org, a non-profit project to maintain public works on the Internet, has even proposed to use open source to create “Law.gov,” “an open-source authenticated repository of all primary legal materials in the United States” (https://public.resource.org/law.gov).

As a practical matter, therefore, with increasing mainstream business use of open source code (intentionally or not), counsel and their clients must become familiar with the issues associated with the use of open source software, because the typical deal documents ' diligence requests and contractual language ' will have to address open source, just as they would any other mission-critical asset. (For examples of open source representations and warranties in deal documents, see, www.slideshare.net/OpenLogic/open-source-crash-course-open-source-licenses-and-patents-transactions-and-enforcement.) By analogy, consider how environmental law evolved from a niche practice of real estate and corporate lawyers into a huge concern of its own that often dictates the structure, or collapse, of a deal.

Features v. Risks

To try to balance those “valuable” features against the “risks” for e-commerce firms, let's first be clear about our terms, beginning with the fact that the common association of “open source” with “free” is not accurate, beyond the most general understanding. Instead, an “open source” license means that it is free of restrictions (such as those discussed in licensing articles in this publication), rather than free of upfront licensing or acquisition fees. The Open Source Initiative (www.opensource.org) has a multi-part “open source definition” relating to the availability of underlying code for distribution and redistribution.

In the words of Richard Stallman, a “software freedom activist” who is often considered the creator of the concepts underlying open source licensing: “When we call software 'free,' we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes. This is a matter of freedom, not price, so think of 'free speech,' not 'free beer'” (www.gnu.org/philosophy/open-source-misses-the-point.html). (The discussion at this link of the philosophy of open source software, and how it differs from other commonly confused alternatives, is well worth reading, but beyond the scope of this article.)

From the perspective of the e-commerce developer, however, that “freedom” can mean something very different from what it may mean to the principals and others involved in a business using open source for an application used only internally.

In other words, if what differentiates your site and business from your competition is the functionality of your site, and you developed it using open source software subject to a typical open source license, then you may not be able (in theory, at least) to restrict others from using it in the same way that you could protect a patented application, or (more commonly) a trade secret. Even worse is that potentially, anyone can have access to the same code, and develop from or with it in the same way you did.

When we first started to study and learn programming languages, back in the dark ages of the mid-70s, everything was operating-system specific. Today's operating and programming environments are mostly PC-based, with almost every business operating on both local area and wide area networks. The Internet is a requirement for all business operations. Code is everywhere, and is available for almost every conceivable common routine, and some not-so common routines as well. Software is, in some circles, becoming less and less proprietary, almost to the point of, well, completely open ' or open source software. Open source software is a relatively new and exciting area for programmers and developers. Need a routine for doing something simple like a sort, or something complex like signal processing? Don't write it, download it. It's easy, it's fast ' and it's free.

But the convenience of getting “easy, fast and free” code can make you forget that open source software is licensed, not owned. The user must conform to the license terms, even if the terms require that the product's code be made available, in whole or in part, in ways that typical profit-seeking firms would not offer to customers. For example, consider the following parts of the Open Source definition that a typical for-profit firm could find troubling (the particular license terms will depend on which open source license one relies on):

• 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.
• 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.
• The program must include source code, and must allow distribution in source code as well as compiled form. ' Deliberately obfuscated source code is not allowed.

Strings Attached

But open source software has strings attached, and by strings, we mean a license. While the license may give you the right to use the code, if you are going to use or distribute code that includes any open source software, you need to be aware of the rights and obligations imposed by the license attached to the code. As there is no one common license, the potential legal pitfalls, restrictions and requirements for each piece of open source code that you use may be different. And trust me: If you are operating in a Linux or Unix environment, you probably are using open source software. In fact, the Android mobile operating system is an open source software project, so it is likely that you are using open source software on your mobile phone.

That is not to say that you can't protect your business's IP, just as you could with traditional, licensed software, you just have to do so knowing that the code underlying your site is required to be made available.

You can still use traditional protection techniques, such as confidentiality agreements, with employees and others who must have access to that information (see, “Keeping e-Secrets ' Knowledge Protection for the
Online Firm,” in the September 2007 edition of e-Commerce Law & Strategy, at www.ljnonline.com/issues/ljn_ecommerce/24_5/news/149201-1.html).

In addition, as in any business, barriers to competition work best when they are inherent in the business, rather than imposed solely by a legal document ' a cheaper manufacturing technology, or more effective marketing scheme, will always outperform an expensive lawsuit to defeat your competition. (A broad discussion of the concerns of using open source in a corporate setting, and the burdens of managing assets subject to open source licenses, may be found at www.slideshare.net/OpenLogic/open-source-crash-course-open-source-licenses-and-patents-transactions-and-enforcement.)

Free, But Restricted

The potential for inconsistent licensing ' open source may be free, but it is not free of restrictions ' can also create technical headaches, especially in firms that integrate systems from multiple vendors that don't always work smoothly together.

While your firm may have a support agreement with vendors of paid software, the support firm may not be obligated to provide any assistance with issues relating to any other vendor's products (much less open source software). For instance, warranties in software and other technology products may have only very limited benefit (e.g., for premature hardware failure), but you don't even get that level of comfort when using open source software.

To be fair, and within the open source ethos, you also get a world, literally, of other users who may have already found or created a solution to your problem, but use of such a resource would not be a typical corporate way of problem-solving. (For an example of the legal and technical complexities of complying with multiple open source licenses, see the discussion of development of phones using Android components, at www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202495469387.)

More Questions

The legal questions raised by open source licensing extend beyond operations, to corporate level transactions.

Typical warranties, for example, required when a company is bought, call for disclosures about what types of software are present and the licenses to which it is subject. While those warranties would not likely block a deal, the seller must have an internal management system to be able to give the requested disclosures, without undue expense to locate that information.

Similarly, a well-advised buyer will ask about the “source of the source” (i.e., where you got your code, and what rights and legal obligations may come with it). The buyer must confirm your ownership of the software rights you are selling, and screen for potential claims of infringement or competing ownership claims (e.g., claims of a code writer or developer who did not have a work-made-for-hire agreement).

Also, if your software and systems have been built up over time, but you cannot clearly trace the lineage of what the buyer will acquire, the buyer could look on that situation negatively, and cut the price, or demand greater indemnities and holdbacks. Steve Jobs, commenting on a “real world” open source dispute between patented and open source standards in video codecs, noted: “(J)ust because something is open-source, it doesn't mean or guarantee that it doesn't infringe on others patents” (http://online.wsj.com/article/SB10001424052748703752404576178833590548792.html).

Of course, open source users do not have anyone to sue for indemnification if the code you use turns out to have infringed the rights of a third party. Even though you may never have had a claim relating to a piece of open source code, a buyer who knows that there is an uncertainty about the assets to be acquired will inevitably reduce the value of those assets (and your selling price), even if the buyer may not really expect any claims either. Modification of any of the open source code, such as to incorporate it into your operations or products, will also create potential complications that must be addressed ' again, an issue not insurmountable, but a question that should be discussed. In short, even if open source software can be freely used, a buyer must know the license terms by which it will be governed.

The Gartner researcher mentioned earlier who wrote in the Harvard Business Review also warned about the absence of open source management policies in corporate settings, and the implicit cost of the overhead expense needed to manage this “free” asset:

Even as our survey painted a rosy picture of the future of enterprise use of open source software, it also surfaced a concern. Most organizations, it revealed, have not established a policy framework to guide decision-making on the use of open source software. A proper framework would outline types of licenses acceptable to the organization, guidelines pertaining to intellectual property, regulations governing contributions to external projects, and an approved vendor/project list. ' Organizations are fast getting over their qualms about open source software. Now it's time for them to develop and implement formal policies, and start managing open source software like the strategic resource that it is. (http://blogs.hbr.org/cs/2011/03/open_source_software_hits_a_st.html.)

Practical Risks

Now that you've decided to use open source software, what's the worst that could happen? In brief, if you develop code, and in that code you use open source software, all the code you create may become open source software, whether or not you expected to create open source software. Here's how that may happen, and some ideas to prevent that from happening (which requires a bit of copyright law background).

Under U.S. copyright law, the owner of the copyright in the material has the exclusive right to exploit and use the copyrighted material. Part of that exclusive right to use and exploit the copyrighted material includes the exclusive right to create “derivative works.” A derivative work is an expansion of, change to, or amendment of the original copyrighted work that retains the original intent of the author and the essence of the original copyrighted work.

So how does this apply to software?

Let's assume for a moment that you have developed proprietary software, whether for internal use for your business, or to sell as a product. And let's assume that you have used some open source code as part of that proprietary software.

Let's also assume that the license that comes with that open source software that you have embedded in your proprietary software says that any derivative work created from that open source software must also be distributed as open source. If your proprietary software is a derivative work of the open source software, your proprietary software may no longer be proprietary. It may now be open source as well.

Now, how do you prevent this from occurring? There are some technical processes that may be employed to prevent your proprietary code from becoming open source if you use open source in your code. For example, do not compile the open source with the proprietary code, or use dynamic linked libraries or system calls. Another suggestion is to carefully research the license that comes with the open source software that you are using. If it requires that all derivative works become open source, don't use the code.

We also recommend that, if you do not know if you are using open source, do an audit. If you do not have the expertise to do an audit, there are a number of reputable companies that can find open source in your proprietary code (e.g., www.openlogic.com, www.blackducksoftware.com, and www.palamida.com) and provide a complete report that includes the licensing requirements of the found code. Lastly, your organization should have strictly enforced policies on the use of open source in any project.

Conclusion

All these points lead to a simple conclusion: Don't choose open source if your sole motivation is cost savings. The fact that it is “free” masks the many other costs that a business enterprise must incur to use open source software that may not be very different from using a comparable product under a license that requires paying a fee. Open source can give you flexibility to develop e-commerce tools that can help you differentiate your site from others and, perhaps more important, do so more quickly than competitors working with proprietary products. Open source may even help you develop less expensive strategies than those you could use without it.

But if saving costs alone is your motivation for considering open source, then you may find that the price of “free” can be quite high, in terms of legal needs and business management burdens; the absence of a commercial vendor's help desk means that someone, whether on your staff or at an outside vendor, will have to devote time ' and incur cost ' to resolving issues as they arise.

Working through those issues can just take time away from the real challenges of e-commerce: marketing, developing and retaining customers for your online firm.

For any new business, controlling costs can be the most important factor in survival, much less success.

This is all the more true in e-commerce, with its razor-thin profit margins and ease of market entry for potential competitors (see, “Avoiding e-Conomic Insanity When Business Rebounds: A Company Declining with the Economy Is Bad Enough ' Don't Let a Rebounding Economy Kill Your Business with a Ricochet,” in the March 2009 edition of e-Commerce Law & Strategy, at www.ljnonline.com/issues/ljn_ecommerce/25_11/news/151816-1.html).

So, then, the prospect of “free” software, through the open source movement, seems like a CFO's dream come true. After all, why shouldn't a firm get a critical asset at no cost?

In other words, why pay a monthly licensing or maintenance fee when something that appears to work well can possibly be had at no cost online?

Free? Well '

Unfortunately, the real world has taught us all that “free” can be very expensive. We're sure there are few among you who haven't seen ads offering something of apparent value for FREE ' with an asterisk. Yet inevitably, “FREE ' with an asterisk” means that there is some cost to get the “free” product.

For example, “free after rebate” means that not only do you have to invest your own time to submit the rebate application (after not having lost the receipt, and collected all the proofs of purchase and other materials required to be submitted), but you must pay for the product and wait ' and wait ' and hope that you get your money back several months later. Other allegedly free products require you to pay a “nominal” shipping and handling charge ' a profit center for many direct-marketing firms.

It is not surprising, therefore, that many consumer protection agencies routinely warn against the risks of so-called “free” offers. (See, www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt008.shtm and www.ftc.gov/opa/2010/04/freecredit.shtm from the Federal Trade Commission (FTC), and www.csoonline.com/article/682496/ftc-targets-free-trial-offers-from-canadian-entrepreneur from the International Data Group (IDG).)

In the same way that it often “costs a lot to go broke” because of the fees and expenses associated with a formal bankruptcy filing, perhaps users of open source software should stop to consider all the costs of getting a critical asset for “free” ' especially because software licenses have been sold, for cash, for many years, despite the ready availability of seemingly adequate “free” open source alternatives.

Similarly, free “home use” versions of popular software are frequently offered to induce firms to license the paid version (e.g., AVG's security products). Some firms routinely rely on such limited products, despite their (typically) limited functionality, lack of vendor support and uncertain scalability to the needs of a growing business, a scalability and functionality that must be available to customers 24/7 ' and don't notice that the license terms prohibit commercial use, as is typical.

(As noted in prior columns, reading a software license can reveal unexpected ' but legally enforceable ' requirements. See, for example, “I SIGNED WHAT?! The Brutish
World of e-Commerce Terms and Conditions ' or, Why Goliath Sometimes Loses,” in the July 2008 edition of e-Commerce Law & Strategy, at www.ljnonline.com/issues/ljn_ecommerce/25_3/news/150654-1.html.)

Must You Pay Twice?

So can ' or should ' e-commerce firms use open source software to build their business and gain competitive advantage? Or does that just invite future problems, such as when growth outstrips the capacity of the product and, paradoxically, makes the choice of “open source” more expensive than traditional software? It comes down to this: Must the user pay for its software twice ' once to build the site with open source, and again to replace it with traditional code as the limitations of open source reveal themselves?

Perhaps it is not surprising that in the world of corporate cost-cutting that began long before today's recession, consideration of open source has been much discussed for business use. (See, e.g., www.acc.com/legalresources/resource.cfm?show=16485. In fact, Mark Radcliffe, the pro bono general counsel of the Open Source Initiative, publishes a blog on these issues at http://lawandlifesiliconvalley.com/blog.)

Even in 2008, a study by the respected Gartner firm (reported on Radcliffe's blog) concluded that: “By 2012, 90% of enterprises will use open source either direct or embedded,” and that “virtually all of our clients use open source even if they are not aware of it” (http://lawandlifesiliconvalley.blogspot.com/2008/04/open-source-as-borg-resistance-is.html).

More recently, in March 2011, a Harvard Business Review article (by a Gartner researcher) opined that “Open Source Software Hits a Strategic Tipping Point,” because “mainstream adopters of IT solutions across a widening array of market segments are rapidly gaining confidence in the use of open source software, with many now stressing its valuable features more than its risks” (http://blogs.hbr.org/cs/2011/03/open_source_software_hits_a_st.html).

Public.Resource.org, a non-profit project to maintain public works on the Internet, has even proposed to use open source to create “Law.gov,” “an open-source authenticated repository of all primary legal materials in the United States” (https://public.resource.org/law.gov).

As a practical matter, therefore, with increasing mainstream business use of open source code (intentionally or not), counsel and their clients must become familiar with the issues associated with the use of open source software, because the typical deal documents ' diligence requests and contractual language ' will have to address open source, just as they would any other mission-critical asset. (For examples of open source representations and warranties in deal documents, see, www.slideshare.net/OpenLogic/open-source-crash-course-open-source-licenses-and-patents-transactions-and-enforcement.) By analogy, consider how environmental law evolved from a niche practice of real estate and corporate lawyers into a huge concern of its own that often dictates the structure, or collapse, of a deal.

Features v. Risks

To try to balance those “valuable” features against the “risks” for e-commerce firms, let's first be clear about our terms, beginning with the fact that the common association of “open source” with “free” is not accurate, beyond the most general understanding. Instead, an “open source” license means that it is free of restrictions (such as those discussed in licensing articles in this publication), rather than free of upfront licensing or acquisition fees. The Open Source Initiative (www.opensource.org) has a multi-part “open source definition” relating to the availability of underlying code for distribution and redistribution.

In the words of Richard Stallman, a “software freedom activist” who is often considered the creator of the concepts underlying open source licensing: “When we call software 'free,' we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes. This is a matter of freedom, not price, so think of 'free speech,' not 'free beer'” (www.gnu.org/philosophy/open-source-misses-the-point.html). (The discussion at this link of the philosophy of open source software, and how it differs from other commonly confused alternatives, is well worth reading, but beyond the scope of this article.)

From the perspective of the e-commerce developer, however, that “freedom” can mean something very different from what it may mean to the principals and others involved in a business using open source for an application used only internally.

In other words, if what differentiates your site and business from your competition is the functionality of your site, and you developed it using open source software subject to a typical open source license, then you may not be able (in theory, at least) to restrict others from using it in the same way that you could protect a patented application, or (more commonly) a trade secret. Even worse is that potentially, anyone can have access to the same code, and develop from or with it in the same way you did.

When we first started to study and learn programming languages, back in the dark ages of the mid-70s, everything was operating-system specific. Today's operating and programming environments are mostly PC-based, with almost every business operating on both local area and wide area networks. The Internet is a requirement for all business operations. Code is everywhere, and is available for almost every conceivable common routine, and some not-so common routines as well. Software is, in some circles, becoming less and less proprietary, almost to the point of, well, completely open ' or open source software. Open source software is a relatively new and exciting area for programmers and developers. Need a routine for doing something simple like a sort, or something complex like signal processing? Don't write it, download it. It's easy, it's fast ' and it's free.

But the convenience of getting “easy, fast and free” code can make you forget that open source software is licensed, not owned. The user must conform to the license terms, even if the terms require that the product's code be made available, in whole or in part, in ways that typical profit-seeking firms would not offer to customers. For example, consider the following parts of the Open Source definition that a typical for-profit firm could find troubling (the particular license terms will depend on which open source license one relies on):

• 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.
• 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.
• The program must include source code, and must allow distribution in source code as well as compiled form. ' Deliberately obfuscated source code is not allowed.

Strings Attached

But open source software has strings attached, and by strings, we mean a license. While the license may give you the right to use the code, if you are going to use or distribute code that includes any open source software, you need to be aware of the rights and obligations imposed by the license attached to the code. As there is no one common license, the potential legal pitfalls, restrictions and requirements for each piece of open source code that you use may be different. And trust me: If you are operating in a Linux or Unix environment, you probably are using open source software. In fact, the Android mobile operating system is an open source software project, so it is likely that you are using open source software on your mobile phone.

That is not to say that you can't protect your business's IP, just as you could with traditional, licensed software, you just have to do so knowing that the code underlying your site is required to be made available.

You can still use traditional protection techniques, such as confidentiality agreements, with employees and others who must have access to that information (see, “Keeping e-Secrets ' Knowledge Protection for the
Online Firm,” in the September 2007 edition of e-Commerce Law & Strategy, at www.ljnonline.com/issues/ljn_ecommerce/24_5/news/149201-1.html).

In addition, as in any business, barriers to competition work best when they are inherent in the business, rather than imposed solely by a legal document ' a cheaper manufacturing technology, or more effective marketing scheme, will always outperform an expensive lawsuit to defeat your competition. (A broad discussion of the concerns of using open source in a corporate setting, and the burdens of managing assets subject to open source licenses, may be found at www.slideshare.net/OpenLogic/open-source-crash-course-open-source-licenses-and-patents-transactions-and-enforcement.)

Free, But Restricted

The potential for inconsistent licensing ' open source may be free, but it is not free of restrictions ' can also create technical headaches, especially in firms that integrate systems from multiple vendors that don't always work smoothly together.

While your firm may have a support agreement with vendors of paid software, the support firm may not be obligated to provide any assistance with issues relating to any other vendor's products (much less open source software). For instance, warranties in software and other technology products may have only very limited benefit (e.g., for premature hardware failure), but you don't even get that level of comfort when using open source software.

To be fair, and within the open source ethos, you also get a world, literally, of other users who may have already found or created a solution to your problem, but use of such a resource would not be a typical corporate way of problem-solving. (For an example of the legal and technical complexities of complying with multiple open source licenses, see the discussion of development of phones using Android components, at www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202495469387.)

More Questions

The legal questions raised by open source licensing extend beyond operations, to corporate level transactions.

Typical warranties, for example, required when a company is bought, call for disclosures about what types of software are present and the licenses to which it is subject. While those warranties would not likely block a deal, the seller must have an internal management system to be able to give the requested disclosures, without undue expense to locate that information.

Similarly, a well-advised buyer will ask about the “source of the source” (i.e., where you got your code, and what rights and legal obligations may come with it). The buyer must confirm your ownership of the software rights you are selling, and screen for potential claims of infringement or competing ownership claims (e.g., claims of a code writer or developer who did not have a work-made-for-hire agreement).

Also, if your software and systems have been built up over time, but you cannot clearly trace the lineage of what the buyer will acquire, the buyer could look on that situation negatively, and cut the price, or demand greater indemnities and holdbacks. Steve Jobs, commenting on a “real world” open source dispute between patented and open source standards in video codecs, noted: “(J)ust because something is open-source, it doesn't mean or guarantee that it doesn't infringe on others patents” (http://online.wsj.com/article/SB10001424052748703752404576178833590548792.html).

Of course, open source users do not have anyone to sue for indemnification if the code you use turns out to have infringed the rights of a third party. Even though you may never have had a claim relating to a piece of open source code, a buyer who knows that there is an uncertainty about the assets to be acquired will inevitably reduce the value of those assets (and your selling price), even if the buyer may not really expect any claims either. Modification of any of the open source code, such as to incorporate it into your operations or products, will also create potential complications that must be addressed ' again, an issue not insurmountable, but a question that should be discussed. In short, even if open source software can be freely used, a buyer must know the license terms by which it will be governed.

The Gartner researcher mentioned earlier who wrote in the Harvard Business Review also warned about the absence of open source management policies in corporate settings, and the implicit cost of the overhead expense needed to manage this “free” asset:

Even as our survey painted a rosy picture of the future of enterprise use of open source software, it also surfaced a concern. Most organizations, it revealed, have not established a policy framework to guide decision-making on the use of open source software. A proper framework would outline types of licenses acceptable to the organization, guidelines pertaining to intellectual property, regulations governing contributions to external projects, and an approved vendor/project list. ' Organizations are fast getting over their qualms about open source software. Now it's time for them to develop and implement formal policies, and start managing open source software like the strategic resource that it is. (http://blogs.hbr.org/cs/2011/03/open_source_software_hits_a_st.html.)

Practical Risks

Now that you've decided to use open source software, what's the worst that could happen? In brief, if you develop code, and in that code you use open source software, all the code you create may become open source software, whether or not you expected to create open source software. Here's how that may happen, and some ideas to prevent that from happening (which requires a bit of copyright law background).

Under U.S. copyright law, the owner of the copyright in the material has the exclusive right to exploit and use the copyrighted material. Part of that exclusive right to use and exploit the copyrighted material includes the exclusive right to create “derivative works.” A derivative work is an expansion of, change to, or amendment of the original copyrighted work that retains the original intent of the author and the essence of the original copyrighted work.

So how does this apply to software?

Let's assume for a moment that you have developed proprietary software, whether for internal use for your business, or to sell as a product. And let's assume that you have used some open source code as part of that proprietary software.

Let's also assume that the license that comes with that open source software that you have embedded in your proprietary software says that any derivative work created from that open source software must also be distributed as open source. If your proprietary software is a derivative work of the open source software, your proprietary software may no longer be proprietary. It may now be open source as well.

Now, how do you prevent this from occurring? There are some technical processes that may be employed to prevent your proprietary code from becoming open source if you use open source in your code. For example, do not compile the open source with the proprietary code, or use dynamic linked libraries or system calls. Another suggestion is to carefully research the license that comes with the open source software that you are using. If it requires that all derivative works become open source, don't use the code.

We also recommend that, if you do not know if you are using open source, do an audit. If you do not have the expertise to do an audit, there are a number of reputable companies that can find open source in your proprietary code (e.g., www.openlogic.com, www.blackducksoftware.com, and www.palamida.com) and provide a complete report that includes the licensing requirements of the found code. Lastly, your organization should have strictly enforced policies on the use of open source in any project.

Conclusion

All these points lead to a simple conclusion: Don't choose open source if your sole motivation is cost savings. The fact that it is “free” masks the many other costs that a business enterprise must incur to use open source software that may not be very different from using a comparable product under a license that requires paying a fee. Open source can give you flexibility to develop e-commerce tools that can help you differentiate your site from others and, perhaps more important, do so more quickly than competitors working with proprietary products. Open source may even help you develop less expensive strategies than those you could use without it.

But if saving costs alone is your motivation for considering open source, then you may find that the price of “free” can be quite high, in terms of legal needs and business management burdens; the absence of a commercial vendor's help desk means that someone, whether on your staff or at an outside vendor, will have to devote time ' and incur cost ' to resolving issues as they arise.

Working through those issues can just take time away from the real challenges of e-commerce: marketing, developing and retaining customers for your online firm.