GnuTLS in Debian

[Andreas Metzler]

Hello,

Debian ist still relying heavily on GnuTLS 2.12.x, and I do not think
this is sustainable for much longer.

State of Play:
---------
In July 2011 with version 3.0 [1] GnuTLS switched to Nettle as only
supported crypto backend. Nettle requires GMP.

GnuTLS and Nettle are available under LGPLv2.1+. GMP used to be
licensed LGPLv2.1+ ages ago but upgraded to LGPLv3+ in version 4.2.2
(released September 2007).

Therefore GnuTLS 3.x cannot be used by GPLv2 (without "or later"
clause) software which is the main reason most of Debian is still
using GnuTLS 2.x.

Problems:
---------
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.)

How to continue from here/solve this:
---------
#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+

#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.


Personal comments:
---------
I do not think #1 and #2 are realistic given Debian's manpower issues. Also
#1 would stop working at all if nettle required newer GMP features. (I
have not checked whether this is already the case.)

I have given up on #3 and do not think it will happen. GMP upstream has
been made aware of the issue in 2011 [2] and has not shown any intention of
a license change.

#4 is just here for completeness sake.

#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.

Fedora is discussing the issue in
<https://bugzilla.redhat.com/show_bug.cgi?id=986347>. There is
automatically generated depency tree with the problematic packages
highlighted crosslinked in the bugreport[3]. Debian does not have the
infrastructure to do something similar, but I guess gnutls usage is
more widespread.

Summary:
---------
Afaict it boils down to #6. But perhaps I have missed something
obvious. Comments welcome.

cu Andreas


[1] Version 2.11.1 (released 2010-09-14) used nettle as
/prefered/ crypto backend, however gcrypt was still supported as
alternative.

[2] http://gmplib.org/list-archives/gmp-bugs/2011-February/002178.html
http://gmplib.org/list-archives/gmp-devel/2011-May/001952.html

[3] http://people.redhat.com/nmavrogi/fedora/out.fedora.txt

[brian m. carlson]

Post by Andreas Metzler
---------
#1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.

This seems like the best idea, as it lets us use newer versions of
GnuTLS that support elliptic curves with the minimum amount of pain.

Post by Andreas Metzler
#2 Fork GnuTLS 2 for Debian.
#3 Hope that GMP is relicensed to GPL2+/LGPLv3+
#4 Hop nettle switches to a different arbitrary precision arithmetic
library.
#5 Declare GMP to be a system library.

I don't think this is actually feasible, due to the way the GPLv2 is
actually written. Otherwise, we wouldn't be using GnuTLS at all, since
OpenSSL would be satisfactory for everything.

Post by Andreas Metzler
#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.

I don't think this option is a good idea. It will leave git without
HTTPS support, since libcurl3-nss doesn't actually work for HTTPS.
libcurl3-nss requires an additional library not in Debian for the crypto
support to work at all, and despite me filing bugs, neither the NSS nor
the curl maintainers have stepped up to fix this.

This also doesn't consider the fact that NSS provides poorer crypto
support than either OpenSSL or GnuTLS, although it's getting better.

[Ben Hutchings]

Post by brian m. carlson

Post by Andreas Metzler
---------
#1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.

This seems like the best idea, as it lets us use newer versions of
GnuTLS that support elliptic curves with the minimum amount of pain.

I think this would be a good idea if GnuTLS doesn't depend on too many
features of newer GMP.

[...]

Post by brian m. carlson

Post by Andreas Metzler
#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.

I don't think this option is a good idea. It will leave git without
HTTPS support, since libcurl3-nss doesn't actually work for HTTPS.
libcurl3-nss requires an additional library not in Debian for the crypto
support to work at all, and despite me filing bugs, neither the NSS nor
the curl maintainers have stepped up to fix this.
This also doesn't consider the fact that NSS provides poorer crypto
support than either OpenSSL or GnuTLS, although it's getting better.

The free software world desparately needs a permissively licenced TLS
library with sane default behaviour. OpenSSL or GnuTLS seem to have
failed us on both grounds, and I hope interested developers will
cooperate with the Fedora developers in making NSS usable by more
applications.

Ben.

[Bastien ROUCARIES]

Post by Ben Hutchings

Post by brian m. carlson

Post by Andreas Metzler
---------
#1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.

This seems like the best idea, as it lets us use newer versions of
GnuTLS that support elliptic curves with the minimum amount of pain.

I think this would be a good idea if GnuTLS doesn't depend on too many
features of newer GMP.
[...]

Post by brian m. carlson

Post by Andreas Metzler
#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.

I don't think this option is a good idea. It will leave git without
HTTPS support, since libcurl3-nss doesn't actually work for HTTPS.
libcurl3-nss requires an additional library not in Debian for the crypto
support to work at all, and despite me filing bugs, neither the NSS nor
the curl maintainers have stepped up to fix this.
This also doesn't consider the fact that NSS provides poorer crypto
support than either OpenSSL or GnuTLS, although it's getting better.

The free software world desparately needs a permissively licenced TLS
library with sane default behaviour. OpenSSL or GnuTLS seem to have
failed us on both grounds, and I hope interested developers will
cooperate with the Fedora developers in making NSS usable by more
applications.

Fedora created a open SSL compat library based on libnss. I can package it
if i get a sponsor

Post by Ben Hutchings
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.

[Bastien ROUCARIES]

Post by Ben Hutchings

Post by brian m. carlson

Post by Andreas Metzler
---------
#1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.

This seems like the best idea, as it lets us use newer versions of
GnuTLS that support elliptic curves with the minimum amount of pain.

I think this would be a good idea if GnuTLS doesn't depend on too many
features of newer GMP.
[...]

Post by brian m. carlson

Post by Andreas Metzler
#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.

I don't think this option is a good idea. It will leave git without
HTTPS support, since libcurl3-nss doesn't actually work for HTTPS.
libcurl3-nss requires an additional library not in Debian for the crypto
support to work at all, and despite me filing bugs, neither the NSS nor
the curl maintainers have stepped up to fix this.
This also doesn't consider the fact that NSS provides poorer crypto
support than either OpenSSL or GnuTLS, although it's getting better.

The free software world desparately needs a permissively licenced TLS
library with sane default behaviour. OpenSSL or GnuTLS seem to have
failed us on both grounds, and I hope interested developers will
cooperate with the Fedora developers in making NSS usable by more
applications.

I plan to package http://rcritten.fedorapeople.org/nss_compat_ossl.html
Note that the certificate problem have been solved by recent p11-kit package

And if we solve https://bugzilla.mozilla.org/show_bug.cgi?id=402712 we
have something sane I think

Bastien

Post by Ben Hutchings
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.

[Carlos Alberto Lopez Perez]

Post by Ben Hutchings

Post by Andreas Metzler
#1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.
This seems like the best idea, as it lets us use newer versions of
GnuTLS that support elliptic curves with the minimum amount of pain.

I think this would be a good idea if GnuTLS doesn't depend on too many
features of newer GMP.

On the GnuTLS webpage there is the following statement:

"""
1. Gmplib is under LGPLv3. Older versions of gmplib under LGPLv2 are also supported.
""" http://gnutls.org/download.html#fn1

[Moritz Mühlenhoff]

Post by Andreas Metzler
#5 Declare GMP to be a system library.

(..)

Post by Andreas Metzler
#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.

We should do that (and also reevaluate the position wrt OpenSSL) by
running it by the Software Freedom Law Center.

Red Hat has real lawyers who looked into the issue, we should do the
same.

Cheers,
Moritz

[Russ Allbery]

Post by Moritz Mühlenhoff

Post by Andreas Metzler
#5 Declare GMP to be a system library.

(..)

Post by Andreas Metzler
#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.

We should do that (and also reevaluate the position wrt OpenSSL) by
running it by the Software Freedom Law Center.
Red Hat has real lawyers who looked into the issue, we should do the
same.

I'm inclined to agree, since the relief and advantages of not having to
worry about OpenSSL linked with GPL code are extremely substantial. That
would be a nice wall to stop beating our heads against.

