Red Hat Bugzilla – Bug 459153
Review Request: ann - Library for searching Approximate Nearest Neighbors
Last modified: 2008-11-25 11:56:51 EST
Spec URL: http://fedora.danny.cz/ann.spec
SRPM URL: http://fedora.danny.cz/ann-1.1.1-1.fc10.src.rpm
ANN is a library written in the C++ programming language to support both
exact and approximate nearest neighbor searching in spaces of various
dimensions. It was implemented by David M. Mount of the University of
Maryland, and Sunil Arya of the Hong Kong University of Science and
Technology. ANN (pronounced like the name ``Ann'') stands for
Approximate Nearest Neighbors. ANN is also a testbed containing
programs and procedures for generating data sets, collecting and
analyzing statistics on the performance of nearest neighbor algorithms
and data structures, and visualizing the geometric structure of these
I believe the license is LGPLv2+; where do you see that it is restricted to v2 only?
There is really no need to duplicate those three documentation files between the main and -libs packages. You can duplicate the actual license text if you really feel the need to (even though the lawyers have indicated that it is not necessary) but there's really no point in duplicating things like ReadMe.txt.
* source files match upstream:
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
X license field does not match the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper (none).
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint is silent.
* final provides and requires are sane:
ann = 1.1.1-1.fc10
ann(x86-64) = 1.1.1-1.fc10
ann-devel = 1.1.1-1.fc10
ann-devel(x86-64) = 1.1.1-1.fc10
ann-libs = 1.1.1-1.fc10
ann-libs = 1.1.1-1.fc10
ann-libs(x86-64) = 1.1.1-1.fc10
* %check is not present; no test suite upstream.
I have no idea how to test this package. I can at least run the ann2fig
binary but I don't know what to pass to it. Maybe there's something in the
sample directory, but it doesn't seem to be installed anywhere.
* shared libraries installed:
ldconfig called properly.
unversioned .so link is in the -devel package.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
X documentation is duplicated between packages.
* file permissions are appropriate.
* scriptlets are OK (ldconfig).
* code, not content.
* headers are in the -devel package.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.
You should be right with the license - the sources specify "Lesser GNU Public License" without version and there is no "or any later version" clause. So LGPLv2+ should be right.
The *.txt docs are now included only in the -lib subpackage, because it will be always installed.
You can run the tests manually after building the package eg. in mock. There is even an expected output, but it differs due the newer version (1.0 vs. 1.1.1) and the package doesn't have performance statistics enabled. So it cannot be easily automated.
Updated Spec URL: http://fedora.danny.cz/ann.spec
Updated SRPM URL: http://fedora.danny.cz/ann-1.1.1-2.fc10.src.rpm
(In reply to comment #2)
> You should be right with the license - the sources specify "Lesser GNU Public
> License" without version and there is no "or any later version" clause. So
> LGPLv2+ should be right.
Copying.txt explicitly says:
"This program is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser Public License as published by the
Free Software Foundation; either version 2.1 of the License, or (at your
option) any later version."
=> This is the "later version" clause.
"GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999..."
=> This is a copy of LGPLv2.1.
=> This package is LGPLv2+'ed
(In reply to comment #3)
> (In reply to comment #2)
> > You should be right with the license - the sources specify "Lesser GNU Public
> > License" without version and there is no "or any later version" clause. So
> > LGPLv2+ should be right.
> Copying.txt explicitly says:
> "This program is free software; you can redistribute it and/or modify it
> under the terms of the GNU Lesser Public License as published by the
> Free Software Foundation; either version 2.1 of the License, or (at your
> option) any later version."
> => This is the "later version" clause.
> License.txt says:
> "GNU LESSER GENERAL PUBLIC LICENSE
> Version 2.1, February 1999..."
> => This is a copy of LGPLv2.1.
> => This package is LGPLv2+'ed
OK, thanks for explanation. I am really not a licensing expert, so I thought that license text in the source files (*.cpp, *h)) is prioritized against the included *.txt files and it leads into LGPLv2+ too.
Dan, I am not an expert either, but (quoting from IRC): "<f13> wolfy: what's in the individual source files wins."
However, in this case the source files reference the license file (via ReadMe.txt) so probably that the author wanted his source to be LGPv2+ but failed to properly mention that in the source files. I'd say it's one of those cases where one should send a mail to the author politely asking for clarifications.
I don't think there's any real ambiguity here. Sure, it would be nice if upstream just used the license block specified by the LGPL in their source files instead of having folks make a trip through three files to find the info, but I don't think the currently situation leaves any real doubt as to what the license is. Maybe you could ask them, but since the last update to this software was two years ago, I doubt you'll see much of a response.
In any case, the issues I had are fixed.
(In reply to comment #6)
> I don't think there's any real ambiguity here.
Agreed. An author's intention is what matters at court. IMO, they did express their intention very clearly (LGPLv2+), in this case.
The only critical situation would be if their sources were containing inlined license terms/clauses which would be contradicting their "global detached license". I haven't checked if this this applies in this particular case.
Thanks to all for their opinions. I should be more educated in the licensing area now. I will continue in the process during next week after my return from vacation.
New Package CVS Request
Package Name: ann
Short Description: Library for searching Approximate Nearest Neighbors
imported and built
Package Change Request
Package Name: ann
New Branches: EL-5