clucene-developers — CLucene development-related discussion.

[CLucene-dev] [ clucene-Bugs-771862 ] newest port for Windows/Linux/Cygwin/MinGW

[SourceForge.net <no...@so...>]

Bugs item #771862, was opened at 2003-07-15 15:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=558446&aid=771862&group_id=80013

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: jimmy pritts (jbpritts)
Assigned to: Nobody/Anonymous (nobody)
Summary: newest port for Windows/Linux/Cygwin/MinGW

Initial Comment:
If sourceforge works this time, attached will be the 
newest clucene release candidate.  I made some 
significant changes to the macro system, and some 
small changes to the source code.  I ran 'demo' on 
Windows, Linux, Cygwin, and it worked perfectly.  I 
ran 'tests' on Windows, Linux, Cygwin, and their are 
some minor problems with each platform.  clucene 
should build without changes on the 3 platforms listed 
above.   For Linux you should have autoconf 2.57, 
automake 1.7, and libtool 1.5.  A recent cygwin release 
includes all of these tools.  

I did not test on mingw, but I would be surprised if there 
are any major issues.

I follow the mailing list, so I can help with problems or 
qustions.

regards, 
  Jimmy.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=558446&aid=771862&group_id=80013

Re: [CLucene-dev] Re: license (clarification)

[<rg...@sd...>]

>>>>> "Max" == Max Khesin <ma...@to...> writes:
Max> 
Max> The problem is that some changes are not really an improvement of
Max> the open source package as its goals are defined. e.g if I stick
Max> clucene in some cool documentation software I am working on my
Max> prog will be subject to either the open-source req. of lgpl or to
Max> the inconvenience of using a linked binary.

It all comes down to what Title 17 refers to as a "derived work."  If
CLucene were just a separate executable called via VB script in your
product's documentation window, no problems.  If you integrate it too
far it is a derived work.  The FSF makes the claim that all dynamic
linking is deriving a new work from the library, but the LGPL
explicitly gives up the author's right to works _derived by linking_
(but not by other means).  And it is possible that at least some uses
of dynamic linking aren't derived works inspite of the FSF's position.
It isn't clear where the line is, not because of the license, but
because Title 17 purposely doesn't make it explicit.

>> However, if you wanted some of my code under the Apache license, I
>> would make you pay for it -- my reasoning being that I get
>> something for my code, either access to better versions of it, or
>> money.
Max> 
Max> I do not see how you can pull this off under apache. apache means
Max> it's open-source. and even if you do not post your code but sell
Max> it to me under apache i can just go ahead and post it
Max> myself.

Yes, that is what I was suggesting.  You can offer it under the GPL
and wait until someone asks about a different license, then charge
money.  If you give it to them under the Apache license you will
probably only sell it once, but sometimes a single large commercial
license fee is all you can get anyway.  Sometimes they try to sell a
traditional commercial license in which the licensee can't
re-distribute the source.

Max> what I have seen some people do is offer the code under
Max> either GPL OR a commercial license. This way people who do not
Max> want to be burdened by GPL can just go ahead and by the GPL-free
Max> license.

Exactly.  Doesn't MySQL do this ?
 
>> Swish-e is also debating going through a license change discussion,
>> you might go over to there forum and complain there too :)  They have
>> mentioned the BSD license, which would statisfy your requirements.

Max> Maybe I will :). Is it written in an 'appropriate' language?

C.  I think it is technically less advanced than MG or Lucene, because
it is older.  It does have a stemmer though.  I don't know the size of
the index relative to the body of work.

http://swish-e.org/ (Look at the link at the bottom of the page for
the License discussion)

I think I'm sticking with CLucene though, the LGPL is fine for me and
I think it is more advanced than Swish-e.

Max> I have both 1st and recently got 2d editions. My 'dayjob' is
Max> working for a company which developed the 1st (and still the best
Max> :) commercial implementation of JBIG2 image compression. Many
Max> principles of symbolic compression being covered in MG, we are
Max> longtime friends :)

Have you tried to use the software from the site ?  I have found the
"get scripts" which you need to index things to be buggy and brittle.

>> It's actually only 8 MB, that's not bad maybe I'll just use it.
Max> 
Max> The advantage is you can say things like 'twice as fast as the X
Max> search engine on the Reuters corpus', similar to the 'CCITT 8'
Max> image set when it comes to compression (static huffman codes in
Max> fax machines were optimized based on these 8 images).

I'm downloading it.

--Rob

Re: [CLucene-dev] Re: license (clarification)

[Max K. <ma...@to...>]

> There's no "maybe" about it, if you distribute a binary that is
> know who to buy off ;)

If a commericial license was available I would consider it, although at
this early stage my funds are very limited. I just do not think the way
things are now clucene is ready to offer a commercial license, but Ben may
disagree :).

> Both licenses would allow you to share your changes if you wanted, so
> that's not really the issue is it ?  The issue is that you want to NOT
> share your changes, and the LGPL doesn't allow that and the Apache
> does.

