As Ted is hinting, try to make a Joshua specific abstraction of the Language Module, and then provide N implementations. The KenLM implementation could be hosted outside ASF, in case Legal doesn't approve (can't recall the status of that) of using KenLM's published API, and users have to make the separate download of KenLM.
Painful, yes somewhat... But I think you could provide a script that does all the work, just make sure that the User is well-informed. Niclas On Sun, Jun 21, 2015 at 7:07 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: > Yes. That does sound like a blocker as it stands. > > Is there any prospect for relicensing? > > Is the BerkeleyLM package suitable for pulling into the Joshua project so > that KenLM becomes an optional dependency? > > > > On Sat, Jun 20, 2015 at 3:50 PM, Lewis John Mcgibbney < > lewis.mcgibb...@gmail.com> wrote: > > > Hi Folks, > > I am looking for some advice here. > > We are currently in conversation about potentially transitioning the > Joshua > > project [0] to the foundation. Our current conversation is ongoing at > [1]. > > From one of the key developers of Joshua, the following question has > arose; > > There is an issue with an LGPL'd library for handling language models > > (KenLM > > <https://github.com/kpu/kenlm>). There is an alternative (BerkeleyLM), > but > > it is not actively maintained any more and is not quite as good as KenLM > in > > a few key respects. A quick glance at the incubator page suggests that > this > > dependency would keep the project from becoming a full-fledged one. Can > you > > comment on this? > > Thanks for any input folks > > Lewis > > > > [0] http://joshua-decoder.org/ > > [1] https://github.com/joshua-decoder/joshua/issues/204 > > > > -- > > *Lewis* > > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
