Legal issues from a radical community angle

The sixth Free Software Legal and Licensing Workshop, which took place on 4-5 April 2013 in Amsterdam, opened with a keynote (slides [PDF]) from Stefano "Zack" Zacchiroli, the Debian Project Leader (DPL) for the last three years. Zack's aim was to provide the assembled lawyers with an overview of the kinds of legal issues that are faced by Debian—lessons from his own experience that he believes are useful "when dealing with communities like us". He emphasized that although he would use Debian as his example, the issues he was going to cover applied more generally to many community software projects.

Debian legal fundamentals

Zack started by outlining how Debian is organized and operates. Debian is now nearly twenty years old (DebConf 13 will fall on the twentieth anniversary in August), and has grown into one of the largest free software projects in terms of developers and users. "Today, we are quite successful." Debian is the leading distribution (source: w3techs.com) in the web server market, he said. The project has a huge archive of packages (some 30,000 binary packages) and supports twelve architectures. It is the base for around half of the active free software distributions.

Debian also has a social aspect that is embodied in the Social Contract. Zack focused on a few points from the Social Contract that determine how Debian approaches legal issues. First, the Debian software archive is structured into two parts. The main repository consists of the software that Debian believes to be free. Second, Debian also provides a kind of hosting service (the non-free repository) where it hosts non-free software that users need to run their systems. Finally, Debian has a philosophical commitment not to hide technical problems; that commitment has grown into a general culture of transparency. This openness can be problematic for legal issues, because there is an assumption that it is usually best not to publicly discuss any legal problem you might have.

Zack then looked at what he termed three legal fundamentals of Debian. The first of these is the Debian Free Software Guidelines (DFSGs), which is "one of the benchmarks for deciding if software is free or not". It requires the four software freedoms (run, study, redistribute, modify) and has some distribution-specific provisions. It also serves as the basis for the Open Source Definition, another widely cited definition of software freedom. The DFSGs apply to all content used and created by Debian—not just software, but also documentation, artwork, and so on. In a sense, this makes Debian even more radical than the Free Software Foundation, he said.

The second legal fundamental concerned governance. On paper, Debian is pretty formal. It has a constitution that provides structures and rules, and has a number of bodies (e.g., DPL and the technical committee) and procedures (e.g., the new member process and resolutions). In practice, however, Debian is almost anarchic. There are hundreds of teams and thousands of maintainers who are almost entirely autonomous when it comes to making technical decisions. There is no top-down decision-making process.

The third legal fundamental that Zack discussed was Debian's independence. Compared to other popular distributions, Debian is unique. There is no single company that could claim to significantly influence Debian's direction. Debian lives largely on donations and a gift economy. This does have drawbacks, he noted. Debian has limited access to the kinds of corporate resources available to many other distributions, so that, unlike commercial distributions, Debian generally cannot solve problems by, for example, paying developers. Debian's independence is also reflected in how its assets are organized. Those assets are scattered across a number of institutions around the world, for example, Software in the Public Interest in the US, FFIS in Germany, and debian.ch in Switzerland.

Zack noted various consequences of the fundamentals that he had described. First of all, top-down control does not work; one can't tell volunteers what to do. Second, Debian has very limited access to legal advice—unlike commercial distributions, Debian does not have in-house lawyers to call on. Finally, there is some US-centrism in the legal information that they do have access to.

Zack then presented three stories "from the trenches" concerning legal issues that Debian has faced, one on each of the topics of copyright, patents, and trademarks.

Copyright

The copyright concerns of a distribution project such as Debian are different from the concerns of a development project. Because Debian does very little software development, it has no interest in copyright assignment. Debian's main concern is verification, to ensure that the software in main is completely free according to DFSGs and that the remaining software that Debian mirrors can be legally redistributed.

The lesson that the Debian project has learned is that doing this sort of verification in a distributed fashion doesn't work in a project at the scale of Debian. Even though Debian goes to some effort to train its members in legal issues, the project has learned that it isn't possible to guarantee that all maintainers are equally attentive when it comes to legal issues.

Instead, Debian has adopted a two-tier process for license review. In the first step, the Debian maintainers review the copyright claims made by the upstream project. Then there is a second step that is performed only the first time that the package added to Debian. That step is performed by the FTP Masters, who review packages from the "new queue". Upon passing that review, the package is added to the Debian archive. Subsequent updates of the upstream package skip the second step of the review.

This review approach is a compromise between being thorough and doing what is possible given the available human resources. It endeavors to ensure that on the first time a package is uploaded, a thorough license review occurs, while relaxing the effort required for subsequent updates. In passing, Zack noted that the Debian legal mailing list is only a discussion forum; it does not represent any official legal stance by the Debian project on licenses or projects.

When dealing with licenses in a project on the Debian scale, some degree of automated quality assurance is desirable, Zack said. Such automation would help to determine whether incompatibly licensed code is linked together (e.g., OpenSSL-licensed code linked with GPL-licensed code) or to determine how much code is licensed GPLv2-only and is thus incompatible with GPLv3-licensed code. The idea would be to cross-check package-build dependencies with licensing information, in order to find packages that need further licensing review. To do this, one needs a machine-readable version of the copyright information.

Debian started work on a standardized format (debian/copyright) for copyright information in 2007, and reached version 1.0 of the format in 2012. The format is both human and machine readable, and can describe license types and versions for a package. The format can describe licenses for an entire package while at the same indicating exceptions for subtrees and even individual files. Zack noted that SPDX serves a similar role to debian/copyright, although, by contrast with debian/copyright, SPDX is primarily intended for machine reading. There are some prototype converters for converting between the SPDX and debian/copyright formats.

