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.