On Wed, 1 Jul 2020 at 18:39, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: > > On 01. 07. 20 16:24, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > > > == Summary == > > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper > > library, which will set OpenBLAS as system-wide default backend, and > > at the same time will provide a proper switching mechanism that > > currently Fedora lacks. > > > > ... > > > > == Scope == > > * Proposal owners: Modify the SPECs of the BLAS/LAPACK-dependent > > packages to build against FlexiBLAS instead of the current backend > > they are using. > > I wonder, given FlexiBLAS is released under GPL (and not LGPL), whether this > means we would need to change the licenses of all non-GPL packages that will be > linked to FlexiBLAS to GPL. > > CCing legal. Ok, let me recap here, because I wasn't subscribed to the legal list. Basically, FlexiBLAS is a wrapper for an API (BLAS/LAPACK) that is BSD. But to act as a wrapper, a program needs to link against the part of FlexiBLAS that replicates that API, and they just connect symbols to the appropriate backend (this is use 1). On the other hand, FlexiBLAS provides another API that allows programs to hook into the first API, profile, debug, switch the backend in real time... (this is use 2). Here we are talking about use 1, and the question is whether this can be considered under the exception of a "system library", as defined in the first section of GPLv3. If not, the program must be GPL-compatible? Or the program needs to change the license altogether?

I contacted the upstream maintainer about this, and he really wants to permit the use case in this change proposal (I've been working with him 3 weeks to fix bugs and bring a suitable version to Fedora for this), so if this can't be considered a "system library", he is willing to add an exception to the license. This is what he told me: > About the linking problem I could think of an exception, similar to the linking exception in gcc/glibc, which coincides with our "Free for free use" idea. I could add that FlexiBLAS is allowed to be linked against free software with an OSI approved license as none of the flexiblas headers are used at compile-time. In this way all open-source software can use FlexiBLAS no matter if it is BSD/MIT/APACHE/GPL code but those who want to use the special features like switching BLAS within the program or developing debug hooks like the profile hook, have to be compatible to GPL.

On Fri, 3 Jul 2020 at 16:15, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; wrote: > > On Thu, Jul 02, 2020 at 09:50:47AM +0200, Iñaki Ucar wrote: > > On Wed, 1 Jul 2020 at 18:39, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: > > > > > > On 01. 07. 20 16:24, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > > > > > > > == Summary == > > > > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper > > > > library, which will set OpenBLAS as system-wide default backend, and > > > > at the same time will provide a proper switching mechanism that > > > > currently Fedora lacks. > > > > > > > > ... > > > > > > > > == Scope == > > > > * Proposal owners: Modify the SPECs of the BLAS/LAPACK-dependent > > > > packages to build against FlexiBLAS instead of the current backend > > > > they are using. > > > > > > I wonder, given FlexiBLAS is released under GPL (and not LGPL), whether this > > > means we would need to change the licenses of all non-GPL packages that will be > > > linked to FlexiBLAS to GPL. > > > > > > CCing legal. > > > > Ok, let me recap here, because I wasn't subscribed to the legal list. > > Basically, FlexiBLAS is a wrapper for an API (BLAS/LAPACK) that is > > BSD. But to act as a wrapper, a program needs to link against the part > > of FlexiBLAS that replicates that API, and they just connect symbols > > to the appropriate backend (this is use 1). On the other hand, > > FlexiBLAS provides another API that allows programs to hook into the > > first API, profile, debug, switch the backend in real time... (this is > > use 2). > > > > Here we are talking about use 1, and the question is whether this can > > be considered under the exception of a "system library", as defined in > > the first section of GPLv3. If not, the program must be > > GPL-compatible? Or the program needs to change the license altogether? > > The "system library exception" is about allowing a GPL program to be > distributed without the source code for some of the libraries it links > to. But here we're talking about the opposite issue: whether we can > distribute *other* works linked to the GPLv3 library under their > original licenses. The "system library exception" is not relevant and > §5c says "You must license the entire work, as a whole, under this > License to anyone who comes into possession of a copy. This License > will therefore apply, along with any applicable section 7 additional > terms, to the whole of the work, and all its parts, regardless of how > they are packaged." > > FSF insists that dynamically linking with a GPL-covered work is making > a combined work based on the GPL-covered part, and thus the final > product may only be distributed under the GPL, as quoted above [1]. > I think this interpretation is dubious in some cases, but here, when > we're talking about compiling and linking programs against the GPLv3 > headers, it seems reasonable. > > If it would be possible to instead compile packages against some other > blas library, and only substitute flexiblas during dynamic linking at > users' systems, the GPLv3-covered work would only be created then and > we wouldn't need to care about licensing of other packages. That's the thing: this is certainly possible, but from the packaging point of view, it's more difficult, because BLAS and LAPACK are separate shared libraries. You could, for instance, duplicate yet again the BLAS/LAPACK interface into a single library that could be e.g. BSD, then build all the packages against that one, then provide that with FlexiBLAS instead. You could use the separate libraries libblas and liblapack and then have other stubs pointing to FlexiBLAS instead. All this is possible, but it's a ton of duplicated code, effort, etc., and it's ridiculous. So if the above it's perfectly possible and complies with the license, it's also ridiculous that avoiding this extra unnecessary stuff doesn't. > > [1] https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic > > > I contacted the upstream maintainer about this, and he really wants to > > permit the use case in this change proposal (I've been working with > > him 3 weeks to fix bugs and bring a suitable version to Fedora for > > this), so if this can't be considered a "system library", he is > > willing to add an exception to the license. This is what he told me: > > > > > About the linking problem I could think of an exception, similar to the linking exception in gcc/glibc, which coincides with our "Free for free use" idea. I could add that FlexiBLAS is allowed to be linked against free software with an OSI approved license as none of the flexiblas headers are used at compile-time. In this way all open-source software can use FlexiBLAS no matter if it is BSD/MIT/APACHE/GPL code but those who want to use the special features like switching BLAS within the program or developing debug hooks like the profile hook, have to be compatible to GPL. > > Would the maintainer consider switching the whole thing to LGPLv3? > This would preserve the freeness of his code and be much less hassle > for everyone involved, with no interpretation of new legal texts required. LGPL has other implications towards proprietary software, and that's what the authors specifically want to protect, so that's a hard line.

Wouldn't the Classpath Exception [1] be appropriate here? This wouldn't require the interpretation of a new legal text.

On Sat, 4 Jul 2020 at 16:20, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; wrote: > > > > Would the maintainer consider switching the whole thing to LGPLv3? > > > This would preserve the freeness of his code and be much less hassle > > > for everyone involved, with no interpretation of new legal texts required. > > > > LGPL has other implications towards proprietary software, and that's > > what the authors specifically want to protect, so that's a hard line. > > I'm not sure what you mean. LGPL keeps the code free but allows it to be > freely combined with software under different licenses, which is what we > want in this case. Yeap, but it's more permissive also with the FlexiBLAS interface (the one that enables hooking into the duplicated BLAS/LAPACK interface, the one that BLAS/LAPACK consumers are not using), and this is what the authors do not want.

> > Wouldn't the Classpath Exception [1] be appropriate here? This > > wouldn't require the interpretation of a new legal text. > > Classpath exception talks about "executable". This isn't very precise, > but at least in normal speech, a library is not an executable, so the > classpath exception would not cover other libraries which link to > flexiblass. So for example, numpy would not be covered by the exception. True. But what about the "Linking over a controlled interface exception"? That sounds like exactly this case: https://www.gnu.org/licenses/gpl-faq.en.html#LinkingOverControlledInterface