Number to Words and licencing

[Thomas Troesch]

On Fri, Nov 1, 2013 at 2:40 PM, John Ralls <jralls at ceridwen.fremont.ca.us>wrote:

>
> On Nov 1, 2013, at 11:14 AM, Thomas Troesch <ttroesch at gmail.com> wrote:
>
> > I have been looking at the list of open bugs for check printing.  Bug
> > 626001 asks for number to words based on locale.
> >
> > One approach would be to provide for locale specific plug-ins or code
> > paths.  For a programmer its a simple way to think about it, but I don't
> > know how well that would work with translators.
> >
> > I found some open source code that has a rule based parser to support
> > NLSnumber translations.  The rules themselves may be too much for the
> > typical
> > translator.
> >
> > Before I dig into it to see if it would work for checks ( looks promising
> > ), I'd like to have an opinion regarding license compatibility.
> >
> > From the web ( icu-project.org ):
> > "The ICU projects since ICU 1.8.1 and ICU4J 1.3.1 are covered by the ICU
> > license <http://source.icu-project.org/repos/icu/icu/trunk/license.html>
> ,
> > a simple, permissive non-copyleft free software license, compatible with
> > the GNU GPL.".  The license is at "
> http://source.icu-project.org/repos/icu/
> > icu/trunk/license.html".  The function that I'm interested in is
> described
> > at "RuleBasedNumberFormat" at the bottom of "http://userguide.icu-
> > project.org/formatparse/numbers".  Class documentation is at "
> http://icu-
> > project.org/apiref/icu4c/classRuleBasedNumberFormat.html".
> >
> > I have no intuition as to whether bringing in a lump of code like this
> > would make sense.  Opinions and insight welcome.
>
> The ICU license isn’t on the FSF-approved list [1], but it’s pretty close
> to
> the BOOST license [2], which is, and which is approved. However, it
> includes one
> extra clause that’s somewhat annoying: The requirement to document the
> copyright not only in the code but also in all supporting documentation.
> That
> sort of thing can get a bit onerous: See the FSF discussion about the
> original
> BSD license [3]. Compatibility [4] comes down to whether it’s OK to combine
> the work in question with a work released under the GPL, and if the authors
> say it is, I guess they know best.
>
> Lifting code out of other projects is asking for trouble: Either we become
> responsible for maintaining that new code or we have to expend significant
> effort to keep in sync with the original tree. Much better to make it a
> dependency and link it.
>
> That said, while I think we’re trying to reduce dependencies rather than
> add
> them, ICU is easily the best cross-platform FOSS I18N/L10N library
> available.
> It has one problem: Its translation facility is utterly incompatible with
> gettext, and gettext is what almost all FOSS translators are used to. That
> can
> be avoided by continuing to use gettext for translation and using ICU for
> everything else… but that’s perhaps a bit bigger job than what you’re
> willing
> to sign up for. OTOH it seems dumb to use ICU for just number->numeric text
> formatting.
>
> Regards,
> John Ralls
>
> [1] http://www.gnu.org/licenses/license-list.html
> [2] http://directory.fsf.org/wiki/License:Boost1.0
> [3] http://www.gnu.org/philosophy/bsd.html
> [4] http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible


John:

Thank you for your thoughtful response.

I had looked at ICU only for the purpose of number to words translation.  I
just now took the time to review the scope of what it addresses, and I see
how big a task it would be to incorporate ICU in general.  It seems to have
clear advantages, but its much more work than I can, or probably should,
do.  I'm not really familiar with NLS issues.  I took my very first look at
a .po file just to get an idea about how things work now.

I'm focused on NLS for printing checks, and all I know about it is from
http://en.wikipedia.org/wiki/Cheque .  Do you think it would be at all
practical to consider developing plug-ins for number to words based on
locale settings?  Developing translations would be a very different
process, but may be sufficiently interesting for some people.

Thomas