[Marco d'Itri]

Post by Moritz Mühlenhoff
We should do that (and also reevaluate the position wrt OpenSSL) by
running it by the Software Freedom Law Center.
Red Hat has real lawyers who looked into the issue, we should do the
same.

Agreed, Debian has been promoting bad decisions due to developers
playing armchair lawyers for way too long.

[Steve Langasek]

Post by Marco d'Itri

Post by Moritz Mühlenhoff
We should do that (and also reevaluate the position wrt OpenSSL) by
running it by the Software Freedom Law Center.
Red Hat has real lawyers who looked into the issue, we should do the
same.

Agreed, Debian has been promoting bad decisions due to developers
playing armchair lawyers for way too long.

Red Hat only needs to meet the standard that they don't think there's risk
to the company of being sued for a license violation. Debian holds itself
to a higher, ethical standard of complying with the license even when the
risks are small.

Your insulting reference to laymen who are capable of reading and reasoning
about license terms as "armchair lawyers" doesn't magically make the text of
the license ignorable.

[Russ Allbery]

Post by Steve Langasek

Post by Marco d'Itri

Post by Moritz Mühlenhoff
We should do that (and also reevaluate the position wrt OpenSSL) by
running it by the Software Freedom Law Center.
Red Hat has real lawyers who looked into the issue, we should do the
same.

Agreed, Debian has been promoting bad decisions due to developers
playing armchair lawyers for way too long.

Red Hat only needs to meet the standard that they don't think there's
risk to the company of being sued for a license violation. Debian holds
itself to a higher, ethical standard of complying with the license even
when the risks are small.

For the specific case of OpenSSL incompatibility with the GPL, I doubt
that's the position that would prevail in a GR. I think it's rather hard
to see any real harm to either license that comes from combining that
code, or any upstream who actually cares about the apparent
incompatibility for any reason other than because distributions worry
about it. It's therefore very hard to see how this is somehow a higher
ethical stance.

I'm similarly dubious that the GMP maintainers really don't want it to be
usable with Git through the indirection of GnuTLS, as opposed to not
wanting to (or not being allowed by the FSF to) back down from the policy
of GPLv3 for everything for its other benefits.

[Faidon Liambotis]

Post by Steve Langasek

Post by Marco d'Itri

Post by Moritz Mühlenhoff
We should do that (and also reevaluate the position wrt OpenSSL) by
running it by the Software Freedom Law Center.
Red Hat has real lawyers who looked into the issue, we should do the
same.

Agreed, Debian has been promoting bad decisions due to developers
playing armchair lawyers for way too long.

Red Hat only needs to meet the standard that they don't think there's risk
to the company of being sued for a license violation. Debian holds itself
to a higher, ethical standard of complying with the license even when the
risks are small.
Your insulting reference to laymen who are capable of reading and reasoning
about license terms as "armchair lawyers" doesn't magically make the text of
the license ignorable.

I think a better way to put Marco's argument would be: "[h]acker legal
education, with its roots in programming, is strong on formal precision
and textual exegesis. But it is notably light on legal realism: coping
with the open texture of the law and sorting persuasive from ineffective
arguments".

That's from a commentary[1] by James Grimmelmann[2], that started from a
review of Biella's book and discusses the legal education of hackers and
members of the Debian community in particular. It's worth a read.

I, too, believe that we could use the reality check. We already did so
with our patent policy and solved long-standing problems for our users.

Regards,
Faidon

1:
http://www.concurringopinions.com/archives/2013/09/hacker-legal-education.html
2: http://james.grimmelmann.net/ -- a professor of law specializing on
copyright, IP & Internet Law, for what it's worth.

[Steve Langasek]

Post by Faidon Liambotis
I think a better way to put Marco's argument would be: "[h]acker
legal education, with its roots in programming, is strong on formal
precision and textual exegesis. But it is notably light on legal
realism: coping with the open texture of the law and sorting
persuasive from ineffective arguments".
That's from a commentary[1] by James Grimmelmann[2], that started
from a review of Biella's book and discusses the legal education of
hackers and members of the Debian community in particular. It's
worth a read.

Well, I find that your quote is taken quite out of context. James seems in
fact quite positive about hacker's becoming well-versed in the law, while at
the same time taking a balanced view by pointing out the limits of our
amateur education (the part you quote). Being a Debian developer does *not*
prepare one to practice law in a courtroom. But it *does* prepare one to
understand the terms of a license, which is not something that requires a
professional.

Determining whether a particular course of action is in keeping with the
wishes of the copyright holder is not something that requires consulting a
lawyer, any more than determining whether a license meets our own DFSG
guidelines. These are not questions that need to be *adjudicated*, they are
matters for us to decide by a careful reading of the licenses and the
application of our shared principles.

Post by Faidon Liambotis
I, too, believe that we could use the reality check. We already did
so with our patent policy and solved long-standing problems for our
users.

Well, I'm not sure what problems that patent policy actually solved for our
users. As far as I can see, our current patent policy was simply a
codification of existing practice.

But as for a reality check, remember that lawyers by and large only give you
the answers to the questions you ask. It's very easy to ask the wrong
question where the GPL's system library exception is concerned. I have seen
many people ask the wrong question before, precisely because they believed
they already knew the answer.

[Felipe Sateler]

Post by Steve Langasek

Post by Faidon Liambotis
I, too, believe that we could use the reality check. We already did so
with our patent policy and solved long-standing problems for our users.

Well, I'm not sure what problems that patent policy actually solved for
our users. As far as I can see, our current patent policy was simply a
codification of existing practice.

The users of faac, lame and the non-crippled ffmpeg/libav would beg to
disagree.

[Marco d'Itri]

Post by Steve Langasek
Red Hat only needs to meet the standard that they don't think there's risk
to the company of being sued for a license violation. Debian holds itself
to a higher, ethical standard of complying with the license even when the
risks are small.

I am clearly missing the ethical standard we should comply with, since
the upstream developers obviously do not care about the issue in the
first place.
As usual, Russ explained this better than I could do.

This is self-inflicted damage, and I think it's slightly arrogant to
pretend that Debian is the only organization which cares about ethics.

[Clint Byrum]

Post by Marco d'Itri

Post by Steve Langasek
Red Hat only needs to meet the standard that they don't think there's risk
to the company of being sued for a license violation. Debian holds itself
to a higher, ethical standard of complying with the license even when the
risks are small.

I am clearly missing the ethical standard we should comply with, since
the upstream developers obviously do not care about the issue in the
first place.

An author is not the only party to text. There are also those who have
received this license, and adhered to it for the sake of the author and
the copyright holders who have also adhered to it.

So, it is rather disrespectful and could cause harm to those who have
worked within the confines of the text to at some point ignore the text.
I'm not suggesting it _will_ cause harm, but it may. In fact, RedHat
has harmed Debian and enriched themselves by ignoring it.

So Debian is now in an odd position. If it were to reverse position,
those users who have been diligently adhering to the license and expending
resources would be at a disadvantage to new users who won't have to deal
with that. That may be a position a business can take, but as volunteer
organization with no profit motive, I think Debian has to take more care
to stay as close to the ethical center as possible.

If the original authors would like to clarify their position (oh god
please OpenSSL change your license!), then this conflict of interest
would go away. But I suspect this has been argued to them before.

Post by Marco d'Itri
As usual, Russ explained this better than I could do.
This is self-inflicted damage, and I think it's slightly arrogant to
pretend that Debian is the only organization which cares about ethics.

Only is not a word that Steve used. He was differentiating Debian from
RedHat specifically in fact. There are quite a few more organizations
in the world than "Debian" and "RedHat'. Also this isn't so much an
external issue as "caring about ethics". I think this is internal,
and it is part of what defines Debian.

Is it inconvenient? Absolutely. Should we change it? Well, last I checked
we do take votes on major issues.

[Russ Allbery]

Post by Clint Byrum
An author is not the only party to text. There are also those who have
received this license, and adhered to it for the sake of the author and
the copyright holders who have also adhered to it.
So, it is rather disrespectful and could cause harm to those who have
worked within the confines of the text to at some point ignore the text.
I'm not suggesting it _will_ cause harm, but it may. In fact, RedHat has
harmed Debian and enriched themselves by ignoring it.

This strikes me as equivalent to a long-distance runner who insists on
running barefoot due to an idiosyncratic understanding of the rules of the
race that isn't shared by anyone else, including the judges, and then gets
upset at the other runners for winning while wearing shoes. (Analogy
intentionally chosen because it is possible to compete and win in
long-distance races barefoot, but most runners don't.)

Red Hat is not responsible for our license interpretations. If the rest
of the world doesn't care, standing by our interpretation looks less like
ethics and more like masochism.

Post by Clint Byrum
So Debian is now in an odd position. If it were to reverse position,
those users who have been diligently adhering to the license and
expending resources would be at a disadvantage to new users who won't
have to deal with that.

Those users who have been diligently adhering to the license may well be
doing things they don't have to do, and discovering that they don't have
to do a bunch of work that they've been doing should be a cause for
*relief*, not anger.

Please, let's not get so invested in what we've done previously that we
distort our thinking so far as to think that good news is actually bad
news.

Post by Clint Byrum
If the original authors would like to clarify their position (oh god
please OpenSSL change your license!), then this conflict of interest
would go away. But I suspect this has been argued to them before.

There is no way to change the OpenSSL license. The project doesn't use
copyright assignment and the number of contributors is far too large to be
able to track them all down and get their permission.

Post by Clint Byrum
Is it inconvenient? Absolutely. Should we change it? Well, last I
checked we do take votes on major issues.

There are two angles to this question. One is whether we really do run a
legal risk, which is something that should be answered by lawyers, and is
not something on which we should vote. If it's not legally advisable to
combine the code, that's the end of the matter as far as I'm concerned,
but I think we should ask a real lawyer and not rely on careful parsing of
the licenses in question. As Faidon pointed out, doing that often
produces incorrect results in real-world legal systems.

If a lawyer tells us we're being overly cautious, then the other angle is
whether we want to continue to be unnecessarily cautious out of a sense of
ethics, or just because we want to keep doing what we've always done and
don't like change for some reason. If we get to that point, by all means,
let's have a GR. I will be stunned if the project decides to insist on
not using OpenSSL given legal advice that it's not a legal concern.

[Stephan Seitz]

Post by Russ Allbery
but I think we should ask a real lawyer and not rely on careful parsing

Yes, this is true, but I’m wondering how many lawyer you mean to ask? Is
one enough? After all this is a difficult question, and you will only get
the final answer from a judge in the end.
Or do we need to ask different lawyers in different countries? Is the
answer in one country enough? This may affect mirror operators.

Merry christmas!

Stephan

[Russ Allbery]

Yes, this is true, but I’m wondering how many lawyer you mean to ask? Is
one enough? After all this is a difficult question, and you will only
get the final answer from a judge in the end.

The realistic probability of a lawsuit here is small (has anyone *ever*
been sued over combining OpenSSL code with GPL code?), so I think our
normal legal counsel would be sufficient. They're aware of issues with
different jurisdictions.

[Clint Adams]

Post by Russ Allbery
There is no way to change the OpenSSL license. The project doesn't use
copyright assignment and the number of contributors is far too large to be
able to track them all down and get their permission.

I do not believe that either of these statements is categorically true.

If I recall correctly, similar things were said about freeing Moria and
Angband, then it turned out that it would have been trivial to contact
Robert Koeneke if anyone had actually bothered to try.

The OpenSSL license terms are terrible. That, the awful build system,
the awful API, and some of the crypto are reasons that we should not use
OpenSSL at all for anything. But instead we run around harming free
software by making GPL exceptions and pretending that OpenSSL is good
and tolerable.

As an intellectual property abolitionist, I'll refrain from weighing in
on the ethical issues of adhering to stupid license terms.

[Steve Langasek]

Post by Clint Adams

Post by Russ Allbery
There is no way to change the OpenSSL license. The project doesn't use
copyright assignment and the number of contributors is far too large to be
able to track them all down and get their permission.

I do not believe that either of these statements is categorically true.
If I recall correctly, similar things were said about freeing Moria and
Angband, then it turned out that it would have been trivial to contact
Robert Koeneke if anyone had actually bothered to try.
The OpenSSL license terms are terrible. That, the awful build system,
the awful API, and some of the crypto are reasons that we should not use
OpenSSL at all for anything. But instead we run around harming free
software by making GPL exceptions and pretending that OpenSSL is good
and tolerable.

Which crypto library has a non-awful API?

Post by Clint Adams
As an intellectual property abolitionist, I'll refrain from weighing in
on the ethical issues of adhering to stupid license terms.

I think you've managed to invert my point here, actually, which was that
when someone licenses their work under *the GPL*, we should respect their
wishes - even though it would make our lives a lot easier to be able to ship
binaries linked against OpenSSL.

[Russ Allbery]

Post by Steve Langasek
I think you've managed to invert my point here, actually, which was that
when someone licenses their work under *the GPL*, we should respect
their wishes - even though it would make our lives a lot easier to be
able to ship binaries linked against OpenSSL.

Which means that we should go ahead and link with OpenSSL code from
upstreams whose software is released under the GPL and who have declined
to add an exception clause because they think our request for an exception
clause is idiotic and they refuse to play along with what they consider to
be ridiculous legal interpretations?

I know at least one such upstream and I suspect there are lots more.
There's a lot of software written under the GPL that explicitly and
intentionally supports being linked with OpenSSL, and I have a hard time
believing we're doing something somehow more ethical by declining to do
so.

Incidentally, one of the problem packages, Git, also has the same problem
with relicensing: there are lots of copyright holders, and therefore no
easy mechanism to add a license exception.

[Steve Langasek]

Post by Russ Allbery

Post by Steve Langasek
I think you've managed to invert my point here, actually, which was that
when someone licenses their work under *the GPL*, we should respect
their wishes - even though it would make our lives a lot easier to be
able to ship binaries linked against OpenSSL.

Which means that we should go ahead and link with OpenSSL code from
upstreams whose software is released under the GPL and who have declined
to add an exception clause because they think our request for an exception
clause is idiotic and they refuse to play along with what they consider to
be ridiculous legal interpretations?

Sure, as far as I'm concerned that's a license clarification in itself. If
the upstream actually has the legal authority to make such a determination
for all the copyright holders, then by all means, let's take that license
exception, whether or not they think it's ridiculous for us to call it a
license exception. ;-)

But in the case where there are multiple copyright holders, I don't think
it's reasonable to do this just on the basis that the current upstream
maintainer thinks it's an issue beneath their notice - there *are* people
who consider this a real issue, and don't want their GPL works bundled with
OpenSSL in a manner contrary to the license.

Post by Russ Allbery
I know at least one such upstream and I suspect there are lots more.
There's a lot of software written under the GPL that explicitly and
intentionally supports being linked with OpenSSL, and I have a hard time
believing we're doing something somehow more ethical by declining to do
so.

The letter of the license says that such works can be distributed in source
form and linked locally against whatever the user wants to link against; and
they can be distributed as stand-alone binaries that (in the GPLv2 case)
link against arbitrary system libraries. But the license also says that an
OS vendor can NOT link against system libraries with incompatible licenses
if the binary is bundled with the OS.

The wording in GPLv2 is /confusing/ because of the nested exceptions
involved, but it's not ambiguous. While there are many upstreams of GPL
software written to link with OpenSSL who would be happy for us to bundle
binary builds of their software in Debian, it is not possible to infer this
for *all* such upstream works.

The FSF is one such copyright holder for which we should not infer this to
be true; they had the opportunity to relax this requirement in the drafting
of GPLv3, and explicitly did not. In fact, the system library exception is
now defined even more narrowly than for GPLv2, so that it now covers only
language runtime libraries. I think this was a poor choice on the FSF's
part, but it's the choice they made, and we should honor it.

Post by Russ Allbery
Incidentally, one of the problem packages, Git, also has the same problem
with relicensing: there are lots of copyright holders, and therefore no
easy mechanism to add a license exception.

I think if we make a good-faith effort to contact all the copyright holders,
have gotten the assent of all the major copyright holders, and have not
gotten any NACKs, then we're meeting our ethical obligation and can in good
conscience regard it as ok to build it into binaries linked against OpenSSL.
I think this is ok because as you rightly point out, there are a lot of
people who think this is a silly thing for us to worry about. But I think
it's also not ok to distribute such binaries *without* asking, because there
is a non-negligible group who doesn't consider it silly.

[Thorsten Glaser]

of GPLv3, and explicitly did not. In fact, the system library exception i=

s

now defined even more narrowly than for GPLv2, so that it now covers only
language runtime libraries. I think this was a poor choice on the FSF's

Is it really?

| A "Standard Interface" means an interface that either is an official
|standard defined by a recognized standards body, or, in the case of
|interfaces specified for a particular programming language, one that
|is widely used among developers working in that language.

OpenSSL is an interface specified for C and widely used among
developers working in C. And OpenSSL is the =E2=80=9Cde facto=E2=80=9D stan=
dard
for crypto, hashes and SSL (and one of the major contenders for
bignum) in C, on Unix.

|Component, and (b) serves only to enable use of the work with that
|Major Component, or to implement a Standard Interface for which an
|implementation is available to the public in source code form. A

And libssl.so.* and libcrypto.so.* DLLs implement this Standard
Interface called OpenSSL, which is available to the public in source
code form.

So, I disagree with that reading.

bye,
//mirabilos
--=20
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
=09-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

[Kurt Roeckx]

Post by Thorsten Glaser

Post by Steve Langasek
of GPLv3, and explicitly did not. In fact, the system library exception is
now defined even more narrowly than for GPLv2, so that it now covers only
language runtime libraries. I think this was a poor choice on the FSF's

Is it really?
| A "Standard Interface" means an interface that either is an official
|standard defined by a recognized standards body, or, in the case of
|interfaces specified for a particular programming language, one that
|is widely used among developers working in that language.
OpenSSL is an interface specified for C and widely used among
developers working in C. And OpenSSL is the "de facto" standard
for crypto, hashes and SSL (and one of the major contenders for
bignum) in C, on Unix.

I understand the intention of that differently than you do and
find the word "widely" in it ambigious. I think the "specified
for a particular programming language" is important and is
different than "implemented in a particular programming language".
OpenSSL is a de facto crypto standard, not a de facto C standard.

I want to compare it with priority=standard, so that everyone
expect that to be available when writing in that language.
OpenSSL might be widely used, but not that widely that you think
it's part of the language.

Comparing this with some other languages, of what I think would
be part of the standard interface:
- perl: The packages perl + perl-modules, no extra modules
- php: What you can run with php5-cli / php5 without modules
- java: What's in the jre
- C++: libc and libstdc++ functions, STL. You can argue over
boost as some compilers actually ship with that and their
intention is to be a standard library/interface.


Kurt

[Dimitri John Ledkov]

Post by Clint Adams

Post by Russ Allbery
There is no way to change the OpenSSL license. The project doesn't use
copyright assignment and the number of contributors is far too large to be
able to track them all down and get their permission.

I do not believe that either of these statements is categorically true.
If I recall correctly, similar things were said about freeing Moria and
Angband, then it turned out that it would have been trivial to contact
Robert Koeneke if anyone had actually bothered to try.
The OpenSSL license terms are terrible. That, the awful build system,
the awful API, and some of the crypto are reasons that we should not use
OpenSSL at all for anything. But instead we run around harming free
software by making GPL exceptions and pretending that OpenSSL is good
and tolerable.
As an intellectual property abolitionist, I'll refrain from weighing in
on the ethical issues of adhering to stupid license terms.

While I'd want to agree, on the other side we have FSF with the GNU
Project that purposely restrict license terms, resulting in in
GPLv2-only software not able to use any recent crypto library.

To me it looks like FSF/GNU project are acting against the spirit of
the free software here. Explicitly what they promise not to do with
their copyright assignment. This is not the first time this happened
as well. With the move to GPLv3, Apple has seized upstream gcc
development and instead works on llvm/clang. Which imho is a technical
loss for the project. And I can't recall the tls/CUPS issue at the
moment.

On these grounds I have not signed FSF copyright assignment. What's
the point, if further down the line, my software will not be available
to be used by a wide opensource community as possible, or be limited
in some way.

I hope that everyone agrees that OpenSSL advertisement clause has very
little publicity, monetary, or otherwise benefit these days. And I
presume FSF/GNU would also see it as such. When GPLv3/AGPLv3 were in
the process of being drafted, the drafter were well aware that linking
with OpenSSL has not been resolved, on blanket or on opt-out basis.
E.g. I pretty sure the world would not collapse if a new revision of
GPLv3.x license terms have "This product includes software developed
by the OpenSSL Project for use in the OpenSSL Toolkit.
(http://www.openssl.org/)" unless otherwise stated and have the
appropriate OpenSSL licensing exception. And it would truly become a
relief.

At this point I'd like to champion the recent big company / project to
grant OpenSSL linking exception, for an otherwise AGPLv3 software.
10gen granted a blanket OpenSSL linking exception for MongoDB. I
cannot thank enough all the people who were involved in making this
happen: from Mark Shuttleworth, James Page and many others from Ubuntu
side and Laura Czajkowski (Community Manager at MongoDB) and the rest
of legal / technical / management teams on the 10gen.... and I guess
many other people who got involved.

In the spirit, of open source, and specifically in support of
(AL)GPLv2 software, FSF/GNU are positioned to make (AL)GPLv3 software
backwards compatible, enough to link against. Such that, e.g.
(LA)GPLv2 code can link against (AL)GPLv3 code as long as (AL)GPLv3
code is not modified. If it is modified, those modification should be
re-distributed under the corresponding (AL)GPLv3 license. This would
open up the route for projects to move forward to v3 license terms if
they can and want, for the benefits/terms that those offer, without
hammering everyone "left behind", and without using dual-license terms
which pretty-much all/any benefits of the v3 clauses. This would also
be a great relief to everybody.

Designing v3 license terms, to be incompatible with v2, looks to me as
an "embrace, extend and extinguish" tactic, except it seems to
targeted at the open source software movement itself, that the FSF
helped to establish.

"License Must Not Be Specific to Debian" or, imho, any specific
projects, because well it's in-feasible and is causing real problems
for distributions. Maybe it is finally time to fix GPL?!

[Russ Allbery]

Post by Clint Adams
If I recall correctly, similar things were said about freeing Moria and
Angband, then it turned out that it would have been trivial to contact
Robert Koeneke if anyone had actually bothered to try.

That doesn't quite match my memory. People did try when the idea first
came up, and were not successful. I'm glad that people were later able to
do so.

This is an interesting example in the context of the OpenSSL and GPL
incompatibility. The relicensing of Angband definitely followed the "good
enough and no one is objecting" principle once the major contributors were
contacted, and I'm fairly sure that not everyone who had touched the
source base formally signed off on the relicensing. For example, I did a
significant update of the in-game command help back in the mid 1990s, and
I suspect the current help continues to be a (now uncredited) derivative
of my work. I don't remember being contacted about this (although to be
fair it's possible it happened and I've forgotten, since I would have said
yes without thinking about it much).

It also helped that Ben had rewritten a large chunk of the source, so in
many cases no one traced history back before him. It's questionable
whether that would hold up to a formal legal challenge, since he didn't do
a clean-room reimplementation.

I fully support the Angband relicensing for the same reason that I would
support linking with OpenSSL if a lawyer says it's okay: I think we worry
too much about this stuff and stand too heavily on technicalities that no
one really cares about.

[Clint Adams]

Post by Steve Langasek
Which crypto library has a non-awful API?

Many of the native Haskell crypto libraries do. I am aware
that that is a somewhat unhelpful answer.

Post by Steve Langasek
I think you've managed to invert my point here, actually, which was that
when someone licenses their work under *the GPL*, we should respect their
wishes - even though it would make our lives a lot easier to be able to ship
binaries linked against OpenSSL.

There are two roles a free software license plays. One is the actual
copyright license under a legal regime that legitimizes extortion and
coercion based on artificial scarcity, occasionally used as a weapon
in disputes inside and outside of courtrooms. The other is that of
a social contract between the developers and the amorphous and nebulous
free software community.

One of these is important, and one we violate all the time. Debian is
violating the letter of the GPL constantly, and the GPL is something
that people sue over. I would bet that nobody would sue over BSD
violations, but I would also have bet that nobody would sue over
the Artistic License, and that's happened. I'm sure we're violating
permissive licenses too, regardless of legal risk.

When I release something under the GPL I'm not promising to sue you
if you don't distribute your modifications clearly marked and dated.
I'm indicating my intention that all derivative works must be GPL'd.

Post by Steve Langasek
Incidentally, one of the problem packages, Git, also has the same problem
with relicensing: there are lots of copyright holders, and therefore no
easy mechanism to add a license exception.

I believe Git has at least one copyright holder who is a pigheaded
contrarian or the license could be fixed to have an "or later".

Post by Steve Langasek
While I'd want to agree, on the other side we have FSF with the GNU
Project that purposely restrict license terms, resulting in in
GPLv2-only software not able to use any recent crypto library.

GPLv2-only folks should be made to see how their antisocial
behavior is harming everyone. I think this is a delightful
situation for them to be in.

Plenty of other licenses have an "or later" baked in and nobody
whines about this at all. I've heard plenty of people fear that
horrible things will happen with Creative Commons leadership,
yet no one is trying to redline "later" from CC-BY-SA.

But since the GPL allows it, people think it's somehow reasonable
to be v2-only. It is not. It has led to all manner of problems,
and for what? People enjoying Tivoization? Those people should
be punched in the face. Fear of the FSF making a GPLv4 that's
the text of Apache 2.0? Oh no, the sky is falling.

Post by Steve Langasek
To me it looks like FSF/GNU project are acting against the spirit of
the free software here. Explicitly what they promise not to do with
their copyright assignment. This is not the first time this happened
as well. With the move to GPLv3, Apple has seized upstream gcc
development and instead works on llvm/clang. Which imho is a technical
loss for the project. And I can't recall the tls/CUPS issue at the
moment.

I would say that the effort evil scumbags like Apple are putting in
to undermine GPLv3 is a pretty strong sign that everyone should be
switching to "v3 or later".

Post by Steve Langasek
On these grounds I have not signed FSF copyright assignment. What's
the point, if further down the line, my software will not be available
to be used by a wide opensource community as possible, or be limited
in some way.

If you don't believe in the ideals of the free software movement,
then why aren't you licensing what you write under Expat or ISC?
There's a reason copyleft has restrictions. As for copyright agreements,
I am hardly going to say that anyone should ever sign one, but
the FSF has the only good ones.

Post by Steve Langasek
I hope that everyone agrees that OpenSSL advertisement clause has very
little publicity, monetary, or otherwise benefit these days. And I
presume FSF/GNU would also see it as such. When GPLv3/AGPLv3 were in
the process of being drafted, the drafter were well aware that linking
with OpenSSL has not been resolved, on blanket or on opt-out basis.
E.g. I pretty sure the world would not collapse if a new revision of
GPLv3.x license terms have "This product includes software developed
by the OpenSSL Project for use in the OpenSSL Toolkit.
(http://www.openssl.org/)" unless otherwise stated and have the
appropriate OpenSSL licensing exception. And it would truly become a
relief.

All advertisement and attribution clauses should be banned from
this planet. They're conceptually awful and we rarely comply
with them anyway. OpenSSL is awful. We should not cater to it.
OpenSSL should change its license to something friendlier.
I don't know what would motivate them sufficiently to do so.

Post by Steve Langasek
In the spirit, of open source, and specifically in support of
(AL)GPLv2 software, FSF/GNU are positioned to make (AL)GPLv3 software
backwards compatible, enough to link against. Such that, e.g.

That completely nullifies the improvements in v3. If you make
v3 downgradeable to v2 then you could legally tivoize my GPLv3+
library. I don't want you to tivoize my GPLv3+ library. If you
tivoize my GPLv3+ library, you are ignoble.

Post by Steve Langasek
Designing v3 license terms, to be incompatible with v2, looks to me as
an "embrace, extend and extinguish" tactic, except it seems to
targeted at the open source software movement itself, that the FSF
helped to establish.

No, the FSF helped to establish the Free Software movement. The
Open Source movement is a bunch of people who don't understand
why Free Software is important. Open Source folks want to
"embrace, extend and extinguish" the Free Software movement
whether they know it or not, hence your implication that they
are the same thing.

Post by Steve Langasek
"License Must Not Be Specific to Debian" or, imho, any specific
projects, because well it's in-feasible and is causing real problems
for distributions. Maybe it is finally time to fix GPL?!

Well, there's always https://gitorious.org/copyleft-next I guess.

[David Weinehall]

On Mon, Dec 23, 2013 at 10:43:54PM +0000, Clint Adams wrote:
[snip]

Post by Clint Adams
GPLv2-only folks should be made to see how their antisocial
behavior is harming everyone. I think this is a delightful
situation for them to be in.
Plenty of other licenses have an "or later" baked in and nobody
whines about this at all. I've heard plenty of people fear that
horrible things will happen with Creative Commons leadership,
yet no one is trying to redline "later" from CC-BY-SA.
But since the GPL allows it, people think it's somehow reasonable
to be v2-only. It is not. It has led to all manner of problems,
and for what? People enjoying Tivoization? Those people should
be punched in the face. Fear of the FSF making a GPLv4 that's
the text of Apache 2.0? Oh no, the sky is falling.

As one of the "GPL v2 only" proponents, I take affront. I choose to
license what little software I release as GPL v2 only because I do not
consider the GPL v3 to have what attracted me to use the GPL v2 in the
first place.

Relicensing libraries that have long been GPL v2 (or later) or LGPL v2.1
(or later) to (L)GPL v3 (or later) is, if anything, very antisocial,
since it locks out users of GPL v2 (only) software and forces the GPL v3
interpretation onto GPL v2 (or later) software.

But by all means, go on and punch me in the face...


Regards: David Weinehall

[Vincent Lefevre]

Post by David Weinehall
Relicensing libraries that have long been GPL v2 (or later) or LGPL v2.1
(or later) to (L)GPL v3 (or later) is, if anything, very antisocial,
since it locks out users of GPL v2 (only) software and forces the GPL v3
interpretation onto GPL v2 (or later) software.

You can still old versions of the libraries and port bug fixes.
New features provided by later versions are regarded as new work,
just like if you had to use entirely new libraries.
--
Vincent Lefèvre <***@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Clint Adams]

Post by David Weinehall
As one of the "GPL v2 only" proponents, I take affront. I choose to
license what little software I release as GPL v2 only because I do not
consider the GPL v3 to have what attracted me to use the GPL v2 in the
first place.

The only theoretical advantage I see to GPLv2 is in the termination
clause, and in practice that seems to be really more trouble than
it's worth.

Beyond that you have substandard and unclear wording, tivoization,
lesser patent protection, and incompatibility with Apache 2.0.

So what about that is attractive, and what about v3 is so intolerable
that you cannot abide your software being distributed under it or
combined with v3+ works?

[Stephen M. Webb]

Post by Clint Adams

Post by David Weinehall
As one of the "GPL v2 only" proponents, I take affront. I choose to
license what little software I release as GPL v2 only because I do not
consider the GPL v3 to have what attracted me to use the GPL v2 in the
first place.

The only theoretical advantage I see to GPLv2 is in the termination
clause, and in practice that seems to be really more trouble than
it's worth.
Beyond that you have substandard and unclear wording, tivoization,
lesser patent protection, and incompatibility with Apache 2.0.
So what about that is attractive, and what about v3 is so intolerable
that you cannot abide your software being distributed under it or
combined with v3+ works?

There are organization who will allow v2 but not v3 because of the tivoizaton and patent clauses. A developer may want
his work to be used by such organizations as well as by Debian.

[Kurt Roeckx]

Post by Stephen M. Webb

Post by Clint Adams

Post by David Weinehall
As one of the "GPL v2 only" proponents, I take affront. I choose to
license what little software I release as GPL v2 only because I do not
consider the GPL v3 to have what attracted me to use the GPL v2 in the
first place.

The only theoretical advantage I see to GPLv2 is in the termination
clause, and in practice that seems to be really more trouble than
it's worth.
Beyond that you have substandard and unclear wording, tivoization,
lesser patent protection, and incompatibility with Apache 2.0.
So what about that is attractive, and what about v3 is so intolerable
that you cannot abide your software being distributed under it or
combined with v3+ works?

There are organization who will allow v2 but not v3 because of the tivoizaton and patent clauses. A developer may want
his work to be used by such organizations as well as by Debian.

That would be an argument for v2+, not v2 only.


Kurt

[Stephen M. Webb]

Post by Kurt Roeckx

Post by Stephen M. Webb

Post by Clint Adams

Post by David Weinehall
As one of the "GPL v2 only" proponents, I take affront. I choose to
license what little software I release as GPL v2 only because I do not
consider the GPL v3 to have what attracted me to use the GPL v2 in the
first place.

The only theoretical advantage I see to GPLv2 is in the termination
clause, and in practice that seems to be really more trouble than
it's worth.
Beyond that you have substandard and unclear wording, tivoization,
lesser patent protection, and incompatibility with Apache 2.0.
So what about that is attractive, and what about v3 is so intolerable
that you cannot abide your software being distributed under it or
combined with v3+ works?

There are organization who will allow v2 but not v3 because of the tivoizaton and patent clauses. A developer may want
his work to be used by such organizations as well as by Debian.

That would be an argument for v2+, not v2 only.

Nope. An organization that will not accept the GPLv3 because of the tivoization and patent clauses will not accept
GPLv2 or later. The "or later" clause means a downstream can invoke their rights under the GPLv3 to demand secret
encryption keys or upstream can revoke the license for patent action. These organizations do not accept GPLv2+ because
it's effectively GPLv3.

[Виталий Филиппов]

On Sun, 29 Dec 2013 02:59:35 +0400, Stephen M. Webb

Post by Stephen M. Webb

Post by Kurt Roeckx

Post by Stephen M. Webb

Post by Clint Adams

Post by David Weinehall
As one of the "GPL v2 only" proponents, I take affront. I choose to
license what little software I release as GPL v2 only because I do not
consider the GPL v3 to have what attracted me to use the GPL v2 in the
first place.

The only theoretical advantage I see to GPLv2 is in the termination
clause, and in practice that seems to be really more trouble than
it's worth.
Beyond that you have substandard and unclear wording, tivoization,
lesser patent protection, and incompatibility with Apache 2.0.
So what about that is attractive, and what about v3 is so intolerable
that you cannot abide your software being distributed under it or
combined with v3+ works?

There are organization who will allow v2 but not v3 because of the
tivoizaton and patent clauses. A developer may want
his work to be used by such organizations as well as by Debian.

That would be an argument for v2+, not v2 only.

Nope. An organization that will not accept the GPLv3 because of the
tivoization and patent clauses will not accept
GPLv2 or later. The "or later" clause means a downstream can invoke
their rights under the GPLv3 to demand secret
encryption keys or upstream can revoke the license for patent action.
These organizations do not accept GPLv2+ because
it's effectively GPLv3.

IMHO this point of view should be incorrect... The "or later" clause
should mean that everyone is free to choose the license they want for
REdistribution - GPL2, GPL3 or maybe GPL4 in the future :) and they don't
need to fulfill the GPL3 requirements in that case. But anyone can take
their code, modify and REdistribute it under GPL3.

[Simon McVittie]

Post by Kurt Roeckx

Post by Stephen M. Webb
There are organization who will allow v2 but not v3 because of the
tivoizaton and patent clauses. A developer may want
his work to be used by such organizations as well as by Debian.

That would be an argument for v2+, not v2 only.

Nope. An organization that will not accept the GPLv3 because of the
tivoization and patent clauses will not accept
GPLv2 or later. The "or later" clause means a downstream can invoke
their rights under the GPLv3 to demand secret
encryption keys or upstream can revoke the license for patent
action.
These organizations do not accept GPLv2+ because
it's effectively GPLv3.

I think this is a misinterpretation of the "or later" wording. To have a
slightly more concrete discussion, let's say you're relying on being
able to "tivoize" software that is a derivative work of libfoo version
5, licensed under GPL-2+ by copyright holder FooCorp. (I am not a
lawyer, this is not legal advice, and this is a hypothetical situation.)

When you consider the terms of libfoo's license, the licensing
boilerplate says you may choose "at your option, either version 2 of the
License, or any later version" (with version 3 currently the only
possible later version). If FooCorp try to compel you to provide the
encryption keys that implement tivoization, you can tell them "I chose
to distribute/derive from libfoo under GPL-2, which does not require
that" - AIUI this gives them no basis to insist that you comply with
GPL-3 terms.