The problem is that some changes are not really an improvement of the open
source package as its goals are defined. e.g if I stick clucene in some
cool documentation software I am working on my prog will be subject to
either the open-source req. of lgpl or to the inconvenience of using a
linked binary.  


> It's not my code and I'm plunging ahead with either license.  However,
> if you wanted some of my code under the Apache license, I would make
> you pay for it -- my reasoning being that I get something for my code,
> either access to better versions of it, or money.

I do not see how you can pull this off under apache. apache means it's
open-source. and even if you do not post your code but sell it to me under
apache i can just go ahead and post it myself. what I have seen some
people do is offer the code under either GPL OR a commercial license. This
way people who do not want to be burdened by GPL can just go ahead and by
the GPL-free license.

> Swish-e is also debating going through a license change discussion,
> you might go over to there forum and complain there too :)  They have
> mentioned the BSD license, which would statisfy your requirements.
Maybe I will :). Is it written in an 'appropriate' language?

> and just about everyone else is GPL, and when they aren't GPL they are
> written in Java or Perl or another inappropriate language.  
:). Yes, these are inappropriate. (the authors of original lucene may
disagree)


> I had heard of this, I think it was referenced in the very good book
> "Managing Gigabytes".  ( http://www.mds.rmit.edu.au/mg/ ) 

I have both 1st and recently got 2d editions. My 'dayjob' is working for a
company which developed the 1st (and still the best :) commercial
implementation of JBIG2 image compression. Many principles of symbolic
compression being covered in MG, we are longtime friends :)

> It's actually only 8 MB, that's not bad maybe I'll just use it.

The advantage is you can say things like 'twice as fast as the X search
engine on the Reuters corpus', similar to the 'CCITT 8' image set when it
comes to compression (static huffman codes in fax machines were optimized
based on these 8 images).

cheers,

max.

Re: [CLucene-dev] Re: license (clarification)

[<rg...@sd...>]

>>>>> "Max" == Max Khesin <ma...@to...> writes:
Max> 
Max> Hi Rob,
Max> all of this is great if you are not modifying the original
Max> code. Let's say you are tightly integrating your code with
Max> clucene, via source rather than a shared library. You may be ok
Max> with lgpl, or somebody can theoretically come and demand you to
Max> publish all your code under 'derived works' clause.  Maybe you
Max> will win the case, after shelling out your hard-earned money for
Max> lawers or maybe you will loose or give up. This is very
Max> improbable, but you cannot have real peace of mind without a
Max> short clear license like apache. 

There's no "maybe" about it, if you distribute a binary that is
produced partitially from LGPL code and doesn't provide all the
source, you will be in violation of the license, unless incorporates
the LGPL code through the specific method of linking the library (and
provided source to that library, including any changes you made).  It
would not be a "somebody" who sued, the only person who could sue you
for that would be the author or authors of CLucene; so at least you
know who to buy off ;)

Max> And apache would not prevent people like me from
Max> contributing/improving the main open-source apache.

Both licenses would allow you to share your changes if you wanted, so
that's not really the issue is it ?  The issue is that you want to NOT
share your changes, and the LGPL doesn't allow that and the Apache
does.

It's not my code and I'm plunging ahead with either license.  However,
if you wanted some of my code under the Apache license, I would make
you pay for it -- my reasoning being that I get something for my code,
either access to better versions of it, or money.

Max> This is what I would LIKE to do. Without having a license which
Max> will give me a peace of mind I would rather, frankly, start from
Max> scratch. Anyway, like Doug said, 'with lgpl people complained and
Max> with apache the complains stopped'. So I am going to have to keep
Max> complaining :).

Swish-e is also debating going through a license change discussion,
you might go over to there forum and complain there too :)  They have
mentioned the BSD license, which would statisfy your requirements.

I have conducted a pretty energetic search of all the various index /
search tools looking for what was under which license.  The Managing
Gigabytes stuff is GPL, but there are a small number of authors so you
might ask about a license change there.  The original SWISH was "GPL
or LGPL" according to the announcement:
http://www.rice.edu/sw/swish/patches/kevinh.19970916.html And htdig
and just about everyone else is GPL, and when they aren't GPL they are
written in Java or Perl or another inappropriate language.  Or else
they are designed to be used through a web interface, and would need
modification to make them into a general library.  There are small
projects for searching specific things like bibliographies, but none
of them seem to have the robustness and development that
lucene/clucene have.

Max> BTW a commonly used dataset for searching can be found here:
Max> 
Max>  http://www.daviddlewis.com/resources/testcollections/reuters21578/

