Development of Creative Commons licenses

[drew Roberts <zotz AT 100jamz.com>]

On Monday 25 September 2006 04:43 pm, Mia Garlick wrote:
> two comments below:
>
> On Sep 25, 2006, at 1:36 PM, drew Roberts wrote:
> > On Monday 25 September 2006 11:01 am, Mia Garlick wrote:
> >> it was included on line 42 of pages 14-16 of the table attached at
> >> the bottom (forgive me) of this email posted to the list: http://
> >> lists.ibiblio.org/pipermail/cc-licenses/2006-September/004027.html
> >>
> >> # the comment was:
> >>
> >> 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/cgibin/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
> >>
> >> GPLv3 draft 2 maybe does this — http://gplv3.fsf.org/gpl-
> >> draft-2006-07-27.html
> >>
> >> No covered work constitutes part of an effective technological
> >> “protection” measure under section 1201 of Title 17 of the United
> >> States Code. When you convey a covered work, you waive any legal
> >> power to forbid circumvention of technical measures that include use
> >> of the covered work, and you disclaim any intention to limit
> >> operation or modification of the work as a means of enforcing the
> >> legal rights of third parties against the work's users.
> >>
> >> # the response was:
> >>
> >> While the use of the term “copyright owner” as used in Section 1201
> >> is arguably imprecise, the conclusion that it authorizes CC licensor
> >> to consent to the circumvention of a third-party’s TPM applied by a
> >> CC licensee is seriously flawed.
> >>
> >> To date, to the extent the courts have considered this term, it has
> >> been in the context of movie studios authorizing DVD manufacturers to
> >> make DVD players that read CSS; in the context of Real Networks suing
> >> for the cracking of their DRM, or in the context of a garage door
> >> opener’s consent to a consumer unscrambling a code they applied to
> >> their own garage door open.  In other words, the relevant copyright
> >> owner who can authorize circumvention of a TPM is the copyright owner
> >> of the work who applied the TPM to the work in the first place or the
> >> technology company that developed the TPM and applied it to the work
> >> with the consent of the copyright owner of that work.
> >>
> >> It would defeat the purpose of Section 1201 (which is to protect the
> >> technological locks voluntarily applied by copyright owners to their
> >> works) if Alejandra could, for example, apply a CC license, with a
> >> circumvention consent provision in it, to her work and Benito could
> >> then place it on iTunes and, by virtue of the CC license, Carlos
> >> could then lawfully decrypt iTunes.
> >
> > In a sane world, this would be iTunes problem as they could easily
> > have a
> > system which put DRM on some tracks and left if off of others. If
> > they choose
> > to put it on tracks where the copyright holder specifically
> > disallows such
> > measures or only allows them with a provision of circumvention,
> > that hsould
> > be their tough luck.
> >
> > Where is this thinking flawed? (Other than this is not a sane world.)
>
> your response assumes that it is iTunes that puts it on the track.

Well, yes, and if that is not the way how this works then my logic would not 
hold. Can anyone confirm how this really works? Does apple really hand out 
the keys to encrypt content to any and everyone, or do they do it themselves, 
or do they only hand out the keys to encrypt under contract? Or do they use a 
public key type system.

all the best,

drew

> in the hypo given, it is Benito who puts it n the track...why should
> iTunes' DRM be vulnerable just because some random third party puts
> it on Alejandra's track?

