Description of problem: octave seems to be bundling a number of libraries: amos - available here http://netlib.org/amos/ but possibly non-free license http://www.acm.org/publications/policies/softwarecrnotice/ (readme says it's based on TOMS algorithm 644), also see http://web.archive.org/web/20080805032259/http://users.bigpond.net.au/amiller/toms.html arpack (available in Fedora) daspk - seems to be related to version 2.0 available here http://www.engineering.ucsb.edu/~cse/software.html dassl available here http://www.engineering.ucsb.edu/~cse/software.html gl2ps (available in Fedora) fftpack - available here http://www.netlib.org/fftpack/ (seems to be bundled in scipy, too) odepack - available here http://www.netlib.org/odepack/ and repackaged here http://www.shocksolution.com/math_tools/odepack/ quadpack - available here http://www.netlib.org/quadpack/ ranlib (randlib?) 1.3 - available here http://lib.stat.cmu.edu/general/Utexas/ Version-Release number of selected component (if applicable): octave-3.4.0-1
Blocking FE-Legal for possible amos issue.
I don't see any real evidence that the amos files are derived from the TOMS files. The statement about being an "improved version" of the algorithms almost certainly means that it implements a faster way of doing the same math, not that there is any other relationship, and I'm inclined to assume that unless there is real evidence to the contrary. The bundling is a real issue though. Lifting FE-Legal
Is it octave upstream that is doing the bundling (i.e. are these bundles in the regular tarball)? Odd considering that Octave is an official GNU project and I thought that they frown upon bundling too.
At least fftpack is not used, since FFTW is preferred over it. The same may apply to the other ones as well...
(In reply to comment #2) > I don't see any real evidence that the amos files are derived from the TOMS > files. I think that amos library is derived from the TOMS library. See Reference URI. Reference: http://pl.digipedia.org/usenet/thread/12697/9625/ http://octave.1599824.n4.nabble.com/Fwd-OctDev-libcruft-amos-nonfree-Bessel-code-in-Octave-td4632360.html http://octave.1599824.n4.nabble.com/Can-we-freely-use-AMOS-in-Octave-td4642557.html http://www.netlib.org/toms/644 http://www.netlib.org/amos/cairy.f
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Based on http://octave.1599824.n4.nabble.com/Can-we-freely-use-AMOS-in-Octave-td4642557.html, I think it is safe to consider AMOS as being in the Public Domain. The bundling is still an issue.
I've sent a message to the netlib folks to see if they can make it any easier to download the files. Yeesh.
Any progress in unbundling? Looks like current version bundles even more stuff. libgui/qterminal -> QTerminal (https://github.com/qterminal/qterminal) liboctave/cruft/ Faddeeva (http://ab-initio.mit.edu/wiki/index.php/Faddeeva_Package) slatec-err (http://www.netlib.org/slatec/err/) slatec-fn -> slatec-fnlib (http://www.netlib.org/slatec/fnlib/) amos, odepack, quadpack and ran(d)lib are still there. da(spk|srt|ssl) seem to have moved to http://iguana.cs.ucsb.edu/wordpress/?page_id=224#linux
Bah, one step forward, two back it seems. Actually, the qterminal in octave seems more like http://code.google.com/p/qterminal/
Ping?
I think there's no point in keeping this bug open as obviously unbundling isn't happening. The bundled codes are declared in Provides, so packaging guidelines are being followed at least.