Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 11 Dec 2013 19:08:13 +0000

I would like to point out that Cisco has published the initial source code for the H.264 codec. You can find it from the source code links at http://www.openh264.org/

There still lots of work going on build, test system, other architectures etc. If you want to read the code and see what is there, feel free to browse. If you are feeling brave and like living on the bleeding edge, go ahead compile it, and try out. Be warned that significant refactoring is happing as this gets moved to support the binary module. The binary module will not be up till early next year.  There is a bit of information about what is supported at https://github.com/cisco/openh264/blob/master/README.md The appropriate mailing list for discussing it is [email-masked] and you can subscribe at https://groups.google.com/d/forum/openh264-dev 

There is also a 5 minute video that helps explain the "open source code" and "binary download" and other IPR issues as that seems to cause confusion for folks. You can find it at http://vimeo.com/cullenfluffyjennings/openh264-ipr

Cullen

On Oct 30, 2013, at 6:28 AM, Jonathan Rosenberg (jdrosen) <[email-masked]> wrote:

> I’d like to make an announcement material to the conversations around MTI video codecs in rtcweb.
>  
> Cisco is announcing today that we will take our H.264 implementation, and open source it under BSD license terms. Development and maintenance will be overseen by a board from industry and the open source community.  Furthermore, we will provide a binary form suitable for inclusion in applications across a number of different operating systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module available for download from the Internet. We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms.
>  
> We believe that this contribution to the community can help address the concerns many have raised around selection of H.264 as MTI. I firmly believe that with H.264 we can achieve maximal interoperability and now, do it with open source and for free (well, at least for others – its not free for Cisco J)
> More information on the open source project can be found at http://www.openh264.org, which is sparse now but more coming soon.
>  
>  
> Thx,
> Jonathan R.
>  
> --
> Jonathan Rosenberg, PhD
> VP, CTO Collaboration
> Cisco Systems
> [email-masked]
>  
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Ron <[email-masked]>
Date: Thu, 12 Dec 2013 06:02:39 +1030

On Wed, Dec 11, 2013 at 07:08:13PM +0000, Cullen Jennings (fluffy) wrote:
> There is also a 5 minute video that helps explain the "open source code" and
> "binary download" and other IPR issues as that seems to cause confusion for
> folks. You can find it at http://vimeo.com/cullenfluffyjennings/openh264-ipr

I don't suppose that you have a webm version of that which I'd actually be
able to watch in any of the currently popular browsers do you?

vimeo just says "Jeepers!  This video can't be played".

  Ron

---

From: Paul Giralt <[email-masked]>
Date: Wed, 11 Dec 2013 14:54:37 -0500

> vimeo just says "Jeepers!  This video can't be played".

Plays in Firefox, Safari, and Chrome for me. 

-Paul

---

From: Leon Geyser <[email-masked]>
Date: Wed, 11 Dec 2013 22:24:21 +0200

I guess you have Windows 7/8?
Firefox only supports H.264 playback if the OS can provide a decoder as far
as I know. WebM is natively supported by Firefox without relying on the OS
or plugins.

---

From: Paul Giralt <[email-masked]>
Date: Wed, 11 Dec 2013 15:31:56 -0500

No - I'm on a Mac. Someone else pointed out to me that this is likely because it's playing using Flash Player. I didn't really dig into how it was working. Now that I see that ron is likely using Debian, that explains why he wouldn't be able to see it. My mistake. 

-Paul

On Dec 11, 2013, at 3:24 PM, Leon Geyser <[email-masked]> wrote:

> Firefox only supports H.264 playback if the OS can provide a decoder as far as I know. WebM is natively supported by Firefox without relying on the OS or plugins.
> 
>

---

From: Kaiduan Xie <[email-masked]>
Date: Wed, 11 Dec 2013 16:09:33 -0500

It works on Chrome Mac and Ubuntu Linux :)

Very clear explanation, Cullen!

/Kaiduan

On Wed, Dec 11, 2013 at 3:31 PM, Paul Giralt <[email-masked]> wrote:

> No - I'm on a Mac. Someone else pointed out to me that this is likely
> because it's playing using Flash Player. I didn't really dig into how it
> was working. Now that I see that ron is likely using Debian, that explains
> why he wouldn't be able to see it. My mistake.
>
> -Paul
>
> Firefox only supports H.264 playback if the OS can provide a decoder as
> far as I know. WebM is natively supported by Firefox without relying on the
> OS or plugins.
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Dec 2013 16:50:24 -0700

On Dec 11, 2013, at 12:32 PM, Ron <[email-masked]> wrote:

>> You can find it at http://vimeo.com/cullenfluffyjennings/openh264-ipr
> 
> I don't suppose that you have a webm version 

I'm really not trying to be difficult about this but I do have a ton of other things I should doing and none of the major video production tool support VP8 so it's not trivial for me to make a VP8 version. If I uploaded it to youtube, would that make it work for you? It is CC licensed so if you want to put up a webm version of it, that would be cool. 

On the other hand I could convert it to H.261 and see if anyone can figure out how to play that.  :-) (And thanks to Maik for putting the H.261 code out there ).

---

From: cowwoc <[email-masked]>
Date: Wed, 11 Dec 2013 19:05:16 -0500

Cullen,

Could you please respond to Engel Nyst's comment on this thread? He wrote:

"I am concerned about the fake appearances Cisco is giving. The code 
"appears" to be BSD-licensed, and github repository gives no indication 
to well intended people that in reality it's not. Forking the repository 
and building a derivative release *already runs afoul* of MPEG-LA 
restrictions and exposes people to uncertainty and being chased for 
fees, when it's a natural thing to do.
Misleading people that an implementation is open source when it's not is 
an unacceptable action in my book, under any shape or form; and I will 
keep short here as to other practical scenarios and issues that it brings. "

What is Cisco's official position on this?

Thank you,
Gili

---

From: Ron <[email-masked]>
Date: Thu, 12 Dec 2013 11:45:50 +1030

On Wed, Dec 11, 2013 at 04:50:24PM -0700, Cullen Jennings wrote:
> I'm really not trying to be difficult about this but I do have a ton of other
> things I should doing and none of the major video production tool support VP8
> so it's not trivial for me to make a VP8 version. If I uploaded it to
> youtube, would that make it work for you? It is CC licensed so if you want to
> put up a webm version of it, that would be cool. 

I really wasn't trying to be difficult on this either (it's not like we have
any shortage of real difficulties to get past :) but there was a certain
irony to the explanation being in a format that the people who might be most
interested in its details wouldn't be able to view.

Letting youtube transcode it, or putting a downloadable version somewhere
that someone who is better equipped to do this can do that would be fine.

> On the other hand I could convert it to H.261 and see if anyone can figure
> out how to play that.  :-) (And thanks to Maik for putting the H.261 code out
> there ). 

Or you could do an MJPEG one, assuming there's no sign language in it that
might become illegible :D

  Cheers,
  Ron

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 Dec 2013 11:21:01 -0700

> that someone who is better equipped to do this can do that would be fine.

Give http://youtu.be/YMZz4M4ab4U a try and let me know if that works for you.

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 05:08:52 +1030

> Give http://youtu.be/YMZz4M4ab4U a try and let me know if that works for you. 

That one works with a WebM transcode, thanks!

  Ron

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Dec 2013 13:51:31 -0500

Cullen,

I got several question regarding this:

1. Have Cisco finalized the license terms for open H.264 binary
distribution? Is this for personal communications only? What are the exact
restrictions on what can this be used for, such as can it be used for an
MCU which provides a commercial conferencing service?

2. Do you absorb just MPEG-LA IPR license fees or do you absorb all the IPR
license fees needed to run the binary? For instance, do you have agreement
with Nokia in place? Have you encoder been reviewed regarding the IPR not
covered by MPEG-LA license which covers decoder only?

3. Is there are going to be an open process in place for third parties to
provide IPR declarations? For instance somebody detects that Cisco codec
infringes on their IPR and decides to sue the users vs Cisco. Having an
open process to disclose IPR might serve as a protection tactic, since if
the such third party is suing people without making their IPR claim
publicly available, they can be more easily defended against.

4. Who would be allowed to host the binary modules on Cisco site? How
friendly do you have to be with Cisco to get a module version which is
specific to you to be hosted on the Cisco site?

5. What would be the IPR terms for any changes contributed to Cisco codec?
Would you require a contributor to provide all users of this site a free
license?

Regards,

_____________
Roman Shpount

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 12 Dec 2013 18:54:24 +0000

Cisco and the openh264 project is certainly not trying to mislead anyone on the state of IPR on the openh264 project. When you go to http://www.openh264.org/ , the front page discusses the MPEG-LA licensing and make it clear how things are provided. The http://www.openh264.org/faq.html adds more information. The front page of the project also has a link to Cisco's public statements on the subject at http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc . That blog posting also make it clear that relation between the open source and MPEG-LA patent licensing. 

The definition I use for Open Source is the one provided by http://opensource.org/. Largely I use this because I think they have the longest standing definition that has the widest consensus but also they have the trade mark for the term. 

Code can have patents that apply to it and still be Open Source. VP8 and Opus are examples of this. Code can have patents that are not royalty free that apply to it and still be Open Source. x264 is an example of this. Code can be BSD licensed and have patents that apply to it. openh264 is an example of that. 

The MPEG-LA licenses allow people to to fork and build and run things in small quantities. This allows developers to build products and try things out without any trouble before they have to license things. Setting small quantities at a hundred thousand seems pretty generous to me. So I disagree that people that fork and build this are automatically running afoul of the MPEG-LA. And people in the open source community might want to give some thought to how x264 and ffmeg projects work and how long they have been working this way. 

I agree misleading people about if something is Open Source or not is not cool in my book either. If anyone thinks the openh264.org code is not BSD licensed, send me facts on why and we can make sure that it is. 

On Dec 11, 2013, at 5:05 PM, cowwoc <[email-masked]> wrote:

> "I am concerned about the fake appearances Cisco is giving. The code "appears" to be BSD-licensed, and github repository gives no indication to well intended people that in reality it's not. Forking the repository and building a derivative release *already runs afoul* of MPEG-LA restrictions and exposes people to uncertainty and being chased for fees, when it's a natural thing to do. 
> Misleading people that an implementation is open source when it's not is an unacceptable action in my book, under any shape or form; and I will keep short here as to other practical scenarios and issues that it brings. "
> 
>> There still lots of work going on build, test system, other architectures etc. If you want to read the code and see what is there, feel free to browse. If you are feeling brave and like living on the bleeding edge, go ahead compile it, and try out. Be warned that significant refactoring is happing as this gets moved to support the binary module. The binary module will not be up till early next year.  There is a bit of information about what is supported at 
>> https://github.com/cisco/openh264/blob/master/README.md The appropriate mailing list for discussing it is [email-masked] and you can subscribe at https://groups.google.com/d/forum/openh264-dev
>>  
>> 
>> There is also a 5 minute video that helps explain the "open source code" and "binary download" and other IPR issues as that seems to cause confusion for folks. You can find it at 
>> http://vimeo.com/cullenfluffyjennings/openh264-ipr
>> 
>> 
>> Cullen
>> 
>> 
>> 
>> On Oct 30, 2013, at 6:28 AM, Jonathan Rosenberg (jdrosen) 
>> <[email-masked]>
>>  wrote:
>> 
>> 
>>> More information on the open source project can be found at 
>>> http://www.openh264.org
>>> , which is sparse now but more coming soon.
>>>  
>>>  
>>> Thx,
>>> Jonathan R.
>>>  
>>> --
>>> Jonathan Rosenberg, PhD
>>> VP, CTO Collaboration
>>> Cisco Systems
>>> 
>>> [email-masked]
>>> 
>>>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 Dec 2013 11:59:31 -0700

Great - glad that worked and let me know if that helps clarify the situation.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 Dec 2013 12:37:13 -0700

On Dec 12, 2013, at 11:51 AM, Roman Shpount <[email-masked]> wrote:

> 1. Have Cisco finalized the license terms for open H.264 binary distribution?

no

> Is this for personal communications only?

doubt I know you mean by "personal communications" and I encourage people who think they understand what MEPG-LA means by non commercial to go talk to your lawyers because it is a specifically defined term that does not mean what you might think using an english dictionary.  I do encourage people to actually read the MPEG-LA FAQ on licensing for AVC as it provides a good way to understand this.  Let me try and answer this much more directly in next question. 

> What are the exact restrictions on what can this be used for, such as can it be used for an MCU which provides a commercial conferencing service?

This is the type of licenses people used in things like Webex (which includes what I think you would call commercial conferencing), Skype, Cisco video conferring system used by business for doing business calls, video conferencing MCU, google hangouts, apple face time, various commercial soft phone and hard phones, the list goes on. 

> 
> 2. Do you absorb just MPEG-LA IPR license fees or do you absorb all the IPR license fees needed to run the binary? For instance, do you have agreement with Nokia in place? Have you encoder been reviewed regarding the IPR not covered by MPEG-LA license which covers decoder only?

The Cisco messaging has been very clear about this. Obviously no one can know about patents they don't know about and Cisco is not distributing a binary module that  they don't legally have the right to distribute. 

Think about someone else, who if the first person who gets sued if some new IRP comes up on H.264. It won't people Mozilla who are distributing Firefox with no H.264 code in it, it is more likely to be Cisco who is distributing the binary download that contains the H.264 code.  Google taking a similar approach with a VP8 binary module might help alleviate some of the concerns about IPR on VP8. 

> 
> 3. Is there are going to be an open process in place for third parties to provide IPR declarations?

> For instance somebody detects that Cisco codec infringes on their IPR and decides to sue the users vs Cisco. Having an open process to disclose IPR might serve as a protection tactic, since if the such third party is suing people without making their IPR claim publicly available, they can be more easily defended against.

Sure - just send it to the email list. 

> 
> 4. Who would be allowed to host the binary modules on Cisco site? How friendly do you have to be with Cisco to get a module version which is specific to you to be hosted on the Cisco site?

I'd probably rephrase that question a bit since Cisco is taking the open source and compiling it and putting up the binary module but I think I know what you are getting at. Lets say polycom, one of Cisco's largest competitor in video conferencing, wanted to to add an option to the code to support the foo feature in the codec because they like to use that and sent  a patch under BSD license. I would imagine the governance board for the open source project would accept that and Cisco would start building it into the binary modules. 

Let me give an example the other way. Someone ports it to a vax780 and wants Cisco to dispute that. Until it was clear that the number of downloads for that was going to get close to 100 thousand, I doubt people would be keen on making a binary for it because the person can easily host it themselves. 

Lets say there is some API you need to make it so you can do they type of control you want in a VP8 to H.264 transcoder and you submit a patch for that and it looks like it would in over 100k volumes. As long as it does not break other things, it's really hard imaging it would not be accepted. 

> 
> 5. What would be the IPR terms for any changes contributed to Cisco codec? Would you require a contributor to provide all users of this site a free license? 

not sure what you mean by free license but ..

They patches would need to be BSD licenses, but no, we can't ask for a licenses to all patents that apply to the patch. Lets say you decided to implement high profile for the codec (we hope someone does that but it's not in the code yet) and contribute the code under BSD. There is no way you can provide royalty free license to all the patents on that because you don't own all the patents. However, we would still very much like to take the code because we can include that in the binary module and make it a better codec.

---

From: cowwoc <[email-masked]>
Date: Thu, 12 Dec 2013 15:02:10 -0500

On 12/12/2013 2:37 PM, Cullen Jennings wrote:
> The Cisco messaging has been very clear about this. Obviously no one 
> can know about patents they don't know about and Cisco is not 
> distributing a binary module that they don't legally have the right to 
> distribute. Think about someone else, who if the first person who gets 
> sued if some new IRP comes up on H.264. It won't people Mozilla who 
> are distributing Firefox with no H.264 code in it, it is more likely 
> to be Cisco who is distributing the binary download that contains the 
> H.264 code. Google taking a similar approach with a VP8 binary module 
> might help alleviate some of the concerns about IPR on VP8.

Two questions about this:

 1. To Google: When is it coming?
 2. To VP8-detractors: would such a binary change your mind about
    supporting VP8 as MTI?

Thanks,
GIli

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Dec 2013 15:04:31 -0500

On Thu, Dec 12, 2013 at 2:37 PM, Cullen Jennings <[email-masked]> wrote:

> Think about someone else, who if the first person who gets sued if some
> new IRP comes up on H.264. It won't people Mozilla who are distributing
> Firefox with no H.264 code in it, it is more likely to be Cisco who is
> distributing the binary download that contains the H.264 code.  Google
> taking a similar approach with a VP8 binary module might help alleviate
> some of the concerns about IPR on VP8.
>

>From personal experience this assumption is incorrect. Typical patent troll
would go after a number of smaller users, get settlement to provide history
that they have a valid IPR claim and then go after big guys.

> > For instance somebody detects that Cisco codec infringes on their IPR
> and decides to sue the users vs Cisco. Having an open process to disclose
> IPR might serve as a protection tactic, since if the such third party is
> suing people without making their IPR claim publicly available, they can be
> more easily defended against.
>

I think it would be beneficial to have a place on openh264 site where the
site owners (Cisco) would specifically ask any third party to disclose
their IPR claims against this implementation. I want to make sure that if I
get sued, I can point to something more then your email on the list and say
that this party was given the opportunity to disclose their claim and
failed to do so.  I am not talking about my IPR that I want to disclose, I
want to make sure that patent trolls are exposed for what they are. To be
fair, the same mechanism would benefit VP8 as well.

> > 5. What would be the IPR terms for any changes contributed to Cisco
> codec? Would you require a contributor to provide all users of this site a
> free license?
>
> They patches would need to be BSD licenses, but no, we can't ask for a
> licenses to all patents that apply to the patch. Lets say you decided to
> implement high profile for the codec (we hope someone does that but it's
> not in the code yet) and contribute the code under BSD. There is no way you
> can provide royalty free license to all the patents on that because you
> don't own all the patents. However, we would still very much like to take
> the code because we can include that in the binary module and make it a
> better codec.
>

At this time I am talking about the IPR that I, as a contributor own. For
instance I have, my own patented way to improve the encoder and I
contribute the code to the project. Would the contribution agreement put
any requirements on the conditions under which I contribute this IPR to the
project?
_____________
Roman Shpount

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 07:23:08 +1030

On Thu, Dec 12, 2013 at 06:54:24PM +0000, Cullen Jennings (fluffy) wrote:
> 
> Cisco and the openh264 project is certainly not trying to mislead anyone on
> the state of IPR on the openh264 project. When you go to
> http://www.openh264.org/ , the front page discusses the MPEG-LA licensing and
> make it clear how things are provided. The http://www.openh264.org/faq.html
> adds more information. The front page of the project also has a link to
> Cisco's public statements on the subject at
> http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc
> . That blog posting also make it clear that relation between the open source
> and MPEG-LA patent licensing. 

Yes, I need to agree with Cullen here.  It's important that people who are
concerned about the IPR encumbrance of H.264 (or anything else here) not
conflate that with a particular source implementation not being "Open Source".

These are two orthogonal things.

Cisco has been a bit handwavy on the topic of "oh those other patent holders
outside the MPEG-LA", but their FAQ does clearly state You're Own Your Own
with that.

Neither it nor the new video explains how their offer can actually solve
the problem that it claims to solve though.  If it isn't actually licencing
all of the *known* royalty bearing and actively pursued and litigated IPR,
then how can it have possibly solved this problem?

I wouldn't go so far as to say they've misled people.  But that very important
sticking point has been buried way down deep in the finest of fine print, and
generally been ignored when specific questions about "how is this solved?"
have been asked.

> The definition I use for Open Source is the one provided by
> http://opensource.org/. Largely I use this because I think they have the
> longest standing definition that has the widest consensus but also they have
> the trade mark for the term. 

