There is a fairly common perception among members of the Free and Open Source software (FOSS) hacker1 community that there is no equivalent community of FOSS lawyers. Karsten Wade, a deeply involved member of the Fedora community, had this to say on the subject in March 2010:
"During Richard Fontana's talk at SCALE, I heard a clear need for a community of practice for the FLOSS legal community..."2
Wade saw a need for a community that in fact already exists, and is growing. This note will explore the gap between the perception and the reality, first by briefly surveying the state of the FOSS legal community, then by exploring the reasons why there is such a disconnect between the lawyers and the community of our clients, and finally suggesting some ways in which the community might invest in improving itself.
There are a multitude of formal definitions of community. Etienne Wenger provides the following useful one:
"Communities of practice are groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly."3
This definition specifically focuses on what Karsten Wade (in the previous quote) and Wenger (in his research) refer to as 'communities of practice' - communities which are formed around skills, rather than more traditional community focuses like a neighbourhood, religion, or political affiliation. The FOSS developer community is a common example of a modern 'community of practice.' The heart of this author's personal, less formal test for community is 'can the members of a group with shared interests call on each other for help when needed?' In both these formal and informal ways, there is definitely a growing FOSS legal community.
First, over the past decade, the progress of FOSS has created a group of legal experts who have a shared interest in understanding and engaging with communities of FOSS hackers. This is a diverse group with diverse motivations,4 including partners at high-profile law firms, counsel at FOSS-using companies, individual practitioners with FOSS clients, and other interested groups like the Open Invention Network (OIN) and the Software Freedom Law Center (SFLC). Over time, a variety of events, most notably the eighteen month General Public License revision process,5 have also started building regular lines of communications among these people. The combination of these two trends - increased concern and increased interaction - have resulted in a true community of practice by Wenger's definition. This community has also passed my personal, informal test - when the author's employer (Mozilla) started a process to review its own license, hePage 79was aware of at least a half-dozen people who he knew would answer his call for help. This informal community was very helpful in laying the early groundwork for the Mozilla Public License (MPL) process, and has continued to be helpful as the process has continued.
While the community clearly exists, it is still small and largely informal, largely lacking the sophisticated infrastructure that hackers have come to associate with mature, functional communities. As a result, the community is largely invisible to hackers. For example, hackers look for mailing lists6 and mini-conferences as signs of community because regular communication is critical (though insufficient) to forming real community. There are now several mailing lists where FOSS lawyers discuss topics of interest. Two such groups - the older Open Bar7 and the newer Free Software Foundation Europe's (FSFE) Freedom Task Force European Legal Network8 - have public web presences, but most of them are effectively private - making it difficult for hackers to recognize that such communication is taking place. Similarly, several organizations, like SFLC, OIN, the Open Source Initiative (OSI), and the Linux Foundation (TLF), have started hosting legal mini-conferences, like OSI's recent event,9 SFLC's series of events in support of GPL v3, and the annual FSFE European Legal Network Conference. As any hacker who has been part of a large community will tell you, such face-to-face conferences are critical for building strong ties - in fact, for hackers, attending such a conference is often a critical step in turning occasional participants into vigorous community members. The existence of this communications infrastructure is a positive sign for the community.
While the community has made some progress in building infrastructure, and therefore visibility, some other structural features that hackers look for in a functional community are still invisible-either missing or, in some cases, private. Most notably, when hackers look to see if a community is healthy and vibrant, they look to see signs that the community is engaging in an ongoing, tangible project; the community's success in building the project is often seen as a proxy for the health of the community.10 While several FOSS lawyers (most notably those in OIN) are engaged in ongoing projects that might satisfy this role, the specialist nature of the projects may make them fairly opaque to non-lawyers. These ongoing public projects are almost necessarily rare, since most legal projects are one-time events, and many others are private (like most GNU General Public License (GPL) compliance negotiations, or many of the documents produced by the European Legal Network). Because of this they cannot leave the tangible, public artefacts that code-centric communities recognise as signs of success. In addition, because these interactions tend to take place within specific communities, rather than involving multiple FOSS communities at the same time, they may not have a broad impact on community perception.
Relatedly, another sign of maturity that FOSS hackers look for is collaboration with other projects. This signals that others have found that community to be useful and/or easy to work with. ThePage 80most efficient way to do this is to provide something that is useful to many projects at once; for example, the Linux kernel and GNU compiler are viewed as successful and mature in part because the software they provide underpins so many other projects. The FOSS legal community is not without examples of this - the GPL, for example, is used by many projects, and the SFLC's Conservancy11 is becoming more widely known as a good example of the kinds of useful infrastructure that lawyers can provide to developers. But these examples are rare, and that rarity contributes to the visibility and awareness problem that faces the FOSS legal community.
The lack of community infrastructure and recognition described in the previous section is in large part caused by the short time that lawyers have been involved in FOSS. These things don't come overnight, even to the most 'natural' communities. But it is also worth examining the structural and cultural barriers which have helped make it hard for lawyers to participate in the open source 'bazaar.'
Before focusing on lawyers in particular, it is worth reviewing the concept of the bazaar. In Eric Raymond's seminal 'The Cathedral and the Bazaar',12 he argues that pre-open source development was focused on a model of development that resembled that of the cathedral-builders, where only certain participants were allowed to contribute, and then only in a very structured, hierarchical fashion. In contrast, he observes that most open source projects are more like a bazaar - "a great babbling bazaar of differing agendas and approaches" where anyone who wants to can set up a 'stall' and eagerly exchange knowledge, skills, and content. While this 'bazaar' model is certainly not perfect,13 it has proven quite robust and is the dominant organisational model for most open source projects. In contrast, legal practice has traditionally been very 'cathedral'-like, and this culture will put some barriers between lawyers and open source clients.
The first example of problematic legal culture is the common practice of the billable hour. The billable hour encourages us to be very sceptical of any work which is "inefficient" or which doesn't give an immediate pay-off. Unfortunately, much of the work necessary to build social capital in a community falls into one or both of these categories. For example, educating others to do common tasks is one of the things that healthy communities of practice do well. This process is costly in the beginning (because work is done by less efficient workers, and the expert's teaching time is time not directly applied to the problem at hand) but has long-term pay-offs as the community of skilled individuals grows, allowing experts to focus more exclusively on high-value tasks.
A second, related issue is the occasional arrogance lawyers have about the skills necessary to do legal work. In the non-FOSS world, this problem manifests itself as a reluctance to use paralegals for many tasks leading to unnecessary client costs. In the FOSS world, there is a slightly lessPage 81direct impact. Healthy communities break down the barriers between 'insiders' and 'outsiders'14 so that new bodies, new perspectives, and new enthusiasm regularly refresh the community. Unfortunately the elitism of the legal community can make this hard to do. This is not an easy problem to solve, of course, since much of what lawyers do is in fact extremely complicated, and in many cases requires not only formal training but also extensive practical experience. Despite this problem, the impact of this insider/outsider barrier can be reduced. For example, a healthy legal community could explicitly seek to provide tasks and other entry points that are accessible to non-lawyers. (Most distributions do this to some extent by farming out very basic licensing testing to hackers.) A healthy community could also clearly articulate why some tasks truly do a specific skill set, making new participants less likely to be discouraged when they aren't able to participate. Taking these steps would help broaden the base of participants, giving the community more resources in the future.
The lawyer's habitual allergy to plain English,15 which is so essential to a functional community that it isn't even mentioned in The Open Source Way, is also a problem. Non-hierarchical communities tend to form around people who communicate in the informal style which is naturally associated with relaxation and fun (in the case of volunteers) or associated with peers relating to each other on a fair basis (in the case of multi-company collaborations). This communication may be highly jargon-filled (when that jargon is central to the mission of the community) but that should not be confused for formality. Formality is typically a signal of distance, hierarchy, and other things that aren't conducive to community formation. The lawyer's natural tendency to be both formal and use a lot of jargon is a dual killer.
On top of all these other problems, the structures of privilege, evidence, and ethics law combine to make lawyers very nervous about discussing anything in public. Young lawyers are often explicitly told that doing things in public has very few upsides and vast numbers of potential downsides. This means that even when all other cultural barriers are reduced or removed, there is a tendency to keep the communities that do exist - and their successes - private and out of the limelight.
All of these cultural factors combine to reduce the visibility of the FOSS legal community, and reduce the community's ability to interact with and support other open source projects. While no magic bullet can cure these problems, awareness of them, particularly when planning open source legal projects, could help reduce their impact and increase the success of the legal community.
This note has presumed that increased visibility and effectiveness would be a good thing for the FOSS legal community. While increasing the social capital and infrastructure of the legal community is unlikely to be controversial, the other part - increasing the broader FOSSPage 82community's awareness of the legal community - is clearly not a unanimous goal of the legal community.
Increased legal visibility in the FOSS community could be seen to have two primary downsides. First, increased legal participation could be seen as a source of increased transaction cost between open source participants - more documents to read, more risks highlighted, etc. This is a legitimate concern; after all, lawyers do not have a sterling reputation for reducing transactional friction. This should not be an overriding concern, though. The success of the GPL and Creative Commons suggests that when lawyers are sensitive to the problems of friction they can use techniques like standardisation, simplification, and attentiveness to client needs to increase trust and reduce transaction costs.
The second theoretical downside is that increased legal participation could be interpreted by naive consumers as a sign that there is increased legal uncertainty around FOSS. Since increased legal uncertainty is a known strategy of the opponents of open source,16 this is a legitimate concern, but not an insurmountable one. For example, the community could reduce this risk by turning the spotlight from work on high-risk issues, like patents, to issues that play to FOSS strengths, like inefficiency-reducing standardized documents.
These potential downsides should be weighed against the many values of publicity. Most notably, knowing that lawyers are working actively on their behalf will help increase hacker community confidence - and hence investment in - their own work. Such confidence is an explicit goal of projects like OIN. Publicity will also help bring more resources 'out of the woodwork' - as any experienced community participant will tell you, other people can't help if they don't know what you're working on.17 These benefits should outweigh the concerns discussed above.
In hacking, the shift from a cloistered, do-everything-in-house mentality to one focused on public collaboration and sharing did not happen overnight.18 Making the same shift will be even slower for lawyers because of the structural and cultural barriers this note has highlighted. These barriers are generally deeply engrained; some may not go away at all and others will go away only slowly. But, keeping those concerns in mind, the rest of this note will suggest some projects that might be reasonably attainable while also increasing the long-term effectiveness of the FOSS legal community by broadening and deepening the community's social capital.
The first category of projects would be those that lower the barriers to community formation and participation by lawyers. This category of project is perhaps the one where the most work is already going on, led by various groups who are bringing lawyers together at conferences to educate them and build social ties. But the community could go further. One potential project is in the area of privilege law. As already noted, many lawyers believe that privilege law makes it difficult to give legal advice to an entire FOSS community. No formal guidance (that the author is aware of) lays out how and to what extent lawyers are legally and ethically permitted to give public advice to ill-defined communities; instead, lawyers fall back to their own conservative instincts in this area. If a group of lawyers sought and publicized formal ethical guidance in this area, more lawyers would be enabled to do more work with pre-existing communities.
Another category of projects that could be considered are educational or 'security blanket' projects that seek to protect and calm the broader developer community by educating the community about intellectual property law, combating disinformation, and educating the community about the legal community's protective strategies. For example, at a recent meeting of FOSS lawyers, there was discussion about patent strategy - not merely planning for the next attack, but also about educating and informing the broader community about the plan. Such a proactive, two-pronged approach which explicitly combines action with broad education about the action would help get the legal community itself in the habit of working collaboratively on such projects as well as making the community aware that good work was being done on their behalf. This would make members more competent in self-assessment, less fearful, and more motivated to do their own work.
Collaborative projects that produce reusable legal documents are a third category of work that could help build legal community social capital as well as directly benefiting the developer community. Interestingly, this community has produced some of the most widely used legal documents on earth (in the form of the various public copyright licenses) but has largely failed to produce similar standard documents dealing with common issues like basic legal and intellectual property education, trademark licenses, privacy policies, and copyright assignments. Collaborative attempts to write such documents would not only help reduce friction for the community of FOSS practitioners, it would again build the legal community's experience, enabling it to more effectively deal with future challenges.
Finally, lawyers should look to identify legal work that can engage non-lawyers, both because of the pragmatic short-term effects of engaging a large community with a lot of resources, and because of the long-term effects of building a more impactful community. One example of this might be engaging with the engineers who work at distributions to do a more effective job of checking license compatibility in the projects that they package for the distributions. Doing this would leverage pre-existing engineering resources to improve the quality of licensing information available to the entire community. In the same vein, OIN has a project which attempts to collect ideas from hackers and turn them into records of defensive prior art19 available to patent examiners. This is an excellent example of the kind of work that can be done by helping non-lawyers create information. One could easily imagine extending or duplicating this model for a variety of legal projects which need engineering input, such as attempts to explain linking to lawyers.
This list of potential projects is certainly not exhaustive, but is intended to illustrate the kinds of projects which could lay the groundwork for increased effectiveness and visibility for the FOSS legal community. Careful thinking about cultural and structural ramifications of every project, not only the legal ramifications, can help build a more effective long-term community - of both lawyers and clients.
Despite the barriers identified in this note, the FOSS law community is still growing, which is a testament to the power of the collaborative model and the social and economic incentives which are drawing lawyers to collaborate. Hopefully this note can contribute to this growth by spurring the community to greater introspection when planning projects and considering communication with this atypical, but worthy, group of clients.
 This note uses hacker in the traditional, positive sense of someone who "delights in having an intimate understanding of the internal workings of a system" (http://catb.Org/iargon/html/H/hacker.html); as the note will discuss later the author believes that the formal language of 'developers' and 'engineers' is not conducive to community creation.
 Karsten Wade, email to Fedora Legal List, Mar. 10, 2010, available at http://lists.fedoraproiect.org/pipermail/legal/2010-March/001179.html
 Wenger, Etienne 'Communities of Practice: A Brief Introduction', http://www.ewenger.com/theorv/. via 'The Open Source Way', http://theopensourcewav.org/book/single-page/index.htmlttThe Open Source Way-Communities of Practice-What is a Community of Practice
 Diversity of motivation is typical of functional communities; for some discussion of this issue, see Benkler, Yochai (2002) 'Coase's Penguin, or, Linux And The Nature of the Firm', 112 YaleLJ. 369; also available at http://www.valelawiournal.org/the-vale-law-iournal/content-pages/coase's-penguin.-or.-linux-and-the-nature-of-the-firm/
 For background on the process, see 'GPL3 Process Definition', available at http://gplv3.fsf.org/gpl3-process.pdf
 See, e.g., 'The Open Source Way', Sec. 126.96.36.199 "Set up a mailing list first" available at http://theopensourcewav.org/wiki/How to loosely organize a communitv#Set up a mailing list first.
 Open Bar, web site at http://www.open-bar.org/
 Freedom Task Force, web site at http://www.fsfe.org/proiects/ftf/index.en.html
 Radcliffe, Mark, 'February 10 FOSS Legal Strategy Session Silicon Valley: Success!1 available at http://lawandlifesiliconvallev.com/blog/?p=421
 Traditionally journals like this one serve a similar signaling functions in the legal community by conveying to other lawyers that a sub-specialty has reached a critical, self-sustaining mass and a sense of self-identification. It will be interesting to see if this journal performs a similar signaling function to the hacker community.
 Software Freedom Conservancy, website at http://conservancv.softwarefreedom.org/
 Available at http://catb.org/~esr/writings/homesteading/cathedral-bazaar/
 See, e.g., discussion of the implications of the bazaar model for user interface design in Feinberg, Jay, 'The cathedral and the bazaar of user interface design1, available at http://icite.net/blog/200403/cathedral bazaar.html and Dorner, Christian, et al, 'End Users at the Bazaar: Designing Next-Generation Enterprise Resource Planning Systems', available at http://doi.ieeecomputersocietv.org/10.1109/MS.2009.127
 See, e.g., discussion in 'The Open Source Way1, http://www.theopensourcewav.org/book/The Open Source Way-Communities of Practice-Open a dialogue between inside and outside perspectives.html
 For the web user's take on the use of plain English, see Levine, Rick, et al, (1999) 'The Cluetrain Manifesto', available at http://cluetrain.com/. For a specialist's review of the harm done to the legal profession by specialized language, see chapter 4 ('Some Benefits of Drafting in Plain English') of Butt and Castle (2006), 'Modern Legal Drafting: A Guide to Using Clearer Language'
 See, e.g., Parloff, Roger, 'Microsoft takes on the free world1, Fortune Magazine, May, 14, 2007, available at http://monev.cnn.com/magazines/fortune/fortune archive/2007/05/28/100033867/index.htm/
 In a recent example of this, one major open source company recently announced a project to collaboratively build a specific type of legal document which could be reused across many projects, reducing transaction costs for everyone who used it. This announcement immediately won commitments from a substantial number of legal community members to work on the document. Less than two weeks later, another major open source company announced that they had been privately working on a nearly identical document for a year. Had the second company announced their work earlier, the document would likely have drawn resources from outside the company (making the process more efficient for them) and made the resulting document more useful for a broader range of projects (making the outcome more useful for the open source community as a whole.)
 For apre-open source discussion of this phenomenon in Boston and San Francisco, see Saxenian, Anna-Lee (1996) 'Regional Advantage: Culture and Competition in Silicon Valley and Route 128', Harvard University Press
 Linux Defenders project, website at http://linuxdefenders.org/