iLBC license issue

[Daniel Pocock]

>>>      
>>>
>>Can iLBC be split into a separate package?
>>    
>>
>
>  Yes, it can.
>
>  
>
>>I have been thinking of putting together a common codec API for VoIP
>>applications, to
>>
>>a) try and defuse the myriad licensing issues that seem to arise
>>whenever codecs are discussed (especially my now notorious patch for
>>Asterisk).
>>b) allow all applications to use any codec, thus improving the reach of
>>open source apps and reducing development time
>>c) potentially allow (yucky) commercially licensed codecs to be shared
>>across multiple applications, CPUs and even distinct hosts within an
>>enterprise, so end users don't end up paying for the same codec 3 or 4
>>times over
>>
>>The API would be licensed under something unrestrictive like Vocal, the
>>apps built on the API could be GPL or Vocal, and the end user could then
>>dynamically choose codecs regardless of license.
>>
>>How do people feel about this idea, and would Debian be a good place for
>>it to start?
>>    
>>
>
>  This is my personal opinion. It does not make much sense to develop yet
>  another api unless you can make all application developers use it.
>  
>
That is a good point - nonetheless, most developers don't particularly 
like these license issues, and will probably see this as something that 
will empower their projects.

>  Additional api/library would only make things more complex and introduce
>  additional bugs. Furthermore it would be quite hard to make it generic
>  enough so it can be used across all applications and protocols. Note that
>  to make it fully transparent to the application you would need to provide
>  identifiers and characteristics of codecs for RTP, SDP, and others.
>
>  
>
Yes, that is understood.  I've been studying the codec APIs within 
Asterisk and OpenH323 to try and establish what is best practice.  I've 
also had feedback that an option for static linking at compile time is 
desirable, so there will probably need to be some tools to help 
re-arrange third-party binary-only codecs to link statically and avoid 
naming clashes.

>  It would make sense if applications like kphone could be written without
>  explicit knowledge about available codecs, but are you sure you can really
>  make the API generic enough and yet easy to use to make this possible ?
>
>  
>
Yes, I believe this is definitely possible.  It is also highly 
desirable.  Doing so will promote good programming practices, and save 
people the hassle of re-inventing the wheel each time they create an 
application.

>  
>
>  Having libraries that applications can link against, like libilbc and
>  libspeex makes imho sense and would be worth doing.
>  
>
The challenge with this is that
a) libilbc and libspeex may not have identical APIs, so an application 
developer has to be familiar with each different API
b) if the app links directly to libilbc, or, for instance, libg729, then 
there might be license issues

I've started to document some requirements for a codec API:

    http://www.unifiedcodec.org/

Regards,

Daniel