Leading items

The legality of file sharing services

The entertainment industry has been engaging in a long and fierce campaign to make the writing of certain kinds of software illegal. In their view, tools like DeCSS or Elcomsoft's eBook processor are to be outlawed simply because they can be used to violate copyrights. File sharing software has also been targeted by this industry for the same reasons; people can use that software to share copyrighted files. If the RIAA and MPAA have their way, unrestricted file sharing systems would come under the same sort of legal sanctions as DeCSS.

In this arena, however, the industry must work without one of its favorite weapons. File sharing networks just move bits around, they do not actively circumvent any sort of copy protection mechanism. As a result, they are not exposed to the anti-circumvention clauses of the DMCA. So file sharing networks must be fought with traditional copyright law. As last week's ruling in the Grokster et al. case (available in PDF format) shows, the studios are going to have a harder time. File sharing networks, when properly constructed, are legal.

What are the attributes of legal file sharing software? From this ruling, one concludes that such software must (1) have real non-infringing uses, (2) not be based on a central server architecture, and (3) not provide for control over what can or cannot be distributed through the network.

The court was quite clear that the simple potential to infringe copyrights was not enough to condemn the software or the companies distributing it:

Lawful uses of the software would not be enough, however, if the companies were actively involved in the distribution of copyrighted materials. The saving factor for the defendants here was that they do not maintain any sort of central server or index of the files available in the network, and are not involved in actual file transfers.

Just as relevant is the fact that the the defendants had no control over what their users were sharing:

This is a lesson which has been taught by the American courts more than once: control brings liability. If you do not have control over a system, you have a defense against liability for what others do with that system. There is no more convincing way of relinquishing control than by releasing the software under a free license.

The plaintiffs put forward the claim that better control should have been put into the defendants' software. The court did not buy it, however:

Current law, in other words, does not require that products be made in such a way that they cannot be used to infringe copyrights. Ed Felten has speculated that the entertainment industry will soon make efforts to change the law. This would be an unsurprising move, to say the least; that is, after all, what the CBDTPA would do. As one LWN commenter pointed out, pressing for that sort of law would break the RIAA's agreement with the BSA, where it said it would not push for further anti-copying measures. Relying on that agreement to hold sounds risky, however; chances are good that there will be new legislative efforts in the near future.

Comments (2 posted)

The Linux kernel and digital rights management

The entertainment industry is certain to continue its attempts to obtain the protection it wants from the Congress and the courts. But the industry is also very interested in technical means of enforcing limited access to its products. As Lawrence Lessig pointed out years ago, the software running on our systems is the other component of the code which constrains our actions. There's no shortage of people, governments, and corporations who would like to use that code to control (and monitor) what we can do with our systems and the products we purchase.

In most Linux users' view, there is little intersection between this sort of digital rights management (DRM) code and free software. After all, what's to keep us from simply yanking out any code which gets in the way of what we want to do? So some people were surprised when Linus Torvalds posted a message stating "I want to make it clear that DRM is perfectly ok with Linux!"

There is, you see, a scenario where DRM software can be embedded within the Linux kernel, and there is very little that can be done about it. It is not that hard to build hardware that refuses to boot a kernel which has not been signed with a particular private key. That kernel could restrict access to devices, or refuse outright to run applications which have not also been signed with a given key. Such a kernel could take away all of the control we would otherwise have over our systems whether we like it or not. Yes, whoever distributes the kernel must provide source, but, without the private key (and, thus, the ability to create a signed, binary kernel), a Linux user cannot make changes and get them to run on the target system.

Linus gives two reasons for his position: distributing signed binaries is acceptable under the GPL, and he does not want to be in a position of saying what can or cannot be done with the Linux kernel.

The GPL argument is interesting. Anybody who distributes a GPL-licensed program in binary form must make the associated source available. That source is defined by the GPL as:

One could well question whether a private key used to sign the binary is covered by this language. Most commenters seem to think that it is not. If the GPL has nothing to say about keys, then the distribution of signed binaries (without the associated private keys) is clearly within the bounds of the license.

If a private key is considered part of the program's installation scripts, there could be a problem. Linus has stated his opinion, but he cannot speak for the others who hold copyrights on code in the kernel. One of those people could conceivably mount a legal challenge should he or she object to the signed binary distribution. Kernel hackers in general seem uninclined to make this sort of challenge, but one never knows.

