OBOn Sat, Apr 28, 2018 at 02:35:29PM -0500, Dirk Eddelbuettel wrote: > > 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?bastien 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. The exact text of point 4 of the Social Contract is “Our priorities are our users and free software”. You seem to have forgotten the second half of the sentence. > 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. This has nothing to do with crippling the MKL package. Reference BLAS and ATLAS have already a lower priority than OpenBLAS. See: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries These priorities are meant to express what Debian thinks is the best option to implement BLAS. I can’t see how we could collectively think that MKL is better than OpenBLAS: we have always valued freedom above performance or features, it is the essence of this project. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: PGP signature