Copyright assignment (or licensing) agreements for projects is a rather
contentious issue that reflects differing views of how free software will
be best-positioned to grow over the coming years. Several perspectives
were on display at the "Panel on Copyright Assignment" held on August 6 at the Desktop
Summit in Berlin. The panel consisted of two opponents of such
agreements, Michael Meeks and Bradley Kuhn, as well as perhaps their most
outspoken proponent, Mark Shuttleworth, with GNOME Foundation executive
director Karen Sandler handling the moderation duties. In the end, each
position was well-represented, but, as might be guessed, neither side
convinced the other; each will likely continue to pursue its path over
the coming years.
Sandler asked the assembled room—packed with 400 or more
attendees—how many knew about the issues surrounding copyright
assignment and around half raised their hands. More or less the same half
responded that they already had strong feelings about the subject, though in which direction wasn't
necessarily clear from the query itself. Based on the general feeling in
the free software world—perhaps reflected in the 2-1 ratio on the panel—it is probably
reasonable to assume that most of the strong feelings were in the
The differences between copyright assignment agreements (CAAs) and
copyright licensing agreements (CLAs)—the difference between assigning
copyright to an organization vs. giving the organization a broad license to
do what it wishes with the contribution—was not really under
discussion as Sandler pointed out in the introduction. For the most part,
the differences between the two are not germane to the dispute. She then
asked each of the panelists to introduce themselves and to outline their
Setting the stage
LibreOffice and longtime GNOME hacker Michael Meeks went first with
his objections that he said came under three separate headings:
scalability, conflict, and ownership. Those make a nice acronym that also
summarizes his feelings, he said. Meeks was at one time an advocate of
copyright agreements, and then changed his mind because he has "seen it
go badly wrong".
The scalability problem is that giving the rights to your code to a company
leads to them having a monopoly. The company typically has a strong
copyleft outbound license (e.g. GPL) to drive any proprietary licensing to
the company. This can lead to conflicts, he said, like "hackers
vs. suits" or the community vs. the company. If contributors don't
feel like they own part of the code, they "feel very differently
about the project", he said. They don't necessarily feel any
allegiance to the company, but the loss of ownership can make them feel
like they aren't really part of the project either. That can cause less
vibrant and excited communities.
Canonical and Ubuntu founder Mark Shuttleworth said that he thinks of
himself as a gardener and
"looks at how ecosystems grow and thrive". As a businessman,
he wants to be part of a thriving ecosystem and believes that others in the
room share that view. Today, we don't have a thriving ecosystem for the
Linux desktop, he said. Even in the face of Microsoft domination, iOS and
Android have built thriving ecosystems and he would like to see the Linux
desktop do the same.
"Freedom is not on the table in these discussions",
Shuttleworth said. While code that is contributed under one of these
agreements could go proprietary, the code itself is not at risk as it will
always be available under the free license that it was distributed under.
The Linux ecosystem needs lots of smaller companies and startups to be
involved, but that isn't happening, he said, as they are developing for
Android, iOS, or the web—and are not at the Desktop Summit.
There are several ways to get companies to participate in a free software
project, Shuttleworth said. One way is to a "nexus project"
like the Linux Kernel, where companies have to participate in its
development, though they "hate it" and wish that they weren't
required to do so, he said. Another way is
to have a "core shared platform" with a permissive license
that allows companies to add "secret sauce extensions", and
pointed to the PostgreSQL community as an example. Aggregation is another
path—used by Linux distributions—to take the work of multiple
communities, package them up, and make quality or IP promises about the
bundle to attract customers. Lastly, he mentioned the single vendor model
which clearly states that there is an organization behind the project, like
Mozilla. There are fears about that model, he said, but the way those
fears are dealt with in mature markets is via competition.
Bradley Kuhn of the Software Freedom Conservancy disagreed with
Shuttleworth: "software freedom is always on the table", he
said, and it is always under threat. Kuhn was formerly the executive
director of the Free Software Foundation (FSF) and currently serves on its
board. He noted that the FSF put a lot of effort into putting together a
legal framework where projects can work with companies on equal footing.
The license that is used by a community is in some ways the constitution of
that community, but a copyright agreement can change that constitution in
unilateral ways. Copyleft is designed to make sure that derivatives of the
code are always available under the terms which the original code was
Kuhn noted that some might be a bit surprised at his opposition, given that
the FSF requires copyright assignment for its projects. He has been
advocating making that optional rather than mandatory, but has so far been
unable to convince the board to make that change. But there is "a
tremendous amount of value" in assigning copyrights to an
organization that is "completely aligned with free software"
such as the FSF. The FSF has made promises that the code and its
derivatives will always be available under a free license, but unless a
company makes those same kind of promises, there is no such guarantee. So
far his requests to some companies to make promises of that sort have
been met with a change in the subject, he said.
Meeks asked Shuttleworth if he agreed that signing a copyright agreement
with a company gives that company a monopoly, and Shuttleworth said that he
didn't. If the code is available under the GPL, there is no monopoly, he
said, though the company with a majority of the copyright is in a
"beneficial position". Kuhn argued that Shuttleworth was
changing the subject, because the monopoly is on the ability to
license the code under proprietary terms. That is a "trite and
obvious" observation, Shuttleworth said, in agreeing that it does
give that kind of monopoly power to the copyright holder.
Meeks said that the reason that there are two major Linux desktop projects
stems from the proprietary licensing problem, referring to the non-free Qt
licensing that existed at the time of the GNOME project's founding. He
believes that having both of those is a "sad waste". Part of
the problem for Linux is lots of "pointless duplication", he
said. In response to a question from Shuttleworth, Meeks said that having both the Firefox and Chrome browsers was pointless
duplication in his view. "I see nothing wrong with Firefox", he said.
Signing requirements and "friction"
pointed out that copyright agreements "can cause problems and we should be
careful to address them". One of those problems is the "friction"
caused by having to sign an agreement at all, noting that one of the great
strengths of the GPL is that you don't have to sign it. But, in cases
where an agreement is needed, we can reduce the friction, which is what
Project Harmony was set up to do, he said. By reducing the number of
differing agreements, companies like Canonical would not have to look at up
different ones every year, he said.
Kuhn said that his goal would be for Canonical and others to never have to
sign such an agreement at all. If the license under which the code is
contributed is the same as that under which the project is released
(i.e. "inbound == outbound"), there would be no need for an agreement. The
GPL is designed to handle that situation properly, Kuhn said. He also
noted that he was concerned about the Harmony agreements because they could
lead to the same kind of confusion that the Creative Commons (CC) licenses did.
By having multiple different kinds of agreements under the same top-level
name (e.g. Harmony or CC), there can be confusion as to what
is meant, he said. It took time to separate the freedom-oriented CC
licenses from the non-free choices, and he worries that a similar situation
may arise for Harmony.
Sandler asked the panelists about using the "or later" clause (e.g. GPLv2
or later, aka "plus" licenses) when licensing code and what the implications were. Kuhn noted
that the Linux kernel famously does not use "or later". He said
that doing so is putting trust in another organization, and that if you don't
trust that organization "deeply", don't sign a copyright
agreement with them or add an "or later" clause to a license that is under
But Shuttleworth is concerned that using "inbound == outbound" licensing is
"believing that the world won't change". While licensing
won't change overnight, it will eventually to address changes in the legal
landscape. Just as there needed to be a GPLv3 to address shortcomings in
v2, there will be a GPLv4 and a GPLv5 some day, he said. Richard Stallman
will not be around forever, so you are placing your trust in the
institution of the FSF, he said. It would be better to place that trust in
the project itself and allow it to decide if any license changes are needed
down the road.
Essentially disagreeing with both, Meeks thinks that "or later" is
"vital". He says that he trusts the FSF and thinks that others
should too, but beyond that, "the FSF is less of a risk than killing your
project through bureaucracy". One reason that companies want to be
able to get proprietary licenses to free software is so that "they
can get patent protection that isn't available to us", he said.
There is also the question of patent licenses, Meeks said.
Harmony agreements assign patent rights along with the other rights and if
the code is released under a permissive license (e.g. BSD), the patent
rights accumulated by the company don't necessarily flow back to those who receive the code. It would
be nice to have the community be in the same boat with respect to patents
as the other companies
that license the code, but that may not be true if the Harmony agreements
are used, he said. "Harmony makes it more complicated, not simpler", he said.
Patents were "debated vigorously" as part of the process of
coming up with the Harmony agreements, Shuttleworth said. He was a
"tangential observer" of the process, he said, but did see
that the patent issue was discussed at length. The problem is that you
have to be careful what you ask for inbound with respect to patents if you
want to be able to use various kinds of outbound licenses, he said.
Patents are "a very serious problem", but the Harmony
agreements just give the ability to ship the code with a license to any
patents held by the contributor that read on the contribution.
The GPLv3 was designed to ensure that everyone is getting the same patent
rights, Kuhn said. Part of the reason for the update was because the GPLv2
was not as good in that regard, he said.
Dead developers and companies
The problem of the "dead developer" is one place where some
kind of copyright agreement can help, Sandler said. If there is a need to
relicense a project where one or more copyright holders is dead or
otherwise unreachable, what can be done if there is no agreement, she
asked. Meeks said that the "dead company argument is also
interesting". There are more developers than companies, so maybe
they die more often, but we have already seen problems coming from dead
companies, he said. "Plus" licenses can help there, he said.
Meeks also said that he was happy to hear that Canonical was using plus
licenses, but Shuttleworth was quick to point out that was not the
case. Canonical's preferred license is GPLv3, though it will contribute to
with plus licenses, he said.
We have seen problems with dead companies that have resulted in other
companies coming in to "pick at the carcass", Kuhn said.
Sometimes part of that carcass is free software projects where the new
company then changes all of the policies going forward, he said. The dead
developer situation is very different as there are very personal decisions
that developers may want to make regarding their code after they are gone.
That could include appointing someone to make those decisions—as Kuhn
has done—after they pass. Shuttleworth was skeptical about relying on
people to get their affairs in order before they go.
The panel wrapped up with a short discussion of competition, with
Shuttleworth saying that the free software world fears competition and
tries to prevent anyone from getting a competitive advantage. Meeks
believes that there is
already enough competition from the proprietary software companies, so
adding it into the free software community is not needed. Kuhn's position is
that the "ecosystem that has worked so far is a copyleft
ecosystem" without any kind of copyright agreement.
While interesting, the panel was given too short of a slot, so that it felt
very compressed. In addition, there was no opportunity for the audience to
ask questions, which is something that Kuhn noted as one of the most
important parts of any kind of panel discussion. The balance on the panel
also seemed a bit skewed, though, as noted above, that may roughly reflect
the community's opinion on the matter. A neutral third member of the
panel, replacing either Meeks or Kuhn, might have been better, though
Sandler did a nice job of steering things as a neutral moderator. In some
ways like the topic itself, the panel was quite interesting, but vaguely
unsatisfying. There are certainly no easy answers, and we will likely
struggle with it for many years to come.
[ I would like to thank the GNOME Foundation and KDE e.V. for their
funding my trip to the Desktop Summit. ]
to post comments)