And, for anyone who might not already know or realise this, that definition
was in fact taken almost verbatim from the one that Debian adopted in its
earliest days, just with references to Debian made generic.

I don't think anyone who understands either of those definitions would
deny that BSD licenced source code is indeed "open source".

But it's also important to realise that this was an Elegant Definition
For A More Civilised Age.

Specifically it dates to a time when Copyright was the only significant
law that universally applied to the rights you had for a piece of software.
Most people consider that it still only applies to copyright, since patents
are less universal, and trying to define things around a myriad of local
laws, some of which are still in flux, is a much more difficult problem.

That said though, if you were to look at the entirety of the licencing
required to actually _use_ this software, including the patent licences
in the jurisdictions where they are valid - then this would fail to meet
this definition of "Open" on the following points:

 3. Derived Works

  The license must allow modifications and derived works, and must allow
  them to be distributed under the same terms as the license of the original
  software.

If you take Cisco up on their offer of absorbing the MPEG-LA fees, but
only if you use their blob, it fails this test.  Even if you don't, the
licence you buy will not be transitive still.

 5. No Discrimination Against Persons or Groups

  The license must not discriminate against any person or group of persons.

Whether or not it fails this point depends a bit on how much you believe
in the fantasy of FRAND.

 6. No Discrimination Against Fields of Endeavor

  The license must not restrict anyone from making use of the program in a
  specific field of endeavor. For example, it may not restrict the program
  from being used in a business, or from being used for genetic research.

The MPEG-LA licence being granted with The Blob fails this test AIUI, since
it's limited in the scope of uses you are permitted.

 7. Distribution of License

  The rights attached to the program must apply to all to whom the program
  is redistributed without the need for execution of an additional license
  by those parties.

This fails for much the same reason as 3.  You have no right to redistribute
The Blob under the same terms you obtained it.

 8. License Must Not Be Specific to a Product

  The rights attached to the program must not depend on the program's being
  part of a particular software distribution. If the program is extracted
  from that distribution and used or distributed within the terms of the
  program's license, all parties to whom the program is redistributed
  should have the same rights as those that are granted in conjunction with
  the original software distribution.

Fails as for 7. if you take Cisco's One True download site to be a
"particular software distribution".  You can't redistribute it with
the same rights that you obtained it.

 9. License Must Not Restrict Other Software

  The license must not place restrictions on other software that is
  distributed along with the licensed software. For example, the license
  must not insist that all other programs distributed on the same medium
  must be open-source software.

This is a slightly less clear cut failure.  But clearly the patent
terms will infect other software if that software uses The Blob.

 10. License Must Be Technology-Neutral

  No provision of the license may be predicated on any individual technology
  or style of interface.

The MPEG-LA licence is explicitly not technology neutral.

So even if we dismiss the few possibly questionable violations of the
above definitions, it would still clearly fail more than half of the
tests used for guidance about what constitutes Software Freedom once
the patent licencing terms are taken into account.

Unless you happen to live in one of the small handful of countries that
presently still laugh at the idea that software is patentable.

> Code can have patents that apply to it and still be Open Source. VP8 and Opus
> are examples of this.

The notable difference here though is that those patents are *also* licenced
under terms that are completely compatible with the Open Source Definition.

So if we put Opus to the same tests as above, it would still pass even with
the patent licences taken into account.

VP8 would similarly pass them all easily with flying colours.

If you can negotiate a patent grant, from *all* confirmed holders, under the
same or similar terms for H.264, then my objections to it would evaporate.
If you can't, then its licencing regime is nothing like that of Opus or VP8,
and though you could make the Sophisticated claim that there are Open Source
implementations of it, that would very much be a half-truth innuendo about
the rights that are granted to users and developers.

Open Source H.264 is a fine museum piece.  You can look upon it with all
the wonder that you can muster.  But you aren't free to take it home and
actually use it without risking a visit from the mob to claim their
protection money.

> The MPEG-LA licenses allow people to to fork and build and run things in
> small quantities. This allows developers to build products and try things out
> without any trouble before they have to license things. Setting small
> quantities at a hundred thousand seems pretty generous to me. So I disagree
> that people that fork and build this are automatically running afoul of the
> MPEG-LA.

Again you are calling this problem "solved" by only referring to the terms
offered by MPEG-LA.  There is no guarantee of similar conditions being
granted by the other IPR holders.  And you still can't put *anything* on
the internet and not wake up in the morning to possibly find there's now a
million copies out there being redistributed by a thousand different people.

The law of small numbers just doesn't apply there.

> And people in the open source community might want to give some
> thought to how x264 and ffmeg projects work and how long they have been
> working this way. 

Yes, have we mentioned that FRAND is broken and willfully distorted to
the advantage of the licencing mobs ;?

http://www.techdirt.com/articles/20070312/165448.shtml

"The first one is free" has been the hallmark of many of the oldest
professions, things have been working this way for a very long time
indeed  :)

> I agree misleading people about if something is Open Source or not is not
> cool in my book either. If anyone thinks the openh264.org code is not BSD
> licensed, send me facts on why and we can make sure that it is. 

There was a question raised elsewhere about the uncanny similarity of
some code in openh264 to that in x264 -- but I assume if the copyright
holders of that are concerned, then they already have been, or will be
in touch with you about that.

  Cheers,
  Ron

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 08:02:34 +1030

> Great - glad that worked and let me know if that helps clarify the situation. 

So none of what was talked about there was something that I was previously
confused about, it never really seemed that complicated to me or poorly
explained what you had in mind, my main concern was (and still is) that it
doesn't actually solve the numerous problems - and in fact creates a whole
bunch of new ones to only partly solve one problem with one H.264 patent
holding group out of several known ones.

But I couldn't know that for sure until I'd actually seen it :)

It does however raise a brand new problem (one which is actually quite
technically interesting!), and I am interested to know if that was just
a misunderstanding on your part in explaining it, or if you actually do
plan to really solve this. [1]

You talk about Mozilla fingerprinting the *source* that they verified,
and then being able to confirm that fingerprint in the binary blob they
download from the Cisco build farm.

I had previously assumed people were only planning to take a hash of
the binaries already up there, merely to ensure the blob that a user
actually downloaded wasn't some totally foreign trojan, but was what
was expected to come from the Cisco site.

There is considerable work presently being done on fully reproducible
binaries, since obviously this is of interest on many fronts, but it's
currently far from being a universally (or easily) Solved Problem.

Is Cisco actually planning to invest work into solving this (for all
architectures!) as part of this project?  Or was that just you assuming
something which probably isn't how it will actually work in practice?

The former certainly would be a cool contribution and a real and
pleasant surprise to me, independently of the problems that still
plague this as a solution to the MTI codec problem.

  Cheers,
  Ron

[1] - I am also kind of curious how you plan to deal with the fact
      that there are several thousand Debian derivatives, all of
      which may or may not be binary compatible with each other
      at any given point in time.
      But I suspect I do already know the answer to that one :)

---

From: Kaiduan Xie <[email-masked]>
Date: Thu, 12 Dec 2013 16:38:16 -0500

+1

I have been wondering can Google distribute VP8 binary module with similar
approach as CISCO's H264 binary module support for a while.

Can some one from Google confirm this?

/Kaiduan

On Thu, Dec 12, 2013 at 3:02 PM, cowwoc <[email-masked]> wrote:

> The Cisco messaging has been very clear about this. Obviously no one can
> know about patents they don't know about and Cisco is not distributing a
> binary module that they don't legally have the right to distribute. Think
> about someone else, who if the first person who gets sued if some new IRP
> comes up on H.264. It won't people Mozilla who are distributing Firefox
> with no H.264 code in it, it is more likely to be Cisco who is distributing
> the binary download that contains the H.264 code. Google taking a similar
> approach with a VP8 binary module might help alleviate some of the concerns
> about IPR on VP8.
>
>

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 08:13:10 +1030

On Thu, Dec 12, 2013 at 03:04:31PM -0500, Roman Shpount wrote:
> their IPR claims against this implementation.

We so far can't even get the organisations who have active contributors
in this WG and which hold H.264 patents to comply with their obligations
for disclosure under the IETF requirements.[1]

Why would you expect a note on a Cisco website to work any better?

  Ron

[1] - Which would unless I'm mistaken, include ...   Cisco?

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Dec 2013 16:55:56 -0500

> Why would you expect a note on a Cisco website to work any better?
If I am getting sued by somebody for IPR violation due to use of Cisco
binary and if there is a place where the person suing me could announce
that this binary violates their IPR rights, but failed to do so, I can use
it in my defense that they never tried to informed me and this is form of
entrapment. IANAL, but from experience this helps.

At least active WG contributors are not suing me yet.
_____________
Roman Shpount

---

From: Engel Nyst <[email-masked]>
Date: Fri, 13 Dec 2013 00:21:01 +0200

Cullen, thank you for giving answers in the open.

On 12/12/2013 08:54 PM, Cullen Jennings (fluffy) wrote:
> http://opensource.org/. Largely I use this because I think they have
> the longest standing definition that has the widest consensus but
> also they have the trade mark for the term.

Entirely agree. Please indulge me to look at the BSD and Open Source in 
this project.

The repository at https://github.com/cisco/openh264 has a README that says:
> License BSD, see LICENSE file for details.

Then, it only contains a LICENSE file. People come, fork the repository, 
look at the license and see:

> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
> * Redistributions of source code must retain the above
> copyright notice, this list of conditions and the following
> disclaimer.
 > * Redistributions in binary form must reproduce the above
> copyright notice, this list of conditions and the following
> disclaimer in the documentation and/or other materials provided with
> the distribution.

Note "redistributions and use in source and binary forms [...] are
permitted provided that [those two conditions] are met".

Those conditions, explicitly stated, for anyone to see. As long as 
people keep those, they're permitted to redistribute the code, in source 
or binary.

It does not say "Redistributions and use [...] are permitted provided 
that [those two conditions] AND if and only if you redistribute in small 
quantities." It does not say "You're not permitted to redistribute 
unless you track your downloads to be sure they're small quantities, and 
take it privately with Cisco and/or MPEG-LA for the... *permission to 
redistribute and use*".

Let me put it this way. There are 18 million hits on Github, if I search 
for BSD text in projects (please see for example a quick search here 
http://ur1.ca/g6h4m).

Those 18 million hits belong to projects that are BSD-licensed, and 
where "redistributions and use [...] are permitted provided that [these 
explicit two conditions] are met" is typically what it says: 
"redistributions and use [...] *are permitted* provided that [these 
explicit two conditions] are met".

That's what makes them Open Source: there is NO other "license" to get 
for "big quantities".

The expectation of the user reading that a project is BSD-licensed is to 
be what it says, and what we, in the open source community, know and 
use: the Open Source Definition. Cisco's project breaks badly that 
expectation, and there is no indication in the repository that this 
"BSD-licensed" refers to "redistributions sort of permitted, but only 
for small quantities".

> Code can have patents that apply to it and still be Open Source.

Of course, I have to agree, it is true that patents can apply to any 
code. That's the legal system, nothing to do with Cisco, it's reality.

However, Cisco and MPEG-LA reserves patent rights and does not include 
the licensing in the BSD license.

THAT is to say it does not comply with the Open Source Definition. It is 
Open Source if there is NO other license for people to strike deals for 
*redistribution* in "big quantities".

Please see Open Source Definition, condition #7.

 > The rights attached to the program must apply to all to whom the
 > program is redistributed *without the need for execution of an
 > additional license by those parties*.

It does not seem to me that the "BSD-licensed *but* in reality you are 
not allowed to redistribute in binary, and/or for some quantities make a 
deal with MPEG-LA" complies with this condition.

Condition #3.

 > The license must allow modifications and derived works, and must
 > allow them to be distributed under the same terms as the license of
 > the original software.

I don't think the Cisco project license ("BSD but you are not allowed to 
distribute under BSD") complies at all.

> VP8 and Opus are examples of this. Code can have patents that are not
> royalty free that apply to it and still be Open Source. x264 is an
> example of this. Code can be BSD licensed and have patents that
> apply to it. openh264 is an example of that.

Allow me to make a quick comparison between H.264 and VP8 (WebM).

H.264.
"BSD-licensed" with no patent license, added to the knowledge that 
MPEG-LA does not allow redistributions in binary or source form, 
modified or not.

In other words, it *cancels* some of the permissions granted in BSD.

VP8.
BSD-licensed and a patent grant, both from Google and from any 
contributor to VP8.

If I remember history correctly (please correct me if wrong), Google has 
bought all patents known at the time, before open sourcing VP8. Then it 
has offered a free and open license to all the patents they owned and 
those they get in the future. From VP8 patent grant:

 > Google hereby grants to you a perpetual, worldwide, non-exclusive,
 > no-charge, royalty-free, irrevocable (except as stated in this
 > section) patent license to make, have made, use, offer to sell, sell,
 > import, transfer, and otherwise run, modify and propagate the
 > contents of this implementation of VP8, where such license applies
 > only to those patent claims, both currently owned by Google and
 > acquired in the future, licensable by Google that are necessarily
 > infringed by this implementation of VP8.

The WebM project offers a patent license, which is exactly what one 
would expect because *it's entirely in-line with what BSD says*.

Google and any contributor to VP8 offer it. They can't do more (no one 
can offer a license for someone else's claims), but they do this.

This isn't the case of H.264 by a long shot. Redistribution in binary 
form, not actually permitted. Redistribution in source form, not 
actually permitted. Both, perhaps for "100k units" or "small downloads". 
Patents are withheld, and used to practically *cancel* the permissions 
granted in BSD text.

> I agree misleading people about if something is Open Source or not
> is not cool in my book either. If anyone thinks the openh264.org code
> is not BSD licensed, send me facts on why and we can make sure that
> it is.

Please see above a few pointers of the analysis. When people come (not 
from this mailing list, from the public) and look at the repository, 
they see a "BSD license" that they expect it's like any BSD license. 
Permits redistribution to begin with, under those two conditions. But 
*this* license is contradicted, and canceled in practice, from the 
perspective of the developer, by another license, which isn't explicit 
and not in the same place.

Perhaps part of the problem we have here is that these old licenses, 
like BSD, were drafted without patent grants. It's unfortunate today, 
but they're from a time, IIRC, when patents for software were not 
exploding, and were not used to obscure or *cancel in practice* their 
permission grants.

 > The MPEG-LA licenses allow people to to fork and build and run
 > things in small quantities. This allows developers to build products
 > and try things out without any trouble before they have to license
 > things. Setting small quantities at a hundred thousand seems pretty
 > generous to me. So I disagree that people that fork and build this
 > are automatically running afoul of the MPEG-LA.

I'd submit a suggestion for the openh264 project. Please add a license 
to the repository, which covers the terms Cisco really offers. Cisco, 
not MPEG-LA, of course (if I remember correctly though, Cisco is part of 
MPEG-LA licensors, I apologize in advance if my memory fools me). It 
could start, I'm not sure, perhaps like this:

"Redistributions in source or binary form are not permitted, unless in 
small quantities, and only on personal machines or for development 
purpose on github website.

Cisco does not hereby offers you any grant for the patents it owns, or 
will own in the future, regardless whether they are necessarily 
infringed by this implementation of H.264.

No contributors that own patents [...] offer any grant for the patents 
they own [that are infringed...]

Redistributions in source or binary, when compliant with above, must 
retain the above copyright notice, this list of conditions and the 
following disclaimer."

While very quickly and roughly written, is there anything incorrect in 
the above?

Please, correct it or simply consider its substance. My suggestion is 
intended to indicate the problem, it's not drafted properly. It's a 
simple matter of being accurate about the licensing requirements that 
apply in reality to the project.

-- 
~enyst

"Excuse me, Professor Lessig, but may I ask you to sign this CLA, so
that we have legally your permission to distribute your CC-licensed words?"

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Thu, 12 Dec 2013 23:25:38 +0100

On 12/12/13 22:32, Ron wrote:
[...]
> currently far from being a universally (or easily) Solved Problem.
At least there were several people concerned about trusting the blob 
version being built from the open sourced code. I, as one of them, got 
the answer that I can take the code and build it on my system and then 
compare the binaries (the answer was not from Cisco, saying it just to 
be sure is not inducing anyone in error). Upon a follow up that whether 
we should expect mobile devices to be shipped with compile tools and 
devel libs soon, the reply came that cross compilation should (can) be used.

Its going aside the topic of this mailing list, but as you, I would be 
also very interested to see a solution for fingerprinting the sources 
and then matching the binary outcome from third party build systems.

Back on topic, my concern was for custom/new applications using the 
blobs. Maybe Mozilla (+ other major browsers or large companies) and 
Cisco can get to a mechanism between them that Mozilla builds the blobs 
and uploads them to Cisco. Firefox on your device will take it from 
Cisco site and compare the fingerprints. I don't think will solve all 
the security concerns, but can shift the trust relation to Mozilla, as 
between the application and its mother company (i.e., if one doesn't 
trust Mozilla, it shouldn't use bare Firefox binary in the first place).

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

---

From: cowwoc <[email-masked]>
Date: Thu, 12 Dec 2013 17:25:39 -0500

openh264 is a patent troll's wet dream.

If I were a troll, I'd fork openh264, contribute some juicy code sniplet 
that enhances the codec, and wait for Cisco to integrate it into the 
official version. 3-6 months later, I'd sue everyone who uses it.

Note that "everyone who uses it" refers to the thousands of companies 
who are expected to compile the codec for themselves under the false 
impression that they are safe because they have under 100k deployments. 
Because Cisco makes no attempt to review the code for IPR, and many 
companies are expected to use it, it makes it a very attractive target 
for patent trolls. And good luck linking the contributor back to the 
troll. There are plenty ways of contributing code by proxy or 
anonymously to avoid detection.

I bring this up to point out that you cannot really treat the software 
license independently from IPR. The two go hand in hand. If you're going 
to accept contributions from the public, you're going to have to review 
it for IPR, and good luck going down that road...

Gili

On 12/12/2013 4:55 PM, Roman Shpount wrote:
>
> On Thu, Dec 12, 2013 at 4:43 PM, Ron <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> binary and if there is a place where the person suing me could 
> announce that this binary violates their IPR rights, but failed to do 
> so, I can use it in my defense that they never tried to informed me 
> and this is form of entrapment. IANAL, but from experience this helps.
>

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 12 Dec 2013 22:34:15 +0000

>for disclosure under the IETF requirements.[1]

According to my reading of the IETF IPR policy documents there is no such
obligation.

Stephan

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 12 Dec 2013 23:34:44 +0100

> 2. To VP8-detractors: would such a binary change your mind about

Would this be different from <https://tools.google.com/dlpage/webmmf>?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Roach <[email-masked]>
Date: Thu, 12 Dec 2013 17:01:30 -0600

On 12/12/13 16:25, Daniel-Constantin Mierla wrote:
> if one doesn't trust Mozilla, it shouldn't use bare Firefox binary in 
> the first place

And if one doesn't trust Cisco, one shouldn't use the Internet.

As I've pointed out before, if Cisco is targeting you, you're pretty 
much hosed.

/a

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 09:41:01 +1030

> According to my reading of the IETF IPR policy documents there is no such

Which part of:

   IPR disclosures under Sections 6.1.1. and 6.1.2 are required with
   respect to IPR that is owned directly or indirectly, by the
   individual or his/her employer or sponsor (if any) or that such
   persons otherwise have the right to license or assert.

would you say indicates there is no such obligation?

I won't discount that there may be some slippery reading of the requirements
which people acting in bad faith may be able to ooze between, but if that
were actually the case, then that would be a compelling reason to completely
exclude this technology from consideration at all.

Where is the wide open door that permits them not to disclose which I am
missing here?  It's not like anyone could plausibly be unaware of which
companies are major holders of IPR relevant to H.264, and I'm pretty certain
there are messages posted to this list where people directly confirm their
company is one.

Large amounts of it were declared (with whatever questionable merit) as
applying to VP8.  Are you saying the people who declared that are unaware
that H.264 is also being proposed for use here?

  Ron

---

From: Justin Uberti <[email-masked]>
Date: Thu, 12 Dec 2013 15:27:13 -0800

Right. We have previously provided plugins for IE and Safari for WebM
playback in <video/>.

For WebRTC usages, we'd also need to include an encoder (the existing
plugin is just the decoder), but obviously we'd be very happy to do so if
these other browsers wanted to provide VP8 support in that manner.

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Fri, 13 Dec 2013 00:39:03 +0100