What FooCorp *can* do to *encourage* you to accept the GPL-3 is to
release a new version, say libfoo version 6, under either GPL-3 or
GPL-3+. If they are no longer maintaining libfoo v5, or v6 has
compelling new features, you have an uncomfortable choice: either you
can upgrade to libfoo v6 (which in practice compels you to comply with
GPL-3 terms, since there is no later version yet), or you can continue
to use libfoo v5, forking and/or maintaining it if necessary, with or
without assistance from FooCorp or other libfoo users, and being careful
to avoid copying anything not available under GPL-2 into it.

This is not unique to the GPL: FooCorp could equally well release libfoo
v5 under a permissive BSD-style license, and libfoo v6 under something
more restrictive, such as the GPL or a proprietary license (although in
this case, you'd probably be more likely to find disgruntled libfoo v5
users who were willing to help you to fork v5 under its original license).

S

[Kurt Roeckx]

Post by Stephen M. Webb

Post by Kurt Roeckx

Post by Stephen M. Webb

Post by Clint Adams

Post by David Weinehall
As one of the "GPL v2 only" proponents, I take affront. I choose to
license what little software I release as GPL v2 only because I do not
consider the GPL v3 to have what attracted me to use the GPL v2 in the
first place.

The only theoretical advantage I see to GPLv2 is in the termination
clause, and in practice that seems to be really more trouble than
it's worth.
Beyond that you have substandard and unclear wording, tivoization,
lesser patent protection, and incompatibility with Apache 2.0.
So what about that is attractive, and what about v3 is so intolerable
that you cannot abide your software being distributed under it or
combined with v3+ works?

There are organization who will allow v2 but not v3 because of the tivoizaton and patent clauses. A developer may want
his work to be used by such organizations as well as by Debian.

That would be an argument for v2+, not v2 only.

Nope. An organization that will not accept the GPLv3 because of the tivoization and patent clauses will not accept
GPLv2 or later. The "or later" clause means a downstream can invoke their rights under the GPLv3 to demand secret
encryption keys or upstream can revoke the license for patent action. These organizations do not accept GPLv2+ because
it's effectively GPLv3.

The "or later" means "or later" and just that. It doesn't mean
a downstream can say they received it under the later version.
And the upstream can't claim that either.

But a downstream can change it to v3+ if they wish, but that
doesn't change anything for the people they got it from for
whom it will still be v2+ (until they change that).


Kurt

[Stephen M. Webb]

Post by Kurt Roeckx
The "or later" means "or later" and just that. It doesn't mean
a downstream can say they received it under the later version.
And the upstream can't claim that either.

The "or later" means my clients' lawyers state unequivocally that they will not accept GPLv2+ software, but GPLv2-only
is completely acceptable. This is not an isolated incident.

As a corollary, that may also be why the company that employs me insists on GPLv3-only licensing by default.

[Steve Langasek]

Post by Stephen M. Webb

Post by Kurt Roeckx
The "or later" means "or later" and just that. It doesn't mean
a downstream can say they received it under the later version.
And the upstream can't claim that either.

