Dennis Kennedy is a well-known legal technology expert, technology lawyer and blogger. His blog and his web page are highly-regarded resources on technology law and legal technology topics. He is member of the ABA Law Practice Management Section’s Council and Webzine Board.
Open Source software has been called the software that runs the Internet – from the Apache web server to the Mozilla browser and from the Linux operating system to the invisible inner workings of the Internet. Open Source refers not only to software programs and the unique licenses that govern them, but also to a philosophy and what some might call a movement.
The Open Source licenses represent a very different approach to licensing than most businesses, and their lawyers and legal departments, have become accustomed to in the commercial software setting. Research on the Open Source licenses will often turn up conflicting interpretations, misinformation, philosophical arguments and diametrically opposed points of view. This result should not surprise you, especially if you have researched the commentary on the changing Microsoft software license policies where you will see much of the same. There is good reason, in both cases. Important issues are at stake and a casual approach can result in significant consequences.
At the same time, there are important business benefits that Open Source programs bring to the table, not the least of which are potentially substantial cost savings and the access to and right to use the source code of the software.
There is a tendency, especially among lawyers, to use legal risks as a way to say “no” to innovation, new approaches and much of anything out of the ordinary. However, there are legal risks in all things and there are business risks in staying with only the most standard and conservative approaches. The focus should be on assessing the legal risks on the basis of informed judgments and taking reasonable and appropriate steps to manage legal risks in way that makes sense in the context of your business.
The best starting place, of course, is from a position of knowledge based on good information and an understanding of best practices. Too often, however, the starting point comes from unfounded beliefs, limited anecdotal evidence and an unwillingness to do the work required to achieve a solid base of knowledge. The potential business value of Open Source software is simply too great to tolerate a “head in the sand” approach. In addition, you may well find the presence of Open Source software in your business already, without policies in place or in violation of existing policies.
In today’s business world, software plays such a vital role that a cavalier approach to software license management of all kinds of software is both ill-advised and dangerous. In addition to the obvious risks of software piracy and infringement issues, poor license management often leads to duplication, unnecessary expenses, poor strategic decisions, lock-in with old software, inconsistent negotiation approaches and a host of other problems.
If you already have a good license management approach, Open Source software will fit into your system. If you do not have a good approach, your consideration of Open Source software should be a driver toward adopting or improving license management practices. In either event, Open Source software must be discussed at a high-level, with conclusions drawn and policies and procedures implemented. This approach is especially important if you are planning to develop software or contract with third parties to develop software under an Open Source model.
The following ten tips are intended to help you deal with some of the big legal and practical issues. They are, of course, not intended to cover all issues, but they will give you a good checklist to help guide your discussion and make good decisions.
1. Understand the Different Approaches That the Open Source Licenses Take . It is important not to think about the Open Source licenses in monolithic terms. I divide the Open Source licenses into four families: GPL, BSD, Netscape/Corporate, and Custom. That’s not an “official” taxonomy, but I have found it to be a useful way to think about the various licenses and make it easier to analyze the relevant issues. Different licenses can have very different consequences. It also makes sense that everyone, including your lawyer, understands the technology, business and legal aspects of the decision.
2. Pay Special Attention to the General Public License . The General Public License represents a unique approach to software licensing and is the source of the notion of “copyleft.” Many other Open Source licenses do not have the same terms. Most of the heated discussion and controversy you will hear about Open Source involves the General Public License. If you choose only one thing to have policies about and require special review of, it should be the General Public License. In my opinion, if you do not understand the GPL, you should be nothing more than a simple user of GPL software.
3. Remember the Source Code . In simplest terms, the biggest difference between Open Source software and commercial software relates to the source code of the program. In nearly every commercial software license, you receive only the object code of the program – the machine-readable executable version of the program. You do not get the source code – the “programmer’s version” – and you are likely to be restricted from even trying to produce or reverse-engineer the source code. In Open Source programs, you are entitled to the source code and can view it, fix it, modify it and improve it.
4. Make Reasonable Comparison with Commercial Software . It’s easy to find frantic concerns about Open Source software over reasons that apply just as easily to commercial software. In 2004, the threat of software patents to Open Source has been widely discussed. At the same time, we’ve seen Sun lose a patent infringement case involving its Java programming language to Kodak, with a settlement of $90 million dollars. Eolas won a patent infringement judgment against Microsoft. Is your comfort level, when you really think about, any better when you consider whether commercial software vendors can prove they own every bit of the code of their programs than it is for Open Source programs? Many of the same questions about contract enforceability of the Open Source licenses apply to all software licensed on a clickwrap or “clickthrough” basis. Analyze Open Source licenses in the same way you analyze commercial software licenses.
5. Think in Terms of Choosing, Rather Than Negotiating, Open Source Licenses . In a certain sense, Open Source licenses just “are.” They are a classic example of the clickwrap license agreement. You take it or you leave it. As a practical matter, there may be no one to negotiate with. The community development model also drives people toward the common standard licenses. Even if you are a developer, you will find few incentives to create your own custom Open Source license. As frustrating as it can be to lawyers, the best approach is to evaluate the available choices and weigh the consequences, not to think in terms of ways to tinker with or improve the terms of agreements. The focus becomes legal risk management and valuating legal risk in the context of business decisions.
6. Do Not Confuse Open Source with Public Domain . Make no mistake – Open Source software is real intellectual property that is governed by a real license that puts limits on your rights and imposes certain obligations. The obligations may not be all that onerous in comparison to commercial licenses, but they do exist and you ignore them at your peril.
7. Inventory and Assess What You May Already Be Using . Be aware that many standard programming tools are Open Source programs. There are many stories of programmers and IT staff “smuggling” in Open Source programs that they prefer to work with or selling unsuspecting management on the basis of cost savings. You may find that both internal IT staff and third party contractors are using or have used Open Source code, tools or programs without your knowledge. You need to know what you have before you can determine what issues to address and how. It has become very important for both business decision-makers and lawyers to have a good understanding of the technology issues, including what the software does and the alternatives available. Many companies are moving toward Open Source because IT staff can paint a rosy picture on security issues to justify a move to programs they like or want to try. It is important not to take those arguments at face value and at least be able to ask the right questions.
8. Open Source Use Requires Open Source Training . There are many myths and misconceptions about Open Source programs and Open Source licenses. Many programmers incorrectly believe that Open Source code and tools may be freely incorporated into their work. Knowing the right questions to ask is half the battle, but IT staff, contract negotiators and legal personnel, including outside lawyers, must be trained on the legal issues involved with Open Source as well as on the policies and procedures that you decide to take.
9. Reasonable Policies and Procedures Are Not Optional . Many business people believe that if you give a lawyer a look at a business process and he or she will find the need for a written policy. In fairness, there are regulatory and other requirements that may dictate the need for a policy, but, in other cases, policies and procedures are good tools for legal risk management. Often existing policies and procedures can be revised to cover Open Source issues. With questions about security in Microsoft products, the business prospects of software companies and the evolution of subscription, on-demand and other models, there is no question that Open Source software will be an option in many software decisions. A ban on Open Source software will probably be as impractical and unwise as an “anything goes” or “Open Source only” policy. A reasonable, evolving set of policies and procedures crafted to fit the business needs and corporate risk comfort level of your company will invariably be the best approach to take.
10. Treat Open Source Policy as a Team Game . It has become very clear in the last few years that IT policy should not be made in a vacuum. Consider the privacy example. Companies that left privacy policies to the IT department or the legal department quickly found that “standard language” had enormous implications for the marketing department, executives, sales staffs and others. Nothing turned out to be simple or standard until all constituents got involved and worked through the ramifications. Similarly, Open Source usage, especially if development projects are contemplated, creates a wide range of legal and business issues that should not be handled in isolation. Theory has to meet practice to get the best results. If the lawyer only looks at the legal issues and the CIO looks only at the IT issues, you increase the likelihood of finger-pointing when an unexpected, but quite predictable, bad result occurs. No one, especially me, likes the idea of yet another committee meeting, but Open Source is a good example where time and effort spent on the front-end will pay off substantially over the alternative of cleaning up potentially messy and expensive situations in which you may one day find yourself.
Conclusion
Don’t be an Open Source ostrich. Open Source software is not likely to go away nor are you likely to avoid it. As always, “be prepared” is the best motto. Addressing this area from a reasonable knowledge base, with your eyes wide open, only makes good sense in today’s business environment. These ten tips will help you get your Open Source house in order and pave the way for effective and wise use of Open Source software with your legal risks kept within your level of comfort.