> As I've pointed out before, if Cisco is targeting you, you're pretty 

Are these intended to be some subtle jokes? Or maybe you can give more 
specific details. If you refer to core infrastructure, I dealt with many 
ISPs that had no Cisco footprint around. Internet might be beyond of 
only what some people saw or they believe it is.

Daniel

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 10:14:30 +1030

On Thu, Dec 12, 2013 at 11:25:38PM +0100, Daniel-Constantin Mierla wrote:
> version being built from the open sourced code. I, as one of them,
> got the answer that I can take the code and build it on my system
> and then compare the binaries

That's the bit that actually makes this Hard and Interesting.

If you take the code, and build it on your own system, then it's far
more likely than not that the binaries *will* be different.  Even if
you really did compile exactly the same source code.

Which is why I'm curious if this is a misunderstanding, and Cullen
described how he hoped or thought it would work (but how it probably
almost certainly won't) -- or if they actually are planning to solve
the problems which would make this (somewhat) possible to do.

And I had actually forgotten how unintuitive this problem might be
to people who use regularly software they don't have the source to
until you mentioned being told that :)

  Ron

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Dec 2013 00:30:32 +0000

If Ron can justify such a statement, the he is also in defiance of the IETF IPR rules, because he himself is required to make a disclosure. The requirement is to disclose if you know of..., not if you own.

But I believe Stefan is correct. Neither IETF or its contributors has not written a document specifying the H.264 codec as an essential part of its operation, therefore making a disclosure is not required. If IETF progresses to making a statement that incorporation of an H.264 implementation forms an essential part of a webrtc specification, then disclosure in IETF will be required.

ISO/IEC JTC1 does have a specification for H.264, and I am led to believe disclosures of IPR have been made there. Noone involved in this discussion as far as I am aware is hiding H.264 IPR. Again I believe as a third party, you are also allowed to make IPR disclosures there (certainly every other SDO I know of allows third party disclosures).

And before this degenerates into a discussion of what people want the IETF IPR rules to become rather than what they are, take that to the IETF discussion list.

Regards

Keith Drage

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of 
> Stephan Wenger
> Sent: 12 December 2013 22:34
> To: Ron; [email-masked]
> Subject: Re: [rtcweb] Cisco to open source its H.264 
> implementation and absorb MPEG-LA licensing fees
> 
> 
> 
> >> I think it would be beneficial to have a place on openh264 
> site where 
> >>the  site owners (Cisco) would specifically ask any third party to 
> >>disclose  their IPR claims against this implementation.
> >
> >in this WG and which hold H.264 patents to comply with their 
> >obligations for disclosure under the IETF requirements.[1]
> 
> According to my reading of the IETF IPR policy documents 
> there is no such obligation.
> 
> Stephan
> 
> 
> >

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 Dec 2013 17:58:55 -0700

> the problems which would make this (somewhat) possible to do.

The thing that is hard is making a compile match an existing binary when you don't really know how the original binary was compiled. The plan here is to exactly describe the process that Cisco uses to compile (which linux distro, which version, which compiler version etc, all the build scripts etc). Then any external group, such as Mozilla, can replicate theses instructions and get the same binary. I do realize that if you build the same code on even very similar systems, you may get a different binary. I realize it is not trivial to get this to all happen but we are confident it can be done.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 Dec 2013 17:59:05 -0700

On Dec 12, 2013, at 4:01 PM, Adam Roach <[email-masked]> wrote:

>> if one doesn't trust Mozilla, it shouldn't use bare Firefox binary in the first place
> 
> As I've pointed out before, if Cisco is targeting you, you're pretty much hosed.
> 
> /a
 
I was going to say if one did't trust Mozilla, it was pretty unlikely you were going to trust the internet. Heck if you don't trust gcc, I don't know  how you get on the internet.

---

From: Jack Moffitt <[email-masked]>
Date: Thu, 12 Dec 2013 18:12:03 -0700

> The thing that is hard is making a compile match an existing binary when you don't really know how the original binary was compiled. The plan here is to exactly describe the process that Cisco uses…

This sounds very fragile. Why not just create a public EC2 image that
can build the code, and then everyone will have the same setup and it
will be easy to replicate. Or even better, just a standard chef or
puppet script that uses a well known stock public EC2 AMI.

jack.

---

From: Engel Nyst <[email-masked]>
Date: Fri, 13 Dec 2013 03:34:00 +0200

> outside the MPEG-LA", but their FAQ does clearly state You're Own Your Own

