IAAL* : Peer-to-Peer File Sharing and Copyright Law after Napster
by Fred von Lohmann
Attorney-at-Law and Visiting Researcher
Berkeley Center for Law & Technology
What this is, and who should read it.
As the Napster saga illustrates, the future of peer-to-peer file-sharing is entwined, for better or worse, with copyright law. The legal fight has already broken out, with copyright owners targeting not only the makers of file-sharing clients like Napster and Scour, but also companies that provide products that rely on or add value to public P2P networks, such as MP3Board.com, which provides a web-based search interface for the Gnutella network.
The fight has only just begun. If these early skirmishes yield any lesson for future P2P developers, its that a legal strategy needs to be in place early, preferably at the beginning of development, rather than bolted on at the end. As a result, if you are interested in peer-to-peer file sharing, whether as a developer, investor, or provider of ancillary services (such as search services, platform tools, or security), its time to bone up on some copyright law basics.
This piece is meant as a general explanation of the U.S. copyright law principles most relevant to P2P file-sharing technologies. It is aimed primarily at:
The following discussion is meant as a general introduction, and thus occasionally glosses over some of copyright laws more subtle nuances. At the most basic level, it is aimed not at giving you all the answers, but rather at allowing you to recognize the right questions to ask your lawyers.
What this is not: The following discussion focuses only on U.S. copyright law, and does not address any issues that may arise under non-U.S. law. While non-copyright principles may also be mentioned, this discussion does not attempt to examine other legal principles that might apply to P2P file-sharing, including patent, trademark, trade secret, or unfair competition. Nothing contained herein constitutes legal adviceplease discuss your individual situation with your own attorney.
Copyright Basics and the Intersection with P2P Filesharing
Copyright law applies to virtually every form of expression that can be captured (or, to use the copyright term of art, fixed) in a tangible medium, such as on paper, film, magnetic tape, hard drive, optical media, or even merely in RAM. Songs, books, photographs, software, and movies are all familiar examples of copyrighted works. Copyright protection begins from the moment that the expression is fixed, and continues for the lifetime of the author, plus 70 years.
During this period, copyright law reserves certain rights exclusively to the owner of the work, including the right to reproduce, distribute, and publicly perform the work. So, for example, if you wrote a song and recorded it on your computer, you would own the resulting copyrighted work and only you would have the right to make copies of the file, distribute it to the public, or sing the song in your local concert hall. If anyone else did any of these things without your permission, she would be infringing your copyright (unless the activity qualified as a fair use or fell into one of the other statutory exceptions to a copyright owners exclusive rights).
The nature of digital file-sharing technology inevitably implicates copyright law. First, since every digital file is fixed for purposes of copyright law (whether on a hard drive, CD, or merely in RAM), the files being shared generally qualify as copyrighted works. Second, the transmission of a file from one person to another results in a reproduction, a distribution, and possibly a public performance (in the world of copyright law, public performance includes the act of transmitting a copyrighted work to the public). To a copyright lawyer, every reproduction, distribution, and public performance requires an explanation, and thus file-sharing systems seem suspicious from the outset.
The end-users: direct infringement.
For the individuals who are sharing files, the question becomes whether all of these reproductions, distributions, and public performances are authorized by the copyright owner or otherwise permitted under copyright law (as fair use, for example). So, if the files you are sharing with your friends are videos of your vacation, you are the copyright owner and have presumably authorized the reproduction, distribution, and performance of the videos. However, if you are sharing MP3s of Metallicas greatest hits, or disc images of the latest Microsoft Office 2000 installation CD, the issue becomes more complicated. In that case, assuming that the copyright owner has not authorized the activity, the question of copyright infringement will depend whether you can qualify for any of the limited exceptions to the copyright owners exclusive rights. If not, youre what copyright lawyers call a direct infringeryou have directly violated one or more of the copyright owners exclusive rights.
The P2P tool maker: contributory and vicarious infringement.
But what does this have to do with those who develop and distribute peer-to-peer file-sharing tools? After all, in a pure peer-to-peer file-sharing system, the vendor of the file-sharing tool has no involvement in the copying or transmission of the files being shared. These activities are handled directly between end-users. Copyright law, however, can sometimes reach beyond the direct infringer to those who were only indirectly involved in the infringing activity. As in many other areas of the law (think of the wheel man in a stick up, or supplying a gun to someone you know is going to commit a crime), copyright law will sometimes hold one individual accountable for the actions of another. So, for example, if a swapmeet owner rents space to a vendor with the knowledge that the vendor sells counterfeit CDs, the swapmeet owner can be held liable for infringement alongside the vendor.
Under copyright law, this indirect, or secondary, liability can take two distinct forms: contributory infringement and vicarious infringement. In order to prevail under either theory, the copyright owner must first show that some underlying direct infringement has taken place. In other words, there must be a direct infringer before anyone will be indirectly liable. In a widely-used public peer-to-peer file-sharing environment, however, it is a virtual certainty that at least some end-users are engaged in infringing activity (unless specific technical measures are taken to prevent this, like permitting only the sharing of files that have been cryptographically marked as authorized). When the major record labels and music publishers decided to sue Napster, for example, it was not difficult for them to locate a large number of Napster users who were sharing copyrighted music without authorization.
Contributory infringement is similar to aiding and abetting liability: one who knowingly contributes to anothers infringement may be held accountable. Or, as the courts have put it, one who, with knowledge of the infringing activity, induces, causes, or materially contributes to the infringing conduct of another, may be held liable as a contributory infringer. So, in order to prevail on a contributory infringement theory, a copyright owner must prove each of the following elements:
Vicarious infringement is derived from the same legal principle that holds an employer responsible for the actions of its employees. A person will be liable for vicarious infringement if he has the right and ability to supervise the infringing activity and also has a direct financial interest in such activities. Thus, in order to prevail on a vicarious infringement theory, a copyright owner mush prove each of the following:
It should be noted that the nature of vicarious infringement liability creates a strong incentive to monitor the conduct of your users. This stems from the fact that knowledge is not required for vicarious infringement liability; a person can be a vicarious infringer even if they are completely unaware of infringing activity. As a result, if you exercise control over your users and derive a benefit from their activities, you remain ignorant of their conduct at your own risk. In the words of the Napster court, the right to police must be exercised to the fullest extent. Turning a blind eye to detectable acts of infringement for the sake of profit gives rise to liability.
Indirect Liability and P2P Systems: the Napster Case
The Napster case represents the first application of these indirect liability theories to a peer-to-peer file-sharing service. In that case, the plaintiffs admitted that Napster did not, itself, make or distribute any or their copyrighted works. Instead, they argued that Napster is liable for contributory and vicarious infringement. In its February 12, 2001 opinion, the Ninth Circuit agreed, rejecting each of Napsters proposed defenses.
Turning first to contributory infringement, the Ninth Circuit upheld the lower courts findings:
The Ninth Circuit also endorsed the lower courts vicarious infringement analysis:
The Ninth Circuit concluded, however, that the lower court had not adequately considered the technological limits of the Napster system when crafting the preliminary injunction. In ordering the district court to revise its injunction, the Ninth Circuit spelled out some guiding principles. First, in order to prevent contributory infringement, after receiving notice from a copyright owner that a work is being shared on its system without authorization, Napster will have to take reasonable steps to prevent further distribution of the work. Although the particulars will be up to the lower court, this almost certainly will require that Napster implement file-name filtering to its central index. It may also require that Napster implement more sophisticated filtering based on MP3 ID tags, MD5 hashes, acoustic fingerprints, or other meta-data.
Second, in order to prevent vicarious infringement, the Ninth Circuit declared that Napster bears the burden of policing its system within the limits of the system. Again, the particulars of this command will be determined by the lower court. Nevertheless, this will almost certainly require some pro-active monitoring activity by Napster. Since, in the courts view, Napster controls its users, Napster will likely be required to take reasonable measures to keep tabs on what those users are up to, within the bounds of its system architecture. At a minimum, this will require that Napster pro-actively monitor its central index to weed out any songs that it knows are not authorized for sharing. It will also require that Napster continue to terminate users who share copyrighted works without authorization.
Potential Defenses Against Contributory and Vicarious Liability
No Direct Infringer: All of My Users are Innocent Fair Users
As discussed above, if there is no direct infringement, there can be no indirect liability. Consequently, if a peer-to-peer developer can plausibly claim that no users in the network are sharing copyrighted works without authorization, this would be a complete defense to any contributory or vicarious infringement claims. Unfortunately, this may be extremely difficult to demonstrate, given the decentralized nature of most P2P networks and the wide variety of uses to which they may be put. Even if file sharing by some users is privileged under the fair use doctrine or another statutory exception to copyright, it will be very difficult to show that every user falls within such an exception. Nevertheless, in certain specialized networks that permit the sharing of only secure, authorized file types, this may be a viable defense.
Capable of substantial noninfringing uses
Although contributory and vicarious infringement can sweep broadly, catching even those only indirectly involved in the copyright infringement of others, the Supreme Court has defined an outer limit to this reach. In a case involving the Sony Betamax VCR, the Supreme Court found that contributory infringement liability could not reach the manufacturer of a device that is capable of substantial noninfringing use.
Universal City Studios and Disney were on one side of this case, arguing that the Sony Betamax VCR was a tool of copyright infringement. On the other side were Sony, its advertising agent, several of its retail distributors, and one individual VCR user. The case ultimately made its way to the Supreme Court, which ultimately issued a 5-4 decision that proceeded in two parts. First, the Court held that there could be no contributory liability, even if some VCR users were engaged in copyright infringement, so long as the device was capable of a substantial noninfringing use. In the second part of its opinion, the Court found that the VCR was capable of several such noninfringing uses, including the time-shifting of television broadcasts by home viewers.
Unfortunately, the recent Ninth Circuit decision in the Napster case has dramatically reduced the scope of the Betamax defense. First, the Napster court found that this defense does not apply to vicarious infringement liability. Accordingly, if you have control over, and derive a financial benefit from, direct infringement, the existence of substantial noninfringing uses for your service is irrelevant. Second, the court concluded that the Betamax defense only applies until specific information identifying infringing activity has been received. At that point, a failure to act to prevent the infringing activity will give rise to liability, and the existence of substantial noninfringing uses becomes irrelevant.
The Ninth Circuits interpretation of the Betamax defense has at least two important implications for P2P developers. First, it underscores the threat of vicarious infringement liabilityat least in the Ninth Circuit, a court will not be interested in hearing about your substantial noninfringing uses if you are accused of vicarious infringement. Accordingly, control and direct financial benefit, as described above, should be given a wide berth. This will likely reduce the attractiveness of business models built on an on-going service or community-building model, to the extent that these models allow the provider to control user activity (i.e., terminate or block users) and create value by attracting a large user base. At the same time, it may increase the attractiveness of selling completely decentralized file-sharing software, insofar as this might minimize the vendors control over, and continuing direct financial benefit from, infringing uses.
Second, with respect to contributory infringement, the Ninth Circuits interpretation of the Betamax defense makes it risky to ignore cease and desist letters from copyright owners, which in turn may limit a developers freedom to define the architecture of her product or service. Once you have received notice of specific infringing activity, your substantial noninfringing uses may no longer serve as a shield to contributory liability. Of course, even the Ninth Circuit recognized that the ability to respond to these notices may be limited by the technology behind the challenged service or product. Nevertheless, when a court is required to determine the limits of what is technically reasonable, the results can be uncertain. The Napster decision certainly suggests that copyright owners, once they make out a case of contributory or vicarious infringement liability, are in a position to demand that a developer of P2P tools take steps to reduce the likelihood that it will be used for infringing activity. What these steps might entail is difficult to predict, but may include, in some cases, modification of the architecture and capabilities of the tool, service or system.
The DMCA Section 512 safe harbors
In 1998, responding in part to the concerns of ISPs regarding their potential liability for the copyright infringement of their users, Congress enacted a number of narrow safe harbors for copyright liability. These safe harbors appear in section 512 of the Copyright Act, which in turn appears in title 17 of the U.S. Code (17 U.S.C. 512). These safe harbors apply only to online service providers, and only to the extent that the infringement involves four functions: transitory network transmissions, caching, storage of materials on behalf of users (e.g., web hosting, remote file storage), and the provision of information location tools (e.g., providing links, directories, search engines).
Each of these functions, however, is narrowly defined by the statute (e.g., they dont cover what youd think) and reflects the state of the art in 1998. For example, the automated web page caching conducted by AOL in 1998 falls within the caching safe harbor, while the more sophisticated efforts of Akamai today may not. Because Congress did not anticipate peer-to-peer file sharing when it enacted the safe harbors, many P2P products may not fit within the four enumerated functions. For example, according to an early ruling by the district court in the Napster case, an OSP cannot use the transitory network transmission safe harbor unless the traffic in question passes through its own private network. Many P2P products will, by their very nature, flunk this requirement, just as Napster did.
In addition to being limited to certain narrowly-circumscribed functions, the safe harbors are only available to entities that comply with a number of complex, interlocking statutory requirements:
In the final analysis, qualifying for any of the DMCA safe harbors requires careful advance attention to the legal and technical requirements and obligations that the statute imposes. As a result, any P2P developer who intends to rely on them should seek competent legal counsel at an early stage of the development processan after-the-fact, bolt on effort to comply is likely to fail (as it did for Napster). For more detailed information regarding the limits and requirements of the safe harbors, you might consult the overview located at http://www.richmond.edu/jolt/v6i4/article1.html.
The DMCA ban on circumvention technologies
One recent addition to the copyright landscape deserves special attention. Section 1201 of the Copyright Act, enacted as part of the DMCA, makes it unlawful to circumvent any technology aimed at protecting a copyrighted work. In addition, the development, distribution or use of circumvention technology or devices is, with only narrow exceptions, also unlawful. For example, if a copyright owner uses a digital rights management (DRM) solution to protect a song, it would be unlawful for anyone to crack the encrypted file without the copyright owners permission, or to build or distribute a software tool designed to crack the file. The litigation involving DeCSS software, which is capable of decrypting video DVDs, represents one of the first cases testing these anti-circumvention provisions of the DMCA.
Of course, circumvention technology is not a necessary part of a peer-to-peer file-sharing network. Todays P2P protocols, such as Gnutella, simply facilitate file transfers, leaving the file itself, whether encrypted or not, unaltered. Nevertheless, as copyright owners begin to deploy DRM and watermarking systems, there may be interest in integrating circumvention tools with file-sharing tools. In light of the DMCAs broad ban on circumvention technology, however, any such integration may substantially increase the risk of liability.
Lessons and Guidelines for P2P Developers
A few general guidelines for P2P developers can be derived from the discussion above. These are steps you can take that may: (1) reduce the chance that your project will be an easy, inviting target for copyright owners; (2) placate your investors when they ask you whether you are likely to spend their money on litigation rather than products; and (3) minimize the chances that your case will become the next legal precedent that content owners can use to threaten future innovators.
Of course, because the relevant legal principles are still in flux, these guidelines represent merely one, general analysis of the legal landscapeplease consult with an attorney regarding your precise plans.
1) Your two options: total control or total anarchy.
In the wake of the Napster decision, it appears that copyright law has foisted a binary choice on P2P developers: either build a system that allows for thorough monitoring and control over user activities, or build one that makes such monitoring and control completely impossible. This conclusion stems from the Ninth Circuits analysis of contributory and vicarious liability in the Napster case.
As discussed above, contributory infringement requires that you have knowledge of, and materially contribute to, someone elses infringing activity. In most cases, it will be difficult to avoid material contributionafter all, if your system adds any value to the user experience, you probably have materially contributed to any infringing user activities. So the chief battleground on contributory infringement will likely be on the knowledge issue. The Napster courts analysis suggests that once you receive notice that your system is being used for infringing activity (e.g., a cease and desist letter from a copyright owner), you have a duty to do something to stop it. What might that something be? Well, it will be limited by the architecture of your system, but may ultimately be decided by a court. So, in order to avoid the unpleasant surprise of a court telling you to re-engineer your technology to stop your infringing users (as happened to Napster), you can either include mechanisms that enable monitoring and control of user activities (and use them to stop allegedly infringing activity when you receive complaints), or choose an architecture that will convince a judge that such monitoring and control is impossible.
The Napter courts vicarious liability analysis also counsels for either a total control or total anarchy approach. Vicarious liability requires that you control, and receive benefit from, someone elses infringing activity. The benefit element will be difficult to resist in many P2P casesso long as the system permits or enables the sharing of infringing materials, this will serve as a draw for users, which can be enough benefit to result in liability. So the fight will likely center on the control element. The Napster court found that the right to block a users access to the service was enough to constitute control. The court also found that Napster had a duty to monitor the activities of its users to the fullest extent possible. Accordingly, in order to avoid vicarious liability, a P2P developer would be wise to either incorporate mechanisms that make it easy to monitor and block infringing users, or choose an architecture that will convince a judge that monitoring and blocking is impossible.
2) Better to sell stand-alone software products than on-going services.
As discussed above, vicarious liability is perhaps the most serious risk facing P2P developers. Having the power to terminate or block users constitutes enough control to justify imposing vicarious liability. Add financial benefit in the form of a business model that depends on a large user base, and youre well on your way to joining Napster as a vicarious infringer. This is true even if you are completely unaware of what your users are up tothe pairing of control and financial benefit are enough. Of course, most service business models fit this control and benefit paradigm. What this means is that, after the Napster decision, if you offer a service, you may have to monitor your users if you want to escape liability. If you want to avoid monitoring obligations, youll have to give up on control. Its time to set aside all the lessons youve learned about the importance of relationships in the New Economy. If your system may be used for infringement, and this capability is a draw for users, youve already crossed the benefit threshold. In order to avoid vicarious liability for those infringing uses, you will need to give up any control over users.
Vendors of stand-alone software products may be in a better position to resist monitoring obligations and vicarious infringement liability. After Sony sells a VCR, it has no control over what the end-user does with it. Neither do the makers of photocopiers, optical scanners, or audio cassette recorders. Having built a device with many uses, only some of which may infringe copyrights, the typical electronics manufacturer has no way to terminate end-users or block their ability to use the device (but look out for those shrinkwrap software license terms permitting unilateral vendor termination). Not coincidentally, these manufacturers also typically dont get sued (at least not yet) by copyright owners. The key here is to let go of any control you may have over your usersno remote kill switch, contractual termination rights, or other similar mechanisms.
3) Can you plausibly deny knowing what your end-users are up to?
Assuming that you have escaped vicarious infringement by eliminating control or financial benefit, there is still the danger of contributory infringement. To avoid liability here, you will need to address whether you knew, or should have known, of the infringing activity of your users. Have you built a level of plausible deniability into your product architecture and business model? If you promote, endorse, or facilitate the use of your product for infringing activity, youre asking for trouble. Similarly, software that sends back usage reports may lead to more knowledge than you want. Instead, talk up all the great legitimate capabilities, sell it (or give it away), and then leave the users alone. Again, the choices are total control, or total anarchy (see #1 above).
There are other good reasons for designing deniability into your product or system. First, it protects your users and, depending on your architecture, hosts or nodes as well. If youre not collecting information about what theyre doing, no one can get that information from you. Thats important for reasons that have little to do with copyright infringement. By not collecting user information, peer-to-peer networks can promote free speech and privacy. Remember the FBIs Library Awareness Program? Dont make yourself a target for subpoenas if you dont have to.
4) What are your substantial noninfringing uses?
If your product is intended to work solely as a mechanism for copyright piracy, youre asking for legal trouble. More importantly, youre thinking too small. Almost all peer-to-peer systems can be used for many different purposes, some of which the creators themselves fail to appreciate. So create a platform that lends itself to many uses, or, to paraphrase William Gibson, let the street find its own uses for things. For example, if youre developing a file-sharing system or distributed search engine, support all file types, not just MP3 or Divx files. Actively, sincerely, and enthusiastically promote the noninfringing uses of your product. And dont promote any infringing uses.
The existence of real, substantial noninfringing uses will increase the chances that you can invoke the Betamax defense if challenged in court. As discussed above, however, it is worth noting that this defense will only help you until the copyright owner delivers a cease and desist letter notifying you of specific infringing activity. At that point, the Betamax defense may evaporate, and may leave you with an obligation to make a reasonable effort to stop the infringement. What this means will depend on the architecture of your system and the whims of the court.
5) Disaggregate functions.
Separate different functions and concentrate your efforts on a discrete area. In order to be successful, peer-to-peer networks will require products to address numerous functional needssearch (e.g., OpenCOLA), security (e.g., Intels security toolkit), dynamic file redistribution (e.g., Freenet), to take a few examples. Theres no reason why one entity should try to do all of these things. In fact, the creation of an open set of protocols, combined with a competitive mix of interoperable, but distinct, applications is probably a good idea, from a product-engineering point of view.
This approach may also have legal advantages. If Sony had not only manufactured VCRs, but also sold all the blank video tape, distributed all the TV Guides, and sponsored clubs and swap meets for VCR users, the Betamax case might have turned out differently. Part of Napsters downfall was its combination of indexing, searching, and file sharing in a single piece of software. If each activity is handled by a different product and vendor, on the other hand, each entity may have a better legal defense to a charge of infringement.
A disaggregated model, moreover, may limit what a court can order you to do to stop infringing activity by your users. For example, if a search engine that trawls the P2P network space were to be held contributorily or vicariously liable for facilitating access to copyrighted works, the search engine company would not be able make any changes to an anonymized, secure file-sharing product that was developed by a different company. As the Napster court recognized, you can only be ordered to police your own premisesthe smaller it is, the less you can be required to do.
Finally, certain functions may be entitled to special protections under the safe harbor provisions of the Digital Millennium Copyright Act (DMCA). Search engines, for example, enjoy special DMCA protections. Thus, the combination of a P2P file sharing application with a third party search engine might be easier to defend in court than Napsters integrated solution.
6) Dont make your money from the infringing activities of your users.
Avoid business models that rely on revenue streams that can be directly traced to infringing activities. For example, if you are developing a peer-to-peer auction system, do not take a percentage cut on transactions completed through the system. To take another example, a peer-to-peer file sharing system that includes a payment mechanism might pose similar problems, if the system vendor takes a percentage cut of all payments, including payments generated from sales of bootleg Divx movie files.
Of course, in the wake of the Napster decision, the mere fact that infringing material may act as a draw, thus increasing your user base, might be enough to trigger vicarious liability. Nevertheless, there is nothing to be gained by building your business on a financial benefit even more directly linked to infringing activity by usersyoull only be making it that much easier for copyright owners to shut you down.
7) Be open source.
In addition to the usual litany of arguments favoring the open-source model, the open source approach may offer special advantages in the peer-to-peer realm. It may be more difficult for a copyright owner to demonstrate control or financial benefit with respect to an open source product. After all, anyone can download and compile open source code, and no one has the ability to terminate or block access or otherwise control the use of the resulting applications. Financial benefit may also be a problematic concept where the developers do not directly realize any financial gains from the code (as noted above, however, the Napster court has embraced a very broad notion of financial benefit, so this may not be enough to save you). Finally, by making the most legally dangerous elements of the P2P network open source (or relying on the open source projects of others), you can build your business out of more legally defensible ancillary services (such as search services, bandwidth enhancement, file storage, file meta-data services, etc.).
8) Do not be a direct infringer: make and store no copies.
This one may be obvious, but remember that if you make or distribute any copies (even if only in RAM) of copyrighted works, you may be held liable as a direct infringer. In that case, many of the defenses discussed here will not be available to you. The court will not be interested in control or knowledge or financial benefit or material contribution. If you made copies, youre probably liable for infringement. Of course, this shouldnt be a problem for most P2P developers, since the great insight of peer-to-peer architectures is that the actual resources being shared need not pass through any central server. Nevertheless, be careful where caching or similar activities are concerned.
9) Do not build any circumvention devices into your product.
Avoid incorporating into your product any technology designed to circumvent a protection measure meant to protect the rights of copyright owners. For example, do not incorporate any code into your product that is intended to crack the CSS encryption system used on DVDs, bypass the protection scheme used on Sony Playstation video games, or strip the no copy flags out of streaming RealAudio files. Whatever you may think about the merits of this work, leave it to others. Youll have enough worries without adding circumvention liability to the list.
10) Dont use someone elses trademark in your name.
This tip does not relate to copyright, but rather trademark law. Its also good common sense. Many early peer-to-peer products are attempting to capitalize on the notoriety of Napster by incorporating portions of the Napster name into their productsNapigator, OpenNap, and AIMster, to name a few. Napster has shown itself to be a strong defender of its trademark rights, having threatened legal action against a variety of unauthorized Napster merchandise vendors. Gnutella may also be a dangerous name to appropriate, as it is not clear who owns it (AOL?), and whether the owners of the Nutella trademark may at some point assert their own trademark rights. And remember that AppleSoup, for example, was forced to changed its name to FlyCode after receiving pressure from Apple Computer.
Good luck, and change the world!
* * *
About the Author: Fred von Lohmann is an attorney working as a visiting researcher with the Berkeley Center for Law & Technology, a research center associated with the Boalt Hall School of Law at UC Berkeley. His current research is focused on the impact of peer-to-peer technologies on the future of copyright. He also continues to maintain a relationship with Morrison & Foerster LLP (www.mofo.com), where prior to joining the Center he was an associate with a practice concentrated on transactions and counseling involving copyright, the Internet, and information technology. His primary legal interests lie at the intersection of copyright law and the Internet, including issues relating to online music distribution and the application of the Digital Millennium Copyright Act (DMCA) to Internet businesses. He has worked with a variety of Internet clients, including Yahoo!, Verio, Myplay, Riffage, Voquette, iUniverse.com, SpikeRadio and NBCi.
Copyright Information: Permission to reproduce and distribute this paper is freely given, provided that such activities are for noncommercial purposes and include attribution to the author. All other rights reserved. Contact the author at fred@vonLohmann.com for all other permissions.
* Acronym for I am a lawyer, to distinguish from the common IANAL (I am not a lawyer) that appears on Slashdot and other online forums.
© 2001 Fred von Lohmann v. 1.0
Please send any questions or comments to firstname.lastname@example.org.