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

On 12/12/2013 10:53 PM, Ron wrote:
> 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.

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 [..]".

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

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.

> 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
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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