I had heard of this, I think it was referenced in the very good book
"Managing Gigabytes".  ( http://www.mds.rmit.edu.au/mg/ )  I was
wanting something easy for sanity testing, and something I knew I
could re-distribute to you guys, so I could make tar file and send it
and say "see, search for this and then grep for it, something's
wrong."

It's actually only 8 MB, that's not bad maybe I'll just use it.

--Rob

Re: [CLucene-dev] Test body

[<rg...@sd...>]

>>>>> "Ben" == Ben van Klinken <be...@vi...> writes:
Ben> 
Ben> Hi Rob,
Ben> Sounds like a good idea, Rob. Linux Gazette sounds good! No
Ben> specific files have been used before - just whatever i come
Ben> across first. Documentation of something generally.
Ben> 
Ben> You'll currently find some differences between the outputs of the
Ben> java and c++ version. It's not a major problem but should be
Ben> fixed anyway. The numbering of documents (or segments i think)
Ben> some how differs. I looked into this but could not find why at
Ben> the time. This doesn't affect the search results though.
Ben> 
Ben> Also, don't forget when running searches that the
Ben> unicode/non-unicode versions will have slightly different output
Ben> (depending on the input of course). The java version uses unicode
Ben> - and in c++ is optional. There is a gcc script version of
Ben> clucene in the pipeline so it would be great if someone could
Ben> test unicode on that :)
Ben> 
Ben> Thanks Rob for the offer. Look forward to hearing the results.
Ben> 
Ben> cheers,
Ben> Ben

Ok, I will start with the Linux Gazette.  Eventually I would like the
test body to be large enough that we can time indexing and searching
to see if changes affected runtime.  But for now, just a few sanity
checks that can be verified with grep would be nice.  I'll let you
know shortly.

--Rob

Re: [CLucene-dev] Re: license (clarification)

[Max K. <ma...@to...>]

Hi Rob,
all of this is great if you are not modifying the original code. Let's say
you are tightly integrating your code with clucene, via source rather than
a shared library. You may be ok with lgpl, or somebody can theoretically
come and demand you to publish all your code under 'derived works' clause.
Maybe you will win the case, after shelling out your hard-earned money for
lawers or maybe you will loose or give up. This is very improbable, but
you cannot have real peace of mind without a short clear license like
apache. And apache would not prevent people like me from 
contributing/improving the main open-source apache. This is what I would
LIKE to do. Without having a license which will give me a peace of mind I
would rather, frankly, start from scratch. Anyway, like Doug said, 'with
lgpl people complained and with apache the complains stopped'. So I am
going to have to keep complaining :).

BTW a commonly used dataset for searching can be found here:

 http://www.daviddlewis.com/resources/testcollections/reuters21578/

Re: [CLucene-dev] Test body

[Ben v. K. <be...@vi...>]

Hi Rob,

Sounds like a good idea, Rob. Linux Gazette sounds good! No specific files
have been used before - just whatever i come across first. Documentation of
something generally.

You'll currently find some differences between the outputs of the java and
c++ version. It's not a major problem but should be fixed anyway. The
numbering of documents (or segments i think) some how differs. I looked into
this but could not find why at the time. This doesn't affect the search
results though.

Also, don't forget when running searches that the unicode/non-unicode
versions will have slightly different output (depending on the input of
course). The java version uses unicode - and in c++ is optional. There is a
gcc script version of clucene in the pipeline so it would be great if
someone could test unicode on that :)

Thanks Rob for the offer. Look forward to hearing the results.

cheers,
Ben





----- Original Message -----
From: Rob Ristroph <rg...@sd...>
To: <clu...@li...>
Sent: Sunday, July 06, 2003 12:31 PM
Subject: [CLucene-dev] Test body


>
> I want to gather together a set of text documents that I can test
> CLucene on, and if it fails to find something or returns the wrong
> document then I can demonstrate the bug to everyone else by giving
> them the same set of test documents.
>
> I think I am going to make a collection of text versions of the
> Declaration of Independence, maybe all issues of the Linux Gazette,
> and a few other things we can freely re-distribute to each other.
>
> Any suggestions on what to include ?  Has CLucene or the Lucene
> project used specific test bodies before ?
>
> --Rob
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> CLucene-developers mailing list
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers
>

[CLucene-dev] Test body

[<rg...@sd...>]

I want to gather together a set of text documents that I can test
CLucene on, and if it fails to find something or returns the wrong
document then I can demonstrate the bug to everyone else by giving
them the same set of test documents.

I think I am going to make a collection of text versions of the
Declaration of Independence, maybe all issues of the Linux Gazette,
and a few other things we can freely re-distribute to each other.

Any suggestions on what to include ?  Has CLucene or the Lucene
project used specific test bodies before ?

--Rob

Re: [CLucene-dev] Re: license (clarification)

[<rg...@sd...>]

>>>>> "Max" == Max Khesin <ma...@to...> writes:
Max> 
Max> Hi Rob,
Max> I am not a legalist, but after looking at lgpl it appears that
Max> any source modifications have to be published, too. That's the
Max> part that is not good for a proprietary project. Apache has no
Max> such restictions.

