incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Licensing Issue
Date Thu, 25 Jun 2015 15:31:55 GMT
Ralph,
yes, you might have a good point there. But that should then raise another
angle.

Say that I have 2 plugins for a project, both with the same set of
features, and one is "recommended" and has ALv2, whereas the "optional" one
is LGPL. However, a majority (say everyone) chooses the LGPL plugin, say,
because it has a a simpler configuration system than the ALv2 one.

Now, does that fails the intent of the policy??

I would argue; No, because it would only show that people care more about
usability than about licensing.

Now, in this particular case Lewis says "not quite as good as KenLM in a
few key respects", which could mean a lot of things in reality. But, end of
the day, the user can make their choice, either they are Ok with the LGPL,
or they need to back down on some features. The alternative, as I see it,
is that the both the "LGPL is ok for me" users as well as the rest end up
with either the lesser featured LM, or possibly no Joshua project at all.

So, my question is; "What happened to pragmatism?"

Another analogy from the past; Some users refused to use Java, because it
wasn't open sourced back then. And we had a whole bunch of projects that
required a proprietary JDK to be useful to users. I would argue that this
was a much stronger case than Joshua's dilemma (face it, just about
everyone is ok with LGPL), yet ASF would have been a very different world
if Java wasn't allowed.

Cheers
Niclas

On Mon, Jun 22, 2015 at 1:19 PM, Ralph Goers <ralph.goers@dslextreme.com>
wrote:

> While this is all true, there is a key point in the policy that should be
> considered [1].
>
> “Will the majority of users want to use my product without adding the
> optional components”?
>
> So if a Language Module is required and BerkeleyLM is so substandard that
> no one will really use it, then you aren’t really achieving what the policy
> is saying.
>
>
> Ralph
>
> [1] - http://www.apache.org/legal/resolved.html#optional <
> http://www.apache.org/legal/resolved.html#optional>
> > On Jun 20, 2015, at 8:42 PM, Niclas Hedhman <niclas@hedhman.org> wrote:
> >
> > 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.dunning@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.mcgibbney@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
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message