libreadline

[Brian May]

Hello,

It has come to my attention that a number of packages may be breaching
the GPL by linking with libreadline instead of libeditline.

For instance, I asked on debian-legal, and was told that no program may
link both with libreadline and openssl because the licenses of these two
packages are incompatible (if you disagree, please bring it up on
debian-legal, not here).

However, a number of programs do exactly this. Probably the most popular
package is python2.1.

It is not very simple to change to use libeditline though, as many
programs have probably been hardcoded to look for libreadline, not
libeditline.

I propose a package (or maybe do it to libeditline-dev) that contains
the following symlink and conflicts with libreadline4-dev:

ln -sf libeditline.so.0.0.0 /usr/lib/libreadline.so

This means packages can build depend on this new package, and will
automatically link to use libeditline instead of libreadline.

Comments?

[Thomas Bushnell, BSG]

Post by Brian May
This means packages can build depend on this new package, and will
automatically link to use libeditline instead of libreadline.
Comments?

Horrible idea. I want to have libreadline on my system *and*
libeditline, *and* use all the available applications. The conflict
you suggest would destroy this.

The thing to do is to actually fix the packages in question to link
against libeditline itself.

[Brian May]

Post by Thomas Bushnell, BSG

Post by Brian May
This means packages can build depend on this new package, and will
automatically link to use libeditline instead of libreadline.

Horrible idea. I want to have libreadline on my system *and*
libeditline, *and* use all the available applications. The conflict
you suggest would destroy this.

In that case, why not create another package?

Post by Thomas Bushnell, BSG
The thing to do is to actually fix the packages in question to link
against libeditline itself.

(remembering that the goal of the Debian maintainer should not be to
rewrite configure scripts which may never get integrated upstream).

[Thomas Bushnell, BSG]

Post by Brian May

Post by Thomas Bushnell, BSG
Horrible idea. I want to have libreadline on my system *and*
libeditline, *and* use all the available applications. The conflict
you suggest would destroy this.

In that case, why not create another package?

Huh? How would creating another package help? Maybe I'm
misunderstanding something.

Post by Brian May

Post by Thomas Bushnell, BSG
The thing to do is to actually fix the packages in question to link
against libeditline itself.

(remembering that the goal of the Debian maintainer should not be to
rewrite configure scripts which may never get integrated upstream).

The Debian maintainer cannot simultaneously meet *all* goals in cases
like this. The question is, which is the best one to let slide. It
seems to me that having the maintainer make a trivial one-line change
to the source is much better than any of the other alternatives.

Thomas

[Thomas Bushnell, BSG]

Post by Thomas Bushnell, BSG
The Debian maintainer cannot simultaneously meet *all* goals in cases
like this. The question is, which is the best one to let slide. It
seems to me that having the maintainer make a trivial one-line change
to the source is much better than any of the other alternatives.

Actually, the *best* thing is for someone to make an openssl
alternative that doesn't conflict with the GPL, in my opinion.

Thomas

[Thomas Bushnell, BSG]

Also, a point of information for those of us who don't know all the
details. The GPL-incompatibility in the Open SSL package is purely
that it contains a variant on the old noxious BSD advertising clause.
Has anyone asked the OpenSSL project if they would consider removing
the clause? (Or replacing it with a request?)

Thomas

[Anthony Towns]

Post by Thomas Bushnell, BSG
Also, a point of information for those of us who don't know all the
details. The GPL-incompatibility in the Open SSL package is purely
that it contains a variant on the old noxious BSD advertising clause.
Has anyone asked the OpenSSL project if they would consider removing
the clause? (Or replacing it with a request?)

It's the original authors' (Eric Young and Tim Hudson) license that's
difficult to get changed.

I contacted Richard Stallman about this a year ago to get a gist on the

Post by Thomas Bushnell, BSG

Am I correct in thinking that the advertising clauses are the only cause of
* The licence and distribution terms for any publically available version or
* derivative of this code cannot be changed. i.e. this code cannot simply be
* copied and put under another distribution licence
* [including the GNU Public Licence.]

That IS a problem. It prohibits including this code in a GPL-covered
program, and therefore is incompatible with the GPL.
That license comes from EAY. I tried asking him to change it,
but he said no. I think there was a misunderstanding about what
I was requesting, but he didn't want to listen to the explanation.

(>> == me, > == rms)

Getting the license changed seems pretty unlikely. There's "gnutls"
which is an SSL library that's being developed under the GPL, which GPL
programs can link to. Unfortunately non-GPL programs can't link to it,
so we've pretty much blocked ourselves off from being able to have a
single SSL/crypto library that all free software can use, which is a
shame. Unless someone starts up a third project, of course.

Especially amusing is that the effect of the snippet above seems to be
to effectively copyleft OpenSSL anyway...

BTW, this is just noted for reference, not for debate. It's unlikely that
GPLed programs that link against OpenSSL will be let into main if the FSF
still have reason to think it's not legit. If you can get Eben Moglen to
say it's okay, OTOH, I'm sure everyone'll be convinced.

Cheers,
aj

[Jeroen Dekkers]

Post by Anthony Towns
Getting the license changed seems pretty unlikely. There's "gnutls"
which is an SSL library that's being developed under the GPL, which GPL
programs can link to. Unfortunately non-GPL programs can't link to it,
so we've pretty much blocked ourselves off from being able to have a
single SSL/crypto library that all free software can use, which is a
shame. Unless someone starts up a third project, of course.

Non-GPL programs can link with a GPL library, as long at the license
is GPL compatible. I don't know how many GPL incompatible programs use
SSL (a license field in the package description would be nice to find
out :-).

Looking at the homepage of GnuTLS it implements TLS 1.0, SSL 3.0
and a lot of other things. It looks like GnuTLS could replace
OpenSSL. If there are a lot programs with GPL incompatible license, we
could ask to license GnuTLS under the LGPL. Starting a third project
just because of a license is stupid IMHO.

Jeroen Dekkers

[Britton]

Post by Anthony Towns
Getting the license changed seems pretty unlikely. There's "gnutls"
which is an SSL library that's being developed under the GPL, which GPL
programs can link to. Unfortunately non-GPL programs can't link to it,

Has anybody asked them to relicense under LGPL?

Britton

[Gregor Hoffleit]

Post by Britton

Post by Anthony Towns
Getting the license changed seems pretty unlikely. There's "gnutls"
which is an SSL library that's being developed under the GPL, which GPL
programs can link to. Unfortunately non-GPL programs can't link to it,

Has anybody asked them to relicense under LGPL?

