Discussion:
GnuTLS in Debian
(too old to reply)
Andreas Metzler
2013-12-22 19:20:02 UTC
Permalink
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
--
`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'
brian m. carlson
2013-12-22 20:00:02 UTC
Permalink
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.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Ben Hutchings
2013-12-22 21:10:02 UTC
Permalink
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.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
Bastien ROUCARIES
2013-12-22 23:00:02 UTC
Permalink
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.
Florian Weimer
2013-12-30 09:10:02 UTC
Permalink
Post by Bastien ROUCARIES
Fedora created a open SSL compat library based on libnss.
It doesn't work all that well because there is no way to implement
host name checking. The OpenSSL API it's based on did not have an
interface for host name verification, and the compatibility library
does not duplicate enough of OpenSSL's ASN.1-related functionality so
that applications can implement the verification themselves.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@mid.deneb.enyo.de
Bastien ROUCARIES
2014-01-01 17:50:02 UTC
Permalink
Post by Florian Weimer
Post by Bastien ROUCARIES
Fedora created a open SSL compat library based on libnss.
It doesn't work all that well because there is no way to implement
host name checking. The OpenSSL API it's based on did not have an
interface for host name verification, and the compatibility library
does not duplicate enough of OpenSSL's ASN.1-related functionality so
that applications can implement the verification themselves.
Could we list on a wiki the lack this library?

I will upload it and you could open a bug.after it.

Bastien
Bastien ROUCARIES
2013-12-23 16:00:02 UTC
Permalink
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.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/CAE2SPAYk9sAn=a23jpnRD_VQB_MnMHPN3F+A-***@mail.gmail.com
Carlos Alberto Lopez Perez
2013-12-24 04:30:02 UTC
Permalink
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
2013-12-22 20:40:01 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@inutil.org
Russ Allbery
2013-12-22 21:00:02 UTC
Permalink
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.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Marco d'Itri
2013-12-22 23:30:03 UTC
Permalink
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.
--
ciao,
Marco
Steve Langasek
2013-12-23 00:30:01 UTC
Permalink
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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Russ Allbery
2013-12-23 00:40:02 UTC
Permalink
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.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Faidon Liambotis
2013-12-23 06:50:01 UTC
Permalink
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.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@debian.org
Steve Langasek
2013-12-24 07:50:01 UTC
Permalink
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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Felipe Sateler
2013-12-25 17:00:02 UTC
Permalink
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.
--
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/l9f2pm$m5n$***@ger.gmane.org
Marco d'Itri
2013-12-23 16:10:02 UTC
Permalink
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.
--
ciao,
Marco
Clint Byrum
2013-12-23 17:50:01 UTC
Permalink
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.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/1387818795-sup-***@clint-HP
Russ Allbery
2013-12-23 19:00:02 UTC
Permalink
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.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Stephan Seitz
2013-12-23 19:20:02 UTC
Permalink
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
--
| Stephan Seitz E-Mail: ***@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
Russ Allbery
2013-12-23 19:30:02 UTC
Permalink
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.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Clint Adams
2013-12-23 20:10:02 UTC
Permalink
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.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@scru.org
Steve Langasek
2013-12-23 20:30:02 UTC
Permalink
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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Russ Allbery
2013-12-23 21:00:02 UTC
Permalink
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.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Steve Langasek
2013-12-24 07:00:02 UTC
Permalink
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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Thorsten Glaser
2013-12-27 14:50:02 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@herc.mirbsd.org
Kurt Roeckx
2013-12-28 01:50:02 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@roeckx.be
Dimitri John Ledkov
2013-12-23 21:00:02 UTC
Permalink
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?!
--
Regards,

Dimitri.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/CANBHLUgmSLOX8xWZy8c0sovHQsX=e-***@mail.gmail.com
Russ Allbery
2013-12-23 21:20:02 UTC
Permalink
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.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Clint Adams
2013-12-23 22:50:02 UTC
Permalink
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.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@scru.org
David Weinehall
2013-12-28 08:50:01 UTC
Permalink
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
--
/) David Weinehall <***@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@hirohito.acc.umu.se
Vincent Lefevre
2013-12-28 11:00:02 UTC
Permalink
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)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@xvii.vinc17.org
Clint Adams
2013-12-28 21:00:02 UTC
Permalink
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?
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@scru.org
Stephen M. Webb
2013-12-28 21:20:02 UTC
Permalink
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.
--
Stephen M. Webb <***@bregmasoft.ca>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@bregmasoft.ca
Kurt Roeckx
2013-12-28 21:20:03 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@roeckx.be
Stephen M. Webb
2013-12-28 23:10:02 UTC
Permalink
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.
--
Stephen M. Webb <***@bregmasoft.ca>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@bregmasoft.ca
Виталий Филиппов
2013-12-28 23:40:02 UTC
Permalink
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.
--
With best regards,
Vitaliy Filippov
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@vitalif.vhome
Simon McVittie
2013-12-29 00:40:02 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@debian.org
Kurt Roeckx
2013-12-29 01:00:02 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@roeckx.be
Stephen M. Webb
2013-12-29 01:40:01 UTC
Permalink
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.
--
Stephen M. Webb <***@bregmasoft.ca>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@bregmasoft.ca
Steve Langasek
2013-12-29 03:40:02 UTC
Permalink
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? ;)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Vincent Lefevre
2013-12-29 11:50:01 UTC
Permalink
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)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@xvii.vinc17.org
Vincent Lefevre
2013-12-29 02:00:02 UTC
Permalink
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)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@xvii.vinc17.org
Florian Weimer
2013-12-29 21:00:03 UTC
Permalink
Post by Stephen M. Webb
Nope. An organization that will not accept the GPLv3 because of the
tivoization and patent clauses will not accept GPLv2 or later.
Apple allegedly rejects the GPLv3, but continues to distribute
GPLv2-or-later code.

Microsoft distributes GPLv2-or-later code, too.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@mid.deneb.enyo.de
Craig Small
2013-12-30 03:20:01 UTC
Permalink
Post by Stephen M. Webb
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.
Oh man, you can tell they never worked under the NM process under me
then, because that was one of my favourite questions.

The "(at your option)" is absolutely critical here. Those organizations
that have taken that line have missed this point. That's what stops
things like "tentacles of evil".

That version of that software will always be GPL v2, or if they (and
only they) like, GPL v3. It is their decision for that particular
release of software.

Now, the developer might choose to license under GPLv3 next release,
but then he/she/them could relicense under whatever license they
collectively feel like it too.

GPL-2+ means I release it as GPLv2, but any user of my software can
choose to have it under GPLv3. It also means subsequent developers
could release it as v3, but that could/would be a fork if the primary
development is still ongoing.

- Craig
--
Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@enc.com.au
David Weinehall
2013-12-29 03:00:03 UTC
Permalink
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
--
/) David Weinehall <***@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@hirohito.acc.umu.se
Clint Adams
2013-12-31 15:00:02 UTC
Permalink
Post by David Weinehall
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.
So your doomsday scenario is that if you license something
GPLv2+, someone might fork and modify it to be GPLv3+, and
then someone else with a different doomsday scenario can't
incorporate those modifications into GPLv2-only software?
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@scru.org
cameron
2013-12-31 15:40:02 UTC
Permalink
Matt,

Yes, it is possible, but only the contributions of the fork would be
GPLv3 only, the original GPLv2+ code would still be just that.
Nevertheless, the final product would be GPLv3 only.

Cameron Norman
Post by Clint Adams
Post by David Weinehall
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.
So your doomsday scenario is that if you license something
GPLv2+, someone might fork and modify it to be GPLv3+,
I was under the impression that forks couldn't change licenses. Is the
scenario which Clint describes (legally) possible?
-mz
--
with a subject of "unsubscribe". Trouble? Contact
Matt Zagrabelny
2013-12-31 15:40:02 UTC
Permalink
Post by Clint Adams
Post by David Weinehall
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.
So your doomsday scenario is that if you license something
GPLv2+, someone might fork and modify it to be GPLv3+,
I was under the impression that forks couldn't change licenses. Is the
scenario which Clint describes (legally) possible?

-mz
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/CAOLfK3UOxX+f0_Ca9LWE-n6p50y-***@mail.gmail.com
Kurt Roeckx
2013-12-31 15:50:02 UTC
Permalink
Post by Clint Adams
Post by David Weinehall
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.
So your doomsday scenario is that if you license something
GPLv2+, someone might fork and modify it to be GPLv3+,
I was under the impression that forks couldn't change licenses. Is the
scenario which Clint describes (legally) possible?
The boilerplate says: "you can redistribute it and/or modify it
[...] either version X of the License, or (at your option) any
later version."

As I understand it, assuming X is 2, this means I can redistribute
this under 2, 2+, 3, 3+ without needing any persmissions from the
copyright holder because they already said I can redistribute and
modify it under "2 or later". But people of course aren't going
to be interested in my version just because I change the license,
but they might if I make some changes under this new license.

Please note that that doesn't mean that if I get something from
someone and it says "2 or later" that I can say I received it
under 3. I received the 2 version, but I can change it to 3 if
I wanted to.


Kurt
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@roeckx.be
Paul Tagliamonte
2014-01-04 03:30:02 UTC
Permalink
Post by Clint Adams
So your doomsday scenario is that if you license something
GPLv2+, someone might fork and modify it to be GPLv3+,
I was under the impression that forks couldn't change licenses. Is the
scenario which Clint describes (legally) possible?
I drew up this table a few weeks back when someone was misunderstanding
the GPL combination stuff.
/
| HELPFUL GPL UPGRADE TABLE
|
|
| +-------+--------+-------+--------+
| | GPL-2 | GPL-2+ | GPL-3 | GPL-3+ | <=========
| +-------+-------+--------+-------+--------+ \\
| | GPL-2 | GPL-2 | GPL-2 | NO!!! | NO!!! | ||
| +-------+-------+--------+-------+--------+ ||
| | GPL-2+| GPL-2 | GPL-2+ | GPL-3 | GPL-3+ | ||
| +-------+-------+--------+-------+--------+ ||
| | GPL-3 | NO!!! | GPL-3 | GPL-3 | GPL-3 | ||
| +-------+-------+--------+-------+--------+ ||
| | GPL-3+| NO!!! | GPL-3+ | GPL-3 | GPL-3+ | ||
| +-------+-------+--------+-------+--------+ ||
| ^^ ||
| || ||
|Take the license of your work ||
| ||
| and match it with the license of the work you want
| to include into your work (linking, static linking,
| copying into, any sort of memory sharing)
|
|
| Find the grid that matches the two entries.
| This value is the license that you may distribute
| the derived work under.
|
| If the value is "NO!!!", then you're violating the
| terms of the GPL and *MAY NOT* distribute this work.
\

Didn't think I'd have to post it to a Debian mailing list, but alas.

The resulting license is the work, when it's all jumbled up and combined,
*not* the original code that was GPL-2+. That will stay 2+ regardless of
what it's being used in, and can be taken out to restore it's 2+-eyness.

Cheers,
Paul
--
.''`. Paul Tagliamonte <***@debian.org> | Proud Debian Developer
: :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`. `'` http://people.debian.org/~paultag
`- http://people.debian.org/~paultag/conduct-statement.txt
Luca Capello
2014-01-04 10:10:01 UTC
Permalink
Hi there!
Post by Paul Tagliamonte
Post by Clint Adams
So your doomsday scenario is that if you license something
GPLv2+, someone might fork and modify it to be GPLv3+,
I was under the impression that forks couldn't change licenses. Is the
scenario which Clint describes (legally) possible?
I drew up this table a few weeks back when someone was misunderstanding
the GPL combination stuff.
/
| HELPFUL GPL UPGRADE TABLE
Without checking in details Paul's table, upstream FAQ contains a
commented matrix where copying and usage are separate (as it should):

<http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility>

Thx, bye,
Gismo / Luca
David Weinehall
2014-01-01 10:00:03 UTC
Permalink
Post by Clint Adams
Post by David Weinehall
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.
So your doomsday scenario is that if you license something
GPLv2+, someone might fork and modify it to be GPLv3+, and
then someone else with a different doomsday scenario can't
incorporate those modifications into GPLv2-only software?
In essence, yes. While I do realise that no version of the GPL
guarantees that I can fold back downstream modifications into my
codebase (since the modifications need only be released further
downstream), there's a huge difference between "there's a theoretical
chance that the awesome improvement written by downstream user X will
never reach you" and "You cannot include said improvement even if you do
get hold of the modification".

While the situation is probably familiar to many developers who choose
BSD licenses for their software only to see their code folded into GPL
or proprietary software without being able to merge back the
improvements, they have in the first place chosen a license that has
this possiblity as one of its intentions. The BSD allows for this, I
would almost say that it encourages it. BSD licensed code is folded
into proprietary software all the time.

That's also why I *don't* use BSD-style licenses for software that
I write, but rather GPLv2 or LGPLv2.1.

The fact that the GPLv3 changed the license to be incompatible with, and
(at least in my opinion) not equivalent to the GPL v2, violates what I
saw as one of the attractive things with the GPL, being the "share and
share alike" way of thinking. I always envisioned the (or later) clause
to be meant for fixing minor issues (unclear phrasing, inadvertent
stuff, etc.) like the changes from LGPL v2 to LGPL v2.1.

If someone really feels that some portion of codes I've written would be
useful for their project I'm more than happy to license that particular
bit -- almost -- whichever way they want (GPLv3, BSD, MIT, ...),
but I'm very uncomfortable with the notion of having forks of my
projects use a different license than my software does.


Regards: David
--
/) David Weinehall <***@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@hirohito.acc.umu.se
Clint Adams
2014-01-04 03:20:01 UTC
Permalink
Post by David Weinehall
That's also why I *don't* use BSD-style licenses for software that
I write, but rather GPLv2 or LGPLv2.1.
So if someone takes your LGPLv2.1-only software and adds GPLv2-only
code to it, do you feel similarly betrayed because you can't take
that code back?
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@scru.org
David Weinehall
2014-01-06 15:10:02 UTC
Permalink
Post by Clint Adams
Post by David Weinehall
That's also why I *don't* use BSD-style licenses for software that
I write, but rather GPLv2 or LGPLv2.1.
So if someone takes your LGPLv2.1-only software and adds GPLv2-only
code to it, do you feel similarly betrayed because you can't take
that code back?
Yes; that ruins the whole purpose of choosing of the LGPL --
not only does the GPL not allow proprietary software to link
against it (which is, for me, the whole point of licensing a library
under the LGPL), but a change from LGPL to GPL is also oneway.

The only situation I find such a license transformation morally ok is
when taking parts of the code to incorporate in a project (let's say
that a library contains a neat utility function that might be useful in
another project. Linking against a library just for the sake of a
single utility function is pretty over the top, but borrowing that code
(properly credited, of course) feels perfectly fine.


Regards: David
--
/) David Weinehall <***@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@hirohito.acc.umu.se
Dimitri John Ledkov
2014-01-06 15:30:02 UTC
Permalink
Post by David Weinehall
Post by Clint Adams
Post by David Weinehall
That's also why I *don't* use BSD-style licenses for software that
I write, but rather GPLv2 or LGPLv2.1.
So if someone takes your LGPLv2.1-only software and adds GPLv2-only
code to it, do you feel similarly betrayed because you can't take
that code back?
Yes; that ruins the whole purpose of choosing of the LGPL --
not only does the GPL not allow proprietary software to link
against it (which is, for me, the whole point of licensing a library
under the LGPL), but a change from LGPL to GPL is also oneway.
The only situation I find such a license transformation morally ok is
when taking parts of the code to incorporate in a project (let's say
that a library contains a neat utility function that might be useful in
another project. Linking against a library just for the sake of a
single utility function is pretty over the top, but borrowing that code
(properly credited, of course) feels perfectly fine.
Well, instead of using "or later" clause, one can
dual/tripple/multiple license code under licenses one is ok with.
E.g. GPLv2 | GPLv3 and _without and later_

But GPL text does confuse me as a whole, no modifications nor derivate
works of the GPL license text are allowed, and the original text has
"and later" clause - is licensing without "and later" constitues
modification of the GPL license text, which is prohibited and thus all
GPL licensed software is, in-fact, with "and later" clause?

I guess it's a more of debian-legal@ question rather than debian-***@.
--
Regards,

Dimitri.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@mail.gmail.com
Stephen Kitt
2014-01-06 22:10:03 UTC
Permalink
Hi Dimitri,
Post by Dimitri John Ledkov
But GPL text does confuse me as a whole, no modifications nor derivate
works of the GPL license text are allowed, and the original text has
"and later" clause - is licensing without "and later" constitues
modification of the GPL license text, which is prohibited and thus all
GPL licensed software is, in-fact, with "and later" clause?
The GPL itself discusses this, in section 9 in GPL v2 and in section 14 in
GPL v3. The notice that mentions the version you apply to your code comes
after the "END OF TERMS AND CONDITIONS" line, so it's not actually part of
the license (although it is part of the license document, which is what the
"verbatim" clause applies to, in its entirety). When you apply the terms to
your code, as I understand it, you're allowed to choose whichever version of
the license you prefer, with or without the "or later" clause; you're not
modifying the license document itself so that's OK.

Regards,

Stephen
(IANAL and all that)
Florian Weimer
2013-12-29 21:00:03 UTC
Permalink
Post by Clint Adams
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.
ASL 2.0 compatibility is nice, but the GPLv3 also contains this clause
which (in my opinion) substantially weakens its copyleft effect:

| You may convey covered works to others for the sole purpose of
| having them make modifications exclusively for you, or provide you
| with facilities for running those works, provided that you comply
| with the terms of this License in conveying all material for which
| you do not control copyright. Those thus making or running the
| covered works for you must do so exclusively on your behalf, under
| your direction and control, on terms that prohibit them from making
| any copies of your copyrighted material outside their relationship
| with you.

Several ISPs claim that the GPLv2 has a similar loophole and refuse to
provide kernel sources for the router they give to you as part of the
Internet service, so it's not just nitpicking. It makes me seriously
doubt that the anti-Tivoization measures in the GPLv3 have any teeth
at all.

Some might object to Section 13, "Use with the GNU Affero General
Public License" because of the the way the AGPL is currently used to
enforce asymmetrical licensing arrangements.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@mid.deneb.enyo.de
Ian Jackson
2014-01-02 19:00:02 UTC
Permalink
Post by Florian Weimer
ASL 2.0 compatibility is nice, but the GPLv3 also contains this clause
| You may convey covered works to others for the sole purpose of
| having them make modifications exclusively for you, or provide you
| with facilities for running those works, provided that you comply
| with the terms of this License in conveying all material for which
| you do not control copyright. Those thus making or running the
| covered works for you must do so exclusively on your behalf, under
| your direction and control, on terms that prohibit them from making
| any copies of your copyrighted material outside their relationship
| with you.
Several ISPs claim that the GPLv2 has a similar loophole and refuse to
provide kernel sources for the router they give to you as part of the
Internet service, so it's not just nitpicking.
These ISPs are simply wrong. They need to be reported to
gpl-violations and sat on by SFLC.

The whole Busybox v. Verizon lawsuit was about exactly this situation.
| On December 7, 2007 SFLC filed a lawsuit against Verizon
| Communications, Inc.[12] alleging that Verizon had violated GPLv2 by
| distributing BusyBox in the Actiontec MI424WR MoCA wireless routers
| bundled with the FiOS fiber optic bandwidth service, without providing
| corresponding source code. A settlement announced on March 17, 2008
| included an agreement to comply with the GPL and an undisclosed sum
| paid to the plaintiffs.[13]
Post by Florian Weimer
It makes me seriously doubt that the anti-Tivoization measures in
the GPLv3 have any teeth at all.
The GPLv3 text you quote above clearly doesn't apply in this
situation. The ISP are not "[conveying the router firmware] for the
sole purpose of having [the customer] ... provide facilities for
running" the firmware.

Perhaps this is a question of English grammar. The only reasonable
parse of the text you quote is

You may convey covered works to others for the sole purpose
of having them
(a) make modifications exclusively for you, or
(b) provide you with facilities for running those works,
provided that [etc.]

Gramatically, "provide [something]" must be preceded (of the bits of
text available) by "you", "you may", or "having them". None of the
other fragments fit.

The least implausible alternative is:

X You may
X (a) convey covered works to others for the sole purpose
X of having them make modifications exclusively for you,
X or
X (b) provide you with facilities for running those works,
X provided that [etc.]

i.e. "You may provide you with facilities".

Ian.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@chiark.greenend.org.uk
Wouter Verhelst
2014-01-04 16:10:02 UTC
Permalink
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.
I am not a member of the church of GNU, nor do I wish to be. I respect
Richard Stallman (and his band of followers) for what he's accomplished
in jumpstarting the Free Software movement (and the Open Source movement
as an offshoot of that), but since I fundamentally do not agree with
everything the FSF proclaims, I do not trust them to *only* come up with
licenses that protect the rights that I think free software should
protect for its users. Therefore, while I don't mind contributing to a
piece of software that comes with an "or later" clause, I am not likely
to pick a license with an "or later" clause for anything I write myself.

This goes for GPLvX "or later", but also for other "or later" licenses,
where they exist.

I'm convinced that the GPLv2 is a free license, but I'm so far undecided
on the GPLv3 (mainly because I've not read the license text in much
detail myself yet since it's far too long and I just never had the time).

How is that in any way antisocial?
--
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

-- http://xkcd.com/1133/
Clint Adams
2014-01-05 15:00:01 UTC
Permalink
Post by Wouter Verhelst
This goes for GPLvX "or later", but also for other "or later" licenses,
where they exist.
I'm convinced that the GPLv2 is a free license, but I'm so far undecided
on the GPLv3 (mainly because I've not read the license text in much
detail myself yet since it's far too long and I just never had the time).
How is that in any way antisocial?
Because licensing is a social activity and you're making it all about you.

I could go waste my time making up a license that addresses only the
things I care about. It wouldn't have an attribution requirement.
It would terminate on trademark-related legal action. It would thus
be incompatible with every other copyleft license out there.

This wouldn't just be a colossal waste of time, it would be antisocial
because any code under this license would be deliberately incompatible
with anything else FOR NO GOOD REASON.

I once licensed something under GPLv2-only because I was afraid of
what v3 might bring, but that turned out to be stupid and I'm glad
someone yelled at me to fix it early on, because it was incompatible
with v3+ FOR NO GOOD REASON.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@scru.org
Thorsten Glaser
2014-01-06 12:00:02 UTC
Permalink
Post by Clint Adams
because any code under this license would be deliberately incompatible
with anything else FOR NO GOOD REASON.
Uhm, then stop advocating the GNU GPL, which is deliberately incompatible
with anything else FOR NO GOOD REASON.

bye,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@tglase.lan.tarent.de
Wouter Verhelst
2014-01-06 23:10:02 UTC
Permalink
Post by Clint Adams
Post by Wouter Verhelst
This goes for GPLvX "or later", but also for other "or later" licenses,
where they exist.
I'm convinced that the GPLv2 is a free license, but I'm so far undecided
on the GPLv3 (mainly because I've not read the license text in much
detail myself yet since it's far too long and I just never had the time).
How is that in any way antisocial?
Because licensing is a social activity and you're making it all about you.
I guess that's something we heavily disagree about, then.

Licensing is not a social activity, to me. Writing free software is
social, sure, and so I do want to share my code with whomever *I* think
deserves it.

To do that, it is necessary to choose a license which allows people to
use (and modify!) my code in ways that I think is reasonable. Since
"reasonable" also includes "making sure that it can be mingled with
other code," I have no good reason to choose a GPLvX-incompatible
license, and I will go to great lengths to avoid that, if I can.

However, having said that, the FSF has a history of making statements
that I disagree with about what is "ethical" behaviour as a developer,
and thus I cannot in good conscience trust them to come up with a
license that will not disenfranchise people whom I think do not deserve
to be disenfranchised. In that light, it would be wrong to allow the FSF
to dictate what people can (or cannot) be allowed to do with my code.
Post by Clint Adams
I could go waste my time making up a license that addresses only the
things I care about. It wouldn't have an attribution requirement.
It would terminate on trademark-related legal action. It would thus
be incompatible with every other copyleft license out there.
And that would be very silly. But then, I'm not suggesting that.

[...]
Post by Clint Adams
I once licensed something under GPLv2-only because I was afraid of
what v3 might bring, but that turned out to be stupid and I'm glad
someone yelled at me to fix it early on, because it was incompatible
with v3+ FOR NO GOOD REASON.
I concur that if you fully agree with the FSF's position, there is no
good reason to license something v2-only.

Understand that not everyone feels that way.
--
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

-- http://xkcd.com/1133/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@debian.org
Clint Byrum
2013-12-24 00:10:01 UTC
Permalink
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.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/1387841822-sup-***@clint-HP
Russ Allbery
2013-12-24 00:50:02 UTC
Permalink
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?
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Clint Byrum
2013-12-24 16:50:01 UTC
Permalink
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.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/1387853050-sup-***@clint-HP
Jonathan Nieder
2013-12-25 21:40:03 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@google.com
Alessandro Ghedini
2013-12-26 17:40:03 UTC
Permalink
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
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
Bernhard R. Link
2013-12-27 17:20:03 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@client.brlink.eu
Russ Allbery
2013-12-27 18:00:02 UTC
Permalink
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).
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Bernhard R. Link
2013-12-28 10:10:01 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@client.brlink.eu
Thomas Hochstein
2014-01-01 19:20:02 UTC
Permalink
Post by Russ Allbery
Post by Bernhard R. Link
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.
At least for the non-native speaker of English "idiosyncratic" may
rhyme very unfortunately with "idiotic"; that may be Bernhard's point.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@landroval.ancalagon.de
Russ Allbery
2014-01-01 19:40:01 UTC
Permalink
Post by Russ Allbery
Post by Bernhard R. Link
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.
At least for the non-native speaker of English "idiosyncratic" may rhyme
very unfortunately with "idiotic"; that may be Bernhard's point.
Yeah, I saw that also in Bernhard's reply. That confusion had honestly
never occurred to me before since, despite the visual similarities, the
words are completely unrelated in English. The etymologies are disjoint:
idiot comes from French and hence from Latin and dates back to the 1400s,
whereas idiosyncratic has an independent derivation from Greek root words
meaning "mixed together" and has existed independently with roughly its
current meaning since the 1600s.

Idiosyncratic and idiosyncrasy have not, historically, had a negative
connotation beyond the definition that they are peculiar to individual
organizations or institutions. Consider, for example, some of the
following citations from the OED:

1839 H. Hallam Introd. Lit. Europe III. vi. 596 The elaborate
delineations of Jonson, or the marked idiosyncracies of
Shakspeare.

1918 F. E. Pierce Currents & Eddies in Eng. Romantic Generation
i. iii. 85 The frame of the old ballad even..was a legacy of the
ardour, the life, and the idiosyncrasy of the Northmen who left
their descendants in our glens.

1949 Punch 13 May 636/2 Universities do not exist to lay on degree
courses to follow the idiosyncratic requirements of a particular
employer.

2003 E. Gregg & R. Trillo Rough Guide to Gambia 50/1 The Gambia's most
idiosyncratic Christmas tradition is its fanal processions, unique
to the Kombos.

I'm sorry for the confusion for non-native speakers. English has a bad
habit of drawing words from all sorts of different languages and thus
creating a lot of accidental similarities between words that have no
relationship to each other.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Tollef Fog Heen
2014-01-03 18:00:03 UTC
Permalink
]] Russ Allbery

Wildly off-topic, but hey. :-)
Post by Russ Allbery
Yeah, I saw that also in Bernhard's reply. That confusion had honestly
never occurred to me before since, despite the visual similarities, the
idiot comes from French and hence from Latin and dates back to the 1400s,
whereas idiosyncratic has an independent derivation from Greek root words
meaning "mixed together" and has existed independently with roughly its
current meaning since the 1600s.
Actually, idiot comes from greek too (from wikipedia):

Idiot as a word derived from the Greek ἰδιώτης, idiōtēs («person
lacking professional skill», «a private citizen», «individual»), from
ἴδιος, idios («private», «one's own»).[1] In Latin the word idiota
(«ordinary person, layman») preceded the Late Latin meaning
«uneducated or ignorant person».[2] Its modern meaning and form dates
back to Middle English around the year 1300, from the Old French
idiote («uneducated or ignorant person»). The related word idiocy
dates to 1487 and may have been analogously modeled on the words
prophet[3] and prophecy.[4][5] The word has cognates in many other
languages.

An idiot in Athenian democracy was someone who was characterized by
self-centeredness and concerned almost exclusively with private—as
opposed to public—affairs. [...]

I think they have the same root too, roughly «individual», which fits
well with the definition of idiosyncratic too.
Post by Russ Allbery
I'm sorry for the confusion for non-native speakers. English has a
bad habit of drawing words from all sorts of different languages and
thus creating a lot of accidental similarities between words that have
no relationship to each other.
I don't think you can blame English for ancient Greek being
confusing. :-)
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@rahvafeir.err.no
Thomas Goirand
2013-12-24 07:40:01 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@debian.org
Clint Byrum
2013-12-24 17:00:01 UTC
Permalink
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.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/1387902981-sup-***@clint-HP
Thomas Goirand
2013-12-28 07:40:01 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@debian.org
Bernhard R. Link
2013-12-28 10:10:01 UTC
Permalink
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@client.brlink.eu
Marco d'Itri
2013-12-29 03:50:01 UTC
Permalink
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.
--
ciao,
Marco
Thomas Goirand
2013-12-30 02:20:02 UTC
Permalink
Post by 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.
The licensing careless attitude of some upstreams is a reality in some
cases, however I am having a hard time to generalize it like this, and
be take it as a valid point for this debate. Most upstream authors who
cares about licensing, do not agree with Debian's view about GPL and
OpenSSL incompatibility, and this is what counts.
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.
You are writing this just as if we're going to have a trial because of
the issue we're discussing. This will *NOT* happen.
Post by Bernhard R. Link
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.
Exactly what software will be "no longer available" if we decide to
revert our (IMO wrong) interpretation about the OpenSSL & GPL license?
This makes no sense to me.

Cheers,

Thomas
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@debian.org
Jonathan Nieder
2013-12-30 17:50:03 UTC
Permalink
Post by Thomas Goirand
Most upstream authors who
cares about licensing, do not agree with Debian's view about GPL and
OpenSSL incompatibility, and this is what counts.
Is that true? When does it even come up? What do this majority of
upstream authors take the meaning and purpose of the phrase

unless that component itself accompanies the executable.

in the GPLv2 to be?

Puzzled,
Jonathan
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@google.com
Russ Allbery
2013-12-30 19:00:01 UTC
Permalink
Post by Jonathan Nieder
Is that true? When does it even come up? What do this majority of
upstream authors take the meaning and purpose of the phrase
unless that component itself accompanies the executable.
in the GPLv2 to be?
Most upstream authors that I've spoken with don't believe that licensing
crosses the shared library ABI boundary, that the shared OpenSSL library
and the GPLv2 program that calls it remain separate works, and therefore
there is no need for OpenSSL to meet the GPLv2 requirements since the
binary as distributed is not a derivative work of both projects. Instead,
the projects are combined at runtime by the end user, who doesn't have to
meet any redistributability requirements of either license.

The FSF is a notable exception to this.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Vincent Lefevre
2013-12-30 21:30:02 UTC
Permalink
Post by Russ Allbery
Most upstream authors that I've spoken with don't believe that licensing
crosses the shared library ABI boundary, that the shared OpenSSL library
and the GPLv2 program that calls it remain separate works, and therefore
there is no need for OpenSSL to meet the GPLv2 requirements since the
binary as distributed is not a derivative work of both projects. Instead,
the projects are combined at runtime by the end user, who doesn't have to
meet any redistributability requirements of either license.
I suppose that this is allowed only if when compiling the GPLv2
program against OpenSSL, inline functions from OpenSSL (if there
are ones) are not included in the GPLv2 program.
--
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)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@xvii.vinc17.org
Russ Allbery
2013-12-30 22:00:02 UTC
Permalink
Post by Vincent Lefevre
Post by Russ Allbery
Most upstream authors that I've spoken with don't believe that
licensing crosses the shared library ABI boundary, that the shared
OpenSSL library and the GPLv2 program that calls it remain separate
works, and therefore there is no need for OpenSSL to meet the GPLv2
requirements since the binary as distributed is not a derivative work
of both projects. Instead, the projects are combined at runtime by the
end user, who doesn't have to meet any redistributability requirements
of either license.
I suppose that this is allowed only if when compiling the GPLv2
program against OpenSSL, inline functions from OpenSSL (if there
are ones) are not included in the GPLv2 program.
Or if those inline functions are not copyrightable, which may be the case
for some trivial pieces of code. Yes.

I'm therefore a lot more dubious of this argument for C++ libraries, since
with C++ it's common for substantial chunks of library code to end up
inlined in the binary that includes its headers.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Ansgar Burchardt
2013-12-30 21:30:02 UTC
Permalink
Hi,
Post by Russ Allbery
Most upstream authors that I've spoken with don't believe that licensing
crosses the shared library ABI boundary, that the shared OpenSSL library
and the GPLv2 program that calls it remain separate works, and therefore
there is no need for OpenSSL to meet the GPLv2 requirements since the
binary as distributed is not a derivative work of both projects. Instead,
the projects are combined at runtime by the end user, who doesn't have to
meet any redistributability requirements of either license.
The FSF is a notable exception to this.
One can create a shim library implementing the interface that does
nothing and also provide headers stripped of comments (including
parameter names). Then one can use that shim headers and library to
create a program that uses the given interface.

However none of the copyrightable parts of the library in question were
used during this process, unless the interface was copyrightable. Does
the FSF believe this?

This is basically the other direction of what Wine or Samba do (they
reimplement the library given the interface).

Ansgar
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@eisei.43-1.org
Russ Allbery
2013-12-30 22:10:02 UTC
Permalink
Post by Ansgar Burchardt
Post by Russ Allbery
Most upstream authors that I've spoken with don't believe that
licensing crosses the shared library ABI boundary, that the shared
OpenSSL library and the GPLv2 program that calls it remain separate
works, and therefore there is no need for OpenSSL to meet the GPLv2
requirements since the binary as distributed is not a derivative work
of both projects. Instead, the projects are combined at runtime by the
end user, who doesn't have to meet any redistributability requirements
of either license.
The FSF is a notable exception to this.
One can create a shim library implementing the interface that does
nothing and also provide headers stripped of comments (including
parameter names). Then one can use that shim headers and library to
create a program that uses the given interface.
However none of the copyrightable parts of the library in question were
used during this process, unless the interface was copyrightable. Does
the FSF believe this?
This is one of the places where you have to be careful about the
difference between software and law. Introducing a shim layer solely to
obscure the linkage between the binary and the shared library is unlikely
to change the matter from a legal perspective; in fact, you could possibly
end up in a worse legal position if the judge decided you were doing this
in an intentional effort to deceive.

What does matter is if there are multiple, unrelated functional
implementations of the same interface. In that case (such as with
readline, whose interface has been independently reimplemented in
BSD-licensed code), even the FSF has conceded the point that the license
will not cross that sort of API boundary. But you have to actually have
another functional, independent, clean-room implementation to make use of
that legal argument.

Otherwise, you still have to argue the hotly disputed point of whether
writing a program to an API that's unique to one software project makes
your program a derivative work of that project.
Post by Ansgar Burchardt
This is basically the other direction of what Wine or Samba do (they
reimplement the library given the interface).
Except they do a full clean-room reimplementation of the interface, so
this is more akin to the readline situation.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Steve Langasek
2013-12-30 22:20:02 UTC
Permalink
Post by Ansgar Burchardt
Post by Russ Allbery
Most upstream authors that I've spoken with don't believe that licensing
crosses the shared library ABI boundary, that the shared OpenSSL library
and the GPLv2 program that calls it remain separate works, and therefore
there is no need for OpenSSL to meet the GPLv2 requirements since the
binary as distributed is not a derivative work of both projects. Instead,
the projects are combined at runtime by the end user, who doesn't have to
meet any redistributability requirements of either license.
The FSF is a notable exception to this.
One can create a shim library implementing the interface that does
nothing and also provide headers stripped of comments (including
parameter names). Then one can use that shim headers and library to
create a program that uses the given interface.
However none of the copyrightable parts of the library in question were
used during this process, unless the interface was copyrightable. Does
the FSF believe this?
No, what the FSF believes is that you should comply with the terms of the
license they've written, which states that you can only distribute a GPL
binary together with the libraries it uses if those libraries are
distributed under the same license terms, *because they say so*.

The GPL requirement about dependency licensing does not rely on the legal
definition of derivative works. So arguments that a GPL program that links
against OpenSSL is not a derivative work of OpenSSL are missing the point.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Russ Allbery
2013-12-30 22:50:01 UTC
Permalink
Post by Steve Langasek
The GPL requirement about dependency licensing does not rely on the
legal definition of derivative works. So arguments that a GPL program
that links against OpenSSL is not a derivative work of OpenSSL are
missing the point.
I don't believe this is true of the GPLv2. The restrictions on
distribution of GPL'd code apply to the Program or to a work based on the
Program, which are defined in clause 0 of the GPLv2 as follows:

The "Program", below, refers to any such program or work, and a "work
based on the Program" means either the Program or any derivative work
under copyright law: that is to say, a work containing the Program or
a portion of it, either verbatim or with modifications and/or
translated into another language.

The GPLv2 explicitly defers to copyright law's definition of derivative
work. The subsequent statement about source code in section 3:

For an executable work, complete source code means all the source code
for all modules it contains, plus any associated interface definition
files, plus the scripts used to control compilation and installation
of the executable.

does not add shared libraries to that restriction (programs linked to
shared libraries do not "contain" those shared libraries in any defensible
technical sense).

Now, the GPLv3 does try to broaden the scope of the source code
requirement to include shared libraries:

The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.

and this is where the point about multiple implementations of an API
clearly comes into play ("that the work is specifically designed to
require").
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@windlord.stanford.edu
Andreas Metzler
2014-01-04 18:40:01 UTC
Permalink
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.
Hello,

how do I continue from here?

#1 Do we have some process for talking to the Software Freedom Law
Center, or would I just send them a mail (perhaps after running a
draft through debian-legal).

#2 Is there any point in doing so? Other Mails in the thread show that
there is a non-negligible number of Debian developers who disagrees with
using the system library exception for GMP or OpenSSL.

cu Andreas
--
https://wiki.debian.org/gnutls3
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/0j0mpa-***@argenau.downhill.at.eu.org
Игорь Пашев
2014-01-11 17:40:02 UTC
Permalink
Do I understand correctly the following:

Application M under the MIT license linked to LGPL3 library L - ok
Application C under the CDDL license linked to LGPL3 library L - ok
Application G under the GPL3 license linked to LGPL3 library L - ok,
all under GPL3

Bang!

Application M is now under the GPL3 ?
Application C is now illegally linked to L ?


:-)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/CALL-Q8ztfuhcVUxmkqg7qWVBdVLfs-dcMeK=***@mail.gmail.com
Svante Signell
2014-01-11 18:00:02 UTC
Permalink
Post by Игорь Пашев
Application M under the MIT license linked to LGPL3 library L - ok
Application C under the CDDL license linked to LGPL3 library L - ok
Application G under the GPL3 license linked to LGPL3 library L - ok,
all under GPL3
Bang!
Application M is now under the GPL3 ?
Not a chance, application M stays under the MIT license.
Post by Игорь Пашев
Application C is now illegally linked to L ?
:-)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@PackardBell-PC
Shawn Wilson
2013-12-23 01:20:01 UTC
Permalink
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
2013-12-23 23:10:02 UTC
Permalink
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'
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@latte.josefsson.org
Carlos Alberto Lopez Perez
2013-12-24 11:10:01 UTC
Permalink
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
2013-12-24 19:30:01 UTC
Permalink
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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Andreas Metzler
2013-12-23 08:00:02 UTC
Permalink
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
--
`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'
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@downhill.g.la
Florian Weimer
2013-12-29 21:10:02 UTC
Permalink
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).
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.
libgcc also has this problem. These days, it's GPLv3 or later plus
exceptions. Theoretically, we could try to use compiler-rt from LLVM
instead to cover it, but I'm sure something else will pop up next.

It seems to me that declaring GNUTLS, GMP, libgcc, OpenSSL etc. system
libraries is the only reasonable way forward.

(FWIW, Microsoft distributes a propriatary BSD-derived libc and GCC in
the same download, so it's not just Red Hat that has a wide
interpretation of the system library exception.)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@mid.deneb.enyo.de
Didier 'OdyX' Raboud
2014-01-11 17:00:02 UTC
Permalink
Hi all,

this "GnuTLS in Debian" thread triggered my switch of the src:cups
package from linking against GnuTLS to now link against OpenSSL. CUPS is
GPL-2 only with an OpenSSL exception.

Today, Andreas rightly pointed to me that this induces a problem (for
Debian) for all GPL-without-OpenSSL-exception programs linked against
libcups2. As far as I understand our current stance on that problem,
GPL-licensed programs without an OpenSSL exception are absolutely
forbidden to link with it, even indirectly.

Now, for the actual situation: I initially switched cups following my
option 0) aka:

0) "move away from GnuTLS as its newer versions are incompatible with
GPL-2, use OpenSSL as cups is allowed to be linked against it"


 but I had overlooked the indirect linking problem.

Now, as far as I understood the thread, there are suggestions floating
around to stop caring about this incompatibility and just consider "as a
project" that OpenSSL is a system library, but this decision hasn't been
formally taken yet.

