11:28 a.m.
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:50 a.m.
New subject: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 at 18:39, Miro Hrončok <mhroncok(a)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.
--
Iñaki Úcar
9:14 a.m.
New subject: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
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>
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
11:11 a.m.
New subject: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Fri, 3 Jul 2020 at 16:15, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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(a)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
--
Iñaki Úcar
9:19 a.m.
New subject: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
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(a)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(a)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
10:20 a.m.
New subject: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Sat, 4 Jul 2020 at 16:20, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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
--
Iñaki Úcar
2:55 p.m.
New subject: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
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(a)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
1389
days inactive
1392
days old
6 comments
3 participants
participants (3)
-
Iñaki Ucar -
Miro Hrončok -
Zbigniew Jędrzejewski-Szmek