Internal RIAA memo on KaZaa

[napho]

This is way old but I never saw it before so no flaming me.


KaZaA Network Outline of Proof

PRIVILEGED & CONFIDENTIAL/ATTORNEY WORK PRODUCT

We have distributed various legal and technical memoranda that describe the KaZaA network and the potential legal claims against the entities offering this peer-to-peer service. This memorandum seeks to consolidate our current learning into a single document. Accordingly, detailed below are: (a) a brief overview of the relevant entities and the KaZaA network architecture; (b) the facts supporting our legal claims; and (c) a going forward strategy recommendation.

I. Overview of Entities and Architecture

FastTrack is the Netherlands based software company that developed the software code library used to create the KaZaA peer-to-peer networks. KaZaA was the first application to use the FastTrack code. FastTrack later licensed its code to MusicCity (MusicCity dubbed its system Morpheus) and Grockster. The principals behind FastTrack are Niklas Zennstrom and Janis Friis- - Two young technology developers who are primarily interested in the development of their technology and who have privately funded their operation. MusicCity is being run by Steve Griffin, but with heavy influence by Timberline Venture Partners, the independently managed Northwest Affiliate of Draper Fisher Jurvetson. Timberline owns 65% of MusicCity and is very involved in running the company.

The FastTrack network designates (perhaps automatically) certain peers - more powerful computers with high-band#width connections - as "supernodes." [because of the system’s encrypted communication, we are unable to determine how supernodes are designated]. Several hundred "ordinary" peers connect to any one supernode. A supernode also connects to other supernodes. [because of the system’s encrypted communication, we are unable to determine how one supernode knows how to locate other supernodes]. Vidius found that when one of its machines was in supernode status, it was connected to approximately 25 other supernodes. The supernode functions in Napster-like fashion as a local search hub, building an index of the files being shared by each peer connected to it, and pro#cessing search requests on behalf of those peers. Supernode queries other supernodes to fulfill a search request, but does not query peers serviced by other supernodes (such a step is unnecessary because the supernodes index all files available among the peers they service). The effect of this architecture is to create a relatively small peer-to-peer network of supernodes, each of which in turn functions as a miniature central server for hundreds of other users. As in Napster and Gnutella, file transfers in the FastTrack system are purely peer-to-peer, and involve neither the central server nor any supernode.

Significantly, the FastTrack system encrypts all communications (a) between a peer and the log-in server, (b) between a peer and its supernode, (c) between a supernode and the central servers, and (d) between supernodes [we do not know the nature of the encryption]. However, peer-to-peer com#muni#cations associated with downloading a file are unencrypted. Presumably, the encryption scheme was created, and is controlled, by the developer of the application - FastTrack. By encrypting the com#munication, the developer has ensured that the network remains "closed" and accessible only through the KaZaA, Morpheus, or Grokster applications (and any future licensees of the FastTrack tech#nology).

KaZaA, MusicCity, and Grokster each operate a central log-in server. The addresses of these servers are hard-coded into the application. At log-in, the peer sends one packet of data to the server, and the server returns two packets. The transmissions presumably involve log-in information from the peer and acknowledgement and confirmation from the server. This function appears to be similar for each of the three entities. In addition, Vidius reports that, at least with the KaZaA application, there is a commun#ication regularly every 12 hours between the log-in (.37) server and the user (whether in peer or supernode status) [we do not know the nature of these communications].

Notably, the log-in server is not essential to a peer’s use of the net#work. If the log-in server is not avail#able, the application nevertheless attempts to connect to a supernode using the list contained in the registry (whether it is the preset list for a new user or the most recent update for a repeat user).

After log-in, the peer then attempts to connect to a supernode, using a list of super#node addresses stored in the software application. That list is supplied by the applica#tion devel#oper, and is identical across KaZaA, Morpheus, and Grokster. The list includes IP addresses at universities and other institutions such as the NASA Jet Propul#sion Laboratory. The list of supernodes has changed with each new version of the application. In the newest version of the application, the list also includes an IP address at Disney, rnd11-200.rd.wdi.disney.com. The IP addresses listed in the registry do not all function as supernodes at any given time; in fact, most do not. After logging in, a peer works through the list in its registry until its finds a supernode it can connect to. When the peer connects to a supernode for the first time, it receives an updated list of supernodes, which over#writes the preset list in the registry. [we do not know how the suprnode obtains this updated list of supernodes to distribute]. The list of supernodes in the registry is then updated every time the peer connects to a supernode. Thus, a peer always has the most recent possible list of com#pu#ters that have functioned as supernodes, thereby increasing the odds of a successful connection during the next session. After initially making contact with a supernode, a peer may be shunted around the network as the system attempts to match the peer with the most appropriate super#node.

