From java-dev-return-27114-apmail-lucene-java-dev-archive=lucene.apache.org@lucene.apache.org Wed Sep 03 13:53:01 2008 Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 10087 invoked from network); 3 Sep 2008 13:53:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Sep 2008 13:53:01 -0000 Received: (qmail 85722 invoked by uid 500); 3 Sep 2008 13:52:56 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 85678 invoked by uid 500); 3 Sep 2008 13:52:56 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 85668 invoked by uid 99); 3 Sep 2008 13:52:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Sep 2008 06:52:56 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [217.12.10.218] (HELO web26007.mail.ukl.yahoo.com) (217.12.10.218) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 03 Sep 2008 13:51:56 +0000 Received: (qmail 28861 invoked by uid 60001); 3 Sep 2008 13:51:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nleKflIf1q0YwVD3U0rp+PkmbJGJbzDiXgLFaI93iAFZd0wUMWGotq6ozvOYEqyiX6+j+NTJ18QZBwXGdEG5ilaH1h4eDoPjFPw6TcC1f4R3wDMa6d4S0zYe2Hx/+2V+dwEBSi0da1vybyKU2cTiNFFe1Bxo0xoT62Ek3INF2Fk=; X-YMail-OSG: MOVqNuMVM1lpRueW6JTI4pmYQVw0iRnk_r0G2LAy74qZqAiVk4DsrbkdUVmwo7l.o67LylJX40sYAN4TqdM6P3hB.LsoIwn65DZ_8bfKhCkq1J3OEMVbNfX5O9Mo1jCzO_Eftvnp8zdQvLNsBsfcm54b Received: from [193.36.230.96] by web26007.mail.ukl.yahoo.com via HTTP; Wed, 03 Sep 2008 13:51:23 GMT X-Mailer: YahooMailRC/1096.28 YahooMailWebService/0.7.218.2 Date: Wed, 3 Sep 2008 13:51:23 +0000 (GMT) From: mark harwood Subject: Re: Moving SweetSpotSimilarity out of contrib To: java-dev@lucene.apache.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <699714.28399.qm@web26007.mail.ukl.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org Not tried SweetSpot so can't comment on worthiness of moving to core but ag= ree with the principle that we can't let the hassles of a company's "due di= ligence" testing dictate the shape of core vs contrib.=0A=0AFor anyone conc= erned with the overhead of doing these checks a company/product of potentia= l interest is "Black Duck".=0AI don't work for them and don't offer any end= orsement but simply point them out as something you might want to take a lo= ok at.=0A=0ACheers=0AMark=0A=0A=0A=0A----- Original Message ----=0AFrom: Na= dav Har'El =0ATo: java-dev@lucene.apache.org=0ASen= t: Wednesday, 3 September, 2008 13:21:34=0ASubject: Re: Moving SweetSpotSim= ilarity out of contrib=0A=0AOn Tue, Sep 02, 2008, Chris Hostetter wrote abo= ut "Re: Moving SweetSpotSimilarity out of contrib":=0A> =0A> : >From a lega= l standpoint, whenever we need to use open-source code, somebody=0A> : has = to inspect the code and 'approve' it. This inspection makes sure there's=0A= > : no use of 3rd party libraries, to which we'd need to get open-source=0A= > : clearance as well.=0A> =0A> You should talk to whomever you need to tal= k to at your company about =0A> revising the appraoch you are taking -- the= core vs contrib distinction in =0A> Lucene-Java is one of our own making t= hat is completly artificial. With =0A> Lucene 2.4 we could decide to split= what is currently known as the "core" =0A> into 27 different directories, = none of which are called core, and all of =0A> which have an interdependenc= y on eachother. We're not likely to, but we =0A> could -- and then where w= oud your company be?=0A=0AI can't really defend the lawyers (sometimes you = get the feeling that they=0Aare out to slow you down, rather than help you = :( ), but let me try to explain=0Awhere this sort of thinking comes from, b= ecause I think it is actually quite=0Acommon.=0A=0ALucene makes the claim t= hat it has the "apache license", so that any company=0Acan (to make a long = story short) use this code. But when a company sets out=0Ato use Lucene, ca= n it take this claim at face value? After all, what happens=0Aif somebody s= teals some proprietary code and puts it up on the web claiming it=0Ahas the= apache license - does it give the users of that stolen code any=0Arights? = Of course not, because the rights weren't the distributor's to give=0Aout i= n the first place.=0A=0ASo it is quite natural that when a company wants to= use use some open-source=0Acode it doesn't take the license at face value,= and rather does some "due=0Adiligance" to verify that the people who publi= shed this code really owned=0Athe rights to it. E.g., the company lawyers m= ight want to do some background=0Achecks on the committers, look at the pro= ject's history (e.g., that it doesn't=0Ahave some "out of the blue" donatio= ns from vague sources), check the code and=0Acomments for suspicious string= s, patterns, and so on.=0A=0AWhen you need to inspect the code, naturally y= ou need to decide what you=0Ainspect. This particular company chose to insp= ect only the Lucene core,=0Aperhaps because it is smaller, has fewer contri= butors, and has the vast=0Amajority of what most Lucene users need. Inspect= ing all the contrib - with=0Aall its foreign language analyzers, stuff like= gdata and other rarely used=0Astuff - may be too hard for them. But then, = the question I would ask is -=0Awhy not inspect the core *and* the few cont= ribs that interest you? For=0Aexample, SweetSpotSimilarity (which you need)= and other generally useful=0Astuff like Highlighter and SnowballAnalyzer.= =0A=0A> Doing this would actually be a complete reversal of the goals discu= ssed in =0A> the near past: increasing our use of the contrib structure fo= r new =0A> features that aren't inherently tied to the "guts" of Lucene. T= he goal =0A> being to keep the "core" jar as small as possible for people w= ho want to =0A> develop apps with a small foot print.=0A=0AI agree that thi= s is an important goal.=0A=0A> At one point there was even talk of refactor= ing additional code out of the =0A> core and into a contrib (this was alrea= dy done with some analyzers when =0A> Lucene became a TLP)=0A=0A-- =0ANadav= Har'El | Wednesday, Sep 3 2008, 3 Elul 5768= =0AIBM Haifa Research Lab |-----------------------------------= ------=0A |Promises are like babies: fun= to make,=0Ahttp://nadav.harel.org.il |but hell to deliver.=0A=0A= ---------------------------------------------------------------------=0ATo = unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org=0AFor additiona= l commands, e-mail: java-dev-help@lucene.apache.org=0A=0A=0A --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org