Two different things are in this repository and only one of them is ours to
license.

Ours
----

The engine in `src`, the romanizers in `rom`, the two front ends in `cli`, the
tools in `tools`, the tests in `test`, the reference build in `reference` and
the documents in `docs` are our own work: C written against IBM's objects and
checked against them, line by line, by the audio coming out. That is what the
MIT licence in LICENSE covers.

Two files in `src` are the exception, and they are data rather than code.
`src/klatt/klatt_tables.c` is the synthesiser's own tables, lifted out of `clsyn.obj`
by `tools/engine/klatt-tables.py`, and `src/eci/ssml/eci_xmltok_tables.c` is the eight tables the
XML scanner is, lifted out of `xmltok.obj` by `tools/engine/xmltok.py`. Both are
IBM's on the terms below, exactly as everything under `lang` is. The head of
each says which object it came from, and either can be produced again from
IBM's own file rather than taken on trust. Nothing else in `src` is lifted:
every other file there is C written by hand.

The XML scanner is worth a sentence on why. It is flex output, and a rule set
that has been compiled into a state machine cannot be recovered from the
machine -- the equivalence classes, the base and default rows and the accepting
lists are the only surviving statement of what the forty-eight rules were. So
lifting them was the only faithful course; writing a parser that behaved
roughly the same would have been ours and would have been a different scanner.

`rom` is where the split between the two halves matters most, and it is why
that directory exists at all. A language written in another script needs a
romanizer, which in IBM's SDK is a module of code beside the language's data.
The code is transcribed the way `src` is and is ours on the same terms; the
dictionary and the tables it reads are IBM's data and are in `lang/<tag>` with
the rest of that language, on the terms below. Putting the two in one
directory would have been tidier and would have made the licence line harder
to state truthfully.

IBM's
-----

Everything under `lang` is transcribed out of IBM's Embedded ViaVoice objects:
`lang/enus` is US English, `lang/dede` is German, `lang/engb` is British
English, `lang/eses` and `lang/esus` are the two Spanishes, `lang/frfr` and
`lang/frca` the two Frenches and `lang/itit` is Italian, and any language added
later will be the same.

`lang/jajp` is Japanese and is not in the tree, because a language module that
cannot yet make an instance would break any build that named it. What that
directory holds when it is lifted is IBM's on exactly the terms above, and most
of it by volume is the romanizer's own data: the static dictionary of kanji and
their readings, the substitution tables that make romaji, and the codeset
conversion tables. `tools/rom/dictionary.py` and `tools/rom/tables.py` are what
lift it, and both read IBM's objects rather than being typed out here.

`lang/plpl` says Polish and is Italian. It was made by copying `lang/itit`'s
text forms and renaming them, because a language IBM never shipped has to start
from one it did, and every rule and every table in it is IBM's Italian data
until it has been replaced by something written here. Nothing about the
directory being called Polish makes any of it ours. `make EVVLANG=lang/plpl
census` is what says how much of it is still Italian, and while that answers
anything at all the answer above governs it.

The rules as bytecode, the constants they read, the
statement and field tables, the lookup sets, the variable declarations, the
settings the engine carries in its own image, the voice presets and the
dictionary, and where the engine's arithmetic depends on the exact bytes they
are the exact bytes. The rule names in each directory's
`delta_rules_<lang>.h` and `delta_rules_shim_<lang>.c` are IBM's names,
because they are the names its own compiler left in the objects.

Everything else in a module has a text form beside it now -- `<lang>.globals`,
`<lang>.settings`, `<lang>.statements`, `<lang>.sets` and `<lang>.dict` -- and
each of those is that same data written another way rather than anything of
ours, so they are IBM's on the same terms as the C they regenerate.

The same rules are in `lang/<lang>/rules` as text: one operation to a line in
`.dr` files, what each wrapper stands for in `wrappers.up`, and a few of them
written again as what they do in the `.up` files beside. Those are
transcriptions of IBM's rules rather than anything said about them, so they are
IBM's too, and so is anything of IBM's copied byte for byte into
`rules/constants`. The tools that write and read all of it are in `tools` and
are ours. The language in front of every name is ours as well, and is there so
that two languages can be linked into one program.

A rule written for a language rather than transcribed out of an object is ours,
and `lang/plpl/rules/is_val.up` and `lang/plpl/rules/it_phone.up` are that:
the formant targets of sounds Italian has not got, and the letter-to-sound
rules for Polish's digraphs and for its own letters. What those rules name is
still IBM's -- a phoneme number, a statement type and the code the alphabet
gives a character are its numbering, and a byte in `lang/plpl/rules/constants`
that stands for one of those stands for a number of its -- but what the rules
say with them was written here. That does not soften the paragraph above:
everything else in that module is IBM's Italian until it has been replaced.

That data is IBM's work, not ours. The MIT licence does not cover it and we are
in no position to license it to anyone. The SDK it was read out of says as much
itself, in `doc/wxp/readme.txt`:

    Licensed Materials - Property of IBM
    (C) Copyright IBM Corp. 1999, 2004  All Rights Reserved.

It is in the tree because the engine cannot speak without it, and because a
build that first needed a 110 megabyte SDK from 2004 is a build almost nobody
would ever run. That is a deliberate choice about being useful, not a claim
about ownership.

If you mean to do more with this than read it and run it, the rights in that
data are yours to sort out with whoever holds them, and who that is today is
not simple. IBM published these objects. The engine underneath them was
Eloquence, by Eloquent Technology, which passed to SpeechWorks, then ScanSoft,
then Nuance, whose text-to-speech rights went to Cerence in the 2019 spinoff
and are now the subject of Cerence Inc. v. Microsoft Corporation and Nuance
Communications, Inc., D. Del. 1:25-cv-00553, filed 6 May 2025. None of this is
legal advice.

Where it came from
------------------

IBM's Embedded ViaVoice 4.3 SDK for Windows, which IBM still serves at

    https://public.dhe.ibm.com/software/pervasive/tools/viavoice/sdk/evvWXP.exe

`docs/building.md` says what to do with it, and every tool that reads it is in
`tools`, so anything under `lang` can be produced again from IBM's own file
rather than taken on trust.

Measured against
----------------

The Polish intonation numbers in `docs/status.md` were measured from FLEURS
(https://huggingface.co/datasets/google/fleurs), read speech published by
Google under CC BY 4.0, of which the Polish, US English and Italian
development sets were used. Neither its audio nor its text is in this
repository; what is here is the numbers derived from it and `tools/measure/pitch.py`,
which derived them.

Names
-----

IBM, ViaVoice and Embedded ViaVoice are trademarks of International Business
Machines Corporation. Eloquence is a trademark of its respective owner. This
project is not affiliated with, endorsed by or supported by IBM, Cerence,
Nuance, Microsoft or Apple.