The "or later" means my clients' lawyers state unequivocally that they
will not accept GPLv2+ software, but GPLv2-only is completely acceptable.
This is not an isolated incident.

Perhaps it's not an isolated incident, but if that's really what those
lawyers claim, then they are mistaken. If someone receives a work under the
terms "GPLv2 or later", then they are free to comply with the license by
fulfilling the terms of GPLv2 *or* GPLv3, *whichever they choose*. That
includes when they redistribute it, include it in products, etc.; and no one
downstream of them (or upstream of them) has any right to demand that the
distributor comply with the terms of GPLv3 instead of GPLv2.

Now, the companies in question may legitimately regard a GPLv2+ upstream as
a source business risk, because they have no guarantee that future versions
of the software won't be made available under GPLv3+ instead of GPLv2+, and
if they're relying on being able to continue tracking upstream, they may
well choose to avoid this issue entirely by adhering to a strict "GPLv2
only" policy. But that doesn't mean that GPLv2+ imposes any requirements on
them *per se* that GPLv2 does not.

Post by Stephen M. Webb
As a corollary, that may also be why the company that employs me insists
on GPLv3-only licensing by default.

To make those clients unhappy? ;)

[Vincent Lefevre]

Post by Steve Langasek
Now, the companies in question may legitimately regard a GPLv2+
upstream as a source business risk, because they have no guarantee
that future versions of the software won't be made available under
GPLv3+ instead of GPLv2+, and if they're relying on being able to
continue tracking upstream, they may well choose to avoid this issue
entirely by adhering to a strict "GPLv2 only" policy. But that
doesn't mean that GPLv2+ imposes any requirements on them *per se*
that GPLv2 does not.

Upstream (more precisely, the copyright holder) may decide to switch
directly from "GPLv2 only" to GPLv3 for some future version. So,
companies don't necessarily avoid the issue, though there may be
less risk. The best way to avoid the issue is to actively contribute
to the software and refuse any license change, as long as there is
no copyright assignment required by upstream.
--
Vincent Lefèvre <***@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Vincent Lefevre]

Post by Kurt Roeckx

Post by Stephen M. Webb
There are organization who will allow v2 but not v3 because of
the tivoizaton and patent clauses. A developer may want his work
to be used by such organizations as well as by Debian.

That would be an argument for v2+, not v2 only.

Nope. An organization that will not accept the GPLv3 because of the
tivoization and patent clauses will not accept GPLv2 or later.

Then such an organization should not accept any 3rd-party software,
because the copyright holder is free to add a license at any time,
such as changing "GPLv2 only" to "GPLv2 or later", including versions
that have already been released. This is just silly.
--
Vincent Lefèvre <***@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[David Weinehall]

Post by Clint Adams

Post by David Weinehall
As one of the "GPL v2 only" proponents, I take affront. I choose to
license what little software I release as GPL v2 only because I do not
consider the GPL v3 to have what attracted me to use the GPL v2 in the
first place.

The only theoretical advantage I see to GPLv2 is in the termination
clause, and in practice that seems to be really more trouble than
it's worth.
Beyond that you have substandard and unclear wording, tivoization,
lesser patent protection, and incompatibility with Apache 2.0.

Apart from the termination clause, the GPLv2 is far more concise,
I don't see tivoization as a problem (it's the software I want to
protect, not anyone's combination of it with hardware), nor do I care
about compatibility with Apache 2.0 -- I do, however, care about
compatibility with GPL v2, which GPL v3 isn't.


Regards: David

[Clint Byrum]

Post by Russ Allbery

Post by Clint Byrum
An author is not the only party to text. There are also those who have
received this license, and adhered to it for the sake of the author and
the copyright holders who have also adhered to it.
So, it is rather disrespectful and could cause harm to those who have
worked within the confines of the text to at some point ignore the text.
I'm not suggesting it _will_ cause harm, but it may. In fact, RedHat has
harmed Debian and enriched themselves by ignoring it.