Linus's other reason - not wanting to regulate what others can do with Linux - goes to the core of the philosophy of free software. Any free (or open source) software definition will include a statement that the license cannot discriminate based on the use of the software. The purpose is to exclude licenses that, say, prohibit use by the military, by people with the wrong religion, citizens of certain countries, or drinkers of light beer. Similarly, Linus does not want to discriminate against those who would only allow certain software to run on their systems.

Besides, the techniques which implement DRM can also be used to implement a higher level of security for Linux users. A system that can only run signed executables is certainly going to be more secure than one which will run any binary presented to it. Some users may well want that kind of security, and they should be able to have it. It would be difficult to allow this sort of use while simultaneously forbidding DRM uses.

Ultimately, it comes down to what people are willing to buy. In an ideal world, Linux-based systems which implement oppressive DRM schemes would languish on the shelves, while those which are better suited to the needs and wishes of their users will succeed. The sad fact is that things often do not work that way; when products like DVD players, the Xbox, or Tivo are what's available, that is what people will buy. The marketplace does not work as well as one would like in this regard. But the GPL is not the tool that can fix it.

Comments (22 posted)

When "Free" Isn't Good Enough

[This article was contributed by Joe 'Zonker' Brockmeier]

The GNU Free Documentation License (GFDL) may not be suitable if you're hoping to have your documentation included in Debian "main." The nature of the problem is described in this proposed statement written by Anthony Towns. If adopted as an "official" statement from the Debian project, GFDL-licensed documents will find themselves excluded from the free portion of the Debian distribution.

The conflict between the GFDL and the Debian Free Software Guidelines (DFSG) comes in when the author includes "Invariant" sections or an Acknowledgements or Dedications section. These are described in section 4 of the GFDL. Essentially, the GFDL requires that these sections not be modified or removed, which goes against the (DFSG) requirement that a license "must allow modifications and derived works."

One may avoid the conflict by simply not including the sections that are troublesome, or by using another license. However, that may not satisfy some authors and definitely doesn't solve the problem for documents already accepted.

For many documents, this may not be a problem. If an author insists on using the GFDL and one of the troublesome sections, users can simply grab the documentation elsewhere or even as a Debian package just by getting the package from the "non-free" collection of Debian packages. However, when another program includes the documentation, it may make things a bit trickier. According to Richard Braakman the GFDL puts a "wall between documentation and code."

Braakman also raises a few other issues that he considers problematic with the GFDL. One that is interesting to note is the idea that "languages other than English are poorly supported."

One could ask whether the Debian project should make an exception for documentation. The rules that apply to code may not work so well for documentation, particularly when good documentation is even harder to come by than good code. The Debian developers are not known for compromising on their principles, however. It will be interesting to see what the final outcome of this discussion will be, but it looks entirely likely that the Debian project may decide that one of the GNU Free licenses is, in fact, not free enough.

Comments (6 posted)

Spam for Linux consultants

The Linux Consultants Guide (once the Consultants HOWTO) is a longstanding resource for Linux consultants who wish to get their names out to potential clients. In recent times, this guide has been maintained by the folks at Command Prompt; it is still part of the Linux Documentation Project collection.

It turns out that there is a price for being listed in the Guide, however: commercial email from Command Prompt. This mail contains the following text:

The only way to avoid receiving spam from Command Prompt, in other words, is to be removed from the Guide altogether.

We asked Command Prompt about this policy, and were told: "Nothing is truly free, not even Linux. You have to pay somewhere, whether it be mental/physical resources, money, time... but there is always a cost. Our cost to our listers is communication." They also noted that this policy "is not really published anywhere".

A commercial email every month or so could well be a fair price for inclusion in the consultants database. But people should be informed of the bargain before it is made. As it is, nobody who is receiving this commercial mail has actually agreed to be on that list. Given that the document's license also violates the Linux Documentation Project's guidelines (it prohibits distribution in printed or modified form), one could well ask if the Consultants Guide should still be part of the LDP collection.

Comments (2 posted)

Page editor: Jonathan Corbet
Next page: Security>>