If the registry is somehow corrupted, the application causes the peer to contact another server controlled by KaZaA, supernode.kazaa.com (213.248.112.3 . This address is also hard-coded into the application. This means that the KaZaA network maintains a dynamic list of active supernodes [we do not know how this happens]. Upon connecting to that server, the peer will receive a list of known supernodes. All three applications direct the user to the KaZaA (.3 server in this circum#stance.

KaZaA operates another server in addition to the log-in (.37) server and the (.3 server described above. That is alpha.kazaa.com (213.248.112.34), the address of which, as with the other two, is hard-coded into the application. The (.34) server communica#tes with supernodes [we do not know the nature of the communication]. During an interval when a Vidius machine was acting as a supernode, there were 12 different attempts by the (.34) server to connect to the supernode. Vidius reports that in a completed transaction the (.34) server sends approximately 1600 bytes of information to the super#node. In addition, as noted above, a supernode makes periodic connection with the KaZaA log-in (.37) server. Vidius hypothesizes that there is a loop between the (.34) server, the (.37) server, and the supernode, which is highly suggestive of some sort of control mechanism - the nature of which must remain unknown until the substance of the communications can be analyzed.

Vidius found that "netsplits" or disconnections sometimes occur on the FastTrack network. The system contains some mechanism to resolve such disconections by redirecting peers away from a supernode that has become detached from the network and back to a super#node on the network. Supernodes that are split from the network also eventually reconnect to it, but that reconnection takes 10-15 minutes longer than the reconnection of peers. Vidius believes that this timing differential indicates some control of the reconnection process that is external to the client application.

Among the supernodes on the new preset list is one at s1grokster.com, which resides at the same location as the Grokster log-in server. Those computer functions like an ordinary supernode, compiling indexes of available files and processing search requests. Vidius was able to connect to that supernode, and used it to find and download numerous movie and MP3 files.


II. Elements of Claims and Proof

1. Contributory Infringement

Liability for contributory infringement attaches to "one who, with knowledge of the infringing activity, induces, causes or materially contributes to the infringing conduct of another . . . [L]iability exists if the defendant engages in personal conduct that encourages or assists the infringement." A&M Records, Inc. v. Napster, Inc., 239 F.3d 1004, 1014 (9th Cir. 2001).

Knowledge


FastTrack sought to obtain licensing from NVPI and was referred to individual members of the organization.


NVPI wrote to FastTrack and provided notice that its conduct was infringing and that it should obtain the necessary licensing.


RIAA wrote letter to MusicCity when it was an OpenNap system and placed MusicCity on notice of infringing conduct. The same principals contacted by the RIAA are still in place at MusicCity.


In discussion with General Counsel of Copyright.net, KaZaA CEO acknowledged exchange of copyrighted content and stated looking into filters, particularly for child porn.


Press has raised issue of exchange of copyrighted content with company principals.


Widespread presence of copyrighted materials on system.


Message Boards discuss available music, films, and software.


MusicCity employees participate in message board discussions and CEO acknowledges MusicCity controls message boards.


[should we provide notice by letters and when?]

Material Contribution


FastTrack creates and licenses software primarily used for the reproduction and distribution of copyrighted works.


FastTrack created and controls encryption that ensures that the network remains closed and insulated from outside monitoring.


Provides a dynamic list of available supernodes where content can be exchanged (possibly through the .38 server).


Continually updates the list of available supernodes and communicates that information to users (likely through the .34 server).


FastTrack, MusicCity and Grockster maintain log-in servers.


Maintains the s1grokster.com server which acts as a supernode (and by definition maintains a file index).


Resolves netsplits and other system problems (likely through the .34 server).


Vicarious Infringement

Vicarious liability arises when the defendant "has the right and ability to super#vise the infringing activity and also has a direct financial interest in such activities." Napster, 239 F.3d at 1022.

Right and Ability to Supervise


KaZaA, MusicCity, and Grokster all expressly reserve the right to limit the number of files that users make available or access and to terminate users who infringe intellectual property rights or violate other laws.


Music#City also reserves the right to remove or disable links to alleged#ly infringing material.


Network limits MP3 files to certain bitrate


MusicCity implemented a filter for child pornography.


Steve Griffin claims to have cooperated with police in limiting the exchange of child pornography.

Financial Benefit


Generate advertising revenue based on user base.


Steve Griffin expressed to head of Rock the Vote that he can’t stop infringements so he intends to make money from it.


Zennstrom acknowledged to the press that FastTrack is making money.


The services have a rapidly growing user base and according to CNET’s download.com is the most popular software on the net.


MusicCity obtaining additional funding from Timberline Venture Partners.


III. Recommendation

We have solid claims against FastTrack, MusicCity, and Grockster of secondary liability for copyright infringement. The claims are not as strong as those against Napster, but they are also not so remote as to be wishful.

Our claims would likely be strengthened by learning more about the designation of supernodes and the content of communications within the system. However, the encryption of this communication precludes further learning absent cooperation from one of these companies or court ordered discovery. In that regard, we recently learned that FastTrack is very interested in exploring alternatives to litigation and its principals are willing to sit down with the record companies to discuss ways of resolving any dispute. FastTrack is willing to sell the company and the technology, or enter into a licensing arrangement. FastTrack is also willing to implement filtering technologies to prevent infringements. We have also learned that MusicCity is looking for the litigation and would like for us to file suit.

Thus, we recommend (1) filing claims against FastTrack, MusicCity, and Grockster, (2) immediately thereafter initiating discussions with FastTrack about resolving our claims in a way that will provide us with useful information and testimony against MusicCity, and if possible obtain FastTrack’s cooperation in shutting down or converting MusicCity and Grokster, and (3) continue forward with litigation against MusicCity, Grokster, and potentially Timberline Venture Partners.

[ssj4_android]

Yeah, that is old, but I've never read it before. Wounder if they studied gift?

[pod]

We have also learned that MusicCity is looking for the litigation and would like for us to file suit.

Hmm, I wonder what the mean by that...

[imoron]

My wonder is if the 213.248.112.34 IP addy corresponds to the update message control IP that Harby spotted a while back. If so, then perhaps the mechanism for creating iMorpheus (or iAnyFTOldClient) would be to simply block all communications to and from that IP addy.