The Sneaky Weasel Theory

Simon Phipps posted an interesting response to my write-up of the GPLv3 conference. I said that the current draft of the new license appears to take no explicit action to eliminate the ASP loophole. Simon disagreed:

[A]s I have looked at it more and more, I believe Eben and Richard have been far more subtle. A crude and explicit ASP clawback would have raised a riot. Instead, the seeds are sowed in section 5c ... and even more in section 1.

It's important to look as carefully as Simon is doing at the language, and to consider ways in which users, lawyers and the courts might interpret it. Nevertheless, I think Simon is wrong.

The language in 5(c) is simply that the program display notices via some convenient mechanism. That's common in licenses, and the provision is present in the current version of the GPL, in section 2(c). There's nothing new here. Section 1 does introduce some new language, but I don't think it's intended to cover Web interfaces -- rather, it's intended to resolve the long-standing debate on what "linking" means in the GPLv2.

So on the face of it, I believe those sections do important work, but not any work on the ASP loophole.

More fundamentally, I don't believe that the FSF intends to use subtlety and guile to get important changes into this draft. I've certainly seen legal documents that do this; they are usually drafted by sneaky weasels who want to use words to conceal their intent when they are making an agreement. The question is, could the FSF possibly be sneaky weasels in drafting v3?

I believe that the answer is no. The review and comment process is intended to create a large corpus that explains clearly the intent of the drafters. That way, if there are questions as to meaning later, developers, lawyers and the courts can examine the literature and find out what particular words in the language mean.

This comment period will go on for about a year. Simon raises an interesting question; does the FSF intend sections 1 and 5(c) to require ASPs to release their code? There's clear language in 7(c) and a statement from the podium that deals with the point. I expect that the discussion and commentary will make clear that 1 and 5c are aimed elsewhere.

Fundamentally, this process will be too public, discussions will be too open, and the review will be too painstaking to support sneaky weasel behavior. Eben, Richard and the rest of the FSF are smart people. Being a sneaky weasel in this instance just wouldn't work.

We can take the language at face value.

GPLv3

I'm in Boston for the inaugural meeting for the public review of version 3 of the GNU General Public License. Given the venue, there is less international participation than Eben Moglen and Richard Stallman may have liked, but the turn-out is pretty good. Representatives come from businesses using free software, businesses that produce and service free software, and the broad development community. Participants include HP and Sleepycat, the Apache foundation and individual developers working on small projects. A number of attorneys, from private practices and corporate counsel from technology companies, are here, as well.

All things considered, I think that Eben and Richard did a good job of attracting a cross-section of the interested parties to the kick-off.

The first public draft of the new version is available for public review. It's an interesting document to read, and I encourage you to do that. For the time-pressed or the curious, though, here are a few of my own impressions.

The FSF is clearly taking a much stronger stand against software patents than it did in previous versions of the license. This issue has become increasingly important in the industry. Even Microsoft's source-available licenses dealt with the topic explicitly. The provisions in the new GPL are defensive; someone using GPL'ed code who asserts patent rights for that code against others loses the rights to use. Also, anyone who knowingly distributes GPL'ed code under a patent license that they hold is required to provide, by some means, a patent rights grant for downstream users. This appears to me to be intended to require large companies with substantial patent portfolios to take care of cross-licensing for those who receive GPL'ed software from them. Smaller developers aren't likely to have the tools to obtain blanket licenses, but are much less likely to know that there are patent obligations in code. All told, a good stance for the FSF to take.

Digital rights management -- or, as Richard Stallman puts it, Digital Restrictions Management -- is another major issue for the drafters. They're against it (and so am I). The new draft requires anyone who distributes GPL'ed code that uses DRM to distribute the DRM keys simultaneously. This provision is intended to ensure that hobbyists and others can continue to enhance systems like TiVo, which uses DRM in its most recent releases to prohibit modifications to the software that runs on the systems their customers buy from them. My prediction: The language here will be tricky to get right, as there are lots of parties to consider (author, DRM system vendor, company that builds the system, third-party modifiers and end users), and DRM technology is a moving target. Noble sentiment, some work to do to make sure it plays out properly.

Next, the most anticipated or feared provision, depending upon who you are: The elimination of the ASP loophole. Briefly, the old GPL required you to share your changes if you shared your program. The way you shared programs in the old days was to give copies of them to others. Today, many software packages are "shared" by connecting to a central Web server and using a browser to do things. Application Service Providers, or ASPs, don't ship software, but they still use and enhance GPL'ed packages (sometimes!) and perform the changed version for users.

Many in the developer community want to see those enhancements shared. Many large ASPs want to keep them private. Both sides muster reasonable arguments in favor of their positions. This change has been a lightning rod in the run-up to the new version, and many of us were eager to see how the FSF would address it.

The answer is, they ducked it. There's a provision in the draft agreement -- section 7(d), for those of you reading along at home -- that permits developers to add the requirement to share enhancements that ASPs and companies like them develop, but nothing in the official draft requires that. In fairness to the FSF, the politics on this one issue are tremendously complicated, and the legacy of old GPLv2 code running at ASPs forces those ASPs to make some pragmatic decisions on adoption of new code under the new license if the rules change on them. This topic will be one that gets heavily debated during the comment period.

Section 7 of the new draft is intended to make it easier to build software systems that combine GPLv3 software with other free and open source software. That compatibility is a good thing, but the provisions in section have already raised a lot of eyebrows. There is some concern that allowing people to add conditions to the GPL will confuse, rather than clarify, licensing requirements. For a programmer, the question is, should the license be made extensible (which in my view is what section 7 attempts to do), or should the language permit explicit compatibility with other licenses with certain terms? Stay tuned, this one is far from over.

Now we'll all buckle down for a year and do some work. Feel free to pitch in -- the GPLv3 site explains how.

Links for 7 Jan 2006: Deep stuff

After some weeks of silence, links for the day. I've collected enough of them over the past two weeks that I can afford to split the load. This batch is the stuff that will make you a better person. To wit:

• Bruce Schneier discusses the value of anonymity and how it differs from privacy, in a post rebutting Kevin Kelly's claim that anonymity is bad, with commentary from lots of others interspersed. The key issue seems to me to be balancing individual expectations of privacy with society's need to enforce the law. You ought not to be able to hide while you commit crimes.
• Bruce also led me to an article on automating the download of Amazon wishlists, then using the results for data mining. The erosion of privacy is surprising, sometimes. It's getting easier all the time to find, aggregate and analyze what you used to consider personal information. If you don't want it known, you ought to keep it off the web.
• Obsessed with digital privacy? Get PGPdisk.
  
• Feeding the geeks: Some quantitative data on the relative popularity of programming languages.
• Feeding the geeks a little more: One of the many top download lists for 2005 points you at software you might like, for free.
• I wrote about my hybrid Accord a while ago. There is some future-car research, on hyrdogen-powered vehicles, going on at Cal.
  
• Want to know how the search engines rank results? An article on search engine optimization answers that question, as a side effect of telling you how to improve your score.
• And the old one on the list: Jon Udell had a good article at the end of November on data synchronization and interchange. Sound dull? This is what Google and Microsoft are working on now.

These are the ones you'll read instead, though, because they're just more fun:

• Bump keys, if you don't have the patience to hone your burglary skills over time.
  
• It turns out we are living in the Matrix.
• Everbody loves Three Dead Trolls in a Baggie, because the Trolls know that every OS sucks.
• Floam at home.
• Without Lego, there could be no great art.