incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@apache.org>
Subject Re: Update on Apache Toree and LGPL dependency
Date Sun, 06 Mar 2016 05:42:51 GMT
Having chatted around the 0mq community in the past; I've confidence in
their desire to move to MPL; and 26/32 committers is a great step forward.
You raise a good reservation though John - if you remove the blocker on the
usage side, it's easy for the licensing to remain as is.


I'm +1 for releasing, with a prominent note of the LGPL dependency (along
with a note of the resolution plan). It might be that the Toree committers
may be motivated to rewrite code over at 0mq if there ends up being any
committers who are unavailable or unwilling to relicense.

Hen

On Sat, Mar 5, 2016 at 3:45 PM, John D. Ament <johndament@apache.org> wrote:

> Sorry, misread the revision I was looking at.  The intent to move to MPL
> was done on March 22 2014, 2 years ago this month, not December 2013.
>
> John
>
> On Sat, Mar 5, 2016 at 6:41 PM John D. Ament <johndament@apache.org>
> wrote:
>
> > I have some reservations with what you're proposing, and would like you
> to
> > consult w/ legal-discuss on this first.
> >
> > There's a difference between what Mynewt did and what you're proposing.
> > Specifically, this was a transitive dependency that they relied upon
> > indirectly, so its more of a call out for the library that was leveraging
> > it.  They also intended to replace the library.
> >
> > In your case, you're directly tied to a presently LGPL'd library.  You
> > have no intentions (from what I can see) of moving off of the library.
> >
> > I'm also doubting their long term goals of moving to MPL.  If you look at
> > [1], you'll see that the page hasn't been updated since October 2014.  In
> > addition, looking at the pages revision history (the beauty of wikis),
> the
> > intent to move to MPL was published in December 2013, making the
> statement
> > over 2 years old.
> >
> > I think while this might be OK for an initial incubator release, the
> > project needs to weigh very heavily if it wants to continue to leverage
> > ZeroMQ or not going forward.
> >
> > [1]: http://zeromq.org/area:licensing
> >
> >
> > On Sat, Mar 5, 2016 at 5:06 PM Gino Bustelo <gino@bustelos.com> wrote:
> >
> >> Wanted to give folks an update on our progress with dealing with JeroMQ,
> >> an
> >> LGPL package that enables us to communicate via 0MQ. The 0MQ community
> is
> >> very aware of the issues with LGPL (LGPLv3 + static link exception) and
> it
> >> is their intention to try to move projects to MPL v2. This is not an
> easy
> >> task depending on the age and size of the projects.
> >>
> >> Apache Toree's API access point is through the 0MQ transport layer
> (using
> >> JeroMQ) and that is how Apache Toree connects out-of-the-box with
> Jupyter,
> >> a very common way of consuming Apache Toree that is already in
> production.
> >>
> >> At this point, the JeroMQ project is still released under LGPL, but our
> >> team initiated communications in mid-February with members of the JeroMQ
> >> community to begin their transition to MPL v2 (
> >> https://github.com/zeromq/jeromq/issues/326). The JeroMQ community
> >> reacted
> >> very positively and quickly began the process of collecting votes from
> >> their committers (https://github.com/zeromq/jeromq/issues/327). After
> 15
> >> days, the current tally stands at 26 out of 32 committers have agreed to
> >> switch license.
> >>
> >> Apache Toree has a JIRA (
> https://issues.apache.org/jira/browse/TOREE-262)
> >> where we keep all the relevant links and update with the latest
> >> information. As that process is underway, we will move forward with
> plans
> >> to release a 0.1.0 version of Apache Toree based on the precedence set
> by
> >> Apache Mynewt (
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
> >> ).
> >>
> >> Thanks,
> >> Gino
> >>
> >
>

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