I am an open source lawyer for Red Hat. One important part of my job is to provide information to other companies, including their in-house counsel, about how Red Hat builds enterprise-class products with a completely open source development model and answering their questions about open source licensing in general. After hearing about Red Hat's success, these conversations often turn to discussions about how their organization can evolve to be more open source-aware and -capable, and lawyers at these meetings regularly ask how they can modify their practices to be more skilled in providing open source counsel to their employees.
In this article and the next, I'll convey what I normally tell in-house counsel about these topics. If you are not in-house counsel and instead work for a law firm supporting clients in the software space, you may also find this information useful. (If you are considering going to law school and becoming an open source lawyer, you should read Luis Villa's excellent article What to know before jumping into a career as an open source lawyer.)
My perspective is based on my personal and possibly unique experience working in various engineering, product management, and lawyer roles. My atypical background means I see the world through a different lens from most lawyers. So, the ideas presented below may not be traditional, but they have served me well in my practice, and I hope they will benefit you.
Connect with open source organizations
There are a multitude of open source organizations that are especially useful to open source lawyers. Many of these organizations have measurable influence over the views and interpretations of open source licenses. Consider getting involved with some of the more prominent organizations, such as the Open Source Initiative (OSI), the Software Freedom Conservancy, the Software Freedom Law Center, the Free Software Foundation, Free Software Foundation Europe, and the Linux Foundation. There are also a number of useful mailing lists, such as OSI's license-discuss and license-review, that are worth monitoring and even participating in.
Participating in these groups and lists will help you understand the myriad and unique issues you may encounter when practicing open source law, including how various terms of the open source license texts are interpreted by the community. There is little case law to guide you, but there are plenty of people happy to help answer questions, and these resources are the best source of guidance. This is perhaps one of the very unique and amazing aspects of practicing open source law—the openness of the development community is equally matched by the openness of the legal community to provide perspective and advice. All you have to do is ask.
Adopt the mindset of a business manager and find a path to yes
Product managers are ultimately held responsible for a product or service from cradle to grave, including enabling that product or service to get to market. Since the bulk of my career has been spent leading product-management organizations, my mind is programmed to find a path, no matter how, to get a viable product or service to market. I encourage any lawyer to adopt this mindset since products and services are the lifeblood of any business.
As such, the approach I have always taken in my legal practice involves issue spotting and advising clients of risk but always having the objective of finding a path to "YES," especially when my analysis impacts product/service development and release. When evaluating legal issues for internal clients, my executive management or I may, at times, view the risk to be too high. In such cases, continue encouraging everyone to work on the problem because, in my experience, solutions do eventually present themselves, often in unexpected ways.
Be sure to tap all your resources, including your software development clients (see below), as they can be an excellent source of creative approaches to solving problems, often using technology to resolve issues. I have found much joy in this method, and my clients seem pleased with this passion and sentiment. I encourage all lawyers to consider this approach.
Sadly, it is always easy to say "no" for self-preservation and to eliminate what may appear to be any risk to the company. I have always found this response untenable. All business transactions have risk. As a counselor, it is your job to understand these risks and present them to your clients so that they may make educated business decisions. Simply saying "no" when any risk is present, without providing any additional context or other paths forward to mitigate risks, does no good for the long-term success of the organization. Companies need to provide products and services to survive, and you should be helping find that path, whenever possible, to YES. You have an ethical responsibility to say "no" in certain situations, of course, but explore and exhaust all reasonable options first.
Build relationships with developers
Building relationships with your software development clients is absolutely critical. Building rapport and trust with developers are two important ways to strengthen these relationships.
Build rapport
Your success as an open source lawyer is most often a direct result of your positive relationships with your software developers. In many cases, your software developers are the direct or indirect recipients of your legal advice, and they will be looking to you for guidance and counsel. Unfortunately, many software developers are suspicious of lawyers and often view lawyers as obstacles to their ability to develop and release software. The best way to overcome this ill will is to build rapport with your clients. How you do that is different for most people, but here are some ideas.
- Show an interest in your clients' work: Be inquisitive about the details of their project, how it works, the underlying programming language, how it connects to other systems, and how it will benefit the company. Some of these answers will be useful in your legal analysis when ascertaining legal risk and ways to mitigate such risk, but more importantly, this builds a solid foundation for an ongoing positive relationship with your client.
- Be clear to your client that you are working to find a path to YES: It is perfectly acceptable to let your client know you are concerned about certain aspects of their project, but follow that up with ideas for mitigating those concerns. Reassure them that it is your job to work with them to find a solution and not to be a roadblock. The effect of this cannot be overstated.
- Participate in an open source project: This is especially true if you have software development experience. Even if you do not have such experience, there are many ways to participate, such as helping with documentation or community outreach. Or request to join their status meetings just to learn more about their work. This will also allow you to provide counsel on-demand and in real time so that the team may course-correct early in the process.
Have trust
Your software developers are very active in their open source communities and are some of the best resources for understanding current issues affecting open source software and development. Just as you connect with legal organizations, like your local bar or national legal organizations to keep current on the latest legal developments, you should also engage with your software development resources for periodic briefings and to gain their counsel on various matters (e.g., how would the community view the use of this license for a project?).
Relationships breed success
Open source law is unique because of its unusual requirements for success, namely, connections to other open source attorneys, open source organizations, and a deep and respectful relationship with clients. Success is a direct function of these relationships.
In part two of this series, I will explore how and why it is important to find a path to "open" and to develop scalable solutions for your organization.
Comments are closed.