Free music is easy to find nowadays. Just head over to YouTube and one can find millions of tracks, including many of the most recent releases.
This is a problem for the major record labels which don’t want tracks to leak outside YouTube’s ecosystem. For this reason, YouTube rippers are seen as a major threat.
FLVTO.biz and 2conv.com Lawsuit
In 2018, a group of prominent record labels sued two very popular YouTube rippers, FLVTO.biz and 2conv.com. The labels, including Universal, Warner Bros, and Sony, accused the sites of copyright infringement and hoped to shut it down quickly. That was not the case.
The Russian operator of the YouTube rippers, Tofig Kurbanov, fought back. He initially argued that a US court doesn’t have jurisdiction over foreign sites. After a lower court initially agreed, the labels won on appeal. In March, a Virginia federal court ruled that Mr. Kurbanov must face the piracy allegations.
The ruling means that both parties will now have to argue the case on its merits. As part of this process, the labels and stream-rippers are allowed to conduct discovery in order to gather evidence they need.
Labels Want Logs
The labels, for example, requested various documents and emails from the site operator, hoping to back up their claims. In addition, they want to know much more about how the site is used, including what files are downloaded by users, where these users are located, and what the source sites are.
The latter information could be easily stored in server log files. However, Mr. Kurbanov informed the labels that he has nothing to share. The requested data do not exist, he replied, noting that it would be ‘unduly burdensome’ to ‘create or produce’ them.
The response indicated that the stream-rippers simply don’t retain log files that save the requested information. Enabling extensive logging clearly goes a step too far for Mr. Kurbanov. However, the music companies disagree.
‘Rippers Should Preserve Logs’
In a filing submitted at the federal court in Virginia this week, the music companies request a court order that compels the server data to be logged and handed over to the labels.
“In the ordinary course of operations, Defendant’s Websites necessarily generate server data, including data that identifies: (a) the YouTube videos being stream-ripped; (b) the MP3 audio files being copied and distributed; and (c) the geographic locations of the users downloading the audio files,” they write.
“Respectfully, the Court should order Defendant to preserve and produce this key evidence.”
The Evidence Exists
In their motion, the labels argue that the requested evidence already exists. It is readily available, but simply not logged. This is a decision that was made by the operator.
“The problem is that Defendant has configured his server software to turn the logging function off — thus, continually overwriting important data that Plaintiffs explicitly requested in discovery.”
According to the labels, Mr. Kurbanov is not entitled to hide behind this business practice as a means to defeat his preservation obligations. Especially since it only requires minimal effort to start logging.
“It is a bedrock principle that, once a party is required to preserve existing evidence, the party must take affirmative steps to do so. The server data exists, and Plaintiffs simply ask that Defendant be ordered to preserve and produce that data,” the labels conclude.
The request is reminiscent of the piracy lawsuit several Hollywood studios filed against TorrentSpy, more than a decade ago. In that case, which is cited by the labels, a federal court ordered the torrent site to log all data stored in RAM.
Shortly after this court order, TorrentSpy decided to block all US visitors from accessing its site, referencing an uncertain legal climate in the US regarding user privacy.
Thus far, FLVTO.biz and 2conv.com have yet to respond to the request, but given their previous stance, it is likely that Mr. Kurbanov will fight it tooth and nail.
A copy of the record label’s memorandum in support of their motion to compel Mr. Kurbanov to preserve server logs is available here (pdf)