Issues of when and how to enforce free-software licenses, and who should do it, have been on some people's minds recently, and Richard Fontana from Red Hat decided to continue the discussion at FOSDEM. This was a fairly lawyerly talk; phrases like "alleged violation" and "I think that..." were scattered throughout it to a degree not normally found in talks by developers. This is because Fontana is a lawyer at Red Hat, and he was talking about ideas which, while they are not official Red Hat positions, were developed following discussions between him and other members of the legal team at Red Hat.

To his mind, GPL enforcement has always been an important element of free-software law; not that we should all be doing it, all the time, but like it or not, litigation is part of a legal system. Awareness of its possibility, however, was making some Red Hat customers and partners worried about the prospect. There has not, in fact, been much actual litigation around free-software licenses — certainly not compared to the amount of litigation software companies are capable of generating in the normal course of business — thus Fontana felt their fears were unreasonable.

Nevertheless, customers are customers, and if they're afraid of legal issues, it falls to Red Hat's legal department to try to mitigate those fears. Worse, in recent times things have been getting more interesting on the free-software litigation front. Commercial entities such as Versata and XimpleWare have been filing suit; the Software Freedom Conservancy (SFC) has been active, including in Hellwig v. VMware; and Patrick McHardy has been bringing suits in Germany alleging GPL violations. As Fontana noted, however, the German civil litigation system is quite opaque; since no one who knows what McHardy is doing seems inclined to talk about it, the rest of us don't know much.

The SFC tried to pour oil on the waters in the form of its Principles of Community-Oriented GPL Enforcement, published in conjunction with the Free Software Foundation. The principles were good, but they still didn't calm Red Hat's nervous customers. So Fontana and colleagues decided that it was time for a big company with lots of GPL involvement, by which they meant Red Hat, to join the debate. They want to emphasize that there is a place for GPL enforcement, and that a good starting point for this is the SFC's principles.

Fontana and colleagues, however, are by no means in full agreement with those principles. The SFC's primary objective is full compliance with the GPL; Fontana and his colleagues say that maximum compliance is not the most important goal. The SFC says that confidentiality can increase receptiveness and responsiveness; but Fontana said that the value of confidentiality should not be overstated, and that more details of enforcement cases should be disclosed, including those that have not gone to litigation. The preamble to the SFC's principles says that copyleft uses copyright to defend users' freedoms; Fontana recognizes the importance of those, but for him, the primary objective of enforcement is to promote collaboration and participation in the creation and use of free software by making a level playing field for all participants.

So Fontana's preference is that enforcement should be:

Predictable: neither arbitrary nor capricious

Not for gain: enforcement for personal or financial gain causes cynicism about the GPL and compliance with it

Transparent: we need disclosure of non-profit organizations' donor relationships and how it is decided who and how to sue; interestingly, there was no suggestion that commercial organizations could experience similar conflicts of interest in their funding

Without unresolved conflicts of interest: the main concern with these is divided loyalties — consider the position of a company employee who is also personally involved with a free software project when another project developer decides to sue the company

Fontana again tried to take the focus away from litigation. He feels that noncompliance is mostly an awareness problem. Most violators would likely do the right thing if only someone would tell them what that was; he shares the SFC's position on this. Red Hat addresses this by actively trying to help organizations, one-on-one, to come into compliance. He feels that litigation really should be a last resort, and believes he's even stronger on this than the SFC. Litigation is very expensive, locality-specific, and its outcomes can be very bad; it also moves power from developers to judges, which is not really what the community wants. Furthermore, all software that uses a particular version of the GPL uses exactly the same license: it only takes one court to make a bad decision, and an entire community will be affected by it.

There are occasionally times when even Fontana would accept that litigation was justified. One is when there's no strong disagreement on license interpretation; the infringer is simply saying "yes, we know we're doing wrong, but we don't think you can stop us". Another is defensive litigation; someone sues you for something and you countersue for a GPL violation as a quick way to stop the original suit. Twin Peaks v. Red Hat is a clear example of this.

So Fontana is wondering whether the community would benefit from a move toward a community-wide, generally-acceptable and accepted set of principles on when and how the GPL is likely to be enforced. This would be done in the hope that something so widely agreed upon could be used by courts to assist them in ruling when litigation ensues. A visibly irked Bradley Kuhn then asked from the floor why Red Hat was, with no notice, trying to preempt the SFC's principles with a set of its own. Fontana noted that while he is open to engagement on the principles through the SFC's mechanisms, he is less sure whether the view is shared by his colleagues. As he had said, nothing in the talk represented Red Hat's views, but it might be thought that if there were a corporate position on this, the view would then be clearly uniform across the legal department. Fontana also noted that Kuhn had been on the panel that approved his talk, so perhaps it should not have been the surprise that Kuhn was suggesting.

Fontana's talk can now be seen in its entirety from the FOSDEM page on his talk. If I understand Fontana correctly, the core issue is that a set of widely-acceptable and widely-subscribed principles for GPL enforcement would be useful both to Red Hat's commercial clients and to courts that have to rule on the GPL. The SFC's principles are an excellent starting point for creating such a set, but they might not be completely acceptable to Red Hat as they stand. If the SFC wishes to maximize the number of subscribing organizations, it may need to be open to some significant changes. That by no means requires the SFC to allow any such changes, but many sets of slightly-different principles may prove less useful to the community in the long run than one less-perfect but more-widely-accepted set.

[Thanks to the Linux Foundation, LWN's travel sponsor, for making this article possible.]

Comments (9 posted)

I was initially afraid that a talk about conflict management would be touchy-feely to the point of uselessness, but found that every time Deb Nicholson described a scenario, I could remember a project that I'd been involved in where just such a problem had arisen. In the end, her "Handle conflict like a boss" presentation may turn out to have been one of the more rewarding talks I heard at FOSDEM 2017.

Nicholson's first contention was that conflict happens because some people are missing some information. She related a story about a shared apartment where the resident who was responsible for dividing up the electricity bill was getting quite annoyed at the resident who had got behind on his share, until Nicholson pointed out that the latter resident was away at his grandmother's funeral. Instantly, the person who'd been angry was calm and concerned, through no change other than coming into possession of all the facts. Conflict is natural, said Nicholson, but it doesn't have to be the end of the world.

Sometimes, mismatched information causes problems. She showed a slide with a sign from a local "boat and dog wash", and asked us to think about the reaction of the dog washers to a boat washer who announced they'd made things much more efficient by the introduction of a highly-caustic soap that cleaned boats in half the time. The dog washers will be appalled, and say so, and the boat washer in turn may be quite hurt that his or her work in optimizing the wash is unappreciated. Someone who can see the mismatch of information, and encourage all sides to see the other people's point of view, can defuse the situation.

Passion itself can become a problem; that same motor that drives us to do these amazing things can drive us straight onto rocks, as people get caught up in the enthusiasm of the moment and lose sight of the goal. Nicholson put up an amusing slide of a Scottish festival that filled up with Kate Bush impersonators; participants decided to try for a world record. Sadly, everyone was having such a good time that they forgot to have anyone count them, so no record resulted.

Sense of identity can be a minefield, especially when tied up in something task-oriented rather than goal-oriented. It's all very well to have a project to upgrade the bug tracking system to one that doesn't require hours of volunteer work to keep it ticking along, but the person who's known throughout the community as the volunteer who keeps the bug tracking system running may get upset if they're not fully invested in the upgrade.

Some people are just conflict lovers. But if conflict in your project isn't checked, everyone else will leave. Sometimes, this or other conflicts can't easily be stopped, and then it's time to weigh your investment and consider whether you should move on, for your own sanity. As Sarah Sharp once said "there are many FOSS projects, but only one me".

It can help to be aware that there are generally three ways people handle conflict: avoidance, which can lead to festering and eventual disconnection; accommodation, which can lead to the adoption of false or unworkable middles out of a desire to make the conflict go away; and assertion or aggression, where behavior degrades to provoke responses. So this said, how should we deal with conflict? Nicholson noted that kudzu has a reputation in the southern US for taking over the world; in fact, it just grows really well on clear-cut road verges. But that's all that most people see, so they get a mistaken impression of what's really going on. She reiterated that more information is generally the best way to help; often the information that some people, usually newer arrivals, are missing is the historical information. That is particularly important because it tends to explain why we do things the way we do them.

When trying to help, note that people respond to things you can't see: motivations from their employer, life goals, and the like. Ask other people about their motivations, to better understand them. Fear can often be a driver, particularly fear of change. Since none of us likes to admit that fear, finding it out may require private, one-on-one conversations. Sometimes, discussing the alternative scenarios can help (what's the worst that could happen?), but sometimes you have to accept that an idea is just the right one at the wrong time, or vice-versa.

So who's doing this work in your project? Nicholson was clear that it shouldn't just be left to volunteers, and it shouldn't be assumed to be women's work. If you're anywhere near the top of a project, you should be planning for future conflict, right now; when you do, assume the best of people, and set parameters for disagreement. Of those, a vital one is to avoid ad hominem attacks: they are very hard to come back from. Finally, set an example; if you can't walk your walk, it's unlikely anyone else will bother to try.

This whole talk was painful enough to hear that I had to stop myself from wincing on multiple occasions. It's not stuff I deal well with; but I suspect that makes me the target audience; I shall be trying hard to keep it in mind the next few times things get heated.

[Thanks to the Linux Foundation, LWN's travel sponsor, for making this article possible.]

Comments (6 posted)