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

[Ron <[e-mail]>]

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