LWN.net Weekly Edition for August 18, 2016

GPL compliance suit against VMware dismissed

In a setback to the Christoph Hellwig's efforts to enforce the GPL on code that he wrote in the Linux kernel, his suit against VMware in Germany has been dismissed on procedural grounds. The court ruled that he had not provided enough specificity about the code he was claiming had been used by the company. The merits of the GPL and whether the two main parts of VMware's product constitute a derived work of the kernel were not even considered. There may be another chance for the court to do so, however, as Hellwig will appeal the dismissal.

The suit was announced by the Software Freedom Conservancy (SFC) back in March. SFC is funding the litigation, which revolves around VMware's ESXi virtualization product. ESXi has two pieces of interest here: the proprietary "vmkernel" that uses Linux code and drivers in an open source "vmklinux" module.

The source code for vmklinux unquestionably contains Hellwig's code and copyright notices. But vmklinux itself does comply with the GPLv2. The question then becomes: does combining vmklinux and vmkernel make the resulting executable a derivative work of the kernel? Hellwig argued that it does, but the court never even got to that point.

The court dismissed the suit on the grounds that "the materials submitted did not satisfy German evidence rules", Hellwig said on his blog. He provided links to the official ruling [PDF in German] and an unofficial English translation [PDF]. In that post, he announced his intention to appeal, and expressed his dismay that the main question of the case was never addressed:

The court chose not bring in an expert and relied on the filings made by Hellwig and VMware (which are not public, though they are referred to in the ruling). In Germany, the court decides whether expert testimony is required. Based on Hellwig's statement, it would seem that he and his legal team expected the court to do so in this case.

The judgment is split into two main parts: the "findings of fact", which is largely a restatement of the arguments both sides made in their filings, and the "reasons for the decision" that describes the problems the court found with Hellwig's evidence. The court decided that the suit was "admissible" even though Hellwig only held copyright on some portions of the kernel because he claimed "adapters copyright" on the changes that he made to parts of the kernel. The concept of "adapter's copyright" (or at least the term) appears to be specific to Germany, but the ruling makes it reasonably clear what is meant:

But, the fact that it is an admissible action does not mean that Hellwig is entitled to the injunction he seeks, unless his "pleading is sufficiently substantiated to establish the cause of action and whether the Plaintiff has proved where necessary [...] which parts of the Linux program he claims to have modified, and in what manner" That is the first of three tests (the others are establishing that his contributions meet the criteria for adapter's copyright and that VMware has in fact used that code) that are required to be met before the substantive questions about vmkernel and vmklinux can even be considered:

The evidence presented by Hellwig would seem to be files and other information that would be instantly recognizable by a kernel developer or many other members of the free-software community: Git repositories, tar files, git blame output, and so on. None of that information constitutes "an admissible pleading in court procedure", however. The problem seems to be that Hellwig did not directly and specifically show exactly which chunks of code in Linux were his and to link them to the corresponding chunks in vmklinux.

There were apparently three different facets of Hellwig's work on Linux that were part of the claims: his modifications to code throughout the kernel, his work on the SCSI subsystem starting in 2000, and his development of the radix tree code. For the changes to the overall kernel, the evidence presented was the publicly available Git repository of the kernel, which the court considered to be too broad. In addition, a CD containing the entire source code of Linux was submitted but it also lacked specifics:

There was also some git blame output submitted, which might serve to identify those with an adapter's copyright in the files, the court said, but it did not indicate where that code appeared in vmklinux, so it doesn't establish that the code was used by VMware. While there were statements that a full comparison had been made between vmklinux and the kernel, only some examples from that comparison were submitted. Furthermore, the two header files distributed with vmklinux that contain Hellwig's copyrights are not sufficient to show that he has an adapter's copyright in that code: "This cannot simply be assumed merely because the Defendant itself has named the Plaintiff as a possible modifier of Linux; instead, it must be established by the Plaintiff."

For the SCSI subsystem, Hellwig's filings are more specific, but still insufficient for the court. While he claimed to be one of the most active SCSI developers from 2000 to 2004, which involved "complex programming that merits protection", that claim does not provide enough information; "he needs to specifically name those programming achievements for which he seeks protection". The ruling also mentions that VMware had argued that only eight functions from the SCSI code submitted could be attributed to Hellwig's work and that Hellwig did not contest that argument. Furthermore:

The 19 patches to the SCSI hotplug functionality that were submitted were not tied to vmklinux, but also were not accompanied by a statement about how those contributions are complex enough for copyright protection:

For the radix tree work, the explanations offered in the filings evidently were not sufficient to convince the court that it should be covered by copyright. Radix trees are a data structure that are used in various places in the kernel, but the distinction between the code to implement them and the abstraction of the data structure was either not explicitly made or, perhaps, not understood by the court.

It seems clear that Hellwig's legal team did not anticipate the level of detail the court would require to establish the copyrights and where they were alleging that VMware was infringing them. The team also seems to have relied on the kind of evidence that would be compelling to a technical audience, but evidently was not precise enough for the court. For its part, VMware seems to have vigorously defended itself—if no code of Hellwig's can be shown to have been used by the company, clearly the whole argument disappears, thus the dismissal.

SFC also announced the appeal; in it, executive director Karen Sandler lamented that there is something of a mismatch in the resources each side has available to it:

The money expended by VMware could become a real issue if the appeal is not successful, as the court awarded VMware its costs when dismissing the case. That number is sure to be quite large at this point and will only grow through the appeals process.

The SFC also released a comparison of vmklinux and Hellwig's contributions to the kernel that was done by Bradley M. Kuhn. It shows considerable similarity between Hellwig's contributions and vmklinux. But, perhaps like what was filed with the court, it is a technical analysis, rather than a detailed, line-by-line annotation that the court seems to indicate that it wants.

Hopefully, the appeal is successful in at least getting past the procedural hurdles so that the court can rule on the more interesting (at least to the free-software community) part of the puzzle: whether vmklinux and vmkernel constitute a combined work that is derived from the kernel. Though it won't really set precedents either inside or outside of Germany, a ruling on that question would start to clarify some of the scope of the GPL, which will be helpful to both the community and those who might want to better understand all of the facets of where and how the license applies.

Comments (15 posted)

The GNOME Newcomers initiative

At GUADEC 2016 in Karlsruhe, Germany, Bastien Ilsø and Carlos Soriano reported on the revamped Newcomers section of the GNOME web site. The section is intended to draw in new users and developers and help them find their way around the project as well as to help them get the necessary development environment set up to begin contributing code.

The predecessor of the new outreach site was the "GNOME Love" section of the project's wiki (an Internet Archive capture of the page is available here). Conversations about replacing it began in 2014, Soriano said, although the work did not start in earnest until mid-2015. The name of the page was an obvious problem, he said: at best it gave no hint as to the content of the section; at worst it suggested the wrong thing entirely, like a "GNOME appreciation" project. But the team identified many other issues. The GNOME Love section assumed a lot of knowledge on the reader's part, including experience with Git, Bugzilla, patching tools, packaging, dependency management, and the GNOME build tool JHBuild.

Furthermore, the content was insufficient. JHBuild, he said, is a generic utility (even though it is optimized for building GNOME), so using it requires first setting up the correct build configuration. And the instructions on GNOME Love relied mainly on linking to existing tutorial and reference material from elsewhere, which made it hard to navigate—and potentially confusing, when those external resources got out-of-date. He noted that when talking to users asking for help, the first question a member of the GNOME team had to ask was "which guides have you been reading?" followed by "how far did you get in them?" Finally, the documentation tried to do too much in some regards, such as providing setup instructions for every major Linux distribution.

The rebranding work, Ilsø said, started by updating the name and visual iconography of the site. It then did away with the external links, replacing them with a four-step "how to get started" plan. The steps listed are "choose a project," "build the project," "find and solve a task," and "submit the patch." Each is addressed in its own page, using new documentation written for the purpose.

The "choose a project" page was deemed to be of particular importance, since it is the first step. The page highlights seven GNOME programs (chosen from a rotating list), with each project's section listing specific information about the code, one or more new-contributor mentors from the team, and the project's IRC channel. Each project also has a "Contribute" page in its own section of the GNOME wiki; Ilsø said that templates had been provided to ensure that every project could provide a standard set of information.

The "build the project" section was streamlined, focusing on just two distributions: the most recent releases each of Fedora and Ubuntu. The "find and solve a task" page introduces the development tools and issue-tracking, while the "submit the patch" page explains explains a basic Git-based workflow.

In general, Ilsø and Soriano said, the revamped guide has been well received, but it still needs further work. Partly this will involve updating the instructions to support the Builder IDE and the new Flatpak sandboxed-application package format. Working on a Flatpak will be far simpler and require less setup for new users. The Newcomers page also still needs to be linked in from several other sections of the GNOME web site, in particular from other "entry points" like the various engagement, documentation, and translation pages. It could also be expanded to better explain how the different components of GNOME fit together.

But there will also need to be changes made to the developer documentation hosted at developer.gnome.org, which exists outside of the Newcomers section. Like the old GNOME Love section, that site contains scores of documentation pages that vary considerably in how up-to-date they are. Ilsø noted that he knows how old the "introduction to GTK+" material is, because he rewrote it himself more than a year and a half ago, and it has not changed since. But the team has a plan in place; it met at FOSDEM 2016 and held a hackfest to scope out the necessary improvements to the documentation. Allan Day has also helped by developing mock-ups of how to reorganize the material.

Finally, the speakers reminded the audience that even the rewritten material still assumes that the newcomer involved has experience with GNOME and with desktop Linux in general. While likely to be true, it would be better to provide newcomer information that was accessible to a broader audience. But developing that material might be best done in conjunction with downstream distributions and upstream software projects, they added, given the breadth of the information it could encompass.

Audience members asked what individual project teams should do to better coordinate with the Newcomers section. Ilsø and Soriano replied that each project listed on the "find a project" page had to have an official mentor and ensure that there are also bugs in the official bug tracker that are tagged as being for newcomers.

Attracting new developers always takes work. Large-scale development efforts like GNOME can have an even more difficult task in helping to get potential new contributors oriented, given the size and complexity of the project. While work remains to be done, the revitalized Newcomers section is a marked improvement over the old GNOME Love site.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2016.]