>
> also, it is beyond comprehension that the DMCA laws were introduced
> to allow party A to authorize circumvention of an unrelated party I's
> DRM.  the consent provision can only, logically be read to authorize
> party I to authorize select people to circumvent party I's DRM so
> that it is not always a violation of the law to circumvent DRM; you
> can circumvent DRM with the consent of the person who authorized the
> DRM being put on the work.  using the hypo names given, the law
> should be read to mean that: Alejandra can release a work under a CC
> license with her DRM on it and then authorize people to circumvent
> it...that is a far cry from Alejandra authorized Carlos to circumvent
> a third party DRM applied by Benito...
>
> >> Given the technological measure
> >> referred to in Section 1201 has to have been applied with the
> >> authority of the copyright owner, this consent provision does not
> >> seem to give copyright owners the power to authorize the
> >> circumvention of technological measures applied by someone else such
> >> as a licensee.  If this were the case, competitors could release
> >> their works on terms that would authorize the circumvention of
> >> another’s TPM.
> >>
> >> Finally, GPL v3 draft 2 does not seem to be invoking this provision.
> >> The quoted text seems to be saying that GPL-licensed code cannot form
> >> part of a technological measure that is protected under Section
> >> 1201.  It is not saying that a copyright owner has the power to
> >> authorize the circumvention of a technological lock applied by
> >> someone else to their work.
> >
> > I think you have this spot on as it relates to the GPL. It is not
> > talking
> > about other works at all but about this work being considered a
> > part of an
> > effective technological measure. (At least I read it the same way
> > you do. If
> > I understand your take correctly.)
> >
> > all the best,
> >
> > drew
> >
> >> On Sep 25, 2006, at 6:01 AM, Terry Hancock wrote:
> >>> Greg London wrote:
> >>>>>> 3) allow DRM/TPM, but explicitly grant permission to crack it
> >>>>>
> >>>>> as i indicated in the table circulated on the list earlier,
> >>>>> this is
> >>>>> not imo, a viable option.
> >>>>
> >>>>  I'm sorry. I must have skimmed over that email in a rampant battle
> >>>>  with spam. could you send a URL to the archives where this is
> >>>>  explained?
> >>>
> >>> Obviously, I hadn't seen it either, so maybe it bears repeating?
> >>>
> >>>>  Of all the options, I thought this was the best because it allowed
> >>>>  TPM, which should make debian folks happy, it didn't require
> >>>> parallel
> >>>>  distribution, which should make someone happy, and it authorizes
> >>>>  circumvention, which means that if TPM actually IS used to
> >>>> attempt a
> >>>>  fork, it cannot be maintained.
> >>>
> >>> I like the explicit permission to crack TPM, because of these
> >>> reasons,
> >>> but I would like the license to *also* require parallel
> >>> distribution as
> >>> an additional safeguard.
> >>>
> >>> The problem is that while the permission to crack the TPM defeats
> >>> the legal obstacle (at least barring Mia's objection, which as I
> >>> say, I
> >>> haven't seen yet),  it still potentially leaves the technical
> >>> obstacle
> >>> in place (IOW, we're still limited by the sophistication of our
> >>> cracking
> >>> technology -- on the plus side, that provides a legitimization of
> >>> such
> >>> technology projects, but I don't think that's a good enough reason).
> >>>
> >>> A potential half-way point would be to re-word the anti-TPM language
> >>> to be more evidently anti-"use of TPM to impede distribution", e.g.:
> >>>
> >>> "You may not use technological protection measure in such a way that
> >>> they impede the further distribution or examination of the
> >>> content,..."
> >>>
> >>> and then one could add the permission incidentally:
> >>>
> >>> "furthermore you grant permission to circumvent any TPM measure
> >>> imposed on this content by you or others"
> >>>
> >>> (obviously, IANAL, but I hope this conveys the general idea).
> >>>
> >>> The point is, I'm pretty sure that enables Debian's "parallel
> >>> distribution"
> >>> concept without a lot of complexity, without much change from what's
> >>> already in the license, and while still retaining a negative
> >>> connotation
> >>> for TPM (which ISTM was the real objection at iCommons, from the
> >>> description I've heard).
> >>>
> >>> On a related note, the United States congress is now considering a
> >>> bill to make this permission an implicit part of US law (a much
> >>> better
> >>> long-run solution), in the form of "HR 1201" which is supposed to
> >>> amend the DMCA to allow circumvention, whenever access would
> >>> otherwise be permitted by copyright law (my paraphrase).  The EFF
> >>> has a nifty tool to help send your opinion to your congressman if
> >>> you
> >>> are a US citizen:
> >>>
> >>> http://action.eff.org/site/Advocacy?id=115
> >>>
> >>> Cheers,
> >>> Terry
> >>>
> >>>
> >>> --
> >>> Terry Hancock (hancock AT AnansiSpaceworks.com)
> >>> Anansi Spaceworks http://www.AnansiSpaceworks.com
> >>>
> >>> _______________________________________________
> >>> cc-licenses mailing list
> >>> cc-licenses AT lists.ibiblio.org
> >>> http://lists.ibiblio.org/mailman/listinfo/cc-licenses
> >>
> >> _______________________________________________
> >> cc-licenses mailing list
> >> cc-licenses AT lists.ibiblio.org
> >> http://lists.ibiblio.org/mailman/listinfo/cc-licenses
> >
> > --
> > (da idea man)
> > http://www.ourmedia.org/node/145261
> > Record a song and you might win $1,000.00
> > http://www.ourmedia.org/user/17145
> > _______________________________________________
> > cc-licenses mailing list
> > cc-licenses AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/cc-licenses
>
> _______________________________________________
> cc-licenses mailing list
> cc-licenses AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/cc-licenses

-- 
(da idea man)
http://www.ourmedia.org/node/145261
Record a song and you might win $1,000.00
http://www.ourmedia.org/user/17145