From a legal perspective, the potential value of debian/copyright is that it represents a huge corpus of reviewed licensing statements about free software, Zack said. So far, reviewed debian/copyright descriptions in the new machine-readable format have been completed for about 44% of the Debian archive (about 8000 source packages).

Patents

Like all large software assemblies, the Debian archive is a patent minefield, Zack noted. You will surely find someone who will make claims against the archive, he said. Debian has tried to do some some risk assessment with patent issues. One lesson that he has learned from the process is quite shocking, he said. "Hysteria has totally won." Communities tend to take a black-and-white approach to the subject of patents, when in fact the matter is necessarily blurry.

The "black" part of the picture is that communities think that certain software is inherently dangerous from a patent perspective, because the software has (for example) been the subject of claims or lawsuits, and that software must therefore be avoided. The "white" part of the picture is that much other software is considered to be perfectly safe, resulting in a false sense of security. This dichotomy creates a pressure to split software into "safe" and "unsafe" categories, and can lead to software forks; Zack noted that the Debian-multimedia fork was the product of such pressures. Such forks result in much wasted effort duplicating the same tasks.

The generally accepted wisdom that one should not speak publicly about patents doesn't work within Debian. There have been recurrent public mail threads of the form "I think package X is governed by patents; please remove package X". These claims usually come from someone with little legal background. Such claims can be dangerous for the claimant, because they show that the person knows something about the patent; that, in turn, can render the claimant more (legally) accountable than anyone else. These claims can also be dangerous for the Debian community because there is a huge public readership of the mailing lists, and there is a potential for increased claims for damages against the project (for knowingly violating patents).

As a community, Debian needs a lot more training material on patents. That material needs to be community-oriented (rather than company-oriented) and cover other jurisdictions as well as the US. Working with the Software Freedom Law Center (SFLC) has resulted in the Debian Position on Software Patents and the Community Distribution Patent Policy FAQ. Zack emphasized this piece from the former document:

Debian needs a lot more patent training materials such as these, Zack said, as well as high-quality pro bono legal help in dealing with patent issues.

Trademarks

Like all large free software projects, Debian has many trademarks, including the "Debian" name and the Debian swirl.

The first lesson about trademarks that Zack noted is that free software communities tend to be "viscerally" against them. The notion of using a trademark to restrict the use of a program runs counter to Debian's culture of software freedom. The DFSGs allow the possibility that:

However, the document goes on to note that:

In the face of community skepticism about trademarks, the best argument that Zack has found is that trademarks can be a useful tool to prevent infringements that run counter to the community ethos. For example, without a trademark, one loses the possibility of going after people who distribute a product that they claim to be Debian, but which contains non-free software or malware.

Skepticism about trademarks and the "feeling of restriction" that most trademark policies impose means that for fourteen years (1998-2012), Debian had a "lousy" trademark policy, Zack said. The Debian trademark policy 1.0 said:

Among other problems, Zack noted that this policy contained no example of unacceptable use of the trademarks and no statement restricting the use of the name Debian in products, which is one of the principal purposes of having trademarks.

Debian needed a free software-compatible trademark vision. Such a vision was drafted a few years ago by Benjamin Mako Hill and Greg Pomerantz. One of the two main goals expressed in that vision is that trademarks should be as free as possible. In other words, "tell me [a Debian developer] the minimum restrictions that I must impose in order to protect my trademarks". The other main goal was to have trademarks used as much as possible; the rationale for this is that hackers use trademarks to promote free software, by, for example, selling merchandise that employs the Debian trademark.

Debian's work on trademarks, in conjunction with reviews by lawyers at the SFLC, resulted in the release of version 2.0 of the trademark policy in January 2013. The policy has already become quite popular and acted as an inspiration for work in other communities, Zack said.

We need much more reference and educational material at the intersection of trademark law and free software, Zack said. Trademark templates that clearly indicate which parts of the document are required and which are optional are also needed. In this regard, he expressed great appreciation for the Model Trademark Guidelines site that was started by Pam Chestek in February 2013.

Looking forward

Zack said that the stories he had told were just a sampling of the legal issues faced by free software projects. Debian alone has faced many other issues, including US regulations on the export of cryptographic software, DMCA issues, issues dealing with contributions from US-embargoed countries, and trademark trolls. Debian still has problems dealing with inbound trademark policy: how can the project decide when it is safe to keep the original name of a piece of software or when it needs to rename a program to avoid trademark issues? Other communities will have many more stories, Zack said. "You should ask them to tell you their story. We need each other. The community needs legal advice, and lawyers need community stories to understand what legal approaches might work in the context of particular software communities."

Zack closed his talk with a legal wish list. The free software community needs much more legal educational material, he said, so that people in those communities are aware of the legal issues that affect their daily work. The community also needs more fiscal sponsors and more access to high-quality pro bono legal advice (along the lines of SFLC). There are a few things that the community needs less of, he said. Among these are fewer laws that punish people for knowing things or talking about things. "Please, fix the law." The community also needs fewer people, including lawyers, spreading FUD (fear, uncertainty, and doubt), because it is making the software ecosystem more complex. Finally, there needs to be less US-centrism, he said. The community has some understanding of the US legal system, but needs much better understanding of other countries' legal systems. Zack concluded with the observation that laws, how we apply them, and how we communicate about them, all shape free software communities and their processes.