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.
On Wed, 1 Jul 2020 at 18:39, Miro Hrončok mhroncok@redhat.com 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.
Is this possible? Would this be accepted?
Thanks.
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@redhat.com 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.
[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.
Zbyszek
On Fri, 3 Jul 2020 at 16:15, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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@redhat.com 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.
[1] https://fedoraproject.org/wiki/Licensing/GPL_Classpath_Exception
On Fri, Jul 03, 2020 at 06:11:08PM +0200, Iñaki Ucar wrote:
On Fri, 3 Jul 2020 at 16:15, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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@redhat.com 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.
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.
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.
Zbyszek
On Sat, 4 Jul 2020 at 16:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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
On Sat, Jul 04, 2020 at 05:20:48PM +0200, Iñaki Ucar wrote:
On Sat, 4 Jul 2020 at 16:20, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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.
OK. Thanks for the clarification.
Maybe talk with the authors and tell them that a few functions to provide this extra interface are not important enough to create all the hassle with GPLv3 for a commonly used library and that LGPL would protect their code almost as well? I assume that they want their library to be widely used, and this strict licensing will be a constant source of problems because many existing scientific packages are using more liberal licensing and will not want to change their licensing to accommodate flexiblas.
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
Yep, that seems like it would work. The first para contains a legal interpretation of GPLv3 and thus doesn't belong in the exception text. But the rest is OK.
Zbyszek
-
Iñaki Ucar -
Miro Hrončok -
Zbigniew Jędrzejewski-Szmek