Desktop Summit: Copyright assignments

We're bad at marketing

We can admit it, marketing is not our strong suit. Our strength is writing the kind of articles that developers, administrators, and free-software supporters depend on to know what is going on in the Linux world. Please subscribe today to help us keep doing that, and so we don’t have to get good at marketing.

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 opposition camp.

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 position.

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 released under.

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.

Monopolies

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"

Shuttleworth 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 to 300 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.

Or later

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 their control.

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.

Patent concerns

There is also the question of patent licenses, Meeks said. The 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 projects 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 assistance in funding my trip to the Desktop Summit. ]