According to Werner Koch <***@gnupg.org>, this is no option:
(http://lists.gnupg.org/pipermail/gnutls-dev/2001-May/000120.html)

Post by Britton
No, we won't change libgcrypt to LGPL.
I know that the reasoning behind LGPLing the basic GNOME libraries.
However if someone want's to get the benefit of encryption under
GNOME he should play fair and GPL his software too. There are ways
to work around this but I won't give hints on how to do this.
Changing everything too LGPL would just help to boost proprietary
software; given that GNOME is part of GNU I don't think that this is
a good idea.

Gregor

[Brian May]

Post by Thomas Bushnell, BSG
Also, a point of information for those of us who don't know all the
details. The GPL-incompatibility in the Open SSL package is purely
that it contains a variant on the old noxious BSD advertising clause.
Has anyone asked the OpenSSL project if they would consider removing
the clause? (Or replacing it with a request?)

See
<URL:http://lists.debian.org/debian-legal/2002/debian-legal-200204/msg00072.html>
for the start of the thread that I created on debian-legal.

I was told that openssl cannot change the license, Eric Young is the
copyright holder. I do not know if anyone has approached Eric (I would
be surprised if nobody has) or not, but somebody thought it would be
unlikely that he would want to change it.

[Brian May]

Post by Thomas Bushnell, BSG

Post by Thomas Bushnell, BSG
The Debian maintainer cannot simultaneously meet *all* goals in cases
like this. The question is, which is the best one to let slide. It
seems to me that having the maintainer make a trivial one-line change
to the source is much better than any of the other alternatives.

Actually, the *best* thing is for someone to make an openssl
alternative that doesn't conflict with the GPL, in my opinion.

I believe FSF are already doing this.

For instance, see libgcrypt1 and gnutls3.

However openssl started first, so it obviously has the advantage of
being more mature and with more features.

(I am not really familiar myself with the limitations in the GPL code;
however, when I tried it with mutt, it didn't seem to recognize the
remote host certificate was signed by a recognized CA certificate,
unless I recompiled it with openssl).

[Joseph Carter]

Post by Thomas Bushnell, BSG

Post by Thomas Bushnell, BSG
The Debian maintainer cannot simultaneously meet *all* goals in cases
like this. The question is, which is the best one to let slide. It
seems to me that having the maintainer make a trivial one-line change
to the source is much better than any of the other alternatives.

Actually, the *best* thing is for someone to make an openssl
alternative that doesn't conflict with the GPL, in my opinion.

Well, we've got mozilla's SSL implementation under a reasonable enough
license IIRC. But most things don't support using that yet.

[Brian May]

Post by Joseph Carter
Well, we've got mozilla's SSL implementation under a reasonable enough
license IIRC. But most things don't support using that yet.

What is the license of libnss3? /usr/doc/libnss3/copyright says it could
be either NPL, MPL, or GPL.

GNU do not consider the NPL or MPL as compatable with the GPL, for
details see <URL:http://www.mozilla.org/NPL/NPL-1.0.html> and
<URL:http://www.mozilla.org/MPL/MPL-1.1.html>.

[Joseph Carter]

Post by Brian May

Post by Joseph Carter
Well, we've got mozilla's SSL implementation under a reasonable enough
license IIRC. But most things don't support using that yet.

What is the license of libnss3? /usr/doc/libnss3/copyright says it could
be either NPL, MPL, or GPL.
GNU do not consider the NPL or MPL as compatable with the GPL, for
details see <URL:http://www.mozilla.org/NPL/NPL-1.0.html> and
<URL:http://www.mozilla.org/MPL/MPL-1.1.html>.

IIRC, it is now available under all three. The FSF does not consider the
Artistic license of perl to be GPL-compatible either, but perl is licensed
under both that and the GPL, so they're happy enough with it.

The Clarified Artistic license should be perfectly compatible with the
GPL, as far as I know.

[Andrew McDonald]

Post by Brian May

Post by Joseph Carter
Well, we've got mozilla's SSL implementation under a reasonable enough
license IIRC. But most things don't support using that yet.

What is the license of libnss3? /usr/doc/libnss3/copyright says it could
be either NPL, MPL, or GPL.

The license in the CVS versions of libgcrypt and libgnutls have
recently (in the last couple of days) changed to LGPL (from GPL).
(Though for libgnutls this doesn't apply to all of the code. If built
with SRP or OpenPGP support then it is still GPL).

[Brian May]

Post by Thomas Bushnell, BSG
Huh? How would creating another package help? Maybe I'm
misunderstanding something.

Create a package, say libeditline-convert that contains the symlink and
conflicts with libreadline-dev.

That way you can install both libeditline-dev and libreadline-dev at the
same time if you want, but packages can still build-depend
libeditline-convert.

Sure, it is a hack, thats why I asked here first ;-)

Post by Thomas Bushnell, BSG
The Debian maintainer cannot simultaneously meet *all* goals in cases
like this. The question is, which is the best one to let slide. It
seems to me that having the maintainer make a trivial one-line change
to the source is much better than any of the other alternatives.

Unfortunately it isn't always as simple as making a one line change. You
have to understand the way the configure script works, how it calls
these macros, try to get autoconf generate a new configure script (it
doesn't always work on upstream code).

This is fine. As a maintainer of a complicated package, I am prepared to
do this.

This big problem is when the new version of the upstream package is
released, and certain changes mean that the old patch will no longer
apply without redoing it all over again...

(just very small upstream changes can mess things up too).

Of course, in a perfect world, the Debian maintainer would just send the
patch upstream, and it would get integrated before the next release, but
in practice things aren't always this easy.

[Jeroen Dekkers]

Post by Brian May

Post by Thomas Bushnell, BSG
Huh? How would creating another package help? Maybe I'm
misunderstanding something.

Create a package, say libeditline-convert that contains the symlink and
conflicts with libreadline-dev.
That way you can install both libeditline-dev and libreadline-dev at the
same time if you want, but packages can still build-depend
libeditline-convert.
Sure, it is a hack, thats why I asked here first ;-)

It's a damn ugly hack and I doubt it will work perfectly. We should have
a much better solution for this problem.

Post by Brian May

Post by Thomas Bushnell, BSG
The Debian maintainer cannot simultaneously meet *all* goals in cases
like this. The question is, which is the best one to let slide. It
seems to me that having the maintainer make a trivial one-line change
to the source is much better than any of the other alternatives.

