You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Gino Bustelo <gi...@bustelos.com> on 2016/05/19 17:30:13 UTC
Toree's One Release Constraint
I write this to start a discussion about the "One release constraint"
placed on Toree and what I feel is an unreasonable constraint on a project
that is undergoing incubation. A brief background first...
In Toree we have an LGPL dependency that is not a simple rip an replace.
The library is JeroMQ and it is a JVM binding to 0MQ. This is THE protocol
layer used in Jupyter between clients and kernels (Toree serves as a
Jupyter kernel). Over the past months, we've worked with the JeroMQ
community to help move along a license change to MPL v2 (
https://github.com/zeromq/jeromq/issues/327). The progress showed huge
promised at the start and we are down to 3 committers out of 31 who have
not responded. The JeroMQ community is moving towards code remediation.
In my opinion, this effort shows great inter-OS community cooperation and
something that should be valued by Apache. Why rewrite and maintain code
that already exist? Why not allow the process to take place? Isn't that
what the incubation period is for? Allow projects to resolve concerns
before they graduate?
So my question is, why one release? This has been our biggest impediment in
putting an official incubation release out. We are ready. We have all the
disclaimer in place alerting the user that Toree contains LGPL code. The
biggest concern is releasing and discovering a defect that we would not be
able to fix due to the "One release constraint".
Again... I just wish to start the discussion and find a resolution that
will allow Toree to properly grow and move forward with its incubation.
Thanks,
Gino
Re: Toree's One Release Constraint
Posted by Edward Capriolo <ed...@gmail.com>.
Yes this is the other benefit to abstracting an API. You can mock test with
the API or provide a drop in replacement if once exists. IE I do not
integration tests Java projects using mysql, I use h2 or derby.
On Fri, May 20, 2016 at 2:17 PM, Shankar Venkataraman <
shankarvenkataraman666@gmail.com> wrote:
> In addition, if the LGPL (or a less open licensing) dependency makes it
> hard to set up and run automated tests on an ongoing basis, it does nullify
> the spirit of the one release doctrine. To honor the doctrine may lead to
> painful refactoring, but I do think it is essential for Toree to be truly
> open.
>
> Shankar
>
>
>
> On Fri, 20 May 2016 at 09:42 Alex Harui <ah...@adobe.com> wrote:
>
> >
> >
> > On 5/20/16, 9:32 AM, "Edward Capriolo" <ed...@gmail.com> wrote:
> >
> > >Yes if you are using a feature specific to a specific product it is
> > >obvious
> > >even if you wrap cruft around it. however when I see something that uses
> > >"rabbit mq" i generally think to wrap an interface around it so I can
> > >replace with Apache Kafka :).I am wondering if the same be done here.
> >
> > Interface abstraction might be a good engineering design decision, but it
> > won't affect the perceived LPGL dependency if a significant number of
> your
> > users must bring down an LPGL dependency in order to have a satisfactory
> > solution. It isn't whether they "can" replace RabbitMQ with Apache
> Kafka,
> > it is whether they will.
> >
> > -Alex
> >
> >
>
Re: Toree's One Release Constraint
Posted by Shankar Venkataraman <sh...@gmail.com>.
In addition, if the LGPL (or a less open licensing) dependency makes it
hard to set up and run automated tests on an ongoing basis, it does nullify
the spirit of the one release doctrine. To honor the doctrine may lead to
painful refactoring, but I do think it is essential for Toree to be truly
open.
Shankar
On Fri, 20 May 2016 at 09:42 Alex Harui <ah...@adobe.com> wrote:
>
>
> On 5/20/16, 9:32 AM, "Edward Capriolo" <ed...@gmail.com> wrote:
>
> >Yes if you are using a feature specific to a specific product it is
> >obvious
> >even if you wrap cruft around it. however when I see something that uses
> >"rabbit mq" i generally think to wrap an interface around it so I can
> >replace with Apache Kafka :).I am wondering if the same be done here.
>
> Interface abstraction might be a good engineering design decision, but it
> won't affect the perceived LPGL dependency if a significant number of your
> users must bring down an LPGL dependency in order to have a satisfactory
> solution. It isn't whether they "can" replace RabbitMQ with Apache Kafka,
> it is whether they will.
>
> -Alex
>
>
Re: Toree's One Release Constraint
Posted by Alex Harui <ah...@adobe.com>.
On 5/20/16, 9:32 AM, "Edward Capriolo" <ed...@gmail.com> wrote:
>Yes if you are using a feature specific to a specific product it is
>obvious
>even if you wrap cruft around it. however when I see something that uses
>"rabbit mq" i generally think to wrap an interface around it so I can
>replace with Apache Kafka :).I am wondering if the same be done here.
Interface abstraction might be a good engineering design decision, but it
won't affect the perceived LPGL dependency if a significant number of your
users must bring down an LPGL dependency in order to have a satisfactory
solution. It isn't whether they "can" replace RabbitMQ with Apache Kafka,
it is whether they will.
-Alex
Re: Toree's One Release Constraint
Posted by Edward Capriolo <ed...@gmail.com>.
Yes if you are using a feature specific to a specific product it is obvious
even if you wrap cruft around it. however when I see something that uses
"rabbit mq" i generally think to wrap an interface around it so I can
replace with Apache Kafka :).I am wondering if the same be done here.
On Fri, May 20, 2016 at 12:03 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 5/20/16, 8:57 AM, "Edward Capriolo" <ed...@gmail.com> wrote:
>
> >" You could argue that it makes the dependency optional"
> >Yes that is what I am saying. Like in a JDBC application you may be
> >connecting to postgres or mysql you are not concerned how those are
> >licensed because you are linked to the shim/driver. You could even bring
> >in
> >the Microsoft SQL server as a jar in this case.
>
> Right. Then, AIUI, the test is about "will" not "could". What "will"
> the majority of your customer do? If reality is that they will bring down
> the LGPL implementation you have not truly passed the "optional" test.
> The uber goal is to get away from having customers of Apache products
> worry about LGPL and other unfriendly licenses ending up on their system.
>
> -Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: Toree's One Release Constraint
Posted by Alex Harui <ah...@adobe.com>.
On 5/20/16, 8:57 AM, "Edward Capriolo" <ed...@gmail.com> wrote:
>" You could argue that it makes the dependency optional"
>Yes that is what I am saying. Like in a JDBC application you may be
>connecting to postgres or mysql you are not concerned how those are
>licensed because you are linked to the shim/driver. You could even bring
>in
>the Microsoft SQL server as a jar in this case.
Right. Then, AIUI, the test is about "will" not "could". What "will"
the majority of your customer do? If reality is that they will bring down
the LGPL implementation you have not truly passed the "optional" test.
The uber goal is to get away from having customers of Apache products
worry about LGPL and other unfriendly licenses ending up on their system.
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Toree's One Release Constraint
Posted by Edward Capriolo <ed...@gmail.com>.
" You could argue that it makes the dependency optional"
Yes that is what I am saying. Like in a JDBC application you may be
connecting to postgres or mysql you are not concerned how those are
licensed because you are linked to the shim/driver. You could even bring in
the Microsoft SQL server as a jar in this case.
On Fri, May 20, 2016 at 11:21 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 5/20/16, 7:23 AM, "Edward Capriolo" <ed...@gmail.com> wrote:
>
> >Would it be acceptable to develop a shim layer toree can link to that and
> >the provider is dropped in at runtime like the jdbc interface?
>
> AIUI, a shim doesn't break the dependency chain. You could argue that it
> makes the dependency optional, but then the test becomes whether the
> majority of your users will end up downloading the LPGL version anyway.
> IMO, the mentors should help you advocate for a second exception to the
> rule.
>
> HTH,
> -Alex
>
>
Re: Toree's One Release Constraint
Posted by Alex Harui <ah...@adobe.com>.
On 5/20/16, 7:23 AM, "Edward Capriolo" <ed...@gmail.com> wrote:
>Would it be acceptable to develop a shim layer toree can link to that and
>the provider is dropped in at runtime like the jdbc interface?
AIUI, a shim doesn't break the dependency chain. You could argue that it
makes the dependency optional, but then the test becomes whether the
majority of your users will end up downloading the LPGL version anyway.
IMO, the mentors should help you advocate for a second exception to the
rule.
HTH,
-Alex
Re: Toree's One Release Constraint
Posted by Edward Capriolo <ed...@gmail.com>.
Would it be acceptable to develop a shim layer toree can link to that and
the provider is dropped in at runtime like the jdbc interface?
On Thursday, May 19, 2016, Craig Russell <cr...@oracle.com> wrote:
> I found Jim’s message from February 24 in which he says that for one
> release, he’s ok with having the LGPL dependency.
>
> Given that substantial progress has been made and continues to be made on
> getting the dependency relicensed, I expect that asking for permission for
> another release in the incubator with the same LGPL dependency should also
> be granted.
>
> Craig
>
> > On May 19, 2016, at 12:04 PM, Gino Bustelo <gino@bustelos.com
> <javascript:;>> wrote:
> >
> > "one release constraint" as in we can only have one release with the LGPL
> > dependency. No other release until that dependency is resolved.
> >
> > On Thu, May 19, 2016 at 1:33 PM, Mike Jumper <mike.jumper@guac-dev.org
> <javascript:;>>
> > wrote:
> >
> >> On May 19, 2016 10:30 AM, "Gino Bustelo" <gino@bustelos.com
> <javascript:;>> wrote:
> >>>
> >>> I write this to start a discussion about the "One release constraint"
> >>> placed on Toree and what I feel is an unreasonable constraint on a
> >> project
> >>> that is undergoing incubation. A brief background first...
> >>>
> >>> In Toree we have an LGPL dependency that is not a simple rip an
> replace.
> >>> The library is JeroMQ and it is a JVM binding to 0MQ. This is THE
> >> protocol
> >>> layer used in Jupyter between clients and kernels (Toree serves as a
> >>> Jupyter kernel). Over the past months, we've worked with the JeroMQ
> >>> community to help move along a license change to MPL v2 (
> >>> https://github.com/zeromq/jeromq/issues/327). The progress showed huge
> >>> promised at the start and we are down to 3 committers out of 31 who
> have
> >>> not responded. The JeroMQ community is moving towards code remediation.
> >>>
> >>> In my opinion, this effort shows great inter-OS community cooperation
> and
> >>> something that should be valued by Apache. Why rewrite and maintain
> code
> >>> that already exist? Why not allow the process to take place? Isn't that
> >>> what the incubation period is for? Allow projects to resolve concerns
> >>> before they graduate?
> >>>
> >>> So my question is, why one release? This has been our biggest
> impediment
> >> in
> >>> putting an official incubation release out. We are ready. We have all
> the
> >>> disclaimer in place alerting the user that Toree contains LGPL code.
> The
> >>> biggest concern is releasing and discovering a defect that we would not
> >> be
> >>> able to fix due to the "One release constraint".
> >>>
> >>> Again... I just wish to start the discussion and find a resolution that
> >>> will allow Toree to properly grow and move forward with its incubation.
> >>>
> >>> Thanks,
> >>> Gino
> >>
> >> Hi Gino,
> >>
> >> What "one release constraint" are you referring to?
> >>
> >> Thanks,
> >>
> >> - Mike
> >>
>
> Craig L Russell
> Architect
> craig.russell@oracle.com <javascript:;>
> P.S. A good JDO? O, Gasp!
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>
>
--
Sorry this was sent from mobile. Will do less grammar and spell check than
usual.
Re: Toree's One Release Constraint
Posted by Craig Russell <cr...@oracle.com>.
I found Jim’s message from February 24 in which he says that for one release, he’s ok with having the LGPL dependency.
Given that substantial progress has been made and continues to be made on getting the dependency relicensed, I expect that asking for permission for another release in the incubator with the same LGPL dependency should also be granted.
Craig
> On May 19, 2016, at 12:04 PM, Gino Bustelo <gi...@bustelos.com> wrote:
>
> "one release constraint" as in we can only have one release with the LGPL
> dependency. No other release until that dependency is resolved.
>
> On Thu, May 19, 2016 at 1:33 PM, Mike Jumper <mi...@guac-dev.org>
> wrote:
>
>> On May 19, 2016 10:30 AM, "Gino Bustelo" <gi...@bustelos.com> wrote:
>>>
>>> I write this to start a discussion about the "One release constraint"
>>> placed on Toree and what I feel is an unreasonable constraint on a
>> project
>>> that is undergoing incubation. A brief background first...
>>>
>>> In Toree we have an LGPL dependency that is not a simple rip an replace.
>>> The library is JeroMQ and it is a JVM binding to 0MQ. This is THE
>> protocol
>>> layer used in Jupyter between clients and kernels (Toree serves as a
>>> Jupyter kernel). Over the past months, we've worked with the JeroMQ
>>> community to help move along a license change to MPL v2 (
>>> https://github.com/zeromq/jeromq/issues/327). The progress showed huge
>>> promised at the start and we are down to 3 committers out of 31 who have
>>> not responded. The JeroMQ community is moving towards code remediation.
>>>
>>> In my opinion, this effort shows great inter-OS community cooperation and
>>> something that should be valued by Apache. Why rewrite and maintain code
>>> that already exist? Why not allow the process to take place? Isn't that
>>> what the incubation period is for? Allow projects to resolve concerns
>>> before they graduate?
>>>
>>> So my question is, why one release? This has been our biggest impediment
>> in
>>> putting an official incubation release out. We are ready. We have all the
>>> disclaimer in place alerting the user that Toree contains LGPL code. The
>>> biggest concern is releasing and discovering a defect that we would not
>> be
>>> able to fix due to the "One release constraint".
>>>
>>> Again... I just wish to start the discussion and find a resolution that
>>> will allow Toree to properly grow and move forward with its incubation.
>>>
>>> Thanks,
>>> Gino
>>
>> Hi Gino,
>>
>> What "one release constraint" are you referring to?
>>
>> Thanks,
>>
>> - Mike
>>
Craig L Russell
Architect
craig.russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Toree's One Release Constraint
Posted by Gino Bustelo <gi...@bustelos.com>.
"one release constraint" as in we can only have one release with the LGPL
dependency. No other release until that dependency is resolved.
On Thu, May 19, 2016 at 1:33 PM, Mike Jumper <mi...@guac-dev.org>
wrote:
> On May 19, 2016 10:30 AM, "Gino Bustelo" <gi...@bustelos.com> wrote:
> >
> > I write this to start a discussion about the "One release constraint"
> > placed on Toree and what I feel is an unreasonable constraint on a
> project
> > that is undergoing incubation. A brief background first...
> >
> > In Toree we have an LGPL dependency that is not a simple rip an replace.
> > The library is JeroMQ and it is a JVM binding to 0MQ. This is THE
> protocol
> > layer used in Jupyter between clients and kernels (Toree serves as a
> > Jupyter kernel). Over the past months, we've worked with the JeroMQ
> > community to help move along a license change to MPL v2 (
> > https://github.com/zeromq/jeromq/issues/327). The progress showed huge
> > promised at the start and we are down to 3 committers out of 31 who have
> > not responded. The JeroMQ community is moving towards code remediation.
> >
> > In my opinion, this effort shows great inter-OS community cooperation and
> > something that should be valued by Apache. Why rewrite and maintain code
> > that already exist? Why not allow the process to take place? Isn't that
> > what the incubation period is for? Allow projects to resolve concerns
> > before they graduate?
> >
> > So my question is, why one release? This has been our biggest impediment
> in
> > putting an official incubation release out. We are ready. We have all the
> > disclaimer in place alerting the user that Toree contains LGPL code. The
> > biggest concern is releasing and discovering a defect that we would not
> be
> > able to fix due to the "One release constraint".
> >
> > Again... I just wish to start the discussion and find a resolution that
> > will allow Toree to properly grow and move forward with its incubation.
> >
> > Thanks,
> > Gino
>
> Hi Gino,
>
> What "one release constraint" are you referring to?
>
> Thanks,
>
> - Mike
>
Re: Toree's One Release Constraint
Posted by Mike Jumper <mi...@guac-dev.org>.
On May 19, 2016 10:30 AM, "Gino Bustelo" <gi...@bustelos.com> wrote:
>
> I write this to start a discussion about the "One release constraint"
> placed on Toree and what I feel is an unreasonable constraint on a project
> that is undergoing incubation. A brief background first...
>
> In Toree we have an LGPL dependency that is not a simple rip an replace.
> The library is JeroMQ and it is a JVM binding to 0MQ. This is THE protocol
> layer used in Jupyter between clients and kernels (Toree serves as a
> Jupyter kernel). Over the past months, we've worked with the JeroMQ
> community to help move along a license change to MPL v2 (
> https://github.com/zeromq/jeromq/issues/327). The progress showed huge
> promised at the start and we are down to 3 committers out of 31 who have
> not responded. The JeroMQ community is moving towards code remediation.
>
> In my opinion, this effort shows great inter-OS community cooperation and
> something that should be valued by Apache. Why rewrite and maintain code
> that already exist? Why not allow the process to take place? Isn't that
> what the incubation period is for? Allow projects to resolve concerns
> before they graduate?
>
> So my question is, why one release? This has been our biggest impediment
in
> putting an official incubation release out. We are ready. We have all the
> disclaimer in place alerting the user that Toree contains LGPL code. The
> biggest concern is releasing and discovering a defect that we would not be
> able to fix due to the "One release constraint".
>
> Again... I just wish to start the discussion and find a resolution that
> will allow Toree to properly grow and move forward with its incubation.
>
> Thanks,
> Gino
Hi Gino,
What "one release constraint" are you referring to?
Thanks,
- Mike
Re: Toree's One Release Constraint
Posted by Luciano Resende <lu...@gmail.com>.
As we have to add a DISCLAIMER file with incubation details, I would add a
DISCLAIMER-LGPL to make it more visible then embedded in the middle of the
README.md.
On Fri, May 20, 2016 at 12:56 PM, Gino Bustelo <gi...@bustelos.com> wrote:
> @shane
>
> As part of building, we put together a more comprehensive LICENSE and
> NOTICE file that includes the extra information under
>
> https://github.com/apache/incubator-toree/blob/master/etc/legal/LICENSE_extras
> .
> The installer of the pip package prints out the LGPL disclaimer during
> installation. We could certainly also place a more prominent statement in
> the README. The website is still under development and we can also provide
> a disclaimer there. I take any other recommendations.
>
>
>
> On Fri, May 20, 2016 at 2:37 PM, Shane Curcuru <as...@shanecurcuru.org>
> wrote:
>
> > Gino Bustelo wrote on 5/19/16 12:30 PM:
> > ...
> > > In Toree we have an LGPL dependency that is not a simple rip an
> replace.
> > > The library is JeroMQ and it is a JVM binding to 0MQ. This is THE
> > protocol
> > > layer used in Jupyter between clients and kernels (Toree serves as a
> > > Jupyter kernel). Over the past months, we've worked with the JeroMQ
> > > community to help move along a license change to MPL v2 (
> > > https://github.com/zeromq/jeromq/issues/327). The progress showed huge
> > > promised at the start and we are down to 3 committers out of 31 who
> have
> > > not responded. The JeroMQ community is moving towards code remediation.
> >
> > If LGPL code is included either in your source tree or in your existing
> > release(s), why isn't that reflected in a top-level LICENSE and NOTICE
> > file?
> >
> > From reading the homepage of the website and quickly browsing the source
> > tree, the only reference is in DISCLAIMER, which is awfully small. It
> > wasn't obvious to me besides that tiny bit that you include some LGPL
> code.
> >
> > Or am I missing how this dependency works?
> >
> > Yes, I agree that incubation is a process, and there is great progress
> > both here and in the other project towards an Apache-license-harmonious
> > outcome. But we need to be very careful that end-users have a
> > crystal-clear understanding that there is copyleft style licenses in
> > releases or dependencies of anything at Apache.
> >
> > - Shane
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
--
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Toree's One Release Constraint
Posted by Gino Bustelo <gi...@bustelos.com>.
@shane
As part of building, we put together a more comprehensive LICENSE and
NOTICE file that includes the extra information under
https://github.com/apache/incubator-toree/blob/master/etc/legal/LICENSE_extras.
The installer of the pip package prints out the LGPL disclaimer during
installation. We could certainly also place a more prominent statement in
the README. The website is still under development and we can also provide
a disclaimer there. I take any other recommendations.
On Fri, May 20, 2016 at 2:37 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> Gino Bustelo wrote on 5/19/16 12:30 PM:
> ...
> > In Toree we have an LGPL dependency that is not a simple rip an replace.
> > The library is JeroMQ and it is a JVM binding to 0MQ. This is THE
> protocol
> > layer used in Jupyter between clients and kernels (Toree serves as a
> > Jupyter kernel). Over the past months, we've worked with the JeroMQ
> > community to help move along a license change to MPL v2 (
> > https://github.com/zeromq/jeromq/issues/327). The progress showed huge
> > promised at the start and we are down to 3 committers out of 31 who have
> > not responded. The JeroMQ community is moving towards code remediation.
>
> If LGPL code is included either in your source tree or in your existing
> release(s), why isn't that reflected in a top-level LICENSE and NOTICE
> file?
>
> From reading the homepage of the website and quickly browsing the source
> tree, the only reference is in DISCLAIMER, which is awfully small. It
> wasn't obvious to me besides that tiny bit that you include some LGPL code.
>
> Or am I missing how this dependency works?
>
> Yes, I agree that incubation is a process, and there is great progress
> both here and in the other project towards an Apache-license-harmonious
> outcome. But we need to be very careful that end-users have a
> crystal-clear understanding that there is copyleft style licenses in
> releases or dependencies of anything at Apache.
>
> - Shane
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Toree's One Release Constraint
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Gino Bustelo wrote on 5/19/16 12:30 PM:
...
> In Toree we have an LGPL dependency that is not a simple rip an replace.
> The library is JeroMQ and it is a JVM binding to 0MQ. This is THE protocol
> layer used in Jupyter between clients and kernels (Toree serves as a
> Jupyter kernel). Over the past months, we've worked with the JeroMQ
> community to help move along a license change to MPL v2 (
> https://github.com/zeromq/jeromq/issues/327). The progress showed huge
> promised at the start and we are down to 3 committers out of 31 who have
> not responded. The JeroMQ community is moving towards code remediation.
If LGPL code is included either in your source tree or in your existing
release(s), why isn't that reflected in a top-level LICENSE and NOTICE
file?
From reading the homepage of the website and quickly browsing the source
tree, the only reference is in DISCLAIMER, which is awfully small. It
wasn't obvious to me besides that tiny bit that you include some LGPL code.
Or am I missing how this dependency works?
Yes, I agree that incubation is a process, and there is great progress
both here and in the other project towards an Apache-license-harmonious
outcome. But we need to be very careful that end-users have a
crystal-clear understanding that there is copyleft style licenses in
releases or dependencies of anything at Apache.
- Shane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org