Mailing-List: contact lucy-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 23 Dec 2011 20:34:52 -0800
From: Marvin Humphrey <marvin@rectangular.com>
To: lucy-dev@incubator.apache.org
Message-ID: <20111224043452.GA13704@rectangular.com>
References: <4EF3CA27.9070501@aevum.de>
 <20111223025236.GA30915@rectangular.com> <4EF4D822.7020804@aevum.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EF4D822.7020804@aevum.de>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [lucy-dev] Improving the ClusterSearcher

On Fri, Dec 23, 2011 at 08:36:02PM +0100, Nick Wellnhofer wrote:
> On 23/12/11 03:52, Marvin Humphrey wrote:
>> Unfortunately, legally I think we have to hold off on applying this patch, for
>> licensing reasons.  Here's the licensing block from Net::Server:
>>
>>      This package may be distributed under the terms of either the
>>
>>        GNU General Public License
>>          or the
>>        Perl Artistic License
>>
>> Apache products cannot have mandatory dependencies on GPL'd components, so we
>> cannot use Net::Server under the terms of the GPL.  Usage under the terms of
>> the Artistic license has not been approved by Apache Legal.  See the following:
>>
>>    http://www.apache.org/legal/resolved.html for a list of approved licenses.
>>
>>    https://issues.apache.org/jira/browse/LEGAL-86 for an attempt to get
>>    Artistic-1 added to the list of approved licenses, which resulted in a
>>    temporary variance.
>>
>> Can we somehow make SearchServer pluggable or subclassable so that the user
>> can supply routines for forking/preforking/etc?
>
> I think the easiest solution would be to move the guts of the request  
> handling from SearchServer to another module. This could then be used  
> from different server modules.

How about we expose a handle_request() method on SearchServer which takes a
socket handle as an argument, reads the incoming request and sends a response
back?

  =head2 handle_request

     $search_server->handle_request($sock);
  
  Process a request from a socket handle which is ready for reading.

(We might need a timeout to deal with stuck handles.)

Users would be free to write their own serve() loop then.

It would be acceptable to provide sample code in the docs which illustrates
how to use SearchServer in conjunction with Net::Server, though it would be
better if we were to either provide a superior solution on our own or to
promote a liberally licensed alternative instead of Net::Server.

> Do I understand correctly that if we keep the current SearchServer, we can
> also ship another module based on  Net::Server because then it's not a
> mandatory dependency?

My reply had a bug in it.  To clarify: I don't believe that an Apache product
can have a dependency on a GPL'd component, period.

The FSF's position on derivative works is that if you reference a component,
your software derives from it, and since the GPL applies at the boundary of
derivative works, if you use a GPL'd component, the GPL's copyleft provisions
kick in[1].  Some people consider this position legal nonsense, but the ASF
chooses to respect the FSF's wishes nonetheless, so that the licensing of our
products is not contentious and downstream consumers of ASF products can rest
easy.

It's possible, even likely, that the authors of Net::Server do not feel as
strongly about copyleft as the FSF.  The Artistic License -- a weak copyleft
license which has reciprocity provisions regarding the central work but allows
unmodified usage within proprietary software -- better reflects Larry Wall's
wishes, and perhaps the wishes of many within the Perl community.  But the
Artistic License 1.0 is a murky, muddled piece of crap, and very few projects
are actually licensed under the Artistic License 2.0.  And the GPL is what it
is.

Under certain strict conditions, Apache projects can have dependencies
licensed under the LGPL or other prohibited licenses, but not GPL:

  http://www.apache.org/legal/resolved.html#prohibited

  Can Apache projects rely on components under prohibited licenses?

    Apache projects cannot distribute any such components. As with the
    previous question on platforms, the component can be relied on if the
    component's licence terms do not affect the Apache product's licensing.
    For example, using a GPL'ed tool during the build is OK.

  Can Apache projects rely on components whose licensing affects the Apache
  product?

    Apache projects cannot distribute any such components. However, if the
    component is only needed for optional features, a project can provide
    the user with instructions on how to obtain and install the
    non-included work.  Optional means that the component is not required
    for standard use of the product or for the product to achieve a
    desirable level of quality. The question to ask yourself in this
    situation is:

      * "Will the majority of users want to use my product without adding the
        optional components?

In conclusion:

  * It would be nice if most of CPAN wasn't licensed under
    legally-lousy-Artistic/draconian-copyleft-GPL, but we're stuck with the
    consequences of that dubious decision from a long time ago.  (I'm glad
    that a lot of Ruby gems are licensed under MIT.)
  * Dealing with copyleft licenses is a PITA, and so if we can solve a
    problem any other way we should.

Marvin Humphrey

[1] http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem