25^th February 2002

Dear Sir

I wish to take the opportunity to comment personally on the Notice of proposed rulemaking for the use of Sound Recordings under Statutory License (Docket number RM 2002).

My expertise is in the area of the Internet and reception of ‘Internet Radio’ broadcasts. I was one of the principal architects of the (now) Symantec Enterprise Firewall and the Symantec VelociRaptor (see http://enterprisesecurity.symantec.com/products for more information on these products). I am also the author of the Internet Radio component of JReceiver (see http://jreceiver.sourceforge.net/ for more information).

The history of audio transmission using the Internet (and earlier packet networks) covers at least the last 20 years. There are two main types of transmission – unicast and multicast. A unicast transmission is like a telephone call – there is one party at each end of the connection, and information flows from one end to the other[1]. A multicast transmission is like conventional ‘over the air’ radio – there are multiple receivers and multiple (sometimes only one) transmitters. The protocols used to implement these two styles of communication have significant differences. In particular, in a multicast transmission, the transmitter does not know the identities of the receivers or even how many there are. One of the protocols under active development for multicast that focuses on a single transmitter and multiple receivers is Source-Specific Multicast (see http://search.ietf.org/internet-drafts/draft-ietf-ssm-arch-00.txt for more information). This protocol is ideally suited for Internet Radio broadcasters. It is supported (and already implemented) by Cisco in their routers.

For example, if a transmitter wants to transmit a 32,000 bit per second audio transmission to 1,000 receivers using unicast technology, they would need an Internet connection capable of handling 32,000,000 bits per second. However, if they used multicast technology, then they would need an Internet connection capable of handling 32,000 bits per second. The capacity required at the transmission end scales linearly with the number of receivers using unicast, and is constant when using multicast.

I shall restrict my comments to the aspects of the notice of proposed rulemaking that deal with nonsubscription transmission services. The whole structure of the proposed rules makes it clear that only unicast transmissions have been considered. With a unicast transmission, it is possible to count the number of receivers and when they start receiving and stop receiving. It is possible to identify those receivers to the IP (Internet Protocol) address – this can be converted into the users name and address if the user’s Internet Service Provider provides that information (which they will under a subpoena). With a multicast transmission, there is no single[2] entity in the Internet that knows how many receivers there are currently active.

The vast majority of nonsubscription transmission services today use unicast transmission. The technology is more widely available, and the receivers are more widely deployed. I anticipate that within five years, the situation will be completely reversed, with the overwhelming majority using multicast. This change will come about due to the dramatic cost savings in bandwidth of using multicast technology.

Once a nonsubscription transmission service starts to use multicast technology, then it is technically unable to provide the information about its listeners as would be required under this proposed rule. Note also that once multicast receivers start to become widely deployed, then they can be used to receive transmissions from anywhere in the world without requiring large quantities of international bandwidth. This fact alone might cause the mass migration of nonsubscription transmission services to move offshore[3] to a laxer regulatory environment. The physical location would not impact their listeners at all – in fact their listeners would be unable to determine the country of transmission.

The current proposed fees are payable per performance (i.e. per listener). It is not possible to calculate these fees once the transmission service moves to multicast technology. I propose that two schedules of fees be established – one is per listener (which looks like the current schedule), and the other is per song transmission (hereinafter called ‘flat rate’). The latter schedule would probably have very similar fees as are currently paid by conventional AM/FM radio stations. The reporting requirements for the latter schedule would mirror those for AM/FM radio stations. I propose that a licensed nonsubscription transmission service be able to choose which fee schedule (and hence which set of reporting requirements) is most appropriate[4] for them. They should be able to change their election on a yearly basis.

The issue of nonsubscription transmission services using multicast technology to communicate with their listeners is serious, and must be covered in those proposed rules. There are many potential approaches to this problem that preserve the current fee schedule – ranging from treating a multicast transmission as having no listeners[5], just a single listener, or some arbitrary number of listeners like 10,000[6]. The other approaches abandon the current fee schedule and add a new one for multicast transmission.

I would like to comment on the list of information required about the listeners – the Listener’s Log. As far as I can tell, the log is required for two purposes: to determine the amount of fees to be paid to each copyright holder, and for audit purposes.

The information required to determine the fees to be paid to each copyright holder are the start and end time of each connection (at the transmitter) and a reference to the playlist. This allows the performances and copyright holders to be determined.

The information required for audit is just the start and end time of the connection. In this way, a connection made for audit purposes[7] can be matched up (or not!) against the listener’s log provided. To perform this matching, some level of accuracy should be stated in the proposed rules for all times and dates.

In particular, the country[8] in which the user received the transmission should not be recorded (apart from the fact that this is technically impossible[9]), and neither should a unique identifier (but since this is assigned to a session, this could just be a record number in the listener’s log. Since this supplies no useful information it is hard to see why it is required.)

The various assorted time and date formats specified in the proposed rules cause problems – in particular the requirement that the Listener’s Log be in the time zone of the listener (this is not technically possible[10]). I propose that all times and dates conform to the ISO Standard 8601 (see http://www.cl.cam.ac.uk/~mgk25/iso-time.html for more information) and are represented with an explicit timezone indicator. The timezone indicator does not have to correspond to the local timezone. Most transmitters would probably use Coordinated Universal Time[11] (UTC).

The required information for the playlist is also unduly burdensome. I propose that as an alternative to providing the sound recording title, the ISRC, the release year, the featured artist, the album title, the recording label, the UPC code, the catalog number and the copyright information, that the transmitter be permitted to provide the Secure Hash (FIPS 180-1) (see http://www.itl.nist.gov/fipspubs/fip180-1.htm for more information) of the (say) first 30 seconds of the sound recording. This uniquely identifies all the fields listed above. It is easily generated by the nonsubscription transmission service, and can be converted by the copyright agent into the required information[12].

I will comment only in passing on the inequity of considering Internet nonsubscription transmission services as different in kind to AM/FM radio stations. If these rules were proposed for AM/FM radio stations, then it would require that all radio receivers report (somehow) which stations they were tuned to, and for how long. In order to ensure that all radio receivers performed this function, they would need to be licensed and type approved by (probably) the FCC. Do you suppose that such a set of rules would not be under review in federal court for First Amendment violations almost immediately?

The current set of reporting requirements for the Listener’s Log requires that all receivers report their local timezone and country and potentially a ‘unique identifier assigned to a particular user’. Given that the proposed rule does not cover authors of such receiver software, it is difficult to see how this reporting will be achieved, unless there is future regulation planned to force receiver software authors to build in this capability, and presumably import control measures to ensure that all imported receiver software complied with these regulations.

Finally I wish to comment on the possibilities for fraud encouraged by this proposed rule. Under the current fee schedule, the nonsubscription transmission services pay at least 0.07¢ per performance. Assuming that a fraudster[13] could cut a deal with a copyright agent or even with a copyright holder to get half of any incremental revenue that the fraudster could generate, does the fraudster have a viable business opportunity?

Assuming that each performance lasts 3½ minutes, then the fraudster gets 0.01¢ per minute. If the fraudster purchases a server at a major server hosting facility with a 100,000,000 bit per second connection, then he can pretend to be approximately 3,000[14] simultaneous listeners[15] (either to the same or different nonsubscription transmission services). This brings him revenue of 30¢ per minute or $13,000 per month. I estimate that this bandwidth will cost the fraudster around $1,000 per month – note that unlike most servers at hosting facilities, this one is receiving data rather than transmitting data. This makes it probable that he can cut an even better deal.

Thus, our putative fraudster can net over $140,000 per year with a single computer and some custom software. He can, of course, replicate this solution for as long as he can find copyright holders or copyright agents to pay him.

The only way of preventing such activity is to remove the source of revenue for the fraudster. Unfortunately, the record companies are well known for paying to get tracks played on the AM/FM radio – at least the money now travels through middlemen rather than directly to the stations as it did before the big payola scandals. This suggests that cutting off the incentive of the copyright holder or copyright agent to cut a deal with the fraudster is best way of dealing with the problem. The only way to eliminate that incentive is to prevent the actions of the fraudster from changing the amount of money that the copyright holders or copyright agents receive. This suggests that the fees paid by the transmission services should not be dependant on the number of listeners.

In conclusion, my principal recommendations from the discussion above are:

a) The existing fee schedule is augmented by a second, flat rate, fee schedule that does not depend on the number of listeners. The transmission service be allowed to choose which schedule to use; or

b) The existing fee schedule is replaced by a flat rate fee schedule that does not depend on the number of listeners.

c) In the event that the transmission service chooses the per listener fee, the information provided in the Listener’s Log is cut down to purely the playlist reference, and the start and stop times (in any timezone).

d) In the event that no flat rate fee schedule is added, that a clause is added stating that if a transmission service uses multicast technology and does not know how many listeners there are, then this is considered to be one single listener for performance fee purposes; or

