[Kde-accessibility] IBM TTS SDK
garycramblitt at comcast.net
Tue Jan 17 01:34:02 CET 2006
On Tuesday 10 January 2006 10:14, George Kraft wrote:
> FYI, this past December I released an open source IBM TTS SDK for TTS
> dependent projects to compile with. This SDK project only provides the
> ABIs for compiling and no runtime logic.
> The eci.h header file and libibmeci.so stub library will enable your
> open source packages to be built to use the Linux IBM TTS Runtime. The
> Linux distributions could precompile various components with the SDK so
> that the runtime will work when installed.
I'm looking at creating a plugin for KTTS that would enable KTTS users who
have the IBM TTS runtime package to use it with KTTS. In order to write such
a plugin, I must compile and link against the library supplied in the IBM TTS
SDK George mentions above. I want users and packagers to be able to build my
plugin regardless of whether they have the commercial IBM TTS runtime
installed or the IBM TTS SDK installed, which means I must distribute the IBM
TTS SDK with my plugin code. The SDK is licensed according to the IBM Common
This license confuses me. There is a FAQ here
There seem to be several issues.
1. The current KDE licensing policy
does not list the CPL as an approved license, which means I cannot distribute
CPL code with the rest of KTTS in the kdeaccessibility module. Hence, I
cannot include the IBM TTS SDK in the kdeaccessibility module.
2. Number 12 of the FAQ mentioned above seems to say that I cannot license my
plugin code under the GPL or LGPL. Yet, Janina tells me that a similar
derivative called ttsynth_say is licensed under LGPL. ?? If my code has to
be licensed under the CPL, then I cannot include my code in the
kdeaccessibility module either.
3. The CPL seems to obligate commerical distributors who distribute
derivative works to "edemnify" recipients. This part of the CPL has me
totally confused, but it would seem to indicate that commercial distributors
of my plugin would have to indemnify recipients of my plugin? That hardly
seems "right" to me. Very confused.
4. It isn't clear to me what the implications of my plugin are to downstream
distributors, such as Debian. In the past, Debian packagers have excluded
KTTS plugins that rely on non "free" components. For example, the KTTS
Hadifix plugin is not included in the main kttsd package. Instead, it is in
a separate non-free repository as kttsd-contrib-plugins. Now this is done
despite the fact that all the code in the KTTS Hadifix plugin is LGPL. The
Hadifix plugin does not link against Hadifix; it runs it as a subprocess. In
the case of my IBM TTS plugin, it is even worse because my plugin needs to
link against CPL'd code. The status of the CPL with respect to Debian is
Given all these questions and obstacles, I'm think about giving up on an IBM
TTS plugin for KTTS, but perhaps someone can clarify the situation for me?
How is Gnome handling this, for instance?
I think one way to avoid all these issues is to write my plugin so that it
runs IBM TTS as a subprocess (because I assume I could then license my plugin
code under the LGPL). To achieve that, the IBM TTS would need to be
distributed with a command-line utility similar to ttsynth_say. There would
need to be some enhancements to ttsynth_say before I could do that
Gary Cramblitt (aka PhantomsDad)
KDE Text-to-Speech Maintainer
More information about the kde-accessibility