Hi there! A little context might be helpful for the e-mail Olle forwarded over. Lorenzo Miniero is currently working on an implementation of the Opus codecfor Asterisk and was discussing it on the asterisk- dev mailing list (which is entirely appropriate, as that is what the mailing list is there for!) Since we are quickly coming up on a feature freeze deadline for the next major version of Asterisk, I wanted to make sure that Lorenzo knew Digium's position regarding inclusion of a GPLv2 compliant Opus codec in Asterisk at this moment in time.
That means the e-mail was targeted towards a discussion of: * A module that does transcoding of the Opus codec * A module that is licensed under the GPLv2 and distributed with Asterisk * A module that is included in the next major version of Asterisk My statements were made specifically to that scenario, and do not affect possible future support of Opus in Asterisk, pass-through support, or a module produced under a different licensing scheme. I probably could have clarified that a bit better in my original e-mail. I'll also admit I may have pulled out the soap box on that e-mail. What can I say - my loathing and disdain for entities that produce no tangible product, benefit society in no meaningful way, and use intellectual property as a means to stifle, suppress, and kill innovation rather than protect it knows no bounds. I'll try to address the individual statements in this e-mail chain below. On Sat, Jun 29, 2013 at 7:18 AM, Michael Graves <[email protected]> wrote: > Earlier this week Mr Duffet & Mr Sokol performed a demo at WebRTC Expo in > Atlanta. It involved Asterisk on a Raspberry Pi interacting with Chrome via > WebRTC. > <snip> > The implication is that Asterisk now or will soon handle Opus, web > sockets, etc.**** > > ** ** > > Michael Graves **** > > ** > Asterisk 11 already contains support SIP over WebSockets, DTLS-SRTP, and ICE/STUN/TURN. Everything in the demo that was Asterisk related has been released for almost a year now. Asterisk 11 does not contain support for Opus, nor will it - although that's simply the case of our release policy not allowing for new features in an LTS release branch, and has nothing to do with license models or IPRs. *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Anthony Minessale > *Sent:* Friday, June 28, 2013 7:04 PM > *To:* Cullen Jennings (fluffy) > *Cc:* [email protected] > *Subject:* Re: [codec] [asterisk-dev] Opus and VP8**** > > ** ** > > I think everything you can iterate about VoIP / Internet / Security in > general leads to some patent claim or another.**** > > ** ** > > We've had a working Opus module in FreeSWITCH for over a year now and our > new WebRTC beta utilizes it. https://webrtc.freeswitch.org**** > > We're in a similar boat with video and have to do some work if we wanted > to achieve transcoding.**** > > ** ** > > Asterisk already has Silk and CELT anyway so aren't they already opening > that can of worms? > Xiph has made public a statement that an external council has determined that Opus can be implemented without violating the existing IPRs. However, while that statement is publicly available, the analysis that led to that conclusion does not appear to be - and even if it were, IANAL (much less one that specializes in codec patents). I will say that knowledge of at least one external council determining that there are no licensing impacts is certainly nice and a good starting point. However, every project has to make their own determination as to what goes in it and what doesn't. If a project evaluates a technology and determines that there are no licensing issues with including that technology, that's certainly great. But that doesn't change the fact that the burden of the decision rests with each project individually. Obvious rejoinder: "Have you evaluated the IPRs for Opus"? Short answer: it's a month to feature freeze for Asterisk 12 and we have a single in-house council. Neither she nor I are lacking for things to do. As far as Asterisk and Silk/CELT are concerned, Asterisk does not include a GPLv2 module of the Silk or CELT codec in its distribution. Digium has, however, produced Silk and CELT codec modules, in the same way that we produce a G.729 codec module. > ** > > On Fri, Jun 28, 2013 at 5:28 PM, Cullen Jennings (fluffy) < > [email protected]> wrote:**** > > > Well, Asterisk does SIP and that has way more IPR on it than Opus, so uh, > I guess you will need to decide if you think some random claim on IETF web > site is a valid concern or not. Good luck. Note that blocking all forward > progress on asterisk by filing claims on an IETF web page is also a risk to > the project. > > (Oh, and TLS has lots of IPR too) > > PS - every effort possible has been made to ensure that Opus is GPL > compatible.**** > > > > You're right: SIP/TLS has more IPR than Opus. As do many other technologies in our industry, some of which are in Asterisk. We try to make licensing evaluations on all patches that go into Asterisk. If a technology that has IPRs filed against it is implemented in Asterisk it is because we evaluated those claims and made a determination that the technology's inclusion in Asterisk was warranted, the claims didn't exist at the time the patch was written, or the claims weren't known about when the patch went in. In this particular case, at this moment in time, we haven't had the opportunity to evaluate Opus to the extent that I'd feel comfortable with Lorenzo's patch going into Asterisk. We try very hard not to make uninformed decisions regarding licensing of features going into the project. Does this slow us down sometimes? Yes. Does it limit some things that go in Asterisk? Yes. Not to pull out the soap box again, but it's better to be prudent and careful than end up as another casualty of the American patent system. Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
_______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