Comments (none posted)

Flowgraphs in GTK+

At GUADEC 2016 in Karlsruhe, Germany, Daniel "grindhold" Brendle presented his work developing a new library and widget set that will allow GTK+ applications to implement flowgraphs in a standard manner. The widget set would enable applications to provide interactive widgets for linking filters and other block-oriented components—a type of interface many applications currently need to reinvent on their own.

Flowgraphs, Brendle explained, are a general-purpose diagramming technique that many people will recognize from textbooks and other printed matter. They show how objects, information, and signals flow through some sort of process. Biology textbooks use them to illustrate circulation in the body, technical manuals use them to show how a manufacturing process runs, and so on. In software, he said, they are most familiar as the node-and-pipe diagrams that illustrate signal processing or data filtering.

But every open-source project that includes a flowgraph component in its interface seems to reinvent it from scratch, resulting in considerable duplication of effort. He showed several examples: GNU Radio, which uses flowgraphs to connect audio-processing components, Conduit, which uses them to link data sources to data sinks for synchronization, and the computer-aided design (CAD) program Antimony, which uses them to model the construction of objects.

The most familiar implementation, he said, is Blender's node editor, so he took an in-depth look at how it is implemented and what features it offers. The node editor lets Blender users construct a rendering pipeline, specifying various lighting, shading, and reflection filters that are executed on the objects in a rendering job. He identified six key features of Blender's node editor that he wanted to define as the basis for a GTK+ flowgraph library:

1. Each node has input points and output points that can be connected to link nodes together (in a directed acyclic graph).
2. The I/O points and pipe connections are displayed in different colors to indicate the data type used.
3. The connections between nodes are created by the user on the canvas.
4. Each node can optionally display editable parameters for the user to adjust.
5. The program's UI provides warnings for various problem states (such as trying to connect type-incompatible I/O points or creating circular connections between nodes).
6. Special null values are supported for parameters.

Brendle decided to implement his own flowgraph library, since an examination of the existing options revealed that most of them would be unsuitable for adaptation into a general-purpose tool. They are often tied directly into the logic of the application in question, he said, and there were none that hooked into other GTK+ services like the theming engine. Consequently, the flowgraph components always look different from the rest of the user interface.

His first attempt at a flowgraph implementation was a library called libgtkflow, which he started in May 2015. It is written in Vala, GNOME's high-level object-oriented language that compiles to standard C. Subsequently, Daniel Espinosa joined him in the project, reworking the build system and simplifying the API. They eventually decided that the project should be split into two libraries—one to handle the abstract flowgraph model and one to provide the onscreen widgets (although both are still hosted at the same GitHub repository as the original monolithic implementation).

The abstraction library is called GFlow. It provides classes to represent the nodes and the I/O points (which are called "sink" and "source" docks, names borrowed from the similar concepts already used in GStreamer).

The UI sub-library is called GtkFlow. At present, it provides screen-ready implementations of NodeRenderer and DockRenderer elements. The node elements can contain other GTK+ widgets to display parameters, labels, and so on. There is also a NodeView widget designed to display a complete graph. Both GFlow and GtkFlow support GObject Introspection, so they are accessible from any language with GTK+ bindings, including Python, Perl, Lua, and JavaScript.

He added that one important feature planned for future releases is to convert the current NodeRenderer and DockRenderer implementations into generic interfaces that developers can use to create their own customized nodes. For example, someone writing an Arduino or Raspberry Pi simulator might want the Node widget to visually resemble the wiring headers of those devices, rather than a generic GTK+ rectangle.

Looking to the future, Brendle discussed where the library needs further work. The code on GitHub currently runs only in GTK+ 3.20, so fixing compatibility with other recent releases is vital. The NodeView widget only supports selecting and dragging one Node at a time, which needs changing, and the pipe connectors do not yet have all of the features in the original list culled from Blender's implementation. Brendle said that the pipe connectors will likely need to become their own widget type in order to support more "intelligent" features like detecting cycles or other errors.

He also speculated that the GFlow nodes might need to support recursion (so that, for example, an entire flowgraph could be encapsulated into a node, simplifying the construction and display of multi-level graphs), and that the widget set might need to be extended to support right-to-left languages. As it stands today, input docks are hard coded to always be on the left and output docks on the right, which mirrors left-to-right writing systems.

He closed the talk by speculating on what applications might benefit from having a flowgraph implementation in GTK+. The obvious choice is media-processing programs like the video editor Pitivi and the PulseAudio utility Pavucontrol. But there are surely others, he said. "I want you to be creative and do better than me" at making something interesting with the library, he concluded.

It is hard to say when or even if libgtkflow might make it into GTK+ proper. There seemed to be interest from others in the work done by Brendle and Espinosa, though, which is a good sign. If progress continues, application developers could soon have an important new tool available to express complex interactions in their GTK+ interfaces.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2016.]

Comments (4 posted)