Discussion:
System libraries and the GPLv2 (was: Re: GnuTLS in Debian)
(too old to reply)
Florian Weimer
2017-03-25 17:30:33 UTC
Permalink
---------
GnuTLS 2.12.x is dated. It is upstream's old-old-old stable release
(followed by 3.[012].x). The latest bugfix release happened in
February 2012, later security fixes have not been solved by releases but
by patches in GIT. GnuTLS 2.12.x does not work with the recently released
gcrypt 1.6.0. Therefore we will need keep another old library version
around. (I doubt that GnuTLS upstream will port GnuTLS 2.12.x to newer
gcrypt.)
---------
#1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.
#2 Fork GnuTLS 2 for Debian.
#3 Hope that GMP is relicensed to GPL2+/LGPLv3+
(this is what eventually happened.
#4 Hop nettle switches to a different arbitrary precision arithmetic
library.
#5 Declare GMP to be a system library.
#6 Move to GnuTLS3, drop GnuTLS2. Packages which cannot use GnuTLS3
for license reasons will need to drop TLS support or be relicensed or
be ported to a different TLS library.
(snip)
#5 was how Fedora looked at the OpenSSL library issue. Since Debian
has another viewpoint on OpenSSL I somehow doubt we would use it for
GMP.
I would like to suggest to treat more libraries as eligible for the
system library exception within Debian.

This would apply to OpenSSL (pre- and post-relicensing), and, perhaps
more importantly, to libgcc (a widely used C run-time library which is
mandatory to link against on some architectures).

libgcc been available under the GPLv3 for some time, and yet we still
use it to compile GPLv2-only programs. (My understanding is that the
GCC run-time library exception that applies to libgcc does not make
the library licensing GPLv2-compatible, it only helps licenses without
copyleft-like provisions.)

Would it be possible to get real legal advice on this matter, with the
concrete goal to find a usable process to leverage the system library
exception in the GPLv2?
Walter Landry
2017-03-26 00:01:20 UTC
Permalink
Post by Florian Weimer
#5 Declare GMP to be a system library.
(snip)
#5 was how Fedora looked at the OpenSSL library issue. Since Debian
has another viewpoint on OpenSSL I somehow doubt we would use it for
GMP.
I would like to suggest to treat more libraries as eligible for the
system library exception within Debian.
The traditional interpretation as I understand it is that nothing
Debian ships qualifies for the the system exception. This is because
Debian ships everything together, and the system exception only
applies for components that do not accompany the executable.

Cheers,
Walter Landry
Carlos Alberto Lopez Perez
2017-03-29 12:49:48 UTC
Permalink
Post by Walter Landry
Post by Florian Weimer
#5 Declare GMP to be a system library.
(snip)
#5 was how Fedora looked at the OpenSSL library issue. Since Debian
has another viewpoint on OpenSSL I somehow doubt we would use it for
GMP.
I would like to suggest to treat more libraries as eligible for the
system library exception within Debian.
The traditional interpretation as I understand it is that nothing
Debian ships qualifies for the the system exception. This is because
Debian ships everything together, and the system exception only
applies for components that do not accompany the executable.
Debian ships everything together? Really?
Then why we need repositories and apt-get at all?


I think that any package that is essential for the base OS
(aka Priority: required) should qualify for the system exception.
Dmitry Alexandrov
2017-03-29 13:58:45 UTC
Permalink
Post by Carlos Alberto Lopez Perez
Post by Walter Landry
Post by Florian Weimer
#5 Declare GMP to be a system library.
(snip)
#5 was how Fedora looked at the OpenSSL library issue. Since Debian
has another viewpoint on OpenSSL I somehow doubt we would use it for
GMP.
I would like to suggest to treat more libraries as eligible for the
system library exception within Debian.
The traditional interpretation as I understand it is that nothing
Debian ships qualifies for the the system exception. This is because
Debian ships everything together, and the system exception only
applies for components that do not accompany the executable.
Debian ships everything together? Really?
Yes. http://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/
Carlos Alberto Lopez Perez
2017-03-29 19:58:07 UTC
Permalink
Post by Dmitry Alexandrov
Post by Carlos Alberto Lopez Perez
Post by Walter Landry
Post by Florian Weimer
#5 Declare GMP to be a system library.
(snip)
#5 was how Fedora looked at the OpenSSL library issue. Since Debian
has another viewpoint on OpenSSL I somehow doubt we would use it for
GMP.
I would like to suggest to treat more libraries as eligible for the
system library exception within Debian.
The traditional interpretation as I understand it is that nothing
Debian ships qualifies for the the system exception. This is because
Debian ships everything together, and the system exception only
applies for components that do not accompany the executable.
Debian ships everything together? Really?
Yes. http://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/
I don't see there an image named debian-8.7.1-amd64-DVD-X_free-but-GPL-incompatible.iso

So... does this means that we are actually *now* shipping OpenSSL with
GPL software on the same DVD?

How do you propose we fix this?
Carlos Alberto Lopez Perez
2017-03-29 20:53:50 UTC
Permalink
Post by Carlos Alberto Lopez Perez
So... does this means that we are actually *now* shipping OpenSSL with
GPL software on the same DVD?
This is permitted, or are you joking?
Yes

It was a sarcastic answer to Dmitry claim that Debian ships everything
together because of those DVD images.
Francesco Poli
2017-03-29 17:37:00 UTC
Permalink
On Wed, 29 Mar 2017 14:49:48 +0200 Carlos Alberto Lopez Perez wrote:

[...]
Post by Carlos Alberto Lopez Perez
I think that any package that is essential for the base OS
(aka Priority: required) should qualify for the system exception.
Well, for the record, package libssl1.0.2 is Priority: important,
hence, even with this criterion, it would not qualify...
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Carlos Alberto Lopez Perez
2017-03-29 20:08:41 UTC
Permalink
Post by Francesco Poli
[...]
Post by Carlos Alberto Lopez Perez
I think that any package that is essential for the base OS
(aka Priority: required) should qualify for the system exception.
Well, for the record, package libssl1.0.2 is Priority: important,
hence, even with this criterion, it would not qualify...
Right.

But the policy itself still makes a lot of sense (IMHO), and it can be
useful for more libraries other than OpenSSL.

Hopefully OpenSSL will re-license soon to Apache 2.0.
Then it may [1] be "only" incompatible with GPLv2-only software.
But in the worst case, it will be compatible with GPLv2+ and GPLv3.


Regards
-------

[1]
IANAL
https://mta.openssl.org/pipermail/openssl-dev/2017-March/009178.html
Brian May
2017-03-29 20:25:04 UTC
Permalink
Post by Carlos Alberto Lopez Perez
But in the worst case, it will be compatible with GPLv2+ and GPLv3.
I am not sure I see this as the worst case situation. Or maybe you meant
to write "incompatable"?
--
Brian May <***@debian.org>
Carlos Alberto Lopez Perez
2017-03-29 21:10:01 UTC
Permalink
Post by Brian May
Post by Carlos Alberto Lopez Perez
But in the worst case, it will be compatible with GPLv2+ and GPLv3.
I am not sure I see this as the worst case situation. Or maybe you meant
to write "incompatable"?
No.

Apache 2.0 is compatible with GPLv3 [1] (therefore also with GPLv2+).
That is a fact, and its the worst case situation (assuming that the
re-license to Apache 2.0 actually happens)

I know that the FSF holds the view that Apache 2.0 is not compatible
with GPLv2 [1]. But, at the same time I have read that "many prominent
open source lawyers consider the GPLv2 and Apache 2 licenses to be
compatible already" [2].

So, the best case situation (IMHO) would be that a lawyer tell us that
Apache 2.0 is also compatible with GPLv2-only, and that we stop playing
the game of being amateur lawyers instead of software developers.


Regards.
--------

[1]
https://www.gnu.org/licenses/license-list.en.html#apache2

[2]
http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
Philipp Kern
2017-03-29 22:24:39 UTC
Permalink
Post by Carlos Alberto Lopez Perez
So, the best case situation (IMHO) would be that a lawyer tell us that
Apache 2.0 is also compatible with GPLv2-only, and that we stop playing
the game of being amateur lawyers instead of software developers.
But that's not how the law works in the US. Without actual litigation
and precedent, the most you'll get is a risk assessment of getting sued
and your likelihood of winning if so. :)

Kind regards and IANAL
Philipp Kern
Carlos Alberto Lopez Perez
2017-03-30 00:49:04 UTC
Permalink
Post by Philipp Kern
Post by Carlos Alberto Lopez Perez
So, the best case situation (IMHO) would be that a lawyer tell us that
Apache 2.0 is also compatible with GPLv2-only, and that we stop playing
the game of being amateur lawyers instead of software developers.
But that's not how the law works in the US. Without actual litigation
and precedent, the most you'll get is a risk assessment of getting sued
and your likelihood of winning if so. :)
Kind regards and IANAL
Philipp Kern
Right. That is how it also works in Spain, and I suspect that in many
other countries work the same way.

I understand that Debian wants to take a position of zero (or minimal)
risk, and I also understand the desire to respect the interpretation of
the FSF about the GPL (they don't think this two licenses are compatibles).

So that's fine.


However, I still don't understand why we don't just declare OpenSSL a
system library; or at least define a clear policy for when a package is
considered part of the base system (so the GPL system exception applies
to it).

RedHat did this (see me previous (by date) mail on this thread), and
they didn't had any problem in this regard (AFAIK).
Richard Fontana
2017-03-30 01:16:03 UTC
Permalink
Post by Carlos Alberto Lopez Perez
However, I still don't understand why we don't just declare OpenSSL a
system library; or at least define a clear policy for when a package is
considered part of the base system (so the GPL system exception applies
to it).
RedHat did this (see me previous (by date) mail on this thread), and
they didn't had any problem in this regard (AFAIK).
The "Red Hat did this" part is not accurate.

I addressed this in a talk I gave in 2014 - see

(through about 29:40)

Richard
Carlos Alberto Lopez Perez
2017-03-30 03:08:24 UTC
Permalink
Post by Carlos Alberto Lopez Perez
Post by Philipp Kern
Post by Carlos Alberto Lopez Perez
So, the best case situation (IMHO) would be that a lawyer tell us that
Apache 2.0 is also compatible with GPLv2-only, and that we stop playing
the game of being amateur lawyers instead of software developers.
But that's not how the law works in the US. Without actual litigation
and precedent, the most you'll get is a risk assessment of getting sued
and your likelihood of winning if so. :)
Kind regards and IANAL
Philipp Kern
Right. That is how it also works in Spain, and I suspect that in many
other countries work the same way.
I understand that Debian wants to take a position of zero (or minimal)
risk, and I also understand the desire to respect the interpretation of
the FSF about the GPL (they don't think this two licenses are compatibles).
I believe that this is a fundamental difference between RedHat and Debian.
RedHat is going to do everything within the law and inside their values
for a profit. Their values don't include a strict adherence to the wishes
of copyright holders, but strict adherence to the law.
But our values do include respect for copyright holder rights. So while
we can probably get away with this legally, it's been decided (a few
times?) that without the GPL licensor's consent, we can't in good faith
produce a combination of OpenSSL and a GPL program.
Just a simple question:

Do you (or anyone else) _really_ think the copyright holders of the GPL
program in question had any intention ever of not allowing their program
to be used along with OpenSSL, when they where the ones implementing
support for using it on the first place?
Richard Fontana
2017-03-30 03:28:46 UTC
Permalink
Post by Carlos Alberto Lopez Perez
Do you (or anyone else) _really_ think the copyright holders of the GPL
program in question had any intention ever of not allowing their program
to be used along with OpenSSL, when they where the ones implementing
support for using it on the first place?
This, I would say, encapsulates the real Fedora/Red Hat position on
this issue to the extent there is one. It assumes that the intent of
the copyright holders can be determined from their actions.

Richard
Florian Weimer
2017-03-30 08:00:34 UTC
Permalink
The approach of commercial companies to both code and law is "it compiles?
Ship it!". They have sizeable legal departments, so the question they ask
themselves is not "is this legal?" but "are costs of possible litigation
smaller or greater than the cost of doing it correctly?". On the other
hand, individuals who'd be sued in Debian's case (the SPI has no deep
pockets thus is an unlikely target) have no legal clout so being fully in
the clean is our only defense.
But we make similar risk assessments all the time. Some of us even
strongly defend the right to anonymous contributions, that is, they
argue against keeping exact copyright records, which could otherwise
be used to identify the party who added code for which they did not
have permission (so that Debian or a liable Debian contributor could
recover their costs from them).
Florian Weimer
2017-03-30 08:27:46 UTC
Permalink
Post by Richard Fontana
Post by Carlos Alberto Lopez Perez
Do you (or anyone else) _really_ think the copyright holders of the GPL
program in question had any intention ever of not allowing their program
to be used along with OpenSSL, when they where the ones implementing
support for using it on the first place?
This, I would say, encapsulates the real Fedora/Red Hat position on
this issue to the extent there is one. It assumes that the intent of
the copyright holders can be determined from their actions.
But it's not clear that applies when at the time the software was
released by upstream, the libraries were GPLv2-compatible, and we
started linking against GPLv2-incompatible versions only later. This
has already happened with readline (GPLv3 and later), and libgcc
(GPLv3 and later with GCC exception). It was avoided for GMP, which
used to be LGPLv2+, briefly LGPLv3+, and finally GPLv2 or LGPLv3+.

You could argue that if upstream continues to make compatibility fixes
for later readline versions, or enable compiling with later GCC
versions, they give implied permission to link with those
GPLv2-incompatible library versions. But I think this argument breaks
down, at least formally, when there are many copyright holders, and
not everyone contributes to the changes that enable this kind of
forward compatibility (first technically, and then implicitly
license-wise). On the other hand, when a larger upstream project
granted us a linking exception for OpenSSL, they probably did not
obtain consent from all the copyright holders, either.

What really annoys me about this whole situation is this: I think no
one presently argues that the GPLv2 prevents people from distributing
pre-built binaries for proprietary operating systems. I can take
Hotspot (a component of OpenJDK which is GPLv2-only), compile it with
Microsoft Visual Studio, and distribute the result. But I suddenly
can't ship pre-built binaries, as a free software distribution,
because I happen to have upgraded the system compiler past GCC 4.2,
thus got the new GPLv3+ license for libgcc, and can't link GPLv2-only
Hotspot against that anymore. This can't be right, can it?
Holger Levsen
2017-03-30 13:44:50 UTC
Permalink
Post by Florian Weimer
What really annoys me about this whole situation is this: I think no
one presently argues that the GPLv2 prevents people from distributing
pre-built binaries for proprietary operating systems. I can take
Hotspot (a component of OpenJDK which is GPLv2-only), compile it with
Microsoft Visual Studio, and distribute the result. But I suddenly
can't ship pre-built binaries, as a free software distribution,
because I happen to have upgraded the system compiler past GCC 4.2,
thus got the new GPLv3+ license for libgcc, and can't link GPLv2-only
Hotspot against that anymore. This can't be right, can it?
well, yes and no. By design GPLv3 is incompatible with GPLv2-only,
so this is "right" in the sense that it works as intended. It's also a
major fuckup for some GPLv2-only users (as you just described), which
as a result made *me* like+trust the FSF and the GPL less.

(And which then also resulted in me choosing GPLv2-only over GPLv2 or GPLv3
more often.)

By now I also think these "or any future version" clauses are
 brave.
--
cheers,
Holger
Don Armstrong
2017-03-30 17:56:50 UTC
Permalink
It's also a major fuckup for some GPLv2-only users (as you just
described), which as a result made *me* like+trust the FSF and the GPL
less.
The FSF has always suggested that everyone license their works with the
current revision of the GPL at the time of starting the project, or any
later version, at your option. The only way the FSF could have
accommodated v2 only people was to include an explicit v2 reversion
clause, which makes many of the nice v3 features useless. [Like patents,
warranty disclaimers, non-source conveyance, DMCA bits, etc.]
(And which then also resulted in me choosing GPLv2-only over GPLv2 or
GPLv3 more often.)
Why not just license your work GPLv2+, then? You get compatibility with
v3, you can still work with anything which is v2 only, and you have
compatibility with a newer revision of the GPL if one ever happens. Or
at least appoint a proxy who can decide whether later license revisions
meet your standards.
--
Don Armstrong https://www.donarmstrong.com

Do not handicap your children by making their lives easy.
-- Robert Heinlein _Time Enough For Love_ p251
Richard Fontana
2017-03-31 11:17:27 UTC
Permalink
Post by Florian Weimer
On the other hand, when a larger upstream project
granted us a linking exception for OpenSSL, they probably did not
obtain consent from all the copyright holders, either.
Right. For example, I remember one case where a Debian developer
contacted Red Hat to ask that Red Hat include an explicit OpenSSL
linking exception, for some GPL-licensed project maintained by Red
Hat. They did not inquire into the actual state of copyright ownership
of the GPL code in question or attempt to identify and contact
individual copyright owners AFAIK.

It just shows you that everyone is making simplifying assumptions.
Post by Florian Weimer
What really annoys me about this whole situation is this: I think no
one presently argues that the GPLv2 prevents people from distributing
pre-built binaries for proprietary operating systems. I can take
Hotspot (a component of OpenJDK which is GPLv2-only), compile it with
Microsoft Visual Studio, and distribute the result. But I suddenly
can't ship pre-built binaries, as a free software distribution,
because I happen to have upgraded the system compiler past GCC 4.2,
thus got the new GPLv3+ license for libgcc, and can't link GPLv2-only
Hotspot against that anymore. This can't be right, can it?
One of the general approaches I take to GPL and LGPL interpretation is
that, in cases of textual ambiguity, results that are absurd from a
policy perspective (for example, interpretations that privilege
proprietary software over free software) should normally be treated as
incorrect.

Richard
Francesco Poli
2017-03-30 21:37:32 UTC
Permalink
Post by Richard Fontana
Post by Carlos Alberto Lopez Perez
Do you (or anyone else) _really_ think the copyright holders of the GPL
program in question had any intention ever of not allowing their program
to be used along with OpenSSL, when they where the ones implementing
support for using it on the first place?
This, I would say, encapsulates the real Fedora/Red Hat position on
this issue to the extent there is one. It assumes that the intent of
the copyright holders can be determined from their actions.
What about programs that link both with OpenSSL and with a
third party purely-GPL-licensed library?
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Jonas Smedegaard
2017-03-31 08:35:57 UTC
Permalink
Quoting Francesco Poli (2017-03-30 23:37:32)
Post by Richard Fontana
Post by Carlos Alberto Lopez Perez
Do you (or anyone else) _really_ think the copyright holders of
the GPL program in question had any intention ever of not allowing
their program to be used along with OpenSSL, when they where the
ones implementing support for using it on the first place?
This, I would say, encapsulates the real Fedora/Red Hat position on
this issue to the extent there is one. It assumes that the intent of
the copyright holders can be determined from their actions.
What about programs that link both with OpenSSL and with a third party
purely-GPL-licensed library?
<sarchasm>
Surely we can then asses that the intend of our upstreams in such cases
is schizophrenic: They _both_ want to dillute the copyleft licensing
_and_ uphold it strongly.

Because our job as distributors is not to respect what upstreams
explicitly dictate through licensing, but to second-guess what is
_really_ going on in their minds - and when their mindset and ours do
not align, then surely they cannot be trusted to mean what the say - our
need for simple distribution has higher priority than their right to
grant complex licensing.

Right?
</sarchasm>


- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
Richard Fontana
2017-03-31 11:23:25 UTC
Permalink
Post by Francesco Poli
Post by Richard Fontana
Post by Carlos Alberto Lopez Perez
Do you (or anyone else) _really_ think the copyright holders of the GPL
program in question had any intention ever of not allowing their program
to be used along with OpenSSL, when they where the ones implementing
support for using it on the first place?
This, I would say, encapsulates the real Fedora/Red Hat position on
this issue to the extent there is one. It assumes that the intent of
the copyright holders can be determined from their actions.
What about programs that link both with OpenSSL and with a
third party purely-GPL-licensed library?
I don't think that would change anything, but maybe I'm overlooking
something.

