Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On 28 April 2018 at 11:56, Dima Kogan wrote:
| Andreas Tille <andreas@an3as.eu> writes:
|
| > On Fri, Apr 27, 2018 at 06:36:51PM +0200, S�stien Villemot wrote:
| >
| >> There is also a licensing issue: using GPL'd software (e.g. GNU
| >> Octave) with MKL is not allowed.
| >
| > I think that's a pretty strong reason to rate non-free software lowest
| > in the alternatives. Packaging useful non-free software is fine but
| > ranking it higher than free alternatives seems in contrast with our
| > social contract. Users who want to use it should be able to handle
| > alternatives system.
|
| I really would like to see MKL having the highest priority.
|
| Is the licensing issue only there when any other components being linked
| are licensed under the GPL? If so, we need to either
|
| 1. actually handle this issue to make the link fail in cases of license
| violations
|
| 2. not ship MKL at all
|
| 3. decide that the user is sophisticated-enough to manually figure this
| out
|
| Currently we're on the path to option 3. non-free repos are already
| opt-in, and the user already needs to do manual work to get them. If
| they have done this manual work, that's plenty of an indication that
| they have decided that license purity isn't a priority for them.
|
| If I was a user who manually added the non-free repos and then manually
| installed the mkl libraries, I'd be aggravated to find out that there's
| yet another hoop I need to jump through to actually use these libraries.
| This would be a waste of my time, especially since I have already taken
| actions to clearly indicate that I want MKL.
|
| We can decide that we're not interested in providing a license-impure
| option, but then we shouldn't be providing a non-free, and we don't need
| to rehash that argument.
Seconded.
Going through all this work to end up with a priority below all alternatives
is absurd. It effectively _hides_ the MKL.
Remember "our priority are our users" ? If we decide to build and ship this
within the project (even via non-free/contrib) then it may as well be useful.
If we decide that we are too pure for this, then we can indeed move on. But
let's now ship crippling packages that only pretend to help our users.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: