lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prescott Nasser <geobmx...@hotmail.com>
Subject RE: SharpZipLib Dependency?
Date Sat, 03 Nov 2012 02:38:34 GMT
Im all for getting rid of it if we can, not sure its possibly for backwards compatibility.
Im not a fan of libraries that require a ton of other libraries, so any clean up is a +1 from
me.

That said, we do not distribute it. Being included in the repo for ease of development purposes
is not considered distribution. Nor does the link to it constitute endorsement or make it
a release artifact.  We might be able to clean up the readme language to make it more clear
ita for ease, and its under a different license

There was a discussion not to long ago regarding this on one of the general lists (sorry cant
remember which - incubator or board). The gist is that the only thing that we officially release
is the source code. Even the binaries we release are not considered official.

Im confident we are legally in the clear.
Sent from my Windows Phone
________________________________
From: Christopher Currens
Sent: 11/2/2012 6:47 PM
To: dev@lucenenet.apache.org
Subject: Re: SharpZipLib Dependency?

I don't have an answer for you about this, except that we'll get it
taken care of.  It has been distributed as long as I've been a member
of the project, but it seems that we fell under the Special Rule for
Incubating Projects, which allowed us to do quite a bit more with
restricted licenses.  We do need to make sure that we don't violate
any licenses here.

As for the nuget, I can see the issue where someone pulling in the
Lucene.NET package could be unaware of the GPL dependency.  However, I
don't think that this is an issue because it include the linking
exception.  That doesn't mean that a notice wouldn't be necessary, but
it shouldn't wind up being a legal issue to anyone using the software.
 When it comes to dependencies, Nuget via Visual Studio is very clear
that dependencies may be subject to additional license agreements.
While it is wholly the responsibility of the user to make sure they
are following terms of licensing in terms of checking dependencies, I
think it could be good of us to perhaps make some changes in this
area.

On Fri, Nov 2, 2012 at 4:41 PM, Rob Vesse <rvesse@dotnetrdf.org> wrote:
> Thanks for the clarification Chris. I likely only noticed this because I'm
> transitioning a project that relies on Lucene.Net to use NuGet for all
> dependencies rather than keeping copies of the binaries directly.
>
> The real concern I have with this dependency is that that the Lucene.Net
> PMC may have fallen afoul (albeit unintentionally) of some of the Apache
> guidance in how you distribute SharpZipLib without correctly following the
> legal guidance.
>
> I apologize if the following is going to come across as somewhat anal but
> as a fellow Apache and open source developer I want the Lucene.Net project
> to succeed because I use it in my own projects.  So it's in the interest
> of the project and the ASF that you guys get this sorted sooner rather
> than later if there is a problem.  And I'm not any sort of legal
> professional so apologies if my interpretation of Apache policy is a
> little off in places.
>
> The issue is that SharpZipLib is GPL which makes it a prohibited work by
> the Apache rules (http://www.apache.org/legal/3party.html#options) so you
> can't include it directly in Apache releases.
>
> As far as I can see you haven't included it directly which is great.
>
> The official Apache release (the source package) does not contain the
> binary (which is good) it does contain a section in the ReadMe stating
> that additional libraries are required (which is also fine).  However
> there is a problem in that you point users to download it from
> https://svn.apache.org/repos/asf/lucene.net/tags/Lucene.Net_3_0_3_RC1/lib/
> which is on a Apache server.
>
> The Apache guidelines state "YOU MUST NOT distribute a prohibited work
> from an apache.org server" which you are clearly violating here
>
> Whether you need to remove those files from Apache SVN is likely a
> question for Apache Legal or your Incubation mentors (if they are still
> around post-graduation).  For future releases I would suggest that you
> likely want to link to the relevant websites where those third party
> dependencies can be obtained from.  If the PMC wants I believe they can
> choose to host copies of these libraries elsewhere provided they aren't on
> Apache infrastructure and it isn't an official action of the PMC.
>
> The binary release is also fine from the standpoint that dependencies
> aren't included but suffers from the same issue that you point people to
> download them from an Apache server.
>
> I assume this hosting of the dependencies is primarily a holdover from
> Incubation where podlings are allowed a little more freedom in their
> interpretation of the legal guidelines as they work towards becoming a TLP
>
> As for NuGet I believe you are fine because it's a non-Apache release.  I
> think ideally the package should require license acceptance and say that
> it requires installing a GPL dependency though you can probably get by
> without this change for the time being.  (Btw I filed a RFE on NuGet on
> requiring license acceptance on a per-dependency basis which would make
> this easier - http://nuget.codeplex.com/workitem/2773)
>
> Sorry to be a pain in the ass, thanks again for all the work you guys do
> in making Lucene available to .Net developers.  Hopefully this issue is
> fairly trivial for you guys to address in the grand scheme of things.
>
> Thanks,
>
> Rob
>
> On 11/2/12 12:50 PM, "Christopher Currens" <currens.chris@gmail.com> wrote:
>
>>We've had the SharpZipLib dependency for a very long time.  It might
>>be possible that it was included in an earlier nuget package instead
>>of listed as a dependency.  It's there to support compressed fields in
>>an index, which have been removed in the 3.0.3 API.  However, to
>>support backwards compatibility, the package still needs to include
>>the library in order to read indexes that were made pre-3.x that use
>>compressed fields.
>>
>>I'm not 100% sure, but even if you don't use compressed fields, you
>>might not be able to run without it.  I think there is a specific
>>support class that checks for its existence.
>>
>>On Fri, Nov 2, 2012 at 11:56 AM, Rob Vesse <rvesse@dotnetrdf.org> wrote:
>>> I noticed in upgrading to 3.0.3 that SharpZipLib is now a dependency and
>>> will be auto-installed when using the NuGet package.  I don't remember
>>>this
>>> being the case with 2.9.2/2.9.4 and never had any problems using those
>>> versions without it
>>>
>>> Is SharpZipLib a required dependency or is it only used for some
>>>specific
>>> functionality?
>>>
>>> Rob
>>>
>
>
>
>

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