RF
Francesco Poli
2017-03-31 17:28:19 UTC
Permalink
Post by Richard Fontana
Post by Francesco Poli
Post by Richard Fontana
Post by Carlos Alberto Lopez Perez
Do you (or anyone else) _really_ think the copyright holders of the GPL
program in question had any intention ever of not allowing their program
to be used along with OpenSSL, when they where the ones implementing
support for using it on the first place?
This, I would say, encapsulates the real Fedora/Red Hat position on
this issue to the extent there is one. It assumes that the intent of
the copyright holders can be determined from their actions.
What about programs that link both with OpenSSL and with a
third party purely-GPL-licensed library?
I don't think that would change anything, but maybe I'm overlooking
something.
I think the outcome would change significantly.

The copyright holders of the purely-GPL-licensed library (e.g.
readline) have never granted any linking exception, explicitly or
implicitly. They are not the ones who implemented support for OpenSSL
in the program.

Other developers designed and implemented the program, which links with
the purely-GPL-licensed library and with OpenSSL at the same time.

In this scenario, you can determine the intent of the program copyright
holders, but what you need is a linking exception from the
purely-GPL-licensed library copyright holders, not from the program
copyright holders!
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Jonas Smedegaard
2017-03-30 08:44:58 UTC
Permalink
Quoting Carlos Alberto Lopez Perez (2017-03-30 05:08:24)
Post by Carlos Alberto Lopez Perez
Post by Carlos Alberto Lopez Perez
I understand that Debian wants to take a position of zero (or
minimal) risk, and I also understand the desire to respect the
interpretation of the FSF about the GPL (they don't think this two
licenses are compatibles).
I believe that this is a fundamental difference between RedHat and Debian.
RedHat is going to do everything within the law and inside their
values for a profit. Their values don't include a strict adherence
to the wishes of copyright holders, but strict adherence to the law.
But our values do include respect for copyright holder rights. So
while we can probably get away with this legally, it's been decided
(a few times?) that without the GPL licensor's consent, we can't in
good faith produce a combination of OpenSSL and a GPL program.
Do you (or anyone else) _really_ think the copyright holders of the
GPL program in question had any intention ever of not allowing their
program to be used along with OpenSSL, when they where the ones
implementing support for using it on the first place?
Yes, I believe so.

As a concrete example, the Netatalk project has for many years released
code with plugins linking to OpenSSL, but has not added an exception.
Authors of Netatalk try to make a living out of commercial support for
their product, and I genuinely think it is in their interest to make it
possible to use strong crypto - for personal use - but not allow
redistribution of binaries with strong crypto.


- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
Carlos Alberto Lopez Perez
2017-03-30 17:12:53 UTC
Permalink
Post by Jonas Smedegaard
Quoting Carlos Alberto Lopez Perez (2017-03-30 05:08:24)
Post by Carlos Alberto Lopez Perez
Post by Carlos Alberto Lopez Perez
I understand that Debian wants to take a position of zero (or
minimal) risk, and I also understand the desire to respect the
interpretation of the FSF about the GPL (they don't think this two
licenses are compatibles).
I believe that this is a fundamental difference between RedHat and Debian.
RedHat is going to do everything within the law and inside their
values for a profit. Their values don't include a strict adherence
to the wishes of copyright holders, but strict adherence to the law.
But our values do include respect for copyright holder rights. So
while we can probably get away with this legally, it's been decided
(a few times?) that without the GPL licensor's consent, we can't in
good faith produce a combination of OpenSSL and a GPL program.
Do you (or anyone else) _really_ think the copyright holders of the
GPL program in question had any intention ever of not allowing their
program to be used along with OpenSSL, when they where the ones
implementing support for using it on the first place?
Yes, I believe so.
As a concrete example, the Netatalk project has for many years released
code with plugins linking to OpenSSL, but has not added an exception.
Authors of Netatalk try to make a living out of commercial support for
their product, and I genuinely think it is in their interest to make it
possible to use strong crypto - for personal use - but not allow
redistribution of binaries with strong crypto.
- Jonas
Do you have any link or resource that can back what you say here?

I didn't knew about the Netatalk project, but after Googling about this
issue I only see an upstream frustrated because they are unable to
re-license [1], as they are unable to contact all the contributors the
project has.

As you can imagine, any successfully open source project will accumulate
hundreds of contributors along the years (at least 17 years [2] in this
case). Contacting them may be simple just impossible (people change of
email address all the time, people also pass away, and people can just
simply ignore the mail because they are busy with some other stuff).

On top of that, the incentive to take into doing this hard work is not
very big, as either not all downstreams take this issue with the GPL and
OpenSSL as far as Debian, or they include OpenSSL as a system library.

I also see Netatalk was shipped until Fedora 23 with OpenSSL support!
[3], until it was retired because nobody cared to keep maintaining it [4].

