lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject commons-csv and underlying principles
Date Sat, 10 Mar 2012 02:13:15 GMT
There's been a discussion on private@ that could have happened here
about the principles and practicalities of the commons-csv situation.
I'm going to recap from my standpoint, others can then join in.

At some point, a Lucene committer set out to add csv support, and
found some suitable unreleased code in commons. Commons wasn't in any
hurry to release it, and you wanted to release.

I don't want to rehash the particular events that followed, but rather
talk about general principles of the thing.

An Apache release is a source release. It can have external
dependencies. They have to satisfy the license constraints. As best I
understand it, there are only two choices consistent with the rules:

1) just leave a hole and tell users that they need to get it for themselves.

2) make a copy of the commons-csv code inside lucene, with Lucene
package names, and release it.

There has been much discussion of depending on commons-csv binary jar
files (with or without package renaming) that don't come from any
released version in either project. I might be wrong, but I don't
think that this is acceptable in terms of the legal process
surrounding an Apache release.

Note that I haven't mentioned Maven in here anywhere, because, to the
best of my understanding, the situation I'm describing has to be dealt
with -- with or without it.

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


Mime
View raw message