Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Brian T. Sniffen) writes: The ban on use of circumvention devices for copy-prevention schemes is probably toothless, given the fair use doctrine. However, the following activities banned by the DMCA are not copyright infringement, and so fair use is not a defense for them: * Trafficking in access-control circumvention devices. * Accessing a protected work. Here we have a different question, with a very different answer. The first is easy. The access-control circumvention device is not actually a device, but a program; that is, a set of bits. Indeed, nobody is accused of trafficing in a *device*, but only the bits, given that in general not even a CD is being sent. Moreover, trafficking is not merely transmitting, but specifically commercially. Debian doesn't in fact traffic in anything. Anyhow, the point is that there is no existing first amendment category which allows such a restriction on speech. Telling someone how to circumvent access is manifestly speech; there are exceptions to the first amendment for copyright or trade secrets, but in the instant case, this is neither. Nor is it libel, or obscene. As for the second, it is not at all clear to me that the DMCA actually prohibits accessing a protected work, in the context in which I have actually purchased the copy. I have, in fact, purchased the right to access the information on my DVDs. When I play it using my home-unit Yamaha DVD player, I do not break the law, and when I do so using DeCSS, I do the same. Now, if my copy were illegally obtained, it might well be illegal for me to access it. I don't know. But this doesn't affect us; the fact that there is a legitimate use for the software immunizes us against the fact that someone might also use it for nefarious purposes. I agree that, if the issue comes up, Debian should make clear that our intention in distributing DeCSS would only be for access to legal copies. Thomas
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: The ban on use of circumvention devices for copy-prevention schemes is probably toothless, given the fair use doctrine. However, the following activities banned by the DMCA are not copyright infringement, and so fair use is not a defense for them: * Trafficking in access-control circumvention devices. * Accessing a protected work. Here we have a different question, with a very different answer. The first is easy. The access-control circumvention device is not actually a device, but a program; that is, a set of bits. Indeed, nobody is accused of trafficing in a *device*, but only the bits, given that in general not even a CD is being sent. Moreover, trafficking is not merely transmitting, but specifically commercially. Debian doesn't in fact traffic in anything. You haven't read the DMCA, have you? The actual text is No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that-- (1201(2)) Debian certainly manufactures, imports, and offers to the public technology. Anyhow, the point is that there is no existing first amendment category which allows such a restriction on speech. Telling someone how to circumvent access is manifestly speech; there are exceptions to the first amendment for copyright or trade secrets, but in the instant case, this is neither. Nor is it libel, or obscene. The speech-nature of computer programs may be protected; the functional nature of computer programs is likely to not be. The courts appear to be favoring, at best, a portmanteau approach to the question Is Code Speech? As for the second, it is not at all clear to me that the DMCA actually prohibits accessing a protected work, in the context in which I have actually purchased the copy. I have, in fact, purchased the right to access the information on my DVDs. When I play it using my home-unit Yamaha DVD player, I do not break the law, and when I do so using DeCSS, I do the same. Given the lack of explicit license or contract in the DVD packaging, your argument sounds reasonable -- an alternate explanation is that Yamaha and Best Buy are also violating the DMCA, but the MPAA declines to sue them. Now, if my copy were illegally obtained, it might well be illegal for me to access it. I don't know. But this doesn't affect us; the fact that there is a legitimate use for the software immunizes us against the fact that someone might also use it for nefarious purposes. I agree that, if the issue comes up, Debian should make clear that our intention in distributing DeCSS would only be for access to legal copies. I think that neither you nor I are lawyers, and Debian should keep its nose painfully clean until it has reliable legal advice on this subject. And probably let somebody else be the test case. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Brian T. Sniffen) writes: The speech-nature of computer programs may be protected; the functional nature of computer programs is likely to not be. The courts appear to be favoring, at best, a portmanteau approach to the question Is Code Speech? Actually, the courts have basically adopted the Code is Speech rule, and that means that restrictions must be justified as restrictions on speech. Such things are sometimes restrictable, indeed, but not much. I think that neither you nor I are lawyers, and Debian should keep its nose painfully clean until it has reliable legal advice on this subject. And probably let somebody else be the test case. This is a very different meta-question. Sometimes it's the right thing, but it's not really an answer to the actual debate to say nobody really knows, punt to a lawyer for an answer. That's either just advice about what Debian should do (and as such, the person who introduces it should start taking the necessary steps, as Sam Hartman and others did in the encryption case), or else it's an unfair attempt to use FUD. Thomas
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Brian T. Sniffen) writes: Your interpretation would make the access-circumvention provision almost useless: it would mean it only mattered when preventing access to illegally copied works. Which, hey, is a reasonable law. Neat. No, it would also mean that you can't make an access-circumvention for a *copy protection* scheme. The point is that CSS isn't a copyprotection scheme, not at all.
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: Your interpretation would make the access-circumvention provision almost useless: it would mean it only mattered when preventing access to illegally copied works. Which, hey, is a reasonable law. Neat. No, it would also mean that you can't make an access-circumvention for a *copy protection* scheme. The point is that CSS isn't a copyprotection scheme, not at all. You keep snipping the relevant text: do you think your argument can't stand up next to evidence? Let my try this again: CSS is an access control mechanism. The fair use doctrine is a defense to copyright infringement. The DMCA makes circumvention of access control mechanisms illegal. That law also says nothing in the DMCA contravenes the fair use doctrine. The ban on use of circumvention devices for copy-prevention schemes is probably toothless, given the fair use doctrine. However, the following activities banned by the DMCA are not copyright infringement, and so fair use is not a defense for them: * Trafficking in access-control circumvention devices. * Accessing a protected work. Fair use would normally allow you to do either of these things. Neither of them is copyright infringement, though, so the DMCA effectively bans them. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#156287: Advice on Drip (ITP #156287)
Steve Langasek [EMAIL PROTECTED] writes: On Wed, Jul 30, 2003 at 09:09:10AM -0700, Thomas Bushnell, BSG wrote: Steve Langasek [EMAIL PROTECTED] writes: This is an arbitrary distinction that has no clear basis in the law. You are also circumventing CSS by playing the DVD in question (viewing is also a form of access). Remember that CSS is a standard developed by a consortium of DVD *player manufacturers*, to maintain their hardware profits. I believe this is not correct. In what regard? I believe that the circumvention in question, under the DMCA, is specifically only circumvention which is a copy protection mechanism. The CSS is not a copy protection mechanism, in any sense of the term. It is rather a mechanism designed to enforce region coding. It is not correct that CSS was developed by hardware player manufacturers in order to maintain their profits. All the players can always play an unencrypted DVD. It is the studios that choose to encrypt, and they do so to enforce region coding, and staged geographic releases and differential pricing. The distinction was between playing and copying of movies by means of decrypting CSS. You assert that viewing is a form of access (which indeed it is), but this misses the point that the DMCA covers only a copy-protection scheme, not an access protection scheme. I do agree with your broader point that if we can ship libdvdcss, we can ship applications that use it. I also agree that, if it's feasible, a lawyer's advice would be useful here. Thomas
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Steve Langasek [EMAIL PROTECTED] writes: On Wed, Jul 30, 2003 at 09:09:10AM -0700, Thomas Bushnell, BSG wrote: Steve Langasek [EMAIL PROTECTED] writes: This is an arbitrary distinction that has no clear basis in the law. You are also circumventing CSS by playing the DVD in question (viewing is also a form of access). Remember that CSS is a standard developed by a consortium of DVD *player manufacturers*, to maintain their hardware profits. I believe this is not correct. In what regard? I believe that the circumvention in question, under the DMCA, is specifically only circumvention which is a copy protection mechanism. The CSS is not a copy protection mechanism, in any sense of the term. It is rather a mechanism designed to enforce region coding. It is not correct that CSS was developed by hardware player manufacturers in order to maintain their profits. All the players can always play an unencrypted DVD. It is the studios that choose to encrypt, and they do so to enforce region coding, and staged geographic releases and differential pricing. The distinction was between playing and copying of movies by means of decrypting CSS. You assert that viewing is a form of access (which indeed it is), but this misses the point that the DMCA covers only a copy-protection scheme, not an access protection scheme. DMCA 1201(a)(1)(A): No person shall circumvent a technological measure that effectively controls access to a work protected under this title. The prohibition contained in the preceding sentence shall take effect at the end of the 2-year period beginning on the date of the enactment of this chapter. DMCA 1201(a)(3)(A): As used in this subsection, to ''circumvent a technological measure'' means to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner; and You've apparently only read 1201(b), which covers circumvention of mechanisms protecting other Title 17 rights. -Brian I do agree with your broader point that if we can ship libdvdcss, we can ship applications that use it. I also agree that, if it's feasible, a lawyer's advice would be useful here. Thomas -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: DMCA 1201(a)(1)(A): No person shall circumvent a technological measure that effectively controls access to a work protected under this title. The prohibition contained in the preceding sentence shall take effect at the end of the 2-year period beginning on the date of the enactment of this chapter. I'm thinking of the law in toto, including the provisions in the DMCA nothing in the DMCA is intended to contravene existing fair use. This is a pretty big stick to get to wave back at the MPAA and others of their ilk. Since existing fair use guarantees the right to watch my copy, provided it's legal, the provisions you quote must not apply to them. Why? Because the DMCA says, essentially, nothing here contradicts existing fair use principles. Your interpretation would make the access-circumvention provision almost useless: it would mean it only mattered when preventing access to illegally copied works. Which, hey, is a reasonable law. Neat. On the other hand, the text actually says that nothing in the DMCA affects fair use as a copyright-infringement defense. Distribution of an circumvention device isn't copyright infringement, so that doesn't help. The interoperability bits in 1201(f) seem fine to cover libdvdcss / libdvdread distribution, though. -Brian
Re: Bug#156287: Advice on Drip (ITP #156287)
This seems like a big can of worms. I think i'll just fix the bogus direct dependency on libdvdcss for Drip and bring Drip into Debian for now.. thanks all for your help. On Tue, Jul 29, 2003 at 08:01:21PM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 01:49:48AM +, Robert Millan wrote: On Tue, Jul 29, 2003 at 06:14:53PM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 01:02:36AM +, Robert Millan wrote: Whatever. The fact is that when we put Drip, libdvdread and libdvdcss together we obtain what what the DMCA calls a circumvention device for copyright protection technology. This may happen in non-us, but must not happen in main. I don't see any bright line that would be used here to legally distinguish between (Drip+libdvdread+libdvdcss) and libdvdcss by itself. It seems to me that if we're allowed to ship libdvdcss, we're also allowed to ship applications that use it. This is what the DMCA reads: (2) No person shall manufacturate, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component or part thereof, that-- (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; The libdvdcss has the primary purpose of allowing DVD players to reproduce CSS-encoded movies, and not that of circumventing CSS. Any DVD player has the primary purpose of reproducing CSS-encoded movies, so the same applies. Drip is a DVD ripper. Without CSS support, it rips DVDs but doesn't break the CSS protection so it is not put in question. When CSS-enabled, its primary purpose is argueably the circumvention of CSS, which is a technological measure that effectively controls access to a work protected under this title. This is an arbitrary distinction that has no clear basis in the law. You are also circumventing CSS by playing the DVD in question (viewing is also a form of access). Remember that CSS is a standard developed by a consortium of DVD *player manufacturers*, to maintain their hardware profits. Anyway I find this discussion much useless, since the DMCA can't be applied to non-us. SPI is a US corporation, and its assets could be seized as the result of a court settlement against us. AIUI, this is the main reason why CSS-aware software is not already commonplace in non-US. -- Steve Langasek postmodern programmer -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#156287: Advice on Drip (ITP #156287)
Robert Millan said: This is what the DMCA reads: (2) No person shall [...] import, [...] any technology, product, service, device, component or part thereof, [ like Drip+libdvdread+libdvdcss ] Anyway I find this discussion much useless, since the DMCA can't be applied to non-us. non-us has traditionally been home to software than can not be _exported_ from the US, not software that can not be _imported_ into the US. (references: http://lists.debian.org/debian-legal-0209/msg2.html and more recent discussion on debian-legal which I can't find on the web at the moment.) --Joe
Re: Bug#156287: Advice on Drip (ITP #156287)
I'll upload Drip to main when its independant of libdvdcss (through libdvdread), and other technical issues are solved. As for libdvdcss, see the other thread. On Wed, Jul 30, 2003 at 07:02:16AM -0400, Joe Moore wrote: Robert Millan said: This is what the DMCA reads: (2) No person shall [...] import, [...] any technology, product, service, device, component or part thereof, [ like Drip+libdvdread+libdvdcss ] Anyway I find this discussion much useless, since the DMCA can't be applied to non-us. non-us has traditionally been home to software than can not be _exported_ from the US, not software that can not be _imported_ into the US. (references: http://lists.debian.org/debian-legal-0209/msg2.html and more recent discussion on debian-legal which I can't find on the web at the moment.) --Joe -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#156287: Advice on Drip (ITP #156287)
Steve Langasek [EMAIL PROTECTED] writes: This is an arbitrary distinction that has no clear basis in the law. You are also circumventing CSS by playing the DVD in question (viewing is also a form of access). Remember that CSS is a standard developed by a consortium of DVD *player manufacturers*, to maintain their hardware profits. I believe this is not correct.
Re: Bug#156287: Advice on Drip (ITP #156287)
On Wed, Jul 30, 2003 at 09:09:10AM -0700, Thomas Bushnell, BSG wrote: Steve Langasek [EMAIL PROTECTED] writes: This is an arbitrary distinction that has no clear basis in the law. You are also circumventing CSS by playing the DVD in question (viewing is also a form of access). Remember that CSS is a standard developed by a consortium of DVD *player manufacturers*, to maintain their hardware profits. I believe this is not correct. In what regard? -- Steve Langasek postmodern programmer pgppOBUqPVKFM.pgp Description: PGP signature
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Steve Langasek [EMAIL PROTECTED] writes: This is an arbitrary distinction that has no clear basis in the law. You are also circumventing CSS by playing the DVD in question (viewing is also a form of access). Remember that CSS is a standard developed by a consortium of DVD *player manufacturers*, to maintain their hardware profits. I believe this is not correct. I'm not absolutely clear what distinction Steve's referring to, but I assumed it was the distinction between decoding+copying and decoding+playing. My understanding is that it's the decoding (i.e., the circumvention) that's questionable, whether it's copied or played. The whole preventing copying bit is just MPIAA spin; what css actually does is prevent playing (i.e., interpretation of the data). Am I misunderstanding? Adding decss to drip may intuitively *seem* worse than adding decss to a player, but is there legal or factual basis for that? A circumvention device is a circumvention device; that's the whole point with this law. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Bug#156287: Advice on Drip (ITP #156287)
On Wed, Jul 30, 2003 at 01:05:02PM -0400, Jeremy Hankins wrote: I'm not absolutely clear what distinction Steve's referring to, but I assumed it was the distinction between decoding+copying and decoding+playing. My understanding is that it's the decoding (i.e., the circumvention) that's questionable, whether it's copied or played. The whole preventing copying bit is just MPIAA spin; what css actually does is prevent playing (i.e., interpretation of the data). Am I misunderstanding? Adding decss to drip may intuitively *seem* worse than adding decss to a player, but is there legal or factual basis for that? A circumvention device is a circumvention device; that's the whole point with this law. Please let's not bring this discussing again over and over. This issue has been beated to death several times with no result. As Sam Hocevar pointed, we're stuck on it anyway and a good direction to take is hiring a lawyer to analize the situation. Btw, don't confuse decss with libdvdcss. DeCSS is a program for DVD-decoding (somewhat) like Drip. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Advice on Drip (ITP #156287)
On Mon, Jul 28, 2003, Robert Millan wrote: It is important to note that libdvdcss is _NOT_ part of Drip. There are unofficial libdvdcss packages around, and I added them to Build-Conflicts to ensure Drip is not accidentaly linked against it. Uh? I suggest you have a more precise look at the Drip source code and see how exactly it uses libdvdcss. My understanding is that it does not at all: it only uses libdvdread. The Drip author seems to be largely confusing what is installed at build time and what is present at runtime; the warning about libdvdcss not being present is triggered when libdvdcss is not present on the _build_ system. So I think you should just remove your README.Debian note, and let the user see the libdvdread debconf note about its optional use of libdvdcss. That ought to be enough. Cheers, -- Sam.
Re: Advice on Drip (ITP #156287)
On Mon, Jul 28, 2003 at 11:38:37PM +, Robert Millan wrote: Such support is, however, disabled in this package because enabling it would violate the DMCA and possibly other laws. Is this a claim we want to make? I thought it hadn't been settled yet. Richard Braakman
Re: Advice on Drip (ITP #156287)
On Tue, Jul 29, 2003 at 02:19:50AM +, Robert Millan wrote: To my understanding, the legal problem is not in libdvdcss nor in drip, but in the combination of them. libdvdcss itself doesn't violate the DMCA because it can be used for purposes other than ripping DVDs (for players), and Drip itself doesn't violate the DMCA because the default configuration has CSS support disabled. Uh, I think your analysis is flawed. What does or does not violate the DMCA, as we have seen, is determined solely by the MPAA, RIAA, and their member companies, and has nothing at all to do with the text of the law itself or the Congressional Record. -- G. Branden Robinson|Somewhere, there is a .sig so funny Debian GNU/Linux |that reading it will cause an [EMAIL PROTECTED] |aneurysm. This is not that .sig. http://people.debian.org/~branden/ | pgpAgo1GlAnWR.pgp Description: PGP signature
Re: Advice on Drip (ITP #156287)
On Tue, Jul 29, 2003 at 12:41:53PM +0300, Richard Braakman wrote: On Mon, Jul 28, 2003 at 11:38:37PM +, Robert Millan wrote: Such support is, however, disabled in this package because enabling it would violate the DMCA and possibly other laws. Is this a claim we want to make? I thought it hadn't been settled yet. I agree. We have the MPAA and RIAA to tell us what is and isn't legal (which may change from day to day); we don't need to place any handcuffs on ourselves. In general, I think it's stupid to yell at the top of one's lungs, Hey! What I'm doing is *illegal*! -- G. Branden Robinson|If you make people think they're Debian GNU/Linux |thinking, they'll love you; but if [EMAIL PROTECTED] |you really make them think, they'll http://people.debian.org/~branden/ |hate you. pgpwivwQOzgtk.pgp Description: PGP signature
Re: Advice on Drip (ITP #156287)
On Tue, Jul 29, 2003 at 10:19:53AM +0200, Sam Hocevar wrote: On Mon, Jul 28, 2003, Robert Millan wrote: It is important to note that libdvdcss is _NOT_ part of Drip. There are unofficial libdvdcss packages around, and I added them to Build-Conflicts to ensure Drip is not accidentaly linked against it. Uh? I suggest you have a more precise look at the Drip source code and see how exactly it uses libdvdcss. My understanding is that it does not at all: it only uses libdvdread. The Drip author seems to be largely confusing what is installed at build time and what is present at runtime; the warning about libdvdcss not being present is triggered when libdvdcss is not present on the _build_ system. No, autoconf checks for libdvdcss and if found Drip is linked against it: $ ldd /usr/bin/drip | grep libdvdcss libdvdcss.so.2 = /usr/lib/libdvdcss.so.2 (0x4019a000) My understanding is that Drip being linked against libdvdcss is illegal in the USA, so a solution could be to put it in non-us. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Advice on Drip (ITP #156287)
On Tue, Jul 29, 2003, Robert Millan wrote: Uh? I suggest you have a more precise look at the Drip source code and see how exactly it uses libdvdcss. My understanding is that it does not at all: it only uses libdvdread. No, autoconf checks for libdvdcss and if found Drip is linked against it: Then, as I said, I suggest you have a more precise look at the Drip source code and see how exactly it uses libdvdcss. My understanding is that it does not at all. (I hope I got the wording right this time) $ ldd /usr/bin/drip | grep libdvdcss libdvdcss.so.2 = /usr/lib/libdvdcss.so.2 (0x4019a000) Linking drip with libdvdcss is utterly useless since drip does not use any libdvdcss function. My understanding is that Drip being linked against libdvdcss is illegal in the USA, so a solution could be to put it in non-us. Grmbl, please read carefully my first message in this thread. Drip has nothing to do with libdvdcss, only libdvdread uses libdvdcss. -- Sam.
Re: Bug#156287: Advice on Drip (ITP #156287)
On Wed, Jul 30, 2003 at 01:02:36AM +, Robert Millan wrote: On Wed, Jul 30, 2003 at 12:21:22AM +0200, Sam Hocevar wrote: $ ldd /usr/bin/drip | grep libdvdcss libdvdcss.so.2 = /usr/lib/libdvdcss.so.2 (0x4019a000) Linking drip with libdvdcss is utterly useless since drip does not use any libdvdcss function. Ok, I understand. I'll find it out when I get the other problems sorted out (depending on the results, the linker issue might not be relevant) My understanding is that Drip being linked against libdvdcss is illegal in the USA, so a solution could be to put it in non-us. Grmbl, please read carefully my first message in this thread. Drip has nothing to do with libdvdcss, only libdvdread uses libdvdcss. Whatever. The fact is that when we put Drip, libdvdread and libdvdcss together we obtain what what the DMCA calls a circumvention device for copyright protection technology. This may happen in non-us, but must not happen in main. I don't see any bright line that would be used here to legally distinguish between (Drip+libdvdread+libdvdcss) and libdvdcss by itself. It seems to me that if we're allowed to ship libdvdcss, we're also allowed to ship applications that use it. -- Steve Langasek postmodern programmer pgpSZVheXeyJv.pgp Description: PGP signature
Re: Advice on Drip (ITP #156287)
On Wed, Jul 30, 2003 at 12:21:22AM +0200, Sam Hocevar wrote: $ ldd /usr/bin/drip | grep libdvdcss libdvdcss.so.2 = /usr/lib/libdvdcss.so.2 (0x4019a000) Linking drip with libdvdcss is utterly useless since drip does not use any libdvdcss function. Ok, I understand. I'll find it out when I get the other problems sorted out (depending on the results, the linker issue might not be relevant) My understanding is that Drip being linked against libdvdcss is illegal in the USA, so a solution could be to put it in non-us. Grmbl, please read carefully my first message in this thread. Drip has nothing to do with libdvdcss, only libdvdread uses libdvdcss. Whatever. The fact is that when we put Drip, libdvdread and libdvdcss together we obtain what what the DMCA calls a circumvention device for copyright protection technology. This may happen in non-us, but must not happen in main. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#156287: Advice on Drip (ITP #156287)
On Tue, Jul 29, 2003 at 06:14:53PM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 01:02:36AM +, Robert Millan wrote: Whatever. The fact is that when we put Drip, libdvdread and libdvdcss together we obtain what what the DMCA calls a circumvention device for copyright protection technology. This may happen in non-us, but must not happen in main. I don't see any bright line that would be used here to legally distinguish between (Drip+libdvdread+libdvdcss) and libdvdcss by itself. It seems to me that if we're allowed to ship libdvdcss, we're also allowed to ship applications that use it. This is what the DMCA reads: (2) No person shall manufacturate, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component or part thereof, that-- (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; The libdvdcss has the primary purpose of allowing DVD players to reproduce CSS-encoded movies, and not that of circumventing CSS. Any DVD player has the primary purpose of reproducing CSS-encoded movies, so the same applies. Drip is a DVD ripper. Without CSS support, it rips DVDs but doesn't break the CSS protection so it is not put in question. When CSS-enabled, its primary purpose is argueably the circumvention of CSS, which is a technological measure that effectively controls access to a work protected under this title. Anyway I find this discussion much useless, since the DMCA can't be applied to non-us. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#156287: Advice on Drip (ITP #156287)
On Wed, Jul 30, 2003 at 01:49:48AM +, Robert Millan wrote: On Tue, Jul 29, 2003 at 06:14:53PM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 01:02:36AM +, Robert Millan wrote: Whatever. The fact is that when we put Drip, libdvdread and libdvdcss together we obtain what what the DMCA calls a circumvention device for copyright protection technology. This may happen in non-us, but must not happen in main. I don't see any bright line that would be used here to legally distinguish between (Drip+libdvdread+libdvdcss) and libdvdcss by itself. It seems to me that if we're allowed to ship libdvdcss, we're also allowed to ship applications that use it. This is what the DMCA reads: (2) No person shall manufacturate, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component or part thereof, that-- (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; The libdvdcss has the primary purpose of allowing DVD players to reproduce CSS-encoded movies, and not that of circumventing CSS. Any DVD player has the primary purpose of reproducing CSS-encoded movies, so the same applies. Drip is a DVD ripper. Without CSS support, it rips DVDs but doesn't break the CSS protection so it is not put in question. When CSS-enabled, its primary purpose is argueably the circumvention of CSS, which is a technological measure that effectively controls access to a work protected under this title. This is an arbitrary distinction that has no clear basis in the law. You are also circumventing CSS by playing the DVD in question (viewing is also a form of access). Remember that CSS is a standard developed by a consortium of DVD *player manufacturers*, to maintain their hardware profits. Anyway I find this discussion much useless, since the DMCA can't be applied to non-us. SPI is a US corporation, and its assets could be seized as the result of a court settlement against us. AIUI, this is the main reason why CSS-aware software is not already commonplace in non-US. -- Steve Langasek postmodern programmer pgpNKf5kcbnUr.pgp Description: PGP signature
Re: Bug#156287: Advice on Drip (ITP #156287)
On Wed, Jul 30, 2003 at 01:49:48AM +, Robert Millan wrote: (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; I've always wondered what effectively means here. Since you can create an exact, working duplicate of a DVD without breaking CSS, does it effectively control access? Richard Braakman
Advice on Drip (ITP #156287)
[ Please CC me, I'm not subscribed ] Hello! I'm finishing the initial release of the Drip debian package (ITP #156287) which is almost ready for upload. The only resting nitpick is a possible legal problem. The README.Debian I'm pasting below explains for itself, I think everything should be ok the way I have put it, but would appreciate confirmation before uploading to the archive. It is important to note that libdvdcss is _NOT_ part of Drip. There are unofficial libdvdcss packages around, and I added them to Build-Conflicts to ensure Drip is not accidentaly linked against it. ---README.Debian start Drip for Debian --- The purpose of this program is the creation of backup copies for your legaly owned DVD movies. Some of these DVD movies implement an annoying CSS protection to prevent you from creating backups, and Drip has support for using the libdvdcss library, which breaks this protection. Such support is, however, disabled in this package because enabling it would violate the DMCA and possibly other laws. This means in some states including but not necessarily limited to, the USA, it might be illegal to build Drip with libdvdcss support enabled, and/or distribute or even use such a build of Drip. Neither the authors of this program, nor the maintainer of the Debian package, nor the Debian project is responsible in any way for the person who illegaly enables libdvdcss support in Drip. If you think it is legal to do that in your state, you can do that (under your entire responsability) by following these instructions: [...blah blah...] ---README.Debian end -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Advice on Drip (ITP #156287)
I continue to believe that like other packages already in Debian, supporting libdvdcss if it is found is perfectly reasonable. If you manage to dlopen it and find the right symbols, use it. If someone complains, we can reevaluate the situation at that point.
Re: Advice on Drip (ITP #156287)
Hi Sam, On Mon, Jul 28, 2003 at 07:52:57PM -0400, Sam Hartman wrote: I continue to believe that like other packages already in Debian, supporting libdvdcss if it is found is perfectly reasonable. If you manage to dlopen it and find the right symbols, use it. If someone complains, we can reevaluate the situation at that point. To my understanding, the legal problem is not in libdvdcss nor in drip, but in the combination of them. libdvdcss itself doesn't violate the DMCA because it can be used for purposes other than ripping DVDs (for players), and Drip itself doesn't violate the DMCA because the default configuration has CSS support disabled. However, when put together we have a program that is clearly intended for DVD ripping _and_ able to break CSS. This fits the DMCA definition of a circumvention device of copyright protection technology. I want to have libdvdcss in Debian (it's ITPed, and there's a satisfactory discussion in -legal about it), but avoid this problem particularly. The situation that installing both drip and libdvdcss automagically enables CSS support in Drip (with dlopen) is not acceptable, since it could make the user break law without even knowing it. My approach is that users who explicitly desire to have a CSS-enabled Drip can obtain it (since it's perfectly legal if you don't live in the USA) but no person gets it without knowing what person is doing and thus accepting responsability for pers actions. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