Unfortunately it isn't always as simple as making a one line change. You
have to understand the way the configure script works, how it calls
these macros, try to get autoconf generate a new configure script (it
doesn't always work on upstream code).

Isn't it just replacing "readline" with "editline"? If it isn't, your
ugly hack probably won't work either.

Post by Brian May
This is fine. As a maintainer of a complicated package, I am prepared to
do this.

Any maintainer should be prepared to fix his package, else he should
orphan it.

Post by Brian May
This big problem is when the new version of the upstream package is
released, and certain changes mean that the old patch will no longer
apply without redoing it all over again...
(just very small upstream changes can mess things up too).
Of course, in a perfect world, the Debian maintainer would just send the
patch upstream, and it would get integrated before the next release, but
in practice things aren't always this easy.

It's a licence violation, you could even force them to change it, but
I don't think that will be necessary. We should fix all the packages
instead of trying to provide ugly workarounds.

Jeroen Dekkers

[Brian May]

Post by Jeroen Dekkers
It's a damn ugly hack and I doubt it will work perfectly. We should have
a much better solution for this problem.

I am not disputing the first sentence, however, I have tested creating
the symlink and it works perfectly.

I linked ftp in Heimdal with -lreadline, and a ldd on the binary
says it is now using editline.

Post by Jeroen Dekkers
Isn't it just replacing "readline" with "editline"? If it isn't, your
ugly hack probably won't work either.

You have to change the configure script tests to test for the existance
of libeditline.so instead if libreadline.so.

(come to thing of it, header files in one problem I haven't considered,
it might be harder to solve then the shared library; in fact
libeditline-dev doesn't have a header file, is this a bug? Although my
package doesn't seem to use readline.h anyway, except for in the
configure test).

Also, if you just replace libeditline with libreadline, it is unlikely
that upstream will incorporate it, so you have to test for both
libeditline and libreadline, and use the first one available.

You have to incorporate this in my already large patch (142 lines
according to wc --lines), and update it whenever a new version comes
out.

[Jeroen Dekkers]

Post by Brian May

Post by Jeroen Dekkers
It's a damn ugly hack and I doubt it will work perfectly. We should have
a much better solution for this problem.

I am not disputing the first sentence, however, I have tested creating
the symlink and it works perfectly.
I linked ftp in Heimdal with -lreadline, and a ldd on the binary
says it is now using editline.

Then it is probably partly ABI-compatible which I wasn't sure
about. Reading the description it says it provides not all the
features, so it isn't totally ABI compatible? That could give some
nasty bugs...

Post by Brian May

Post by Jeroen Dekkers
Isn't it just replacing "readline" with "editline"? If it isn't, your
ugly hack probably won't work either.

You have to change the configure script tests to test for the existance
of libeditline.so instead if libreadline.so.

I think that isn't so difficult...

Post by Brian May
(come to thing of it, header files in one problem I haven't considered,
it might be harder to solve then the shared library; in fact
libeditline-dev doesn't have a header file, is this a bug? Although my
package doesn't seem to use readline.h anyway, except for in the
configure test).

I guess it is, as it needs a header file for the function prototypes
and other stuff. The editline header file should provide the same as
the readline header file.

Post by Brian May
Also, if you just replace libeditline with libreadline, it is unlikely
that upstream will incorporate it, so you have to test for both
libeditline and libreadline, and use the first one available.

Then there will still be a license volitation.

Post by Brian May
You have to incorporate this in my already large patch (142 lines
according to wc --lines), and update it whenever a new version comes
out.

Your assumpation is wrong. You assume upstream won't include it, you
should assume it does.

Am I right that you actually want to have libeditline provide
libreadline, but a simple Provide: won't work here because versioned
provides don't work?

Jeroen Dekkers

[Brian May]

Post by Jeroen Dekkers
Am I right that you actually want to have libeditline provide
libreadline, but a simple Provide: won't work here because versioned
provides don't work?

Hmmmm... Interesting point.

If libeditline conflicts, provides libreadline, and has
/usr/lib/libreadline.so*, then it would be 100% ABI compatible, and
programs would be able to use either. (you could argue that it isn't
currently 100% ABI compatible due to the different name).

Just some issues you might encounter though:
* package depends (For non-GPL packages) need to prefer
libeditline over libreadline (my understanding only).
* version provides won't help; the version numbers are
completely different.
* All programs would have to use libeditline if installed, even
those that are capable of using libreadline. This might be
good for some people, not so good for others.

[Jeroen Dekkers]

Post by Brian May

Post by Jeroen Dekkers
Am I right that you actually want to have libeditline provide
libreadline, but a simple Provide: won't work here because versioned
provides don't work?

Hmmmm... Interesting point.
If libeditline conflicts, provides libreadline, and has
/usr/lib/libreadline.so*, then it would be 100% ABI compatible, and
programs would be able to use either. (you could argue that it isn't
currently 100% ABI compatible due to the different name).

Names doesn't have much to do with the ABI, it's a way to find the
library, the dynamic linker won't find it if it has some random name.

Post by Brian May
* package depends (For non-GPL packages) need to prefer
libeditline over libreadline (my understanding only).

That's true, but the user could choose to use libreadline instead of
libeditline.

Post by Brian May
* version provides won't help; the version numbers are
completely different.

No, because if versioned provide would work, you could say:
Provide: libreadline4 (== <version it is compatible with>)

Post by Brian May
* All programs would have to use libeditline if installed, even
those that are capable of using libreadline. This might be
good for some people, not so good for others.

The user could choose to use libreadline instead of libeditline if it
wants to without violating the GPL. If needed, maybe we could do some
dynamic linking magic to have both libraries exist at the same time.

This actually started me thinking about what
http://master.debian.org/~brinkmd/arch-handling.txt says, especially
the last example about glibc ABI. I think the way libraries are
handled in Debian can be done better, it should be more focused on the
actual ABI of the library than the version number of the package the
library is in. In this case, you would probably want the following:

libreadline4 package:
Provide: libreadline.so.4

libeditline0 package:
Provide: libreadline.so.4

Random package using readline:
Depend: libreadline.so.4

It gets tricky when new functions get added, this doesn't break the ABI
but will break the compatibility between the libraries. I think this
is best solved by depending on libreadline.so.4.2 if the new function
is added in version 4.2. The best thing would be if all libraries use
versioned symbols, but AFAIK only glibc does that at the moment. I'm
probably overlooking much more problems here, but I think the idea is
at least nice.

Jeroen Dekkers

[Thomas Bushnell, BSG]

Post by Brian May
If libeditline conflicts, provides libreadline, and has
/usr/lib/libreadline.so*, then it would be 100% ABI compatible, and
programs would be able to use either. (you could argue that it isn't
currently 100% ABI compatible due to the different name).

This is not acceptible, because I want the ability to have *both*
libraries.

[Brian May]

Post by Thomas Bushnell, BSG

Post by Brian May
If libeditline conflicts, provides libreadline, and has
/usr/lib/libreadline.so*, then it would be 100% ABI compatible, and
programs would be able to use either. (you could argue that it isn't
currently 100% ABI compatible due to the different name).

This is not acceptible, because I want the ability to have *both*
libraries.

Just curious: Why?

If you have libreadline installed, why would you want libeditline
installed to?

(remembering of course you can install libreadline in place of
libeditline on your own systems).

Of course, throughout this discussion I am assuming that libeditline is
fully ABI compatible, something I haven't investigated myself. I would
be surprised if it is not the case.

Also, I seem the package description of libeditline says that it has
fewer features. Any ideas what features it lacks?

[Thomas Bushnell, BSG]

Post by Brian May
Just curious: Why?

Suppose the proposal is enacted. If it is, then I essentially *can't*
have libreadline on my system unless I refuse to have ssl-using
applications. (Given that having -dev libraries is important to me.)

Post by Brian May
If you have libreadline installed, why would you want libeditline
installed to?

Perhaps I might maintain a package that uses (because of licensing
restrictions or other problems) libeditline.

Perhaps I want to make my entire system available as a place to get
the whole system from.

[Brian May]

Post by Thomas Bushnell, BSG
Suppose the proposal is enacted. If it is, then I essentially *can't*
have libreadline on my system unless I refuse to have ssl-using
applications. (Given that having -dev libraries is important to me.)

The GPL only applies when distributing packages, you can do what you
like with your own system.

Post by Thomas Bushnell, BSG

Post by Brian May
If you have libreadline installed, why would you want libeditline
installed to?

Perhaps I might maintain a package that uses (because of licensing
restrictions or other problems) libeditline.

If the ABI is compatible, then this shouldn't be a problem.

Post by Thomas Bushnell, BSG
Perhaps I want to make my entire system available as a place to get
the whole system from.

Maybe it is a problem if you really want libreadline and also want to
distribute it.

There are 2 solutions I have seen so far:

1. link programs with libreadline instead of libeditline.
* pros: can install both at same time
* cons: cant substitute one for the other without rebuilding.
1. libreadline and libeditline both install libreadline.so.*
* pros: no source code changes.
* pros: can substitute on for the other at installation time.
* cons: can't install both at the same time.

(sorry about the broken numbering)

Maybe we can somehow merge these two solutions?

[Thomas Bushnell, BSG]

Post by Brian May

Post by Thomas Bushnell, BSG
Suppose the proposal is enacted. If it is, then I essentially *can't*
have libreadline on my system unless I refuse to have ssl-using
applications. (Given that having -dev libraries is important to me.)

The GPL only applies when distributing packages, you can do what you
like with your own system.

Except that the proposal would involve, essentially, a *conflict*
between libedit and libreadline. That certainly does affect me.

Post by Brian May

Post by Thomas Bushnell, BSG
Perhaps I might maintain a package that uses (because of licensing
restrictions or other problems) libeditline.

If the ABI is compatible, then this shouldn't be a problem.

As I pointed out, licensing issues may make it important to have both
libraries on a system. Some programs can only be linked against
libeditline, but I may prefer libreadline for non-API-related issues.
(Remember, these two libraries could have the same API and yet
importantly different user interfaces.) So I would want to use
libeditline when I must, and libreadline when I can.

Post by Brian May

Post by Thomas Bushnell, BSG
Perhaps I want to make my entire system available as a place to get
the whole system from.

Maybe it is a problem if you really want libreadline and also want to
distribute it.

Yep. That's what I mean by "make my entire system available".

Post by Brian May
1. link programs with libreadline instead of libeditline.
* pros: can install both at same time
* cons: cant substitute one for the other without rebuilding.

I think you have this backwards, right? You mean "link programs with
libeditline instead of libreadline", right?

[Jeroen Dekkers]

Post by Brian May

Post by Thomas Bushnell, BSG
Suppose the proposal is enacted. If it is, then I essentially *can't*
have libreadline on my system unless I refuse to have ssl-using
applications. (Given that having -dev libraries is important to me.)

OpenSSL isn't the only package providing SSL functionality, GnuTLS
also exists for example.

Post by Brian May

Post by Thomas Bushnell, BSG

Post by Brian May
If you have libreadline installed, why would you want libeditline
installed to?

Perhaps I might maintain a package that uses (because of licensing
restrictions or other problems) libeditline.

If the ABI is compatible, then this shouldn't be a problem.

Post by Thomas Bushnell, BSG
Perhaps I want to make my entire system available as a place to get
the whole system from.

Maybe it is a problem if you really want libreadline and also want to
distribute it.
1. link programs with libreadline instead of libeditline.
* pros: can install both at same time
* cons: cant substitute one for the other without rebuilding.
1. libreadline and libeditline both install libreadline.so.*
* pros: no source code changes.
* pros: can substitute on for the other at installation time.
* cons: can't install both at the same time.
(sorry about the broken numbering)
Maybe we can somehow merge these two solutions?

I think you can use update-alternatives to be able to install both
libraries.

Jeroen Dekkers

[Brian May]

Post by Jeroen Dekkers
I think you can use update-alternatives to be able to install both
libraries.

Is using update-alternatives for shared libraries safe?

dpkg makes sure that symlinks get unpacked first in order to minimize
breakage during upgrades (although I can't remember the reason why this
is important right now).

Will this be a problem for update-alternatives?

I am not yet convinced that update-alternatives will help in this
situation (especially since there seem to be conflicting requirements
from everybody), but it might help in other problems I have encountered.

[J.H.M. Dassen (Ray)]

Post by Brian May
dpkg makes sure that symlinks get unpacked first

No, last, or at least after their targets have been unpacked.

Post by Brian May
in order to minimize breakage during upgrades (although I can't remember
the reason why this is important right now).

Because otherwise libraries which dpkg, maintainer scripts etc. use may be
completely broken. Back in the dark ages, my system was once hosed by a
libc6 upgrade in which the libc.so.4 symlink was unpacked before its target.

Ray

[Junichi Uekawa]

On 06 May 2002 09:59:43 +1000

Post by Brian May

Post by Jeroen Dekkers
I think you can use update-alternatives to be able to install both
libraries.

Is using update-alternatives for shared libraries safe?

I don't know what is really safe in what respect, but
it really doesn't look that much compatible :


$ objdump -T /lib/libreadline.so.4 | grep Base | wc -l
493
$ objdump -T debian/libeditline0/usr/lib/libeditline.so.0 | grep Base | wc -l
24



Linking libeditline to every program as a replacement of libreadline
may cause some "Missing symbols " errors.

Very hard to detect, when filed as bugs.

regards,
junichi

[Junichi Uekawa]

Post by Brian May
If libeditline conflicts, provides libreadline, and has
/usr/lib/libreadline.so*, then it would be 100% ABI compatible, and
programs would be able to use either. (you could argue that it isn't
currently 100% ABI compatible due to the different name).

The last time I looked at libeditline, it did not look very good,
and the packaging of it was not very good either.

It is possible to divert the shared library, but I
recommend against it. I have been through this already with
slang.

"Compatible ABI" usually isn't.

Since it is a license violation in the upstream level,
I recommend asking the upstream to fix their bugs.




regards,
junichi

[Thomas Bushnell, BSG]

Post by Jeroen Dekkers
Then it is probably partly ABI-compatible which I wasn't sure
about. Reading the description it says it provides not all the
features, so it isn't totally ABI compatible? That could give some
nasty bugs...

If there is a program that links with OpenSSL and some GPL'd program,
and has to be linked with that GPL'd program to work right, then it
violates the GPL to distribute it. This was all assuming that
editline *is* a good enough replacement to make the program no longer
in violation of the GPL (provided, of course, that we don't ourselves
proceed to distribute a version that links with readline).

Post by Jeroen Dekkers
Am I right that you actually want to have libeditline provide
libreadline, but a simple Provide: won't work here because versioned
provides don't work?

I don't want that because I want the ability to have *BOTH* libraries
installed.

[Thomas Bushnell, BSG]

Post by Brian May
That way you can install both libeditline-dev and libreadline-dev at the
same time if you want, but packages can still build-depend
libeditline-convert.

And then I can't have all those packages at once. As long as there is
a conflict in the setup, then there is an artificial restriction on
what packages I can have done.

Post by Brian May
Unfortunately it isn't always as simple as making a one line change. You
have to understand the way the configure script works, how it calls
these macros, try to get autoconf generate a new configure script (it
doesn't always work on upstream code).

If it's *that* hard in some particular case, then the upstream program
is very likely violating the GPL itself...

[Junichi Uekawa]

Post by Thomas Bushnell, BSG
Horrible idea. I want to have libreadline on my system *and*
libeditline, *and* use all the available applications. The conflict
you suggest would destroy this.

That's not what will happen, if I read the proposal correctly.

regards,
junichi

[Matthias Klose]

Post by Brian May
Hello,
It has come to my attention that a number of packages may be breaching
the GPL by linking with libreadline instead of libeditline.
For instance, I asked on debian-legal, and was told that no program may
link both with libreadline and openssl because the licenses of these two
packages are incompatible (if you disagree, please bring it up on
debian-legal, not here).
However, a number of programs do exactly this. Probably the most popular
package is python2.1.

- the python binary is not linked against readline and openssl.
- the readline module is linked against libreadline
- the _socket module is linked against libssl

Is one of the following solutions legal:

- Build the standard _socket module without SSL support and add a
new (well, it was called python-ssl) package which builds the ssl
module with ssl support and diverts the package.

- Add a hack to the interpreter, so that the readline and _socket
modules cannot be loaded together.

- Replace readline with editline. Yes this solution is legal, but
I didn't check yet, if it's doable.

[Steve Langasek]

Post by Matthias Klose

Post by Brian May
Hello,
It has come to my attention that a number of packages may be breaching
the GPL by linking with libreadline instead of libeditline.
For instance, I asked on debian-legal, and was told that no program may
link both with libreadline and openssl because the licenses of these two
packages are incompatible (if you disagree, please bring it up on
debian-legal, not here).
However, a number of programs do exactly this. Probably the most popular
package is python2.1.

- the python binary is not linked against readline and openssl.
- the readline module is linked against libreadline
- the _socket module is linked against libssl
- Build the standard _socket module without SSL support and add a
new (well, it was called python-ssl) package which builds the ssl
module with ssl support and diverts the package.
- Add a hack to the interpreter, so that the readline and _socket
modules cannot be loaded together.
- Replace readline with editline. Yes this solution is legal, but
I didn't check yet, if it's doable.

I believe this is only an issue if we also ship python programs that
use both modules. It may be the case that we do; but simply having both
python modules available on the system is not a license conflict, and
end-users are even allowed to write programs using both modules; they
just can't be distributed with Debian without some resolution to the
above issue.

If we don't ship any python programs that depend on both SSL socket
support and readline support, I believe providing a non-SSL-enabled
socket module as the preferred socket module will satisfy the license
requirements. If we have programs that do need both SSL and readline,
then something needs to be changed -- either readline must be replaced
with editline, or OpenSSL must be replaced with gnutls.

Steve Langasek
postmodern programmer

[Gregor Hoffleit]

Post by Steve Langasek
I believe this is only an issue if we also ship python programs that
use both modules. It may be the case that we do; but simply having both
python modules available on the system is not a license conflict, and
end-users are even allowed to write programs using both modules; they
just can't be distributed with Debian without some resolution to the
above issue.
If we don't ship any python programs that depend on both SSL socket
support and readline support, I believe providing a non-SSL-enabled
socket module as the preferred socket module will satisfy the license
requirements. If we have programs that do need both SSL and readline,
then something needs to be changed -- either readline must be replaced
with editline, or OpenSSL must be replaced with gnutls.

Well, if you do this:

freefly:46> python2.1
Python 2.1.3 (#1, Apr 20 2002, 10:14:34)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.

Post by Steve Langasek

Post by Gregor Hoffleit
import socket

then both readline and OpenSSL are linked into the Python interpreter.

Now the question seems to be if distributing a package that allows this
is in violation of the GPL.

If you run a Python script (non-interactively), then readline is not
used.

Gregor

[Steve Langasek]

Post by Gregor Hoffleit

Post by Steve Langasek
I believe this is only an issue if we also ship python programs that
use both modules. It may be the case that we do; but simply having both
python modules available on the system is not a license conflict, and
end-users are even allowed to write programs using both modules; they
just can't be distributed with Debian without some resolution to the
above issue.
If we don't ship any python programs that depend on both SSL socket
support and readline support, I believe providing a non-SSL-enabled
socket module as the preferred socket module will satisfy the license
requirements. If we have programs that do need both SSL and readline,
then something needs to be changed -- either readline must be replaced
with editline, or OpenSSL must be replaced with gnutls.

freefly:46> python2.1
Python 2.1.3 (#1, Apr 20 2002, 10:14:34)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.

Post by Steve Langasek

Post by Gregor Hoffleit
import socket

then both readline and OpenSSL are linked into the Python interpreter.

But a user is within her rights to do that. Creating a program that
loads both of these libraries is allowed -- distributing it in Debian is
not.

Post by Gregor Hoffleit
Now the question seems to be if distributing a package that allows this
is in violation of the GPL.

Distributing a package that *does* this is in violation of the GPL; that
is, we cannot legally distribute a python script that calls both 'import
socket' and 'import readline'. But we allow users to do many things
that we ourselves cannot: a user is free to create such a script on his
local machine, and he is free to call 'import socket' from the python
IDE.

Steve Langasek
postmodern programmer

[Brian May]

Post by Steve Langasek
Distributing a package that *does* this is in violation of the GPL; that
is, we cannot legally distribute a python script that calls both 'import
socket' and 'import readline'. But we allow users to do many things
that we ourselves cannot: a user is free to create such a script on his
local machine, and he is free to call 'import socket' from the python
IDE.

That raises an interesting point. When I asked on debian-legal, the
question was phrased as "What if a program (lets say it has a new bsd
license) is linked against both libreadline and openssl. Would this be
ok?". The answer was No.

However, now I realize I meant to ask a slight different question "What
if a ***package***(lets say it has a new bsd license) is linked against
both libreadline and openssl. Would this be ok?"

I wonder if the answer is still the same?

[Thomas Bushnell, BSG]

Post by Brian May
However, now I realize I meant to ask a slight different question "What
if a ***package***(lets say it has a new bsd license) is linked against
both libreadline and openssl. Would this be ok?"
I wonder if the answer is still the same?

A package doesn't link against anything.

[Gregor Hoffleit]

Post by Brian May
It has come to my attention that a number of packages may be breaching
the GPL by linking with libreadline instead of libeditline.
For instance, I asked on debian-legal, and was told that no program may
link both with libreadline and openssl because the licenses of these two
packages are incompatible (if you disagree, please bring it up on
debian-legal, not here).
However, a number of programs do exactly this. Probably the most popular
package is python2.1.

Brian, I think this information is too vague to make a decision based on
it. I need a clear legal advice on how Debian is violating which
license by distributing the current python2.1 packages.

To be clear: I understand the problem, but I have no idea at which point
we would agree that it is resolved.


As Matthias already wrote, python2.1 is a package which contains a
Python interpreter and several extension modules. Technically, the
extension modules are shared objects (.so). Among these extension
modules is a readline module
(/usr/lib/python2.1/lib-dynload/readline.so) which is linked with
libreadline.so.4. There's another extension module in the package,
(/usr/lib/python2.1/lib-dynload/_socket.so), which is linked with
libssl.so.0.9.6.

The Python interpreter loads extension modules at runtime when it hits
an "import" command (where loading means linking the modules' code into
the interpreter).

The _socket.so module ought to be imported from the socket.py module,
which can be imported with the Python command "import socket". This is
done in many modules of Python's network code.

The readline module will be imported on startup of Python by default, if
available, but only in interactive sessions:

if ((inspect || (command == NULL && filename == NULL)) &&
isatty(fileno(stdin))) {
PyObject *v;
v = PyImport_ImportModule("readline");
if (v == NULL)
PyErr_Clear();
else
Py_DECREF(v);
}

Therefore, as long a user doesn't import the socket module in an
interactive session, it never happens that both the readline library
and the OpenSSL library are linked into the same program.

A switch to editline (if it was feasible technically) is no solution,
since it is well possible that there are/will be other Python extension
modules in Debian which link with other GPL libraries. This is a
fundamental problem.

Again, I see that there's a potential problem, but where exactly is the
borderline (I guess that means where do we want to draw a borderline ?).


A few questions:

(1) How about this: I ship two versions of _socket.so in the python2.1
package: One is linked with OpenSSL, the other doesn't include the SSL
support. Upon loading, socket.py decides whether the interpreter is
already linked with libreadline, and if that's the case, it imports the
SSL-less _socket.so. Vice-versa with the readline module: It checks
whether the interpreter is linked with the libssl, and if that's the
case, it fails to import.

This would legally and morally satisfy the GPL, right ?

(2) If we shipped python2.1 with an SSL-less _socket.so, and
alternatively distributed a python2.1-ssl package, which provides a
SSL-enabled _socket.so, would that change anything ?

(2b) If the python2.1-ssl package included a note of warning, and
perhaps a description how to optionally (!) disable the readline module,
would that be better than (2) ?

(2c) If the installation of python2.1-ssl would remove the readline
module, that should definitely satisfy the GPL, correct ?


AFAICS, the strange situation is that the user would never violate the
GPL (he is free to do with the code what he wants, as long as he doesn't
redistribute this). Only the distributor (i.e. me or Debian as a whole)
could violate the GPL. Now where's the border ? How many provisions do
we have to take to "inhibit" a user from linking GPL stuff with
incompatible stuff ?

I would be glad about some guidelines.

Gregor

[Jeroen Dekkers]

Post by Gregor Hoffleit
Therefore, as long a user doesn't import the socket module in an
interactive session, it never happens that both the readline library
and the OpenSSL library are linked into the same program.
A switch to editline (if it was feasible technically) is no solution,
since it is well possible that there are/will be other Python extension
modules in Debian which link with other GPL libraries. This is a
fundamental problem.
Again, I see that there's a potential problem, but where exactly is the
borderline (I guess that means where do we want to draw a borderline ?).
(1) How about this: I ship two versions of _socket.so in the python2.1
package: One is linked with OpenSSL, the other doesn't include the SSL
support. Upon loading, socket.py decides whether the interpreter is
already linked with libreadline, and if that's the case, it imports the
SSL-less _socket.so. Vice-versa with the readline module: It checks
whether the interpreter is linked with the libssl, and if that's the
case, it fails to import.
This would legally and morally satisfy the GPL, right ?
(2) If we shipped python2.1 with an SSL-less _socket.so, and
alternatively distributed a python2.1-ssl package, which provides a
SSL-enabled _socket.so, would that change anything ?
(2b) If the python2.1-ssl package included a note of warning, and
perhaps a description how to optionally (!) disable the readline module,
would that be better than (2) ?
(2c) If the installation of python2.1-ssl would remove the readline
module, that should definitely satisfy the GPL, correct ?

(3) Link _socket.so with GnuTLS instead of OpenSSl. I don't know how
feasible this is.

Jeroen Dekkers

[Gregor Hoffleit]

Post by Jeroen Dekkers

Post by Gregor Hoffleit
(1) How about this: I ship two versions of _socket.so in the python2.1
package: One is linked with OpenSSL, the other doesn't include the SSL
support. Upon loading, socket.py decides whether the interpreter is
already linked with libreadline, and if that's the case, it imports the
SSL-less _socket.so. Vice-versa with the readline module: It checks
whether the interpreter is linked with the libssl, and if that's the
case, it fails to import.
This would legally and morally satisfy the GPL, right ?
(2) If we shipped python2.1 with an SSL-less _socket.so, and
alternatively distributed a python2.1-ssl package, which provides a
SSL-enabled _socket.so, would that change anything ?
(2b) If the python2.1-ssl package included a note of warning, and
perhaps a description how to optionally (!) disable the readline module,
would that be better than (2) ?
(2c) If the installation of python2.1-ssl would remove the readline
module, that should definitely satisfy the GPL, correct ?

(3) Link _socket.so with GnuTLS instead of OpenSSl. I don't know how
feasible this is.
From a first look, GNU TLS has a very different API. The current code in

the socket module won't work with GNU TLS.

Furthermore, replacing OpenSSL with GNU TLS won't resolve the
fundamental dilemma. We would face the same situation for any other
package that includes a Python extension module with a GPL-incompatible,
but DFSG-free license. If this is the last word, then Debian could only
ship GPL-compatible Python modules (and the same was true for all
derived distributions). This seems to be in conflict with the Social
Contract.

Gregor

[Jeroen Dekkers]

Post by Jeroen Dekkers

Post by Jeroen Dekkers

Post by Gregor Hoffleit
(1) How about this: I ship two versions of _socket.so in the python2.1
package: One is linked with OpenSSL, the other doesn't include the SSL
support. Upon loading, socket.py decides whether the interpreter is
already linked with libreadline, and if that's the case, it imports the
SSL-less _socket.so. Vice-versa with the readline module: It checks
whether the interpreter is linked with the libssl, and if that's the
case, it fails to import.
This would legally and morally satisfy the GPL, right ?
(2) If we shipped python2.1 with an SSL-less _socket.so, and
alternatively distributed a python2.1-ssl package, which provides a
SSL-enabled _socket.so, would that change anything ?
(2b) If the python2.1-ssl package included a note of warning, and
perhaps a description how to optionally (!) disable the readline module,
would that be better than (2) ?
(2c) If the installation of python2.1-ssl would remove the readline
module, that should definitely satisfy the GPL, correct ?

(3) Link _socket.so with GnuTLS instead of OpenSSl. I don't know how
feasible this is.

From a first look, GNU TLS has a very different API. The current code in
the socket module won't work with GNU TLS.

This is indeed a problem.

Post by Jeroen Dekkers
Furthermore, replacing OpenSSL with GNU TLS won't resolve the
fundamental dilemma. We would face the same situation for any other
package that includes a Python extension module with a GPL-incompatible,
but DFSG-free license. If this is the last word, then Debian could only
ship GPL-compatible Python modules (and the same was true for all
derived distributions). This seems to be in conflict with the Social
Contract.

I don't think there is one solution for this, we should look at each
module seperately to see how to solve the problem. IMHO free, GPL
incompatible licenses are only annoying.

Jeroen Dekkers

[Glenn Maynard]

Post by Jeroen Dekkers
I don't think there is one solution for this, we should look at each
module seperately to see how to solve the problem. IMHO free, GPL
incompatible licenses are only annoying.

On the other hand, GPL-licensed libraries are also annoying. It's both
ends that cause this kind of problem: libraries using the GPL instead of
the LGPL, and GPL-incompatible programs that want to use them.

[Bernhard R. Link]

Post by Glenn Maynard

Post by Jeroen Dekkers
I don't think there is one solution for this, we should look at each
module seperately to see how to solve the problem. IMHO free, GPL
incompatible licenses are only annoying.

On the other hand, GPL-licensed libraries are also annoying. It's both
ends that cause this kind of problem: libraries using the GPL instead of
the LGPL, and GPL-incompatible programs that want to use them.

I think one has to distinguish here: GPL-libraries that have something
unique, so that anyone wants to use the, are good to be GPLed as they
push GPL-compatible licences.

What I think is the annoying part of the OpenSSL<->GnuTls problem is
that OpenSSL is the bad guy, so it would be better to have the free
replacement making concessions to nasty program licences (i.e.
GPL incompatible) to get an stable standard library for this
more and more important part, that GPL-programs can use.

With having the free replacement licenced this strict, one only
archieves that the standard-library for encryption keeps beeing
OpenSSL, thus shooting GPLed software in the foot.


Hochachtungsvoll,
Bernhard R. Link

[David Starner]

Post by Bernhard R. Link
I think one has to distinguish here: GPL-libraries that have something
unique, so that anyone wants to use the, are good to be GPLed as they
push GPL-compatible licences.
What I think is the annoying part of the OpenSSL<->GnuTls problem is
that OpenSSL is the bad guy,

This is debatable (and note that you don't have to be infatuated with
the GPL to become involved with Debian), and off topic.

[Joel Baker]

Post by Bernhard R. Link

Post by Glenn Maynard

Post by Jeroen Dekkers
I don't think there is one solution for this, we should look at each
module seperately to see how to solve the problem. IMHO free, GPL
incompatible licenses are only annoying.

On the other hand, GPL-licensed libraries are also annoying. It's both
ends that cause this kind of problem: libraries using the GPL instead of
the LGPL, and GPL-incompatible programs that want to use them.

I think one has to distinguish here: GPL-libraries that have something
unique, so that anyone wants to use the, are good to be GPLed as they
push GPL-compatible licences.
What I think is the annoying part of the OpenSSL<->GnuTls problem is
that OpenSSL is the bad guy, so it would be better to have the free
replacement making concessions to nasty program licences (i.e.
GPL incompatible) to get an stable standard library for this
more and more important part, that GPL-programs can use.
With having the free replacement licenced this strict, one only
archieves that the standard-library for encryption keeps beeing
OpenSSL, thus shooting GPLed software in the foot.

Only if one things the GPL is the best possible license. Since Debian has
a policy of considering all DFSG-free licenses to be equal (in that they
are free, and there is no 'freeness' comparison which can be agreed upon
by the project as a whole), it remains an annoying conflict between the
fact that the library is GPLed instead of LGPLed, and the advertising
requirement of the OpenSSL license.

Since it is clear that we have asked both sides to consider relaxing the
situation which causes conflict, and both sides have said 'no', there
isn't a lot we can do about it, except work to ensure that our users can
still use the software in some reasonable fashion. Which is a pity, because
I think it serves nobody's interest except the curmudgeons, when free
software starts infighting to the point that it prevents the users from
being able to make the best use of it.

Unfortunately, this does mean that the only workable answer is probably
to inspect modules invidividually, irrespective of whether the licenses
'annoy' us or not.

[Bernhard R. Link]

Post by Joel Baker
Only if one things the GPL is the best possible license. Since Debian has
a policy of considering all DFSG-free licenses to be equal (in that they
are free, and there is no 'freeness' comparison which can be agreed upon
by the project as a whole), it remains an annoying conflict between the
fact that the library is GPLed instead of LGPLed, and the advertising
requirement of the OpenSSL license.

I think you have to seperate between what you give rights to exist
and what you prefer.

I'm not saying OpenSSL should be banned or removed from the
distribution, but that its licence hurts the development of
free software.

And an SSL-implementation is an really important thing. Having OpenSSL
polluting the large pool of GPLed software, making it necassary to
add extra permissions for the code, thus making it more problemeatic
to tranfer code between programs, is really an ugly thing.

One might also have different opinions of what free means. Some prefer
something liberal BSD-like, others an more secure GPL-way. I tolarate
advertising clauses and clauses about patents as free, though I see
them as abuse of copyright law.

What I wanted to state was, that I see the fakt of the replacement
beeing GPLed is counterproductive, as the main reason to put a library
under GPL in my eyes - the encouragement of more GNU-usefull
licences i.e. licences that permit at least as much as the GPL -
is in my eyes not applicable to an ssl-implementation, because
introducing an GPL-compatible standard helps this goals more than
protecting the replacement from beeing abused by proprietary programs.

Hochachtungsvoll,
Bernhard R. Link

[Jeroen Dekkers]

Post by Bernhard R. Link
What I wanted to state was, that I see the fakt of the replacement
beeing GPLed is counterproductive, as the main reason to put a library
under GPL in my eyes - the encouragement of more GNU-usefull
licences i.e. licences that permit at least as much as the GPL -
is in my eyes not applicable to an ssl-implementation, because
introducing an GPL-compatible standard helps this goals more than
protecting the replacement from beeing abused by proprietary programs.

You can also say that because GnuTLS is GPL'd more programs will be
under the GPL if they want to use GnuTLS. It's just how you look at
the situation. But GNU decides it, so I suggest discussing it with
them instead of discussing on this list.

Jeroen Dekkers

[Anthony Towns]

Post by Jeroen Dekkers

Post by Bernhard R. Link
What I wanted to state was, that I see the fakt of the replacement
beeing GPLed is counterproductive, as the main reason to put a library
under GPL in my eyes - the encouragement of more GNU-usefull
licences i.e. licences that permit at least as much as the GPL -
is in my eyes not applicable to an ssl-implementation, because
introducing an GPL-compatible standard helps this goals more than
protecting the replacement from beeing abused by proprietary programs.

You can also say that because GnuTLS is GPL'd more programs will be
under the GPL if they want to use GnuTLS.

Except they won't use GnuTLS because they can use OpenSSL instead. Even if
OpenSSL were somewhat worse than GnuTLS, but still functional this would
be the case. And OpenSSL isn't worse than GnuTLS -- it's far better. So
this only hurts GnuTLS by ensuring everyone but the GPL fanboys work on
OpenSSL instead.

Post by Jeroen Dekkers
It's just how you look at
the situation. But GNU decides it, so I suggest discussing it with
them instead of discussing on this list.

Actually the authors decide it, and they've already decided, just like the
OpenSSL folks have. We could always start a third project though! Who's
with me??? :)

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif

[Branden Robinson]

Since Debian has a policy of considering all DFSG-free licenses to be
equal

Debian has no such policy; have you even read DFSG 4?

Licenses that fulfill the letter and spirit of the DFSG in a
straightforward and uncomplicated manner are to be valued more than
licenses which, through slippery constructions, manage to satisfy the
letter of the DFSG while not contributing to users' freedom as much as
other licenses do.

I have long thought that Debian ought to explicitly recognize certain
licenses as being in a "Hall of Fame"; those being licenses that are
widely-used, well-understood, and which work well with other licenses.

My suggestion for this list would be:

* MIT/X11
* 2- and 3-clause BSD
* LGPL
* GPL

[Joel Baker]

Post by Branden Robinson

Since Debian has a policy of considering all DFSG-free licenses to be
equal

Debian has no such policy; have you even read DFSG 4?

I have. In fact, just to be sure, I re-read it 30 seconds ago. I see
nothing in it which asserts that software which complies via DFSG 4 is
"less free", or provides a "freeness operator" by which to make any such
comparison. Encouraging people to make our jobs easier is completely
orthogonal to the question of freeness.

However, the first assertion points out that I was careless with my
language, and I do apologize. I believe it would be more accurate to say
that Debian (as a project, not as developers) has a *practice* of viewing
DFSG compliance as 9/10ths of the law. Which direction that other 1/10th
goes in is entirely up to personal biases, in my experience.

Post by Branden Robinson
Licenses that fulfill the letter and spirit of the DFSG in a
straightforward and uncomplicated manner are to be valued more than
licenses which, through slippery constructions, manage to satisfy the
letter of the DFSG while not contributing to users' freedom as much as
other licenses do.

Where is this stated? I do not see it in the DFSG, or the Social Contract;
if you are referring to another document, please provide a citation. I,
personally, agree with the opinion that licenses which clearly satisfy the
DFSG are 'better', but that's a personal value judgement, and only applies
to what I choose to write/package/etc.

Post by Branden Robinson
I have long thought that Debian ought to explicitly recognize certain
licenses as being in a "Hall of Fame"; those being licenses that are
widely-used, well-understood, and which work well with other licenses.
* MIT/X11
* 2- and 3-clause BSD
* LGPL
* GPL

DFSG 10 seems to accomplish this? Certainly, I could see perhaps an update
to include the LGPL (since the GPL is there already, and if anything it is
more compatible, by purpose) and MIT/X11, but I'd say that we do, in fact,
already recognize such licenses (which is a good thing).

All I all, I personally find the GPL's restrictions to be far more of an
encumberance than someone who just wants a little credit for the work that
they put into something, and thus have a clause requiring advertising to
make some acknowlegement of their work if it's used. But that's only my
opinion, and if you want to start deciding "freeness" values, well, I think
that the S:N ratio on d-d will drop even further than it already is. I'd
rather just settle for deciding if things meet the DFSG, and leave it at
that - it seems like a significant part of these codifiy what "Free" means
for us.

Or, to summarize it, if we're going to get into making that sort of value
judgement, I want the values used to judge to be mine. You want them to be
yours. This does not scale well.

[Jeff Licquia]

Post by Joel Baker

Post by Branden Robinson

Since Debian has a policy of considering all DFSG-free licenses to be
equal

Debian has no such policy; have you even read DFSG 4?

I have. In fact, just to be sure, I re-read it 30 seconds ago. I see
nothing in it which asserts that software which complies via DFSG 4 is
"less free", or provides a "freeness operator" by which to make any such
comparison. Encouraging people to make our jobs easier is completely
orthogonal to the question of freeness.

Who said anything about "less free"? You said "all DFSG licenses are
equal", Branden said "no, they aren't" and provided evidence of a
preference, stated as an "encouragement".

Besides, DFSG 4 doesn't say anything about its purpose being to "make
our jobs easier", either. It's less of a stretch to imply that the
"Debian FREE Software Guidelines" talk about freedom than it is to imply
that they talk about usefulness.

Post by Joel Baker
However, the first assertion points out that I was careless with my
language, and I do apologize. I believe it would be more accurate to say
that Debian (as a project, not as developers) has a *practice* of viewing
DFSG compliance as 9/10ths of the law. Which direction that other 1/10th
goes in is entirely up to personal biases, in my experience.

If you say so. OTOH, we weren't satisfied with the QPL when that
license came down because of its uncooperative nature re: the
GPL-licensed KDE components. I don't think that debate was one of
"personal bias" either.

Post by Joel Baker

Post by Branden Robinson
I have long thought that Debian ought to explicitly recognize certain
licenses as being in a "Hall of Fame"; those being licenses that are
widely-used, well-understood, and which work well with other licenses.
* MIT/X11
* 2- and 3-clause BSD
* LGPL
* GPL

DFSG 10 seems to accomplish this? Certainly, I could see perhaps an update
to include the LGPL (since the GPL is there already, and if anything it is
more compatible, by purpose) and MIT/X11, but I'd say that we do, in fact,
already recognize such licenses (which is a good thing).

At least some versions of the Artistic License were considered bad by
some, mostly because of vagueness as I recall.

Maybe the contents of /usr/share/common-licenses should be considered
"preferred".

Post by Joel Baker
All I all, I personally find the GPL's restrictions to be far more of an
encumberance than someone who just wants a little credit for the work that
they put into something, and thus have a clause requiring advertising to
make some acknowlegement of their work if it's used. But that's only my
opinion, and if you want to start deciding "freeness" values, well, I think
that the S:N ratio on d-d will drop even further than it already is. I'd
rather just settle for deciding if things meet the DFSG, and leave it at
that - it seems like a significant part of these codifiy what "Free" means
for us.
Or, to summarize it, if we're going to get into making that sort of value
judgement, I want the values used to judge to be mine. You want them to be
yours. This does not scale well.

I don't think that there's much controversy over whether the OpenSSL
license is worse than the GPL. Even if you can endure the advertising
clause, there's the "you can't license this code under other licenses,
such as the GPL" clause, which I find to be much more noxious and
uncooperative.

It's fallacious to take a difficult and controversial choice (such as
GPL vs. no-ad-clause BSD) and infer that all choices in that area of
inquiry will be equally difficult to make. This one in particular seems
to be a no-brainer.

[Branden Robinson]

I see nothing in it which asserts that software which complies via
DFSG 4 is "less free", or provides a "freeness operator" by which to
make any such comparison.

Jeff rebutted this point adequately, but I'll pound on it some more.
You are confusing "equal" with "equivalent". Freedom, or "freeness", is
not a discrete quantity like the number of marbles you have. It's also
not a continuous quantity measurable on a single axis, like voltage[1].
Freedom is a complex philosophical concept, which is why the FSF spends
a lot of time explaining what they mean by it. So does Debian, in the
form of the DFSG.

That some simpletons prefer to view the world in terms of "my license is
more free than yours" and refuse to countenance any context for freedom, or
definitions of the concept other than their own, does not mean that
everyone suffers from this irrationality. That News Corporation can
glibly say, "of COURSE you've got a choice in television programming,
we own over 20 different cable channels with a range of entertaining
fare, all carefully selected by us to maximize your viewing pleasure"
does not mean that no one else can plausibly claim that 20 options all
from one vendor doesn't represent real choice. Of course, some people
claim exactly that, but they're just wrong.

Encouraging people to make our jobs easier is completely orthogonal to
the question of freeness.

DFSG 4 makes a value judgement. I do not know by what circumlocutions
you intend to escape or obscure this fact.

However, the first assertion points out that I was careless with my
language, and I do apologize. I believe it would be more accurate to say
that Debian (as a project, not as developers) has a *practice* of viewing
DFSG compliance as 9/10ths of the law. Which direction that other 1/10th
goes in is entirely up to personal biases, in my experience.

I don't see anything here but a sloppy analogy to an even sloppier
quasi-legal concept that doesn't even have relevance to intangible
goods. What are you trying to say?

Post by Branden Robinson
Licenses that fulfill the letter and spirit of the DFSG in a
straightforward and uncomplicated manner are to be valued more than
licenses which, through slippery constructions, manage to satisfy the
letter of the DFSG while not contributing to users' freedom as much as
other licenses do.

Where is this stated?

Read the list archives of debian-legal. By analogy, that one cannot
find something in the Declaration of Independence or the Constitution
doesn't mean it has no bearing on public policy in the United States.

I do not see it in the DFSG, or the Social Contract; if you are
referring to another document, please provide a citation. I,
personally, agree with the opinion that licenses which clearly satisfy
the DFSG are 'better', but that's a personal value judgement, and only
applies to what I choose to write/package/etc.

It goes farther than that. The package maintainer's opinion of what
satisfies his personal understanding of the DFSG is not solely
determinative. That Debian collectively renders decisions about a
package's "freeness" (sometimes retrospectively) through a fairly
freewheeling discussion process involving subscribers to debian-legal,
the archive administrators, upstream authors, and interested third
parties does not rob it of legitimacy. In my DPL platform I called for
a greater formalization of this process, but that's only because I think
it would be prudent, not that we're doomed with destruction if we don't
do it.

Post by Branden Robinson
I have long thought that Debian ought to explicitly recognize certain
licenses as being in a "Hall of Fame"; those being licenses that are
widely-used, well-understood, and which work well with other licenses.
* MIT/X11
* 2- and 3-clause BSD
* LGPL
* GPL

DFSG 10 seems to accomplish this?

Not really. It only mentions a few examples of DFSG-free licenses, and
does not explicitly say that they're considered better than others, or
offer reasons why.

For what it's worth, the original Artistic license, which was the only
one that existed when the DFSG was written (IIRC), is pretty
broadly considered a license with perfectly noble intentions but poor
phrasing. That's why it was rewritten (and not by Debian).

Furthermore, DFSG 10 doesn't even address the issue of the variants of
the BSD license, which has important implications for that part of the
user community that modifies its own systems and distributes its work.
(Debian developers are not the only developers in the world who use
Debian, believe it or not! :) )

Certainly, I could see perhaps an update to include the LGPL (since
the GPL is there already, and if anything it is more compatible, by
purpose) and MIT/X11, but I'd say that we do, in fact, already
recognize such licenses (which is a good thing).

And I'd like to make such a thing more explicit. It doesn't have to be
part of the DFSG document itself. I envision it as a tool to help
people select licenses for their projects that Debian can be
enthusiastic about. A lot of software developers just don't want to be
bothered about licensing issues and don't want to become armchair
IP lawyers; they just want to hack. I think Debian could play a role in
helping these people to make such decisions in a way that reduces the
amount of annoying mail they get down the road from distributors who
want to ship their software but cannot because the author wrote his own
license, which didn't cover all the bases.

All I all, I personally find the GPL's restrictions to be far more of an
encumberance than someone who just wants a little credit for the work that
they put into something, and thus have a clause requiring advertising to
make some acknowlegement of their work if it's used.

Yours is a minority opinion. While various Debian developers have
varied opinions about the Free Software Foundation and, say, Richard M.
Stallman, I'm willing to bet that most of them don't contort their faces
with disgust every time they have to run gcc, wishing they had a "truly
free" compiler instead.

I think it's a very safe bet that the Regents of the University of
California abandoned the advertising clause because their lawyers
decided it was untenable.[2] Huge institutions like that don't loosen
licensing terms out of charity.

But that's only my opinion, and if you want to start deciding
"freeness" values, well, I think that the S:N ratio on d-d will drop
even further than it already is. I'd rather just settle for deciding
if things meet the DFSG, and leave it at that - it seems like a
significant part of these codifiy what "Free" means for us.

You are conflating "freeness" values with any other value judgement
Debian might care to make about a license. I think Debian has the right
to prefer, and ask for, license terms that go above and beyond what the
DFSG minimally requires. Remember clause 4 of the Social Contract? It
is not just our own definition of "Free Software" that we are attempting
to serve.

Or, to summarize it, if we're going to get into making that sort of
value judgement, I want the values used to judge to be mine. You want
them to be yours. This does not scale well.

This is a straw man argument. (For those who don't know what that term
means -- not naming any names here *cough* -- I'll explain it.) I am
not adopting the position you cite at all, and it is not the only
alternative to yours. You are asserting that all value judgements in
the context of the DFSG are judgements of "freeness" on some sort of
sliding scale. Not only is that untrue, but the conception of
"freeness" as being representable on a sliding scale is fallaciously
simplistic.

[1] simple DC voltages; *two* axes isn't enough either, you EE
pedants.

[2] I have to admit that, despite asking legally-minded people over the
years, I've never been able to track down a cite for a case that
establishes that your copyright license cannot place restrictions on
other people's commercial advertising. Last month, in Thompson v.
Western States Medical Center, though, the Supreme Court asserted a
pretty laissez-faire attitude towards the content of commercial
advertising ("A divided U.S. Supreme Court struck down on Monday the
federal government's ban that prevented pharmacies from advertising for
a particular drug mixed and created for a patient's specific needs.
The high court, by a 5-4 vote, said the ban amounted to
unconstitutional restrictions on commercial speech protected by the
First Amendment. The ruling was a setback for the federal government,
which defended the ban.") This ruling is certainly not squarely on
point, since it deals with a restriction on commercial speech instead of
a compulsion to make certain statements in commercial speech. And, of
course, it's one of those typical 5-4 rulings that promises more strife
down the road. So, I'd love it if someone could provide me a better
cite that would seem to motivate
<ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change>.

[Joel Baker]

[ replies from both Branden and Jeff elided ]

I appear to have been having a rather... separate discussion from what was
apparently intended. While I do stand by my points, in general, I no longer
think that they are relevant to what people were trying to talk about.

All of the points made by both replies were salient, and probably even
correct, but as they were made in a context that wasn't anything resembling
the points I was aiming at, I don't think I can evaluate them or reply to
them at length in any useful fashion.

My apologies for the confusion; I leave the field to those who had it
before I came, since I see no reason to *start* a discussion such as I
believed I was participating in.

[Richard Braakman]

Post by Branden Robinson
I think it's a very safe bet that the Regents of the University of
California abandoned the advertising clause because their lawyers
decided it was untenable.[2] Huge institutions like that don't loosen
licensing terms out of charity.

On the other hand, lawyers don't drop clauses just because they are
unenforcible :-)

One possibility is that they thought that defending the advertising clause
might weaken their position on another issue. Maybe they want to be able
to argue against a similar clause in someone else's license.

Or maybe this license change was an actual case of a huge institution doing
something sensible. It does happen.

Richard Braakman

[Branden Robinson]

Post by Richard Braakman

Post by Branden Robinson
I think it's a very safe bet that the Regents of the University of
California abandoned the advertising clause because their lawyers
decided it was untenable.[2] Huge institutions like that don't loosen
licensing terms out of charity.

On the other hand, lawyers don't drop clauses just because they are
unenforcible :-)

Sadly, you have a point there. The same goes for politicians and laws.

Post by Richard Braakman
One possibility is that they thought that defending the advertising clause
might weaken their position on another issue. Maybe they want to be able
to argue against a similar clause in someone else's license.

Hmm, I wonder if the license change was part of the secret settlement
with AT&T? Since the case was settled years previously, though, I guess
that's unlikely. (The lawsuit was settled on 1994-02-04[1], and the
abandoment of the advertising clause did not happen until 1999-07-02[2].)

Post by Richard Braakman
Or maybe this license change was an actual case of a huge institution doing
something sensible. It does happen.

Okay, *now* you're getting way too optimistic for me. :)

[1] http://ftp.openbsd.cz/pub/NetBSD/misc/release/misc/USL-lawsuit
[2] ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change

[Brian May]

Post by Jeroen Dekkers
From a first look, GNU TLS has a very different API. The current code in
the socket module won't work with GNU TLS.

I wonder how hard it would be to create a library that sits on top of
GNU TLS and gives it the same API as openssl.

(I am not volunteering to do this though).

[Josef Spillner]

Post by Brian May
I wonder how hard it would be to create a library that sits on top of
GNU TLS and gives it the same API as openssl.

OpenSSL's API is much too complicated for most applications whose only worry
would be clear-text transmission of data.
We actually have a wrapper in place which gets configured at compile time
(--with-tls=none/gnutls/openssl), which provides nothing but basic socket
enabling/disabling functionality, and cert finding.

But I don't have a clue how generic such an API would be for more difficult
tasks - I'm rather pessimistic here.
I'd rather like to see the openssl authors to remove their stupid licence
restriction.

Josef
--
The MindX Open Source Project: Fighting proprietary games
GGZ now! - The GGZ Gaming Zone: http://ggz.sourceforge.net
ggz.morat.net | ggz.snafu.de | jzaun.com | mindx.sourceforge.net/europeone