iLBC license issue

[Jan Janak]

Daniel Pocock wrote:
> 
> 
> Jan Janak wrote:
> 
>> Hello,
>>
>> kphone (and maybe other packages) contain iLBC (internet Low Bitrate
>> Codec)
>> library. This library has been published as part of RFC3951 by the IETF.
>>
>> The copyright owner of that code is Global IP Sound and the license of
>> the
>> code is not GPL compatible. The license requires that derived work must
>> be backwards compatible with the original specification. This is more
>> restrictive than GPL.
>>
>> I am wondering whether the people on the list are aware of this ? The
>> copyright file in kphone package says that it is released under the
>> terms of
>> GPL, but I wonder if this is true when iLBC is included ? Shouldn't
>> kphone
>> be moved in non-free ?
>>
>> http://www.ilbcfreeware.org/documentation/gips_iLBClicense.pdf
>>
>>  
>>
> 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.
  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.

  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 ?

  Having libraries that applications can link against, like libilbc and
  libspeex makes imho sense and would be worth doing.

    Jan.