Here is how I plan to go about selling a proprietary software that
uses CLucene as a library:

1) The "free trial" or "download version" of the software will have a
   link to the source forge CLucene site somewhere on the page.  Not
   hidden or in fine print, but somewhere below the "Download Now"
   button there will be a paragraph that says something like "This
   software uses a Free Software library called CLucene, and many of
   it's features would not be available without that project."  It has
   to say the version number.  ( If I have changes that aren't in the
   official tree, then I have to host the tar file of source myself,
   which I regard as mild encouragement to keep the project from
   splitting, but not too burdensome if I have to do it. )

2) Any registered version obtained by download will have a similar
   link.

3) Any version sold or given away via CDROM will have the tar file of
   source on the CD, and a README that tells you were it came from and
   that the latest version is on sourceforge.

Basically, any method you use to obtain my software, the CLucene
source will be available via the same method.

That should be enough to satisfy the LGPL.  There is also something
about a written offer to provide source code, I can add that to any
README files if all my documentation is electronic and add it in the
legalese at the end of the printed manual if there is one.

--Rob

P.S.  If you want to get better advice than I can give on these
issues, I recommend the gnu.misc.discuss newsgroup.

Re: [CLucene-dev] Re: license (clarification)

[Max K. <ma...@to...>]

Hi Rob,
I am not a legalist, but after looking at lgpl it appears that any source
modifications have to be published, too. That's the part that is not good
for a proprietary project. Apache has no such restictions.


On 4 Jul 2003, Rob Ristroph wrote:

> 
> Hi,
> 
>         I just joined the mailing list, however I have read all the
>         messages in the archives.
> 
>         I had a few comments about licenses; but I want to preface
>         them by saying that the clucene developers can expect me to
>         work on clucene regardless of whether it is under the GPL,
>         LGPL, BSD or Apache licenses.
> 
>         First, I am unsure of why Max Khesin thinks the LGPL is
>         incompatible with a proprietary product in a way that the
>         Apache license isn't.  Both licenses would require that you do
>         something when distributing a proprietary program that used
>         CLucene.  The Apache requires that notices appear in the
>         proprietary software, the LGPL requires the receiver of the
>         proprietary software be able to get the source code to
>         CLucene.  Personally, I think placing as zip file of CLucene
>         source on a CD or web page is less burdensome than cluttering
>         up my "About" sceen.  Would the names "Apache" and "Apache
>         Software Foundation" be replaced with Ben van Klinkehn ?
> 
>         Some licenses allow the switching later on to others, such as
>         the latest BSD licensed software can be re-licensed as GPL (or
>         practically anything), and LGPL can be re-licensed as GPL, but
>         since Apache requires that notice it can't be switched to GPL
>         or LGPL later.
> 
>         You can offer the software under all three choices, at the
>         user's discretion.  This is called "dual licensing" or
>         "multiple licensing."
> 
>         Someone made reference to the original writers of Lucene and
>         their intentions.  When a piece of software code is re-written
>         completely, so that you change every single line, which is
>         what you do in switching languages, it is a new copyrightable
>         work not a derived work of the previous.  (This is a grand
>         simplification, of course, and there are surely exceptions.)
>         An example is the Berkeley group that took AT&T Unix and
>         re-worked it until it was the separate work of BSD Unix.
>         Sometimes people are confused about this issue and think they
>         can't own code they have written while having someone else's
>         example in front of them, because they have heard discussions
>         of "clean room programming" and "virgin programmers" (virgin
>         programmers are so inexperienced they are known never to have
>         studied common examples).  The issues of clean room and virgin
>         refer to trade secrets and whether reverse engineering was
>         used, not copyrights.  We should be grateful to the Apache
>         group for saving us from all that by making their work Free
>         Software.
> 
>         In any case, the original Lucene and the Apache project is
>         focused on code meant to be run on a server, and most ordinary
>         users of the code don't have it on their computers; while
>         CLucene, being a simple library not in Java, is well suited to
>         being used in applications distributed everywhere.  Users of
>         software via a server don't have much freedom to modify the
>         code anyway, and the people running the server are more likely
>         to be in a corporation, so the two environments naturally lead
>         to different outlooks on licenses.
> 
>         This message is long because I wanted to get all my license
>         opinions into one message.  My future emails will be about
>         using and modifying CLucene :)
> 
> --Rob
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> CLucene-developers mailing list
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers
> 

Re: [CLucene-dev] Re: license (clarification)

[<rg...@sd...>]

