lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Carlson <carl...@bookandhammer.com>
Subject Re: Lucene Sandbox now official
Date Mon, 08 Apr 2002 20:04:36 GMT
Hi,

The only concern I have is if we house and distribute the source, I don't
know what the legal issues are if it not under an APL license.
This issue has come up many times on this list, with Junit and JavaCC.

These binaries had to have special permission or be validated under the
license to be part of the lucene CVS.
I think all contributions need to be source contributions under APL or go to
the contributions area of the web page.

As far as changing their packaging, I just think it would be nicer, but I'm
flexible.

Also, from your email I didn't understand your opinion of the desire route.
#1 or #2.

Let's see if we can finalize this today. I'll also send an email to
jakarta-general to find out if there are any legal issues.

Thanks

--Peter


On 4/8/02 8:02 AM, "Otis Gospodnetic" <otis_gospodnetic@yahoo.com> wrote:

> Hm, I thought we already covered this.
> 
> I think contributions will fall in at least 2 categories:
> 1. Contributions whose home is Lucene Sandbox repository
> 2. Contributions whose home is elsewhere, and that are just dumped in
> Lucene Sandbox in order to:
>  a) keep them in one place and allow Lucene users to find all
> Lucene-related applications easily and in one place instead of doing
> web searches, or mailing list archive searches, etc.
>  b) ensure that a copy of the contributed software is preserved, even
> if the original contributor's site becomes a part of history or
> something such.
>  c) develop them further, merge them, learn from them, etc. and
> create new applications out of them.  That's the contribution to
> project metamorphosis, as I understand it.
>  d) maybe something else that I can't think of right now.
> 
> My opinion is that if we choose to repackage contributions to fit into
> our contributions package tree, we will run into problems when
> contributors want to provide a new version of their code, if they do
> not fall under case 1 above.  As they will continue to develop code
> under their own package tree, on their own machines, maybe under their
> own CVS, etc., they will not necessarily want to change their code to
> fit Jakarta/Lucene package structure and when they fix bugs or release
> new version we'll have a tough time merging the two code bases.
> I wouldn't want to do that :).
> 
> If contributors choose the 1. route then they can restructure the code,
> so that it fits the new environment.  I think then they may have to
> switch to APL, as well, but I don't know much about licensing side of
> things.
> I think this would be the desired route, as that would ensure that the
> code in this repository is more up to date, et cetera.
> 
> This is just what I think.  I hope this doesn't cause long discussions
> :)
> My 0.02 Reals.
> 
> Otis
> 
> 
> --- Peter Carlson <carlson@bookandhammer.com> wrote:
>> 
>> 
>> I was thinking that the contributions in the sandbox area would be
>> source
>> contributions under the APL license. Other contributions that are
>> basically
>> references can still be added through the contributions page.
>> 
>> I guess want I am not thinking the contributions area is just a hodge
>> podge
>> of unorganized stuff. It is structured repackaged (org.apache.lucene)
>> contributions from contributors who are taking ownership. There may
>> be some
>> exceptions to the organization if the contributions are not related
>> to
>> lucene functionality directly (i.e. Erik Hatcher's indexing ant
>> task). Again
>> this does not stop us from adding other's contributions (binaries,
>> non-repackaged) to the contributions area.
>> 
>> Thoughts?
>> 
>> 
>> I agree with your naming convention changes.
>> 
>> Thanks
>> 
>> --Peter
>> 
>> 
>> On 4/4/02 8:22 AM, "Otis Gospodnetic" <otis_gospodnetic@yahoo.com>
>> wrote:
>> 
>>> Peter,
>>> 
>>>> Does everyone agree on that we should following this structure and
>>>> naming convention?
>>>> 
>>>> 
>>>> jakarta-lucene-sandbox/README.txt
>>>> jakarta-lucene-sandbox/LICENSE.txt
>>>> jakarta-lucene-sandbox/index.html
>>>> jakarta-lucene-sandbox/CHANGES.txt
>>>> jakarta-lucene-sandbox/contributions/CHANGES.txt
>>>> jakarta-lucene-sandbox/contributions/build/build.xml
>>>> jakarta-lucene-sandbox/contributions/docs/...
>>>> jakarta-lucene-sandbox/contributions/[contribution]/src/...
>>> 
>>> Not all contributions may include source.
>>> I imagine some contributions will come as an archive of .class
>> files,
>>> too.
>>> 
>>> 
>> 
> jakarta-lucene-sandbox/contributions/[contribution]/xdocs/about[contribution
>>>> ].xml
>>> 
>>> How about: about-[contribution].xml, it's a little easier to read.
>>> 
>>>> jakarta-lucene-sandbox/contributions/[contribution]/build.xml
>>> 
>>> Not all contributions will have sources, so some may not need this.
>>> 
>>>> jakarta-lucene-sandbox/contributions/[contribution]/readme.txt
>>> 
>>> How about README.txt, it's more common.
>>> 
>>>> jakarta-lucene-sandbox/projects/[project]/src/...
>>>> jakarta-lucene-sandbox/projects/[project]/docs/...
>>>> jakarta-lucene-sandbox/projects/[project]/xdocs/...
>>>> jakarta-lucene-sandbox/projects/[project]/build.xml
>>>> jakarta-lucene-sandbox/projects/[project]/README.txt
>>>> jakarta-lucene-sandbox/projects/[project]/CHANGES.txt
>>>> jakarta-lucene-sandbox/projects/[project]/LICENSE.txt
>>>> 
>>>> Where [contribution] is the name of the contribution
>>>> [project] is the name of the subproject in the sandbox area.
>>>> The contribution/build directory contains a build.xml which run
>> all
>>>> contributions build scripts.
>>>> jakarta-lucene-sandbox/contributions/docs/... Would contain all
>>>> created html
>>>> files from the each contributions xdocs/about[contribution].xml
>>>> 
>>>> I'll create the base files when we get buy off.
>>>> 
>>>> The distinction between a contribution and a project is a little
>>>> fuzzy, but
>>>> projects would be for functionality outside the scope of Lucene's
>>>> current
>>>> API, where contributions would be able to be integrated into the
>>>> current API
>>>> (i.e. Analyzers, queryParsers, ...).
>>> 
>>> I may be misunderstanding this.
>>> I'd imagine contributions to be code (source or binaries or...)
>> that
>>> various people provide, which we then either provide as is, or use
>> bits
>>> and pieces of to refactor in specific projects.
>>> These projects then eventually become a part of Lucene (not core,
>> but
>>> applications/extensions).
>>> The crawler+indexer may be one such project, and it may get its
>> pieces
>>> from various people's contributions.
>>> 
>>>> Please provide feedback so we can finalize this.
>>>> 
>>>> Thanks for everyone's input and patience.
>>>> 
>>>> Thanks to Brian for recommending the new CVS. I think it will be
>>>> great to
>>>> get some more Lucene contributors more directly involved if they
>> are
>>>> willing.
>>>> 
>>>> --Peter
>>> 
>>> Otis
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> 
> --
> To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message