This strikes me as equivalent to a long-distance runner who insists on
running barefoot due to an idiosyncratic understanding of the rules of the
race that isn't shared by anyone else, including the judges, and then gets
upset at the other runners for winning while wearing shoes. (Analogy
intentionally chosen because it is possible to compete and win in
long-distance races barefoot, but most runners don't.)

This is a really confusing analogy. The runners are the end users of the
free software in question, and the GPL is the rules of the race? What is
the OpenSSL license then? How are these runners forced to resolve
ambiguous licenses exactly?

I'm not sure that analogy made things more clear for me anyway.

Post by Russ Allbery
Red Hat is not responsible for our license interpretations. If the rest
of the world doesn't care, standing by our interpretation looks less like
ethics and more like masochism.

Adhering to a strict code of ethics is often fairly painful. If the GPL
licensors do not care, then they should be happy to grant an OpenSSL
exception. If the OpenSSL licensors do not care, then they should be
happy to strike the incompatible requirement from the license. And if we
do not care, then we should amend the social contract.

Post by Russ Allbery

Post by Clint Byrum
So Debian is now in an odd position. If it were to reverse position,
those users who have been diligently adhering to the license and
expending resources would be at a disadvantage to new users who won't
have to deal with that.

Those users who have been diligently adhering to the license may well be
doing things they don't have to do, and discovering that they don't have
to do a bunch of work that they've been doing should be a cause for
*relief*, not anger.

It would be a relief, definitely. If it were actually clearly
discovered. Thus far, it has not been "discovered", it is only expressed
as opinions.

Post by Russ Allbery
Please, let's not get so invested in what we've done previously that we
distort our thinking so far as to think that good news is actually bad
news.

If there's good news, praise the flying spaghetti monster! But I'm not
sure "the opinions of the Debian developers overrode the wishes of the
GPL authors" is "good news". More like "interesting news".

Post by Russ Allbery

Post by Clint Byrum
If the original authors would like to clarify their position (oh god
please OpenSSL change your license!), then this conflict of interest
would go away. But I suspect this has been argued to them before.

There is no way to change the OpenSSL license. The project doesn't use
copyright assignment and the number of contributors is far too large to be
able to track them all down and get their permission.

I have heard that before, and it is unfortunate, as it would certainly
be a nice simple solution if OpenSSL just switched to a known license
such as BSD/MIT/Apache2/LGPL.

Post by Russ Allbery

Post by Clint Byrum
Is it inconvenient? Absolutely. Should we change it? Well, last I
checked we do take votes on major issues.

There are two angles to this question. One is whether we really do run a
legal risk, which is something that should be answered by lawyers, and is
not something on which we should vote. If it's not legally advisable to
combine the code, that's the end of the matter as far as I'm concerned,
but I think we should ask a real lawyer and not rely on careful parsing of
the licenses in question. As Faidon pointed out, doing that often
produces incorrect results in real-world legal systems.

I agree with your opinions in the paragraph above entirely.

Post by Russ Allbery
If a lawyer tells us we're being overly cautious, then the other angle is
whether we want to continue to be unnecessarily cautious out of a sense of
ethics, or just because we want to keep doing what we've always done and
don't like change for some reason. If we get to that point, by all means,
let's have a GR. I will be stunned if the project decides to insist on
not using OpenSSL given legal advice that it's not a legal concern.

I think you've missed that we're not trying to cover our butts. We're
trying to uphold the licenses in the spirit of the licenses. Thus far,
we've interpreted "system library" not to apply to OpenSSL. That is the
section that, if a lawyer said "probability of problems is near to 0",
we could consider revisiting.

[Russ Allbery]

Post by Clint Byrum

Post by Russ Allbery

Post by Clint Byrum
An author is not the only party to text. There are also those who have
received this license, and adhered to it for the sake of the author
and the copyright holders who have also adhered to it.
So, it is rather disrespectful and could cause harm to those who have
worked within the confines of the text to at some point ignore the
text. I'm not suggesting it _will_ cause harm, but it may. In fact,
RedHat has harmed Debian and enriched themselves by ignoring it.

This strikes me as equivalent to a long-distance runner who insists on
running barefoot due to an idiosyncratic understanding of the rules of
the race that isn't shared by anyone else, including the judges, and
then gets upset at the other runners for winning while wearing shoes.
(Analogy intentionally chosen because it is possible to compete and win
in long-distance races barefoot, but most runners don't.)

This is a really confusing analogy. The runners are the end users of the
free software in question, and the GPL is the rules of the race? What is
the OpenSSL license then? How are these runners forced to resolve
ambiguous licenses exactly?

The runners are the users, such as distributions, and the rules of the
race are the interpretations of the licenses, including both the GPL and
OpenSSL licenses. Debian is insisting on running barefoot, and you're
saying that because Red Hat wears shoes, because no one else believes that
the rules ban shoes, Red Hat has some sort of unfair advantage.

On the contrary, it's Debian's insistence on following an idiosyncratic
license interpretation that's creating the supposed unfairness. This is
obviously not Red Hat's fault.

Post by Clint Byrum

Post by Russ Allbery
Red Hat is not responsible for our license interpretations. If the
rest of the world doesn't care, standing by our interpretation looks
less like ethics and more like masochism.

Adhering to a strict code of ethics is often fairly painful.

So is masochism. That doesn't make masochism a strict code of ethics.
You have to present some sort of argument that this is actually an ethical
question, as opposed to just weird literalism, which means making an
argument that it somehow matters to someone. I've already stated my
opinion on that position in previous messages.

Post by Clint Byrum
If the GPL licensors do not care, then they should be happy to grant an
OpenSSL exception.

This is demonstrably false, plus it can pose the same challenge as
changing the OpenSSL license, for which see below.

Post by Clint Byrum
If the OpenSSL licensors do not care, then they should be happy to
strike the incompatible requirement from the license.

This is a significant amount of work that they have no meaningful
incentive to do. Debian refusing to use their software in some situations
is not any sort of real incentive; Debian just acquires a reputation for
being weird outliers, and there's no real negative effect for the project.
The current OpenSSL authors didn't create the license terms. They were
inherited from the SSLeay project. It's hard to see why they should
invest significant time and energy and legal resources into this problem
when Red Hat and many others don't believe the problem exists to a
significant extent to worry about. They, like most of us, would much
rather use their resources to write code instead of hire lawyers and
debate legal issues.

It's great that some projects, like Moria and Angband, have done this work
to get rid of bad licenses, but I'll point out that in those cases the
license they got rid of was "no commercial use," which is much more
restrictive and problematic, not to mention less ambiguous. Getting rid
of the advertising clause is far more borderline, and as Clint points out,
is routinely violated by the whole free software community with no
noticable negative effects.

That's the other problem with this analysis of ethics: it's not like we're
complying with every jot and tittle of the licenses of software in the
archive right now. For example, see Bug#709382 (which I haven't done
anything about), or the numerous examples of packages where we don't
maintain a complete GPL-compliant log of changes. Rather, we make a huge
deal about, and go through extensive contortions over, *some* license
issues, like OpenSSL, while completely ignoring other ones that are harder
to check and verify. This is, in part, because applying that consistently
tight level of license compliance across *every* license requirement would
be paralyzing for anyone attempting to produce a Linux distribution. It's
just not feasible; there are too many weird corners of licenses with odd
implications that, in practice, everyone just ignores. The audit effort
required would be immense.

In this specific case, I believe we are taking an expansive interpretation
of the spirit of these licenses that is almost never shared by the people
who actually chose those licenses, as demonstrated by the reactions of
upstreams on those projects when pestered about this supposed issue.

I'm sure we could find some GPL-only upstream out there somewhere who
replies with "yes, I really don't want my code used with OpenSSL," just
like we ran into the University of Washington and their bizarre
interpretation of the MIT license. But we could deal with those as
individual cases, like we did with Pine and XFree86. By far the most
common reactions I've seen have been either "oh, sure, I'll add this
exception" because they never objected to this in the first place or
(sadly common), "Why are you bothering me with nonsensical legal bullshit?
If I didn't want the software to be used with OpenSSL, I wouldn't have
added OpenSSL support. Go away and bother someone else."

Has anyone asked the Git maintainers whether they object to their software
being linked with a libcurl that uses OpenSSL? What did they say?

[Clint Byrum]

Post by Russ Allbery

Post by Clint Byrum

Post by Russ Allbery

Post by Clint Byrum
An author is not the only party to text. There are also those who have
received this license, and adhered to it for the sake of the author
and the copyright holders who have also adhered to it.
So, it is rather disrespectful and could cause harm to those who have
worked within the confines of the text to at some point ignore the
text. I'm not suggesting it _will_ cause harm, but it may. In fact,
RedHat has harmed Debian and enriched themselves by ignoring it.

This strikes me as equivalent to a long-distance runner who insists on
running barefoot due to an idiosyncratic understanding of the rules of
the race that isn't shared by anyone else, including the judges, and
then gets upset at the other runners for winning while wearing shoes.
(Analogy intentionally chosen because it is possible to compete and win
in long-distance races barefoot, but most runners don't.)

This is a really confusing analogy. The runners are the end users of the
free software in question, and the GPL is the rules of the race? What is
the OpenSSL license then? How are these runners forced to resolve
ambiguous licenses exactly?

The runners are the users, such as distributions, and the rules of the
race are the interpretations of the licenses, including both the GPL and
OpenSSL licenses. Debian is insisting on running barefoot, and you're
saying that because Red Hat wears shoes, because no one else believes that
the rules ban shoes, Red Hat has some sort of unfair advantage.

Let's not quibble over analogies. I don't really think it is helpful
still.

Post by Russ Allbery
On the contrary, it's Debian's insistence on following an idiosyncratic
license interpretation that's creating the supposed unfairness. This is
obviously not Red Hat's fault.

To be clear what I am saying is that RedHat has taken a short cut for
their own interests and it is not known to be fair to the authors of
some software.

Post by Russ Allbery

Post by Clint Byrum

Post by Russ Allbery
Red Hat is not responsible for our license interpretations. If the
rest of the world doesn't care, standing by our interpretation looks
less like ethics and more like masochism.

Adhering to a strict code of ethics is often fairly painful.

So is masochism. That doesn't make masochism a strict code of ethics.
You have to present some sort of argument that this is actually an ethical
question, as opposed to just weird literalism, which means making an
argument that it somehow matters to someone. I've already stated my
opinion on that position in previous messages.

Fair enough, I think it is an ethical conundrum and thus must be dealt
with delicately.

Post by Russ Allbery

Post by Clint Byrum
If the GPL licensors do not care, then they should be happy to grant an
OpenSSL exception.

This is demonstrably false, plus it can pose the same challenge as
changing the OpenSSL license, for which see below.

Demonstrably false in what way? Agreed the challenge is gathering all of
the licensors together to grant the exception.

Post by Russ Allbery

Post by Clint Byrum
If the OpenSSL licensors do not care, then they should be happy to
strike the incompatible requirement from the license.

This is a significant amount of work that they have no meaningful
incentive to do. Debian refusing to use their software in some situations
is not any sort of real incentive; Debian just acquires a reputation for
being weird outliers, and there's no real negative effect for the project.
The current OpenSSL authors didn't create the license terms. They were
inherited from the SSLeay project. It's hard to see why they should
invest significant time and energy and legal resources into this problem
when Red Hat and many others don't believe the problem exists to a
significant extent to worry about. They, like most of us, would much
rather use their resources to write code instead of hire lawyers and
debate legal issues.

This is just one way Debian is different than RedHat and others.
"They're doing it so we should too" didn't work when I was a teenager
and it doesn't really work now. :-P

Post by Russ Allbery
It's great that some projects, like Moria and Angband, have done this work
to get rid of bad licenses, but I'll point out that in those cases the
license they got rid of was "no commercial use," which is much more
restrictive and problematic, not to mention less ambiguous. Getting rid
of the advertising clause is far more borderline, and as Clint points out,
is routinely violated by the whole free software community with no
noticable negative effects.

I'm not entirely sure that the advertising clause is violated by Debian
or even RedHat. I don't have data though. Seems like it would be fairly
simple for Debian to comply but it might be rather awkward for RedHat to
have to put a little * next to ever mention of SSL in RedHat products
with a subtext from the license.

Post by Russ Allbery
That's the other problem with this analysis of ethics: it's not like we're
complying with every jot and tittle of the licenses of software in the
archive right now. For example, see Bug#709382 (which I haven't done
anything about), or the numerous examples of packages where we don't
maintain a complete GPL-compliant log of changes. Rather, we make a huge
deal about, and go through extensive contortions over, *some* license
issues, like OpenSSL, while completely ignoring other ones that are harder
to check and verify. This is, in part, because applying that consistently
tight level of license compliance across *every* license requirement would
be paralyzing for anyone attempting to produce a Linux distribution. It's
just not feasible; there are too many weird corners of licenses with odd
implications that, in practice, everyone just ignores. The audit effort
required would be immense.

"We're compromising our ethics elsewhere so why not also accept
compromising them more here?"

AFAIK, we respond promptly to bug reports from licensors. For the bug
mentioned, I think we are acting in good faith by providing the sources
of the build-depends even if there is a bit of version skew. I understand
you're arguing that we would be acting in good faith by declaring libssl a
system library. I am not so sure, but thus far I don't think any consensus
has been reached on that.

Post by Russ Allbery
In this specific case, I believe we are taking an expansive interpretation
of the spirit of these licenses that is almost never shared by the people
who actually chose those licenses, as demonstrated by the reactions of
upstreams on those projects when pestered about this supposed issue.

And what about those upstreams that do actually care?

Post by Russ Allbery
I'm sure we could find some GPL-only upstream out there somewhere who
replies with "yes, I really don't want my code used with OpenSSL," just
like we ran into the University of Washington and their bizarre
interpretation of the MIT license. But we could deal with those as
individual cases, like we did with Pine and XFree86. By far the most
common reactions I've seen have been either "oh, sure, I'll add this
exception" because they never objected to this in the first place or
(sadly common), "Why are you bothering me with nonsensical legal bullshit?
If I didn't want the software to be used with OpenSSL, I wouldn't have
added OpenSSL support. Go away and bother someone else."

"I wouldn't have added OpenSSL support" does not necessarily reflect the
position of all of the copyright holders of the licensed work. It is
entirely possible, even likely, that code gets merged into a project
without the consent of all copyright holders. That doesn't mean that one
can or should violate the license.

[Jonathan Nieder]

Post by Russ Allbery
Has anyone asked the Git maintainers whether they object to their software
being linked with a libcurl that uses OpenSSL?

I am not the author of the most of Git. As a minority author:

- libcurl provides a quite similar API with OpenSSL as with GnuTLS.
I wish it provided a compatible ABI. Then this question could be
sidestepped (similarly to the way lesstif used to be used)

- I'm glad Debian git is not built against OpenSSL, since it provides
a sanity check that git works without that dependency. GnuTLS is
stricter about adherance to the TLS protocol and has caught some
server bugs that way. It might be worth trying a build against nss
to see how it compares.

- I do not want git binaries built to depend on and distributed with
non-free operating system components. I do not want e.g. Microsoft
to customize git to rely on some custom logic in proprietary DLLs
and then distribute it with the OS.

If the license that achieves that *also* makes git linked against
free components like OpenSSL nondistributable in some circumstances
(but still useful in other circumstances, like the Mac build where
OpenSSL comes separately as part of the OS), that's an unfortunate
but acceptable side effect, which I don't think it's worth chipping
away at the license to get rid of.

Using the GPL for git makes it easy to incorporate code from other
sources (e.g., the kernel). GPL+OpenSSL exception doesn't have
that property.

- Git has its own blk-sha1/ implementation which is pleasantly
written, portably written, and very fast. Even if there were no
licensing issues involved, git for Debian would be built with
BLK_SHA1=YesPlease (meaning the only relevant OpenSSL dependency
is via libcurl).

Hope that helps,
Jonathan

[Alessandro Ghedini]

Post by Jonathan Nieder

Post by Russ Allbery
Has anyone asked the Git maintainers whether they object to their software
being linked with a libcurl that uses OpenSSL?

- libcurl provides a quite similar API with OpenSSL as with GnuTLS.
I wish it provided a compatible ABI.

Different SONAMEs/symbols for different TLS providers is done so that things
that shouldn't, don't get linked against the wrong libcurl flavour (this has
been the case way before I became the curl maintainer).

It can be disabled though, but 1) if all the libcurl versions provided the same
*.so.X.Y,Z files, it'd make it impossible to install different versions at the
same time (e.g. libcurl3 + libcurl3-gnutls) and 2) all libcurl reverse depends
would have to be rebuilt.

Cheers

[Bernhard R. Link]

Post by Russ Allbery
On the contrary, it's Debian's insistence on following an idiosyncratic
license interpretation that's creating the supposed unfairness. This is
obviously not Red Hat's fault.

Could you please stop using that word "idiosyncratic". How about
using "interpretations I do not like".

