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 (which is now defunct, since gpl-violations.org is no longer active.)
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 license0. 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):
- Linux, BusyBox, Samba, Mercurial, uClibc: <compliance@sfconservancy.org> (this address is primarily answered by me currently)
- FSF copyrights (many GNU programs such as GnuPG, wget, glibc, gcc, binutils): <license-violation@fsf.org>
- iptables, netfilter, mtd, initrd and msdosfs: <license-violation@gpl-violations.org> (note: gpl-violations.org is no longer active so this address might no longer work)
- XviD: <violations@xvid.org>
If the GPL'd project you've found a violation on isn't on the list above, just find email addresses of people with commit access to the repository for the project or with email addresses in the MAINTAINERS or CONTRIBUTORS files. It's better not to post the violation to a public discussion list for the project, as that's just “going public”.
Never treat a “community violator” the same way as a for-profit violator. I believe there is a fundamental difference between someone who makes a profit during the act of infringement than someone who merely seeks to contribute as a volunteer and screws something up. There isn't a perfect line between the two — it's a spectrum. However, those who don't make any money from their infringement are probably just confused community members who misunderstood the GPL and deserve pure education and non-aggressive enforcement. Those who make money from the infringement deserve some friendly education too, of course, but ultimately they are making a profit by ignoring the rights of their users. I think these situations are fundamentally different, and deserve different tactics.
Once you've reported a violation, please be patient with those of us doing enforcement. There are always hundreds of GPL violations that need action, and there are very few of us engaged in regular and active enforcement. Also, most of us try to get compliance not just on the copyrights we represent, but all GPL'd software. (This behooves both the software freedom community and the violator, as the former wants to see broad compliance, and the latter doesn't want to deal with each copyright holder individually). Thus, it takes much time and effort to do each enforcement action. So, when you report a new violation, it might take some time for the situation to resolve.
Do try your best to request source from the violator on your own. While making the violation public doesn't help, inquiring privately does often help. If you have received distribution of a binary that you think is GPL'd or LGPL'd (or used a network service that you think is AGPL'd), do write to the violator (typically best to use the technical support channels) and ask for the complete and corresponding source code. Be as polite and friendly as possible, and always assume it is their intention to comply until you have specific evidence that they don't intend to do so.
Share as much good information with the violator as you can to encourage their compliance. My colleagues and I wrote A Practical Guide to GPL Compliance for just this purpose.
We need a careful balance regarding GPL enforcement. Remember that the primary goal of the GPL is encourage more software freedom in the world. For many violators, the first experience the violator has with FLOSS is an enforcement action. We therefore must ensure that enforcement action is reasonable and friendly. I view every GPL violator as a potential FLOSS contributor, and try my best to open every enforcement action with that attitude. I am human and thus sometimes become more frustrated with uncooperative violators than I should be. However, striving for kindness with violators only helps give a great image to the software freedom community.
0In some situations, there are a few possibilities for users that exist if the copyright holder is unable or unwilling to enforce the GPL. We've actually recently seen an interesting successful enforcement by a user. I plan to blog in detail about this soon.