Hi,

        I just joined the mailing list, however I have read all the
        messages in the archives.

        I had a few comments about licenses; but I want to preface
        them by saying that the clucene developers can expect me to
        work on clucene regardless of whether it is under the GPL,
        LGPL, BSD or Apache licenses.

        First, I am unsure of why Max Khesin thinks the LGPL is
        incompatible with a proprietary product in a way that the
        Apache license isn't.  Both licenses would require that you do
        something when distributing a proprietary program that used
        CLucene.  The Apache requires that notices appear in the
        proprietary software, the LGPL requires the receiver of the
        proprietary software be able to get the source code to
        CLucene.  Personally, I think placing as zip file of CLucene
        source on a CD or web page is less burdensome than cluttering
        up my "About" sceen.  Would the names "Apache" and "Apache
        Software Foundation" be replaced with Ben van Klinkehn ?

        Some licenses allow the switching later on to others, such as
        the latest BSD licensed software can be re-licensed as GPL (or
        practically anything), and LGPL can be re-licensed as GPL, but
        since Apache requires that notice it can't be switched to GPL
        or LGPL later.

        You can offer the software under all three choices, at the
        user's discretion.  This is called "dual licensing" or
        "multiple licensing."

        Someone made reference to the original writers of Lucene and
        their intentions.  When a piece of software code is re-written
        completely, so that you change every single line, which is
        what you do in switching languages, it is a new copyrightable
        work not a derived work of the previous.  (This is a grand
        simplification, of course, and there are surely exceptions.)
        An example is the Berkeley group that took AT&T Unix and
        re-worked it until it was the separate work of BSD Unix.
        Sometimes people are confused about this issue and think they
        can't own code they have written while having someone else's
        example in front of them, because they have heard discussions
        of "clean room programming" and "virgin programmers" (virgin
        programmers are so inexperienced they are known never to have
        studied common examples).  The issues of clean room and virgin
        refer to trade secrets and whether reverse engineering was
        used, not copyrights.  We should be grateful to the Apache
        group for saving us from all that by making their work Free
        Software.

        In any case, the original Lucene and the Apache project is
        focused on code meant to be run on a server, and most ordinary
        users of the code don't have it on their computers; while
        CLucene, being a simple library not in Java, is well suited to
        being used in applications distributed everywhere.  Users of
        software via a server don't have much freedom to modify the
        code anyway, and the people running the server are more likely
        to be in a corporation, so the two environments naturally lead
        to different outlooks on licenses.

        This message is long because I wanted to get all my license
        opinions into one message.  My future emails will be about
        using and modifying CLucene :)

--Rob

Re: [CLucene-dev] Re: license (clarification)

[Ben v. K. <be...@vi...>]

OK, I think i'm beginning to understand the issues behind licensing
opensource... what a hassle.
To me, flexibility and unhindered use of clucene is important. In my
understanding, that is what
LGPL is (unhindered use) - (though it seems that i am wrong!). I too started
off on GPL, as that
was the "suggested" license on sourceforge. I now understand that GPL is too
restrictive, but why
change to Apache? So Doug, it seems like i went through the same rigmarole
as you. Selecting GPL
without to much thought, going to LGPL, now to Apache... I have no political
agenda when it comes
to clucene, so if you (doug) think that is what people want then i see no
harm in it.

Ben

----- Original Message -----
From: Doug Cutting <cu...@lu...>
To: <clu...@li...>
Sent: Friday, July 04, 2003 3:37 AM
Subject: Re: [CLucene-dev] Re: license (clarification)


> Max Khesin wrote:
> > Doug? What do you think?
>
> I hate dealing licensing issues, but they are important.
>
> This is Ben's decision, as he's written the clucene code.
>
> Some tips:
>    - One should be careful about who copyright is assigned to, as only
> that party can change the copyright and license.  So once you assign the
> copyright to the Apache Foundation, or the FSF, you cannot change it.  I
> couldn't find any copyright statements in the CLucene code.  It's
> probably a good idea to add one to each file.
>    - If you use GPL or LGPL then folks (like Max) will complain
> endlessly.  I initially selected GPL for Lucene without thinking much
> about it.  Folks complained and I switched to LGPL.  They complained
> less, but still complained.  With the move to Apache the complaints
> stopped.  So, if your interest, like mine, is in developing code that
> folks will just use, then Apache will save you some hassle dealing with
> compaliners.  But, depending on your free software political agenda,
> this may not be acceptable to you.
>
> Doug
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> CLucene-developers mailing list
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers
>
>

Re: [CLucene-dev] Re: license (clarification)

[Doug C. <cu...@lu...>]

Max Khesin wrote:
> Doug? What do you think?

I hate dealing licensing issues, but they are important.

This is Ben's decision, as he's written the clucene code.

Some tips:
   - One should be careful about who copyright is assigned to, as only 
that party can change the copyright and license.  So once you assign the 
copyright to the Apache Foundation, or the FSF, you cannot change it.  I 
couldn't find any copyright statements in the CLucene code.  It's 
probably a good idea to add one to each file.
   - If you use GPL or LGPL then folks (like Max) will complain 
endlessly.  I initially selected GPL for Lucene without thinking much 
about it.  Folks complained and I switched to LGPL.  They complained 
less, but still complained.  With the move to Apache the complaints 
stopped.  So, if your interest, like mine, is in developing code that 
folks will just use, then Apache will save you some hassle dealing with 
compaliners.  But, depending on your free software political agenda, 
this may not be acceptable to you.

