RIAA Legal Analysis (fwd)
Wed, 3 Oct 2001 15:10:52 +0200 (MET DST)
-- Eugen* Leitl <a href="http://www.lrz.de/~ui22204/">leitl</a>
ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.lrz.de/~ui22204
57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3
---------- Forwarded message ----------
Date: Wed, 3 Oct 2001 07:20:56 -0500 (CDT)
Subject: RIAA Legal Analysis
An excellent technical analysis from the RIAA legal dept. Any errors of
transcription are likely my own - see the original at
for as long as it is there...
My favorite part is the last paragraph, where they talk of getting
FastTrack to roll over on MusicCity!
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-bandwidth connections - as "supernodes."
[because of the systems 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 systems 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 processing 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
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 communications 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 communication, 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 technology).
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 communication 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 peers use of the network.
If the log-in server is not available, 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 supernode addresses stored in the software application. That list
is supplied by the application developer, and is identical across KaZaA,
Morpheus, and Grokster. The list includes IP addresses at universities and
other institutions such as the NASA Jet Propulsion 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 overwrites 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 computers 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 supernode.
If the registry is somehow corrupted, the application causes the peer to
contact another server controlled by KaZaA, supernode.kazaa.com
(220.127.116.11). 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 (.38) server in this
KaZaA operates another server in addition to the log-in (.37) server and
the (.38) server described above. That is alpha.kazaa.com
(18.104.22.168), the address of which, as with the other two, is
hard-coded into the application. The (.34) server communicates 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 supernode. 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 supernode 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
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
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).
o FastTrack sought to obtain licensing from NVPI and was referred to
members of the organization.
o NVPI wrote to FastTrack and provided notice that its conduct was
and that it should obtain the necessary licensing.
o RIAA wrote letter to MusicCity when it was an OpenNap system and placed
MusicCity on notice of infringing conduct. The same principals contacted
the RIAA are still in place at MusicCity.
o In discussion with General Counsel of Copyright.net, KaZaA CEO
exchange of copyrighted content and stated looking into filters,
for child porn.
o Press has raised issue of exchange of copyrighted content with company
o Widespread presence of copyrighted materials on system.
o 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?]
o FastTrack creates and licenses software primarily used for the
and distribution of copyrighted works.
o FastTrack created and controls encryption that ensures that the network
remains closed and insulated from outside monitoring.
o Provides a dynamic list of available supernodes where content can be
exchanged (possibly through the .38 server).
o Continually updates the list of available supernodes and communicates
information to users (likely through the .34 server).
o FastTrack, MusicCity and Grockster maintain log-in servers.
o Maintains the s1grokster.com server which acts as a supernode (and by
definition maintains a file index).
o Resolves netsplits and other system problems (likely through the .34
o Vicarious liability arises when the defendant "has the right and ability
supervise the infringing activity and also has a direct financial
in such activities." Napster, 239 F.3d at 1022.
Right and Ability to Supervise
o KaZaA, MusicCity, and Grokster all expressly reserve the right to limit
number of files that users make available or access and to terminate
who infringe intellectual property rights or violate other laws.
o MusicCity also reserves the right to remove or disable links to
o Network limits MP3 files to certain bitrate
o MusicCity implemented a filter for child pornography.
o Steve Griffin claims to have cooperated with police in limiting the
of child pornography.
o Generate advertising revenue based on user base.
o Steve Griffin expressed to head of Rock the Vote that he cant stop
infringements so he intends to make money from it.
o Zennstrom acknowledged to the press that FastTrack is making money.
o The services have a rapidly growing user base and according to CNETs
download.com is the most popular software on the net.
o MusicCity obtaining additional funding from Timberline Venture Partners.
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
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
FastTracks cooperation in shutting down or converting MusicCity and
Grokster, and (4) continue forward with litigation against MusicCity,
Grokster, and potentially Timberline Venture Partners.