activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: [VOTE] Apache Artemis 1.2.0
Date Wed, 23 Dec 2015 23:23:48 GMT
So I think the current policy is not that hard to understand.

It basically says that we cannot redistribute category x licensed bits.
Check.

Using the LGPL licensed libaio does not require us to change our license.
Check.

So we are working in a scenario similar to what is described in the "DOES
IT MATTER WHAT PLATFORM AN APACHE PRODUCT IS CREATED TO WORK WITH?" Section
of
http://www.apache.org/legal/resolved.html

Libaio is a platform API that we use if it's available.


On Wednesday, December 23, 2015, Daniel Kulp <dkulp@apache.org> wrote:

>
> > On Dec 23, 2015, at 4:07 PM, John D. Ament <johndament@apache.org
> <javascript:;>> wrote:
> >
> > Are you referring to the bin or src distribution?
>
> Kind of both…
>
> By removing the binary from the src distribution, that covers that case.
>  The user would have to cd into the appropriate directory and explicitly
> run the “make” or whatever to build the binary.   It’s an explicit choice
> they make.   Thus, I’m completely OK with that now.
>
>
> The bin distribution is still an issue.   If the default was to not use
> the libaio at all unless the user either edited a config file to enable it
> or pass a command line flag or similar to take explicit action, I’d be OK
> there as well.     The new wording on the legal pages is completely
> confusing.  The original suggested wording in:
> https://issues.apache.org/jira/browse/LEGAL-54
> makes so much more sense:
>
> "However, projects may use LGPL licensed works in optional features that
> are not enabled by default.”
>
>
> Dan
>
>
>
> >
> > On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dkulp@apache.org
> <javascript:;>> wrote:
> >
> >>
> >> Question: If I grab Artemis 1.1.0 tarbal/zip and start up the broker
> “out
> >> of the box”, does it use libaio or not?  If I specifically have to
> >> configure something (pass a flag, edit a config file, etc…) to enable
> use
> >> if the LGPL library, then fine.    However, if it’s something that
> occurs
> >> completely automatically without the user even knowing that it’s
> occurring,
> >> then I have a major problem with it.  It needs to be something that the
> >> user has to explicitly CHOOSE to use.
> >>
> >> Dan
> >>
> >>
> >>
> >>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> clebert.suconic@gmail.com <javascript:;>>
> >> wrote:
> >>>
> >>> also, there has also been questions about it during the donation
> >>> process.. licenses reviewed.. etc.. so I don't think we need to open a
> >>> new discussions over this. the binary inclusion on the source was
> >>> something that was fixed now.
> >>>
> >>> The dependency on libaio on the C code is through through dynamic
> >>> linked library, and is the same as any C code depending on libc or
> >>> gcc.
> >>>
> >>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> >>> <clebert.suconic@gmail.com <javascript:;>> wrote:
> >>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <johndament@apache.org
> <javascript:;>>
> >> wrote:
> >>>>> Just wondering, does anyone plan to raise the LGPL question w/ legal
> >>>>> discuss?  If we're waiting for the new year to do the next release,
> >> would
> >>>>> be good to at least start the discussion.
> >>>>
> >>>>
> >>>> We had such discussion long ago with legal. I couldn't find that email
> >>>> on my inbox but we specifically asked questions about it. We were ok
> >>>> as I remember. Maybe someone else (Martyn?) will have it on their
> >>>> inboxes. For that reason I don't want to go over the same issue we had
> >>>> asked before.
> >>>>
> >>>> The use of libaio is optional anyways and the system works as
> >>>> expected. what also covers other questions we had here on this thread.
> >>>
> >>>
> >>>
> >>> --
> >>> Clebert Suconic
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

-- 
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino

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