Doug

[CLucene-dev] Re: license (clarification)

[Max K. <ma...@to...>]

Hi guys,
since I asked the original q-n and caused some confusion let me add more:
when I said 'proprietary project' I meant the project I am working on not
clucene. Having to confirm to LGPL will be very restrictive. And when I
said that clucene should be under apache I did not make any legal claim (I
am not a lawer :) I was only saying that this would make sense according
to the original authors' intention. Doug? What do you think?

thanks,
max.

[CLucene-dev] re: license (clarification)

[Maxim K. <ma...@fl...>]

Hi guys, 

Sorry I caused a bit of trouble with the cryptic question. What I meant
is that clucene being under lgpl is not a good result for the
proprietary project I am working on. I also did not make any legal
claims that clucene should be under apache like lucene, all I meant is
that it would make sense to go along with the original authors'
intentions. So, are we good with Apache?

 

Max.

Re: [CLucene-dev] license

[Ben v. K. <be...@vi...>]

I have no idea what he is talking about... but he raised a valid point about
the apache license.

He originally asked a question whether the license was gpl or apache (since
the package actually currently
still contains an apache license file)... anyway, this was his reply after i
said lgpl.

ben


----- Original Message -----
From: Jimmy Pritts <jp...@sd...>
To: <clu...@li...>
Sent: Thursday, July 03, 2003 6:47 AM
Subject: Re: [CLucene-dev] license