Thanks in advance,
Bernhard R. Link

[Russ Allbery]

Post by Bernhard R. Link

Post by Russ Allbery
On the contrary, it's Debian's insistence on following an idiosyncratic
license interpretation that's creating the supposed unfairness. This
is obviously not Red Hat's fault.

Could you please stop using that word "idiosyncratic".

I believe idiosyncratic is exactly the correct term:

idiosyncratic
adj 1: peculiar to the individual; "we all have our own
idiosyncratic gestures"; "Michelangelo's highly
idiosyncratic style of painting"

and therefore decline to stop using it. We are the only project that
arrives at quite the conclusions that we arrive at, which makes our
license interpretation idiosyncratic by definition. All of the machinery,
such as the Desert Island Test or the Dissident Test, is peculiar to
Debian or to members of the broader community who were taught license
analysis by the Debian project.

There is nothing wrong with idiosyncracies. I have a large collection of
them. But I think we have a responsibility to own our own idiosyncracies
and not get upset at other people or projects for not having the same
ones.

Post by Bernhard R. Link
How about using "interpretations I do not like".

I'm not going to use that because it's not true. I actually prefer
Debian's interpretation because it appeals to me as a programmer. We're
very literal about licenses and assume they mean what they say they mean,
like code, and just steer clear of ones that seem to imply things we don't
like. I think this serves us well on several fronts: it's actually more
conservative than the legal system in several ways, and it tends to be
closer to how most of our upstreams who really care about licensing read
their licenses (since most of them are not lawyers and have no legal
advice), so it means we get along with them better.

There are, however, places where this license interpretation method gets
us into trouble precisely because it's not the license interpretation
method actually used by legal systems, and therefore not the one that
matters in the broader societies in which we're embedded. And, as a
result, we can end up in situations like we're in with TLS libraries where
there is no desirable library available for use in the places we want to
use it that satisfies our method of license interpretation. In part
because our method is not the method used by the legal world, and
therefore the incentive to adjust to our interpretation is low.

I'm not particularly interested in a radical change. I like how we
interpret licenses. I am interested in not continuing to beat our head
against the OpenSSL problem unless we see some real possibility of
changing the world by doing so (and the results have been disappointing to
date), or the legal system thinks we need to. Consider it an exception
where we go with a prevailing legal opinion instead of our own, dare I say
idiosyncratic, methods. The exception is worth it in this case *because*
OpenSSL is so pervasive and is causing us so many problems, and because I
think it's very difficult to find a point of ethics in our current stance
on the license (as opposed to slippery slope worries).

[Bernhard R. Link]

Post by Russ Allbery

Post by Bernhard R. Link

Post by Russ Allbery
On the contrary, it's Debian's insistence on following an idiosyncratic
license interpretation that's creating the supposed unfairness. This
is obviously not Red Hat's fault.

Could you please stop using that word "idiosyncratic".

idiosyncratic
adj 1: peculiar to the individual; "we all have our own
idiosyncratic gestures"; "Michelangelo's highly
idiosyncratic style of painting"
and therefore decline to stop using it.

Given that the GPL FAQ and thus the authors of the license seem
to be of the same opinion, calling an interpretation you do not
like as "peculiar to the individual" is already quite derogative.
Using a term that sounds quite similar like idiotic for this
is something even a troll could not do better.

Bernhard R. Link

[Thomas Goirand]

Post by Marco d'Itri
This is self-inflicted damage, and I think it's slightly arrogant to
pretend that Debian is the only organization which cares about ethics.

For once, I agree with you Marco.

Post by Marco d'Itri
If it were to reverse position,
those users who have been diligently adhering to the license and
expending resources would be at a disadvantage to new users who
won't have to deal with that. That may be a position a business
can take, but as volunteer organization with no profit motive,
I think Debian has to take more care
to stay as close to the ethical center as possible.

Are you saying that, just because we inflicted pain before, just for the
sake of being fair to everyone, that pain should stay? I must be wrong,
and didn't get it right... :/

Thomas

[Clint Byrum]

Post by Thomas Goirand

Post by Marco d'Itri
This is self-inflicted damage, and I think it's slightly arrogant to
pretend that Debian is the only organization which cares about ethics.

For once, I agree with you Marco.

Post by Marco d'Itri
If it were to reverse position,
those users who have been diligently adhering to the license and
expending resources would be at a disadvantage to new users who
won't have to deal with that. That may be a position a business
can take, but as volunteer organization with no profit motive,
I think Debian has to take more care
to stay as close to the ethical center as possible.

Are you saying that, just because we inflicted pain before, just for the
sake of being fair to everyone, that pain should stay? I must be wrong,
and didn't get it right... :/

Not so much that "because we inflicted pain before" but "because nothing
has changed other than time". If we have gained some new insight then that
may be enough reason to reverse position. Or maybe we're just tired of
being the only ones actually trying. My point is, we made decisions for
our users and we should not take a reversal lightly.

[Thomas Goirand]

Post by Clint Byrum

Post by Thomas Goirand

Post by Marco d'Itri
This is self-inflicted damage, and I think it's slightly arrogant to
pretend that Debian is the only organization which cares about ethics.

For once, I agree with you Marco.

Post by Marco d'Itri
If it were to reverse position,
those users who have been diligently adhering to the license and
expending resources would be at a disadvantage to new users who
won't have to deal with that. That may be a position a business
can take, but as volunteer organization with no profit motive,
I think Debian has to take more care
to stay as close to the ethical center as possible.

Are you saying that, just because we inflicted pain before, just for the
sake of being fair to everyone, that pain should stay? I must be wrong,
and didn't get it right... :/

Not so much that "because we inflicted pain before" but "because nothing
has changed other than time".

Well, together with time, the thing that has changed, is that we're
seeing more and more cases that are annoying package maintainers, and
therefore, indirectly, our users.

Post by Clint Byrum
If we have gained some new insight then that
may be enough reason to reverse position. Or maybe we're just tired of
being the only ones actually trying. My point is, we made decisions for
our users and we should not take a reversal lightly.

I think we've well passed the point where that old decision is doing
more bad than good to our users. Even if the licensing issue itself
didn't change, and that probably it made sense at some point in time, I
don't think it does anymore, especially seeing that almost no upstream
author cares about Debian's nit-picking on this particular issue. We're
just beating ourselves for no valid reason.

Cheers,

Thomas

[Bernhard R. Link]

Post by Thomas Goirand
don't think it does anymore, especially seeing that almost no upstream
author cares about Debian's nit-picking on this particular issue. We're
just beating ourselves for no valid reason.

Almost no upstream author cares about licensing at all. The mayority of
them has no problems giving self-contradictionary terms. Distributing
stuff with no license at all. Or simply copying other people's code
without looking at the license or even without including any license
statement or even copyright notice.

Debian is no corporation that can just willy-nilly copy stuff around
without caring for the law and hoping noone will find out or just
pay the authors off if they find out. And our users are not really
helped if the software they depended on suddenly is no longer available
because noone cared for the license before.

Bernhard R. Link

[Marco d'Itri]

Post by Bernhard R. Link
Almost no upstream author cares about licensing at all. The mayority of

Great, no ethical issues to be concerned with then.

Post by Bernhard R. Link
Debian is no corporation that can just willy-nilly copy stuff around
without caring for the law and hoping noone will find out or just
pay the authors off if they find out. And our users are not really

You are seriously mistaken about how copyright infringement lawsuits
work: corporations like Red Hat have to be really careful because since
they can pay damages then they can be sued.
There would be no point in suing Debian since we do not have enough
money to be worth the legal effort.
This is why we happily distribute some patented software which Red Hat
does not, like MP3 decoders or (some kinds of) elliptic curves
cryptography.

[Shawn Wilson]

My gut reaction was that #5 or #6 are the best option (leaning to #6). However I guess I don't understand what making something a system library effects the license?

Post by Andreas Metzler
Hello,
Debian ist still relying heavily on GnuTLS 2.12.x, and I do not think
this is sustainable for much longer.
---------
In July 2011 with version 3.0 [1] GnuTLS switched to Nettle as only
supported crypto backend. Nettle requires GMP.
GnuTLS and Nettle are available under LGPLv2.1+. GMP used to be
licensed LGPLv2.1+ ages ago but upgraded to LGPLv3+ in version 4.2.2
(released September 2007).
Therefore GnuTLS 3.x cannot be used by GPLv2 (without "or later"
clause) software which is the main reason most of Debian is still
using GnuTLS 2.x.
---------
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+
#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.
---------
I do not think #1 and #2 are realistic given Debian's manpower issues. Also
#1 would stop working at all if nettle required newer GMP features. (I
have not checked whether this is already the case.)
I have given up on #3 and do not think it will happen. GMP upstream has
been made aware of the issue in 2011 [2] and has not shown any
intention of
a license change.
#4 is just here for completeness sake.
#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.
Fedora is discussing the issue in
<https://bugzilla.redhat.com/show_bug.cgi?id=986347>. There is
automatically generated depency tree with the problematic packages
highlighted crosslinked in the bugreport[3]. Debian does not have the
infrastructure to do something similar, but I guess gnutls usage is
more widespread.
---------
Afaict it boils down to #6. But perhaps I have missed something
obvious. Comments welcome.
cu Andreas
[1] Version 2.11.1 (released 2010-09-14) used nettle as
/prefered/ crypto backend, however gcrypt was still supported as
alternative.
[2] http://gmplib.org/list-archives/gmp-bugs/2011-February/002178.html
http://gmplib.org/list-archives/gmp-devel/2011-May/001952.html
[3] http://people.redhat.com/nmavrogi/fedora/out.fedora.txt
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[Simon Josefsson]

FWIW, I support moving forward with #6.

/Simon

Post by Shawn Wilson
My gut reaction was that #5 or #6 are the best option (leaning to
#6). However I guess I don't understand what making something a
system library effects the license?

Post by Andreas Metzler
Hello,
Debian ist still relying heavily on GnuTLS 2.12.x, and I do not think
this is sustainable for much longer.
---------
In July 2011 with version 3.0 [1] GnuTLS switched to Nettle as only
supported crypto backend. Nettle requires GMP.
GnuTLS and Nettle are available under LGPLv2.1+. GMP used to be
licensed LGPLv2.1+ ages ago but upgraded to LGPLv3+ in version 4.2.2
(released September 2007).
Therefore GnuTLS 3.x cannot be used by GPLv2 (without "or later"
clause) software which is the main reason most of Debian is still
using GnuTLS 2.x.
---------
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+
#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.
---------
I do not think #1 and #2 are realistic given Debian's manpower issues. Also
#1 would stop working at all if nettle required newer GMP features.
(I have not checked whether this is already the case.)
I have given up on #3 and do not think it will happen. GMP upstream
has been made aware of the issue in 2011 [2] and has not shown any
intention of
a license change.
#4 is just here for completeness sake.
#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.
Fedora is discussing the issue in
<https://bugzilla.redhat.com/show_bug.cgi?id=986347>. There is
automatically generated depency tree with the problematic packages
highlighted crosslinked in the bugreport[3]. Debian does not have the
infrastructure to do something similar, but I guess gnutls usage is
more widespread.
---------
Afaict it boils down to #6. But perhaps I have missed something
obvious. Comments welcome.
cu Andreas
[1] Version 2.11.1 (released 2010-09-14) used nettle as
/prefered/ crypto backend, however gcrypt was still supported as
alternative.
[2]
http://gmplib.org/list-archives/gmp-bugs/2011-February/002178.html
http://gmplib.org/list-archives/gmp-devel/2011-May/001952.html
[3] http://people.redhat.com/nmavrogi/fedora/out.fedora.txt
--
`What a good friend you are to him, Dr. Maturin. His other friends
are so grateful to you.'
`I sew his ears on from time to time, sure'

