Yes, I borrows Lucene’s source code(analysis, store, utils ) partly. My search engine is LGPL, and of course I leaved a Apache license text header in all source codes borrowed from Lucene.
Sang Song > 2014. 11. 15., 오후 10:56, Michael McCandless <[email protected]> 작성: > > Yes it does. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Sat, Nov 15, 2014 at 8:53 AM, Will Martin <[email protected]> wrote: >> Um, doesn't the Apache license require inclusion of the license? Just sayin' >> >> >> -----Original Message----- >> From: Michael McCandless [mailto:[email protected]] >> Sent: Saturday, November 15, 2014 8:47 AM >> To: [email protected] >> Subject: Re: How can I make better project than Lucene? >> >> Well the Apache Software License is very generous about poaching. >> >> "Your ideas will go further if you don't insist on going with them." >> >> Mike McCandless >> >> http://blog.mikemccandless.com >> >> >> On Sat, Nov 15, 2014 at 6:42 AM, Will Martin <[email protected]> wrote: >>> Btw: SwSong should not steal code; which implies an existing license whose >>> terms he is willing to break. Not a good first step. ;-) >>> >>> will >>> >>> -----Original Message----- >>> From: Michael McCandless [mailto:[email protected]] >>> Sent: Saturday, November 15, 2014 6:22 AM >>> To: [email protected] >>> Subject: Re: How can I make better project than Lucene? >>> >>> Actually I think competing projects is very healthy for open source >>> development. >>> >>> There are many things you could explore to "contrast" with Lucene, e.g. >>> write your new search engine in Go not Java: Java has many problems, maybe >>> Go fixes them. Go also has a low-latency garbage collector in development >>> ... and Java's GC options still can't scale to the heap sizes that are >>> practical now. >>> >>> Lucene has many limitations, so your competing engine could focus on them. >>> E.g. the "schemalessness" of Lucene has become a big problem, and near >>> impossible to fix at this point, and prevents new important features like >>> LUCENE-5879 from being possible, so you could give your engine a "gentle" >>> schema from the start. >>> >>> The Lucene Filter/Query situation is a mess: one should extend the other. >>> >>> Lucene has weak support for proximity queries (SpanQuery is slow and does >>> not get much attention). >>> >>> Lucene is showing its age, missing some compelling features like a builtin >>> transaction log, "core" support for numerics (they are sort of hacked on >>> top), optimistic concurrency support (sequence ids, versions, something), >>> distributed support (near real time replication, etc.), multi-tenancy, an >>> example server implementation, so the search servers on top of Lucene have >>> had to fill these gaps. Maybe you could make your engine distributed from >>> the start (Go is a great match for that, from what little I know). >>> >>> All 3 highlighter options have problems. >>> >>> The analysis chain (attributes) is overly complex. >>> >>> In your competing engine you can borrow/copy/steal from Lucene's good parts >>> to get started... >>> >>> >>> Mike McCandless >>> >>> http://blog.mikemccandless.com >>> >>> >>> On Fri, Nov 14, 2014 at 8:43 PM, swsong_dev <[email protected]> wrote: >>>> I’m developing search engine, Fastcatsearch. http://github >>>> <hthttp://githubtp//github>.com/fastcatsearch/fastcatsearch >>>> >>>> Lucene is widely known and famous project and I cannot beat Lucene for now. >>>> >>>> But is there any chance to beat Lucene? >>>> >>>> Anything like features, performance. >>>> >>>> Please, let me know what to do to make better product than Lucene. >>>> >>>> Thank you. >>> >>
