Den 25.06.2010 16:28, skrev Nathaniel Smith:
> Not to mention, if MKL were required then GPL'ed projects could not
> legally use SciPy. (Plus it would annoy the FOSS zealots who would
> really rather not use a proprietary library at all. (Like me.))
>
Are you suggesting GPL'd programs cannot use proprietary DLLs? How can
you legally run a GPL'd Python program on Windows, when msvcr90.dll and
the OS are closed source?
If a GPL'd program can use msvcr90.dll, it can use MKL as well. There is
no difference here.
Also, optionally using MKL is different from requiring MKL. We can build
SciPy and NumPy against MKL even today, e.g. for LAPACK and BLAS.
Doesn't that exclude their use from your GPL'd project?
I believe you are thinking backwards, IANAL but I am quite sure it works
like this:
- A GPL'd project can link against whatever library it needs.
- A GPL incompatible project cannot link against a GPL'd library.
GPL is an descending infection from library to project, not an ascending
infection, to speak in medical termes. Ascending GPL infection would not
make sence, since the library is the property of someone else.
All I am saying is this: Why not allow MKL as an alternative to FFTPACK
as well?
Sturla