Part 1: The Dark Practice of Free & Open Source Software Law

This will be part 1 of a 2 part post, the second of which will be titled “The GPL Cooperation Commitment: Coincidentally, Great for Lawyers.” I promise the connection between the two posts will be revealed!

As an open source attorney to a number of tech startups, I often get asked how an attorney can learn more about this field and start practicing within it. I think it’s important to understand the shape and nature of the field, though, before getting into a detailed how-to. In my experience, this is a dark and murky area of law, where success largely depends on one’s connections.

Let’s start with a basic fact about lawyering: law school teaches very little about the actual practice of law, and that’s especially true for transactional or corporate attorneys who do not have a litigation practice, which would include most open source attorneys. When I went to Columbia from 2007-2010, there were no classes specifically on open source or even related fields like licensing, contract drafting, or negotiation. Sure, we could learn about various legal decisions in the areas of contracts and IP, so we had an idea of how the courts interpreted various contractual clauses and statutes, but we only ever read and interpreted one or two contracts and we learned nothing about how to actually put a client’s goals into legally binding writing. At graduation, none of us could really be trusted to write anything more complicated than a bathroom hall pass.

Most lawyers learn the day-to-day business of lawyering on the job, by taking on increasingly complex tasks that are heavily supervised and directed by more senior attorneys. In many areas of the law, this is relatively straightforward because there are many statutes, regulations, court rulings, law review articles, and even treatises available. Clients ask questions, junior attorneys look up the answers, and senior attorneys make sure the junior attorneys looked at the right things and communicated their findings clearly. There might be issues that no one has squarely addressed, in which case the attorney would have to guess as to how it might come out based on the information they have, but there’s no difficulty in figuring out what body of resources they need to examine to make that guess.

The open source world, in contrast, is relatively devoid of resources. In the US, there have only been a handful of cases related to open source and they’ve barely scratched the surface with respect to open source licensing interpretation. Outside the US, there has been more open source litigation, but that litigation has mostly taken place in Germany (and thus limited in applicability to Germany) and has mostly focused on the procedural aspects of the cases that have little bearing on open source license interpretation. With limited judicial interpretation of open source licenses, there’s not much for lawyers to write law review articles, books or treatises on.

So what on earth do lawyers use as resources in guiding their clients? Well, lawyers can guess as to how they think a license should be complied with based on a simple reading of the license, assuming there is just one applicable license. But, given that some licenses weren’t drafted by lawyers, some licenses get fairly technical, and that most commonly used licenses are so old that they predate pivotal concepts like software patents, containers, dependency managers, SaaS, and interpreted languages, simply reading the license leaves most lawyers with more questions than answers. Open source licenses as a whole are completely incomprehensible even to licensing attorneys if they’re unfamiliar with the culture and ethos of the open source movement.  

In practice, even determining how any particular piece of software is licensed is not straightforward. Some software packages aren’t marked with any license at all. There might be licensing information on the project’s homepage instead. While many software packages have a COPYING or LICENSE file indicating the package’s license, many also have additional license information in other files in the package. It’s not uncommon to see packages with 10 or more licenses and finding all of them is either a long manual effort or involves automation.  Additionally, it’s not uncommon to see a package licensed one way within the package itself but for there to be either additional or conflicting terms on the project homepage or an idiosyncratic explanation with regard to how that project interprets its chosen license.

Next, lawyers look to the authors or stewards of the license for help in interpreting it just like litigators look to congressional records for help in interpreting statutes. The GPL, Eclipse, and Apache FAQs are nearly sacred in this world. Sometimes this may involve more digging; going through old email threads, blog posts, and bulletin board posts to dig into the history of how the license was drafted and why. Some of this is available online, but a lot of this is oral history, passed down from one lawyer to another. It can be hard to know where to look or who to ask, so it’s a field where knowing others with this expertise is critical. Without understanding the historical context for how a license was born, what its intended function was, and what, if any, industry consensus there is on how a license should be applied in a particular case, it can be nearly impossible to make heads or tails of what a license written many years or even decades ago might mean in 2019.

Ultimately, lawyers advise their clients based on a risk analysis: if we don’t get this right, what is the likelihood we will be sued and by whom? Here, lawyers start looking at who the entities enforcing open source licenses are, what types of non-compliance they are targeting, who they targeting, and what their goals and motivations are. Some of this information has been memorialized in various writings, but knowing who is doing what today and what they may want to do in the future requires being plugged into the open source legal community and keeping abreast of various organizational politics within these entities. Some of these entities are license stewards or are formally organized as open source compliance organizations, but some of these entities are commercial players motivated by profits and the competitive landscape, and others are just trolls.

It’s also important for an open source lawyer to have some technical expertise. Understanding software architecture, the differences between various programming languages, and various concepts like user space v. kernel space, virtual appliances, APIs, sockets, linking, calling, etc. are all vital to giving clients good guidance. This information is easily understood by lawyers who are also engineers, but lawyers who aren’t engineers need to acquire this knowledge from disparate sources including engineers, other lawyers, and various websites and books. Because the software industry innovates so quickly, there’s no one resource for this information. Given the scale of open source software consumption today, an attorney’s technical expertise also has to extend to familiarity with a number of open source compliance tools, how to properly implement and configure them, and how to create practical workflows with them.

You’ll notice that the common theme here is more or less “you gotta know a guy/gal.” Should be easy enough… but the willingness to exchange legal thought around open source licenses is, perversely, inversely related to the number of court cases in this area. With very little substantive interpretation of open source licenses by the courts, lawyers are extremely reticent to share their understanding of open source licenses with each other. No one wants to reveal an interpretation that another attorney might dispute, and in so doing admit that what their client is doing fails to meet someone else’s understanding of what an open source license requires. That might lead to unwanted attention and litigation.

This leads us to the Free Software Foundation Europe’s Legal Network mailing list. This is probably the definitive mailing list for open source attorneys and the mailing list as a whole is invited to attend an annual conference in Europe called the Legal and Licensing Workshop, which is only open to list subscribers. This is the single largest gathering of open source attorneys in the world and it’s probably fair to say virtually all serious open source legal practitioners try to attend this conference. How does any US attorney knows about this list? You gotta know a guy/gal. How does one get approved to join the list? Again, you gotta know a guy/gal. Someone somewhere has to vouch for you. The list itself can be a valuable resource, but also requires tricky maneuvering: most of the list consists of in-house attorneys who lurk but dare not speak (see above) and some folks on the list are from open source license enforcement organizations. It’s great for outside counsel like me who can ask questions without necessarily divulging on whose behalf I’m asking them, but it’s a “look, don’t touch” arrangement for in-house counsel who might accidentally reveal they’ve being doing it all wrong all along – directly to the people most likely to instigate an enforcement action.

In short, becoming an open source attorney is less about learning the law in a particular field and more about being plugged into a particular community. To give clients the best guidance you can, you have to understand copyright law and contract law (and patents, trademarks to an extent, etc.), be familiar with dozens of licenses, understand their history, understand a good bit about programming and computers, know who the license stewards are and how they interpret their licenses, understand the enforcement players, have a grasp of the competitive landscape, and learn about various compliance automation tools. This is truly a multidisciplinary field in which resources are scattered and hard to come by and where every analysis contains multiple layers.

In my opinion, becoming a real expert in the field takes years of working with a number of different technologies and licenses and getting to know others in the open source world personally or at least through their writing. It also helps to have experience working on both primarily proprietary and primarily open source products. Unsurprisingly, there are relatively few open source legal experts in the world – the last Legal and Licensing Workshop in Barcelona had fewer than 200 attendees. Breaking into this field is just plain hard and strongly depends on having the right connections.