A GPL-enforcement update

While there is a lot of software distributed under the terms of the GNU General Public License, there is relatively little enforcement of the terms of that license and, it seems, even less discussion of enforcement in general. The organizers of linux.conf.au have never shied away from such topics, though, so Karen Sandler's enforcement update during the linux.conf.au 2018 Kernel Miniconf fit right in. The picture she painted includes a number of challenges for the GPL and the communities based on it, but there are some bright spots as well.

Sandler is the executive director of the Software Freedom Conservancy (SFC), which is occupied with a number of activities beyond license enforcement. SFC is the home of the Outreachy project, for example, and serves as an umbrella organization for a long list of free-software projects. The enforcement efforts were the focus of this discussion, though.

She started with an overview of the GPL and how it works. Due to the way the kernel project came about, many of the developers own the copyrights for at least some of the work they have contributed. The SFC represents a group of those developers that came together and asked for help in the enforcement of their copyrights. This work is always done with an eye toward bringing about compliance and helping the free-software ecosystem in general. SFC is a tiny charity with limited resources, so it has to be strategic with its actions. The work is "fascinating" and "so fun", though she acknowledged that being a lawyer may distort her view of the world a bit.

A number of exciting things have happened in the last year, including the release of the enforcement statement signed by a long list of kernel developers — and many of their employers. This statement was somewhat motivated by a specific kernel developer [she was referring to Patrick McHardy] who has been launching aggressive enforcement actions in a way that she described as "not very community-oriented". In reaction, the Linux Foundation's Technical Advisory Board came together to try to clarify how the community saw enforcement and to distinguish that vision from what McHardy was doing.

The statement codifies a practice that the SFC has used for years: applying the termination conditions from version 3 of the GPL to software licensed under version 2 only. The GPLv3 language makes it clear that violators can restore their license to the software by coming back into compliance with the terms of the license. This change "makes sense", she said; inadvertent violations happen all the time, and mistakes should not carry such severe consequences. With nicer terms, today's violator can more easily become tomorrow's contributor.

Right after that happened, four companies (Facebook, Google, IBM, and Red Hat) came out in favor of the new terms; they issued a statement applying those terms to all of their GPLv2-licensed software.

Another interesting event was the DJI Drones affair. Jon Sawyer tweeted that, after a couple of unsuccessful attempts to get DJI to release the source for the GPL-licensed software it ships, he had created and published a root exploit for the company's drones in retaliation. That brought a lot of attention to GPL compliance and just how frustrated developers get when their copyrights are not respected. This sort of action doesn't fit within the SFC's enforcement principles, but she recognized that others may see things differently.

Savvy violators and powerful vendors

Enforcement activities within the SFC are slowly chugging along. The SFC is encountering a lot of delay tactics by companies; the desire is to give companies the time they need to comply, but a lot of these companies are clearly just stringing things along. The effort to get VMware into compliance went on for over four years before the lawsuit was filed, for example. It is important to give companies time to look at the situation and come into compliance, but it seems that some have figured out that they can use that time to delay the whole process.

There has also been an increase in "savvy violators". It used to be that most violations were inadvertent — the companies involved simply didn't understand what their obligations were. Bringing these companies into compliance was a relatively easy task. Now, there are many companies that "know exactly what they are doing". They have concluded that, since there are so few lawsuits around GPL compliance, they can get away with ignoring the GPL. This has been a significant change over the last five years.

When asked about these savvy violators, Sandler expanded a bit. Many companies have had their lawyers do a "tight legal analysis" describing just what the company can get away with. That gives product managers a tool; they think that they can gain an edge by holding back as much as possible until the product reaches its end of life. Technologists within such companies should make more of a fuss internally about such practices, she said.

Another problem is the "powerful vendor". In many cases, violations originate with a particular vendor, and the companies that buy from that vendor are too worried about damaging the vendor relationship to push for compliance. The company marketing the final product looks like the violator, but it is really a victim of the upstream vendor's behavior. This company has no ability to fix the violation itself, and is afraid to work to get the upstream vendor to comply. The SFC has been trying to come up with creative solutions to this problem. One might be to get the downstream vendor to sign a statement to the effect that it has not received the necessary source from the upstream vendor; the SFC would then not pursue enforcement activities against that company.

The increasing interest in security is having a helpful effect instead. It has become relatively easy to convince corporate lawyers that their company needs to obtain the full source code from all vendors so that it will be in a position to deal with any security issues that may arise.

One other ongoing problem is proprietary kernel modules. The SFC has even seen companies patching EXPORT_SYMBOL_GPL() to get the kernel to accept their non-GPL modules, a development Sandler described as "fascinating, shocking, and deeply upsetting".

Copyright retention

The prepared part of the presentation ended with a shift to the topic of individual copyrights. It's a common pattern in our community that projects are started by individuals who naturally own the copyrights on the work they create. The Linux kernel started this way, and it led to an interesting license dynamic, since the individuals involved retained a great deal of influence over the direction of the project.

In a successful project like the kernel, the amount of work done by companies grows over time; this is a good thing. But it does lead to an increase in the amount of copyright in the code that is owned by companies. Much of the success found by the Linux kernel has to do with its origin in copyleft, which has enabled a "beautiful balancing act" with many people and companies collaborating to make the kernel better. As we shift to a situations where companies have more control, that balance can be lost.

Free software works well because the community is in control, but if we do not work to keep that control, we'll cede a lot of our power to companies. One of the great things about being a kernel developer is the ability to go from one company to another and do the same work, or something close to it. Developers are in control and they get to work on what they love; that is possible because the GPL is a real equalizer. Without compliance, we'll lose that benefit, and the kernel will become less special. We may not see the kind of collaboration we've had in the past.

To try to head that off, the SFC has been encouraging developers to negotiate to be able to keep their copyrights in the work they do. There seems to be an increase in the number of companies that are allowing retention of copyrights, she said; as the practice grows, it may become truly common as companies use it as a recruitment tool.

Strong copyleft is in the industry's best interest, she said, but companies driven by short-term interests often see things differently. That has made it hard to find places to have discussions about topics like copyleft and copyright retention. One of the things that makes LCA special, she concluded, is that it is still a space where we can talk about these issues.

Questions

A member of the audience asked about whether developers should bequeath their copyrights in their wills. That turns out to be hard to do in many jurisdictions; it may require an appraisal of the value of the copyrights and may cause the beneficiaries to have to pay taxes. A better way is to set up a trust that can hold and manage those copyrights; this can be done while the developer is still alive.

Another person asked: is there value in reaching out to universities? Sandler agreed that there is; we in the community used to spend a lot of time at universities, she said, but that practice has mostly stopped. It would be a good thing to resume. Projects like Outreachy are helpful in this regard.

The final question was asked by Matthew Wilcox, who noted that he worked for LinuxCare once upon a time and has no idea where the copyrights in his work have ended up. Is there any initiative out there pursuing the copyrights held by zombie companies? Some of those copyrights could probably be obtained cheaply. Sandler responded that the idea is interesting but would require some thought. The SFC puts a lot of effort into ensuring that its actions reflect the wishes of its community. Picking up these copyrights could provide a stronger voice in negotiations, but could also look a bit like a troll attack. It could give the appearance of acting in bad faith. On the other hand, acquiring those copyrights would keep them out of the hands of others who might try to exploit them; it is something requiring further thought.

[Your editor thanks the Linux Foundation and linux.conf.au for assisting with his travel to the event.]

Index entries for this article
Conference	linux.conf.au/2018

---

to post comments