Re: Netatalk and SSL
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 actually supported by the linker? Presumably we're talking about two libraries that have the same SONAME but of which one has ssl support built in and the other does not. In that case, yes it is supported. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
* 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). -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
* 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 the trivial case of libbar providing a get_http function which does a GET request on an HTTP url. If you link with openssl it supports HTTPS and HTTP, if not it just supports HTTP. The Depends field would be filled by libbar-dev's shlibs and since it's such a simple package and the ABI is the same, listing libbar | libbar-ssl makes sense. As I wrote in another mail, libbar and libbar-ssl would have to have the same soname and conflict. | If yes, why do we care about transitive libraries technics like .la | files or pkg-config? I guess that libbar-ssl would have to dlopen | the ssl library to achieve this. Mostly histerical reasons and both libtool and pkg-config should be fixed to not link transitively (on Linux, at least). pkg-config has some of the fixes in, but it needs some more fixes which I haven't had the time to push in yet. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Netatalk and SSL
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 have a soname of libbar and have to conflict). I have no idea if that's what is obvious. If it's true, then there is no problem, provided the program actually works both ways. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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. This one time, at band camp, Thomas Bushnell BSG said: Tollef Fog Heen [EMAIL PROTECTED] writes: libfoo will obviously have a NEEDED which lists libbar (and both libbar-ssl and libbar have a soname of libbar and have to conflict). I have no idea if that's what is obvious. If it's true, then there is no problem, provided the program actually works both ways. Thanks to Tollef and others for actually answering the question I asked. Thank you Thomas for the answers to questions I didn't ask, and for being consistent in them. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Netatalk and SSL
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 are linked against the same gnutls libs. Do you have a reference please? #297174 Is there a bug against gnutls? No. There are a number of TLS-related bugs against exim4 which I have not reassigned since there is no GnuTLS knowledge in the exim environment (the contributor of the GnuTLS-related code in upstream exim vanished years ago) to surely determine whether an issue is really in GnuTLS or in exim. http://wiki.debian.org/PkgExim4 has a help request in the Current Information section, and the probably GnuTLS-related bugs in exim are usertagged in the BTS as gnutls for user [EMAIL PROTECTED] Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Netatalk and SSL
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 higher level application does not itself care or notice. I am not talking about changing the GPL application to directly use the GPL incompatible library. Maybe that applies to gnucash, but I'm trying to understand the more general case. Right. So, you cannot distribute binaries if they do, in fact, link to ssl. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 library. Just for me to learn something: which clause of the GPL is this? I did not find the concept of the source code being useful together with one thing or another in the GPL. Is the theory behind this, that the modified source code together with the GPL-incompatible library (The library source? Or the compiled library?) forms a modified work (in the sense of clause 2)? You cannot evade the terms of the GPL by shipping components separately when you would not be allowed to ship them together, nor does it matter whether two different people do the shipping. Remember always that the GPL applies to the whole program, not to individual files, functions, or lines of code. 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 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 are shipping *binaries* however, which declare shared library dependencies on the GPL-incompatible library, then that excuse vanishes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 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 are shipping *binaries* however, which declare shared library dependencies on the GPL-incompatible library, then that excuse vanishes. Agreed to all of this. 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. But I think you're repeating the same answers, and I'm repeating the same questions, so maybe we should just drop it. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Netatalk and SSL
* 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 are shipping *binaries* however, which declare shared library | dependencies on the GPL-incompatible library, then that excuse | vanishes. So if you have: 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 a licence exception allowing it to be linked to openssl. Also assume that libbar and libbar-ssl are ABI-compatible.) 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 ? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 libraries technics like .la files or pkg-config? I guess that libbar-ssl would have to dlopen the ssl library to achieve this. HS pgpkzvtmTo6RE.pgp Description: PGP signature
Re: Netatalk and SSL
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 intending to | combine their code with the incompatible code. | If you are shipping *binaries* however, which declare shared library | dependencies on the GPL-incompatible library, then that excuse | vanishes. So if you have: 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 a licence exception allowing it to be linked to openssl. Also assume that libbar and libbar-ssl are ABI-compatible.) Is this allowed? I believe that it is, so long as we aren't shipping any other packages that transitively depend on both foo and libbar-ssl, overriding foo's preference. Would it be allowed if the package stanza for libfoo read: Package: libfoo Depends: libbar-ssl | libbar, libc6 I believe that it is not. If you want actual arguments on the subject, they're buried somewhere in debian-legal archives from three years ago. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 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. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 a licence exception allowing it to be linked to openssl. Also assume that libbar and libbar-ssl are ABI-compatible.) 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 What matters is not what the Debian package dependencies look like, but the shared library dependencies in the programs themselves. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 library which contains the exception and which uses openssl, but that doesn't solve the gnucash problem, where we want to link gnucash against this library. We can't do that, because gnucash and gnome don't have the exception. But that's transitive linking. If gnucash doesn't have libssl in it's NEEDED section, or directly reference any symbols from libssl itself, is this really an issue? I understand we can't distribute statically linked copies of gnucash, but we don't do that, AFAIK. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Netatalk and SSL
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 much about GnuTLS. GnuTLS is causing much grief with the exim4 packages and there is nobody who is willing to help. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Netatalk and SSL
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 fairly straight-forward. 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 /dev/random issue? I thought there was a solution to that, except upstream disagreed? -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 /dev/random issue? 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. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Netatalk and SSL
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 posts from that month and the next 2. 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. Do you have a reference please? Is there a bug against gnutls? You might like to contact [EMAIL PROTECTED] to discuss these problems further, and for any help that I can provide you with. James -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 is versioned (on debian anyway) to prevent that being a problem. Do you have a reference? Maybe someone forgot to enable thread safety for libgcrypt. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 gnutls libs. Odd. The gnutls library is versioned (on debian anyway) to prevent that being a problem. Do you have a reference? Maybe someone forgot to enable thread safety for libgcrypt. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297174 It only works if exim and libldap2 are linked against *different* versions of libgnutls. Marc closed the bug because for some time exim4 was compiled against libgnutls12 whereas libldap2 still used libgnutls11. Now that they are both again linked against the same version I fear the problem will appear again. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Netatalk and SSL
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 exception. For example, gwenhywfar is a library which contains the exception and which uses openssl, but that doesn't solve the gnucash problem, where we want to link gnucash against this library. We can't do that, because gnucash and gnome don't have the exception. But that's transitive linking. If gnucash doesn't have libssl in it's NEEDED section, or directly reference any symbols from libssl itself, is this really an issue? I understand we can't distribute statically linked copies of gnucash, but we don't do that, AFAIK. The GPL Compliance Lab was asked about exactly this question. The fact that this is transitive linking means that it is perfectly legal to distribute gnucash *source*. It doesn't affect the binaries at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 *all* the GPL'd code in the final program must have the exception. For example, gwenhywfar is a library which contains the exception and which uses openssl, but that doesn't solve the gnucash problem, where we want to link gnucash against this library. We can't do that, because gnucash and gnome don't have the exception. But that's transitive linking. If gnucash doesn't have libssl in it's NEEDED section, or directly reference any symbols from libssl itself, is this really an issue? I understand we can't distribute statically linked copies of gnucash, but we don't do that, AFAIK. The GPL Compliance Lab was asked about exactly this question. 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. 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 doesn't link to anything - it's just a build system and source code. It doesn't affect the binaries at all. Again, parse problem. What is 'it' in this context? The GPL? The exception? Or are you saying they thought transitive links to GPL incompatible software violates the GPL? I am assuming you meant the last statement, but your brevity left me unclear. And if so, why? I thought that I had read somewhere that the standard advice for making a non-free application talk to a GPL library was through a 'shim' library, so that the symbols aren't loaded together in a non-free/GPL incompatible application. (Of course, I can't immediately find the link to this advice right now. Irritating) Isn't that roughly the same as transitive linking? Just curious, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Netatalk and SSL
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 distribute gnucash *source*. ENOPARSE, sorry. I can't imagine how it _could_ affect the source, since the source doesn't link to anything - it's just a build system and source code. 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. It doesn't affect the binaries at all. Again, parse problem. What is 'it' in this context? It is the fact that the linking is transitive rather than direct. I thought that I had read somewhere that the standard advice for making a non-free application talk to a GPL library was through a 'shim' library, so that the symbols aren't loaded together in a non-free/GPL incompatible application. 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. In the present case, the GPL v3 is expected to solve the problem, because GPL v3 will allow Debian to take advantage of the system libraries exception. But that is many many months away. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 doesn't link to anything - it's just a build system and source code. 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. 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 higher level application does not itself care or notice. I am not talking about changing the GPL application to directly use the GPL incompatible library. Maybe that applies to gnucash, but I'm trying to understand the more general case. I thought that I had read somewhere that the standard advice for making a non-free application talk to a GPL library was through a 'shim' library, so that the symbols aren't loaded together in a non-free/GPL incompatible application. 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 and so forth aren't illegal? This is precisely how many non-free or GPL incompatible applications communicate with GPL'ed ones. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Netatalk and SSL
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 something: which clause of the GPL is this? I did not find the concept of the source code being useful together with one thing or another in the GPL. Is the theory behind this, that the modified source code together with the GPL-incompatible library (The library source? Or the compiled library?) forms a modified work (in the sense of clause 2)? All the best, Jochen -- http://seehuhn.de/ signature.asc Description: Digital signature
Re: Netatalk and SSL
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 and so forth aren't illegal? This is precisely how many non-free or GPL incompatible applications communicate with GPL'ed ones. 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. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 then how is it that the NVidia drivers and so forth aren't illegal? This is precisely how many non-free or GPL incompatible applications communicate with GPL'ed ones. 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 user program, not a kernel module? (I do not know for sure because I have never had cause to download or install it.) Here is the clarification included in the COPYING file distributed with the Linux kernel. It does not talk about kernel modules at all, only about system calls made by user programs. NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. Linus Torvalds -- ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. --Daniel Pead -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 user program, not a kernel module? (I do not know for sure because I have never had cause to download or install it.) Here is the clarification included in the COPYING file distributed with the Linux kernel. It does not talk about kernel modules at all, only about system calls made by user programs. NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Oh, hm. Good point. I'm so used to Linus talking about the reasons behind his exception for modules that I had forgotten that they weren't mentioned in his exception. Sorry about the misleading comment. One can extend the above argument by way of observing that Linux has a clear interface layer that could be treated the same as the system call layer, but Linus doesn't explicitly say that, and the same could be said of just about any shared library. Probably the more persuasive argument, which *also* applies to binaries, is that Debian is not doing the mixing of the NVidia kernel module and the kernel; the user is doing this when running insmod. The user can create works that are not redistributable without violating the GPL; the GPL does not limit what you do with the pile of code that you have on hand as long as you don't give it to someone else. However, I must say that it's hard to see the distinction between distributing a separate kernel binary and a kernel module and claiming the user is doing the combining and distributing a separate compiled binary and a library and claiming the same thing. (A particularly good edge case, which has some serious practical effects in Debian, is whether one needs to care, as an application author, about the licenses on system nsswitch and PAM modules that are dyanmically loaded into the same executable based on a configuration controlled by the user.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 don't, or haven't yet, and those apps Debian doesn't distribute. 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. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 was pretty sure that debian had worked something out for linking OpenSSL with debian package. Was it only for specific packages? Is this developer just not aware of the accommodation? Am I totally out to lunch on what's going on with this? It isn't just Debian: it's the GPL Compliance Lab too. 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 library which contains the exception and which uses openssl, but that doesn't solve the gnucash problem, where we want to link gnucash against this library. We can't do that, because gnucash and gnome don't have the exception. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 pretty sure that debian had worked something out for linking OpenSSL with debian package. Was it only for specific packages? Is this developer just not aware of the accommodation? Am I totally out to lunch on what's going on with this? Please let me know, Thanks, Daniel - -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFElOWqhvWBpdQuHxwRAmjPAJ9mnjbcbUIHbhOIEIuM7C8AXTtdEACglvR4 6qzWm/I2hFzoKRefRz0Bo4w= =fNWd -END PGP SIGNATURE- -- Andrew Donnellan http://andrewdonnellan.com http://ajdlinux.blogspot.com Jabber - [EMAIL PROTECTED] GPG - hkp://subkeys.pgp.net 0x5D4C0C58 --- Member of Linux Australia - http://linux.org.au Debian user - http://debian.org Get free rewards - http://ezyrewards.com/?id=23484 OpenNIC user - http://www.opennic.unrated.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
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 classic macs). I was pretty sure that debian had worked something out for linking OpenSSL with debian package. Was it only for specific packages? Is this developer just not aware of the accommodation? Am I totally out to lunch on what's going on with this? 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 don't, or haven't yet, and those apps Debian doesn't distribute. -- Though spring is here, to me it is still September -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
