GPL Enforcement: Don't Jump to Conclusions, But Do Report Violations

In one of my favorite movies, Office Space, Tom Smykowski (one of the fired employees) has a magic-eight-ball-style novelty product idea: a “Jump to Conclusions” mat. Sometimes, I watch discussions in the software freedom community and think that, as a community, we're all jumping around on one of these mats.

I find that people are most likely to do this when something seems novel and exciting. I don't really blame anyone for doing it; I do it myself when I have discovered an exciting thing that's new to me, even if it's well known by others. But, often, this new thing is actually rather mundane, and it's better to check in with the existing knowledge about the idea before “jumping” to any conclusions. In other words, the best square on the mat for us to land on is the one that reads: Think again!

Meanwhile, as some who follow my microblog know, I've been on a mission in recent months to establish just how common and mundane GPL violations are. Since 21 August 2009, I've been finding one new GPL violating company per day (on average) and I am still on target to find one per day for 365 days straight. When I tell this to people who are new to GPL enforcement, they are surprised and impressed. However, when I tell people who have done GPL enforcement themselves, they usually say some version of: Am I supposed to be impressed by that? Couldn't a monkey do that? Fact is, the latter are a little bit right: there are so many GPL violations that I might easily be able to go on finding one per day for two years straight.

In short, GPL violations are common and everyday occurrences. I believe firmly they should be addressed, and I continue to dedicate much of my life to resolve them. However, finding yet another GPL violation isn't a huge and earth-shaking discovery. Indeed, it's what I was doing today to kill time while drinking my Sunday morning coffee.

I don't mean to imply that I don't appreciate greatly when folks find new GPL violations. I think finding and reporting GPL violations is a very valuable service, and I wouldn't spend so much time finding them myself if I didn't value the work highly. But, the work is more akin to closing annoying bugs than it is to launching a paradigm-shifting FLOSS project. Closing bugs is an essential part of FLOSS development, but no one blogs about every single bug they close (although maybe we do microblog them ;).

Having this weekend witnessed another community tempest about a potential GPL violation, I decided to share a few guidelines that I encourage everyone to follow when finding a GPL violation. (In other words, what follows are a some basic guidelines for reporting violations; other such guides are also available at the FSF's site and the gpl-violations.org site.)

• Assume the violation is an oversight or an accident by the violator until you have clear evidence that tells you differently. I'd say that 98% of the violations I've ever worked on since 1998 have been unintentional and due primarily to negligence, not malice.

• Don't go public first. Back around late 1999, when I found my first GPL violation from scratch, I wanted to post it to every mailing list I could find and shame that company that failed to respect and cooperate with the software freedom community. I'm glad that I didn't do that, because I've since seen similar actions destroy the lines of communication with violators, and make resolution tougher. Indeed, I believe that if the Cisco/Linksys violations had not been a center of public ridicule in 2003 when I (then at the FSF) was in the midst of negotiating with them for compliance, we would not have ended up with such a long saga to resolution.

• Do contact the copyright holders, or their designated enforcement agents. Since the GPL is a copyright license, if the violator fails to comply on their own, only the copyright holder (typically) has the power to enforce the license⁰. Here's a list of contact addresses that I know for reporting various violations (if you know more such addresses, please let me know and I'll add them here):

  • BusyBox and uClibc: <gpl@busybox.net> (this address is primarily answered by me currently)
  • FSF copyrights (many GNU programs such as GnuPG