In spite of a vigorous and well-funded effort there has been a near total failure to control illegal filesharing over the past decade or so. One cause of this is the vast gap in worldview between different parties. To some, a useful analogy is to regard computer programs as a "devices" to accomplish given tasks, and the regulation of the creation and distribution of programs may seem entirely reasonable1. To others, including most programmers, regulations that prevent the distribution of the source code2 of a program are an unconstitutional restriction on their freedom of speech3. Because of this incompatible worldview, people often wind up talking past each other and repeating tired arguments that fail to persuade those on the other side.
This note points out that there is an approach to limiting filesharing that respects the freedom of speech of both artists and programmers, while allowing copyright owners an aggressive defense of their works.
As the litigation surrounding filesharing progressed, a lively public discourse developed on copyright and related issues. We can roughly divide the world into two camps: "Copyfighters" and "Copyright Maximalists" (as typified, for example, by the Electronic Frontier Foundation (EFF)4 and the Recording Industry Association of America (RIAA). These groups divide on many issues aside from filesharing, but filesharing and how to combat it is quite central to the dispute. For the most part, the discussion has always been framed using terms like "making copies", "making available", and "programs as devices", which are concepts based on the current legal framework; these often are fuzzy or entirely nonsensical to those with a technical background, which is part of the cause of the communication gap.
Because so much of the discourse centers on legalistic concepts, the so-called "Betamax case"5 plays a large role in discussions of filesharing. When Sony first introduced the Video Cassette Recorder (VCR), it was sued by a movie studio that claimed that most users of the machines would use it in ways that violated studios' copyrights on films. In a 5-4 Supreme Court decision, it was decided that Sony could not be held responsible for any copyright infringing done by purchasers of the machine, because the Betamax had "substantial non-infringing uses", even if it also had infringing uses as well.
The "Copyfighters" fear that limitations on filesharing progams will have a deleterious effect on technological innovation and freedom of speech in general. In defending filesharing programs (if not filesharing itself) they are quick to point out that not everything on the filesharing networks is there against its owners' permission, and therefore filesharing has "non-infringing uses". Under the Betamax decision, it therefore cannot be banned. This is, however, a fairly thin reed for defenders to lean on, since it is easy to imagine a court finding a way around the Betamax decision6, for example by finding that the infringing uses are so prevalent and serious that they justify banning an otherwise useful technology. Furthermore, the Betamax decision is not a restriction on Congress, which may decide to overturn or restrict it, under the intense lobbying pressure it gets from the content industries.
The First Amendment is the right tool to use to figure out how to regard the different roles in the filesharing network.
To start with, let's accept the position that programs are a form of expression, not a device, and are to be given the highest form of first amendment protection. Even if a program can be used to do something illegal or dangerous, it is no more reasonable to restrict the dissemination of the source code of the program7 than it is to restrict an article that describes how to do an illegal or dangerous thing8. Unlike the defense based on the Betamax decision, this has the virtue of intellectual consistency and has the merit that over time judges and the public may be made to understand this point of view.
Given this absolutist position, how can the gap with the "Copyright Maximalists" be bridged?
We note that few people take the position that copyright is inherently invalid, nor do many believe that everyone should have the right to exchange whatever files they want without restriction9. Objections are generally to the restrictions on free speech rights and consumer choice advocated to protect copyright materials.
While there is this much common ground, the problem is that penalizing the file traders themselves is bad business for the content owners (as it has generated an unending stream of bad publicity) and at any rate it's like trying to kill an ant colony by stepping on individual ants.
However, another way of looking at the issues reveals the possibility of more common ground.
Greenwich Village in New York City is the home of Washington Square Park. For many years, it was well known (among other reasons) as a place where drugs were sold. There was person who stood (in a region of the southwest corner of the park) saying to passers by in a quiet voice "Smoke, smoke!" However, this so-called "steerer" held no drugs. His role was simply to direct the buyer to the "pitcher", who had the drugs somewhere nearby, and who kept silent10.
Even the strongest defender of free-speech rights understands that the "steerer's" words are not just speech. His words are not similar to those of this article, though both simply say that someone in the southwest corner of the park is selling. He is as legally responsible for the sale as the "pitcher", because they are, according to legal terminology, "acting in concert". He is a drug dealer who may never touch any drugs. Note also that the "steerer" receives payments from the illegal transactions - though it is not in fact legally necessary to be able to prove the payments to establish that he's "acting in concert". All that's required is that the "steerer" and the "pitcher" share "community of purpose" in facilitating the illegal transaction. The "steerer's" role is a member of a conspiracy, not someone engaging in free speech. His liability to prosecution does not chill the current author's ability to write and publish this article, which shares no community of purpose with the drug dealers.
In the case of A&M Records v. Napster, the court held that Napster, even though it did not have any copyrighted data on its servers, was still liable for contributory infringement11. To use Napster, a peer-to-peer (P2P) downloader would login to Napster's central server, which connected the user to another user had a file that was being searched for. Since it was Napster's role to hook up the parties illegally exchanging files, it is reasonable to see this as analogous to the "steerer" in Washington Square - Napster didn't have the infringing materials, but that really isn't a defense12.
What happened in response to the Napster decision is that the architecture of P2P filesharing networks became decentralized. Today, one of the most popular filesharing programs13 is LimeWire, which exchanges data using a protocol known as gnutella14. The searching, uploading and downloading functions are all done without there being a central authority, as there was in Napster.
Gnutella is in some ways similar15 to NNTP, the protocol used by the decentralized bulletin board system known as usenet. In its heyday in the 1980s and early 1990's Usenet was very popular, hosting thousands of discussion groups on all sorts of subjects. It died in the late 1990s when it was overwhelmed by spammers trying to sell commercial products. Today usenet software still runs on some servers, but usenet is essentially a dead letter, without large numbers of users. Given the similarities, the question arises Why hasn't gnutella suffered the same fate as usenet?
In fact, spam is a problem for gnutella as well. Unlike usenet (or e-mail) spam, there are, in general, there are four categories of fake files that find their way onto the network.
What is not broadly appreciated is the role that LimeWire the corporation plays in the gnutella network. LimeWire is not merely the provider of software (and there are non-LimeWire gnutella clients, not as popular as LimeWire.) Limewire's client software, aside from supporting the gnutella protocol, receives instructions giving a list of IP address ranges it is to ignore, signed in a cryptographically strong way by LimeWire corporation - no one else may send the list16. This facility was built into LimeWire software in order to allow LimeWire corporation at its choosing to block hosts and content from talking to its clients. Anyone putting up files that LimeWire deems unsuitable is knocked off in a matter of hours18. Since LimeWire clients comprise the lion's share of gnutella users, this puts an end to the spammer's activities. This feature is something which, even after decentralizing gnutella, was still needed to keep gnutella functioning - not against a technical or legal problem, but something equally urgent: spam. Therefore, if LimeWire corporation disappeared, the filesharing network would continue to run - in the sense that users would be able to search and retrieve files - but nonetheless gnutella would be suffering today the same "death by spam" to which usenet ultimately succumbed. In fact, gnutella's death would happen even quicker than usenet's, since the music and movie companies themselves would hire MediaDefender to fill the filesharing network with junk. As we shall see, LimeWire acts as though its job is to keep gnutella safe for copyright infringers, not as a disinterested party discussing which people are sharing which kinds of files. And the word "job" is meant literally in this case, since LimeWire also expects to make money from keeping the network running and useful.
Accordingly, if we may analogize Napster with the "steerer" in Washington Square, LimeWire furthers the "community of purpose" in a different way; it is someone who gives negative information rather than affirmative. He's someone paid to stand in the park pointing out who are cheaters selling bad drugs, allowing the purchasers to find the good stuff. By this analogy LimeWire is actually involved with every illegal transaction on the gnutella network, since it plays a role in facilitating every transaction. Nor can LimeWire avail itself of a free-speech defense, any more than Napster or the "steerer" in Washington Square.
A question arises as to how one can tell the difference in the P2P context between a legitimate spam filtering authority and one that shares "community of purpose" with copyright infringers. The former could legitimately act to keep the network from being flooded (as usenet was) by those selling weight loss drugs and penny stocks. This would enhance the network's non-infringing uses, to use the terminology of the Betamax decision, without encouraging or facilitating infringing uses. There is probably no bright-line rule, but it is reasonably clear that LimeWire is well on the wrong side of any possible grey area.
First, it's useful to compare the way LimeWire acts to block gnutella spam with the way AOL (as an example) blocks e-mail spam.
LimeWire does not clearly advertise its Spam Cop role as a feature of its software, and does not discuss its block list. (The LimeWire web site has only the cryptic description "We're always working to protect you from viruses and unwanted sharing."19) There is no discussion anywhere about what sorts of sites and files it is blocking and for what reason. No notification is given by LimeWire to a site when it is blocked, nor is there any way given to contact LimeWire in order to remove yourself from the block list. LimeWire has the capacity to block specific files from the network (not just specific IP addresses), yet it does not widely advertise this ability to legitimate copyright owners, who could instruct LimeWire to prevent the sharing of their files.
In comparison, blocking e-mail spam is, for AOL and other e-mail providers, a major selling point for its customers. Moreover, AOL does not block bulk e-mailers (many of which are legitimate) on a whim. Every e-mail rejected by AOL is bounced with a notification to the sender, and there are detailed instructions to bulk e-mailers as to what they need to do to avoid running afoul of AOL's filters20. There is a way to contact AOL to remove oneself from the block list, if one is legitimate. The whole process is as transparent as it reasonably can be, within the constraint that a spam filter cannot tell senders how to avoid it.
From our description above of MediaDefender's role, it is clear that a legitimate Spam Cop cannot block MediaDefender. Any search for a non-infringing file would be unaffected by the spoof files. MediaDefender appears to have been, so far as its spoofing goes, a good-faith actor, not one attempting to curtail the distribution of any files other than the ones it was paid to curtail. There does not appear to be any evidence that MediaDefender was ever hired to spoof a non-infringing file. It appears that LimeWire does block MediaDefender, as the ISP known to have hosted it is on MediaDefender's block list, as discussed in the Appendix. In fact, LimeWire appears to be quietly promising to block MediaDefender and its ilk, when it says that it protects against "unwanted sharing", whatever that is.
Lastly, it appears that LimeWire's statements in court conceal what it is doing.
There is an ongoing case, Arista Records el al. v Lime Group et al., in which some record labels are suing LimeWire, claiming that it is liable for contributory infringement for the infringing uses to which its software is put, just as Napster was. In its motion for Summary Judgement, LimeWire states
Likewise, LW does not have the ability to control the manner in which users employ the LimeWire software. Unlike the Napster defendants, LW does not maintain central servers containing files or indices of files. ... LW's system is like that analysed by the Ninth Circuit in Grokster, "truly decentralized". ... LW no more controls the actions of its customers than do any of the thousands of companies that provide hardware or other software used in connection with the internet.21This discussion critically omits any discussion of the block list. The block list is centralized and provided only by LimeWire (because of the crypographic signing). LW most assuredly does control the manner in which LimeWire users employ the LimeWire software, because if a site (or a file) is added to the block list, it is no longer visible to LimeWire users22. This is very far from the normal situation applying in other software used in connection with the internet. (See the Appendix for more details.)
Moreover, the plaintiffs' attorneys appear to be unaware of the blocking of spoofs, as their reply motion23 makes no mention of it (nor the other hidden features of LimeWire software discussed in the Appendix).
Therefore, one concludes that while it might be possible to run a legitimate spam-blocking service for P2P networks, it would look rather different from what LimeWire is doing. The service would act in a transparent way (to all parties, including the courts) with clear rules and open communications. It would not block services like MediaDefender that act only to thwart infringers.
The best way to regulate filesharing effectively is to analyze the various players' roles on free-speech grounds. The individual filesharers are certainly violating the law, but in a small way that probably can't be reasonably controlled. The publishers of the software that allows the network to run (including LimeWire) are exercising free speech - the fact that their code can be made to do something illegal should be irrelevant. However, in every network, there has always been some sort of central authority that keeps a lid on spam. Today, on the gnutella network, that entity is LimeWire corporation. If LimeWire were shut down, the gnutella network would soon devolve into anarchy, and would become useless for downloading music - as usenet became useless for carrying on conversations. Because of their actions to keep the network safe for infringers - their "acting in concert" - it is these central entities that should be liable for contributory infringement24.
This course will not present the sort of free speech restrictions that trouble many. Moreover, in terms of acting against the network as a whole, it also will be far more productive than trying to target the small fish. It is actually an effective measure that should help to find common ground.
The author would like to thank Andrew Appel, David Feige, Ed Felten for useful comments.
[*] The author is not a lawyer, just an interested observer. Nothing in this article should be construed as legal advice, as this article should be regarded as an attempt at a scholarly work.
 The anti-circumvention provisions of the Digital Millennium Copyright Act (DMCA) refer specifically to a "device" for removing copy protection, and this has been interpreted to apply to programs. See http://www.copyright.gov/legislation/dmca.pdf, page 4.
 The argument goes like this: The source code of a program is merely the statement of the underlying ideas in a formal way. Anyone who understands the algorithm can create the source of a program in a straightforward manner. There is, therefore, little material difference between a careful explanation of an algorithm in English and that same algorithm expressed as a program written in Fortran. To a programmer, regulations that prevent the distribution of the source code of a program are an unconstitutional restriction on their freedom of speech. An excellent example of the closeness of speech and software was provided when Prof. Ed Felten of Princeton had a run-in with the Recording Industry Association of America (RIAA) et al after his successful crack of the Secure Digital Music Initiative (SDMI) challenge. The claim from the SDMI was that Felten's paper describing the technique he used to beat the SDMI protections constituted a violation of the DMCA. Given that the paper contained no code whatsoever, it is clear that the SDMI believes that the DMCA applies to speech and not simply programs that can be run on a computer. You may find the letter the SDMI wrote to Felten here: http://cryptome.org/sdmi-attack.htm and for a description of the incident see here http://www.wired.com/politics/law/news/2001/08/46097.
 The status of software-as-speech is not presently settled law. The argument was first explicitly made in the legal context in two freedom-of-cryptography cases in Federal Court in the mid 1990s. In Bernstein v. US Dept of Justice the U. S. Court of Appeals for the Ninth Circuit holds (May 6, 1999):
In light of these considerations, we conclude that encryption software, in its source code form and as employed by those in the field of cryptography, must be viewed as expressive for First Amendment purposes, and thus is entitled to the protections of the prior restraint doctrine.and in Junger v. Daley the U. S. Court of Appeals for the Sixth Circuit holds (April 4, 2000)
Because computer source code is an expressive means for the exchange of information and ideas about computer programming, we hold that it is protected by the First Amendment.However, in Universal City v Reimerdes, the so-called 2600/DeCSS case, the U.S. Court of Appeals for the Second Circuit (May 30, 2001) followed murkier reasoning, holding that programs have a functional, "nonspeech" component that can be regulated. Under this interpretation, prior restraint can be justified even against a link in an HTML document.
[A] hyperlink has both a speech and a nonspeech component. It conveys information, the Internet address of the linked web page, and has the functional capacity to bring the content of the linked web page to the user's computer screen ...[A]pplication of the DMCA to the Defendants' linking to web sites containing DeCSS is content-neutral because it is justified without regard to the speech component of the hyperlink. The linking prohibition applies whether or not the hyperlink contains any information, comprehensible to a human being, as to the Internet address of the web page being accessed. The linking prohibition is justified solely by the functional capability of the hyperlink.The net result of this decision was the rather nonsensical outcome that the defendants were allowed to list the URLs of sites containing the code for DeCSS (a program the decision prohibited) on a web page, but not to put them inside of
hreftags allowing them to be clicked. It is probably safe to say that no one who had a deep understanding of web browsers, HTML and how they work would have reasoned in this way. Indeed, it is interesting to contemplate how this decision could be applied to simply e-mailing a URL to someone else, since most but not all modern e-mail clients turn all URLs in messages into links, whether or not they were coded that way in the original e-mail message. It is difficult to see how any machine readable text can avoid having a "nonspeech" component by this reading.
 The author of this document is a member of the EFF.
 For a review, see the discussion here: http://en.wikipedia.org/wiki/Sony_Corp._v._Universal_City_Studios.
 As pointed out in note 3, in the DeCSS/2600 case, the court found a way around the First Amendment.
 Adopting this absolutist approach has the merit of avoiding strange outcomes that arose after the DeCSS/2600 case, discussed in note 3. Trying to split hairs about what is a program and what is not is, in the long run, certainly a fool's errand. Does a t-shirt with code printed on it have a nonspeech component (http://www.wired.com/science/discoveries/news/2000/08/37941)? What about a picture of a listing of a program written in the C programming language? A list of other such first amendment puzzlers is at Touretzky, D. S. (2000) Gallery of CSS Descramblers http://www.cs.cmu.edu/~dst/DeCSS/Gallery/. The issue of whether broad free speech protections should also apply to non-human-readable executable code is beyond the scope of this discussion.
 Of course, there are restrictions of speech in cases of national security, for example. A program that can be used to design a nuclear weapon could be restricted the same way a paper that describes a way to make a nuclear weapon. Nor need a program be more protected than any other form of speech. It could be found to be libelous, for example.
 Here, we are discussing the situation in the US. In Sweden, the Pirate Party has won seats in the European Parliament, and they and other political parties support legalizing filesharing (and the abolition of patents), see http://www.piratpartiet.se/international/english. In the US, few go quite that far. Richard Stallman is an instructive example - he argues that many of the ways in which copyright has been understood are fundamentally misguided, though even he argues that some term of a monopoly on copying is useful, and that people therefore should not be permitted to access others work for free in all cases. See http://www.gnu.org/philosophy/misinterpreting-copyright.html.
 Washington Square was recently renovated, and the part of the park that was used by the drug dealers was closed for an extended period. It remains to be seen if they will resume their former activities.
 The text of the decision may be seen at http://cyber.law.harvard.edu/~wseltzer/napster.html.
 Napster's defense hinged on its not actually knowing whether the files were infringing or not when it hooked the two parties together. For our purposes, we can simply note that (a) a very large fraction of the files Napster was indexing were infringing, (b) the titles of the files indicated that they were infringing, and (c) Napster, initially at least, did nothing to determine if they were infringing or not. This was a sort of willful blindness that the court found unconvincing. To use our drug dealing analogy, we can imagine that the "steerer" claimed that he thought that the "pitcher" was occasionally selling tobacco rather than pot. At any rate, whatever the merits of Napster's argument, the issues discussed here are essentially independent of those of the Napster case.
 See http://en.wikipedia.org/wiki/Gnutella for a description of the protocol.
 The analogy is not exact, as there was no need in NNTP to have a distributed search function.
 The block list acts against specific internet (IP) addresses and files. For some technical details, see the Appendix below.
 The author has spoken to those with direct experience of this behavior on LimeWire's part.
 https://www.eff.org/files/filenode/Arista_v_Lime_Wi/LimeWire%20-%20LW%20MSJ%20memo%20(redacted).pdf, p 37.
 Except for a very small minority who find the checkbox located on an "Advanced" configuration panel, and choose to turn off the blocking feature.
 Arista v Lime Wire LW Plaintiffs opp brief (redacted) http://www.eff.org/files/filenode/Arista_v_Lime_Wi/LW%20Plaintiffs%20opp%20brief%20(redacted).pdf
 A question may reasonably be asked as to whether a network could exist without any central authority taking on a role like LimeWire's. It seems unlikely. A small group of individuals, all of whom know and trust each other, can maintain a set of social norms that prevents spamming. However, when the network is open and has to be policed by everyone, a system that involves, for example, voting on which files are spam and which aren't is likely to be overwhelmed by the spammers casting fake ballots. The filesharers might try to use a "circle of trust" approach, but this is unlikely to scale very far before spammers find their way in. Usenet, while it worked, used a sort of hybrid system to control spam. Sysadmins of the node servers were supposed to cut off those leaf machines that were flooding the network. This worked well for quite some time, but was not scalable to the size of population usenet ultimately attracted.
IP block lists are a common part of P2P sharing programs. Generally, they are posted on web sites and downloaded by the P2P program, at the direction of the user. The program is generally configurable to download the block list from a site of the user's choosing, and the block list file is stored in a known location and is readable and editable by interested users. For example, the forum discussion here (http://forum.emule-project.net/index.php?showtopic=100907&mode=threaded&pid=727412) describes how to download the block file for the P2P client eMule. The LimeWire P2P clients are unusual in that there is nothing configurable about the choice of block list. Moreover, unlike other programs, there is no way for anyone other than LimeWire to send it, and no way for a non-technical user to examine its contents - in fact, the typical non-technical user would not even know that blocking is going on. (The only way to turn off blocking is on an advanced configuration panel.)
P2P programs authored by LimeWire corporation look on the network for a control message that tells them to write out a file called
simpp.xml. This file is downloaded from the public gnutella network, but it is signed with a private key known only to LimeWire, meaning that only LimeWire corporation can send the file. The file is saved in clear text on the user's machine.
In 2007 some of MediaDefender's internal e-mail was leaked to the public (see http://torrentfreak.com/mediadefender-emails-leaked-070915/). Included in the leak was the name, serverbeach, of the ISP that MediaDefender was using, a fact which was quickly noticed and posted on various forums and bulletin boards (for example, http://m.digg.com/tech_news/Media_Defenders_Emails_Leaked_HTML_Format?offset=80). It appears that at that point all of serverbeach's IP addresses were added to various block lists, and it continues to this day in LimeWire's.
A sample simpp.xml file is listed below. As the structure reveals, it is used by LimeWire's central servers to set various parameters of remotely running LimeWire clients. The initial part indicated in orange is the cryptographic signature, which may be constructed only by LimeWire. The lines indicating
FilterSettings.filteredUrnsRemote (indicated in blue) are block lists. The first of these lists the IP addresses which the client is to ignore, and the second lists a set of file hashes to ignore. The file hash is a sort of compressed version of a given file, which allows the LimeWire client to quickly identify it. If a file's hash is listed in
FilterSettings.filteredUrnsRemote, no LimeWire client will share the file. Both of these facilities could be used by LimeWire to block infringing machines and files, if it were to send out an appropriate block list. These two lines are very long, but if one scrolls to the right, the serverbeach IPs are indicated in red.
LimeWire has also added a facility that allows its server, and only its server, to contact a running LimeWire client and ask it various questions about what the client is doing. This feature (also unmentioned in the court documents) allows LimeWire to phone up LimeWire clients and inspect them, thereby gathering information about its network. The line
FilterSettings.inspectorIps=188.8.131.52 (indicated in violet) shows that inspection requests coming from anyplace other than this one IP address (assigned to a machine called fserv1.limewire.com) are rejected by the client. By configuring it in the simpp.xml file, LimeWire can avoid hard-coding this information in the application itself, thereby allowing it to move the inspector machine to a different IP address at any time.