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,
debian/copyright descriptions have been added 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:
[…] patent concerns expressed publicly may turn out to be
unfounded but create a good deal of fear, uncertainty, and doubt
in the meantime […] please refrain from posting patent
concerns publicly or discussing patents outside of communication
with legal counsel, where they are subject to attorney-client
privilege.
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:
The license may require derived works to carry a different name or
version number from the original software.
However, the document goes on to note that:
(This is a compromise. The Debian group encourages all authors not
to restrict any files, source or binary, from being modified.)
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:
Debian trademarks are valuable assets that we need to protect. We
allow all businesses to make reasonable use of [them]. For example,
if you make a CD of Debian, you can call that product Debian.
If you want to use the name in some other way, you should ask us
first. To be fair to all businesses, we insist that no one other
than Debian uses Debian trademarks in the name of the business,
organization or domain name.
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.