[Carlos Alberto Lopez Perez]

Post by Shawn Wilson
My gut reaction was that #5 or #6 are the best option (leaning to #6). However I guess I don't understand what making something a system library effects the license?

Post by Andreas Metzler
#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.

I would vote for #5 and also I would re-evaluate our position regarding
OpenSSL by asking a lawyer as others have expressed in this thread.


About the system library exception, this is what the GPL FAQ tells:


Q: Can I link a GPL program with a proprietary system library?

A: Both versions of the GPL have an exception to their copyleft,
commonly called the system library exception. If the GPL-incompatible
libraries you want to use meet the criteria for a system library, then
you don't have to do anything special to use them; the requirement to
distribute source code for the whole program does not include those
libraries, even if you distribute a linked executable containing them.

The criteria for what counts as a "system library" vary between
different versions of the GPL. GPLv3 explicitly defines "System
Libraries" in section 1, to exclude it from the definition of
"Corresponding Source." GPLv2 deals with this issue slightly
differently, near the end of section 3.


https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

[Steve Langasek]

Post by Carlos Alberto Lopez Perez
Q: Can I link a GPL program with a proprietary system library?
A: Both versions of the GPL have an exception to their copyleft,
commonly called the system library exception. If the GPL-incompatible
libraries you want to use meet the criteria for a system library, then
you don't have to do anything special to use them; the requirement to
distribute source code for the whole program does not include those
libraries, even if you distribute a linked executable containing them.
The criteria for what counts as a "system library" vary between
different versions of the GPL. GPLv3 explicitly defines "System
Libraries" in section 1, to exclude it from the definition of
"Corresponding Source." GPLv2 deals with this issue slightly
differently, near the end of section 3.
https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

The GPL FAQ has historically failed to cover various nuances of the license
that affect OS distributors. The FAQ is not the license.

The FAQ previously gave uselessly unclear advice around GPL plugins, as
well.

[Andreas Metzler]

On 2013-12-22 Andreas Metzler <***@debian.org> wrote:
[...]

Post by Andreas Metzler
In July 2011 with version 3.0 [1] GnuTLS switched to Nettle as only
supported crypto backend. Nettle requires GMP.
GnuTLS and Nettle are available under LGPLv2.1+. GMP used to be
licensed LGPLv2.1+ ages ago but upgraded to LGPLv3+ in version 4.2.2
(released September 2007).

[...]

Post by Andreas Metzler
---------
#1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.

[...]

Good morning,

Adding one of the missing pieces:

nettle (2.7.1) can be built against GMP 4.2.1, however there is a
testsuite failure (ecc-modinv-test). The failure is probably caused by
some upstream bug in GMP. - Upgrading gmp to 2:4.3.1+dfsg-1 lets the
the test succeed, while versions up to and including 2:4.2.4+dfsg-8.1
fail.

cu Andreas

[Florian Weimer]

Post by Andreas Metzler
---------
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.

Post by Andreas Metzler
#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)

Post by Andreas Metzler
#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?

[Moritz Mühlenhoff]

Post by Florian Weimer
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?

We should have done that a decade ago...

The SFLC can probably help, but an official request to them on behalf
of the project should probably be initiated by the DPL. Fortunately
there's a DPL election happening, so a perfect time to raise that question
to the candidates :-)

Cheers,
Moritz

[Carlos Alberto Lopez Perez]

Post by Florian Weimer

Post by Andreas Metzler
#5 Declare GMP to be a system library.

(snip)

Post by Andreas Metzler
#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]

Post by Carlos Alberto Lopez Perez

Post by Florian Weimer

Post by Andreas Metzler
#5 Declare GMP to be a system library.

(snip)

Post by Andreas Metzler
#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]

Post by Dmitry Alexandrov

Post by Carlos Alberto Lopez Perez

Post by Florian Weimer

Post by Andreas Metzler
#5 Declare GMP to be a system library.

(snip)

Post by Andreas Metzler
#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?

[Andrey Rahmatullin]

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?

[Carlos Alberto Lopez Perez]

Post by Andrey Rahmatullin

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.

[Carlos Alberto Lopez Perez]

[...]

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]

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"?

[Andrey Rahmatullin]

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.

It's worse that being compatible with GPL2 too.

Post by Brian May
Or maybe you meant to write "incompatable"?

No.

[Carlos Alberto Lopez Perez]

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]

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]

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]

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

[Clint Byrum]

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.

Perhaps enough time has passed to reconsider. IMO this is not so much a
legal matter, but a moral and ethical one. We also have to think about
what to do with the Apache 2 licensed OpenSSL, which makes this a good
time to start thinking about it again.

[Carlos Alberto Lopez Perez]

Post by Clint Byrum

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]

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

[Adam Borowski]

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.

We're all coders here, so here's a code example:
==========================
void main()
{
printf("meow\n");
}
==========================

Hey, it works! It might lack that #include <stdio.h> thus might not compile
in some setups, and produces a bogus exit code (5 on amd64, armhf and arm64
on current unstable), but it produces the right output, and those who run
scripts with "set -e" are only bringing problems upon themselves, right?

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.

(And yeah, in the current legal practice, even being 100% clean has
surprisingly low impact on whether you win in court. A "win" where you pay
tens of thousands of dollars doesn't count as a win.)

[Florian Weimer]

Post by Adam Borowski
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]

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]

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.

[Clint Byrum]

Post by Carlos Alberto Lopez Perez

Post by Clint Byrum

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.

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?

Of course not! Personally I believe implementing an OpenSSL interface
is a de facto exception grant.

[Jonas Smedegaard]

Quoting Carlos Alberto Lopez Perez (2017-03-30 05:08:24)

Post by Carlos Alberto Lopez Perez

Post by Clint Byrum

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

[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 Clint Byrum

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]

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 Clint Byrum

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

[Philip Hands]

Post by Carlos Alberto Lopez Perez

Post by Clint Byrum

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.

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?

Sorry, but people's intent is not sufficient.

Let's we decide that we're going to ignore a license, because the
author's a jolly nice person who obviously wasn't concentrating when
they chose the license.

We thus inflict this license violation on our users, our downstreams,
and their users.

Some of those users might then build their infrastructure upon that
software, meaning that changing it could be very costly, and those users
might be wealthy enough to be interesting to copyright trolls.

Then the copyright holder dies and their estate passes on to someone
that wants to maximise its value, so they sell the copyright to a
copyright troll, who then goes around threatening to sue for the GPL
violation, offering an explicit exception ... for a fee.

I think our users expect us not to put them in that situation.

What is the huge upside that makes it worth forcing our users to take
this risk without their explicit consent?

Cheers, Phil.

[Vincent Bernat]

Post by Clint Byrum

Post by Carlos Alberto Lopez Perez
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.

As Carlos, it's hard for me to believe anyone will object to OpenSSL
linking, all the more when they implemented the support for it. Most
upstreams weren't just aware of the need to add an exception (or believe
this is not needed).

In some cases, we ignore the problem too (despite not doing a profit),
even in a case where the copyright holder may have a problem with
OpenSSL (because they would prefer people to use their own SSL
implementation). Here is an old example with Python (not GPL), OpenSSL,
GNU Readline (GPL, no exception):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498857

[Lars Wirzenius]

Post by Vincent Bernat
As Carlos, it's hard for me to believe anyone will object to OpenSSL
linking, all the more when they implemented the support for it.

A compication in this is that even though the developers of a program
would be happy with linking to OpenSSL, people who've written other
libraries the program uses, or other code included in the program, may
not be. I'm such a person. If some code I've released some code under
GPL2 (only), and you link use it in a way that causes it to be linked
with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
to sue you (life is too short), but I might grumble lengthily into my
cup of tea.

[Vincent Bernat]

Post by Lars Wirzenius

Post by Vincent Bernat
As Carlos, it's hard for me to believe anyone will object to OpenSSL
linking, all the more when they implemented the support for it.

A compication in this is that even though the developers of a program
would be happy with linking to OpenSSL, people who've written other
libraries the program uses, or other code included in the program, may
not be. I'm such a person. If some code I've released some code under
GPL2 (only), and you link use it in a way that causes it to be linked
with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
to sue you (life is too short), but I might grumble lengthily into my
cup of tea.

Well, that's really new to me. Why would you object to link to OpenSSL?

[Lars Wirzenius]

Post by Vincent Bernat
Well, that's really new to me. Why would you object to link to OpenSSL?

I'm not sure how to respond to this.

I don't understand why it is new to you. The conflict between the
OpenSSL and GPL licences is well known, at least within Debian. I
don't like weakening the GPL for my own code.

[Florian Weimer]

Post by Lars Wirzenius
A compication in this is that even though the developers of a program
would be happy with linking to OpenSSL, people who've written other
libraries the program uses, or other code included in the program, may
not be. I'm such a person. If some code I've released some code under
GPL2 (only), and you link use it in a way that causes it to be linked
with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
to sue you (life is too short), but I might grumble lengthily into my
cup of tea.

This is interesting.

Do you hold the same position regarding newer versions of GCC (which
have changed the libgcc license to GPLv3+ (plus exceptions), which is
probably as GPLv2-compatible as the OpenSSL license)?

On some architectures, libgcc is required for full “long long”
support, so it's not really optional even for C.

[Lars Wirzenius]

Post by Florian Weimer

Post by Lars Wirzenius
A compication in this is that even though the developers of a program
would be happy with linking to OpenSSL, people who've written other
libraries the program uses, or other code included in the program, may
not be. I'm such a person. If some code I've released some code under
GPL2 (only), and you link use it in a way that causes it to be linked
with OpenSSL without asking me, you'll make me unhappy. I'm unlikely
to sue you (life is too short), but I might grumble lengthily into my
cup of tea.

This is interesting.
Do you hold the same position regarding newer versions of GCC (which
have changed the libgcc license to GPLv3+ (plus exceptions), which is
probably as GPLv2-compatible as the OpenSSL license)?
On some architectures, libgcc is required for full “long long”
support, so it's not really optional even for C.

I say I want people to ask before they do something that my licence
doesn't allow. You want me to have an opinion on another licencing
situation. I don't want to play this game. It'll just end in me asking
probing questions about other people's tea preferences.

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.

I don't like convoluted, controversial re-interpretations of legalese
to achieve Nirvana.

[Russ Allbery]

Post by Lars Wirzenius
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.

[Carlos Alberto Lopez Perez]

Post by Russ Allbery

Post by Lars Wirzenius
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]

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]

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

[Andrey Rahmatullin]

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?

[Josh Triplett]

Post by Carlos Alberto Lopez Perez

Post by Florian Weimer

Post by Andreas Metzler
#5 Declare GMP to be a system library.

(snip)

Post by Andreas Metzler
#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.

[Carlos Alberto Lopez Perez]

Post by Josh Triplett

Post by Carlos Alberto Lopez Perez

Post by Florian Weimer

Post by Andreas Metzler
#5 Declare GMP to be a system library.

(snip)

Post by Andreas Metzler
#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

[Florian Weimer]

Post by Josh Triplett
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.

But those vendors have since stopped doing that, and the GNU tools are
shipped along with the rest of the operating system (Solaris, Macos),
or at least together with the libc they are linked against (Interix).