What's Fedora's stance on linking GPL-only libraries into the same process as a library which is considered GPL-incompatible (such as 4-clause BSD) if this linking happens rather indirectly?
We currently link psql against both libreadline and libcrypto/libssl (OpenSSL), so if that is okay, more indirect linking should be acceptable as well.
However, I'm not sure I'd appreciate that if I were a GPL-only library author who chose that license deliberately (perhaps even with a desire to sell alternative licensing), and some intermediate libraries makes my work available under a more permissive license, only wrapped in a different programming interface.
On 11/19/2013 02:11 PM, Florian Weimer wrote:
What's Fedora's stance on linking GPL-only libraries into the same process as a library which is considered GPL-incompatible (such as 4-clause BSD) if this linking happens rather indirectly?
We currently link psql against both libreadline and libcrypto/libssl (OpenSSL), so if that is okay, more indirect linking should be acceptable as well.
However, I'm not sure I'd appreciate that if I were a GPL-only library author who chose that license deliberately (perhaps even with a desire to sell alternative licensing), and some intermediate libraries makes my work available under a more permissive license, only wrapped in a different programming interface.
For OpenSSL, we consider that a system library, so the point is somewhat irrelevant in that case.
However, to your larger point, we are not concerned with indirect linking like you describe. We are primarily focused with the direct linking case, though, if there was an egregious case of a shim intended to circumvent that, we'd revisit that on a case-by-case basis.
~tom
== ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸><(((º> OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal
On 11/20/2013 09:48 PM, Tom Callaway wrote:
On 11/19/2013 02:11 PM, Florian Weimer wrote:
What's Fedora's stance on linking GPL-only libraries into the same process as a library which is considered GPL-incompatible (such as 4-clause BSD) if this linking happens rather indirectly?
We currently link psql against both libreadline and libcrypto/libssl (OpenSSL), so if that is okay, more indirect linking should be acceptable as well.
However, I'm not sure I'd appreciate that if I were a GPL-only library author who chose that license deliberately (perhaps even with a desire to sell alternative licensing), and some intermediate libraries makes my work available under a more permissive license, only wrapped in a different programming interface.
For OpenSSL, we consider that a system library, so the point is somewhat irrelevant in that case.
That's a refreshingly different approach which certainly simplifies things. :)
However, to your larger point, we are not concerned with indirect linking like you describe. We are primarily focused with the direct linking case, though, if there was an egregious case of a shim intended to circumvent that, we'd revisit that on a case-by-case basis.
What's the procedure for resolving such potential issues? Post it here and ask for advice?
With Fedora's system library exception, that should never be an issue for Fedora itself, but downstream users might be led to assume that the license of a particular library is more permissive than it actually is.
On 11/21/2013 03:42 AM, Florian Weimer wrote:
What's the procedure for resolving such potential issues? Post it here and ask for advice?
Yes.
With Fedora's system library exception, that should never be an issue for Fedora itself, but downstream users might be led to assume that the license of a particular library is more permissive than it actually is.
Unfortunately, people will assume all number of things with or without our input. :)
~tom
== ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸><(((º> OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal
On 11/21/2013 04:59 PM, Tom Callaway wrote:
On 11/21/2013 03:42 AM, Florian Weimer wrote:
What's the procedure for resolving such potential issues? Post it here and ask for advice?
Yes.
Okay, my concern is with the jbigkit (GPLv2+) dependency of libtiff (under its own, MIT-like license). The GPLed code is used to decode JBIG1 parts of TIFF images.
On 12/16/2013 01:00 PM, Florian Weimer wrote:
On 11/21/2013 04:59 PM, Tom Callaway wrote:
On 11/21/2013 03:42 AM, Florian Weimer wrote:
What's the procedure for resolving such potential issues? Post it here and ask for advice?
Yes.
Okay, my concern is with the jbigkit (GPLv2+) dependency of libtiff (under its own, MIT-like license). The GPLed code is used to decode JBIG1 parts of TIFF images.
Okay. Is there a specific libtiff consumer that is GPLv2+ incompatible?
~tom
== ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸><(((º> OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal
On 12/17/2013 02:57 PM, Tom Callaway wrote:
On 12/16/2013 01:00 PM, Florian Weimer wrote:
On 11/21/2013 04:59 PM, Tom Callaway wrote:
On 11/21/2013 03:42 AM, Florian Weimer wrote:
What's the procedure for resolving such potential issues? Post it here and ask for advice?
Yes.
Okay, my concern is with the jbigkit (GPLv2+) dependency of libtiff (under its own, MIT-like license). The GPLed code is used to decode JBIG1 parts of TIFF images.
Okay. Is there a specific libtiff consumer that is GPLv2+ incompatible?
Candidates are:
graphviz (EPL), hylafax+ (libtiff and BSD with advertising), gnuplot.
InsightToolkit (ASL 2.0) might qualify as well, depending on whether the GPLv3 upgrade can heal the original GPlv2 vs ASL 2.0 conflict. Same for ghostscript (AGPLv3+ and Redistributable, no modification permitted).
These are only direct dependencies. Indirect dependencies will need some coding before I can come up with a list.
On 12/17/2013 10:06 PM, Florian Weimer wrote:
On 12/17/2013 02:57 PM, Tom Callaway wrote:
On 12/16/2013 01:00 PM, Florian Weimer wrote:
On 11/21/2013 04:59 PM, Tom Callaway wrote:
On 11/21/2013 03:42 AM, Florian Weimer wrote:
What's the procedure for resolving such potential issues? Post it here and ask for advice?
Yes.
Okay, my concern is with the jbigkit (GPLv2+) dependency of libtiff (under its own, MIT-like license). The GPLed code is used to decode JBIG1 parts of TIFF images.
Okay. Is there a specific libtiff consumer that is GPLv2+ incompatible?
Candidates are:
graphviz (EPL), hylafax+ (libtiff and BSD with advertising), gnuplot.
InsightToolkit (ASL 2.0) might qualify as well, depending on whether the GPLv3 upgrade can heal the original GPlv2 vs ASL 2.0 conflict. Same for ghostscript (AGPLv3+ and Redistributable, no modification permitted).
These are only direct dependencies. Indirect dependencies will need some coding before I can come up with a list.
Are there any final comments on this matter?
On 03/04/2014 07:51 AM, Florian Weimer wrote:
On 12/17/2013 10:06 PM, Florian Weimer wrote:
On 12/17/2013 02:57 PM, Tom Callaway wrote:
On 12/16/2013 01:00 PM, Florian Weimer wrote:
On 11/21/2013 04:59 PM, Tom Callaway wrote:
On 11/21/2013 03:42 AM, Florian Weimer wrote:
What's the procedure for resolving such potential issues? Post it here and ask for advice?
Yes.
Okay, my concern is with the jbigkit (GPLv2+) dependency of libtiff (under its own, MIT-like license). The GPLed code is used to decode JBIG1 parts of TIFF images.
Okay. Is there a specific libtiff consumer that is GPLv2+ incompatible?
Candidates are:
graphviz (EPL), hylafax+ (libtiff and BSD with advertising), gnuplot.
InsightToolkit (ASL 2.0) might qualify as well, depending on whether the GPLv3 upgrade can heal the original GPlv2 vs ASL 2.0 conflict. Same for ghostscript (AGPLv3+ and Redistributable, no modification permitted).
These are only direct dependencies. Indirect dependencies will need some coding before I can come up with a list.
Are there any final comments on this matter?
Not yet. Still looking into this.
~tom
== ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸><(((º> OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal
On 03/04/2014 07:51 AM, Florian Weimer wrote:
On 12/17/2013 10:06 PM, Florian Weimer wrote:
On 12/17/2013 02:57 PM, Tom Callaway wrote:
On 12/16/2013 01:00 PM, Florian Weimer wrote:
On 11/21/2013 04:59 PM, Tom Callaway wrote:
On 11/21/2013 03:42 AM, Florian Weimer wrote:
What's the procedure for resolving such potential issues? Post it here and ask for advice?
Yes.
Okay, my concern is with the jbigkit (GPLv2+) dependency of libtiff (under its own, MIT-like license). The GPLed code is used to decode JBIG1 parts of TIFF images.
Okay. Is there a specific libtiff consumer that is GPLv2+ incompatible?
Candidates are:
graphviz (EPL), hylafax+ (libtiff and BSD with advertising), gnuplot.
InsightToolkit (ASL 2.0) might qualify as well, depending on whether the GPLv3 upgrade can heal the original GPlv2 vs ASL 2.0 conflict. Same for ghostscript (AGPLv3+ and Redistributable, no modification permitted).
These are only direct dependencies. Indirect dependencies will need some coding before I can come up with a list.
Are there any final comments on this matter?
Sorry, this one took a while to research and nail down.
In this specific instance, with this set of interdependent software, Red Hat is not concerned with the jbigkit license making libtiff (with jbigkit support enabled) incompatible with other Free (but GPL-incompatible) licensed software. This assurance comes from direct correspondence with the jbigkit upstream.
Thanks for your patience,
~tom
== ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸><(((º> OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal
On Wed, 2013-11-20 at 15:48 -0500, Tom Callaway wrote:
For OpenSSL, we consider that a system library, so the point is somewhat irrelevant in that case.
Of course, we should not let that dissuade people from porting to GnuTLS and rendering the question irrelevant for that reason instead :)
On 11/21/2013 05:02 PM, David Woodhouse wrote:
On Wed, 2013-11-20 at 15:48 -0500, Tom Callaway wrote:
For OpenSSL, we consider that a system library, so the point is somewhat irrelevant in that case.
Of course, we should not let that dissuade people from porting to GnuTLS and rendering the question irrelevant for that reason instead :)
That's actually not true—you still need to invoke the system library exception for GPLv2-only programs because one of the dependencies, GMP, is LGPLv3+ in its current versions. Attempts to dual-license it under LPGLv3+ and GPLv2, like GNUTLS itself, have failed so far.
On Fri, 2013-11-22 at 09:51 +0100, Florian Weimer wrote:
That's actually not true—you still need to invoke the system library exception for GPLv2-only programs because one of the dependencies, GMP, is LGPLv3+ in its current versions. Attempts to dual-license it under LPGLv3+ and GPLv2, like GNUTLS itself, have failed so far.
Ah yes, good point. For the Android build of OpenConnect I had set it up to build against GMP 4.2 for that very reason. GnuTLS still works with that version, I believe.
-
David Woodhouse -
Florian Weimer -
Tom Callaway