> Hey Ben,
>
> I read the Apache licenese and it is very simple and doesn't place any
> unreasonable obligations on the user.  I would not have an issue with
> clucene being changed to Apache.
>
> Who is Max, and what is he trying to say.  "That is not a good result
> for a proprietary project" means what?  What is not a good result?
> Also forgive what might be a rhetorical question, but what does Max
> mean when he says Lucene is proprietary. Does he mean to say that
> clucene is in violation of the Apache license?  And what does Max mean
> by saying, "I have to make some decisions"?
>
> Regards,
>   Jimmy.
>
>
> "Ben van Klinken" <be...@vi...> writes:
>
> >     Hi guys,
> >
> > I got an email:
> > -----
> > That is not a good result for a proprietary project. :(. Perhaps you
guys
> > should consider Apache, which is what lucene is under. Anyway, if you
find
> > out quickly I would really appreciate it - I have to make some
decisions.
> >
> > Thanks a lot,
> >
> > Max.
> > ------
> >
> > What do you think? Is it better that it is the same as lucene.
> > Jimmy i know we talked about this, but maybe apache is better? If that
still
> > is ok with your project.
> >
> > Ben
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> > _______________________________________________
> > CLucene-developers mailing list
> > CLu...@li...
> > https://lists.sourceforge.net/lists/listinfo/clucene-developers
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> CLucene-developers mailing list
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers
>

Re: [CLucene-dev] license

[Jimmy P. <jp...@sd...>]

Hey Ben,

I read the Apache licenese and it is very simple and doesn't place any
unreasonable obligations on the user.  I would not have an issue with
clucene being changed to Apache.

Who is Max, and what is he trying to say.  "That is not a good result
for a proprietary project" means what?  What is not a good result?
Also forgive what might be a rhetorical question, but what does Max
mean when he says Lucene is proprietary. Does he mean to say that
clucene is in violation of the Apache license?  And what does Max mean
by saying, "I have to make some decisions"?

Regards, 
  Jimmy.

 
"Ben van Klinken" <be...@vi...> writes:

>     Hi guys,
> 
> I got an email:
> -----
> That is not a good result for a proprietary project. :(. Perhaps you guys
> should consider Apache, which is what lucene is under. Anyway, if you find
> out quickly I would really appreciate it - I have to make some decisions.
> 
> Thanks a lot,
> 
> Max.
> ------
> 
> What do you think? Is it better that it is the same as lucene.
> Jimmy i know we talked about this, but maybe apache is better? If that still
> is ok with your project.
> 
> Ben
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> CLucene-developers mailing list
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers

[CLucene-dev] license

[Ben v. K. <be...@vi...>]

    Hi guys,

I got an email:
-----
That is not a good result for a proprietary project. :(. Perhaps you guys
should consider Apache, which is what lucene is under. Anyway, if you find
out quickly I would really appreciate it - I have to make some decisions.

Thanks a lot,

Max.
------

What do you think? Is it better that it is the same as lucene.
Jimmy i know we talked about this, but maybe apache is better? If that still
is ok with your project.

Ben

[CLucene-dev] [ clucene-Bugs-757559 ] linux port

[SourceForge.net <no...@so...>]

Bugs item #757559, was opened at 2003-06-20 00:27
Message generated for change (Settings changed) made by ustramooner
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=558446&aid=757559&group_id=80013

Category: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: jimmy pritts (jbpritts)
Assigned to: Nobody/Anonymous (nobody)
Summary: linux port

Initial Comment:
Attached is the Linux port source tree

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=558446&aid=757559&group_id=80013

Re: [CLucene-dev] multithreads

[Ben v. K. <be...@vi...>]

I agree, I'm all with simplicity on this one. There's no need to go adding
libraries that are not completelly necessary. I'll have a go using macros...
and if someone could test it on linux :)

I'll put up Jimmy's linux scripts soon. I had to make a few changes, as
visual studio wouldn't compile. I won't make a release, so if you guys would
test on linux, and i'll test with cygwin.

Thanks,
ben

----- Original Message -----
From: Doug Cutting <cu...@lu...>
To: <clu...@li...>
Sent: Thursday, June 19, 2003 5:00 AM
Subject: Re: [CLucene-dev] multithreads


> I'm not sure a thread library is needed so much as a mutex library that
> is compatible with whatever thread libraries folks end up using.  Like
> Java Lucene, CLucene should be thread-safe, but not itself
> multithreaded.  But I'[m probably just being over-precise: a particular
> mutex implementation will probably only work with a particular thread
> implementation.
>
> I've heard good things about the Boost Libraries
> (http::/www.boost.org/).  They have a portable C++ thread library that
> includes a mutex implemenation.  However this might be overkill.  You
> might just want to define a couple of macros, like MAKE_MUTEX, and
> WITH_MUTEX, and then define them differently for different platforms.
>
> Doug
>
> Ben van Klinkehn wrote:
>
> >    Hi everyone,
> >
> >I thought I'd ask for your opinions on clucene. At the moment
multithreading
> >support is not implemented. This was mainly because i wasn't sure what
> >library to use for this... as far as portability, etc is concerned. What
do
> >you think? There's a pthreads port for windows around that i've seen...
or
> >does anyone have a better idea?
> >
> >ben
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: INetU
> >Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!

> >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> >_______________________________________________
> >CLucene-developers mailing list
> >CLu...@li...
> >https://lists.sourceforge.net/lists/listinfo/clucene-developers
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> CLucene-developers mailing list
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers
>

Re: [CLucene-dev] Linux port

[Jimmy P. <jp...@sd...>]

I tried to submit an attachment as a bug report but sourceforge keeps
giving me "Error Invalid Filename".  I changed the file name, but it
still happened.  I suspect that the file is too large or sourceforge
is too bogged down for some reason.  You can get the Linux files here:

http://rgr.freeshell.org/clucene/index.html

Jimmy

Doug Cutting <cu...@lu...> writes:

> Jimmy Pritts wrote:
> > I will send via attachment the first Linux port to Doug Cutting and
> > Ben van Klinkehn.
> 
> A better way to distribute things like this is to add a bug to the bug
> database (something like "need linux port") and then attach the
> .tar.gz file to the bug.  Then we can use the bug report system to
> track the progress of integrating these changes.
> 
> Doug
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> CLucene-developers mailing list
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers

[CLucene-dev] [ clucene-Bugs-757559 ] linux port

[SourceForge.net <no...@so...>]

Bugs item #757559, was opened at 2003-06-19 17:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=558446&aid=757559&group_id=80013

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: jimmy pritts (jbpritts)
Assigned to: Nobody/Anonymous (nobody)
Summary: linux port

Initial Comment:
Attached is the Linux port source tree

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=558446&aid=757559&group_id=80013

Re: [CLucene-dev] Linux port

[Doug C. <cu...@lu...>]

Jimmy Pritts wrote:
> I will send via attachment the first Linux port to Doug Cutting and
> Ben van Klinkehn. 

A better way to distribute things like this is to add a bug to the bug 
database (something like "need linux port") and then attach the .tar.gz 
file to the bug.  Then we can use the bug report system to track the 
progress of integrating these changes.

Doug

[CLucene-dev] Linux port

[Jimmy P. <jp...@sd...>]

OK, The linux port is essentially done.  clucene is built both as a
shard object and a static library on Linux.  I am able to build an
index of a large archive of html files and search them with the demo
under examples. tests under examples builds as well but has some
runtime problems.  I will defer these until later as they are not
critical to getting started on Linux.  The problems don't look bad.
The port uses GNU autotools.  I have the following versions installed:

Autoconf 2.57
Automake 1.72
Libtool 1.5a

I am using GCC version 3.2.2.  This is important with repsect to the
autotools as well, because the gcc version affects the way autotools
calculates dependencies.  

If you use significantly older versions, I can almost guarantee
issues.  This is because each of the autotools is constantly changing
with little regard to backward compatability or even compatiability
with the other autotools.  I can try to assist you if you run into
problems.  

The linux source tree mirrors the Windows source tree purposely.
This was done so that eventually one download can build on both
OSes.  In fact, this is almost already a reality.  

The following will get you building assuming that you have suffciently
recent buld tools installed.  

1.) unpack tarball 
2.) cd clucene
3.) ./bootstrap

