Re: What is the "open web" ?

Sent from my iPhone

On Jun 3, 2013, at 1:26 PM, Gervase Markham <gerv@mozilla.org> wrote:

> On 03/06/13 15:54, Mark Watson wrote:
>> You may be right, but today you need to buy a graphics card containing
>> non-free software.
>
> Depends what you mean by "containing". I believe the free-ness of the
> drivers for most of the Intel graphics chipsets goes pretty far down
> these days. Your CPU also runs proprietary microcode, after all.
>
> 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 ?

>
>> And you can be sure that the makers of those cards
>> have been filing patents on what they do for years, so equally
>> performant free solutions are going to be a challenge.
>
> You say that; but we recently managed a patent-free audio codec which
> outperforms all the others using out-of-patent techniques, at least in
> part because they didn't have to contort the design to make sure it used
> at least one patent from everyone in a huge consortium. (OPUS.)
>
> Regardless, patents are not global, and patents expire.
>
>> Having said that, I don't think many people see this as a huge problem
>> or a reason why WebGL should not be part of the web platform.
>
> WebGL as a spec does not _require_, in and of itself, the use of
> proprietary technology. Some (or even, for the sake of argument, all)
> current implementations may do, but that is incidental - it's not
> written into the spec itself. Emmanuel's distinction is a helpful
> clarification here, I think - thanks to him for that.
>
>>> I think that non-RF patents have no place in any system described as
>>> open, no.
>>
>> Just to check I understand correctly, you would object to inclusion in
>> the web platform of APIs for any system capability that required
>> non-free licenses to implement ? Even if that capability is fully
>> standardized and widely available in commodity hardware modules for
>> all platforms ? (For example 3G wireless Internet modules.)
>
> 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 ?

>
> I find it hard to answer that question because I can't think of a
> concrete example. (And a lot of people seem to be keen to ensure that
> there never is one.)
>
>>> You would also be required to buy
>>> particular DRM-compatible hardware rather than being able to have a free
>>> choice of hardware.
>>
>> 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.

>
>>> But I can't imagine a DRM system which
>>> could be reasonably and accurately described as "open", or be an
>>> official part of something so described.
>>
>> Well, this is getting off-topic, but there's OpenIPMP.
>
> That's DRM software, not a system. Does Netflix support OpenIPMP?
>
>> But a DRM
>> system being open (anyone can build servers and matching clients) is
>> different from being able to build clients that work with someone
>> else's existing servers.
>
> Well, quite :-)
>
> Gerv
>
>

Received on Tuesday, 4 June 2013 01:54:55 UTC