cc-licenses AT lists.ibiblio.org
Subject: Development of Creative Commons licenses
List archive
Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses
- From: "Greg London" <teloscorbin AT gmail.com>
- To: "Discussion on the Creative Commons license drafts" <cc-licenses AT lists.ibiblio.org>
- Subject: Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses
- Date: Wed, 27 Sep 2006 22:38:23 -0400
On 9/27/06, Evan Prodromou <evan AT prodromou.name> wrote:
On Wed, 2006-27-09 at 14:10 -0400, Greg London wrote:
> unless DRM Dave is the only person who can supply DRM-enabled
> versions of the work that play on his hardware, and laws such as
> the DMCA prevent Alice and Bob from applying DRM themselves,
> then your parallel distribution fails to negate and creates an inequality.
I agree that parallel distribution fails to rectify that situation.
For example, let's say that DRM Dave's platform is a music player.
Charlie wrote a song, and licensed the sheet music and lyrics under
by-sa-3.x, which requires parallel distribution. DRM Dave's company
records someone performing the song (a derivative work, thus also
by-sa-3.x). The company releases it digitally as a .DDL file (DRM Dave's
Locked format, which has various copy-protection features). Under the
requirements of parallel distribution, DRM Dave's company also releases
the song as a .DDU file (DRM Dave's Unlocked format). Only DRM Dave has
the tools, and the legal authority, to convert DDU files into DDL files
that can be played on the player. So, even though Alice and Bob can copy
and modify the DDU file all they want, they can't make much use of the
file since they can't play it.
Have I captured the problem you're presenting correctly?
That about sums it up, yes.
This seems to me to be equivalent to other problems with proprietary or
rare file formats or lossy compression. It also pops up with ports of
copyleft software to proprietary programming languages, runtimes, or
operating systems. Compare the "Java Trap" problem with Free Software:
http://www.gnu.org/philosophy/java-trap.html
I think the possibility for trouble is way worse than the Java Trap.
We're talking about possibly proprietary hardware, and hardware
companies thrive on patents, not copyright, which can't be
circumvented or reimplemented in software easily. We're also
talking about hardware that could be designed to protect content
to the point that the content is DRM'ed from the storage media
all the way to the display, and the only way to access it is to
decrypt the signal, i.e. circumvent and violate the DMCA.
I've worked as an electrical engineer in consumer electronics
for the last few years. I've seen some proposals being thrown
around that would curdle your milk. The future we are heading
towards is one where everything is under DRM. There is no
analog television broadcasts, everythign is digital and DRM
enforced. DVD's were an attempt to do it with purely technical
measures, but they figured out that wasn't enough, so they
pushed the DMCA through to make it illegal to crack their
shoddy encryption. And Blue-Ray and HDDVD is just around
the corner as the next content distribution medium, covered
by patents, probably new encryption and new DRM and
now enforced by the DMCA to prevent DVD John from cracking it.
And once you start talking hardware, you are talking about
volume. There is no way from some FLOSS company to
compete in the hardware arena against a major proprietary
player that sells millions of copies a year. Especially if
those proprietary players are given away for free, and
people pay for them via monthly subscriptions for service,
(phone, music, video, whatever)
Whether the future turns out to be what we would consider
a dystopia, I don't know, but I can tell you with certainty
that there are consumer electronics companies out there
that envision exactly the sort of thing that would be FLOSS's
worst nightmare: A hardware medium that creates its own
proprietary DRM'ed channel, and the only way to get played on the
channel is to pay the people who made the channel.
Fair Use would be an extinct dinosaur studied in history
classes.
Although it's annoying and inconvenient, I think it's still possible for
Alice and Bob to exercise their freedoms w/r/t the work. For example,
they can reverse-engineer the DDU format (note: such reverse engineering
is not prohibited under the DMCA, since the DDU format is by definition
not protected by an "effective technology measure"). They can then
convert the work into a widely-available format like Ogg Vorbis, FLAC,
or MP3. Or, they could write a software DDU-player. Or, they could
create a DDU player in hardware.
If it really is so easy to get around DRM, then DRM Dave should
be prohibited from making DRM versions in the first place,
and Alice adn Bob should make non-DRM hardware to play
the works without any DRM restrictions.
Now, forbidding re-distribution in DRM'd format would prevent DRM Dave
from doing this at all. So would forbidding re-distribution outright,
forbidding re-distribution in proprietary formats, forbidding
re-distribution of recorded songs, dot dot dot. Where we fine-tune the
system is balancing our desire to Stop DRM Dave with our desire to
enable other people -- like Alice and Bob -- to continue doing
interesting things and sharing them with other nice people.
You can't have it both ways.
You can't argue here that prohibiting DRM versions will prevent
Alice and Bob from sharing their works on Dave's DRM-only hardware.
But then tell me above that even if Dave set himself up as a sole-source
provider, that Alice and Bob could work around it, figure out the format,
and create their own hardware players.
If it is a hard task for Alice and Bob to work around Dave's DRM-only
hardware, then Dave can become sole source provider of works,
and no one will be able to stop him, because its too much work,
and therefore Dave should be prohibited up front by the license
from putting CC works under DRM.
If it is an easy task for Alice and Bob to work around Dave's DRM-only
hardware, then prohibiting DRM versions of the work will not prohibit
Alice and Bob from sharing the work, they can simply build their
own hardware. And if this is the case, then there is no harm from
prohibiting Dave from creating DRM-only versions of the work.
Hard or easy, I get the same result: No DRM should be allowed.
Your argument chooses "Easy" when I bring up the concern about
Dave being sole-source provider. You answer by saying it would
be "easy" for Alice and Bob to work around Dave so he is no longer
sole soure.
But then your argument switches to "hard" when you bring up the
concern that Alice and Bob won't be able to share the work on
Dave's DRM-only hardware. YOu say it would be too hard for Alice
and Bob to create their own hardware or distribute the work on
some alternate hardware that they build themselves.
So, you change your premise as to whether it would be hard or easy
for Alice and Bob to work around Dave's DRM-only hardware and
roll their own player, depending on what resulting conclusion you need
to reach.
If you pick one for both cases, like I do, then an anti-DRM clause
is either protection from evil Dave becoming sole-source, or
irrelevent and will cause no harm to Alice and Bob. Protection
from possible evil, and causing no harm to good people.
-
Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses
, (continued)
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Greg London, 09/25/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, drew Roberts, 09/25/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Terry Hancock, 09/25/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, rob, 09/26/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Terry Hancock, 09/26/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Terry Hancock, 09/26/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, rob, 09/27/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Evan Prodromou, 09/27/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Greg London, 09/27/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Evan Prodromou, 09/27/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Greg London, 09/27/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Evan Prodromou, 09/28/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, drew Roberts, 09/28/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Greg London, 09/28/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Greg London, 09/28/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Greg London, 09/28/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Greg London, 09/28/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, drew Roberts, 09/28/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Greg London, 09/29/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Terry Hancock, 09/29/2006
- Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses, Evan Prodromou, 09/30/2006
Archive powered by MHonArc 2.6.24.