On Wed, Jun 21, 2006 at 01:21:17AM +0200, Hendrik Sattler wrote:
Am Mittwoch, 21. Juni 2006 00:56 schrieb Tollef Fog Heen:
Is this allowed? If not, why not? Would it be allowed if the package
stanza for libfoo read:
Package: libfoo
Depends: libbar-ssl | libbar, libc6
Is this
* Thomas Bushnell BSG
| What matters is not what the Debian package dependencies look like,
| but the shared library dependencies in the programs themselves.
libfoo will obviously have a NEEDED which lists libbar (and both
libbar-ssl and libbar have a soname of libbar and have to conflict).
--
* Hendrik Sattler
| Am Mittwoch, 21. Juni 2006 00:56 schrieb Tollef Fog Heen:
| Is this allowed? If not, why not? Would it be allowed if the package
| stanza for libfoo read:
|
| Package: libfoo
| Depends: libbar-ssl | libbar, libc6
|
| Is this actually supported by the linker?
Imagine
Tollef Fog Heen [EMAIL PROTECTED] writes:
* Thomas Bushnell BSG
| What matters is not what the Debian package dependencies look like,
| but the shared library dependencies in the programs themselves.
libfoo will obviously have a NEEDED which lists libbar (and both
libbar-ssl and libbar
This one time, at band camp, Thomas Bushnell BSG said:
It is not allowed to ship a binary which includes both GPL'd code and
GPL-incompatible code, whether you do so by dynamic or static linking,
and whether the GPL'd code directly or only indirectly depends upon
the GPL-incompatible code.
On Mon, 19 Jun 2006 15:45:09 +0100, James Westby
[EMAIL PROTECTED] wrote:
On (19/06/06 16:04), Marc Haber wrote:
One other is that
GnuTLS seems to fail if used twice inside the same address space, such
as receiving messages via SMTP over TLS and doing lookups via ldaps if
both exim and libldap
Stephen Gran [EMAIL PROTECTED] writes:
Ah, I see the confusion (or maybe have some of my own). I am not talking
about a GPL application that has been modified to use libssl. I am
talking about a GPL application that uses a library, and that library
could or could not link to libssl - the
Jochen Voss [EMAIL PROTECTED] writes:
On Mon, Jun 19, 2006 at 11:21:59AM -0700, Thomas Bushnell BSG wrote:
You cannot distribute GPL'd source which has been modified to link to
a GPL-incompatible library when the only way the source would be
useful is if it is, in fact, linked to that
This one time, at band camp, Thomas Bushnell BSG said:
If the GPL'd source is only useful with GPL-incompatible libfoo, then
you and the shipper of libfoo are combining to ship a program which
contains incompatible licenses, and this is not allowed.
If the GPL'd source is useful with various
* Thomas Bushnell BSG
| If the GPL'd source is useful with various equivalent libraries, some
| GPL-incompatible, some not, then the shipper of the GPL'd source is
| not breaking any rules, because they are not necessarily intending to
| combine their code with the incompatible code.
|
| If you
Am Mittwoch, 21. Juni 2006 00:56 schrieb Tollef Fog Heen:
Is this allowed? If not, why not? Would it be allowed if the package
stanza for libfoo read:
Package: libfoo
Depends: libbar-ssl | libbar, libc6
Is this actually supported by the linker? If yes, why do we care about
transitive
On Wed, Jun 21, 2006 at 12:56:44AM +0200, Tollef Fog Heen wrote:
* Thomas Bushnell BSG
| If the GPL'd source is useful with various equivalent libraries, some
| GPL-incompatible, some not, then the shipper of the GPL'd source is
| not breaking any rules, because they are not necessarily
Stephen Gran [EMAIL PROTECTED] writes:
Unfortunately, it still doesn't answer the question I asked about
transitive linking, where there is no shared library dependency from the
GPL application to a GPL incompatible library.
Yes, it does.
It is not allowed to ship a binary which includes
Tollef Fog Heen [EMAIL PROTECTED] writes:
Package: foo
Depends libfoo, libc6
Package: libfoo
Depends: libbar | libbar-ssl, libc6
Package: libbar
Depends: libc6
Package: libbar-ssl
Depends: libc6, libssl
(Assume that foo, libfoo and libbar are all licenced under the GPL,
libbar with
This one time, at band camp, Thomas Bushnell BSG said:
Anyhow, the point is that certain GPLd programs have special
exceptions that allow them to be linked with openssl. However, note
that *all* the GPL'd code in the final program must have the
exception.
For example, gwenhywfar is a
On Sun, 18 Jun 2006 17:27:28 +0200, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
The other alternative is to port it to another SSL library, like
Mozilla NSS or GnuTLS. Most of the time the SSL code is not terribly
complicated and the port is fairly straight-forward.
otoh, noone seems to care
On 6/19/06, Marc Haber [EMAIL PROTECTED] wrote:
On Sun, 18 Jun 2006 17:27:28 +0200, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
The other alternative is to port it to another SSL library, like
Mozilla NSS or GnuTLS. Most of the time the SSL code is not terribly
complicated and the port is
On Mon, 19 Jun 2006 14:43:11 +0200, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
On 6/19/06, Marc Haber [EMAIL PROTECTED] wrote:
otoh, noone seems to care much about GnuTLS. GnuTLS is causing much
grief with the exim4 packages and there is nobody who is willing to
help.
Is this the
On (19/06/06 16:04), Marc Haber wrote:
On Mon, 19 Jun 2006 14:43:11 +0200, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
Is this the /dev/random issue?
The /dev/random issue is one of the issues, yes.
http://lists.gnupg.org/pipermail/gnutls-dev/2006-January/001046.html
and many more
The /dev/random issue is one of the issues, yes. One other is that
GnuTLS seems to fail if used twice inside the same address space, such
as receiving messages via SMTP over TLS and doing lookups via ldaps if
both exim and libldap are linked against the same gnutls libs.
Odd. The gnutls library
Martijn van Oosterhout schrieb:
The /dev/random issue is one of the issues, yes. One other is that
GnuTLS seems to fail if used twice inside the same address space, such
as receiving messages via SMTP over TLS and doing lookups via ldaps if
both exim and libldap are linked against the same
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Thomas Bushnell BSG said:
Anyhow, the point is that certain GPLd programs have special
exceptions that allow them to be linked with openssl. However, note
that *all* the GPL'd code in the final program must have the
This one time, at band camp, Thomas Bushnell BSG said:
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Thomas Bushnell BSG said:
Anyhow, the point is that certain GPLd programs have special
exceptions that allow them to be linked with openssl. However, note
that
Stephen Gran [EMAIL PROTECTED] writes:
Can you provide a pointer to the discussion? I am curious to read it,
if possible. Of course, if it's just in one of your mbox's, don't worry
about it.
Just in mbox.
The fact that this is transitive linking means that it is perfectly
legal to
This one time, at band camp, Thomas Bushnell BSG said:
Stephen Gran [EMAIL PROTECTED] writes:
The fact that this is transitive linking means that it is perfectly
legal to distribute gnucash *source*.
ENOPARSE, sorry. I can't imagine how it _could_ affect the source,
since the source
Hi Thomas,
On Mon, Jun 19, 2006 at 11:21:59AM -0700, Thomas Bushnell BSG wrote:
You cannot distribute GPL'd source which has been modified to link to
a GPL-incompatible library when the only way the source would be
useful is if it is, in fact, linked to that library.
Just for me to learn
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Thomas Bushnell BSG said:
Except, they *are* loaded together.
Making shim libraries does not change the licensing rules at all,
which for the GPL, apply to the complete program.
So then how is it that the NVidia drivers
Russ Allbery [EMAIL PROTECTED] writes:
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Thomas Bushnell BSG said:
Except, they *are* loaded together.
Making shim libraries does not change the licensing rules at all,
which for the GPL, apply to the complete program.
So
Ben Pfaff [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] writes:
Because the Linux kernel adds an additional clause, in the form of a
statement of the author's interpretation of the license, saying that
such modules are okay.
Are you saying that the NVIDIA driver for Linux is a
On 6/18/06, Lars Wirzenius [EMAIL PROTECTED] wrote:
The OpenSSL license is incompatible with the GPL. A GPL application
needs an addition to its license that allows linking with OpenSSL. Some
application authors do that and then Debian (or anyone) can distribute
the apps (in a binary form); some
Daniel Dickinson [EMAIL PROTECTED] writes:
Ok, I'm confused. In the netatalk README.Debian it says that the
Debian project has decided that OpenSSL is GPL-incompatible and
therefore he can't distribute the ssl-based portions of netatalk (like
encrypted authentication with classic macs). I
The license exemption for OpenSSL has to be done by the copyright
holder. As Debian holds copyright on hardly any of the software
there's not much Debian can do except help persuade upstream to add an
exemption.
Hope this explains,
Andrew
On 6/18/06, Daniel Dickinson [EMAIL PROTECTED] wrote:
su, 2006-06-18 kello 01:33 -0400, Daniel Dickinson kirjoitti:
Ok, I'm confused. In the netatalk README.Debian it says that the
Debian project has decided that OpenSSL is GPL-incompatible and
therefore he can't distribute the ssl-based portions of netatalk (like
encrypted authentication with
33 matches
Mail list logo
