Re: [codec] WGLC #2 for draft-ietf-codec-opus-10

["Michael Ramalho (mramalho)" <[e-mail]>]

All,

Re: " Further, I would regard any discussion about the purpose of IPRs
in OPUS as useless. In general terms it is however an undisputable fact
that OPUS is not as unencumbered as it was the original desire of the
group."

Sorry for dropping in late on this thread, and my comment is not
specific to Ron's comment (Ron, your email is simply convenient - don't
read my reply to your email to be referencing you specifically).

I think Ron's comment is particularly interesting given Skype's IPR
statement (Skype:       https://datatracker.ietf.org/ipr/1602/ ).

Assuming that MSFT does close on the Skype acquisition, the royalty-free
language appears to me to come with the condition that the receiving
entity agrees to not sue MSFT for ANY MSFT patent (even those patents
NOT RELATED to OPUS).

I am not a lawyer, but here is the language:

<quote_from_URL_above>
Skype will retain the right to terminate the license and assert its
patents (including the right to claim past royalties) against any
licensee that asserts or whose affiliate asserts >>>ANY<<< patent
(either directly or indirectly) against Skype or any of Skype's
affiliates or >>>SUCCESSORS IN TITLE<<<.
</quote_from_URL_above>

That, to some companies, may be a really big legal concession to make
for use of an audio codec.

I am not a lawyer, but I did stay at a Holiday Inn Express last night
(joke only to be understood by US attendees) ...

Michael Ramalho, Ph.D.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Erik Norvell
Sent: Thursday, November 17, 2011 8:21 AM
To: Ron; [e-mail]
Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10

Ron,

You are talking about interoperability guarantees and that the IPRs in
the codec would serve the purpose to offer these guarantees rather than
to protect a revenue stream garnered from unwitting users of the
technology. 
 
I don't believe that the threat of potential litigation is the only way
to maintain interoperability between implementations. Further, I would
regard any discussion about the purpose of IPRs in OPUS as useless. In
general terms it is however an undisputable fact that OPUS is not as
unencumbered as it was the original desire of the group. Hence, please
respect that every implementer may want to make his own balance of the
quality of his product using OPUS on the one hand and the licensing
cost/risk stemming from the encumbrance of the codec on the other hand.
With this background I simply request to respect that implementers may
want to have their implementation freedom.

Concerning interoperability itself you seem to confuse this term with a
guarantee to offer the best possible quality. I don't think that we can
go that far. It is definitely not logical given that the encoder would
in any case only be informative. So even if you are using a bit exact
decoder implementation you have no quality guarantees because the
encoder might be crappy. (In fact, you don't even have interoperability
guaranteed.) Hence, it makes no sense to be extremely relaxed on the
encoding end and at the same time to be very restrictive on the decoding
end. A reasonable definition of the term interoperability would be
required first. In my view interoperability of a given encoder/decoder
pair can only mean that the decoder can produce a 'useful output' from
any bitstreams produced by the encoder operated in any possible setting.
The term useful output should relate to intelligibility, but quality
expectations should not be associated with interoperability.

Finally, you seem certain that decoder enhancements are not possible
while encoder enhancements would be. I think there are numerous examples
where the decoding end of existing (speech) codecs were enhanced. Such
enhancements would be disqualified by a too narrow conformance test even
though the decoder should be considered interoperable.
 
Best regards
Erik 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Ron
> Sent: den 16 november 2011 20:18
> To: [e-mail]
> Subject: Re: [codec] WGLC #2 for draft-ietf-codec-opus-10
> 
> On Wed, Nov 16, 2011 at 11:37:12AM +0100, Christian Hoene wrote:
> > Hi,
> > 
> > I would suggest to split two things: 
> > 
> > First, we need a notion for standard conformance because of 
> the legal 
> > IPR requirements (can be more relaxing).
> > Second, we need some tests in respect to interoperability 
> (should be 
> > more straight).
> > 
> >  Both tests need to fulfill different requirements.
> 
> I don't see these as different requirements at all.
> 
> The IPR in this case is not being used to protect a revenue 
> stream garnered from unwitting users of the technology - it 
> is being used to protect the interoperability guarantees that 
> can be offered to end users.
> 
> Separating these two things, and watering down the protection 
> offered by the IPR does not offer any benefit to users, only 
> to implementers who might be tempted to compromise on 
> interoperability.  Possibly for 'practical'
> reasons, and possibly for 'commercial' reasons of their own - 
> but their reasons don't matter, only the end effect, a 
> degraded user experience, is the important consideration (to 
> avoid) here.
> 
> There is one requirement.  Good interoperability.  IPR grant 
> conformance is the only binding method we have of ensuring 
> this.  As heretical as it may seem to the FRAND profit 
> seekers - the real profit to be made here from patents is an 
> enhanced and assured user experience.
> 
> Of course, since I don't actually own any of the IPR, I can't 
> speak for the people who do, or for their motives - but this 
> is what I see as their most valuable gift to us, above and 
> beyond the actual technology itself.
> 
> 
> > Also, I like Erik's idea to allow for algorithms to replace 
> patented 
> > stuff in the codec - even if the quality is a bit worse.
> 
> I think this is a fallacy.  It was argued that this extra 
> freedom might allow people to produce a 'better' decoder.  
> That seems like nonsense to me, the decoder is never going to 
> be able to recover information that simply isn't there - the 
> best it can do is recover all of it with tight fidelity.  
> Which is what the current conformance test tries to measure.
> 
> It was also argued that this freedom might allow people to 
> produce a worse decoder.  That seems like something we should 
> strongly avoid.
> There seem to be only three reasons to do this:
> 
>  - Save cycles on underpowered systems.
>    But the requirements already include assessing complexity 
> guarantees
>    are within reasonable bounds.
> 
>  - Sidestep the IPR to produce systems that are not fully 
> interoperable
>    but can still claim (some semblance of) conformance.
> 
>  - Provide distortive 'enhancements' that some users may 
> assess as being
>    pleasing on a first brief listen, but which reduce the 
> real fidelity
>    of the output.   (eg. simulate mp3 distortion for the people who
>    listening tests actually prove like that more than 
> lossless original)
> 
> Both those latter cases carry a danger of sounding like crap if future
> (real) enhancements are made to the encoder which actually 
> does increase the real fidelity and information content of 
> the encoded signal.
> 
> The likelihood of such improvements being made to the encoder 
> is high, so I think this is a real jeopardy which we should 
> not inflict upon end users or limit future encoder work by.
> 
> The decoder should decode the bitstream accurately.  If it 
> cannot, then it should not claim to decode Opus.  People are 
> always free to sidestep the IPR and make something that 
> sounds worse.  They just shouldn't be encouraged or allowed 
> to then also misrepresent that as Opus and mislead the users 
> that this group set out to serve.  As some of the liaisons 
> have reminded us, we're here because we wanted to *raise* the 
> bar, not to just continue Business As Usual in patented codec 
> proliferation.
> So we should do just that.  And make everyone happy :)
> 
> IMO
> 
>  Ron
> 
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
> 
_______________________________________________
codec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/codec