e) In the event that no flat rate fee schedule is added, that a technically feasible mechanism is defined in the proposed rules to calculate fees payable for transmission services using multicast technology.

Thank you for giving me the opportunity to contribute to this important decision.

Yours truly,

Philip Gladstone

Enc: 10 copies

[1] Unicast connections can be combined together in a tree and branch system (see http://www.allcast.com/?technology for an example), in such a way that the identity and number of receivers is not reliably known.

[2] The information is distributed across the entire Internet. There are no current protocols to obtain this information, and if such protocols were implemented, the requester of the information could not be sure that the information received would be accurate anyway.

[3] It is unclear from the proposed rules what aspects of the nonsubscription transmission service need to be offshore to not be subject to the requirement to pay performance fees. Given the location transparency inherent in the Internet, this ought to be clarified.

[4] In reality I would expect most serious broadcasters to choose the flat rate schedule as it makes budgeting much easier – the broadcaster cannot be financially surprised by a sudden increase in demand a.k.a. the Slashdot Effect (see http://ssadler.phy.bnl.gov/adler/SDE/SlashDotEffect.html and http://pasadena.wr.usgs.gov/office/stans/slashdot.html for more information)

[5] There might be no listeners at any specific instant in time.

[6] This is a reasonable number of listeners to an AM/FM station.

[7] I would hope that copyright fees paid for audit testing calls would be refunded to the nonsubscription transmission service. If not, then there is an incentive for the copyright agent to make a large number of such calls. I propose that a list of these calls be provided to the transmission service, or that the receiver used to make such audit calls specifically identify itself as making an audit test call – though that might rather defeat its own purpose!

[8] I’m assuming that the country of reception makes no difference to the fees paid – in particular it is the country of origin of the transmission that controls the fees.

[9] There is no technical way for one end of a unicast connection on the Internet to determine the physical location of the other end. The only way of doing this (inside the US) is to use the court system and issue subpoenas.

[10] Given that the transmitter does not know where the receiver is, it is not possible to determine the timezone at the receiver’s location. Even with physical location information (say to the closest City and Country), it is not easy to determine the timezone in effect – what is current timezone for Funafuti, Tuvalu? (See http://nist.time.gov/images/TimeZoneMap2000.gif for the complexities)

[11] The official timebase of the US (non military uses) is UTC(NIST). This is equivalent to UTC for nearly all practical purposes. GMT is no longer used. (See http://www.boulder.nist.gov/timefreq/general/government.htm for more information)

[12] This would merely require the copyright holders to produce the list of hash codes along with any other information that they wanted.

[13] I refer to this individual as a fraudster – but it is not clear that he is actually breaking any laws. He is just exploiting a system that is ripe for exploitation.

[14] 3,000 listeners are calculated from the 100,000,000 bits per second connection speed divided by 32,000 bits per second per listener.

[15] This assumes that the fraudster has to consume all the data sent as part of the transmission. It might be possible (with some cunning) to avoid receiving the data of the transmission, thereby increasing dramatically the number of simultaneous listeners.