Re: Alternatives to DRM?

On Tue, Apr 23, 2013 at 5:25 PM, Jeff Jaffe <jeff@w3.org> wrote:
> First, I would make clear that I don't believe that content owners are even
> close to giving up on DRM.

OK. Targeting content to user-modifiable CDMs would amount to giving
up on DRM, so we should equally believe not to be even close to
user-modifiable CDMs.

> DRM opponents have told me that DRM doesn't work.  They assert that every
> DRM system built has been broken and presumably every such system will be
> broken.
>
> Based on that, why do content owners continue to advocate DRM?  I can only
> guess.  But I imagine that the combination of social contract and difficulty
> in avoiding the installed DRM system is what they are relying on.

Systems that treat end-users as untrusted are terrible for
establishing social contracts. I think the ability to invoke
anti-circumvention law even over broken DRM is the more likely
explanation. Consider HDCP. Even though the keys were leaked, the
threat that HDCP might still constitute an "effective technical
protection measure" gives Hollywood control over what features
law-abiding consumer electronics makers can put in mass-market
devices.

> DReaM is not an example of (as you call it), "giving up on DRM".

I didn't suggest it was. I said user-modifiable (as in user-buildable
as opposed to the user having to send modifications to someone else
for building) DRM amounts to giving up on DRM. DReaM was a system with
disclosed source code (except for private keys). AFAICT, it wasn't a
system where end-users could build the client-side implementation of
DRM from source *and have it work* (in the sense of being able to use
it to render the same movies as with a build made by someone else).

> So while DReaM would be easier to break than DRM, it shares some of the
> advantages (to content owners) as real DRM.

Why do you categorize DReaM as something other than "real DRM"?

> I pointed out (on April 12th) in response to Dom that DReaM exists.

DReaM doesn't exist anymore. It's a dead project. AFAICT, the major
Hollywood studios never made a substantial portfolio of movies
available using DReaM. Therefore, DReaM doesn't really prove anything
of relevance.

However, even if one assumes that DReaM would have been acceptable to
major Hollywood majors, DReaM would still only be proof that a DRM
scheme can be "open source" in the sense that the source code except
keys is disclosed. It wouldn't be proof of being Open Source in the
sense of downstream recipients of the source code enjoying the
freedoms typically associated with Open Source.

> You pointed out (on April 22nd) that there are flaws in this.

More to the point, I pointed out that "open source" in the sense of
"disclosed source code except keys" is not particularly interesting
and the more interesting questions are whether everyone downstream
gets to build a fully-functioning CDM and whether downstream gets to
do so on an RF basis--i.e. whether the downstream freedoms associated
with Open Source are actually there. DReaM seems to have been in the
"disclosed source code except keys" category.

> I pointed out that there are answers to these flaws.

I don't think you addressed my point about the flaw in the framing of
the question or my point about Open Source not only about being about
disclosed source but also about the recipients of the source code
actually having the freedoms necessary build and distribute
interoperable products using the source code.

>> If a DRM scheme is incompatible with GPLv3, it's a pretty strong hint
>> that it's incompatible with some important things typically associated
>> with Open Source other than mere source disclosure, such as
>> royalty-freeness and the disclosed source actually being useful to a
>> downstream recipient.
>
> I'm not sure I understand this argument.  Are you saying that DReaM is
> incompatible with other open source licenses as well?

GPLv3 is the license that most strongly protects the ability of
downsteam licensees to exercise all the relevant software freedoms
associated with Open Source or Free Software. If a technical scheme is
not compatible with GPLv3, it's a strong hint that there's a catch
somewhere that denies relevant freedoms to downstream recipients even
if the source code has been disclosed. The disclosure of source code
can be rendered useless to would-be downstream users of the source
code if using or distributing a product built from the source is
encumbered by patents or if the origin of executable builds of the
source is required to be cryptographically certified such that
interoperability can be denied to executable builds depending on who
made them.

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 24 April 2013 07:07:17 UTC