IMHO: if your business model is to sell pre-built binaries with some
feature, its better that you keep this feature with the right license
that prohibits distributing it and forces everyone to build from
sources, rather than relying on some incompatibility between the GPL and
OpenSSL that is not going to stop anyone but Debian and its derivatives
from shipping it.


Regards
-------

[1]
https://lists.debian.org/debian-legal/2004/08/msg00184.html
https://sourceforge.net/p/netatalk/feature-requests/33/
[2]
https://github.com/Netatalk/Netatalk/commit/31843674b7bd32eabcce3a1ad6159b4f94921f79#diff-cf45edbe4d45d61b0f0ce5e9eaeb38bcR82
[3]
http://pkgs.fedoraproject.org/cgit/rpms/netatalk.git/tree/netatalk.spec?h=f23#n84
[4]
http://pkgs.fedoraproject.org/cgit/rpms/netatalk.git/commit/?id=81611ededd7b668145715779723c60d84ef74003
Jonas Smedegaard
2017-03-30 17:25:38 UTC
Permalink
Quoting Carlos Alberto Lopez Perez (2017-03-30 19:12:53)
Post by Carlos Alberto Lopez Perez
Post by Jonas Smedegaard
Quoting Carlos Alberto Lopez Perez (2017-03-30 05:08:24)
Post by Carlos Alberto Lopez Perez
Post by Carlos Alberto Lopez Perez
I understand that Debian wants to take a position of zero (or
minimal) risk, and I also understand the desire to respect the
interpretation of the FSF about the GPL (they don't think this two
licenses are compatibles).
I believe that this is a fundamental difference between RedHat and Debian.
RedHat is going to do everything within the law and inside their
values for a profit. Their values don't include a strict adherence
to the wishes of copyright holders, but strict adherence to the law.
But our values do include respect for copyright holder rights. So
while we can probably get away with this legally, it's been decided
(a few times?) that without the GPL licensor's consent, we can't in
good faith produce a combination of OpenSSL and a GPL program.
Do you (or anyone else) _really_ think the copyright holders of the
GPL program in question had any intention ever of not allowing their
program to be used along with OpenSSL, when they where the ones
implementing support for using it on the first place?
Yes, I believe so.
As a concrete example, the Netatalk project has for many years released
code with plugins linking to OpenSSL, but has not added an exception.
Authors of Netatalk try to make a living out of commercial support for
their product, and I genuinely think it is in their interest to make it
possible to use strong crypto - for personal use - but not allow
redistribution of binaries with strong crypto.
Do you have any link or resource that can back what you say here?
You asked what I _think_ and I shared that with you.

I do not speak on behalf of Netatalk, just brought it up as an example
of what inspires my thinking. More specifically what makes me think
they care about differentiated use cases is their blogging at some point
about a NAS company using their code unfairly. but again, I mention
this not as a piece of fact but as inspiration on how more generally
some may deal differently with licensing.

You may judge my input unreliable due to not being proven by fact, or
you may judge my thinking "far out".


- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
Carlos Alberto Lopez Perez
2017-03-30 19:37:26 UTC
Permalink
Instead, I'll repeat that licenses shouldn't be violated. One way of
achieving that is to ask copyright holders for additional permissions
that are needed to avoid a violation.
The problem with this approach, though, is that many of us have tried this
with GPL software that links against OpenSSL and have been told that we're
being pedantic, wasting the maintainer's time, and they aren't going to
include any such specific license grant because they're not lawyers,
aren't going to mess with licenses, no one else has this problem, and
Debian needs to pull the stick out of its ass.
Now one can just say "well, we don't want to package software from
maintainers like that anyway," but often those people are perfectly
reasonable on many other topics and quite good upstreams. We are widely
viewed as out of step with the community on this specific point, whether
reasonably or unreasonably.
I'm not saying we're wrong, necessarily, but the way that Debian interacts
with software licenses is truly not the way that nearly everyone else
interacts with software licenses. We have non-lawyers with no legal
training read them carefully and attempt to apply their rules as if they
were written in normal English, very precisely. (In other words, we treat
them like they're computer programs.) Very, very few people outside of
Debian do this. Elsewhere, people largely divide into two camps: a quick
skim looking for obvious issues followed by "meh, good enough," or review
by an actual lawyer who is making a legal decision based on legal
interpretation, case law, and a risk analysis.
I think we normally arrive at reasonable conclusions, but sometimes we do
arrive at conclusions that neither of those other two camps reach, and
then we can look oddly out of touch.
Couldn't agree more with you.

Programmers shouldn't try to interpret corner cases on licenses,
or judge about license compatibility.

What the text of a license says is never interpreted word by word by a
lawyer or a tribunal. The intention is also very important.

And when you release a software that uses OpenSSL, there is a clear
intention in that fact that you allow to use OpenSSL. After all, you
have implemented support for it.

I think we should try to consult more with lawyers when we have doubts,
or when there is a disagreement about licenses in general.

It worked for the ZFSOnLinux case.
I think it can work also for this system library exception issue.

My 2 cents.
Ian Jackson
2017-03-30 12:31:33 UTC
Permalink
Post by Carlos Alberto Lopez Perez
However, I still don't understand why we don't just declare OpenSSL a
system library; or at least define a clear policy for when a package is
considered part of the base system (so the GPL system exception applies
to it).
I think the GPL system library exception does not apply for the
benefit of anything on a DVD image. Since we want downstreams to be
able to make arbitrary DVD( image)s containing whatever bits (of main)
that they like, and distribute them, we cannot rely on the system
library exception for anything in Debian.

Ian.
Carlos Alberto Lopez Perez
2017-03-30 19:17:36 UTC
Permalink
Post by Ian Jackson
Post by Carlos Alberto Lopez Perez
However, I still don't understand why we don't just declare OpenSSL a
system library; or at least define a clear policy for when a package is
considered part of the base system (so the GPL system exception applies
to it).
I think the GPL system library exception does not apply for the
benefit of anything on a DVD image. Since we want downstreams to be
able to make arbitrary DVD( image)s containing whatever bits (of main)
that they like, and distribute them, we cannot rely on the system
library exception for anything in Debian.
Ian.
Let me you remember DFSG number 9 [1]:

* License Must Not Contaminate _Other_ Software

The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the
license must not insist that all other programs distributed on the
same medium must be free software.

And also point you to my previous answer to Dmitry:

https://lists.debian.org/debian-legal/2017/03/msg00042.html


Shipping a collection of software on a DVD doesn't make any of this
pieces of software a derivative works one of the other.


[1] https://www.debian.org/social_contract
Don Armstrong
2017-03-30 19:29:55 UTC
Permalink
Post by Carlos Alberto Lopez Perez
* License Must Not Contaminate _Other_ Software
A work which is a derivative work of another piece of software isn't
merely distributed alongside.
Post by Carlos Alberto Lopez Perez
Shipping a collection of software on a DVD doesn't make any of this
pieces of software a derivative works one of the other.
Precisely. It only has bearing on whether the system library exception
to derivative works applies.
--
Don Armstrong https://www.donarmstrong.com

The computer allows you to make mistakes faster than any other
invention, with the possible exception of handguns and tequila
-- Mitch Ratcliffe
Carlos Alberto Lopez Perez
2017-03-30 19:54:08 UTC
Permalink
Post by Don Armstrong
Post by Carlos Alberto Lopez Perez
* License Must Not Contaminate _Other_ Software
A work which is a derivative work of another piece of software isn't
merely distributed alongside.
Post by Carlos Alberto Lopez Perez
Shipping a collection of software on a DVD doesn't make any of this
pieces of software a derivative works one of the other.
Precisely. It only has bearing on whether the system library exception
to derivative works applies.
It should apply.

Fedora and RHEL ship also DVD images, and they do use this system
exception clause of the GPL for linking with OpenSSL.

If you are still not sure, lets consult this with a lawyer instead of
trying to argue about the wording of a license.
Don Armstrong
2017-03-30 20:05:24 UTC
Permalink
Post by Carlos Alberto Lopez Perez
Post by Don Armstrong
Precisely. It only has bearing on whether the system library
exception to derivative works applies.
It should apply.
Why should it apply? GPLv2 is written to make the system library
exception not apply to distributors of the system library.
Post by Carlos Alberto Lopez Perez
Fedora and RHEL ship also DVD images, and they do use this system
exception clause of the GPL for linking with OpenSSL.
How do you know this? They could have made a judgement that copyright
holders who have written code which links against OpenSSL have given an
implicit license grant, or that the likelihood of litigation is
outweighed by the issue with distributing such software.

Or they may have just not bothered doing either, and hoped for the best.
Post by Carlos Alberto Lopez Perez
If you are still not sure, lets consult this with a lawyer instead of
trying to argue about the wording of a license.
I don't think that's necessary, but by all means, write up a specific
set of questions that you propose to have the project ask its legal
representation. Note as well, that the legal advice will necessarily be
jurisdiction and project specific.
--
Don Armstrong https://www.donarmstrong.com

This can't be happening to me. I've got tenure.
-- James Hynes _Publish and Perish_
Philip Hands
2017-03-31 06:55:18 UTC
Permalink
Post by Carlos Alberto Lopez Perez
Post by Don Armstrong
Post by Carlos Alberto Lopez Perez
* License Must Not Contaminate _Other_ Software
A work which is a derivative work of another piece of software isn't
merely distributed alongside.
Post by Carlos Alberto Lopez Perez
Shipping a collection of software on a DVD doesn't make any of this
pieces of software a derivative works one of the other.
Precisely. It only has bearing on whether the system library exception
to derivative works applies.
It should apply.
Fedora and RHEL ship also DVD images, and they do use this system
exception clause of the GPL for linking with OpenSSL.
Perhaps they have decided to ignore the bit of the license that says:

"unless that component itself accompanies the executable."

but I think it is more likely that they've had their lawyers look at
each particular case that they wanted to include in their distro, in
order to assess how realistic it is for there to be a problem with the
result, and how painful it will be to fix if there is a problem.

If we were to do a similar assessment, then we'd be asking the lawyers
different questions, because we also care about how likely it to cause a
problem for any of our downstreams (and their downstreams, etc.) or any
of the users.

RedHat are also in a position to offer indemnity against legal problems
caused by using their distribution, if they want to, whereas we can only
try to avoid the problem.

So, pointing at the fact that RedHat has on occasion decided to violate
the license in this way does nothing to prove that the violation does
not exist.

Nor does it make the exception to the exception go away, and we clearly
are causing the "component" and the "executable" to "accompany" one
another if installing a binary by whatever means causes OpenSSL to
automatically be installed because of the dependency.

I really doubt that any court of law will be particularly interested in
the mechanisms that achieve that effect, so it's not just a case of
making sure that the two things are not on the same DVD.

Cheers, Phil.

P.S. I am not a lawyer

P.P.S. Does anyone really expect a consensus to emerge where we decide
to ignore the exception to the exception across the board without
consulting lawyers? I think there are several people in this thread
(myself included) that have demonstrated that they're going to argue
against such a consensus. That being the case, it's not going to
happen, so repeating the same justifications for why there is no problem
does not seem even slightly productive to me.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Florian Weimer
2017-03-31 08:36:32 UTC
Permalink
Post by Philip Hands
P.P.S. Does anyone really expect a consensus to emerge where we decide
to ignore the exception to the exception across the board without
consulting lawyers? I think there are several people in this thread
(myself included) that have demonstrated that they're going to argue
against such a consensus. That being the case, it's not going to
happen, so repeating the same justifications for why there is no problem
does not seem even slightly productive to me.
I think we can use the discussion in the thread to determine what we
want from the lawyers, should we eventually decide to consult them.

I think it is far more likely to have a constructive discussion with
counsel if we tell them from the start that we want to ship GPL
software as part of Debian which links against libraries such as
current libgcc (for GPLv2 software) and OpenSSL, asking for advice
what is needed to make this happen while minimizing risk for Debian
and downstreams.

I hope we can at least get consensus that this is still the goal we
are after.
Carlos Alberto Lopez Perez
2017-03-30 20:03:09 UTC
Permalink
Post by Carlos Alberto Lopez Perez
Apache 2.0 is compatible with GPLv3 [1] (therefore also with GPLv2+).
It's more complicated than "therefore also".
Imagine a GPL2+ program library linked with a GPL2 library. Now also link
this program with an Apache 2.0 library. What happens?
I agree its more complicated. But usually what happens is this:

For several Linux distributions: nothing happens because they have
already declared OpenSSL a system library.

For Debian: the maintainer reports a bug to the author of the GPLv2
library so they add an exception to link with the OpenSSL. The upstream
maintainer either can't do that because its unable to contact every
author of the software or doesn't care and thinks this is a Debian
specific issue. The Debian maintainer either abandons here or takes into
the task of implementing a patch that uses libgcrypt or similar instead
of OpenSSL. It can happen that the Debian maintainer simply disables the
feature that uses OpenSSL (if that is an option)
Carlos Alberto Lopez Perez
2017-03-30 00:29:14 UTC
Permalink
Post by Carlos Alberto Lopez Perez
Post by Walter Landry
Post by Florian Weimer
#5 Declare GMP to be a system library.
(snip)
#5 was how Fedora looked at the OpenSSL library issue. Since Debian
has another viewpoint on OpenSSL I somehow doubt we would use it for
GMP.
I would like to suggest to treat more libraries as eligible for the
system library exception within Debian.
The traditional interpretation as I understand it is that nothing
Debian ships qualifies for the the system exception. This is because
Debian ships everything together, and the system exception only
applies for components that do not accompany the executable.
Debian ships everything together? Really?
Then why we need repositories and apt-get at all?
I think that any package that is essential for the base OS
(aka Priority: required) should qualify for the system exception.
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.
Emphasis on "unless that component itself accompanies the executable".
The intention of the system library exception is to allow third
parties to ship Free Software on proprietary platforms, while pointedly
*disallowing* the vendor of the proprietary platform from doing so. As
historical precedent, note that some vendors explicitly provided
entirely separate media containing GNU applications, in order to satisfy
that requirement.
Are you a lawyer?

In that case maybe you can explain me how is that RedHat (a company that
makes billions of dollars worth of revenue and that is clearly much more
interesting to sue than Debian if your intention when suing is seeking
some economic compensation), is shipping GPL software (pure GPL --
without any OpenSSL linking exception on the license) and linked with
OpenSSL, by simply declaring OpenSSL a system library, and nobody has
still sued (or complained to) them for doing that? [1]

And if you are not a lawyer (I am not), then I suggest we (the Debian
project) seek for legal advice regarding whether is ok to do this or not.

We did this after the ZFSonLinux package was blocked for years on the
NEW queue because there was a disagreement whether shipping it was ok or
not. And the lawyers from SFLC told us that shipping it t was ok [2].


[1]
The FAQ is from Fedora, but the same applies to RHEL
https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F
https://www.openssl.org/docs/faq.html#LEGAL2
[2]
https://lists.debian.org/debian-devel-announce/2015/04/msg00006.html
Continue reading on narkive:
Loading...