On Mon, 2008-08-25 at 20:04 +0200, Hans de Goede wrote:
Hi All,
The story begins here: https://bugzilla.redhat.com/show_bug.cgi?id=446860
...
I would like to suggest the removal of libgnutls-openssl from Fedora,...
That will probably create many legal problems. If there's a way to keep this package, we should.
As many of you know, the basic problem is that the OpenSSL license is incompatible with the GPL: http://www.fsf.org/licensing/licenses/ http://www.gnome.org/~markmc/openssl-and-the-gpl.html http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg426067.html http://lists.debian.org/debian-legal/2002/10/msg00113.html
Any program that links to libgnutls-openssl that has GPL'ed components probably CANNOT be legally linked to OpenSSL.
--- David A. Wheeler
On Tue, 2008-08-26 at 18:30 -0400, David A. Wheeler wrote:
Any program that links to libgnutls-openssl that has GPL'ed components probably CANNOT be legally linked to OpenSSL.
For what it is worth, we consider OpenSSL a system library (aka, a "major component"), as does the FSF.
From GPLv2:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Thus, we're not concerned about OpenSSL and GPL incompatibility.
~spot
Tom "spot" Callaway wrote:
On Tue, 2008-08-26 at 18:30 -0400, David A. Wheeler wrote:
Any program that links to libgnutls-openssl that has GPL'ed components probably CANNOT be legally linked to OpenSSL.
For what it is worth, we consider OpenSSL a system library (aka, a "major component"), as does the FSF.
From GPLv2:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Thus, we're not concerned about OpenSSL and GPL incompatibility.
Erm what about the "unless that component itself accompanies the executable." part, when we put openssl and a using app together on a CD does that not count as "accompanies the executable"? If not that would be great then I can fix this (for now) by simply using the real openssl in gkrellm.
Regards,
Hans
2008/8/27 Hans de Goede j.w.r.degoede@hhs.nl:
Tom "spot" Callaway wrote:
...
For what it is worth, we consider OpenSSL a system library (aka, a "major component"), as does the FSF.
From GPLv2:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Thus, we're not concerned about OpenSSL and GPL incompatibility.
Erm what about the "unless that component itself accompanies the executable." part, when we put openssl and a using app together on a CD does that not count as "accompanies the executable"? If not that would be great then I can fix this (for now) by simply using the real openssl in gkrellm.
Most people consider "accompanies the executable" to mean it is actually packaged with the application, not separately distributed 'as part of the operating system' ... I think Tom's explanation is pretty complete, in fact. If the FSF don't have a problem with it, and if gnutls' openssl compatability layer has a license that might preclude its use with a large number of the software packages we distribute, then I think we should just use openssl until someone produces a compatible library that can be used with gpl v2 software.
Regards,
Hans
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Thus, we're not concerned about OpenSSL and GPL incompatibility.
Erm what about the "unless that component itself accompanies the executable." part, when we put openssl and a using app together on a CD does that not count as "accompanies the executable"?
It clearly does, and we've previously enforced this exact policy based on advice that shipping them together would cause a problem.
Alan
On Tue, 2008-08-26 at 18:41 -0400, Tom "spot" Callaway wrote:
For what it is worth, we consider OpenSSL a system library (aka, a "major component"), as does the FSF.
I just love correcting myself, but I've been straightened out. The FSF does not consider OpenSSL a system library, so this clause doesn't apply.
~spot
Once upon a time, David A. Wheeler dwheeler@dwheeler.com said:
That will probably create many legal problems. If there's a way to keep this package, we should.
As many of you know, the basic problem is that the OpenSSL license is incompatible with the GPL:
Aside from the "system library" exemption already mentioned, most GPL software that links against OpenSSL has a specific exemption in the documentation.
Any program that links to libgnutls-openssl that has GPL'ed components probably CANNOT be legally linked to OpenSSL.
The flip side of that is that libgnutls-openssl is GPLv3+, which means that anything under GPLv2-only or any other non-GPLv3-compatible license may not be able to use it. I'm not sure, since it implements somebody else's interface; can anything using the OpenSSL library API be considered a derived work of libgnutls-openssl (by virtue of linking)?
Chris Adams wrote:
The flip side of that is that libgnutls-openssl is GPLv3+, which means that anything under GPLv2-only or any other non-GPLv3-compatible license may not be able to use it. I'm not sure, since it implements somebody else's interface; can anything using the OpenSSL library API be considered a derived work of libgnutls-openssl (by virtue of linking)?
My understanding is that public API's are not subject to copyright, however IANAL :-).
David A. Wheeler wrote:
On Mon, 2008-08-25 at 20:04 +0200, Hans de Goede wrote:
Hi All,
The story begins here: https://bugzilla.redhat.com/show_bug.cgi?id=446860
...
I would like to suggest the removal of libgnutls-openssl from Fedora,...
That will probably create many legal problems.
Well only for 2 packages as so far only 2 packages are using ibgnutls-openssl
If there's a way to keep this package, we should.
Agreed another solution would be better one where the gnutls openssl compat headers uses #defines to change the function names to for example gnutls_ prefixed symbols.
Regards,
Hans
On Wed, 2008-08-27 at 09:39 +0200, Hans de Goede wrote:
David A. Wheeler wrote:
On Mon, 2008-08-25 at 20:04 +0200, Hans de Goede wrote:
Hi All,
The story begins here: https://bugzilla.redhat.com/show_bug.cgi?id=446860
...
I would like to suggest the removal of libgnutls-openssl from Fedora,...
That will probably create many legal problems.
Well only for 2 packages as so far only 2 packages are using ibgnutls-openssl
If there's a way to keep this package, we should.
Agreed another solution would be better one where the gnutls openssl compat headers uses #defines to change the function names to for example gnutls_ prefixed symbols.
I have reported the problem to the upstream devel mailing list and they would accept the patch into upstream if someone writes it but they are also considering dropping libgnutls-openssl altogether.
Unfortunately I won't have time to write the patch till middle of September.
So for now I'd suggest to build the affected packages without gnutls-openssl dependency.
On Wed, 27 Aug 2008 19:54:17 +0200 Tomas Mraz tmraz@redhat.com wrote:
On Wed, 2008-08-27 at 09:39 +0200, Hans de Goede wrote:
David A. Wheeler wrote:
On Mon, 2008-08-25 at 20:04 +0200, Hans de Goede wrote:
Hi All,
The story begins here: https://bugzilla.redhat.com/show_bug.cgi?id=446860
...
I would like to suggest the removal of libgnutls-openssl from Fedora,...
That will probably create many legal problems.
Well only for 2 packages as so far only 2 packages are using ibgnutls-openssl
If there's a way to keep this package, we should.
Agreed another solution would be better one where the gnutls openssl compat headers uses #defines to change the function names to for example gnutls_ prefixed symbols.
I have reported the problem to the upstream devel mailing list and they would accept the patch into upstream if someone writes it but they are also considering dropping libgnutls-openssl altogether.
Unfortunately I won't have time to write the patch till middle of September.
So for now I'd suggest to build the affected packages without gnutls-openssl dependency.
I can cheerfully bump and rebuild one of the affected packages (mcabber) against OpenSSL proper if that'll help matters.
(I'd volunteer to help with a patch but I'm not certain my C-fu would be up to the task :-))
Michael. (mcabber package maintainer)
-
Alan Cox -
Bill Crawford -
Chris Adams -
David A. Wheeler -
Hans de Goede -
Matthew Woehlke -
Michael Fleming -
Tom Callaway -
Tomas Mraz