On Wed, Oct 5, 2011 at 6:16 PM, Stephan Wenger <stewe(_at_)stewe(_dot_)org>
wrote:
Phillip,
Please see inline.
On 10.5.2011 13:25 , "Phillip Hallam-Baker" <hallam(_at_)gmail(_dot_)com>
wrote:
I have some issues with the way that the section on IPR is written.
While I agree with most of the statements there. I don't see my two
biggest IPR concerns listed.
1) Specific to this document, we already have unencumbered CODECs that
permit encoding of audio and video with acceptable fidelity and
adequate compression for 95% of all purposes. Thus it is essential
that the IPR regime for any future CODEC strictly limits the cost of
using that technique to some portion of the cost savings from
reduction in bandwidth use.
I disagree for technical reasons that have already been pointed out by
others. I would also suggest that something like AAC, according to your
theory, should have never happened (as it covers essentially the same
application space as MP3, with moderate gains in the quality/bitrate
tradeoff), but it a) was standardized--in the same body as MP3, and b) was
and is a commercial success, despite being quite expensive.
I said that adopting a new encumbered algorithm would be stupid. At no
time did I say that stupid did not happen. For evidence to the
contrary see Planet:Earth
Frequently IPR holders will attempt to prolong the validity of their
patents by making minor tweaks of dubious technical value.
What I said was that if any new CODEC is going to be accepted, the
cost of using that CODEC must be strictly limited to the value that is
provided in terms of limiting the number of bits required. In other
words, I do not want to be paying for the patent that enables me to do
Internet telephony since that can be achieved quite acceptably with no
compression whatsoever. I may be willing to pay $X for a patent that
allows savings significantly greater than $X.
Unfortunately the current draft seems to me to be saying 'free is good
but we might have to pay'. I think the presumption should be that
there will be no payment for this particular application for reasons
that go beyond the general preference for free.
2) The principal concern I have with IPR licensing in general is not
the cost of licensing but the difficulty of licensing. I have on
several occasions been in negotiations with an IPR holder who is
completely unable to decide how much money they want or on what terms
they are willing to offer their IPR.
The IETF is certainly not in the business of regulating how licensing
discussions are to be arranged :-) (Never mind that they can be quite
frustrating, as, apparently, both of us know).
Again, mu law is seriously out of patent. No conversations with wolves
or lawyers required.
All what you write above is true.
Taken in combination, I cannot imagine any reason to use any audio
codec other than MP3 or AC2 (or some other similar legacy scheme) once
we can be assured that the corresponding patents have expired.
Well, many folks actually do license, under sometimes expensive terms,
protected technology, and use them to their benefit.
MP3 became the standard for audio because it was the only widely
supported option. Dolby Digital offered somewhat better fidelity and
multi-tracks.
But those technologies are close to twenty years old and the patents
should be nearing expiry or have already expired.
Your email ends here. Now I'm at loss.
Is your position that
A) the section on IPR be modified with an explanation of the commercial
constraints you have described,
B) the section be modified to gate the issue of an RFC defining an IETF
codec on terms compatible with YOUR commercial constraints you have
described, or
C) something else?
I was arguing for A.
If we are talking about IPR we are inevitably talking about commercial
terms. I would like IPR holders in this space to understand that this
is not going to be the normal patent beauty contest that has been the
norm in this space for the past 20 odd years.
I am quite aware of the licensing schemes employed in the MPEG world
and really don't have much good to say about it.
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf