Re: [Moses-support] Dual Licensing or relicensing Moses

[Tom Hoar]

My last message was based on labeling inside the Moses source. Based on 
the Moses home page http://statmt.org/moses page, "Moses is licensed 
under the LGPL." with a link to: http://www.gnu.org/licenses/lgpl.html. 
Moses is also a combined work, so section 4 "Combined Works" applies. 
Section 2 under that license states:



   2. Conveying Modified Versions.

   If you modify a copy of the Library, and, in your modifications, a
   facility refers to a function or data to be supplied by an
   Application that uses the facility (other than as an argument passed
   when the facility is invoked), then you may convey a copy of the
   modified version:

 * a) under this License, provided that you make a good faith
   effort to ensure that, in the event an Application does not
   supply the function or data, the facility still operates, and
   performs whatever part of its purpose remains meaningful, or
 * b) under the GNU GPL, with none of the additional permissions of
   this License applicable to that copy.

Lane, I agree that the copyright owner(s), and only the owners whoever 
they are, can agree to publish a module (like the tokenizer) under 
another license. In that case, a new fork is published under the new 
license but it does not revoke the master's original license. The two 
separate forks are simultaneously published and licensed separately. Any 
changes the owners make to the new fork must be applied regressively the 
master under the original license. Any changes made by any non-own to 
any fork must be republished under the respective license for that fork. 
Labeling a module with multiple license terms has been done, but creates 
huge complications. There are likely conflicts that, if it were 
contested, a court could invalidate all licensing.


Ken, ownership is tricky. It's governed by different sovereign laws. The 
laws in the USA are different than the laws in Thailand, which may be 
different from those in the UK. In most cases I know of, a contract's IP 
assignment clause declares who owns the work-for-hire. If ownership is 
not assigned in the contract, the respective law kicks in. The law in 
the USA assigns ownership to the author if the author is an independent 
contractor, and assigns ownership to the employer if the author is an 
employee. The law in Thailand is exactly the opposite. It assigns 
ownership to the employee if the author is an employee, and assigns 
ownership to the employer if the author is an independent contractor. I 
do not know the laws in the UK. The only clear path is to assign 
ownership in the work-for-hire contract. That's why I recommended that 
someone check with the University's intellectual property office.


All that said and regardless of ownership, you're safe to act on your 
own when you publish change under the license terms of the fork you 
changed. That's the heart-and-soul of open source licensing.


Tom




Date: Wed, 30 May 2018 04:03:05 +0800
From: liling tan
Subject: Re: [Moses-support] Dual Licensing or relicensing Moses
To: Matt Post
Cc: moses-support

Do note that I did receive a "no" from one of them so I'm not exactly sure
whether everyone's "yes" will change the "no".

Meanwhile, I think it's shouldn't be a problem since the Python port of
Moses' tokenizer does exist separately.
Users just have to make sure that they don't mix it up with more permissive
license when redistributing code.

Regards,
Liling


___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Dual Licensing or relicensing Moses

[liling tan]

Do note that I did receive a "no" from one of them so I'm not exactly sure
whether everyone's "yes" will change the "no".

Meanwhile, I think it's shouldn't be a problem since the Python port of
Moses' tokenizer does exist separately.
Users just have to make sure that they don't mix it up with more permissive
license when redistributing code.

Regards,
Liling

On Wed, May 30, 2018 at 3:59 AM, liling tan  wrote:

> Hi All,
>
> Multiple license for software components isn't impossible. If anyone tries
> to ship/package code with LGPL Moses tokenizer and detokenizer inside an
> MIT or Apache license software, it would be causing a license headache to
> their legal/IP colleagues.
>
> From NLTK perspective, I think it's easier for us to just take the code
> out and create a new repo for it at https://github.com/alvation
> s/sacremoses
>
> But I agree with Matt that if everyone that contributed give their
> consensus, there's no reason why the tokenizer can't be relicensed. Some of
> them have already given the OK and replied to previous threads. But to
> reach everyone I shall try BCC-ing all of them in this reply.
>
> For those who are BCC-ed and have already given their consent, thank you
> and sorry for re-receiving the request!
> For those who are BCC-ed, would you agree to allow the Python port of the
> Moses tokenizer to have MIT license instead of LGPL?
>
> Regards,
> Liling
>
>
> On Wed, May 30, 2018 at 3:00 AM, Matt Post  wrote:
>
>> Hi Lane,
>>
>> I'm not really involved with Moses or NLTK and never meant to take that
>> on personally. However, it still seems to me like a reasonable and
>> achievable goal.
>>
>> matt
>>
>>
>> On May 29, 2018, at 4:53 PM, Lane Schwartz  wrote:
>>
>> Matt,
>>
>> Did you ever track down the people who contributed to the tokenizer? It
>> seems like we should be able to dual license that script. It would be very
>> nice to be able to include the Moses tokenizer and detokenizer as part of
>> NLTK.
>>
>> Lane
>>
>>
>> On Fri, Apr 20, 2018 at 12:38 AM, liling tan  wrote:
>>
>>> Dear Moses Devs and Community,
>>>
>>> Sorry for the delayed response.
>>>
>>> We've repackaged the MosesTokenizer Python code as a library and made it
>>> pip-able.
>>> https://github.com/alvations/sacremoses
>>>
>>> I hope that's okay with the Moses community and the license compliance
>>> is good with this now.
>>>
>>> Regards,
>>> Liling
>>>
>>>
>>>
>>> On Wed, Apr 11, 2018 at 1:41 AM, Matt Post  wrote:
>>>
 Seems worth a shot. I suggest contacting each of them with individual
 emails until (and if) you get a “no”.

 matt (from my phone)

 Le 10 avr. 2018 à 19:26, liling tan  a écrit :

 @Matt I'm not sure whether that'll work.


 For tokenizer, that'll include:


- [image: @phikoehn] phikoehn 
- [image: @hieuhoang] hieuhoang 
- [image: @bhaddow] bhaddow 
- [image: @jimregan] jimregan 
- [image: @kpu] kpu 
- [image: @ugermann] ugermann 
- [image: @pjwilliams] pjwilliams 
- [image: @jgwinnup] jgwinnup 
- [image: @mhuck] mhuck 
- [image: @tofula] tofula 
- [image: @a455bcd9] a455bcd9 


 And these for the detokenizer:

 -
 [image: @phikoehn] phikoehn 
 - [image: @flammie] flammie 
 - [image: @hieuhoang] hieuhoang 
 - [image: @pjwilliams] pjwilliams 
 - [image: @bhaddow] bhaddow 
 - [image: @alvations] alvations 

 Not sure if everyone agrees though.

 Regards,
 Liling

 On Wed, Apr 11, 2018 at 12:39 AM, Matt Post  wrote:

> Liling—Would it work to get the permission of just those people who
> are in the commit log of the specific scripts you want to port?
>
> matt (from my phone)
>
> Le 10 avr. 2018 à 18:19, liling tan  a écrit :
>
> Got it.
>
> So I think we'll just remove the MosesTokenizer and MosesDetokenizer
> function from NLTK and maybe create a PR to put it in
> mosesdecoder/scripts/tokenizer
>
> Thank you for the clarification!
> Liling
>
> On Wed, Apr 11, 2018 at 12:17 AM, Hieu Hoang 
> wrote:
>
>> Still the same problem - everyone owns Moses so you need everyone's
>> permission, not just mine. So no
>>
>> Hieu Hoang
>> http://moses-smt.org/
>>
>>
>> On 10 April 2018 at 17:13, liling tan  wrote:
>>
>>> I understand.
>>>
>>> Could we have permission that it's okay to derive work f

Re: [Moses-support] Dual Licensing or relicensing Moses

[liling tan]

Hi All,

Multiple license for software components isn't impossible. If anyone tries
to ship/package code with LGPL Moses tokenizer and detokenizer inside an
MIT or Apache license software, it would be causing a license headache to
their legal/IP colleagues.

>From NLTK perspective, I think it's easier for us to just take the code out
and create a new repo for it at https://github.com/alvations/sacremoses

But I agree with Matt that if everyone that contributed give their
consensus, there's no reason why the tokenizer can't be relicensed. Some of
them have already given the OK and replied to previous threads. But to
reach everyone I shall try BCC-ing all of them in this reply.

For those who are BCC-ed and have already given their consent, thank you
and sorry for re-receiving the request!
For those who are BCC-ed, would you agree to allow the Python port of the
Moses tokenizer to have MIT license instead of LGPL?

Regards,
Liling


On Wed, May 30, 2018 at 3:00 AM, Matt Post  wrote:

> Hi Lane,
>
> I'm not really involved with Moses or NLTK and never meant to take that on
> personally. However, it still seems to me like a reasonable and achievable
> goal.
>
> matt
>
>
> On May 29, 2018, at 4:53 PM, Lane Schwartz  wrote:
>
> Matt,
>
> Did you ever track down the people who contributed to the tokenizer? It
> seems like we should be able to dual license that script. It would be very
> nice to be able to include the Moses tokenizer and detokenizer as part of
> NLTK.
>
> Lane
>
>
> On Fri, Apr 20, 2018 at 12:38 AM, liling tan  wrote:
>
>> Dear Moses Devs and Community,
>>
>> Sorry for the delayed response.
>>
>> We've repackaged the MosesTokenizer Python code as a library and made it
>> pip-able.
>> https://github.com/alvations/sacremoses
>>
>> I hope that's okay with the Moses community and the license compliance is
>> good with this now.
>>
>> Regards,
>> Liling
>>
>>
>>
>> On Wed, Apr 11, 2018 at 1:41 AM, Matt Post  wrote:
>>
>>> Seems worth a shot. I suggest contacting each of them with individual
>>> emails until (and if) you get a “no”.
>>>
>>> matt (from my phone)
>>>
>>> Le 10 avr. 2018 à 19:26, liling tan  a écrit :
>>>
>>> @Matt I'm not sure whether that'll work.
>>>
>>>
>>> For tokenizer, that'll include:
>>>
>>>
>>>- [image: @phikoehn] phikoehn 
>>>- [image: @hieuhoang] hieuhoang 
>>>- [image: @bhaddow] bhaddow 
>>>- [image: @jimregan] jimregan 
>>>- [image: @kpu] kpu 
>>>- [image: @ugermann] ugermann 
>>>- [image: @pjwilliams] pjwilliams 
>>>- [image: @jgwinnup] jgwinnup 
>>>- [image: @mhuck] mhuck 
>>>- [image: @tofula] tofula 
>>>- [image: @a455bcd9] a455bcd9 
>>>
>>>
>>> And these for the detokenizer:
>>>
>>> -
>>> [image: @phikoehn] phikoehn 
>>> - [image: @flammie] flammie 
>>> - [image: @hieuhoang] hieuhoang 
>>> - [image: @pjwilliams] pjwilliams 
>>> - [image: @bhaddow] bhaddow 
>>> - [image: @alvations] alvations 
>>>
>>> Not sure if everyone agrees though.
>>>
>>> Regards,
>>> Liling
>>>
>>> On Wed, Apr 11, 2018 at 12:39 AM, Matt Post  wrote:
>>>
 Liling—Would it work to get the permission of just those people who are
 in the commit log of the specific scripts you want to port?

 matt (from my phone)

 Le 10 avr. 2018 à 18:19, liling tan  a écrit :

 Got it.

 So I think we'll just remove the MosesTokenizer and MosesDetokenizer
 function from NLTK and maybe create a PR to put it in
 mosesdecoder/scripts/tokenizer

 Thank you for the clarification!
 Liling

 On Wed, Apr 11, 2018 at 12:17 AM, Hieu Hoang 
 wrote:

