FSF Compliance Lab online meeting addresses license questions

The Free Software Foundation’s (FSF) Free Software Licensing and Compliance Lab held a public question and answer session in an IRC meeting last night. The meeting was conducted by Brett Smith, the licensing compliance engineer at the FSF. Smith began by addressing some of the recent FUD surrounding the GPLv3 license, then moved on to answering some of the questions and misconceptions regarding it.

Smith began proceedings by introducing himself as the person who deals with any license-related issues at the FSF. Helping him were Joshua Gay and John Sullivan, campaign managers with the FSF. Sullivan speaks for FSF on digital restrictions management (DRM), proprietary licensing, the FSF’s Defective by Design campaign, and more. He looked over the questions being put forth by people in the #gplv3 channel and forwarded them to Smith, who answered them in the #gplv3-meeting channel, both on the Freenode IRC network.

The first issue Smith addressed was the Evans Data survey that claims very low rates of GPLv3 adoption — contrary to our recent article in which the FSF and Palamida, a company that advises customers on issues that surround free and open software (FOSS), paint a different picture. “Different people,” said Smith in the meeting, “want to benchmark GPLv3’s success in different ways. Some people want to do it by the number of projects who have adopted it. Others want to measure the number of projects that intend to adopt.”

Smith says that since the survey doesn’t say what projects the developers queried by Evans are working on, the survey tells you “basically nothing…. Maybe they all work on one of the BSD distributions, or Apache projects. If that’s the case, it shouldn’t come as a surprise to anyone that they have no plans to use GPLv3. It would be more interesting to poll people already working on GPLed projects, but even that wouldn’t necessarily reveal the whole story. Some projects probably intend to upgrade, but simply won’t get around to it until they do another major release. Others might be waiting for a library that they use to upgrade — I know that this is the case for a handful of KDE programs at least, for example, since Qt is unfortunately released under GPLv2 only.”

Smith, sensing the opportunity, was quick to ding a technology columnist who has criticized FSF in the past. “Really, I think the best benchmark for GPLv3’s success might be the fact that John Dvorak saw fit to pan it in a recent editorial.”

The questions

The people in attendance put forward a host of questions ranging from inquiries about the GPLv3 adoption metrics to section 11 of GPLv3 (Patents) to the additional terms as described in Section 7.

Smith was then asked whether the FSF had any GPLv3 adoption metrics available. “We’re keeping track of that information internally as part of the Free Software Directory. Licensing information is available there, and we’re hoping to make that more readily available in the future, so it’s easy to see who’s adopted the new license. Right now, at least, you can search the Directory by license, which is helpful. But adoption isn’t the be-all end-all metric for the license’s success. We judge the license primarily by how well it protects freedom — and right now, it’s the best license out there in that regard. And between the adoption numbers we do have, and the interest that we’re seeing through channels like questions to the Compliance Lab, we’re happy with the way things are going.”

When asked if the FSF believed that anti-Free Software companies are behind all the FUD, Smith said, “I don’t personally have any opinions about whether this is part of a coordinated effort. If I had to take a guess I’d say it’s probably one of those things where there’s no centralized effort, per se, but people feel compelled to speak out for various reasons. At any rate, the best strategy with FUD is to spread as much of it as you can, as far as you can. So, I think it’s targeting basically everyone.

“I think part of the reason FUD is so insidious is that the people who know it’s FUD tend to just dismiss it out of hand. Which is generally the right reaction, but it can mean that people who don’t know better don’t hear a response. That’s why the Compliance Lab has been working to raise awareness about this, and we’ve asked people to let us know when they see this kind of misinformation out there, so we can address it.”

On the issue of patents and patent protection as described in Section 11 of GPLv3, Smith said, “The GPL deals with patents primarily to make sure that people don’t use patent threats to make the software non-free. Making sure that everybody who ever gets the software has a patent license is a good way to do that, of course, but it’s not the only option. The law is not a binary thing where you’re either in trouble or you’re not. It’s more of a spectrum thing: if you do thing X, how risky is that? And there are different kinds of risk: how likely are you to get in trouble, etc. With patents, generally the risk is that you’ll be sued for patent infringement.”

Smith then explained the purpose of Section 11, saying that “different distributions have different attitudes about how to deal with particular patents, or patent threats. So, allowing patent licensees to make the source available to the public, as Section 11 does, causes a couple of things to happen. First, it means that the source will get out there. If the original patent licensee didn’t make source available like this, it’s possible that *their* recipients may be afraid to distribute the software further. So with this option, at least we now effectively have the source in the hands of every free software coder in the world. This creates a second happy side effect: it would be possible for such developers to argue in court that they at least have an implicit patent license, since they received the software *directly* from the patent licensee. It may not be a bulletproof argument, but it’s a lot easier to make when you’re only one step removed from the patent holder instead of four or five steps away. Also, it may enable coders to merely work around the patent. For example, development could continue in a country where the patent, or an equivalent, wasn’t in force. Or developers could try to find some other way of doing the same task that wasn’t patented. They would still benefit from the original code. For example, if the program was a video player, and the video codec was patented, developers could still use the entire UI and other subsystems, and simply hack it to play Ogg Theora instead. So, this option may not provide absolute protection from patents for every individual developer, but that’s okay, because that’s not the goal. The goal is to make sure the software stays free. And we think that as long as we can get the code into the hands of developers worldwide, that’ll happen.”

Smith also explained how the incompatibility between GPLv2 and GPLv3 doesn’t rule out any interaction between differently licensed programs, since “there have always been channels where it’s legally permissible for GPLed projects to interact with proprietary software. You can use those same channels to interact between GPLv2 and GPLv3. The most straightforward example would be the system() call — it’s okay if a GPLv3 program uses system() to invoke a proprietary program, or a GPLv2 program. But those sorts of ‘arms length’ ways of communicating are your only real options.”

Smith next responded to my question about Section 7 of GPLv3 (additional rights), as the language seems to suggest that downstream users can remove the additional terms added by the developer. If this were the case, what would be the point of allowing the developer to add additional terms to the license, since others could remove them at leisure? Smith clarified that Section 7 actually talks about three different kinds of additional terms.

“The first is additional permissions,” Smith said, “terms that excuse you from a certain requirement of the GPL. LGPLv3 is written as a set of additional permissions on top of GPLv3, for example. People *are* allowed to remove additional permissions, but they’re not required to (unless the permission itself tells them they are). So, if you get a program under LGPLv3, you can distribute it under the terms of LGPLv3, or take out the permissions and just make it GPLv3. The second kind of term doesn’t have a name in the license itself; we’ll call them supplements. These are the things in the lettered subsections that you’re allowed to add. Once these supplements are added, downstream recipients are *not* allowed to remove them. The third kind of term is called a ‘further restriction.’ This is something that tries to add a requirement onto the GPL that isn’t one of the lettered supplements. Section 7 tells people to go ahead and remove those. GPLv2 said they simply weren’t allowed, so if someone tried to add them anyway, licensees got nervous about whether they should follow the additional requirement or follow the term of the GPL that said there could be no additional requirements. This prevents that sort of confusing scenario from popping up.”

With that the meeting came to its conclusion. The IRC logs of the meeting are slated to be put online shortly at the Compliance Lab Web site. Anyone who has additional questions regarding any license may direct them to licensing@fsf.org.