I think I understand that is the problem you are concerned about, 
however it's not the problem I'm concerned about, primarily. (partly 
because I don't know details)

I'm concerned about MPEG-LA and Cisco, who know their own claims, do 
*not* license them, and the github repository presented to the world 
says "License: BSD. See included LICENSE file". The passing by reader 
sees "redistributions are permitted [..]".

> deny that BSD licenced source code is indeed "open source".

Right. In addition, BSD is a free license. I think we agree, only look 
at another part of the context here. I consider the difference between 
BSD licensing and patent licensing in *this* particular project so 
disconnected, so contradictory in *basic* permissions (nothing 
disputable or edge case), by a mild reading even, that I say, in this 
case, that it's not licensed under the terms it says it's licensed.

I agree it isn't the most fortunate short formulation of my concerns. 
However, I'm not sure there's a substantial difference with saying that 
"it's BSD 'indeed' but it's not licensed for redistribution unless in 
trackable small amounts or something like it".

I would love to agree that patent grants are different than the 
copyright grants, or even better, to see patents don't interfere with 
software. Unfortunately, again, this case is so strikingly different 
than the natural expectation from a BSD project, starting from the 
distribution of the *unmodified* binary.

The licensors under "BSD" do *not permit* it to begin with.

For a large, careful, project like Debian, I trust they'll check both 
BSD and additional terms. I administrate Debian machines, and I find it 
difficult to believe I will see *this* "BSD-licensed source code" enter 
Debian main. It's not even distributable by Debian, as far as I can 
tell. I'll wait and see.

I'm concerned about smaller projects and people out there. They see a 
simple, clear, explicit BSD license. They read it's BSD and they read 
it's "Open Source" and it "follows Open Source Definition". It does not, 
as you showed below.

There have been many discussions on whether BSD has an implicit patent 
grant or not, or whether one can reasonably argue in court that it has. 
Since "redistributions and use are permitted...", people will expect 
that redistributions and use are permitted, and may be able to argue in 
court that their redistribution and use are not infringing claims at 
least *from the licensors* under BSD.

I think it's the natural reading people have from BSD, because that's 
what the text says. But in this case, I don't see how can one argue that 
either (IMHO, IANAL) because /elsewhere/ than the repository, 
*licensors* contradict it, from the very beginning of the openh264 project.

If anything, this high profile project from Cisco may influence the 
reading of BSD out there. And Open Source, and Open Source Definition.

I don't think that influence, if I'm unfortunately right and it will 
exist, will be positive for software freedom.

The initiative from Cisco to license part of the claims and provide 
source is commendable as it is, I have no doubt on that; but only in up 
to 20 years it will be in-line with BSD permissions grant at face value, 
Open Source, and following Open Source Definition, and Debian Free 
Software Guidelines. It will probably be a good idea to include a patent 
grant for all licensors then too.

-- 
~enyst

"Excuse me, Professor Lessig, but may I ask you to sign this CLA, so 
that we have legally your permission to distribute your CC-licensed words?"
   ~ Permission Culture, take two.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 13 Dec 2013 02:32:16 +0000

I think you mean open source in general, not openh264 specifically. The same can be done with VP8, Linux, or any widely used project. So should we 10-finger every contributor and demand a license to every thought they ever had or will have? Contributions to the openh264 project will certainly be thoroughly reviewed, not just by Cisco, but hopefully a much larger community. But it is unreasonable to expect reviewers to sniff out potential IPR trojans. It is also unreasonable to demand review of the contributors rather than their contributions. Open source projects would grind to a halt if they succumb to such FUD.

Mo

On 12/12/13, 5:25 PM, cowwoc <[email-masked]<mailto:[email-masked]>> wrote:

If I were a troll, I'd fork openh264, contribute some juicy code sniplet that enhances the codec, and wait for Cisco to integrate it into the official version. 3-6 months later, I'd sue everyone who uses it.

Note that "everyone who uses it" refers to the thousands of companies who are expected to compile the codec for themselves under the false impression that they are safe because they have under 100k deployments. Because Cisco makes no attempt to review the code for IPR, and many companies are expected to use it, it makes it a very attractive target for patent trolls. And good luck linking the contributor back to the troll. There are plenty ways of contributing code by proxy or anonymously to avoid detection.

I bring this up to point out that you cannot really treat the software license independently from IPR. The two go hand in hand. If you're going to accept contributions from the public, you're going to have to review it for IPR, and good luck going down that road...

Gili

On Thu, Dec 12, 2013 at 4:43 PM, Ron <[email-masked]<mailto:[email-masked]>> wrote:

If I am getting sued by somebody for IPR violation due to use of Cisco binary and if there is a place where the person suing me could announce that this binary violates their IPR rights, but failed to do so, I can use it in my defense that they never tried to informed me and this is form of entrapment. IANAL, but from experience this helps.

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 13:13:34 +1030

On Fri, Dec 13, 2013 at 12:30:32AM +0000, DRAGE, Keith (Keith) wrote:
> If Ron can justify such a statement, the he is also in defiance of the IETF
> IPR rules, because he himself is required to make a disclosure. The
> requirement is to disclose if you know of..., not if you own.

Maybe you should actually go read the Note Well RFCs before you engage in
"No U" argumentation that just makes it look like you haven't.

If I owned, or worked for or on behalf of anyone who owned IPR that was
relevant to the work here, I indeed would have disclosed it according to
the obligations noted there.

Since I don't, and I don't actually know specific details of which patents
might apply here (beyond reading of assertions there is a pool, and of
court cases that are being pursued over them, and that many of the people
pushing hard for the adoption of H.264 are holders of them) - I am indeed
discharging the only obligation upon me that I SHOULD point and wave.

> But I believe Stefan is correct. Neither IETF or its contributors has not
> written a document specifying the H.264 codec as an essential part of its
> operation, therefore making a disclosure is not required. If IETF progresses
> to making a statement that incorporation of an H.264 implementation forms an
> essential part of a webrtc specification, then disclosure in IETF will be
> required.

 "Covers or may ultimately Cover a Contribution"

I believe is the language used.

 "unless ... rejected from consideration before a disclosure could reasonably
  be submitted."

And I'm pretty sure we're well past the time of "could reasonably", unless
your position is that we should now immediately reject it from consideration?

> ISO/IEC JTC1 does have a specification for H.264, and I am led to believe
> disclosures of IPR have been made there. Noone involved in this discussion as
> far as I am aware is hiding H.264 IPR. Again I believe as a third party, you
> are also allowed to make IPR disclosures there (certainly every other SDO I
> know of allows third party disclosures).
> 
> And before this degenerates into a discussion of what people want the IETF
> IPR rules to become rather than what they are, take that to the IETF
> discussion list.

 "Contributors must disclose IPR meeting the description in this section;
  there are no exceptions to this rule."

Nobody is arguing for a change to the rules here.  It's the blatant
disregard for them (or perhaps you are trying to subtly demonstrate
that it's simply ignorance of them) which is what concerns me at the
present time.

I'd prefer to just see this remedied by the people who the obligation
falls upon than to make an example of them before the wider IETF.
If it goes that far I would assume it will be with a call for sanctions.

Stephan may still be correct that there is some sneaky back door that
people can hide behind here - but if there is one, all that you've
proved in these statements is that you don't know what it is either.

  Ron

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 12:39:00 +1030

> The thing that is hard is making a compile match an existing binary when you
> don't really know how the original binary was compiled. The plan here is to
> exactly describe the process that Cisco uses to compile (which linux distro,
> which version, which compiler version etc, all the build scripts etc).

It turns out there are quite a few surprising reasons that it's still Hard
even when you do (think you) know how the original was built.

This source might be easier than some, since it (hopefully!) has relatively
few external dependencies, but the list of things which need to be exactly
reproduced is a lot longer and needs to be much more precise than just
"Debian 7.1, gcc 4.8" or so.

There's some pretty good detail on the trials and tribulations of this here:

https://blog.torproject.org/category/tags/deterministic-builds

So it probably would be good if people who are going to work on this get
together with the various other groups that are (I know both Debian and
Fedora also have groups exploring this), since there's plenty to solve
to make it actually happen, even without everyone trying to reinvent that
wheel separately.

But it is good to hear this is a conscious part of the plan.

  Cheers,
  Ron

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 12 Dec 2013 21:59:50 -0500

> puppet script that uses a well known stock public EC2 AMI.

I know it might sound like a lot of work, but this idea actually makes a
lot of sense and goes a long way toward resolving any ambiguities and
will make the reproduceability of the binaries all the more easier to
confirm.  And it will basically take away almost any claim the Cisco or
other parties are trying to be insidious with their binary offer.

The chef/puppet script idea is actully really swell because it will show
the exact system configuration used to produce the build.

This might add more work than planned for Cisco, but it definitely will
pay off in the long run.  These could even be community-developed, as
long as Cisco made it clear which ones they used.

For example, for Fedora, there's already a very healthy community for
self-building packages, so this openness would be embraced readily by
many such users in Fedora as well as the greater "Enterprise Linux"
community (e.g., RHEL, CentOS, Scientific Linux, etc.).  Most likely,
members from this community would contribute their experience in
preparing these configuration scripts and Cisco can kickstart their
building for that platform.

-- 
Libre Video
http://librevideo.org

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Dec 2013 03:03:12 +0000

Well lets turn the question around then.

Which document contains the requirement that makes H.264 an essential part of its content, such that you would make an IPR declaration against it?

6.4.  What Must be in a Disclosure?

6.4.1.  The disclosure must list the numbers of any issued patents or
   published patent applications or indicate that the claim is based on
   unpublished patent applications.  The disclosure must also list the
   specific IETF or RFC Editor Document(s) or activity affected.  If the
   IETF Document is an Internet-Draft, it must be referenced by specific
   version number.  In addition, if the IETF Document includes multiple
   parts and it is not reasonably apparent which part of such IETF
   Document is alleged to be Covered by the IPR in question, it is
   helpful if the discloser identifies the sections of the IETF Document
   that are alleged to be so Covered.

And if you think this applies to H.264, where is the related VP8 disclosure, which following your reasoning, is also required?

Keith

> From: rtcweb [mailto:[email-masked]] On Behalf Of Ron
> Sent: 13 December 2013 02:44
> To: [email-masked]
> Subject: [rtcweb] H.264 IPR disclosures (or persistent lack thereof)
> 
> > If Ron can justify such a statement, the he is also in 
> defiance of the 
> > IETF IPR rules, because he himself is required to make a 
> disclosure. 
> > The requirement is to disclose if you know of..., not if you own.
> 
> Maybe you should actually go read the Note Well RFCs before 
> you engage in "No U" argumentation that just makes it look 
> like you haven't.
> 
> If I owned, or worked for or on behalf of anyone who owned 
> IPR that was relevant to the work here, I indeed would have 
> disclosed it according to the obligations noted there.
> 
> Since I don't, and I don't actually know specific details of 
> which patents might apply here (beyond reading of assertions 
> there is a pool, and of court cases that are being pursued 
> over them, and that many of the people pushing hard for the 
> adoption of H.264 are holders of them) - I am indeed 
> > But I believe Stefan is correct. Neither IETF or its 
> contributors has 
> > not written a document specifying the H.264 codec as an 
> essential part 
> > of its operation, therefore making a disclosure is not required. If 
> > IETF progresses to making a statement that incorporation of 
> an H.264 
> > implementation forms an essential part of a webrtc 
> specification, then 
> > disclosure in IETF will be required.
> 
> And I'm pretty sure we're well past the time of "could 
> reasonably", unless your position is that we should now 
> immediately reject it from consideration?
> 
> 
> > ISO/IEC JTC1 does have a specification for H.264, and I am led to 
> > believe disclosures of IPR have been made there. Noone involved in 
> > this discussion as far as I am aware is hiding H.264 IPR. Again I 
> > believe as a third party, you are also allowed to make IPR 
> disclosures 
> > there (certainly every other SDO I know of allows third 
> party disclosures).
> > 
> > And before this degenerates into a discussion of what 
> people want the 
> > IETF IPR rules to become rather than what they are, take 
> that to the 
> > IETF discussion list.
> 
> Nobody is arguing for a change to the rules here.  It's the 
> blatant disregard for them (or perhaps you are trying to 
> subtly demonstrate that it's simply ignorance of them) which 
> is what concerns me at the present time.
> 
> I'd prefer to just see this remedied by the people who the 
> obligation falls upon than to make an example of them before 
> the wider IETF.
> Stephan may still be correct that there is some sneaky back 
> door that people can hide behind here - but if there is one, 
> all that you've proved in these statements is that you don't 
> know what it is either.
> 
>   Ron
> 
>

---

From: Engel Nyst <[email-masked]>
Date: Fri, 13 Dec 2013 05:09:17 +0200

On 12/13/2013 04:32 AM, Mo Zanaty (mzanaty) wrote:
> I think you mean open source in general, not openh264 specifically.
> The same can be done with VP8, Linux, or any widely used project. So
> should we 10-finger every contributor and demand a license to every
> thought they ever had or will have? Contributions to the openh264
> project will certainly be thoroughly reviewed, not just by Cisco, but
> hopefully a much larger community. But it is unreasonable to expect
> reviewers to sniff out potential IPR trojans. It is also unreasonable
> to demand review of the contributors rather than their contributions.
> Open source projects would grind to a halt if they succumb to such
> FUD.

Please note for VP8, the overall license includes a patent grant, both 
for currently owned patents and those acquired in the future.

In general, newer Open Source licenses or updated licenses, include a 
patent grant, from any licensor/contributor.

In particular, from (large) projects using older licenses, I don't 
remember any project that intently withholds patents /AND/ actively uses 
them to require a separate license.

This widespread practical fact shapes the understanding of those 
licenses in the community, and it is used to argue by some that in those 
older licenses (BSD, GPLv2), patent grants are implied.

I don't know if they're implied or not, and I am not a lawyer.

I just think there is a significant difference between ignoring patents 
completely, in the license and in the project in general, which gives 
users a potential defense in good faith; and withholding patents, with 
the intention to require a separate deal, while using a license that 
reads the same way as the license of all the many projects who never do.

> On 12/12/13, 5:25 PM, cowwoc
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> If I were a troll, I'd fork openh264, contribute some juicy code
> sniplet that enhances the codec, and wait for Cisco to integrate it
> into the official version. 3-6 months later, I'd sue everyone who
> uses it.
>
> impression that they are safe because they have under 100k
> deployments. Because Cisco makes no attempt to review the code for
> IPR, and many companies are expected to use it, it makes it a very
> attractive target for patent trolls. And good luck linking the
> contributor back to the troll. There are plenty ways of contributing
> code by proxy or anonymously to avoid detection.
>
> I bring this up to point out that you cannot really treat the
> software license independently from IPR. The two go hand in hand. If
> you're going to accept contributions from the public, you're going to
> have to review it for IPR, and good luck going down that road...
>
> Gili
>
> On Thu, Dec 12, 2013 at 4:43 PM, Ron
> <[email-masked]<mailto:[email-masked]>> wrote: On Thu, Dec 12, 2013
> at 03:04:31PM -0500, Roman Shpount wrote:
>> I think it would be beneficial to have a place on openh264 site
>> where the site owners (Cisco) would specifically ask any third
>> party to disclose their IPR claims against this implementation.
>
> We so far can't even get the organisations who have active
> contributors in this WG and which hold H.264 patents to comply with
> their obligations for disclosure under the IETF requirements.[1]
>
> If I am getting sued by somebody for IPR violation due to use of
> Cisco binary and if there is a place where the person suing me could
> At least active WG contributors are not suing me yet. _____________
> Roman Shpount
>
>
>
>
>
> _______________________________________________ rtcweb mailing list
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

-- 
~enyst

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 13 Dec 2013 03:33:00 +0000

Yes, Cisco and Mozilla plan on solving fully reproducible binaries for all
targets officially supported in the openh264 project. Nothing less would
be acceptable to the community, especially given the recent security
incidents.

We welcome contributions from anyone who has struggled with this in the
past, and is aware of specific problems or solutions beyond the obvious
ones below.

1. Identical source trees (git hash)
2. Identical project configuration (make targets that include all
configuration options)
3. Identical tool chains on similar build machines (same arch at least,
probably x86-64)
4. Deterministic tool chains (avoid tool options that lack determinism)
5. Deterministically identical tool chain output must be hashed separately
from uniquely generated data (build info, etc.)

Some feel that tool chains can also be subverted and therefore should also
be built from source, using some root golden tool chain. We are not that
paranoid yet. Should we be?

Mo

On 12/12/13, 4:32 PM, Ron <[email-masked]> wrote:
...
There is considerable work presently being done on fully reproducible
binaries, since obviously this is of interest on many fronts, but it's
currently far from being a universally (or easily) Solved Problem.

Is Cisco actually planning to invest work into solving this (for all
architectures!) as part of this project?
...

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 14:03:44 +1030

On Fri, Dec 13, 2013 at 03:03:12AM +0000, DRAGE, Keith (Keith) wrote:
> Which document contains the requirement that makes H.264 an essential part of
> its content, such that you would make an IPR declaration against it?

Including but not limited to ?:
http://lmgtfy.com/?q=webrtc+draft+h264

> And if you think this applies to H.264, where is the related VP8 disclosure,
> which following your reasoning, is also required?

 However, the requirement for an IPR disclosure is satisfied by a blanket
 statement of the IPR discloser's willingness to license all of its potential
 IPR meeting the requirements of Section 6.6 (and either Section 6.1.1 or
 6.1.2) to implementers of an IETF specification on a royalty-free basis ...

Which is not to say at all that I'm arguing there shouldn't also be further
disclosures there too if you can point to something that says the above
doesn't already cover it.

Does that answer your questions, or are we going to do "Mom! He hit me!!"
next?

  Ron

---

From: Ron <[email-masked]>
Date: Fri, 13 Dec 2013 14:33:16 +1030

> be acceptable to the community, especially given the recent security

If nothing else but this comes out of this initiative, then I would have
to say it still would be a great success :)  I'm very glad to hear this.

It's not a case of "I don't trust Cisco" so much "I shouldn't have to".

If this raises the bar for others distributing pre-compiled binaries,
that would be an awesome outcome all on its own.

> from uniquely generated data (build info, etc.)

The tor people would definitely be worth talking to here for first hand
information on what's solved and what still needs serious work.  They
have people working on this full time at present.

The link I posted in the other mail has some details, but I'm sure they'll
have plenty more to say if asked :)

> paranoid yet. Should we be?

Ken Thompson thought we should in 1995!

There is work being done on that too though, which not so much is about
providing a "golden tool chain" as a method of confirming that the one
you have is not corrupted.

But that's probably more of a job for the OS Vendors to do (and for the
real paranoids to confirm that they've done).  There's some information
on that here:

http://www.dwheeler.com/trusting-trust/
https://www.schneier.com/blog/archives/2006/01/countering_trus.html

Getting the openh264 builds reproducible to begin with is probably the
best initial investment, since that will identify the compiler(s) used,
and people can use the above technique to confirm that compiler is clean.

At least for the compilers that you can build yourself from source.

  Ron

---

From: Gili <[email-masked]>
Date: Thu, 12 Dec 2013 23:28:58 -0500

Mo,

The entire point of openh264 is to reduce IPR risk surrounding the use 
of H.264. That is not the point of open-source software in general. So 
for openh264 *specifically* it makes no sense to argue that it reduces 
IPR risk and at the same time allow contributions without reviewing them 
for IPR risk.

Gili

On 12/12/2013 9:32 PM, Mo Zanaty (mzanaty) wrote:
> Open source projects would grind to a halt if they succumb to such FUD.
>
> Mo
>
>
> into the official version. 3-6 months later, I'd sue everyone who uses it.
>
> license independently from IPR. The two go hand in hand. If you're 
> going to accept contributions from the public, you're going to have to 
> review it for IPR, and good luck going down that road...
>
> Gili
>
>>     where the
>>     contributors
>>     obligations
>> [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 13 Dec 2013 05:40:43 +0000

The confusion here is that the VP8 bitstream is defined in IETF (RFC 6386). So there are IETF IPR declarations on that (from Google and Nokia). The H.264 bitstream is defined in ISO/IEC/ITU but not IETF. So there are ISO/IEC/ITU IPR declarations on that (from many, not just MPEG-LA licensors), but there are no IETF IPR declarations since there is no IETF bitstream spec, just protocol specs that wrap or use the bitstream in opaque ways but don’t define it in any way. You can see the ISO/IEC/ITU IPR declarations here:

http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm

(The AVC standard is called H.264 in ITU and MPEG-4 Part 10 or 14496-10 in ISO/IEC.)

Note that IPR declarations are just that, a declaration, not verified in any way by any SDO as being a valid claim necessary to implement a standard.

Mo

On 12/12/13, 10:33 PM, Ron <[email-masked]<mailto:[email-masked]>> wrote:

  Ron

> To: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: SM <[email-masked]>
Date: Thu, 12 Dec 2013 21:52:58 -0800

Hi Mo,
At 21:40 12-12-2013, Mo Zanaty (mzanaty) wrote:
>The confusion here is that the VP8 bitstream is defined in IETF (RFC 
>6386). So there are

That RFC is not an IETF document [1].

Regards,
-sm

1. http://www.rfc-editor.org/info/rfc6386

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 13 Dec 2013 06:31:57 +0000

Contributions to the openh264 project will certainly be thoroughly reviewed, just like contributions to the webm/vp8 project. But neither project can reasonably claim to reliably detect and reject any IPR trojans. Any such claim would be patently dishonest. :)

On 12/12/13, 11:28 PM, Gili <[email-masked]<mailto:[email-masked]>> wrote:

Mo,

The entire point of openh264 is to reduce IPR risk surrounding the use of H.264. That is not the point of open-source software in general. So for openh264 *specifically* it makes no sense to argue that it reduces IPR risk and at the same time allow contributions without reviewing them for IPR risk.

Gili

Mo

Gili

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 13 Dec 2013 07:07:48 +0000

Yes, I¹m aware of that nuance, strike IETF and just say RFC 6386. There
are nuances on the AVC side as well. It is technically not developed by
MPEG nor ITU, but rather a joint team of video experts (JVT) that still
gets published as ISO/IEC/ITU documents. None of those nuances seem
particularly relevant here. Unless you mean there should really be no IETF
IPR disclosures for VP8 since RFC 6386 is an RFC editor contribution
rather than an IETF contribution. That would be technically true, but I
don¹t think Google or Nokia are breaking IETF process by filing the IPR
declarations, they are just not necessarily compelled to do so under the
current policy.

On 12/13/13, 12:52 AM, SM <[email-masked]> wrote:

Hi Mo,

Regards,
-sm

---

From: <[email-masked]>
Date: Fri, 13 Dec 2013 07:48:56 +0000

Hi,

My and Nokia's interpretation has been that since neither of H.264 nor VP8 are IETF specifications, there is no obligation for anyone to disclose IPR on them in the IETF, even if there may be IETF specifications that refer to them. For H.264 all Nokia's IPR is publicly declared in ISO/IEC/ITU. For VP8 Nokia decided voluntarily to do the declaration to make it open and clear what the Nokia position on that is.

Markus

From: rtcweb [mailto:[email-masked]] On Behalf Of ext Mo Zanaty (mzanaty)
Sent: 13 December, 2013 07:41
To: Ron; [email-masked]
Subject: Re: [rtcweb] H.264 IPR disclosures (or persistent lack thereof)

The confusion here is that the VP8 bitstream is defined in IETF (RFC 6386). So there are IETF IPR declarations on that (from Google and Nokia). The H.264 bitstream is defined in ISO/IEC/ITU but not IETF. So there are ISO/IEC/ITU IPR declarations on that (from many, not just MPEG-LA licensors), but there are no IETF IPR declarations since there is no IETF bitstream spec, just protocol specs that wrap or use the bitstream in opaque ways but don't define it in any way. You can see the ISO/IEC/ITU IPR declarations here:

Mo

  Ron

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Dec 2013 13:26:48 +0000

If you are following that interpretation of the rules, there are equivalent VP8 documents against which declarations need to be made. The Google and Nokia disclosures against RFC 6386 do not meet your interpretation of the IPR rules, because they have not been declared against the specific IETF work area (normally but not necessarily identified by an RFC or internet draft). Indeed they have not been declared against any IETF work at all.

Like Stefan, I do not believe these documents force a disclosure. 

But if you want to challenge that, then the appeal route is defined.

And as I say, I believe noone has hidden anything anywhere. There has been plenty of mail on this list and in other documents that tell you where to find the IPR disclosures in other organisations, most of which have a more formal legal status than IETF.

Regards

Keith

> Sent: 13 December 2013 03:34
> To: [email-masked]
> > Which document contains the requirement that makes H.264 an 
> essential 
> > part of its content, such that you would make an IPR 
> declaration against it?
> 
> > And if you think this applies to H.264, where is the related VP8 
> > disclosure, which following your reasoning, is also required?
> 
>  However, the requirement for an IPR disclosure is satisfied 
> by a blanket  statement of the IPR discloser's willingness to 
> license all of its potential  IPR meeting the requirements of 
> Section 6.6 (and either Section 6.1.1 or
> Which is not to say at all that I'm arguing there shouldn't 
> also be further disclosures there too if you can point to 
> something that says the above doesn't already cover it.
> 
> > > Maybe you should actually go read the Note Well RFCs before you 
> > > engage in "No U" argumentation that just makes it look like you 
> > > haven't.
> > > 
> > > If I owned, or worked for or on behalf of anyone who 
> owned IPR that 
> > > was relevant to the work here, I indeed would have disclosed it 
> > > according to the obligations noted there.
> > > 
> > > Since I don't, and I don't actually know specific details 
> of which 
> > > patents might apply here (beyond reading of assertions there is a 
> > > pool, and of court cases that are being pursued over 
> them, and that 
> > > many of the people pushing hard for the adoption of H.264 are 
> > > holders of them) - I am indeed discharging the only 
> obligation upon 
> > > me that I SHOULD point and wave.
> > > 
> > > > of its operation, therefore making a disclosure is not 
> required. 
> > > > If IETF progresses to making a statement that incorporation of
> > > an H.264
> > >  "unless ... rejected from consideration before a 
> disclosure could 
> > > reasonably
> > >   be submitted."
> > > 
> reasonably", 
> > > unless your position is that we should now immediately reject it 
> > > from consideration?
> > > 
> > > 
> > > obligation falls upon than to make an example of them before the 
> > > wider IETF.
> > > Stephan may still be correct that there is some sneaky back door 
> > > that people can hide behind here - but if there is one, all that 
> > > you've proved in these statements is that you don't know 
> what it is 
> > > either.
> > > 
> > >   Ron
> > > 
> > >

---

From: Ron <[email-masked]>
Date: Sat, 14 Dec 2013 20:58:55 +1030

Hi Markus,

On Fri, Dec 13, 2013 at 07:48:56AM +0000, [email-masked] wrote:
> Hi,
> 
> My and Nokia's interpretation has been that since neither of H.264 nor VP8
> are IETF specifications, there is no obligation for anyone to disclose IPR on
> them in the IETF, even if there may be IETF specifications that refer to
> them. For H.264 all Nokia's IPR is publicly declared in ISO/IEC/ITU. For VP8
> Nokia decided voluntarily to do the declaration to make it open and clear
> what the Nokia position on that is.

Do you have a reference to something that is the basis of that interpretation?

I may well be missing something here, but I'm not seeing any exception that
could be interpreted in that way.

If we were making this an optional extra technology we can interop with,
then I could sort of see how this might be considered out of scope for the
IETF to be responsible for, but the drafts submitted wrt to H.264 are all
proposing to make it mandatory for WebRTC.  Which means the IETF would be
effectively coopting this as a standard, since anyone implementing WebRTC
MUST implement it.  That would mean that it _is_ on the IETF standard track,
(albeit by some back door) and as far as I can see, means it falls foul of
at least 2 requirements at the present time:

 9.  Change Control for Technologies

   The IETF must have change control over the technology described in
   any standards track IETF Documents in order to fix problems that may
   be discovered or to produce other derivative works.

(which indeed may not be a problem specific to H.264, but let's not get
too sidetracked by this one at this stage, since this or some other WG
could fix that fairly easily by publishing an RFC if necessary - but we
may indeed need to fix that before all is said and done)

And the requirements of section 6, which I won't quote again except to
note once more that the applicable clause has a "no excuses" requirement

 "Contributors must disclose IPR meeting the description in this
   section; there are no exceptions to this rule."

Which since you are listed as one of the Authors of (at least?) one
of the H.264 proposal drafts, would seem to explicitly disallow the
interpretation you suggest.

draft-burman-rtcweb-h264-proposal even makes no reference whatsoever to
the out of pool IPR held by Nokia (and others?), and seems to imply that
the MPEG-LA subset is all that would need to be licenced.  This would
seem to fall well short of even the bare minimum of due diligence
disclosure to the working group.

Since making this mandatory _would_ expose all implementors of this
IETF standard to the IPR in question, I really can't see how "oh that's
been declared somewhere else already" is an acceptable way to meet the
IETF's requirements.  That would completely defeat the purpose of having
these declarations be a mandatory part of defining IETF standards.

If they are already declared somewhere else then that indeed should make
it easier to make the necessary declarations here, but I don't see what
might absolve the people with such an obligation from still making them?

This seems like information that in the absence of, we can't possibly
even consider H.264 to be a serious contender for acceptance by the
IETF as an integral and essential part of one of its standards.

So afaics, either somebody needs to point out what I'm missing here
(with something more definitive than "my opinion is"), the people with
obligations to disclose need to do so, or we need to simply remove H.264
from any further consideration as MTI.

Thanks to those who responded actually taking this question seriously
though, it shouldn't be hard to resolve one way or the other.

  Cheers,
  Ron

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 14 Dec 2013 12:20:49 +0100

Just FYI (for all the group, actually), I remember we had a F2F discussion in Atlanta about IPR in the IETF. Specifically, Scott Bradner gave a presentation during the RTCWEB session. You can find the recordings here:

http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF85_RTCWEB_SESSION_I&chapter=part_3

Hopefully it will help clarify what is actually supposed to happen.

Lorenzo

On Sat, 14 Dec 2013 20:58:55 +1030

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Ron <[email-masked]>
Date: Sat, 14 Dec 2013 23:55:20 +1030

On Sat, Dec 14, 2013 at 12:20:49PM +0100, Lorenzo Miniero wrote:
> Just FYI (for all the group, actually), I remember we had a F2F discussion in
> Atlanta about IPR in the IETF. Specifically, Scott Bradner gave a
> presentation during the RTCWEB session. You can find the recordings here:
> 

So unfortunately, that session ran out of time and ended right at the
instant before the distinction I see here was actually addressed. :/

In my comment about "optional extra technology" I was thinking precisely
of things like RTP payload definitions.  Those aren't mandating that you
use a particular technology, just saying "if you want to, this is how you
should signal that within this IETF protocol".

And if that's all we were doing with H.264 here, then I'd view it in a
similar light.

But the draft proposals aren't doing that, they are saying we should
mandate it.  Which effectively makes the relevant WebRTC RFC(s) a
perfect superset of the H.264 standard, and would make H.264 itself an
IETF standard that is an essential and mandatory part of what we hope
to publish.  Which afaics means all the usual IETF requirements would
be directly applicable to it.

And just on a side note, the other interesting thing in that discussion
was the importance and necessity for disclosures to "point to the part
of the specification that is affected" -- the total lack of which seems
to be the hallmark of, shall we call them "deliberately disruptive"
disclosures, that are sometimes seen.

At least in the context of VP8, that, combined with the facts that nobody
has since made any change to VP8, or any user of it has stopped using it,
or anyone at all has pointed at some section of its code and said "OMG,
that really is doing what's described in this prohibitive disclosure",
and that courts are throwing out the cases put before them, and the
European regulators are warning against further Troll-like Behaviour,
make it very hard to take those disclosures seriously, or to consider
them as being a genuine blocker for its adoption.

So if people want to clarify that too while they're busy making the
necessary H.264 disclosures, that would be really helpful for those
of us who are still trying to winnow the actual facts from the FUD
and arrive at an actually considered position to present to the Chairs :)

  Thanks!
  Ron

---

From: cowwoc <[email-masked]>
Date: Sat, 14 Dec 2013 10:38:49 -0500

+1

By total coincidence, I happen to be reading a book called "The 
Marketing Playback: Five Battle-Tested Plays for Capturing and Keeping 
the Lead in Any Market" and I note with amusement that they write the 
following about the "High-Low" Play:

High-Low Players are stubborn. They say, "No compromises. Down with 
mediocrity, up with choice." So what if it makes life more complicated? 
You deserve the right thing for you. *One of the key tools in the 
High-Low Player's bag **is FUD**. Sowing fear, uncertainty, and doubt as 
well as underscoring the risks of going with a middle ground are key 
ways to buy time.*

[Emphasis added]
Source: 
http://books.google.ca/books?id=cZAawCoJmrMC&lpg=PT130&ots=goUUaLHeDk&dq=The%20Marketing%20Playbook%20%2Bfud&pg=PT131#v=onepage&q=fud&f=false

Does this sound familiar to anyone?

  * Why choose a mediocre solution (VP8) when you could have a free
    (albeit highly restricted) H.264 codec on the low end, or a more
    powerful (royalty-encumbered) H.264 codec on the high end? (i.e.
    "Best of Both Worlds" vs High-Low options)
  * VP8 is unsafe. Just look at all this (hand waving) IPR problems.
    (i.e. fear, uncertainty, and doubt)

Let's recognize this play for what it is: a desperate attempt to buy 
time. We are all being played.

Gili

---

From: SM <[email-masked]>
Date: Sat, 14 Dec 2013 09:21:09 -0800

Hi Ron,

>at least 2 requirements at the present time:

[snip]

>disclosure to the working group.

draft-burman-rtcweb-h264-proposal-00 is not listed as a working group 
document.  I don't have a clear picture of the discussion about that 
draft.  As such it is difficult to form an opinion about how BCP 79 
applies.  I was puzzled by the lack of IPR disclosures on any of the 
working group documents given that there has been several threads on 
the WG mailing list about patents.

Regards,
-sm

---

From: [email-masked]
Date: Sat, 14 Dec 2013 11:27:30 -0800

+1 -

Anyone else notice the silence of VP8 detractors in response to Google's
offer to host a VP8 binary?

On Sat, Dec 14, 2013 at 7:38 AM, cowwoc <[email-masked]> wrote:

>  +1
>
> By total coincidence, I happen to be reading a book called "The Marketing
> Playback: Five Battle-Tested Plays for Capturing and Keeping the Lead in
> Any Market" and I note with amusement that they write the following about
> the "High-Low" Play:
>
> mediocrity, up with choice." So what if it makes life more complicated? You
> deserve the right thing for you. *One of the key tools in the High-Low
> Player's bag **is FUD**. Sowing fear, uncertainty, and doubt as well as
> underscoring the risks of going with a middle ground are key ways to buy
> time.*
>
> [Emphasis added]
> Source:
>    - Why choose a mediocre solution (VP8) when you could have a free
>    (albeit highly restricted) H.264 codec on the low end, or a more powerful
>    (royalty-encumbered) H.264 codec on the high end? (i.e. "Best of Both
>    Worlds" vs High-Low options)
>    - VP8 is unsafe. Just look at all this (hand waving) IPR problems.
> Let's recognize this play for what it is: a desperate attempt to buy time.
> We are all being played.
>
> Gili
> Ron <[email-masked]> <[email-masked]> wrote:
>
>
>  Hi Markus,
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Lorenzo Miniero, COB
>
> Meetecho s.r.l.
> Web Conferencing and Collaboration Toolshttp://www.meetecho.com
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Dec 2013 11:40:57 -0800

> offer to host a VP8 binary?

You mean aside from the original suggestion coming from Cullen in the
first place? It would be great if we could have this discussion without
people personally attacking others the way that seems to be happening
in this thread.

On the substantive question, while I think it would be great if Google
would host a VP8 binary, I don't think that that really addresses the
arguments against VP8-MTI in quite the same way that Cisco's offer
did for H.264-MTI.

While there certainly are people who have trouble with implementing
VP8, I take the primary argument for H.264 to be that it had a large
installed base (despite being encumbered) and the primary argument
against it being that it was encumbered and therefore hard for new
people to implement. The idea behind Cisco's offer is to reduce that
barrier for new entrants (whether you believe it is doing so is a
different question).

By contrast, the primary argument for VP8 is that it's free (despite
some people saying they couldn't implement it). So, if Google were
to make a plugin available, that would alleviate the concerns of people
that it really was encumbered, but it doesn't do anything for the
existing installed base.

-Ekr

>> Playback: Five Battle-Tested Plays for Capturing and Keeping the Lead in Any
>> Market" and I note with amusement that they write the following about the
>> "High-Low" Play:
>>
>> deserve the right thing for you. One of the key tools in the High-Low
>> Player's bag is FUD. Sowing fear, uncertainty, and doubt as well as
>> time.
>> Why choose a mediocre solution (VP8) when you could have a free (albeit
>> highly restricted) H.264 codec on the low end, or a more powerful
>> VP8 is unsafe. Just look at all this (hand waving) IPR problems. (i.e.
>> fear, uncertainty, and doubt)
>>

---

From: [email-masked]
Date: Sat, 14 Dec 2013 11:51:51 -0800

> people personally attacking others the way that seems to be happening

I don't believe that I made a personal attack. I was thinking of recent
straw poll responses citing IPR objections to VP8.  If the IPR objections
are made in "good faith", then we might expect enthusiastic reception of a
hosted vp8 binary since it specifically addresses those concerns.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Dec 2013 11:56:36 -0800

> hosted vp8 binary since it specifically addresses those concerns.

Suggesting that other people's objections are not made in "good faith"
sure seems like a personal attack to me.

-Ekr

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sun, 15 Dec 2013 07:00:56 +1100

> Let's recognize this play for what it is: a desperate attempt to buy time.

While I'm all for vp8, this argument is a far shot. I actually think that
the longer we wait, the easier it will be to pick vp8.

Did you notice that the only objection to choosing vp8 that returns in the
survey is the Nokia ipr statement? There is no mention any more of lack of
hw support? When Google makes the binary offer that Cisco made for h264,
that goes away. I wonder what objections will remain??

Time is actually on the side of royalty free in this case faict.

Silvia.

>>>> On Fri, Dec 13, 2013 at 07:48:56AM +0000, [email-masked]:
>>>>>
>>>>> Hi,
>>>>>

---

From: cowwoc <[email-masked]>
Date: Sat, 14 Dec 2013 16:16:26 -0500

On 14/12/2013 3:00 PM, Silvia Pfeiffer wrote:
> While I'm all for vp8, this argument is a far shot. I actually think 
> that the longer we wait, the easier it will be to pick vp8.
>
> Did you notice that the only objection to choosing vp8 that returns in 
> the survey is the Nokia ipr statement? There is no mention any more of 
> lack of hw support? When Google makes the binary offer that Cisco made 
> for h264, that goes away. I wonder what objections will remain??
>

I think there is a bit of a fallacy at play here. H.264's installed base 
in the context of WebRTC is exactly zero. Why? Because there is no 
meaningful encoder support on any platform.

H.264 needs to buy time in order to build that hardware encoder support. 
VP8's software codec adoption is a foot in the door, which is precisely 
why H.264 is trying to block it at the pass. If VP8 were to demonstrate 
strong demand by way of WebRTC, it would be far easier to get 
manufacturers to deploy VP8 in hardware.

IPR-issues aside, does anyone honestly think that we'd be better off 
with a video codec monopoly? I'd much rather see VP8 and H.264 compete 
on equal footing. I believe that one of Mozilla's primary goals for 
entering the mobile market was to create competition in that space, 
which is why I hope that they will push for competition in this space as 
well.

Gili

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Dec 2013 13:29:51 -0800

On Sat, Dec 14, 2013 at 1:16 PM, cowwoc <[email-masked]> wrote:
> I think there is a bit of a fallacy at play here. H.264's installed base in
> the context of WebRTC is exactly zero. Why? Because there is no meaningful
> encoder support on any platform.

"Installed base" here also means the very large number of
existing devices which speak SIP and which have H.264-only.

With that said, there are also a large number of devices with
built-in H.264 encoders.

> IPR-issues aside, does anyone honestly think that we'd be better off with a
> video codec monopoly? I'd much rather see VP8 and H.264 compete on equal
> footing. I believe that one of Mozilla's primary goals for entering the
> mobile market was to create competition in that space, which is why I hope
> that they will push for competition in this space as well.

I'm not sure what you think "Mozilla" should do other than what it's doing,
which is to support both codecs.

-Ekr

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Sat, 14 Dec 2013 23:50:25 +0000

My issue is around interop with existing systems (hence also all the SDP stuff baked into RTCWeb)

Hosted binaries make no difference for me

Jeremy Laurenson

On Dec 14, 2013, at 2:27 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

+1 -

Anyone else notice the silence of VP8 detractors in response to Google's offer to host a VP8 binary?

On Sat, Dec 14, 2013 at 7:38 AM, cowwoc <[email-masked]<mailto:[email-masked]>> wrote:
+1

By total coincidence, I happen to be reading a book called "The Marketing Playback: Five Battle-Tested Plays for Capturing and Keeping the Lead in Any Market" and I note with amusement that they write the following about the "High-Low" Play:

High-Low Players are stubborn. They say, "No compromises. Down with mediocrity, up with choice." So what if it makes life more complicated? You deserve the right thing for you. One of the key tools in the High-Low Player's bag is FUD. Sowing fear, uncertainty, and doubt as well as underscoring the risks of going with a middle ground are key ways to buy time.

[Emphasis added]
Source: http://books.google.ca/books?id=cZAawCoJmrMC&lpg=PT130&ots=goUUaLHeDk&dq=The%20Marketing%20Playbook%20%2Bfud&pg=PT131#v=onepage&q=fud&f=false

  *   Why choose a mediocre solution (VP8) when you could have a free (albeit highly restricted) H.264 codec on the low end, or a more powerful (royalty-encumbered) H.264 codec on the high end? (i.e. "Best of Both Worlds" vs High-Low options)
  *   VP8 is unsafe. Just look at all this (hand waving) IPR problems. (i.e. fear, uncertainty, and doubt)

Let's recognize this play for what it is: a desperate attempt to buy time. We are all being played.

Gili

  Thanks!
  Ron

On Sat, 14 Dec 2013 20:58:55 +1030
Ron <[email-masked]><mailto:[email-masked]> wrote:

Hi Markus,

On Fri, Dec 13, 2013 at 07:48:56AM +0000, [email-masked]<mailto:[email-masked]> wrote:

Hi,

  Cheers,
  Ron

--
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Sat, 14 Dec 2013 22:01:41 -0500

> which is to support both codecs.

Ekr,

> existing devices which speak SIP and which have H.264-only.

as a fact?  I'm particularly interested in the "very large number" part
more than the H.264-only part.  How many SIP devices are really out
there that have any a passing interest or chance at being an interop
target for rtcweb?

The reason I ask is because amongst the most pressing strengths of H.264
as MTI for rtcweb is interop, but interop is not a primary goal of
rtcweb.  Introducing the burden of H.264 into the spec for new devices,
technologies, and methods should not be a factor if the true relevance
is minimal or, in fact, small enough to be considered non-existent.

-- 
Libre Video
http://librevideo.org

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Dec 2013 20:59:22 -0800

Basil Mohamed Gohar <[email-masked]> wrote:
>      but interop is not a primary goal of
>rtcweb.  

Oh???

d/

-- 
Dave Crocker
bbiw.net

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 15 Dec 2013 06:03:35 +0000

As that statement has never been put to a decision, you cannot say it is a goal, or is not a goal. 

It is just plain not determined.

Keith

> Basil Mohamed Gohar
> Sent: 15 December 2013 03:02
> To: [email-masked]
> Subject: Re: [rtcweb] H.264's high-low play (Was: H.264 IPR 
> disclosures (or persistent lack thereof))
> 
> >>> Did you notice that the only objection to choosing vp8 
> that returns 
> >>> in the survey is the Nokia ipr statement? There is no mention any 
> >>> more of lack of hw support? When Google makes the binary 
> offer that 
> >>> Cisco made for h264, that goes away. I wonder what 
> objections will remain??
> >>>
> >> I think there is a bit of a fallacy at play here. H.264's 
> installed 
> >> base in the context of WebRTC is exactly zero. Why? 
> Because there is 
> >> no meaningful encoder support on any platform.
> > 
> > "Installed base" here also means the very large number of existing 
> > devices which speak SIP and which have H.264-only.
> > 
> > With that said, there are also a large number of devices 
> with built-in 
> > H.264 encoders.
> > 
> > 
> >> with a video codec monopoly? I'd much rather see VP8 and H.264 
> >> compete on equal footing. I believe that one of Mozilla's primary 
> >> goals for entering the mobile market was to create competition in 
> >> that space, which is why I hope that they will push for 
> competition in this space as well.
> > 
> > I'm not sure what you think "Mozilla" should do other than 
> what it's 
> > doing, which is to support both codecs.
> > 
> > -Ekr
> 
> Ekr,
> 
> > "Installed base" here also means the very large number of existing 
> > devices which speak SIP and which have H.264-only.
> 
> as a fact?  I'm particularly interested in the "very large 
> number" part more than the H.264-only part.  How many SIP 
> devices are really out there that have any a passing interest 
> or chance at being an interop target for rtcweb?
> 
> The reason I ask is because amongst the most pressing 
> strengths of H.264 as MTI for rtcweb is interop, but interop 
> is not a primary goal of rtcweb.  Introducing the burden of 
> H.264 into the spec for new devices, technologies, and 
> methods should not be a factor if the true relevance is 
> minimal or, in fact, small enough to be considered non-existent.
> 
> --
> Libre Video
> http://librevideo.org

---

From: Ron <[email-masked]>
Date: Sun, 15 Dec 2013 18:27:57 +1030

On Sat, Dec 14, 2013 at 11:40:57AM -0800, Eric Rescorla wrote:
> first place?

My understanding is there has already _been one_ for a very long time now.
Possibly even since before there was a WebRTC WG, certainly since before
Cisco offered to host one for H.264.

It might need some tweaking to suit everyone here, but I'm fairly sure
that if this is the only sticking point that work would get done.

> some people saying they couldn't implement it).

I don't remember seeing too many arguments that listed technical reasons
why they _couldn't_.  Only why they said they _wouldn't_ or didn't want
to.  And all of those arguments were basically "oh noes, teh unknown IPR"
(and which realistically I think actually boil down to, in every case,
"we own IPR for H.264, we don't own any for VP8" - which isn't much of a
safety net for the majority of people who don't own H.264 IPR).

Which if we agree is transferred to someone else if you download a binary
from them, can be mitigated for VP8 at least as well as for H.264.  (and
if we don't agree on that, then Cisco's offer doesn't help either).

In fact it's still mitigated _better_ for VP8, since Google is giving you
a "free licence" to *all* of the known applicable IPR, along with a strong
defensive reciprocity guarantee - while the Cisco offer is _only_ licencing
you the MPEG-LA pool, which leaves you no licence at all to the other known
IPR that exists outside of that pool, and no promise from even MPEG-LA that
you are in any way safe for having a licence from them.

> So, if Google were to make a plugin available, that would alleviate the
> concerns of people that it really was encumbered, but it doesn't do
> anything for the existing installed base.

The existing installed base for WebRTC is pretty much exclusively VP8
at present.  So no, it won't do anything for them at all :)  They already
have it.

For people yet to implement WebRTC, that don't already have VP8 available,
they probably also don't already have Opus available either.  If linking
to libvpx (or a downloaded plugin of it) and linking to libopus, presents
a total showstopper technical difficulty to them, then I don't hold out
much hope for the quality, or delivery, or a WebRTC implementation from
them at all.  This is surely the most trivial part of anything that they
will need to do.

We already established that almost every platform with "hardware H.264"
would need to reimplement it in software for this anyway.  I don't see
how this poses any significant extra difficulty to do for VP8 instead
(or as well should they choose).

The notable thing to my mind, is that the people who considered VP8 as
the only viable option when this was a two horse race, have almost
universally attempted to compromise on some other option that also met
the needs and fears of the people who said the IPR situation surrounding
it was untenable for them.  I can't think of (m)any people from the
H.264 or bust camp that have engaged with that to satisfy the concerns
expressed about it.  Presently they're still arguing that they don't
even need to disclose to the IETF at all ...

If people are going to talk of Solomonic solutions, then if Solomon was
a chair, I suspect he'd know who cared more about this baby's welfare :>

  Ron

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Sun, 15 Dec 2013 16:33:04 -0500

>>      but interop is not a primary goal of

My error of omission was pointed-out off-list.  I meant *legacy*
interop.  Of course, we'd want full interop between full implementations
of rtcweb. :)

-- 
Libre Video
http://librevideo.org

---

From: Roman Shpount <[email-masked]>
Date: Sun, 15 Dec 2013 18:12:31 -0500

> It is just plain not determined.
Considering that WebRTC decided not to support plain RTP, SDES-SRTP, G.722
or any other wide band codecs except Opus, I would think the fact the
interop is not a goal was already determined for audio. Either one of those
things have higher impact on interop then H.264 supprot. As far as video is
concerned, I would argue that even though there are a few devices that
support H.264, there are practically no interconnected video systems and
for most video devices interop was not a priority.
_____________
Roman Shpount

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 16 Dec 2013 00:50:30 +0000

I'm not sure exactly where you are trying to take this discussion.

If you are implying that the IPR for either of the two codec specifications is unknown, then we MUST stop any decision making process until it is known, because the WG is bound to take that status into account in making its decision.

But I believe the chairs have stated in prior meetings that the IPR is known, and noone has contradicted that on the list or in the meeting, and where to find it has been reiterated time and time again, in the meeting, on mailing lists and in documents.

And you yourself do not seem to be pointing at any IPR coverage that you know of that has not been publically identified.

The only doubts I have heard about absence of IPR disclosure is specifically against the VP8 codec, with the contention that as the specification has only recently been submitted to ISO, many ISO participants may still be evaluating their patent portfolio against it.

Of course if you really do want an IETF IPR disclosure under way, then submit a draft that makes both codecs mandatory and asks for it to be a WG item. The codec declarations will have to be made against that document. But do you really believe that will produce any surprise declarations.

That draft WG document at the moment does not exist.

Regards

Keith

> Sent: 14 December 2013 13:25
> To: [email-masked]
> > Just FYI (for all the group, actually), I remember we had a F2F 
> > discussion in Atlanta about IPR in the IETF. Specifically, Scott 
> > Bradner gave a presentation during the RTCWEB session. You 
> can find the recordings here:
> > 
> > 
> So unfortunately, that session ran out of time and ended 
> right at the instant before the distinction I see here was 
> actually addressed. :/
> 
> In my comment about "optional extra technology" I was 
> thinking precisely of things like RTP payload definitions.  
> Those aren't mandating that you use a particular technology, 
> just saying "if you want to, this is how you should signal 
> that within this IETF protocol".
> 
> And if that's all we were doing with H.264 here, then I'd 
> view it in a similar light.
> 
> But the draft proposals aren't doing that, they are saying we 
> should mandate it.  Which effectively makes the relevant 
> WebRTC RFC(s) a perfect superset of the H.264 standard, and 
> would make H.264 itself an IETF standard that is an essential 
> and mandatory part of what we hope to publish.  Which afaics 
> means all the usual IETF requirements would be directly 
> applicable to it.
> 
> 
> And just on a side note, the other interesting thing in that 
> discussion was the importance and necessity for disclosures 
> to "point to the part of the specification that is affected" 
> -- the total lack of which seems to be the hallmark of, shall 
> we call them "deliberately disruptive"
> At least in the context of VP8, that, combined with the facts 
> that nobody has since made any change to VP8, or any user of 
> it has stopped using it, or anyone at all has pointed at some 
> section of its code and said "OMG, that really is doing 
> what's described in this prohibitive disclosure", and that 
> courts are throwing out the cases put before them, and the 
> European regulators are warning against further Troll-like 
> Behaviour, make it very hard to take those disclosures 
> seriously, or to consider them as being a genuine blocker for 
> its adoption.
> 
> So if people want to clarify that too while they're busy 
> making the necessary H.264 disclosures, that would be really 
> helpful for those of us who are still trying to winnow the 
> actual facts from the FUD and arrive at an actually 
> considered position to present to the Chairs :)
> 
>   Thanks!
>   Ron
> 
> 
> > > > My and Nokia's interpretation has been that since 
> neither of H.264 
> > > > nor VP8 are IETF specifications, there is no obligation 
> for anyone 
> > > > to disclose IPR on them in the IETF, even if there may be IETF 
> > > > specifications that refer to them. For H.264 all Nokia's IPR is 
> > > > publicly declared in ISO/IEC/ITU. For VP8 Nokia decided 
> > > > voluntarily to do the declaration to make it open and 
> clear what the Nokia position on that is.
> > > 
> > > I may well be missing something here, but I'm not seeing any 
> > > exception that could be interpreted in that way.
> > > 
> > > If we were making this an optional extra technology we 
> can interop 
> > > with, then I could sort of see how this might be 
> considered out of 
> > > scope for the IETF to be responsible for, but the drafts 
> submitted 
> > > wrt to H.264 are all proposing to make it mandatory for WebRTC.  
> > > Which means the IETF would be effectively coopting this as a 
> > > standard, since anyone implementing WebRTC MUST implement 
> it.  That 
> > > would mean that it _is_ on the IETF standard track, 
> (albeit by some 
> > > back door) and as far as I can see, means it falls foul 
> of at least 2 requirements at the present time:
> > > 
> > > 
> > > (which indeed may not be a problem specific to H.264, but 
> let's not 
> > > get too sidetracked by this one at this stage, since this or some 
> > > other WG could fix that fairly easily by publishing an RFC if 
> > > necessary - but we may indeed need to fix that before all is said 
> > > and done)
> > > 
> > > 
> > > And the requirements of section 6, which I won't quote 
> again except 
> > > to note once more that the applicable clause has a "no excuses" 
> > > requirement
> > > 
> > > draft-burman-rtcweb-h264-proposal even makes no reference 
> whatsoever 
> > > to the out of pool IPR held by Nokia (and others?), and seems to 
> > > imply that the MPEG-LA subset is all that would need to 
> be licenced.  
> > > This would seem to fall well short of even the bare 
> minimum of due 
> > > diligence disclosure to the working group.
> > > 
> > > 
> > > IETF standard to the IPR in question, I really can't see how "oh 
> > > that's been declared somewhere else already" is an 
> acceptable way to 
> > > meet the IETF's requirements.  That would completely defeat the 
> > > purpose of having these declarations be a mandatory part 
> of defining IETF standards.
> > > 
> > > If they are already declared somewhere else then that 
> indeed should 
> > > make it easier to make the necessary declarations here, 
> but I don't 
> > > see what might absolve the people with such an obligation 
> from still making them?
> > > 
> > > 
> > > This seems like information that in the absence of, we can't 
> > > possibly even consider H.264 to be a serious contender for 
> > > acceptance by the IETF as an integral and essential part 
> of one of its standards.
> > > 
> > > (with something more definitive than "my opinion is"), the people 
> > > with obligations to disclose need to do so, or we need to simply 
> > > remove H.264 from any further consideration as MTI.
> > > 
> > > 
> > > Thanks to those who responded actually taking this question 
> > > seriously though, it shouldn't be hard to resolve one way 
> or the other.
> > > 
> > >   Cheers,
> > >   Ron
> > > 
> > > 
> > Web Conferencing and Collaboration Tools http://www.meetecho.com

---

From: cowwoc <[email-masked]>
Date: Sun, 15 Dec 2013 20:18:48 -0500

+1

If the H.264 crowd was as willing to compromise on some other option 
then we could reach a solution that would be satisfactory to all 
parties. I still hope that we can reach such a compromise.

Gili

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Dec 2013 17:25:29 -0800

I'm sure I'm going to regret asking this, but what compromise do you think
either side has offered?

-Ekr

On Sun, Dec 15, 2013 at 5:18 PM, cowwoc <[email-masked]> wrote:
> +1
>
> If the H.264 crowd was as willing to compromise on some other option then we
> could reach a solution that would be satisfactory to all parties. I still
> hope that we can reach such a compromise.
>
> Gili
>
>

---

From: Adam Roach <[email-masked]>
Date: Sun, 15 Dec 2013 19:46:34 -0600

On 12/14/13 13:51, [email-masked] wrote:
> If the IPR objections are made in "good faith", then we might expect 
> enthusiastic reception of a hosted vp8 binary since it specifically 
> addresses those concerns.

Watch out: that logic cuts both ways. Some people who had IPR-related 
objections to H.264 gave Cisco's offer a warm reception; others did not. 
Are you also leveling an accusation of bad faith at the latter party?

/a

---

From: cowwoc <[email-masked]>
Date: Sun, 15 Dec 2013 22:38:04 -0500

I've seen multiple VP8 proponents rate the following options as Acceptable:

 1. H.261 as MTI
 2. Theora as MTI
 3. Implement two of [H.261, H.264, VP8] as MTI

They might not love the option but they are willing to accept it as a 
compromise. On the flip side, I've seen multiple H.264 backers rate 
"H.264 s MTI" as "Yes" and all other options as "No". They did not 
include a single option as "Acceptable".

It doesn't really matter who responded this way. What *is* important is 
that we can only reach a mutually acceptable compromise if the majority 
rate multiple options as "Acceptable". Anyone who is only willing to 
accept a single option pretty much guarantees that they will find 
themselves disappointed.

I mean... negotiation and compromise, by definition, imply that you are 
not going to get 100% of what you're asking for. The sooner people 
internalize that, the sooner we can move on.

Gili

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Dec 2013 20:04:43 -0800

On Sun, Dec 15, 2013 at 7:38 PM, cowwoc <[email-masked]> wrote:
> H.261 as MTI
> Theora as MTI
> Implement two of [H.261, H.264, VP8] as MTI
>
> compromise. On the flip side, I've seen multiple H.264 backers rate "H.264 s
> MTI" as "Yes" and all other options as "No". They did not include a single
> option as "Acceptable".

You might try taking a closer look at the survey results. I'm not a mind-reader
so I don't know what an "H.264 backer" is, but the following people voted
positively for H.264 and negatively for VP8. I've listed their votes below
(accreting Yes and Acceptable, since the difference doesn't seem relevant
here):

Stefan Hakkansson   (264, None, 2/3 [VP8, H263, H.264], 263)
Bernard Aboba (264 only)
Sal Loreto (264, None, 263 only)

Perhaps I missed some, since I just went by responses to the thread, but this
seems sufficient to demonstrate that your characterization of the data isn't
accurate.

-Ekr

---

From: cowwoc <[email-masked]>
Date: Mon, 16 Dec 2013 00:35:37 -0500

> seems sufficient to demonstrate that your characterization of the data isn't
On second thought, I think you're right.

Based on the limited number of straw poll votes cast so far, people 
objected to codecs for one of two reasons:

  * IPR concerns
  * Video quality

VP8 proponents objected to H.264 (and H.263) for IPR reasons, and H.264 
proponents objected to VP8 for IPR reasons.
Some people objected to the use of older codecs for video quality 
reasons (if I remember correctly, VP8 proponents were more willing to 
accept a lower-quality codec than H.264 proponents)
Both objections (IPR and video quality) are quite reasonable.
(I don't view "None" as a compromise. Anyone voting for this is not 
giving anything up. They are saying "I'll do what I want, and you do 
what you want" and they do so at the cost of interoperability.)

At the end of the day, I don't think there is a "right answer" for 
everyone because one business might trade legal risk for high-quality 
video, while another will prefer to trade video quality for reduced 
legal risk. This is a subjective decision which is best left up to the 
business. At the same time, I think the interoperability requirement 
should outweigh this.

Consider what will happen if we end up with "No MTI". Some devices will 
support VP8, others will support H.264. Do people realize that sticking 
a transcoder in the middle exposes you to the exact same IPR risks that 
they are complaining about? I mean, H.264 folks will be force to 
implement VP8 in the transcoder, and VP8 folks will be forced to 
implement H.264 in the transcoder. Doesn't this open you up to the same 
IPR risk as "Both H.264 and VP8 are MTI"?

Gili

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Dec 2013 21:50:12 -0800

> On second thought, I think you're right.

At the risk of pressing the point, this seems like it would be a good
time for you to explicitly retract your comments about the motives of
H.264 proponents.

> IPR concerns
> Video quality

Well, as I've said a number of times, there are people who are
in favor of H.264 because they care about interop with non-WebRTC
H.264 devices. I realize that that's not yet appeared in the
survey results, but it was in JDR's presentation at IETF and
we've only seen a very small number of results.

> Consider what will happen if we end up with "No MTI". Some devices
> will support VP8, others will support H.264. Do people realize that
> sticking a transcoder in the middle exposes you to the exact same IPR
> risks that they are complaining about? I mean, H.264 folks will be
> force to implement VP8 in the transcoder, and VP8 folks will be forced
> to implement H.264 in the transcoder. Doesn't this open you up to the
> same IPR risk as "Both H.264 and VP8 are MTI"?

No, because "you" is different people.

To take a simple example, consider the case of a browser which
implements VP8-only. Clearly, the browser has no H.264 IPR risk, at
the cost of not being able to talk to people who do H.264. However, If
someone else (say a conferencing system) decides to build a system
with a VP8-H.264 transcoder, then *they* are the person incurring the
IPR risk. That's really not the same thing at all.

I'm certainly not suggesting that no-MTI is a good thing, but it
isn't the same as MTI-X from the perspective of IPR exposure.

-Ekr

---

From: cowwoc <[email-masked]>
Date: Mon, 16 Dec 2013 01:30:36 -0500

> time for you to explicitly retract your comments about the motives of

The only thing that changed is that I have a better appreciation for why 
some H.264 proponents cannot accept older codecs such as H.261 or 
Theora. I'm still bothered by the fact that none of them extended a 
olive branch to people who objected to IPR-encumbered codecs. I find it 
hard to believe that none of their use-cases would be adequately served 
by these codecs. That being said, let's wait for more straw poll results 
to come in.

> isn't the same as MTI-X from the perspective of IPR exposure.

Fair enough. So we're pushing out the IPR risk to companies who author 
transcoding bridges. This is certainly acceptable for some businesses, 
but it's worth noting that other business models would be wiped out by 
the need for transcoding.

This is why I favor the "Must implement two of [VP8, H.264, older 
codec]" option. Companies who need high-end video can fallback on 
transcoders. Companies who want to avoid IPR issues can fallback on 
older codecs. I like this option best because it displeases everyone 
equally. Everyone is compromising on something they want but getting 
something in return. And again, we are only talking about the fallback 
scenario. If the peers are compatible, there is no need for transcoding 
or older codecs.

Gili

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 16 Dec 2013 09:51:22 +0100

> That draft WG document at the moment does not exist.
Keith, it is completely unclear to me why such a draft would cause more
disclosures to come forth, given that we have one draft proposing
declaring H.264 CBP mandatory that caused no IPR disclosures, and
another draft proposing declaring VP8 mandatory that, again, caused no
IPR disclosures.

It's not lack of drafts that causes the lack of disclosures, as far as I
can tell.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 16 Dec 2013 10:05:30 +0100

> It is just plain not determined.
Keith, I take it you mean "interop with non-WebRTC equipment" here - the
combination of top-quoting and long thread quotes makes it a little
uncertain what exactly you're referring to.

The group's charter has the following list of work items:

The WG will perform the following work:

    1.  Define the communication model in detail, including how session
        management is to occur within the model.

    2.  Define a security model that describes the security and privacy
        goals and specifies the security protocol mechanisms necessary
        to achieve those goals.

    3.  Define the solution - protocols and API requirements - for
        firewall and NAT traversal.

    4.  Define which media functions and extensions shall be supported in
        the client and their usage for real-time media, including media
        adaptation to ensure congestion safe usage.

    5.  Define what functionalities in the solution, such as media codecs,
        security algorithms, etc., can be extended and how the
        extensibility mechanisms works.

    6.  Define a set of media formats that must or should be supported by
        a client to improve interoperability.

    7.  Define how non media data is transported between clients in a
        secure and congestion safe way.

    8.  Provide W3C input for the APIs that comes from the communication
        model and the selected components and protocols that are part of
        the solution.

    9.  The group will consider options for interworking with legacy VoIP
        equipment.

Note that point 6 is about WebRTC talking to WebRTC, and is "Define",
while point 9 is about talking to the "installed base", and is "consider".

This text has been the same since May 2011.

I'd say that it has definitely been put to a decision: The IESG approved
this charter. And the language was NOT accidental at the time.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 16 Dec 2013 11:45:16 +0100

On 12/12/2013 10:38 PM, Kaiduan Xie wrote:
> +1
>
> I have been wondering can Google distribute VP8 binary module with 
> similar approach as CISCO's H264 binary module support for a while.
>

As Justin said - we're certainly willing to help people adopt VP8 in any 
way that makes a difference, as long as the stuff we have to provide is 
in reasonable proportion to the difference it makes.

What we need to know can only be answered by the people who have IPR 
concerns about VP8:

 >>>> Will it make a difference to them? <<<<

If they say it makes a difference big enough to turn "won't support VP8" 
into "will support VP8", I think we'll do the maximum we can to be helpful.

If they say "it doesn't matter, we don't want to support VP8 anyway", 
it's unlikely that we'll make the investment and incur the maintenance 
cost for such a solution.

Anyone who isn't concerned by the present IPR situation can just 
download the sources now, compile, run, and distribute the VP8 encoder 
and decoder as much as they like. Technically, that's the simplest way 
and the way that's most flexible for those implementations that can use it.

>
> /Kaiduan
>
>
> On Thu, Dec 12, 2013 at 3:02 PM, cowwoc <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     The Cisco messaging has been very clear about this. Obviously no
>>     one can know about patents they don't know about and Cisco is not
>>     distributing a binary module that they don't legally have the
>>     right to distribute. Think about someone else, who if the first
>>     person who gets sued if some new IRP comes up on H.264. It won't
>>     people Mozilla who are distributing Firefox with no H.264 code in
>>     it, it is more likely to be Cisco who is distributing the binary
>>     download that contains the H.264 code. Google taking a similar
>>     approach with a VP8 binary module might help alleviate some of
>>     the concerns about IPR on VP8.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 16 Dec 2013 12:09:22 +0100

* Harald Alvestrand wrote:
>> Of course if you really do want an IETF IPR disclosure under way, then 
>> submit a draft that makes both codecs mandatory and asks for it to be a 
>> WG item. The codec declarations will have to be made against that 
>> document. But do you really believe that will produce any surprise 
>> declarations.
>>

It looks to me as though the expectation is that once a document is made
an official Working Group draft then others than those contributing the
draft have to make disclosures, and since as far as I can tell the draft
to make VP8 mandatory is not an official Working Group draft, making it
one would then cause more disclosures to come forth, as you put it. That
expectation might not be justified but the interpretation of the comment
above seemed straightforward.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 16 Dec 2013 14:43:48 +0100

> above seemed straightforward.
This may be an expectation that some people have, but it has no 
grounding whatsoever in the IETF IPR disclosure rules, where the gating 
factor is that it has been "contributed", and that others "realize" that 
the IPR they know about applies to the contribution.

RFC 3979 section 6.2.1 is pretty explicit. Nowhere in the document is 
the concept of "working group draft" mentioned.

It's been pointed out any number of times that this is what the rules say.

I won't dictate anyone's actions - there are plenty of reasons (some 
good, some bad) that people might conclude that the right action for 
them is to act in ways that are not in accordance with the rules - but 
the rules say what they say - and that does NOT mention "working group 
draft adoption"; the rules apply to ANYTHING that is contributed.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 16 Dec 2013 16:12:57 +0100

Since this is a subthread with technical content, I'd like it to have 
its own header....

the name I've heard for this kind of generation environments is 
"hermetic build".
Google's been trying for hermetic builds for NaCL for instance - see 
this doc:
http://www.chromium.org/nativeclient/design-documents/building-a-hermetic-toolchain-on-cygwin

> paranoid yet. Should we be?

There's more fun, including:

- Sources that timestamp the compilation output (wrecks hashes)
- Sources that #include stuff from system locations (break hermeticness)

In order to get the same version of the toolchain, one pretty much has to
either distribute it with the sources or build it from source - the latter
has the same issues one level down, so distributing the toolchain may
be the simpler option.

The bootable image of the build environment may be the simplest way....

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 16 Dec 2013 17:55:00 +0100

>http://www.chromium.org/nativeclient/design-documents/building-a-hermetic-toolchain-on-cygwin

That seems to be a different concept, specifically

  Definition: the Native Client toolchain is said to be hermetic iff
  it can be copied to any location in the directory tree and it does
  not require system-wide installation of other 3-rd party tools.

which is more like http://en.wikipedia.org/wiki/XCOPY_deployment

  XCOPY deployment or xcopy installation is a software application's
  installation into a Microsoft Windows system simply by copying files.

Goals of these include being able to have multiple independent versions
of an application installed on a single system e.g. for testing purposes
and being able to put an application on a USB drive and run it from
there without any need to install or uninstall the software.

The goal of "reproducible binaries" is verification.

As an example, a binary might contain absolute paths to where the debug
symbol files have been generated during compilation. This path would be
specific to the build environment and would make the binaries less "re-
producible". But there is no real runtime dependency on such paths, so
it does not interfere with "XCOPY deployment".

>The bootable image of the build environment may be the simplest way....

The idea is to avoid trusting binary blobs, so one binary blob producing
another binary blob is not really interesting. Of course, explaining how
to create an equivalent bootable image (install Debian vX.Y with default
options, apt-get build tools, wget source code, untar, configure, make)
can avoid many problems.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: John Leslie <[email-masked]>
Date: Mon, 16 Dec 2013 12:08:20 -0500

cowwoc <[email-masked]> wrote:
> 
> [a bunch of stuff better not repeated...]
> 
> older codecs...

   The straw-poll results so far indicate we're headed for No-MTI. :^(

   (For the record, this is Acceptable to me.)

   No-MTI means we wait for the market to sort things out, and
hopefully add a single MTI once things are sorted out (if any of us
live that long).

   In the meantime, there will surely be H.264 islands and VP8 islands.

   Very importantly, there will arise transcoding services to bridge
between them. I am hopeful (but not optimistic) that these transcoding
services can add "only" 60 milliseconds of delay. That will be good
enough for many uses.

   BTW, I'm certain these transcoding services will arise -- I only
fear that they will instead add 100-200 milliseconds of delay, which
is NOT good enough for real-time conferencing.

   Fortunately, there will also be browsers that support both codecs;
and those will likely be the winners in the market -- though it will
be interesting to see what happens when they get sued for IPR issues...

   BTW, this is why I intend to support SHOULDs for both H.264 and VP8
if we fail to agree on something as MTI.

   This "two of [VP8, H.264, older codec]" appears to be the viable
compromise: it gives us usable-if-unattractive video with a minimum
of dependencies which might otherwise scuttle actual deployment. If
we actually must wait for transcoding services to arise, deployment
might take entirely too long.

   So I ask -- what is driving the No votes on [... older codec]?

   If it is "I don't want to look at unattractive video," what can
we do to assure you that you won't have to?

   If it is "I don't want to spend any time implementing it," are you
truly on the critical path to deployment of WebRTC?

   If it is something else, can you at least _tell_ us why?

   Unless we can make progress on this sort of question, I fear we
will have to declare defeat on the MTI question shortly after the
straw poll closes.

> If the peers are compatible, there is no need for transcoding or
> older codecs.

   (Please don't forget that so long as _one_ endpoint supports both
H.264 and VP8, the peers _are_ compatible. This can work to make
either "two of" or no-MTI acceptable.)

--
John Leslie <[email-masked]>

---

From: Ron <[email-masked]>
Date: Tue, 17 Dec 2013 04:32:08 +1030

On Mon, Dec 16, 2013 at 05:55:00PM +0100, Bjoern Hoehrmann wrote:
> symbol files have been generated during compilation.

That actually raises another interesting point, being whether the people
proposing these blobs have thought about also providing debug symbols for
them, since the lack of that would certainly make problems harder to
diagnose.

It is possible these days to strip those into a separate image from the
runtime library.

> options, apt-get build tools, wget source code, untar, configure, make)