> Still the same problem - everyone owns Moses so you need everyone's
> permission, not just mine. So no
>
> Hieu Hoang
> http://moses-smt.org/
>
>
> On 10 April 2018 at 17:13, liling tan  wrote:
>
>> I understand.
>>
>> Could we have permission that it's okay to derive work from Moses
>> with respect to the (de-)tokenizer and possibly other scripts under an
>> MIT/Apache tool?
>>
>> Legally it's a restriction but I think for what's it worth, having
>> mutual agreement between the OSS is sufficient to still keep any port of
>> LGPL work until someone starts to enforce legal actions and I think it's
>> safe to back off to taking down these functionalities in the Apache/MIT
>> code.
>>
>> Regards,
>> Liling
>>
>> On Wed, Apr 11, 2018 at 12:09 AM, Hieu Hoang 
>> wrote:
>>
>>> we can

Re: [Moses-support] Dual Licensing or relicensing Moses

[Matt Post]

Hi Lane,

I'm not really involved with Moses or NLTK and never meant to take that on 
personally. However, it still seems to me like a reasonable and achievable goal.

matt

> On May 29, 2018, at 4:53 PM, Lane Schwartz  > wrote:
> 
> Matt,
> 
> Did you ever track down the people who contributed to the tokenizer? It seems 
> like we should be able to dual license that script. It would be very nice to 
> be able to include the Moses tokenizer and detokenizer as part of NLTK.
> 
> Lane
> 
> 
> On Fri, Apr 20, 2018 at 12:38 AM, liling tan  > wrote:
> Dear Moses Devs and Community,
> 
> Sorry for the delayed response. 
> 
> We've repackaged the MosesTokenizer Python code as a library and made it 
> pip-able.
> https://github.com/alvations/sacremoses 
> 
> 
> I hope that's okay with the Moses community and the license compliance is 
> good with this now.
> 
> Regards,
> Liling
> 
> 
> 
> On Wed, Apr 11, 2018 at 1:41 AM, Matt Post  > wrote:
> Seems worth a shot. I suggest contacting each of them with individual emails 
> until (and if) you get a “no”. 
> 
> matt (from my phone)
> 
> Le 10 avr. 2018 à 19:26, liling tan  > a écrit :
> 
>> @Matt I'm not sure whether that'll work.
>> 
>> 
>> For tokenizer, that'll include:
>>  
>>  phikoehn 
>>  hieuhoang 
>>  bhaddow 
>>  jimregan 
>>  kpu 
>>  ugermann 
>>  pjwilliams 
>>  jgwinnup 
>>  mhuck 
>>  tofula 
>>  a455bcd9 
>> 
>> And these for the detokenizer:
>> 
>> 
>>  phikoehn 
>>  flammie 
>>  hieuhoang 
>>  pjwilliams 
>>  bhaddow 
>>  alvations 
>> 
>> Not sure if everyone agrees though.
>> 
>> Regards,
>> Liling
>> 
>> On Wed, Apr 11, 2018 at 12:39 AM, Matt Post > > wrote:
>> Liling—Would it work to get the permission of just those people who are in 
>> the commit log of the specific scripts you want to port?
>> 
>> matt (from my phone)
>> 
>> Le 10 avr. 2018 à 18:19, liling tan > > a écrit :
>> 
>>> Got it. 
>>> 
>>> So I think we'll just remove the MosesTokenizer and MosesDetokenizer 
>>> function from NLTK and maybe create a PR to put it in 
>>> mosesdecoder/scripts/tokenizer 
>>> 
>>> Thank you for the clarification!
>>> Liling
>>> 
>>> On Wed, Apr 11, 2018 at 12:17 AM, Hieu Hoang >> > wrote:
>>> Still the same problem - everyone owns Moses so you need everyone's 
>>> permission, not just mine. So no
>>> 
>>> Hieu Hoang
>>> http://moses-smt.org/ 
>>> 
>>> 
>>> On 10 April 2018 at 17:13, liling tan >> > wrote:
>>> I understand. 
>>> 
>>> Could we have permission that it's okay to derive work from Moses with 
>>> respect to the (de-)tokenizer and possibly other scripts under an 
>>> MIT/Apache tool? 
>>> 
>>> Legally it's a restriction but I think for what's it worth, having mutual 
>>> agreement between the OSS is sufficient to still keep any port of LGPL work 
>>> until someone starts to enforce legal actions and I think it's safe to back 
>>> off to taking down these functionalities in the Apache/MIT code. 
>>> 
>>> Regards,
>>> Liling
>>> 
>>> On Wed, Apr 11, 2018 at 12:09 AM, Hieu Hoang >> > wrote:
>>> we can't change the license, or dual license it, without the agreement of 
>>> everyone who's contributed to Moses. Too much work 
>>> 
>>> Hieu Hoang
>>> http://moses-smt.org/ 
>>> 
>>> 
>>> On 10 April 2018 at 15:47, liling tan >> > wrote:
>>> Dear Moses Dev,
>>> 
>>> NLTK has a Python port of the word tokenizer in Moses. The tokenizer works 
>>> well in Python and create a good synergy to bridge Python users to the code 
>>> that Moses developers have spent years to hone. 
>>> 
>>> But it seemed to have hit a wall with some licensing issues. 
>>> https://github.com/nltk/nltk/issues/2000 
>>>  
>>> 
>>> General port of LGPL code is considered derivative and is incompatible with 
>>> Apache or MIT license. I understand that LGPL keeps derivative from being 
>>> proprietary but it's a little less permissive than non-copyleft license 
>>> like Apache and MIT licenses. 
>>> 
>>> Note that this licensing issue might also affect Marian which is MIT 
>>> license and also incompatible with LGPL so although technically users can 
>>> chain the code from different libraries, but Marian couldn't

Re: [Moses-support] Dual Licensing or relicensing Moses

[Kenneth Heafield]

Hi,

    Just to clarify that employees of the University of Edinburgh would
technically go to the university while PhD students keep the code they
write.  Our IP people won't mind if we authors choose to allow another
license. 

Kenneth


On 05/29/2018 11:03 AM, Lane Schwartz wrote:
> The source code's copyright IPR is the property of the University of
> Edinburgh. It's polite to track down the authors/contributors, but
> it's not necessary. The University's legal/intellectual property
> department is the authority and best source of information about
> licensing. 

___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Dual Licensing or relicensing Moses

[Lane Schwartz]

Tom,

Moses is licensed under LGPL. But if the contributors agree, there's no
reason that the tokenizer script can't also be simultaneously licensed
under Apache.

Most open source projects only have a single license, but there are
certainly cases where code is distributed under more than one license.

Lane


On Tue, May 29, 2018 at 10:27 AM, Tom Hoar  wrote:

> Hi Liling,
>
> I'm not sure what you mean by "dual licensing or re-license." Software is
> published under one license, which may or may not be compatible with other
> licenses. The Moses trunk is licensed under LGPL2.1, except those modules
> specifically republished under their respective licenses. My copy of
> tokenizer.perl script shows it's LGPL2.1. Under those terms, any changes to
> its code, if published, must be published under LGPL2.1 or newer. It looks
> to me like you've done that.
>
> You might have problems including a Python version of tokenizer.perl in
> NLTK because NLTK is licensed under the incompatible Apache License Version
> 2.0, at least according to this site, https://www.quora.com/What-
> are-the-major-differences-between-GNU-LGPL-v3-and-v2-1.
>
> The source code's copyright IPR is the property of the University of
> Edinburgh. It's polite to track down the authors/contributors, but it's not
> necessary. The University's legal/intellectual property department is the
> authority and best source of information about licensing.
>
> Tom
>
>
> On 5/29/2018 9:53 PM, moses-support-requ...@mit.edu wrote:
>
> Date: Tue, 29 May 2018 09:53:03 -0500
> From: Lane Schwartz  
> Subject: Re: [Moses-support] Dual Licensing or relicensing Moses
> To: liling tan  
> Cc: moses-support  
>
> Matt,
>
> Did you ever track down the people who contributed to the tokenizer? It
> seems like we should be able to dual license that script. It would be very
> nice to be able to include the Moses tokenizer and detokenizer as part of
> NLTK.
>
> Lane
>
>
> On Fri, Apr 20, 2018 at 12:38 AM, liling tan  
>  wrote:
>
>
> Dear Moses Devs and Community,
>
> Sorry for the delayed response.
>
> We've repackaged the MosesTokenizer Python code as a library and made it
> pip-able.https://github.com/alvations/sacremoses
>
> I hope that's okay with the Moses community and the license compliance is
> good with this now.
>
> Regards,
> Liling
>
>
>
>
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>


-- 
When a place gets crowded enough to require ID's, social collapse is not
far away.  It is time to go elsewhere.  The best thing about space travel
is that it made it possible to go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Dual Licensing or relicensing Moses

[Tom Hoar]

Hi Liling,

I'm not sure what you mean by "dual licensing or re-license." Software 
is published under one license, which may or may not be compatible with 
other licenses. The Moses trunk is licensed under LGPL2.1, except those 
modules specifically republished under their respective licenses. My 
copy of tokenizer.perl script shows it's LGPL2.1. Under those terms, any 
changes to its code, if published, must be published under LGPL2.1 or 
newer. It looks to me like you've done that.


You might have problems including a Python version of tokenizer.perl in 
NLTK because NLTK is licensed under the incompatible Apache License 
Version 2.0, at least according to this site, 
https://www.quora.com/What-are-the-major-differences-between-GNU-LGPL-v3-and-v2-1.


The source code's copyright IPR is the property of the University of 
Edinburgh. It's polite to track down the authors/contributors, but it's 
not necessary. The University's legal/intellectual property department 
is the authority and best source of information about licensing.


Tom


On 5/29/2018 9:53 PM, moses-support-requ...@mit.edu wrote:

Date: Tue, 29 May 2018 09:53:03 -0500
From: Lane Schwartz
Subject: Re: [Moses-support] Dual Licensing or relicensing Moses
To: liling tan
Cc: moses-support

Matt,

Did you ever track down the people who contributed to the tokenizer? It
seems like we should be able to dual license that script. It would be very
nice to be able to include the Moses tokenizer and detokenizer as part of
NLTK.

Lane


On Fri, Apr 20, 2018 at 12:38 AM, liling tan  wrote:


Dear Moses Devs and Community,

Sorry for the delayed response.

We've repackaged the MosesTokenizer Python code as a library and made it
pip-able.
https://github.com/alvations/sacremoses

I hope that's okay with the Moses community and the license compliance is
good with this now.

Regards,
Liling



___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Dual Licensing or relicensing Moses

[Lane Schwartz]

Matt,

Did you ever track down the people who contributed to the tokenizer? It
seems like we should be able to dual license that script. It would be very
nice to be able to include the Moses tokenizer and detokenizer as part of
NLTK.

Lane


On Fri, Apr 20, 2018 at 12:38 AM, liling tan  wrote:

> Dear Moses Devs and Community,
>
> Sorry for the delayed response.
>
> We've repackaged the MosesTokenizer Python code as a library and made it
> pip-able.
> https://github.com/alvations/sacremoses
>
> I hope that's okay with the Moses community and the license compliance is
> good with this now.
>
> Regards,
> Liling
>
>
>
> On Wed, Apr 11, 2018 at 1:41 AM, Matt Post  wrote:
>
>> Seems worth a shot. I suggest contacting each of them with individual
>> emails until (and if) you get a “no”.
>>
>> matt (from my phone)
>>
>> Le 10 avr. 2018 à 19:26, liling tan  a écrit :
>>
>> @Matt I'm not sure whether that'll work.
>>
>>
>> For tokenizer, that'll include:
>>
>>
>>- [image: @phikoehn] phikoehn 
>>- [image: @hieuhoang] hieuhoang 
>>- [image: @bhaddow] bhaddow 
>>- [image: @jimregan] jimregan 
>>- [image: @kpu] kpu 
>>- [image: @ugermann] ugermann 
>>- [image: @pjwilliams] pjwilliams 
>>- [image: @jgwinnup] jgwinnup 
>>- [image: @mhuck] mhuck 
>>- [image: @tofula] tofula 
>>- [image: @a455bcd9] a455bcd9 
>>
>>
>> And these for the detokenizer:
>>
>> -
>> [image: @phikoehn] phikoehn 
>> - [image: @flammie] flammie 
>> - [image: @hieuhoang] hieuhoang 
>> - [image: @pjwilliams] pjwilliams 
>> - [image: @bhaddow] bhaddow 
>> - [image: @alvations] alvations 
>>
>> Not sure if everyone agrees though.
>>
>> Regards,
>> Liling
>>
>> On Wed, Apr 11, 2018 at 12:39 AM, Matt Post  wrote:
>>
>>> Liling—Would it work to get the permission of just those people who are
>>> in the commit log of the specific scripts you want to port?
>>>
>>> matt (from my phone)
>>>
>>> Le 10 avr. 2018 à 18:19, liling tan  a écrit :
>>>
>>> Got it.
>>>
>>> So I think we'll just remove the MosesTokenizer and MosesDetokenizer
>>> function from NLTK and maybe create a PR to put it in
>>> mosesdecoder/scripts/tokenizer
>>>
>>> Thank you for the clarification!
>>> Liling
>>>
>>> On Wed, Apr 11, 2018 at 12:17 AM, Hieu Hoang 
>>> wrote:
>>>
 Still the same problem - everyone owns Moses so you need everyone's
 permission, not just mine. So no

 Hieu Hoang
 http://moses-smt.org/


 On 10 April 2018 at 17:13, liling tan  wrote:

> I understand.
>
> Could we have permission that it's okay to derive work from Moses with
> respect to the (de-)tokenizer and possibly other scripts under an
> MIT/Apache tool?
>
> Legally it's a restriction but I think for what's it worth, having
> mutual agreement between the OSS is sufficient to still keep any port of
> LGPL work until someone starts to enforce legal actions and I think it's
> safe to back off to taking down these functionalities in the Apache/MIT
> code.
>
> Regards,
> Liling
>
> On Wed, Apr 11, 2018 at 12:09 AM, Hieu Hoang 
> wrote:
>
>> we can't change the license, or dual license it, without the
>> agreement of everyone who's contributed to Moses. Too much work
>>
>> Hieu Hoang
>> http://moses-smt.org/
>>
>>
>> On 10 April 2018 at 15:47, liling tan  wrote:
>>
>>> Dear Moses Dev,
>>>
>>> NLTK has a Python port of the word tokenizer in Moses. The tokenizer
>>> works well in Python and create a good synergy to bridge Python users to
>>> the code that Moses developers have spent years to hone.
>>>
>>> But it seemed to have hit a wall with some licensing issues.
>>> https://github.com/nltk/nltk/issues/2000
>>>
>>> General port of LGPL code is considered derivative and is
>>> incompatible with Apache or MIT license. I understand that LGPL keeps
>>> derivative from being proprietary but it's a little less permissive than
>>> non-copyleft license like Apache and MIT licenses.
>>>
>>> Note that this licensing issue might also affect Marian which is MIT
>>> license and also incompatible with LGPL so although technically users 
>>> can
>>> chain the code from different libraries, but Marian couldn't have any
>>> dependencies on the Moses components. (But we know do know that none of 
>>> our
>>> models built with Marian would work without the Moses tokenizer which 
>>> is in