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.
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 l
* 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?
Imag
* 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).
--
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
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,
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 includ
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 i
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
* 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
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 var
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
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 - t
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 a
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 Li
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 comp
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
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 so
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,
> > sin
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 t
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
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
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 s
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
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
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 thi
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 po
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
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
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).
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); som
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 wit
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:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 was
34 matches
Mail list logo