It actually requires much more than that, since any given Debian X.Y is
not definitive about what versions of which packages you may end up with.
Debian potentially has security updates several times a day, so if a
dependency is affected by one of those, you could build a binary that will
not be perfectly reproducible just a few hours later on "the same" X.Y
release of the distro.

There are several options around that, one being http://snapshot.debian.org/
but really you need to document the precise version of everything in the
loop.

And then there were other fun things the tor people found, like locale
being significant for some builds.

I agree that "here's a binary build environment image" doesn't really solve
the problem though -- that just means the paranoid people we're relying on
to be our canaries here need to solve the even bigger problem of figuring
out how to exactly reproduce it first.  As with the question of toolchain
verification, that's probably something we should leave to the OS vendors,
with the paranoids directly keeping them in check -- since there's probably
already plenty to do here just properly specifying the environment needed
for one relatively simple lib.

Ideally this will all eventually be automated, and people can run build
farms independently, that continually verify all the software all the time.
Which is a big part of the reason I'd like to see the people working on
this all get together to build common tools and infrastructure for it.

  Ron

---

From: cowwoc <[email-masked]>
Date: Mon, 16 Dec 2013 13:02:19 -0500

> either "two of" or no-MTI acceptable.)

Correct. My point is that the MTI discussion only impacts the case where 
the peers are *not* compatible.

I bring this up because some people are rejecting [older codec] for its 
quality/bandwidth ratio. I am trying to point out that:

  * We're only talking about a subset of peers that are not compatible
    with each other.
  * Of that subset, a further subset of the use-cases require multiple
    high-quality videos using low bandwidth.
      o Most people need one high-quality speaker and many small
        "talking heads".
      o Almost no one does this over a mobile connection (even when VP8
        and H.264 are available).
  * Networks and codecs are getting faster every day. Legal barriers are
    going away at a much slower rate.

We are in a much better position to improve the user experience if 
problems are technical in nature (network, codec speed) versus legal in 
nature. For that reason, I'd much rather err on the side of older codecs 
than IPR-encumbered ones.

If someone manages to convince MPEG-LA to become more transparent then I 
might revisit this decision, but at this point it's looking highly unlikely.

Gili

---

From: Randell Jesup <[email-masked]>
Date: Tue, 17 Dec 2013 02:38:57 -0500

>> paranoid yet. Should we be?

#include <classic_unix_getty_backdoor.h>

Tool chains absolutely can be subverted, to the point where even 
rebuilding them using themselves from 'clean' source leaves them subverted.

Super-widely-distributed binaries (like this would be) are obvious 
targets for such things (as are browsers like Chrome and Firefox - but 
those have some extra safety due to build built across a wide range of 
toolchains - but even that leaves the official binaries at risk in theory).

At some point, you have to decide if hand-assembling code with a hex 
editor is worth it (and do you *trust* your hex editor?)
;-)  And don't forget, the backdoor code-flip could be in the filesystem 
too!  With some serious hackery, even in the HD (stretching, but 
theoretically possible I believe).

If you don't want to go that far down, you need to decide to trust 
*some* basic toolchain, use it to build the "current" toolchain, and use 
that to build the binaries.  You can help yourselves by choosing a base 
toolchain that predates anyone knowing you're going to use it for this 
project.  (Note: base toolchain includes the base OS...)

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: John Leslie <[email-masked]>
Date: Fri, 20 Dec 2013 06:36:31 -0500

Matthew Kaufman makes several good points in favor of no-MTI.

   Basically, by the time we actually get this decision made, _every_
codec we may list as MTI will be obsolete (though Matthew doesn't
phrase it quite so bluntly.

Matthew Kaufman <[email-masked]> wrote:
>
> 5.  All entities MUST support at least one of H.264 and VP8
>  
>    *   Are you in favor of this option [Yes/No/Acceptable]: Barely acceptable
>  
>    *   Do you have any objections to this option, if so please summarize them:
> There appear to be no entities that are prevented from shipping one
> of these at this time based on the responses I have seen, however
> we may find at a future time that this is not true. It also will be
> meaningless at a future time when a new codec comes along that is
> in all ways superior. I also believe that it will be reasonable to
> have "audio-only WebRTC devices", and those obviously won't want to
> ship either codec.

   We have seen strenuous objections to re-compiling 20-year old code
for H.261 (and needing to maintain it). It _is_ reasonable to think
that maintaining code for _two_ obsolete codecs will deserve twice
as much objection.

> 7.  There is no MTI video codec
> 
>    *   Are you in favor of this option [Yes/No/Acceptable]: YES
> 
>    *   Do you have any objections to this option, if so please summarize them:
> All of my other objections are remedied by this option. Additionally,
> this entire straw poll is flawed in that the technical community is
> answering on behalf of their respective legal departments, who are not
> present for the discussion.

   Though I quite agree with Matthew that IETF participants playing
lawyers is a bad way to make a decision, I still wish to commend the
Chairs for doing this straw poll -- it brings out ideas and documents
the full extent of our lacking a common base upon which to make the
MTI decision.

   Most responses seem to rule out the no-MTI choice; but we _cannot_
rule it out. We can punt it to another WG, perhaps, if we can't
bring ourselves to consensus to put it in writing; but we're getting
no closer to consensus on any other choice, and at some point we
need to put this question to rest.

> be interesting to see what happens when they get sued for IPR issues...

   We don't _need_ to specify a MTI video codec -- with or without
a MTI codec specified, _some_ browser will support the market demand.

> if we fail to agree on something as MTI.

   I remind folks that the only difference between SHOULD and MUST
is that a vendor can still claim compliance to the standard if they
omit a SHOULD.

   (And, alas, we really have no way to stop a vendor from claiming
compliance even if the _do_ omit a MUST.)

---

From: cowwoc <[email-masked]>
Date: Fri, 20 Dec 2013 11:34:30 -0500

Hi John,

> phrase it quite so bluntly.

MTI is not about picking the newest/best codec. It's about ensuring 
interoperability. You can always upgrade to a newer/better codec even if 
it's not MTI.

> that maintaining code for _two_ obsolete codecs will deserve twice

Maik has posted H.261 code on Github which already compiles for most 
platforms, so it is unlikely you would have to maintain it. And again, 
compromise and interoperability does not come for free. Inevitably you 
will have to support some piece of code that you're not 100% in favor of 
(otherwise you wouldn't be compromising).

> need to put this question to rest.

What's the point of a standard (any standard) that does not guarantee 
interoperability? In the worse case, we'd end up with two competing 
standards but (in my opinion) dropping MTI in the one-and-only standard 
defeats its reason for existing.

Gili

---

From: David Singer <[email-masked]>
Date: Fri, 20 Dec 2013 09:26:10 -0800

There are some things to be said for no MTI:

* (we have had this in 3GPP): once something is mandatory, it’s hard to un-mandate it.  “what about backward compatibility with older systems?”.  3GPP is taking many years to move H.263 from mandated to recommended to optional.  the world moves on, and mandates stay.
* it is functionally equivalent to an MTI that is not respected (and more honest)
* there are audio-only devices (anyone remember those things called ‘telephones’?)
* and finally: Santa is not allowed to use video (FAA ruling, it seems, sad), and videophones in cars may one day be frowned on

Happy hols, everyone

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: cowwoc <[email-masked]>
Date: Fri, 20 Dec 2013 12:55:55 -0500

Think about how silly that statement is. You're asking us to drop video 
MTI in order to be interoperable with telephones without screens (which 
are on the verge of disappearing) but, in dropping MTI we would actually 
be *reducing* interoperability between WebRTC devices, not increasing it.

WebRTC is about web devices first, legacy devices second. At least, it 
is for me.

Gili

On 20/12/2013 12:26 PM, David Singer wrote:
> * (we have had this in 3GPP): once something is mandatory, it's hard 
> to un-mandate it.  "what about backward compatibility with older 
> systems?".  3GPP is taking many years to move H.263 from mandated to 
> recommended to optional.  the world moves on, and mandates stay.
> * there are audio-only devices (anyone remember those things called 
> 'telephones'?)
> * and finally: Santa is not allowed to use video (FAA ruling, it 
> seems, sad), and videophones in cars may one day be frowned on
>
> Happy hols, everyone
>
>
> David Singer

---

From: Ron <[email-masked]>
Date: Sat, 21 Dec 2013 04:59:59 +1030

Sticking with the truth-in-advertising theme:

On Fri, Dec 20, 2013 at 06:36:31AM -0500, John Leslie wrote:
> for H.261 (and needing to maintain it).

"strenuous" seems a little tenuous, as is the part about anybody actually
needing to use 20 year old or unmaintained code to have support for this.

The only "20 year old code" that's been referenced here is a reference
implementation, that's interesting for IPR assurance reasons, but much
less so as a production code base (though on a modern machine, even its
'not optimised for performance' state might still be faster than some or
all H.264 encoders, and give you better battery life to boot!).

And that code probably took me nearly all of 15 minutes to resurrect,
and I could have stopped after the first 5 (with a trivial 3 line patch)
but I spent a few more to make it warning free and able to cross compile,
just because my coffee pot wasn't done percolating yet.

Or you know, I could have just downloaded a modern lib, that's currently
maintained and working and suitable for production use.

> It _is_ reasonable to think that maintaining code for _two_ obsolete
> codecs will deserve twice as much objection.

Yes, 2 x epsilon seems about right to me too.

> a MTI codec specified, _some_ browser will support the market demand.

Corollary:

 We don't _need_ to specify a WebRTC standard -- with or without a
 WebRTC standard specified, _some_ product will support the market demand.

Except the charter says that's exactly the problem we're supposed to be
working on fixing:

 There are a number of proprietary implementations that provide direct
 interactive rich communication using audio, video, collaboration,
 games, etc. between two peers' web-browsers. These are not interoperable,
 as they require non-standard extensions or plugins to work.  There is a
 desire to standardize the basis for such communication ...

So yeah, we could give up on that, and tell everybody to go use Skype,
or their mobile phone, or whatever the proprietary flavour of the day is
today.  Or we could be good engineers and actually find a real working
compromise to solve this problem.  One which calls an artificial blockage
caused by a wooden shoe exactly what it is.

  Ron

---

From: Justin Uberti <[email-masked]>
Date: Fri, 20 Dec 2013 13:32:25 -0800

I do think we should have an affordance for audio-only devices that don't
need to concern themselves with video codecs, but that seems like a spec
wording issue, and not a reason to throw out the idea of MTI.

On Fri, Dec 20, 2013 at 9:55 AM, cowwoc <[email-masked]> wrote:

> MTI in order to be interoperable with telephones without screens (which are
> on the verge of disappearing) but, in dropping MTI we would actually be
> *reducing* interoperability between WebRTC devices, not increasing it.
>
> WebRTC is about web devices first, legacy devices second. At least, it is
> for me.
>
> Gili
>
>
>  * (we have had this in 3GPP): once something is mandatory, it’s hard to
> un-mandate it.  “what about backward compatibility with older systems?”.
>  3GPP is taking many years to move H.263 from mandated to recommended to
> optional.  the world moves on, and mandates stay.
> ‘telephones’?)
> * and finally: Santa is not allowed to use video (FAA ruling, it seems,
> sad), and videophones in cars may one day be frowned on
>
>  Happy hols, everyone
>
>
> David Singer

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Dec 2013 13:36:31 -0800

On 12/20/2013 1:32 PM, Justin Uberti wrote:
> I do think we should have an affordance for audio-only devices that
> don't need to concern themselves with video codecs, but that seems like
> a spec wording issue, and not a reason to throw out the idea of MTI.

What you are implying is multiple usage profiles, or configurations, 
with specifics sets of MTIs for each.

Ideally, these should be built on top of each other, starting with a 
core, minimal capability and then adding capabilities on top.

Pessimally, these would be non-overlapping configurations.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 20 Dec 2013 22:02:20 +0000

On resource-constrained devices, there will barely be room for one highly-optimized (potentially hardware-offloaded) video codec. Carrying software implementations of others, no matter how "simple", will simply not fit in available memory.

Matthew Kaufman
________________________________________
From: rtcweb [[email-masked]] on behalf of Ron [[email-masked]]
Sent: Friday, December 20, 2013 10:29 AM
To: [email-masked]
Subject: Re: [rtcweb] Is there room for a compromise?

Corollary:

  Ron

---

From: Ron <[email-masked]>
Date: Sat, 21 Dec 2013 09:18:09 +1030

On Fri, Dec 20, 2013 at 10:02:20PM +0000, Matthew Kaufman (SKYPE) wrote:
> On resource-constrained devices, there will barely be room for one
> highly-optimized (potentially hardware-offloaded) video codec. Carrying
> software implementations of others, no matter how "simple", will simply not
> fit in available memory.

The p64 implementation of H.261 (this being the one that is deliberately
not highly optimised for anything at all except correctness and ease of
verification) fits into ...  wait for it.   64kB.

And that includes all of the effusive help text, diagnostic and error
strings ...

So given we've already established that almost no device will actually be
able to use its potential hardware-offloading for this, and will almost
certainly need to carry a software implementation - this certainly looks
like a very attractive choice for the constrained devices that worry you!

How much memory does the Skype logo image take ;?

  Ron

---

From: cowwoc <[email-masked]>
Date: Fri, 20 Dec 2013 17:51:18 -0500

I have news for you: WebRTC will not run on all devices known to man.

If I had to choose between interoperability for 95% of today's use-cases 
(browsers, smartphones) versus supporting WebRTC on my iToliet, I guess 
I'd have to forgo the iToliet.

Gili

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 20 Dec 2013 23:40:37 +0000

Mandating H.264 *and* VP8 isn't going to change what browsers support.

Mandating H.261 isn't going to change what embedded devices support.

So why are we bothering to mandate what manufacturers will ignore?

Matthew Kaufman

(Sent from my iPhone)

> On Dec 20, 2013, at 12:52 PM, "cowwoc" <[email-masked]> wrote:
> 
> If I had to choose between interoperability for 95% of today's use-cases (browsers, smartphones) versus supporting WebRTC on my iToliet, I guess I'd have to forgo the iToliet.
> 
> Gili
>

---

From: Jack Moffitt <[email-masked]>
Date: Fri, 20 Dec 2013 17:23:16 -0700

...
> So why are we bothering to mandate what manufacturers will ignore?

Mozilla has stated it will ship both. Google already ships both
codecs, although not with WebRTC. It seems plausible that they might
ship both for WebRTC if it is so mandated. For the browsers that
really leaves Microsoft and Apple.

Am I to read your statement that Microsoft will refuse to ship VP8
should it be mandated with or without 264? Is that Apple's position?

I think that is the assumption most of us have, but Cullen mentioned
at the last meeting that his discussions with browser vendors were
such that they were willing to ship what was mandated[1].

jack.

[1] I found this surprising, and my pessimistic interpretation of this
was that they would ship a compliant implemention *IF* they shipped
one at all. In other words, if H.264 or No MTI is not chosen then they
would not ship WebRTC at all.

---

From: John Leslie <[email-masked]>
Date: Fri, 20 Dec 2013 21:00:43 -0500

cowwoc <[email-masked]> wrote:
> interoperability?

   No standard _can_ "guarantee" interoperability.

   There are many standards that specify _part_of_ how to accomplish
something.

   WebRTC will, in any case, have to specify some way to propose codecs
which are _not_ MTI and negotiate their use. It would be silly to not
allow this same mechanism to propose codecs which _are_ MTI. This would
greatly simplify future upgrades to better codecs.

   And it would be many times more foolish to claim that the market
will not demand better codecs...

   (Please note that my "position" is to have two SHOULD codecs if we
cannot reach consensus on one or more MTI codecs -- in which case it
would be reasonably common for negotiation to succeed.)

   We seem to agree that there will be H.264-only devices attempting
to use WebRTC, and there will be VP8-only devices attempting to use
WebRTC. We have also been told that certain browsers expect to support
both. In those cases, the negotiation succeeds, whether or not we
ever agree on one or more MTI codecs.

   (Of course, it can't _actually_ succeed unless someone designs
the system for negotiation...)

   The point is, a standard which fully designs the negotiation
process is clearly useful -- even though that standard allows a
case where negotiation fails.

> In the worse case, we'd end up with two competing standards

   Perhaps -- but we don't _need_ two competing standards. We end
up with what I would call islands of connectivity within WebRTC.

> but (in my opinion) dropping MTI in the one-and-only standard 

   We aren't designing "the" one-and-only standard. We're designing
a standard to be useful in combination with other standards.

   (Is _that_ the reason so many folks seem to be wearing blinders?)

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 21 Dec 2013 16:55:13 -0500

> * (we have had this in 3GPP): once something is mandatory, it’s hard to un-mandate it.  “what about backward compatibility with older systems?”.  3GPP is taking many years to move H.263 from mandat…

[BA] In particular, I am expecting implementations of H.265 and VP9 to show up during 2014, and in 18-24 months it is quite possible the H.264/VP8 debate will be irrelevant. "No MTI" allows us to focus on getting the specs finalized without the continuing distraction of MTI video codec debates. 

> * it is functionally equivalent to an MTI that is not respected (and more honest)

[BA] No MTI is better than a disrespected MTI choice that continues to distract the WG.

> * there are audio-only devices (anyone remember those things called ‘telephones’?)

[BA] How did SIP somehow survive without an IETF mandatory to implement audio codec? And if they had chosen something other than G.711, might that not have complicated RTCWEB discussions on the subject?

> * and finally: Santa is not allowed to use video (FAA ruling, it seems, sad), and videophones in cars may one day be frowned on

[BA] More likely Santa ran afoul of FCC restrictions, unless there was an airworthiness issue :)

---

From: Ron <[email-masked]>
Date: Sun, 22 Dec 2013 09:46:51 +1030

On Sat, Dec 21, 2013 at 04:55:13PM -0500, Bernard Aboba wrote:
> [BA] In particular, I am expecting implementations of H.265 and VP9 to show
> up during 2014, and in 18-24 months it is quite possible the H.264/VP8 debate
> will be irrelevant. "No MTI" allows us to focus on getting the specs
> finalized without the continuing distraction of MTI video codec debates. 

While I have no doubt that people will begin supporting VP9 and/or H.265
before too long, the significant extra processing cost required to run
them anywhere near real-time will likely pose its own interoperability
barrier well beyond the challenges of choosing an MTI codec for anything
that might elect to only support those.

You're still going to need a lower complexity fallback for some time to
come if you actually care about broad interop.  Unless Daala manages a
clean sweep like Opus did.

> [BA] No MTI is better than a disrespected MTI choice that continues to distract the WG.

Spoiling the marketing of people who don't care about interop is better
than spoiling the standard.

> [BA] How did SIP somehow survive without an IETF mandatory to implement audio
> codec?

It ...  didn't?  SIP has so many ways to be completely non-interoperable
that as a global standard it's been completely stillborn.  Codecs are
the least of the many interoperability problems that ruined it by design.

It's effectively been contained to being a reinvention of proprietary
digital handset protocols bound to a particular brand of PBX, with few
guarantees beyond boundless user frustration once you mix equipment
from more than one vendor.

As a communication mechanism for connecting arbitrary remote peers it's
a complete failure.  If it wasn't, it's probably pretty safe to say this
working group would have never actually needed to form in the first place.
And maybe also safe to say that Microsoft would have never purchased
Skype :)

We should learn from those mistakes, not let people fool us again into
re-creating them.

> And if they had chosen something other than G.711, might that not have
> complicated RTCWEB discussions on the subject?

The PSTN?  You could trivially fit full band Opus into a single G.711
timeslot today.

But they don't for general use because, you know, interoperability.

And the PSTN *also* needs gateways to transcode G.711 to 'itself' in
some cases, because when people let the market decide, they came up
with two mutually incompatible companding algorithms.  So a standards
body had to step in and mandate which one wins when they collide, so
that we could have an actually global telephone network.  QED.

  Ron

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 21 Dec 2013 18:25:08 -0500

> the least of the many interoperability problems that ruined it by design.

[BA] Indeed. And let me suggest that we are in great danger of repeating this in RTCWEB, which today is not sufficiently specified to enable widespread interop - but could be if we were to spend our efforts more wisely.

---

From: Ron <[email-masked]>
Date: Sun, 22 Dec 2013 10:34:35 +1030

On Sat, Dec 21, 2013 at 06:25:08PM -0500, Bernard Aboba wrote:
> [BA] Indeed. And let me suggest that we are in great danger of repeating this
> in RTCWEB, which today is not sufficiently specified to enable widespread
> interop - but could be if we were to spend our efforts more wisely.

That's only a danger if we handwave away the Difficult problems with
"let the market decide" platitudes.

I haven't seen other questions of interoperability going unanswered
just because this one is still not resolved yet.  And however many
drafts may still be waiting on something for completion, I haven't
seen huge floods of people reporting having those problems either.

I suspect most people here have mastered chewing gum and walking at
the same time;  so if this is the current bulk of the list discussion
I can only imagine that either people aren't running into many interop
problems in other areas -- or they aren't actually working on their own
independent implementations until they are sure this can be resolved
satisfactorily and that work won't be a total waste of their time.

The two major browser vendors at least seem to be actively collaborating
on resolving any interop problems they have identified and making good
progress with that.  I assume what they learn will make its way into
being properly specified if it isn't already.

What issues do you see that you haven't already been engaging with here?

  Ron

---

From: Martin Thomson <[email-masked]>
Date: Sat, 21 Dec 2013 18:47:36 -0800

On 21 December 2013 13:55, Bernard Aboba <[email-masked]> wrote:
> "No MTI" allows us to focus on getting the specs finalized without the continuing distraction of MTI video codec debates.

I think that "no consensus" would work equally well.

---

From: Justin Uberti <[email-masked]>
Date: Sat, 21 Dec 2013 21:28:20 -0800

I hope that it will be even simpler than that; merely a statement
indicating that devices that can't send or receive a given media type need
not concern themselves with the MTI codecs of that type.

On Fri, Dec 20, 2013 at 1:36 PM, Dave Crocker <[email-masked]> wrote:

> What you are implying is multiple usage profiles, or configurations, with
> specifics sets of MTIs for each.
>
> Ideally, these should be built on top of each other, starting with a core,
> minimal capability and then adding capabilities on top.
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Dec 2013 09:22:58 -0500

This seems very sensible

> On Dec 22, 2013, at 0:28, Justin Uberti <[email-masked]> wrote:
> 
> I hope that it will be even simpler than that; merely a statement indicating that devices that can't send or receive a given media type need not concern themselves with the MTI codecs of that type.
> 
> 
>> What you are implying is multiple usage profiles, or configurations, with specifics sets of MTIs for each.
>> 
>> Ideally, these should be built on top of each other, starting with a core, minimal capability and then adding capabilities on top.
>>

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 22 Dec 2013 09:12:44 -0800

> just because this one is still not resolved yet. 
[BA] This debate has consumed so many cycles that there has been little room to discuss anything else. 
> And however many drafts may still be waiting on something for completion, I haven't> seen huge floods of people reporting having those problems either.
[BA] There have been a substantial number of issues filed in TRAC - including against the RTP usage document (which does not adequately cover aspects such as feedback messages and bandwidth estimation), circuit breakers (which appears to compete with the consent mechanism) and the security document (which still has open issues on screen sharing). 
Personally, I'd prefer to spend my time on those issues.

---

From: Colin Perkins <[email-masked]>
Date: Sun, 22 Dec 2013 18:40:54 +0000

On 22 Dec 2013, at 17:12, Bernard Aboba <[email-masked]> wrote:
>> And however many drafts may still be waiting on something for completion, I haven't seen huge floods of people reporting having those problems either.
> 
> [BA] There have been a substantial number of issues filed in TRAC - including against the RTP usage document (which does not adequately cover aspects such as feedback messages and bandwidth estimation), 

As far I was aware, those issues have been addressed. If there's anything still outstanding, can you please explain your concerns? There are open issues with the RTP usage draft, but I don't recall any remaining about feedback messages or bandwidth estimation.

> circuit breakers (which appears to compete with the consent mechanism)

Again, I thought your concerns had been addressed some months ago. What issues remain?

-- 
Colin Perkins
http://csperkins.org/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 22 Dec 2013 11:20:33 -0800

On 12/21/2013 9:28 PM, Justin Uberti wrote:
> indicating that devices that can't send or receive a given media type
> need not concern themselves with the MTI codecs of that type.
>

Except that the reality of what you describe isn't nearly as simple as 
it sounds.

You are proposing there be statements about what "mandatory to 
implement" features are not mandatory to implement.

What you describe is typically called a "profile".  Whatever its length, 
a profile defines a subset of some larger specification, and says what 
parts of the specification apply, and what parts don't.

The problem with writing a larger and more complicated specification, 
and then going back and writing a profile which says what parts of the 
specification are or are not in force, is that it's complex and 
confusing, when applied in large-scale.

Adoption of anything for the Internet is an ultimate example of 
"large-scale".  The issue isn't what you or I might find comfortable, 
but what works well across the very, very wide range of readers, 
developers and operators across the global Internet.

Historically, the approach that has worked far better for the Internet 
is to specify a small, tight, core that everyone MUST -- absolutely 
must, no exceptions -- implement, and then build upon that.  Add modules 
incrementally or in combination.

(Humans are better at processing conjunction than negation.  Profiling 
is a negation mechanism.  Incremental features is, of course, conjunction.)

If I am understanding the nature of what is being proposed with respect 
to codecs, it translates into:

      1.  Define a core rtcweb control mechanism that does not specify 
any MTI codecs.  Everyone must implement this core.  No exceptions.  By 
itself, this mechanism will not be usable, since /some/ codecs are 
needed.  But at least the control mechanism would be standardized.

      2.  Define suites of codecs -- possibly independent or overlapping 
suites -- for use by different rtcweb communities.

      3.  The hope is that some of these suites will come to dominate 
the industry.

The above merely tries to summarize what some others have been saying or 
implying.

The one point of concern is that #3 does not require open standards for 
the codecs.  It can; but it doesn't have to.

That is, the community process of adopting particular codecs might turn 
out to be dominated by entirely proprietary components.  So that while 
the control mechanism is an open public standard, the operational system 
is not.

When the Internet was first going into the mass-market, some products 
were labeled "based on Internet standards".  "Based on" was a 
code-phrase that meant that proprietary components were part of the 
product and rendered it non-interoperable with products from other vendors.

That's the risk of the no-MTI codec approach.

d/

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Dec 2013 17:28:27 -0500

On Sun, Dec 22, 2013 at 2:20 PM, Dave Crocker <[email-masked]> wrote:
> Except that the reality of what you describe isn't nearly as simple as it
> sounds.
>
> You are proposing there be statements about what "mandatory to implement"
> features are not mandatory to implement.
>
> What you describe is typically called a "profile".  Whatever its length, a
> profile defines a subset of some larger specification, and says what parts
> of the specification apply, and what parts don't.
>
> The problem with writing a larger and more complicated specification, and
> then going back and writing a profile which says what parts of the
> specification are or are not in force, is that it's complex and confusing,
> when applied in large-scale.
>
> "large-scale".  The issue isn't what you or I might find comfortable, but
> what works well across the very, very wide range of readers, developers and
> operators across the global Internet.
>
> Historically, the approach that has worked far better for the Internet is to
> specify a small, tight, core that everyone MUST -- absolutely must, no
> exceptions -- implement, and then build upon that.  Add modules
> (Humans are better at processing conjunction than negation.  Profiling is a
> negation mechanism.  Incremental features is, of course, conjunction.)
>
> If I am understanding the nature of what is being proposed with respect to
> codecs, it translates into:
>
>      1.  Define a core rtcweb control mechanism that does not specify any
> MTI codecs.  Everyone must implement this core.  No exceptions.  By itself,
> this mechanism will not be usable, since /some/ codecs are needed.  But at
> least the control mechanism would be standardized.
>
>      3.  The hope is that some of these suites will come to dominate the
> industry.
>

I don't think that's what Justin is suggesting.

Rather, I think he's suggesting is that if you don't do video, for
instance, you need not do the video MTI codec.

To take a simple example, a number of phones do not have front-facing
cameras and also have processors that are incapable of doing an
adequate video call (especially if we select a codec for which they
don't have adequate hardware support). In that case, it might be
reasonable to simply not offer video at all on such devices.  In such
a case, would it really make sense to call such devices non-compliant
for not implementing an MTI video codec that they wouldn't negotiate
in any case?

This seems like an orthogonal question to whether devices that do
video MUST do a given video codec.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Sun, 22 Dec 2013 14:57:26 -0800

On 12/22/2013 2:28 PM, Eric Rescorla wrote:
> In that case, it might be

The complement to the implication of your above is whether it makes 
sense to specify a large "complete" system that you know will not be 
implemented in some cases?

I didn't say that a profiling approach was "wrong".  I said it is more 
complex and therefore riskier.  Profiling is an example of a big-system 
approach to specification.  It usually requires more time, less group 
process discipline, and more difficult adoption and interoperability 
patterns.

Why not simplify things considerably, by distinguishing between the core 
that everyone really /does/ have to implement, for whatever level of 
interoperability is required for everyone?  Then specify whatever 
/additional/ functional suites are needed for specific, tailored 
applications, such as the one you cite?

Again, if I'm understanding the basics here, we have two approaches that 
are logically equivalent, but differ in complexity for some cases.

That is:

1.  Profiling approach

     Read and understand --

     a. MTI:  Control base, component 1, component 2, component 3,
              component 4, component 5, component 6...

     b. Ignore component 2, component4, component 5

2. Incremental approach

    Read and understand --

    a. MTI:  Control base
    b. MTI:  Component 1, Component 3, component 6

Remember that the question of complexity for humans is not an arithmetic 
functions.  More components to process means exponential increases in 
complexity.  Hence, the second is easier to work with, for large numbers 
of average implementers around the world.

d/

ps. As an example of the challenges with negation, note that Justin's 
and your messages did not properly handle the Reply-to field of the 
messages I sent.  Instead, your email client sent the mail to the From: 
address and ignored Reply-to:, although Reply-to: is supposed to 
override From:.  This is a mechanism that has been in our email 
standards for more than 35 years and folks still get it wrong! 
Reply-to: is an exceptional (override) mechanism and indeed, 
implementers often get those wrong. Profiling is a form of exceptional 
specification style.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 23 Dec 2013 00:38:53 +0100

>process discipline, and more difficult adoption and interoperability 

This is about "All implementations must support video codec ABC" versus
"Implementations that support video must support video codec ABC". That
is not really profiling. You cannot tell through black box testing if a
device that has no screen and no camera implements a certain video co-
dec (that largely means there is no difference between the two clauses),
so the question would be whether it's okay to put a "100% IETF RTCWeb
compliant" sticker on text-only, audio-only, video-only, ... devices.

>applications, such as the one you cite?

I agree that the "Incremental approach" is better than the "profiling
approach", but as I read the discussion, that is not the issue here.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Dec 2013 20:10:47 -0500

On Sun, Dec 22, 2013 at 5:57 PM, Dave Crocker <[email-masked]> wrote:
> The complement to the implication of your above is whether it makes sense to
> specify a large "complete" system that you know will not be implemented in
> some cases?
>

I don't think I understand what you are suggesting.

We have two capabilities here, Audio and Video. We already have two
MTI audio codecs (Opus and G.711). Stipulate that we decide
on an MTI codec for video (call it VP264). Now, for devices of the type
I described above, we have the following options in terms of requirements.

1. Need not support video and need not support VP264 (Justin's suggestion),
but MUST support VP264 if it supports video.
2. Need not support video but MUST support VP264 in any case.
3. MUST support video and MUST support VP264.

Which of these are you proposing? Or something else?

-Ekr

---

From: Ron <[email-masked]>
Date: Mon, 23 Dec 2013 11:52:55 +1030

> >> need not concern themselves with the MTI codecs of that type.

[snipped]

> instance, you need not do the video MTI codec.

I didn't think that this was exactly what he was suggesting either.
The crucial difference being "can't" vs "don't".

If you don't have a camera, or a screen, then it's pretty obvious
to any user of that device that they can't expect any type of video.

This elaboration however is a somewhat different slippery slope:

> cameras

If they have a screen, they can still receive it, and might well expect
to do so.  For that matter, they might even be prepared to stand in front
of a mirror to send it :)

> and also have processors that are incapable of doing an
> don't have adequate hardware support).

This would seem to be yet another argument for having a low complexity
codec as the fallback MTI.  Given we've established almost no current
device has adequate specialised hardware for any codec and will all
need to be able to do it on its application processor anyway.

Is there anything with a camera that doesn't have processing resources
far greater than were used for video 20 years ago?

What proportion of devices would struggle with VP8 or H.264 on their
application CPU?

> In that case, it might be reasonable to simply not offer video at all
> on such devices.

Which would be a surprising outcome for anyone expecting a device that
can play them cat videos should also be able to give them video from a
webrtc application as advertised.

> In such a case, would it really make sense to call such devices
> non-compliant for not implementing an MTI video codec that they
> wouldn't negotiate in any case?

Yes, it would.  Choosing not to provide video support where video is
an integral part of the standard and something supported by the device
is deliberate non-compliance.

That's quite different from just not doing the obviously impossible
on obviously primitive devices.

People have suggested that if we let the market decide, parts of it
might well decide on only H.265, this would effectively rule out *all*
current mobile devices for lack of processing power.  If concern for
those devices is in scope here, then we definitely do need to mandate
something with an acceptable complexity bound to ensure that won't
be a problem.

> video MUST do a given video codec.

It doesn't seem like a very complicated question.  Justin's suggestion
was an eminently sensible statement of the obvious.  If your device
obviously can't ever do video at all, nobody is going to be surprised
if the code for that doesn't happen to be there either.

That's not in any way practically different from you not giving consent
to enable the camera, and simply turning off your screen backlight.
If you wanted those things you'd have bought a device with a screen and
a camera.

But that's very different from having a device which does have a camera
and/or screen and finding that its claim to support webrtc came with a
big caveat emptor.  I don't think we should be supporting a backdoor
"No MTI" or "let the market decide" outcome through a loophole like this.

  Ron

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 23 Dec 2013 02:40:05 +0100

>if the code for that doesn't happen to be there either.

That is not quite the whole story. If you order a product with "WebRTC"
and get a text pager or ringphone that do speak the wire protocol, you
might well feel mislead because you associate "WebRTC" with smartphone
video conferencing or whatever. The Working Group might well decide to
deny certain underpowered devices to claim implementing the standard it
is defining. There might be good reasons for that aswell, e.g. certain
technically plausible implementations might not meet accessibility or
other requirements considered mandatory by the Working Group.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Dec 2013 20:42:10 -0500

> codec as the fallback MTI.

It is quite possible we will not standardize such a codec.

>  Given we've established almost no current

It's actually extremely expensive on low-end phones.

> webrtc application as advertised.

You will note that many such devices use H.264 for precisely this reason.
I.e., they have hardware codecs.

> is deliberate non-compliance.

What we are debating here is precisely whether video is or is not a
compliance requirement. You seem to be assuming that, I don't,
and as far as I know the specification language doesn't require
it. Can you please point to the relevant part of the specification
which requires implementations to offer to accept and/or send
video?

> on obviously primitive devices.

"Obvious" is a difficult term here. Have you actually tried doing
VP8 video on low-end smartphones? I actually have and I can't
even tell you definitively which ones could eventually be made
to do acceptable video and which ones could not. How, exactly,
is that supposed to be "obvious" to the average consumer?

> If you wanted those things you'd have bought a device with a screen and

I don't see any material difference between not having a screen and
not having enough CPU to do provide good quality video. And of
course since nearly all devices have some screen, we're now stuck
debating exactly what flavor of a device has a big enough screen
that it can support video. A watch? An ipod nano? A featurephone?

> "No MTI" or "let the market decide" outcome through a loophole like this.

I don't find this very persuasive. If I'm the manufacturer of a device which
has a hard time doing acceptable video conferencing, I have three
choices:

1. Don't offer WebRTC at all.
2. Offer WebRTC audio only.
3. Offer WebRTC with lousy video;

You seem to want to argue that we should label anyone who does #2 as
noncompliant. I fail to see how that serves any useful interest, especially
given the extremely marginal value of "compliant" versus "noncompliant"
to the average consumer.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Sun, 22 Dec 2013 18:06:18 -0800

On 12/22/2013 5:40 PM, Bjoern Hoehrmann wrote:
> If you order a product with "WebRTC" and get a text pager or
> ringphone that do speak the wire protocol, you might well feel
> mislead because you associate "WebRTC" with smartphone video
> conferencing or whatever.

This is an essential point.  It highlights the human factors/marketing 
reason that profiling is problematic:  a single label for a broad set of 
functions that aren't always all provided is misleading.

This is the reason that each type of capability needs its own, 
distinctive name.

This warrants repeating:  To the extent that different styles of use 
will mean that some features are not supported, a single generic name 
will be misleading.

Perhaps not surprisingly, the incremental approach to specification
lends itself nicely to this issue, whereas profiling does not.

And to the extent that folks think subsetting (profiling) is not the
issue, please re-read some of the language being used, such as:

> a statement indicating that devices that can't send or receive a
> given media type need not concern themselves with the MTI codecs of
> that type.

That's profiling.

On the other hand, distinctive labels, such as

    1.  rtcweb base

    2.  rtcweb video

    3.  rtcweb audio

    4. rtcweb audio + video

are names that distinguish one product type from another.  (I don't care 
what the actual names are, as long as each distinguishes the set of 
features from other, different sets.)

d/

---

From: Ron <[email-masked]>
Date: Mon, 23 Dec 2013 14:19:58 +1030

> It is quite possible we will not standardize such a codec.

It is indeed possible, yes.  Whether it would be wise is the question
that I think we might not have considered sufficiently in this light.

> It's actually extremely expensive on low-end phones.

Which is why I think the question of complexity bound is quite relevant
for MTI fallback requirements.

> I.e., they have hardware codecs.

The earlier discussion had a hard time finding any device where those
hardware engines would actually be able to be used by WebRTC applications
for a fairly broad range of reasons.  So even those devices still have
the same complexity constraints, and either they are important and we
should consider what will actually work on them - or they aren't and any
argument about what they can or can't support is irrelevant to WebRTC.

It doesn't seem unreasonable to decide that the mandatory parts of this
standard should be able to actually run on the general purpose CPUs of
the sort of devices that are expected to benefit from implementing it,
without the need for proprietary ASICs.

> which requires implementations to offer to accept and/or send

Hmm.  I had indeed read the first paragraph of the charter, which
describes audio and video as "core components", as making this a
key part of the standard.

If I'm mistaken about there being consensus on that, then yes, the
question is more open still.   And I'm going to need more popcorn.

> is that supposed to be "obvious" to the average consumer?

Hence my question about whether the complexity requirements of both
VP8 and H.264 might actually rule them both out for fallback MTI.
I'm pretty sure we do have at least one video choice available to us
that wouldn't leave those devices completely out in the cold.

> that it can support video. A watch? An ipod nano? A featurephone?

You'll need to define "good quality video" before we can enter that
rat hole!

Is "able to transmit legible sign language" good quality?

How big does a screen need to be before the extra quality of the high
complexity codecs actually become perceptible and of any value at all?

> given the extremely marginal value of "compliant" versus "noncompliant"

Actually, my argument here is probably closer to:

 - If we create a crap standard, that puts devices which do have video
   hardware into a ghetto if they don't have the right proprietary ASIC
   to support even the minimum requirement for video - then that would
   be our fault and it would deserve to be called a crap standard.

 - If vendors create an implementation of it that gives users of some
   device a far poorer experience than they might otherwise reasonably
   expect to have had, then yes they deserve whatever label they might
   receive for that, not us.

As you say, given the marginal value to consumers, they don't have to
claim to be WebRTC compliant in order to interop with it for audio only.

The bigger danger is allowing the creation of a general impression that
"video doesn't work with WebRTC at all on video devices".  Which would
leave us right back with the same problem that this group was chartered
to solve.

  Ron

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 23 Dec 2013 12:18:13 -0500

[RS> ] Actually the FCC recently reviewed this problem (I'm not sure if Santa offered public ex parte comments) and at least for now these restrictions will be lifted.  Santa will have to watch for FAA regulations on this , but Santa has a long record of understanding that agencies regulatory process.  

http://www.fcc.gov/document/fcc-initiates-review-rules-wireless-services-onboard-aircraft

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 30 Dec 2013 07:44:35 -0800

Colin said: 
As far I was aware, those issues have been addressed. If there's anything still outstanding, can you please explain your concerns? There are open issues with the RTP usage draft, but I don't recall any remaining about feedback messages or bandwidth estimation.
[BA]  The RTP usage document needs to align with the feedback messages utilized by modern video codecs. 
draft-ietf-payload-vp8 Section 5 refers to the RPSI and SLI feedback messages. draft-ietf-payload-rtp-h265 Section 8 refers to the RPSI and (newly defined) SPLI messages. 
And yet draft-ietf-rtcweb-rtp-usage Section 5.1.3 indicates that support for SLI is OPTIONAL while Section 5.1.4 indicates that support for RPSI is OPTIONAL.  
This doesn't seem right.