The StorageTek DMCA decision
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:
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.
Posted Sep 1, 2005 9:41 UTC (Thu)
by job (guest, #670)
[Link] (6 responses)
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.
Posted Sep 2, 2005 0:11 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (5 responses)
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.
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?
Posted Sep 4, 2005 2:47 UTC (Sun)
by njhurst (guest, #6022)
[Link] (2 responses)
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.
Posted Sep 5, 2005 18:23 UTC (Mon)
by giraffedata (guest, #1954)
[Link] (1 responses)
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.
Posted Sep 6, 2005 0:07 UTC (Tue)
by njhurst (guest, #6022)
[Link]
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.
Posted Sep 8, 2005 7:35 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Sep 9, 2005 6:31 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
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.
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.
Posted Sep 1, 2005 21:55 UTC (Thu)
by kevinbsmith (guest, #4778)
[Link] (5 responses)
I trust someone with more legal/GPL expertise will clarify this.
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.)
Posted Sep 1, 2005 23:59 UTC (Thu)
by giraffedata (guest, #1954)
[Link] (1 responses)
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.
Posted Sep 2, 2005 1:40 UTC (Fri)
by lutchann (subscriber, #8872)
[Link]
Posted Sep 2, 2005 4:05 UTC (Fri)
by kevinbsmith (guest, #4778)
[Link] (1 responses)
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)
Posted Sep 2, 2005 15:11 UTC (Fri)
by lutchann (subscriber, #8872)
[Link]
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.
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.Two DRMs not equal?
Two DRMs not equal?
In what way can DeCSS be said to facilitate copyright infringement?
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.
"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."Two DRMs not equal?
Two DRMs not equal?
"Bit-wise DVD copiers have been available for windows for several years, which don't even look at the CSS stuff."
"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?"Two DRMs not equal?
Two DRMs not equal?
Seems pretty obvious to me that it's easier to make an illegal copy of a DVD with DeCSS than without.
WolTwo DRMs not equal?
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?
The StorageTek DMCA decision
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").The StorageTek DMCA decision
The StorageTek DMCA decision
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.
The StorageTek DMCA decision
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
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?The StorageTek DMCA decision
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:The StorageTek DMCA decision