So as far as CUPS is concerned, I see three ways forward:

1) revert the switch to OpenSSL and link against GnuTLS 2. This
basically postpones the question to the moment when GnuTLS 2 is
removed from Debian. As I understood the thread, GnuTLS 2 is likely
to be removed from testing before the freeze, right?

2) switch to GnuTLS 3. This is not allowed because GnuTLS 3 is GPL-3 and
CUPS is GPL-2 only.

3) report RC bugs against all packages linking against libcups2
which licenses don't allow indirect linking to OpenSSL (mostly GPL-
-without-OpenSSL-exception) and hope that fixes can be found license-
-wise. There are >= 38 packages build-depending on libcups2-dev and
= 120 packages depending on libcups2. Also, I am not aware of tools
to detect this incompatibility automatically. I also doubt we'll be
able to find solutions for all packages; yet libcups2 is quite
important in desktop stacks.

So there is apparently no good solution on the long-term if the need for
OpenSSL exceptions isn't waived. For now, I'm leaning towards solution
1) to avoid willingly introducing dozens of RC bugs in testing when
libcups2 enters testing (unless I create a "maintainer RC bug" blocked
by all the 3)-created bugs).

I would really welcome opinions and advices on this matter.

Many thanks in advance, cheers,

OdyX
Ben Hutchings
2014-01-11 17:30:03 UTC
Permalink
Post by Didier 'OdyX' Raboud
Hi all,
this "GnuTLS in Debian" thread triggered my switch of the src:cups
package from linking against GnuTLS to now link against OpenSSL. CUPS is
GPL-2 only with an OpenSSL exception.
Today, Andreas rightly pointed to me that this induces a problem (for
Debian) for all GPL-without-OpenSSL-exception programs linked against
libcups2. As far as I understand our current stance on that problem,
GPL-licensed programs without an OpenSSL exception are absolutely
forbidden to link with it, even indirectly.
[...]

I think this is an absurd interpretation. It is certainly not being
applied to linux-tools, where we have perf linked against libpython
linked against OpenSSL.

Ben.
--
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.
Svante Signell
2014-01-11 17:50:02 UTC
Permalink
Post by Didier 'OdyX' Raboud
Hi all,
this "GnuTLS in Debian" thread triggered my switch of the src:cups
package from linking against GnuTLS to now link against OpenSSL. CUPS is
GPL-2 only with an OpenSSL exception.
Now, as far as I understood the thread, there are suggestions floating
around to stop caring about this incompatibility and just consider "as a
project" that OpenSSL is a system library, but this decision hasn't been
formally taken yet.
1) revert the switch to OpenSSL and link against GnuTLS 2. This
basically postpones the question to the moment when GnuTLS 2 is
removed from Debian. As I understood the thread, GnuTLS 2 is likely
to be removed from testing before the freeze, right?
2) switch to GnuTLS 3. This is not allowed because GnuTLS 3 is GPL-3 and
CUPS is GPL-2 only.
What are the chances of cups re-licensing (dual-licensing) to GPL2+?
This would be a step in the right direction. (in worst case use some
other software package than cups as default for printing)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@PackardBell-PC
Loading...