Lately, I’ve been receiving, more and more, pleas from developers looking for ways to get around their legal departments when it comes to using open source technology for their company’s app. “The suits don’t get it.”, “My lawyer is paranoid.”, “Our legal team doesn’t want the risk!”, “Do you sell IP protection?” Um no.
Quite frankly, my heart goes out to these poor developers that have to swallow their pride and ask their peers these lame questions. How do you tell a lawyer that he doesn’t know what he’s talking about?
I embarked on a brief journey in hopes of creating an email template for these increasingly frequent requests. I confirmed that, indeed, there is a lot of information out there touting the dangers of open source and countless blogs that are just simply incorrect. I did, however, find a great article by Dennis Kennedy, a tech lawyer based in Missouri, that hit the nail right on the head! Being a non-lawyer type, I ran it by our own tech-savvy attorney and he gave it the thumbs up.
So, without further ado, I give you Dennis Kennedy’s ten tips for dealing with the practicalities of open source technology and my stock answer to all future requests for IP protection:
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.
Read the entire article.
A special thanks to Mr. Kennedy for allowing his tips to be reprinted here.