|
|
Subscribe / Log in / New account

The StorageTek DMCA decision

Last year, StorageTek (soon to be a subsidiary of Sun) brought a suit against Custom Hardware Engineering, alleging copyright and DMCA violations. CHE is a third-party maintenance vendor which was offering maintenance services for StorageTek's tape libraries. To carry out that maintenance, CHE built a gadget which would intercept diagnostic messages sent within the library; CHE also had to bypass StorageTek's "GetKey" system which protected access to those messages. StorageTek claimed that running the maintenance code (which generates the diagnostic messages) was a copyright violation, and that bypassing GetKey went against the DMCA's anticircumvention measures. A U.S. district court agreed, and issued an injunction shutting CHE's maintenance service (for these libraries) down.

CHE appealed the injunction, and an appeals court has now produced a ruling [PDF] reversing the injunction. In doing so, the appeals court has placed some limits, however small, on the application of the DMCA.

This case matters. It is not hard to imagine similar situations which could affect the free software community. If StorageTek's internal diagnostic streams are privileged, many other hardware communication paths may be as well. Consider a closed network adaptor, for which a free, reverse-engineered driver exists. The vendor could claim that the communications between the proprietary driver and the firmware on the card serve as an access to that (copyrighted) firmware, and that the (undocumented, complex) interface to the card is a technical measure preventing unauthorized access. By this reasoning, a free driver would be a DMCA violation. As DRM systems work their way into (what used to be) general-purpose computers, this sort of issue will come up in that context as well.

When viewed in this context, the StorageTek decision, while welcome, does not give much relief. It is a narrow decision which does little to return control of hardware to those who have purchased (and believe that they own) it.

The core of the appeals court decision is that CHE's activities did not, in fact, constitute copyright infringement. The infringement argued by StorageTek took the form of CHE loading StorageTek's maintenance code into the library's processor by means of rebooting the machine. This allegedly infringing activity is the same thing that happens when the owner of the machine turns it on. This "copying" of the software into RAM might well have been a copyright infringement, except that the copyright law contains an explicit exception for third-party maintenance providers. Even in this case, CHE might not have been in the clear, however; the company prevailed in the end because StorageTek had never made a clear separation between its operational and maintenance programs. The whole mess is loaded when the system boots, so the appeals court decided that it was all necessary to operate the library.

In other words, if StorageTek had been more careful to keep its maintenance software separate, and to not load it automatically when the system boots, it might have gotten through this appeal. The court also notes that StorageTek could have written its software license agreement to forbid third parties (such as CHE) from turning on the machine at all - but didn't.

Once that decision was reached, the court had little trouble with the DMCA claim. The DMCA, the court decided, is a copyright law. To that end, the anti-circumvention provision does not stand on its own, but is tied to the underlying copyright regime. That limits how this provision can be read:

To the extent that CHE's activities do not constitute copyright infringement or facilitate copyright infringement, StorageTek is foreclosed from maintaining an action under the DMCA.... That result follows because the DMCA must be read in the context of the Copyright Act, which balances the rights of the copyright owner against the public's interest in having appropriate access to the work.

In theory, this interpretation means that circumvention, itself, is not a crime. It is only when that circumvention is part of a violation of copyright that the DMCA comes in to play. Unfortunately, anything which is said to "facilitate" copyright infringement will fall on the wrong side of that line, so there is nothing good in this ruling for DeCSS (for example).

So, in the end, this ruling does little to enable us "consumers" to keep control over the devices that we believe we own. It is more likely to serve as a checklist for companies like StorageTek in the future: their systems are likely to be designed to avoid the pitfalls encountered by StorageTek in this case. This ruling has, mainly, increased the number of lawyers that hardware manufacturers must apply to achieve their aftermarket goals.

Whenever one buys a device containing proprietary software, one must accept that said device may serve somebody else's interests. That is in the nature of proprietary software, but that nature is made worse by current copyright law, which sees the act of paging software into RAM to execute it as an act of copying which may be controlled by the copyright owner. The ruling in the StorageTek case has drawn some boundaries on how far vendors can use copyright law to assert control over hardware they have sold, but the situation, fundamentally, has not changed.


to post comments

Two DRMs not equal?

Posted Sep 1, 2005 9:41 UTC (Thu) by job (guest, #670) [Link] (6 responses)

In what way can DeCSS be said to facilitate copyright infringement? Both systems work the same way, there is some data that the copyright owner does not allow the user to access (music, text, or in this case diagnostic data) and then there is some key present or a bit set which basically means "do not enter". The DMCA protects this.

I fail to see how some DRM mechanisms such as the ones for Windows Media and DVDs is protected by law, but StorageTek's isn't. Apart from that the big entertainment conglomerates seems to have unlimited political power in the US, of course. Maybe the court does realise somewhere that sometimes competition in the marketplace might be a good thing after all, I just wish they felt the same when dealing with software patents.

Two DRMs not equal?

Posted Sep 2, 2005 0:11 UTC (Fri) by giraffedata (guest, #1954) [Link] (5 responses)

In what way can DeCSS be said to facilitate copyright infringement?

I can't figure out in what way you imagine that it doesn't.

Seems pretty obvious to me that it's easier to make an illegal copy of a DVD with DeCSS than without.

I fail to see how some DRM mechanisms such as the ones for Windows Media and DVDs is protected by law, but StorageTek's isn't.

The article says the distinction is that the things Storage Tek's mechanism stops you from doing are not copyright violations. But a major thing that CSS stops you from doing is a very plain copyright violation: making a copy of your friend's The Matrix so you don't have to buy one of your own.

Or are you questioning the wisdom of DMCA being tied to copyright?

Two DRMs not equal?

Posted Sep 4, 2005 2:47 UTC (Sun) by njhurst (guest, #6022) [Link] (2 responses)

"But a major thing that CSS stops you from doing is a very plain copyright violation: making a copy of your friend's The Matrix so you don't have to buy one of your own."

It does nothing of the sort. Bit-wise DVD copiers have been available for windows for several years, which don't even look at the CSS stuff. CSS stops people from taking extracts from the DVD - it is designed to make the DVD a play only medium. Similarly, region coding is not designed to prevent copyright infringement.

Two DRMs not equal?

Posted Sep 5, 2005 18:23 UTC (Mon) by giraffedata (guest, #1954) [Link] (1 responses)

"Bit-wise DVD copiers have been available for windows for several years, which don't even look at the CSS stuff."

I stand corrected, and that does place CSS in a different light as an anti-copyright-violation device.

Now, to make sure I understand: This is something where you make a duplicate DVD on writeable DVD media and play it on an approved DVD player?

If so, CSS still gave plenty of copyright protection in the days in which it was first a legal issue -- before there were home DVD writers.

All the argument I remember when DVD movie releases were delayed by years while the technologists tried to satisfy the movie studios' concerns was about preventing people from making copies in place of buying copies from the studio. I don't think the studio executives really cared about people editing their movies.

I also remember a lot of talk about having manufactured-in serial numbers on blank media so bitwise copies wouldn't work. But it sounds like that didn't happen.

Two DRMs not equal?

Posted Sep 6, 2005 0:07 UTC (Tue) by njhurst (guest, #6022) [Link]

"Now, to make sure I understand: This is something where you make a duplicate DVD on writeable DVD media and play it on an approved DVD player?"

Correct. Or at least, it works on several DVD players here, I recently found out that US DVD players are very less permissive than those elsewhere.

Two DRMs not equal?

Posted Sep 8, 2005 7:35 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

Seems pretty obvious to me that it's easier to make an illegal copy of a DVD with DeCSS than without.

Actually, by decrypting the stream, it makes it impossible to make a faithful copy. Given that, how can you claim it's easier to make a copy with DeCSS than without?

Cheers,
Wol

Two DRMs not equal?

Posted Sep 9, 2005 6:31 UTC (Fri) by giraffedata (guest, #1954) [Link]

Actually, by decrypting the stream, it makes it impossible to make a faithful copy. Given that, how can you claim it's easier to make a copy with DeCSS than without?

I think we're talking about a copy of the movie content, not of the bits on the DVD. You can't make a copy of the movie content without decrypting.

It's been pointed out in other comments in this thread that one can often copy the encrypted bits to another DVD and then have an approved DVD player decrypt it. However, when the legality of DeCSS was being debated, there was no way for a casual copier to write a DVD, and copyright owners were hoping to get legal protections to make it impossible to create a usable copy that way (e.g. require blank media to have a serial number and the DVD player to match that with a serial number encrypted into the movie).

Today, given the reality of usefully coyping encrypted data, maybe the old arguments that DeCSS facilitates copying aren't as strong.

The StorageTek DMCA decision

Posted Sep 1, 2005 19:05 UTC (Thu) by lutchann (subscriber, #8872) [Link] (6 responses)

That is in the nature of proprietary software, but that nature is made worse by current copyright law, which sees the act of paging software into RAM to execute it as an act of copying which may be controlled by the copyright owner.

It should be noted that this protection supports free software as well. If the act of loading software into RAM were not under control of the copyright holder, it would have been impossible for the GPL to prevent vendors from dynamically linking GPL'd software against proprietary binaries.

The StorageTek DMCA decision

Posted Sep 1, 2005 21:55 UTC (Thu) by kevinbsmith (guest, #4778) [Link] (5 responses)

I could be wrong, but I don't think the GPL prevents linking with proprietary binaries. It prevents distributing code that does binary linking (that's a vague hand-waving phrase because I don't have time to research and compose precise wording). It's the distribution that's covered by copyright, not the execution (or "use").

I trust someone with more legal/GPL expertise will clarify this.

The StorageTek DMCA decision

Posted Sep 1, 2005 23:06 UTC (Thu) by lutchann (subscriber, #8872) [Link] (4 responses)

The FSF asserts that the act of executing a dynamically-linked program, which causes the program plus libraries to be loaded into the same address space, creates a derived work. This results in the strange situation in which the proprietary software vendor (who linked their proprietary code against a GPL'd library, for example) is not violating the GPL by distributing their proprietary executable, but all of their users are by running it. The FSF resolves this by making the dubious claim that dynamically-linked executables constitute a derived work if they link against a GPL'd library even if no GPL'd code is compiled into the executable.

There has been a lot of speculation as to whether this would hold up in court, and I don't personally think it would. If not, the result would be that the GPL would be more or less equivalent to the LGPL, and anybody could combine GPL'd code into their proprietary apps simply by turning it into a shared library. Of course, the question of whether binary-only Linux kernel modules are legal would be resolved once and for all.

The FSF will probably clarify the dynamic linking restriction in GPLv3, and the fact that copyright covers the act of executing the program is the only basis they'd have for making this enforcable without turning the GPL into a contract, which wouldn't be practical. That's more of what I was getting at with my original comment.

Unfortunately, it's not clear that this can be easily resolved in GPLv3, since the definition of "dynamic linking" is pretty vague these days. RPC allows function calls between different address spaces (and hosts even), MMU-less systems load all their executables into the same address space, and virtualization even makes the concepts of "loading" and "running" vague. I expect that GPLv3 will be much longer than v2.

As an aside, it's really too bad that litigation in modern times is so expensive that most copyright disputes are settled out of court. We really need case law to catch up to the state of the art.

(Usual disclaimer: I am not a lawyer. I have had no legal training. Seek the advice of a qualified attorney or tax professional. Past performance is not an indication of future results. May contain peanuts.)

The StorageTek DMCA decision

Posted Sep 1, 2005 23:59 UTC (Thu) by giraffedata (guest, #1954) [Link] (1 responses)

I agree that the idea that copyright law lets the author control loading into memory for execution is nonsense. (It really isn't much different from creating a copy of a book page on your retina for the purpose of reading it). Mine isn't a legal opinion either.

But does that make GPL the same as LGPL? LGPL lets you _statically_ link the licensed material with some other stuff into a single executable and distribute that executable without licensing the whole thing under LGPL, doesn't it? GPL does not.

The StorageTek DMCA decision

Posted Sep 2, 2005 1:40 UTC (Fri) by lutchann (subscriber, #8872) [Link]

Well, I did say "more or less". :-) You're right, technically the LGPL would still be more permissive since statically linking to GPL'd code and distributing it would be a clear copyright/license violation. It's been years since I've seen a vendor satisfy LGPL requirements by distributing the unlinked object files, though, so I think the net effect would be the same.

The StorageTek DMCA decision

Posted Sep 2, 2005 4:05 UTC (Fri) by kevinbsmith (guest, #4778) [Link] (1 responses)

I know the FSF believes that binary dynamic linking creates a derived work. However, it does not necessarily follow that the act of executing such a work would violate the GPL. Do you have any links where I could read more about that claim?

Right near the top of the GPL, we see: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted..."

My interpretation remains that one could create a derived work (e.g. something dynamically linked), and could run it on their own computer for their own use. But they could not distribute it to anyone else, except under a GPL-compatible license.

Kevin (also definitely not a lawyer)

The StorageTek DMCA decision

Posted Sep 2, 2005 15:11 UTC (Fri) by lutchann (subscriber, #8872) [Link]

Ahh, OK, I spent some quality time with Google this morning and it looks like my facts are about 30 years out of date. The Copyright Act of 1976 specifically exempted the act of copying executable code into memory for the purpose of executing it from copyright protection. See this Q&A by Lawrence Rosen:

http://www.linuxjournal.com/article/4754

This casts serious doubt, in my mind, that any copyright license (i.e. not a commercial-software-style license agreement, which is governed by contract law), could have any basis for precluding dynamic linking. Again, I sure wish we could see how this would play out in court.


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds