Open Source Risk Management in the Enterprise

Updated [18-Jun-2006]: This work was expanded into a presentation and a pair of white papers.  You can find all the refernces in this blog post. As always, all materials available under a creative commons license. 
 

One of our sales team here at Optaros asked me how I would respond to questions from an enterprise customer about legal risk assessment with open source software in general, as well as in the context of the SCO Group and IBM litigation. 

Here was my answer, in case others find it useful:

SCO/IBM is a about copyright misappropriation between two vendors.  SCO claims IBM used SCO property in its contributions to the Linux operating system.  SCO still needs to establish that its property has been used, as well as establishing that it couldn't be used through the contracts in place at the time between the companies. The Canopy Group, the parent company of SCO Group, has a long history of acquiring the technology assets of a failing company and litigating against a vendor.  (They successfully did this to Microsoft and CA.)

When SCO Group sent letters to a very large number of Linux customers threatening to sue them, then started trying to sue Autozone and Daimler-Chrysler, they were attempting to put pressure on IBM to settle.  It has back fired.  Several large vendors (HP, Novell, and Microsoft) all took the opportunity to loudly offer indemnifications against intellectual property lawsuits in relation to their products. HP and Novell did this for their respective Linux offerings and Microsoft did it for their own product portfolio to try and differentiate their commercial offering from a generic "open source" threat.  IBM loudly did NOT offer an indemnification around Linux, saying it wasn't necessary.

In a more general discussion around open source and legal risk to the enterprise, I would suggest that an enterprise evaluate the risk in relation to its risks around other contract areas with respect to software in general:

• A company stands a larger risk of being sued over license counting issues from a commercial software vendor than they do over intellectual property issues (copyright) and open source.  License management and counting users is a notoriously difficult space.  Both vendors and customers can feel they're being cheated.  There's no good general way to manage user license counting across diverse vendors and products. Vendors regularly litigate in these spaces. Some even wield the BSA as a stick and call for audits.  Open source licensing reduces risk here.
• The only lawsuit to date is the SCO vs. IBM suit.  It isn't seminal — it's an aberration based on a particular company's historical behavior. In a multi-billion dollar market place, Linux has been in active deployment for 10 years, MySQL for 5 years, and Apache for 15 years.  This is the only lawsuit in which a customer was threatened and then only as a legal tactic to pressure another vendor. In a very few other cases, inappropriate use of software licensed under the GNU General Public License (GPL) has been at issue between two vendors or between the vendor and the project.   In every case, the vendor has respected the license, and either published their modifications or modified the project code to no longer use the software covered by the GPL.  There have been no product catastrophes or outrageous damages.  No enterprise end customers to my knowledge have ever had a problem.

From a software development perspective, there is concern of late over whether or not your own software development efforts have been somehow "tainted" with "viral" code and would need to be therefore published at large — and concern over what sort of software development tools and practices need to be put in place to prevent such risk.  Ideas around free and open source license compliance tracking have been raised. Again one needs to consider the risks in context.

• A vendor that has a software product distributed in the marketplace needs to be more sensitive to what their license responsibilities mean to their product than an enterprise simply deploying software in-house. 
• Every developer I've known in 25 years of software development understands that copying code without checking the license can lead to consequences that will affect the company's ability to ship its product.  The developers may not be copyright lawyers, but they know to call in project management for a review. This also applies to code samples found in books and developer network portals (e.g. MSDN with its once confusing array of copyright statements), as well as to third party licensed software (e.g. C++ library and framework source code), not just to open source software.  In other words, this is not specific to open source. 
• The requirement that software source code be either published and licensed (or the software withdrawn) under some open source licenses such as the GPL is triggered on distribution of the software.  This is very relevant to a software development company, but not to an enterprise that is deploying the software internally.  Licenses such as the Apache license or BSD license don't require publication of the software source code at all. Even software development companies, however, have demonstrated they can ship products based on free and open source licenses such as the GPL without "risking their businesses", gaining very different benefits that outweigh the risks of publishing the source code.
• I would sooner invest in better software development tools for testing, debugging, and release and configuration management to improve software quality and reduce software maintenance costs than detecting code taint of specific of open source projects (while ignoring developer portal code and published code in journals, books, and magazines, or worse still software that came into the company from a third party that will never be finger printed and identifiable from a tool.)  The risks don't merit the expense in context.
• There are no tools that can feasibly be created that can detect patent taint. 

