OBOn Sat, Apr 28, 2018 at 11:56:02AM -0700, 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. The non-free section is enabled on a lot of bare metal machines, because you almost always need a firwmare blob to use mainstream hardware. Or you may want to read documentation under GFDL-with-invariant-section. So enabling the non-free section does not necessarily mean that you are happy with using non-free software, especially when there are free alternatives. > 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. Note that this is already the case if you want to use reference BLAS or ATLAS but have OpenBLAS installed (because the latter has the highest priority). So we are not special-casing MKL here. > 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. There seems to be a consensus in favor of packaging MKL, so I don’t understand why you’re saying this. We’re just talking about clearly expressing the fact that Debian prefers free alternatives and making sure that the user is aware of licensing issues with dynamic linking. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: PGP signature