Skip to Content.
Sympa Menu

cc-licenses - Re: [cc-licenses] Version 3.0 - Public Discussion

cc-licenses AT lists.ibiblio.org

Subject: Development of Creative Commons licenses

List archive

Chronological Thread  
  • From: Terry Hancock <hancock AT anansispaceworks.com>
  • To: Discussion on the Creative Commons license drafts <cc-licenses AT lists.ibiblio.org>
  • Subject: Re: [cc-licenses] Version 3.0 - Public Discussion
  • Date: Sun, 13 Aug 2006 22:32:43 -0500

Mike Linksvayer wrote:
I'm surprised nobody AFAICT has suggested just that -- rather than
disallow DRM, explicitly give authority to circumvent. The DMCA
seems to allow this --
http://thomas.loc.gov/cgi-bin/query/D?c105:6:./temp/~c1059gv3KK::

`(A) 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're right. I haven't seen this suggestion here or on the GPLv3 discussion. Seems like a logical addition to the wording. But I don't think it's sufficient, so I wouldn't say "rather than".

Explicit permission to reverse engineer a particular work still implies the need for a cracker to do the job, and the DMCA makes it potentially illegal even to write the cracker. It's like giving permission to pick your door lock, but lockpicks are still illegal (note that AFAIK, *lockpicks* like wire-cutters, guns, and other 'potentially criminal tools' *aren't* illegal -- in glaring significant contrast to the approach taken with DRM!).

> And I also doubt that Free Software advocates will look kindly on a
> project that had a chance to make their licenses compatible with
> the DFSG, but decided not to.
>
> I'd appreciate it if people would factor this into their decisions.

I agree with Evan.

I'm honestly not sure. Both the FSF and the CC want strong anti-DRM clauses in free licensing. There is considerable fear of the problems that DRM can wreak. I'm personally of the opinion that such fears are exaggerated -- but not unfounded. I think that a significant effort to educate the public on the limitations of "Defective by Design" hardware (I love that label) is capable of having an effect on buying habits. IF companies step up to the plate and provide competitive non-DRM hardware alternatives, I believe people will buy them (although not without a lot of marketing effort).

OTOH, the "DRM dystopia" is not impossible, and the FSF and the CC want to take steps to prevent it via licensing. Debian has little connection to CC, but will usually follow the lead of the FSF. CC may only be reinforcing the FSF position by hanging onto its anti-DRM language.

So, politically speaking, I think CC still has a lot of room to maneuver on the DRM issue.

At the same time, though, I think the "parallel distribution" model is a harmless change. This is due to my experience with the GPL, since the GPL's allowance for parallel distribution of source and binary versions of code.

I'm not convinced by any of the arguments I've seen so far that a reasonably implemented "parallel distribution" clause would allow some kind of DRM lock-in -- I just can't see how. So far, all the panic scenarios seem to involve a license violation -- the work goes into DRM, it's modified, then released only as DRM. Hence, license violation.

OTOH, the arguments that the existing wording, or the non-violation of fair-use rights already ensure the ability to add DRM to a non-DRM work just for porting to DRM platforms sound fairly solid to me. It seems quite reasonable that I should be able to encode works I already have in my possession (gosh I hope fair use covers that) for my own use. This might involve the publications of keys which might be some kind of contract violation with DRM providers, but otherwise seems reasonable to me. I'd like to see the practical side of this kind of environment considered. It clearly imposes a penalty on DRM platforms, but that's incentive not to use them, which might be a good thing to have.

Cheers,
Terry

--
Terry Hancock (hancock AT AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com





Archive powered by MHonArc 2.6.24.

Top of Page