Re: Alternatives to DRM?

On 4/24/2013 2:35 AM, Henri Sivonen wrote:
> 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.

Sorry for the misunderstanding.  In the thread we were talking about 
DReaM.  I said that content owners might be willing to compromise to 
accept DReaM type systems.  You said that compromise would mean giving 
up on DRM.  That was why I thought you said that DReaM would mean giving 
up on DRM.

>   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.

I think you are missing the context of the April 12th response.  Dom had 
asked whether there was an open source compatible DRM solution. I said 
"DReaM appears to indicate feasibility."

>
> 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.

Correct.  I did not address this point.  Actually, to be precise, I 
conceded that DReaM (to my understanding) is probably NOT compatible 
with GPLv3.

Dom, in framing this as a question about open source compatible DRM was 
anchoring the discussion on a long-established W3C practice to make sure 
that our standards are implementable in open source.  I was merely 
pointing out that this would be possible with DReaM.

To your point, W3C could certainly add a new practice to make sure that 
our standards are compatible with the "no 'disclosed source code except 
keys'" category.  In that case DReaM like solutions would indeed be 
excluded.

>
>>> 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 11:33:12 UTC