The following is what you should see...

++ libtoolize --force --copy --ltdl --automake
++ aclocal -I /usr/share/libtool/libltdl
++ autoconf
++ autoheader
++ automake -a --copy --foreign

If this happens breathe a sigh of relief.

4.) cd build
5.) ../configure CXXFLAGS="-g -DCOMPILER_GCC" CFLAGS="-g -DCOMPILER_GCC" --prefix=/home/your_name/clucene_test

6.) a lot of stuff will fly by the screen.  At the very end of the
output you should see:

config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating src/CLucene/Makefile
config.status: creating src/CLucene/analysis/Makefile
config.status: creating src/CLucene/analysis/standard/Makefile
config.status: creating src/CLucene/document/Makefile
config.status: creating src/CLucene/index/Makefile
config.status: creating src/CLucene/queryParser/Makefile
config.status: creating src/CLucene/search/Makefile
config.status: creating src/CLucene/store/Makefile
config.status: creating src/CLucene/util/Makefile
config.status: creating examples/Makefile
config.status: creating examples/demo/Makefile
config.status: creating examples/tests/Makefile
config.status: creating examples/tests/test/Makefile
config.status: creating examples/tests/test/search/Makefile
config.status: creating examples/tests/test/queryParser/Makefile
config.status: creating config.h
config.status: executing depfiles commands

This is a very good sign.

7.) make install

7.1.) things will churn for a very long time, the clucene library will
be built as well as the examples.

8.) check /home/your_name/clucene_test/bin and /home/your_name/clucene_test/lib

In bin you should see:
demo test

In lib you should see:
libclucene.so.0.0.0 libclucene.la libclucene.a 
and symbolic links to these files.

9.) export LD_LIBRARY_PATH=/home/your_name/clucene_test/lib
10.) run the demo in bin directory
11.) create tests.store in bin directory, run the tests.  It will fail but
problems appear to be minor.  I will address these later.

If you made it to 11, then I am very pleased.  Most likely the build
scripts will need to be tweaked to run on your system, or you will
have to upgrade.  Shoot me an E-Mail if things turn out to be an
unmitigated disaster.

I will send via attachment the first Linux port to Doug Cutting and
Ben van Klinkehn. 

Cheers,
  Jimmy.

 

Re: [CLucene-dev] multithreads

[Jimmy P. <jp...@sd...>]

Currently I have demo linked and running against clucene.  I have to
trace through the execution because clucene is segfaulting.  The
segfaults are coming mostly as a result of different behavior from the
Linux filesystem calls.  For example, in the directory traversal code,
the nonported code does not take into accout directories . and .. when
traversing.  Also the non ported code does not distinquish between
directories and file names, which also needs to happen in Linux when
using the native dirent structures (which I used in the port).  I am
very close to getting it working, and will submit something tonight.

I second the vote for Boost.  Boost would solve a lot of portability
problems.  

The boost::filesystems library would take care of the filesystem
differences.  boost::date_time would do the same for date/time
portability issues, as well as the need for a robust date/time class.
boost::threads would take care of the need for a portable thread
classes.  There are many more libraries that would prove useful as
well: www.boost.org

I've used Boost in another project, and it works very well with GCC.
Their regression reports state that their stuff plays well with MSVC 7
and better.  It is my experience that the boost libraries clean up
code, and they are also easy to use and well designed.

After I submit the quick and dirty port of clucene, I would be willing
to help with converting parts of clucene to use Boost. Look forward to
everyone's thoughts on this...

Jimmy.



Doug Cutting <cu...@lu...> writes:

> I'm not sure a thread library is needed so much as a mutex library
> that is compatible with whatever thread libraries folks end up using.
> Like Java Lucene, CLucene should be thread-safe, but not itself
> multithreaded.  But I'[m probably just being over-precise: a
> particular mutex implementation will probably only work with a
> particular thread implementation.
> 
> I've heard good things about the Boost Libraries
> (http::/www.boost.org/).  They have a portable C++ thread library that
> includes a mutex implemenation.  However this might be overkill.  You
> might just want to define a couple of macros, like MAKE_MUTEX, and
> WITH_MUTEX, and then define them differently for different platforms.
> 
> Doug
> 
> Ben van Klinkehn wrote:
> 
> >    Hi everyone,
> >
> >I thought I'd ask for your opinions on clucene. At the moment multithreading
> >support is not implemented. This was mainly because i wasn't sure what
> >library to use for this... as far as portability, etc is concerned. What do
> >you think? There's a pthreads port for windows around that i've seen... or
> >does anyone have a better idea?
> >
> >ben
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: INetU
> >Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> >_______________________________________________
> >CLucene-developers mailing list
> >CLu...@li...
> >https://lists.sourceforge.net/lists/listinfo/clucene-developers
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> CLucene-developers mailing list
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers