Over the years, I have heard people from the Software Freedom Conservancy (SFC) say many times that most free-software license violations are not intentional. Indeed, the SFC's principles of community-oriented enforcement say that "most GPL violations occur by mistake, without ill will". I've always had some difficulty in believing that; after all, how hard can it be to create a GPL repository on GitHub and sync the code into it? But it is also said that managing programmers is like herding cats. It was therefore interesting to hear a large-scale cat herder talk at FOSDEM 2018 about the license violations that occurred in their organization and what he and his colleagues did about it.

Andreas Schreiber works for DLR, Germany's national aeronautics and space research center. DLR has some 8,000 employees across 40 institutions at 20 sites; of those, around 1,500 work on software development. Schreiber said its annual budget of some €150M for software development makes DLR one of the largest software developers in Germany. However, it is primarily an academic institution. Unlike many large commercial software developers, its software is largely written by people employed because of their expertise in such fields as aeronautics and space transportation, who have no formal computer science background, and often no formal training in software development.

Many different technologies and over 30 programming languages are routinely used at DLR. Much free software is both used and created there, under many different licenses, and that, said Schreiber, is where the problems come in. Because of the academic nature of DLR, an overview of all existing software development projects is simply not possible. Development often takes place with external partners and the resulting software is frequently released to the world at large under a free license.

In the past, DLR developers have mistakenly released software with license compatibility problems or unintentionally failed to honor license conditions. In one high-profile case, the German government gave some of DLR's software to another country, assuring the recipient that the software was open-source, when this was not in fact true. A journalist from Der Spiegel picked up on this, and much effort was required to rectify the situation. Although DLR's software licensing problems are not quite as visible or expensive as its hardware problems — which Schreiber illustrated with a picture of a rocket exploding — they were nevertheless visible at a high level inside DLR. In 2012, the CIO sent around a letter reminding everyone that free-software license conditions were not optional and must be honored. Nevertheless, developers who were not trained in the minutiae of free licenses often struggled to understand their obligations, especially when more than one license was involved.

So Schreiber's group at DLR developed a four-hour training program on the legal issues surrounding free software, which could be attended by any DLR employee that wanted to do so. It is given by two people, one a DLR software engineer and the other a legal expert from DLR's technology marketing department. His group has run this training once a year from 2012 onward, and each year between 10 and 30 people have signed up.

The group has also produced a paper brochure, which was commissioned from a law firm in Berlin. This brochure contains information about one's rights and obligations with respect to free software, for both unmodified and modified versions of the software. It includes the requirements of the licenses in common use at DLR, including the GPL, Apache, BSD, and MIT licenses, in an easy-to-honor checklist form. Furthermore, the brochure contains a decision tree for choosing a project license, depending on the project's requirements for strong, weak, or no copyleft, and whether special conditions are required. It is currently available only in German, but DLR is working on an English-language version that it intends to release under a Creative Commons license sometime in 2018.

DLR found that encouraging knowledge exchange between people inside the organization who had experience with licensing issues was important. DLR has an internal tradition of wikis and the infrastructure to support that, so Schreiber's group put up an "Open Source" wiki. There is also an internal tradition of WAWs (Wissens Austausch Workshops, or Knowledge Exchange Workshops) which are run on subjects as varied as visualization of huge data sets, autonomous flying, software engineering, and photonic systems. So Schreiber's group ran several DLR.Open WAWs, each lasting two days and limited to 60 participants; there are short lectures, lightning talks, and small-group breakout sessions. Last year all participants had to produce a poster about themselves and their work at DLR, examples of which are shown in the slides [PDF], though the main thing learned from some posters was that there are people at DLR with "very strange minds" and it's quite hard to follow their thinking, Schreiber said, to laughter.

What you can't measure, you don't really know. DLR is an academic institution, so Schreiber's group systematically tried to measure how useful these free-license initiatives were. In addition to receiving positive feedback, his group also learned that, although much free software is used at DLR, a lot of that was open libraries and tools brought in from outside. Most of the software developed at DLR is still not being published freely. The group also found that there was strong interest in freeing internally-developed software.

At the same time, though, there was criticism of the idea. Although some worried that revenue-generating opportunities were being missed, one of the big obstacles was the lack of a formal process definition for employees to follow in order to publish their work as free software and the demotivating effect of the extra time required to do it. Schreiber's group has since created the missing process definition. It also created a single internal email address for all free-software licensing queries, which gets questions on topics such as choosing a free license, best practices for one's own free-software project, and how to migrate away from commercial software. Some of these the group answers internally; sometimes it acts as an information exchange, by putting the employee in touch with other internal resources such as the legal or technology marketing departments.

The group has also had three licenses formally approved by the legal department. Any employee can use any of these licenses on code they create in the course of work with no further oversight. The three licenses are BSD, Apache v2, and Eclipse Public License v1. Interestingly, none of these is a strong copyleft license, and one of them (the EPL) is incompatible with the GPL.

In answer to a question from the floor, Schreiber said the absence of a strong copyleft license from the list was unintentional; those three are the licenses about which his group is most often asked. The list is not intended to be set in stone for all time, and he would be perfectly happy to add a strong copyleft license, most likely the GPL; it hasn't happened yet, though. In answer to another question, Schreiber said that there are DLR projects released under the GPL, and the AGPL, but that doing so currently requires the approval of both the legal department and the developer's manager. It would seem to me that adding a strong copyleft license to the list of pre-approved licenses is important and should be addressed soon.

Schreiber also noted that both NASA and ESA have developed their own open-source licenses, whereas DLR has deliberately chosen not to do that. Given widespread concerns about license proliferation, and that NASA's license is both non-free and GPL-incompatible, this seems a good decision. In addition, in response to a later question, Schreiber said his group has tried mandating licenses for DLR projects, but that just did not work in the DLR culture, where researchers are used to doing what they like, how they like. Imposing a single institutional license would have been difficult; instead, the group provides advice and support, it will even recommend if asked to, but it doesn't mandate.

In summary, Schreiber said the approach DLR took was to offer specific and relevant information to DLR employees, and then provide time and space for peer discussions and knowledge exchange. Only after all that has been done is it time to introduce any kind of formal process or directions from management. The lessons learned and procedures developed have been taken up by some other interested organizations, including the Helmholtz Association. If I were in an organization of anything like the complexity and mindset of DLR, I'd be paying a lot of attention to what Schreiber's group is doing, too.

[We would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Brussels for FOSDEM.]

Index entries for this article
GuestArticles	Yates, Tom
Conference	FOSDEM/2018