Re: What is the "open web" ?

On 04/06/13 02:54, Mark Watson wrote:
>> I think the FSF's distinction of "if someone else can modify it, you
>> should have freedom with regard to it" is a useful one here.
> 
> Interesting. So, firmware that is truly burned into ROM is ok, but
> anything stored in memory that is physically modifiable needs to be
> modifiable also by the user. Is that the intended meaning ?

That is where the FSF draw the line for the GPLv3. And I think it's
useful to avoid getting sucked into increasingly angels-on-a-pin
discussions about whether having a truly Open Web requires you to be
accessing it from a computer with Free Software microcode.

But I think we are getting off the point. The distinction between making
EME/CDMs part of the web platform, and any of your other examples, is
that by their very design and nature, EME/CDMs require gatekeepers from
whom you need permission to implement the function. It's a feature, not
a bug. To some extent the requirement of gaining permission is true of
patented non-RF technologies - but in that case, it's clearly identified
as a bug, not a feature, which is why they are considered a problem for
the Open Web, and avoided, by W3C policy. But even then, it's not a
requirement to the same extent, because patents are non-global and
expire but (if robust) the EME/CDM system requires permission to be
gained from the gatekeeper by everyone, for all time, everywhere.

>> I would think it very weird if the web platform came up with a
>> capability which _required_ the use of specifically 3G access to the
>> Internet.
> 
> Sure, but one can easily imagine APIs that expose capabilities that
> are only available on 3G/4G wireless networks. Those standards are
> full of stuff that could reasonably be subject to application control.
> Maybe we could take exposing the available mobile networks as an
> example ?

It seems to me that you are trying to get at the point: "if it's OK to
have an interface to platform-provided non-Freely-implemented service X,
then why not thing Y, e.g. a CDM?" But if that fact that X is
non-Freely-implemented is a sub-optimal thing, and if X and Y are
independent, why should the existence of X make people any more willing
to accept Y? It seems like a step backwards, not a step sideways.

>>> For the sake of argument, lets suppose that your choice of hardware
>>> does not restrict the set of services you can access, provided the
>>> hardware supports this capability at all.
>>
>> That rather seems to be "hypothesis contrary to fact". "If the moon were
>> made of green cheese, what effect would that have on the space program?
>> Well..."
> 
> Not at all. Our service supports a small number of different DRMs
> today in order to reach a wide rang if devices. I don't expect that
> set to grow much. I can easily imagine a situation where graphics
> cards generally support one of a small set of DRMs and most or all
> services support all the DRMs in that set.
> 
>  Remember the intention of EME is to *avoid* a proliferation of
> incompatible plugin-based solutions.

You would still be required to buy DRM-compatible hardware, which would
have restrictions on its capabilities mandated by the DRM manufacturer.

As Hixie has wisely pointed out, DRM is not about stopping people
copying things, it's about giving content owners leverage over playback
device providers. If you embed the CDM in the graphics hardware, it
simply means that they exercise that leverage over graphics card
manufacturers instead of OS manufacturers, plugin manufacturers or
browser makers. The end result is still that users don't get the
capabilities they want out of their system because their idea of what is
reasonable to do conflicts with someone else's.

Gerv

Received on Tuesday, 4 June 2013 09:19:46 UTC