Email this article 
Back to Volume 1, Issue 1 table of contents
Platform: Collaboration among counsel
by Karen F. Copenhaver.a
(a) Partner, Choate Hall & Stewart LLP
Abstract
How do we advance the development of sound legal constructs for FOSS without waiting for the results of litigation? Through the same sorts of collaborative development models that brought us open source software. But, because there are legitimate concerns that cause lawyers to hesitate before jumping in to a discussion thread, the development of private places for conversations among lawyers is a positive development that will result in benefits for the entire community.
Keywords
Law; information technology; Free and Open Source Software; Lawyers; Ethics; FOSSBazaar; FUD; Patents; Copyrights; GPL; derivative work; intellectual property; compliance; jurisdictions
Celebrating the Formation of a Community of Lawyers for the Advancement of Understanding of Free and Open Source Licensing and Business Models
It is unfortunate that so many people are first introduced to the concept of open source software and open, collaborative development models through the lens of licence agreements and legal concerns. The benefits of community development of key industry infrastructure loom so much larger and are so much more important than what should be a side bar discussion about how we build the right legal models to support these efforts. Nevertheless, lawyers have been given a very prominent place in the conversation and as a result, for many free and open source developers, lawyer jokes are no joke. There is a special place reserved in their hearts for their most profound disappointments that is dedicated to lawyers.
Why are open source licences so challenging for lawyers?
Why don’t lawyers get it? There is actually a long list of reasons why open source software licences present challenges for lawyers. And when we consider these challenges, it becomes clear why the lawyer’s network promoted by FSFE has been so warmly embraced by so many lawyers around the globe.
Intellectual Property Law
All matters relating to intellectual property are challenging because there is a long history of underlying public policy and evolving statutes, case law and industry practices that must be considered to put any IP issue into context. It is not uncommon for current industry practices to be analysed using legal authorities that are decades if not centuries old – sometimes with surprising results. New applications of intellectual property rights are always subject to debate until a rich body of case law or other rulings is developed that provides both clarity and finality on issues of first impression. Of course, free and open source licences are often called “copyleft” licences precisely because these licences use copyright concepts for revolutionary purposes which challenge the efficacy of these historical precedents. Lawyers who litigate for their living love the use of “old wine in new bottles” as fodder for disputes that have good arguments on both sides and that have sufficient importance to justify the cost of litigating the claims all the way through to the issuance of a judge’s decision on the merits. But lawyers who are charged with giving timely advice to decision makers are less enthusiastic about the benefits of future court room dramas.
Edge Cases
There are very few areas of the law where the boundaries are absolutely clear and firmly established. The law develops through incremental decisions which over time fix and move the boundary time and time again. With open source, however, we have spent many years in grueling arguments over imponderable questions on the meaning of edge cases even though there are many clear cases in the centre that would be more useful teaching tools. Although such lively debates are interesting, they have their downside. This constant bickering contributes to a common impression that these licences are too dangerous and too complex for commercial adoption.
Why do lawyers do this? Well, for one, it is in our code of ethics to push the limits of the law as far as it can go in order to make the best argument for our client. Thus lawyers naturally push the edges of the envelope. Second, it is the way we are taught in law school. Law students are grilled with questions until they reach the limit where the proposition they are arguing is no longer true or no longer works. This is the way lawyers make points and undermine opposing arguments in an adversarial process. Lawyers naturally spend a lot of time arguing edge cases. And, third, the edge cases are intellectually challenging and fun to think about!
But there are other reasons to dwell on the edges cases that are more specific to open source. Because copyleft open source licences often want to extend the reciprocal obligations as far as intellectual property rights can go, the licences drive the analysis to the edge cases. And questions about open source licences are often posed in a context in which the possible reach of the licence is the question – even if no one has ever asserted a claim that the licence should extend that far. The question prior to adoption is often: “How far under any possible interpretation of the licence could someone argue that the licence’s obligations extend?” Even if the answer to 99% of the possible realistic scenarios is the subject of a fairly clear consensus, the analysis is still going to focus on the 1% which remains unclear until we have more litigation and more rulings that provide a better basis for analysis.
The Law Relating to the Software Industry
It is not just the complexity of intellectual property law that lends such uncertainty to the analysis of open source licences. There are many other legal issues relating to the non-open source software industry that are unsettled. Two decades after the industry adopted “shrinkwrap” licensing practices, courts were only beginning to address actual trade practices. The questions about whether an open source licence should be analysed as a contract or as a licence arise because of the lack of certainty around the requirements of contract formation that has plagued the industry for decades (and continues to be argued in many jurisdictions today.)
Legal Analysis versus Community Consensus
In a FOSSBazaar meeting we discussed the two step process through which most companies move toward embracing the use of open source software within their organizations. Many companies cross the first threshold with a rude awakening. One day they think their operations are open source free. They have little or no understanding of the business benefits of open source and are happy to be in a position to be able to avoid the entire discussion. The next day they realize that they are using open source, lots of it. With this discovery they enter into a period in which open source software is purely a problem to manage. During this phase, the focus is on the role of lawyers as the front-line of defence and risk avoidance. And these lawyers tend to focus on a strict legal analysis of the relevant documents based on how a judge in a court of law would interpret the licence permissions and obligations.
Many companies go on to cross a second threshold. This step is more like an “a ha!” moment than a rude awakening. Management stops seeing open source as a necessary evil and starts to embrace it as an opportunity to be exploited to their advantage. These companies move from prohibiting employee access to open source projects to encouraging active participation by their employees in projects on which the company relies. A company that has entered this phase moves the focal point of the compliance process out of the lawyer’s office and into the product development process or data center. Lawyer’s representing clients that have entered this phase are more focused on how the communities in which they are invested interpret the licences. These lawyers are tasked with discerning the community consensus and that community replaces the judge and jury as the most important arbiter. These lawyers discuss the licence obligations in terms of that community consensus – or what one of the most experienced lawyers in this are refers to as the “folk wisdom” – rather than in terms of a strict legal analysis.
But when lawyers posit the community consensus as legal analysis there is violent pushback, and for good reason. Lawyers who are considering how these issues will be decided by courts, have legitimate concerns that a community consensus as to the meaning of, for example, “derivative work” as used in a licence such as the GPL, might be given weight by a judge in a consideration of copyright law. Lawyers and developers operating on the basis of the technical community’s assessment of where the sharing obligations should be triggered for practical reasons have to remember that an expansive interpretation of copyright law relating to software gives rights to proprietary software vendors as well as open source developers. It is important to draw a distinction between legal analysis and a practical, technical approach to appropriate rules in support of collaborative development.1
Not surprisingly, lawyers working in these different contexts find it very difficult to reach a consensus as the basis for their analysis is completely different. Unfortunately, the inevitable fireworks sometimes adds to the impression that these are dangerous documents indeed.
Litigators versus Pragmatists; In-House versus Outside Counsel
In-house attorneys play a very important role in any discussion of open source licences. Even if in-house counsel have a wide variety of perspectives based on where their employers are in the spectrum of open source adoption, they share a certain immediacy of purpose. They make decisions and set a course of action based on what will happen in the short term, long before litigation might provide a final determination of the parties’ respective rights and obligations. Legal analysis of the licence is only one consideration. A company can be technically right, and still lose. In-house counsel are often providing advice and counsel to their employer client in terms of the impact of negative publicity on employees, shareholders, customers, partners and other important stakeholders. In-house counsel are also considering issues in terms of internal policies and processes that drive issue identification and resolution, consistency in interpretation and risk assessment, and must always keep in mind the preservation of systems of internal controls.
Outside counsel are often engaged to play a role similar to that of an in-house counsel, but they are more often expected to predict how a situation would play out if fully litigated. The issues are framed in terms of legal procedure and the issuance of a final ruling by a judge sitting in a court room reviewing case law and statutes as the basis for his or her decision. The same presenting issue can look very different through this lens.
Not surprisingly, lawyers in these different roles sometimes find it very difficult to see eye to eye. And also not surprisingly, the public discourse is more often focused on the litigation scenario. It does not require the discussion of internal private matters and has the potential for more drama. It also is a better way for lawyers to drum up business.
Lawyers versus Engineers
While all of these complexities and varying perspectives mean it is not surprising that the legal community has trouble speaking with a single voice, developers are not sympathetic. Although developers who participate in open source communities often appear to enjoy jousting with lawyers on points of copyright law, they continue to be frustrated by the legal communities’ inability to provide a definitive answer to even the most basic questions. Development is delayed while lawyers talk. Development is disrupted with remediation tasks for lack of a definitive legal ruling. There are distinctions drawn where there are no meaningful functional differences, and situations are considered analogous where there are critical dissimilarities. Developers can describe the same operation or function to the lawyers in many different ways and get different answers. The lawyers sometimes appear completely at sea – desperate to leave an opening for every possible adverse argument to be made over and over again.
Developers are engineers and everything in their being drives them toward decision making and closure. Developers are familiar with the community consensus and are confident that common sense will prevail. They are far more comfortable looking to project committers like Linus Torvalds for guidance than to the legal community. They are comfortable with rolling interpretations of licences that reflect programming and industry developments. They assume those interpretations will be backward compatible with past interpretations, enabling everyone to continue to build on the work that has already been completed. They do not stop and wait for certainty.
Although the lawyers spend time discussing whether the licence is a contract, the developers see the licence as much more akin to a constitution than a contract. A constitution is a living document which comes to embody an evolving understanding. You cannot truly understand a constitution without a study of the historical contexts in which the precepts have been tested and new understandings forged. Developers view open source licences in much the same way.
Lawyers, on the other hand, who are focused on how the document might be interpreted by a judge in a court of law, must look at the licence as a legal instrument. Lawyers must follow the rules of contract construction and look first for answers within the four corners of the document. The words, all of the words, must be given meaning. Interpretations that conflict with the actual words of the licence must be rejected. Lawyers must divide the document into those parts that are limitations on intellectual property and those that are contractual covenants. To the extent there is ambiguity in the document, lawyers must first identify the parties to the agreement and look for statements made by those parties and which might be considered parol evidence of the party’s intent. Statements by others who are not a party to the agreement are relevant only if they can be shown to have been adopted by one or both of the parties or to evidence a community consensus as to the meaning of the document that is sufficiently universal that anyone using the document would be presumed to have intended to adopt that interpretation as trade usage or industry custom.
Progress through Collaboration
So how do we move beyond the cacophony of voices and perspectives and end the FUD (Fear, Uncertainty and Doubt)? Through collaboration, of course. Education by and for attorneys is the key to supporting adoption of open source. Unfortunately, lawyers are closed source by nature. Why? Why don’t lawyers participate in “licensediscuss” and other open discussions regarding licence interpretation and copyright law? Developers often assume it is either ignorance or stinginess that keeps us away, but there is a long list of legitimate concerns that make lawyers hesitate before jumping in to a discussion thread.
Ethical Limitations
Lawyers have special obligations to their clients. For example, they cannot take on work that conflicts with the client’s interests without the client’s permission. In order to fulfil this obligation, lawyers have to know exactly who their clients are at all times.
Of course, the rules are much more complex than this, but, in essence, a client relationship is formed when an individual believes that an attorney is providing legal advice to them. In other words, client relationships are determined by the reasonable expectations of the client and lawyers have an obligation to manage the formation of client relationships so that individuals are not misled. This obligation is very difficult to fulfil in the midst of a discussion through email chat.
Context
One of the lessons that I learned my very first day practising law is that practising law is 99% facts and 1% law. Lawyers give advice based on a very specific set of facts and they test those facts through questioning and review of documentation to make sure that the facts that they have been given are accurate. A slightly different set of facts might result in completely different recommendations from the same lawyer.
A statement made by a lawyer on an email list that is based on a very specific question can be taken out of context and applied to a different set of facts which would have elicited a very different response from the lawyer. More often, the email discussions are based on a very limited statement of facts. It often happens that in a lengthy discussion it emerges that contributors to the discussion have made very different assumptions based on the sketchy information originally provided. When more details are provided, a very different discussion ensues.
Cutting and Pasting
Similarly, the lawyer does not want his or her statements quoted in a different context to which they may not be applicable or accurate.
Timing
As we have said, the law is still developing. Statements made today will be rendered obsolete by a case handed down tomorrow. And yet the posted comments will continue to be available unless the lawyer takes affirmative action to have them deleted or altered. Even with affirmative steps to remove or update the statements on the archive, the comments will survive in every forwarded copy.
Tone and Balance
Lawyers who want to see legal developments which are supportive of open source projects and licences hesitate to participate in discussions that focus on risk and the arguments that might be made in support of alternative positions. Although a good lawyer always fully considers the arguments that can be made for or against any point, even articulating the “dark side” in print to balance a discussion may permanently link the lawyer to that point of view. On the other hand, only stating the preferred analysis is not a complete consideration of an issue.
Liability
Individuals who rely on a lawyer’s advice, even those who lurk on websites and have never identified themselves on a discussion list, may take action based on the statements made by the lawyer and may assert a claim against the lawyer if statements on which they relied cause damage.
For all of these reasons, despite the acknowledged benefits of “open,” providing lawyers with a private space, limited to lawyers, in which to discuss these issues, to learn from each other and to arrive at common understandings, is absolutely essential to developing the necessary legal ecosystem around free and open source software. The FSFE2, Open Bar and the Linux Foundation have all established and fostered such communities. The benefits of these legal communities will be seen in public communications that are more thoughtful and in less disruption and more confidence for the user community. We need a collaborative development process from which best practices can emerge. We need dialogue to form an articulated consensus. We need thoughtful explanation to understand why we have reached different conclusions and how those differences might be bridged.3
Although some might despair that this process has taken a long time and continues to move more slowly than anyone would like, there are clear benefits to moving slowly. However frustrated lawyers have been with the dearth of clarifying case law interpreting open source licences, the absence of litigation has been good for open source adoption. There is the obvious implication that the absence of litigation is evidence that companies should not have undue fear of open source adoption. But there is a much more important benefit that has come from keeping these matters out of the courts – the decisions, if and when they do come, will benefit from the long community conversation and the judges will reach different conclusions than they probably would have had the litigation commenced early in the development of open source licensing models. The recent Jacobsen case in the U.S. is an example of the kind of balanced decision making that is possible when not only the issues in the particular case are ripe for resolution but the case can be presented through amicus briefs in the context of its impact on a set of established industry expectations.
Conclusion
I was asked by a member of the audience at a conference once what I thought about all of the discussion on the “licensediscuss” email list for the Open Source Initiative that began “IANAL but” (I Am Not A Lawyer). The questioner clearly anticipated a lecture on how dangerous and potentially misleading these discussions of legal issues by non-layers can be. But my immediate and heartfelt reaction was to be grateful for the non-lawyers who had shown us the way. I responded, “If the lawyers had been all over this from the very beginning, we would have killed it.” No one should confuse the “licensediscuss” posts with legal advice, but we should not ignore them either. These are the discussions out of which a community consensus has begun to form and through which many people, lawyers included, began to understand the value of collaborative development and the community fundamentals that are essential to its successful implementation. Let the conversations continue! And let the lawyers heed the call to collaborate in the development of legal models to support collaborative development and free and open source software.
Karen Copenhaver, a partner at Choate, Hall & Stewart LLP and counsels business clients in the drafting and negotiation of strategic alliances,technology transfer and licensing of intellectual property, particularly in the areas of patent licensing, software licensing and open source business models. She is engaged by the Linux Foundation to serve as Director of Intellectual Property Strategy, is listed in Chambers USA,Legal 500, Massachusetts Super Lawyers, and has been chosen by Intellectual Asset Management (IAM) magazine as one of the world's top IP strategists, and is featured in the June 2009 "IAM 250 - A Guide to the World's Leading IP Strategists." Karen is only the 5th lawyer ever to receive Mass High Tech's prestigious "Mass High Tech All-Stars Award," which honours the thought leaders and innovators throughout theNew England technology sector.
Licence and Attribution
This paper was published in the International Free and Open Source Software Law Review, Volume 1, Issue 1 (July 2009). It originally appeared online at http://www.ifosslr.org.
This article should be cited as follows:
Copenhaver, Karen F. (2009) 'Platform: Collaboration among counsel', IFOSS L. Rev., 1(1), pp 53 – 60
Copyright © 2009 Karen F. Copenhaver
This article is licensed under a Creative Commons UK (England and Wales) 2.0 licence, no derivative works, attribution, CC-BY-ND.
As a special exception, the author expressly permits faithful translations of the entire document into any language, provided that the resulting translation (which may include an attribution to the translator) is shared alike. This paragraph is part of the paper, and must be included when copying or translating the paper.
1An example of a separation of the legal analysis from the technically based community consensus is the definition of Corresponding Source Code which is used in GPL 3.0. Using Corresponding Source Code to define the sharing obligation separates the technical discussion (what does a developer need in order to avail him or herself of the freedom to develop a derivative) from the use of the copyright term “derivative work” as the boundary of the sharing obligation.
2Through its legal arm, the Freedom Task Force
3The most difficult challenge with respect to achieving clarity in the interpretation of open source licences is the impact of local laws. For fairness, the licences should have a similar interpretation across the globe. Actors in one jurisdiction should not benefit from a more advantageous interpretation. Laws in a single jurisdiction should not interfere with the reasonable expectations of those who contribute to development projects under a licence that accurately expresses their goals for the project under commonly held community understandings. But the same process as happens within a single jurisdiction can to some extent also occur across jurisdictions. As a common consensus emerges, and as open source developed infrastructure provides the backbone for local industries, courts will struggle within permissible boundaries to preserve expectations and to avoid disruptions that could be damaging to local economic activity.