Here's another way to think about taint and compliance:  when I was vice president, R&D at a software company, the development team was juggling a Microsoft source code license, our own software assets, and every imaginable free and open source license.  If the Microsoft code base was compromised via source code taint from a GPL project, we would be out of business.  We didn't have deep legal pockets to ride out a storm.  Every one would simply be sent home and our investors would look for new investments.  Because we were shipping product on the Microsoft platform, the open source community was very vigilant about possible license abuse. 

My developers cleared any license for use prior to working with the open source code with product management. We checked with our general counsel once a product cycle (and frankly as I recall we explained it to them the first time around).  We kept a simple manual register of licenses that covered the software we used.  When we shipped the product with our own product EULA, we included a file that detailed all the other licenses and what parts of the product they related to, however, it was our EULA that the customer cared about.  We ran a simple scan for copyright notices as part of our product build process to ensure nothing had been inadvertently missed in the manual process.  This was in a very complex product using upwards of 350 tools from the open source world covered by on the order of 25 different free and open source licenses, many of which are not formally registered with the Open Source Initiative (which didn't exist when we started the company).  [srw — You can still find the file in /docs/CPYRIGHT.TXT in Microsoft Services for UNIX V3.5, available here.]

We did not expose all of our source code.  We contributed source code enhancements and bug fixes back in several different communities (e.g. ed/ex, PD KornShell, the GCC compiler suite), as well as publishing our changes for GPL tools (the GCC compiler suite, the RCS version control suite).   

A little education goes a long way here.  It is not as complex as people fear it is with respect to using open source software, and frankly the commercial software world is riskier for the enterprise with respect to litigation.

Comments

[David Ascher]

Nice summary.

[Dan Clayton]

A quick read of your blog makes me wonder why you missed the prime legal questions about newSCO. Did AT&T own any significant copyrights to UNIX when it transferred ownership to Novell or had it already lapsed into public domain? Did Novell transfer whatever copyrights and patents they held for UNIX to Caldera ( oldSCO ) when Caldera purchased some rights to collect licensing fees for UNIX and pass 95 % on to Novell? There does not seem to be a document transferring copyrights which is required by law. Did oldSCO transfer any ownership they might have had to newSCO? These questions need to be answered proving a chain of copyright transfers before newSCO can even begin to address why they would own software that IBM developed. None of their legal claims have any standing until they prove they own copyrights.

[Jack Carroll]

I've followed the SCO Group maneuvers from the beginning. Their behavior leads me to doubt greatly that legal merit has any bearing at all on their decision process. Most of their claims are so transparently flimsy, that I'm firmly convinced that the only purpose of any of their actions is to generate publicity so as to inflate the price of their worthless stock. In other words, their only revenue model is investment fraud. These people are swindlers, pure and simple.

[Frank Haney]

A couple of corrections, one to the article, one to Dan Clayton's comment:

1. SCO is no longer a Canopy company.
2. oldSCO and newSCO. The entity formally known as the Santa Cruz Operation and now known as Tarantella is the original or oldSCO. The entity formally known as Caldera bought some of the assets of the Santa Cruz Operation, changed its name to The SCO Group and is now often known as newSCO.

NB A few years earlier, Novell sold something to the Santa Cruz Operation which amongst other things enabled the SantaCruz Operation to collect Unix licence money on behalf of Novell.

[stephe]

Good point Frank. The SCO Group is no longer owned by the Canopy Group directly. The litigation was started in that light but is carrying on its own course. I've sometimes thought of the Canopy Group actions as sort of a reverse venture capitalist — investing in companies that then syphon money out of the market through litigation rather than building a business with customers forward. Maybe this was Canopy's way of disengaging when it looked like this dog doesn't hunt anymore, similar to the way a VC would move on from an investment that was failing.

[Juergen]

You can tell customers that there's no difference between OpenSource (Linux) and Microsoft and they should read the indemnification by M$! All they do is to say that you have to stop using the software on notice or your indemnification is invalid. Then you are allowed to use it again once they have a replacement (IF).
Great if your company depends on that piece of software!

kjs