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.