Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Sun, Jan 06, 2002 at 01:39:29PM -0800, Thomas Bushnell, BSG wrote: No. It has always been understood by the GNU Project that using kernel syscalls does not make something one program; the fact that Linus mentions that explicitly doesn't change the fact one whit. How is the GNU Project's understanding relevant when they did not write the Linux kernel? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
Hamish Moffatt [EMAIL PROTECTED] writes: On Sun, Jan 06, 2002 at 01:39:29PM -0800, Thomas Bushnell, BSG wrote: No. It has always been understood by the GNU Project that using kernel syscalls does not make something one program; the fact that Linus mentions that explicitly doesn't change the fact one whit. How is the GNU Project's understanding relevant when they did not write the Linux kernel? The point, which you seem intent on missing, is that the understanding of the GNU Project, and the Linux kernel, and all the other free kernels out there, is the same in this regard. The fact that the Linux authors put it explicitly does not indicate, therefore, that without putting it there explicitly, the GPL would have different implications.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Thu, Jan 03, 2002 at 06:29:50PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] writes: If a library's interface is implemented to a standard or similar, than someone linking to a GPL library version should be alright, no? No. Actually linking to the GPL'd library is not allowed if you are doing so from non-GPL-compatible code. The GPL is written to specifically prevent someone who would normally have to modify or copy parts of a non-library GPL'ed program's source(and thus releasing the changes under the GPL), instead turn parts of it into a GPL'ed library(effectivly copying,but perfectly fine) making any changes/additions outside the once non-library code and releasing the final product where the intent is clearly to copy GPL code and use it in a non-GPL compatible program. Here the fact that the code is now a library form is merely a technicality. So linking must be considered forming a derived product, and forbidden. If an author chooses to release he code under the GPL he states his intent that the code cannot be used under programs with non-GPLed licenses. If the author wants to allow this specifically, then the author shoud use the LGPL. Philip Thiem
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
- Original Message - From: Marcus Brinkmann [EMAIL PROTECTED] To: debian-legal@lists.debian.org Sent: Friday, January 04, 2002 9:15 PM Subject: Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license On Fri, Jan 04, 2002 at 05:22:07PM +1100, Hamish Moffatt wrote: For example, the kernel is GPLed but will load and run programs with incompatible licenses. Those programs make syscalls to the kernel to perform system work; how is this permitted? It is so different from an incompatibly-licensed program linking to a GPLed library? And Linus Torvald has added a statement just before the GPL in the file COPYING at the top level directory of the kernel source tree that makes it clear that he thinks that user level programs that only use syscalls to communicate with the kernel are considered to be using the kernel in a normal way. Best on the quality information that I have gained following these discussions -- thank you -- to say the same thing that you have Marcus a little bit different. The kernel is not strictly GPL'd, but GPL-compatible. That clause that says system calls are a-ok, supports the moral/legal intention of the GPL by requiring such a declariation to be explicit. Correct? Best regards, Lloyd __ Get your FREE personalized e-mail at http://www.canada.com
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Sun, Jan 06, 2002 at 07:30:19AM -0800, [EMAIL PROTECTED] wrote: different. The kernel is not strictly GPL'd, but GPL-compatible. That clause that says system calls are a-ok, supports the moral/legal intention of the GPL by requiring such a declariation to be explicit. Correct? No. The kernel is GPLed with the clarification that user-space programs running on the kernel don't combine to be considered a derived work by the kernel. See /path/to/kernel/src/COPYING. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] writes: Best on the quality information that I have gained following these discussions -- thank you -- to say the same thing that you have Marcus a little bit different. The kernel is not strictly GPL'd, but GPL-compatible. That clause that says system calls are a-ok, supports the moral/legal intention of the GPL by requiring such a declariation to be explicit. Correct? No. It has always been understood by the GNU Project that using kernel syscalls does not make something one program; the fact that Linus mentions that explicitly doesn't change the fact one whit. Thomas
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Thu, Jan 03, 2002 at 04:28:55PM -0800, [EMAIL PROTECTED] wrote: Wow, I am worried for our free software community then. You sound like the software companies that do not want people to be able to publicly publish security bug reports. How did the GPL get to its current state then? O darn, we lost in court again, better go back to the drawing board. Nobody had yet the guts to challenge the GPL in court. In all cases where the FSF approached people and urged them to comply with the terms, people preferred to do so rather than going to court. If you are worried about enforcability of the GPL, please read the excellent articles Free Software Matters: Enforcing the GPL I and II by Prof. Eben Moglen, who does it daily. And if you have the chance, listen to him when he gives a talk in your area, he is an excellent speaker. http://emoglen.law.columbia.edu/ Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Fri, Jan 04, 2002 at 05:22:07PM +1100, Hamish Moffatt wrote: For example, the kernel is GPLed but will load and run programs with incompatible licenses. Those programs make syscalls to the kernel to perform system work; how is this permitted? It is so different from an incompatibly-licensed program linking to a GPLed library? And Linus Torvald has added a statement just before the GPL in the file COPYING at the top level directory of the kernel source tree that makes it clear that he thinks that user level programs that only use syscalls to communicate with the kernel are considered to be using the kernel in a normal way. The ldso license is interesting (/usr/doc/ldso/copyright, possibly only on potato or earlier systems). The commentary implies that ld.so deliberately uses the BSD license because the GPL is too strict. Which means that the GPL serves the purpose it was intended for. The understanding of the GPL by the ldso author seems to be in line with what Thomas and many other people say about the effectiveness of the copyleft in the GPL. The general understanding of the [...] contributors is from that perspective merely wishful thinking. Tcl can dynamically load shared libraries so that scripts can use library functions. tcl itself appears to have a BSD-type license. What if a tcl script, using a non-GPL compatible license, causes tcl to load a GPL library (eg libreadline)? The script is being interpreted by the Tcl shell, it's not capable of being linked to anything itself. It might depend on the way that happens. If the script is not written in a way that depends on this behaviour and is in general unaware of that loading happening, and is not shipped with a version of tcl that loads such a library, then it might be okay. The other extreme is that the script explicitely triggers this loading and depends on this behaviour, and all three are shipped in one product. All these details matter, and you will not be able to get a good answer to an incomplete question in license issues. Getting off-topic a bit, there's an interesting clause in the license for libio, in /usr/doc/libc6/copyright (on potato anyway). Not on woody, and I don't have potato to check the context. So no comment :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Thu, Jan 03, 2002 at 06:45:50PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] writes: I do not really understand why, I guess accepting it in the definition of derivative work is the basis, but I cannot help, but wonder as I have not seen legal challanges that support this. It's a perfectly normal case of a derivative work. When you link program A with program B, you are creating a derivative work, A+B. You can only distribute that work if the licenses of A and B permit it. Don't dismiss this as completely obvious. It's not uncontroversial. For example, the kernel is GPLed but will load and run programs with incompatible licenses. Those programs make syscalls to the kernel to perform system work; how is this permitted? It is so different from an incompatibly-licensed program linking to a GPLed library? The ldso license is interesting (/usr/doc/ldso/copyright, possibly only on potato or earlier systems). The commentary implies that ld.so deliberately uses the BSD license because the GPL is too strict. It also has the following paragraph: * It is the general understanding of the above contributors that a * program executable linked to a library containing code that falls * under the GPL or GLPL style of license is not subject to the terms of * the GPL or GLPL license if the program executable(s) that are supplied * are linked to a shared library form of the GPL or GLPL library, and as * long as the form of the shared library is such that it is possible for * the end user to modify and rebuild the library and use it in * conjunction with the program executable. This seems to suggest that a program linking to a GPLed library does not have to be GPLed itself. Interesting that the ld.so license avoids being GPLed anyway to avoid this exact problem. Tcl can dynamically load shared libraries so that scripts can use library functions. tcl itself appears to have a BSD-type license. What if a tcl script, using a non-GPL compatible license, causes tcl to load a GPL library (eg libreadline)? The script is being interpreted by the Tcl shell, it's not capable of being linked to anything itself. libterm-readline-gnu-perl is a package of a Perl module to use libreadline from Perl progams. According to the license, it's available under the same terms as Perl ie your choice of GPL or the Artistic license. But since any combination of GPL program + a GPL-compatibly-licensed program must by GPLed, you really can't use it under the Artistic license at all ie the GPL always dominates. So non-GPL programs apparently can't use that library. Getting off-topic a bit, there's an interesting clause in the license for libio, in /usr/doc/libc6/copyright (on potato anyway). As a special exception, if you link this library with files compiled with a GNU compiler to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. Why does the license require you to use a GNU compiler? Bizarre. Just some thoughts, Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
Hamish Moffatt [EMAIL PROTECTED] writes: Don't dismiss this as completely obvious. It's not uncontroversial. For example, the kernel is GPLed but will load and run programs with incompatible licenses. Those programs make syscalls to the kernel to perform system work; how is this permitted? Because the kernel is not one program together with the applications it runs. It is so different from an incompatibly-licensed program linking to a GPLed library? Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. The ldso license is interesting (/usr/doc/ldso/copyright, possibly only on potato or earlier systems). The commentary implies that ld.so deliberately uses the BSD license because the GPL is too strict. It also has the following paragraph: The ldso people don't have any ability to change the licenses of the actual authors of the libraries in question. There are lots of different cases. A great deal of difficulty is caused by people asserting that totally different cases must all be treated the same way. Post one case at a time, and not a giant spew of a jillion examples, as if they all argued for one single point. Each separate case is a separate discussion. Many of the examples you cited are cases where it is not very important whether the combined thing is a single derived work or not, because the licenses are more permissive than the GPL. Other cases involve explicit declarations by the authors of the programs about how they intend the license to be interpreted. Many involve things like the kernel that are not libraries at all. Getting off-topic a bit, there's an interesting clause in the license for libio, in /usr/doc/libc6/copyright (on potato anyway). As a special exception, if you link this library with files compiled with a GNU compiler to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. Why does the license require you to use a GNU compiler? Bizarre. I have no idea. But what on earth does it have to do with the present conversation? Why do you think that getting off-topic a bit, in a post which already contained so much that is off-topic, has any hope of doing any good for the conversation?
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. I should add here that it is relevant that the callouts to the kernel are callouts to an interface which is defined as not making things a combined derived work, which is not normally the case for a library. It is relevant and important here that the authors of the kernel intend that understanding of those callouts. If some nefarious added callouts to a GPL'd program which normally had nothing similar, and then had some non-free program use those callouts, all as an attempt at a subterfuge to defeat the GPL, this would not be allowed. Thomas
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Thu, Jan 03, 2002 at 10:43:48PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. I should add here that it is relevant that the callouts to the kernel are callouts to an interface which is defined as not making things a combined derived work, which is not normally the case for a library. It is relevant and important here that the authors of the kernel intend that understanding of those callouts. What is the definition of a callout? Why is it so different to a published library function? Apart from convenience of argument, that is. You dismissed my Tcl example without comment but I don't see how it is different to the kernel case. A non-free program running in the Tcl interpreter can have the Tcl interpreter load a GPLed library such as libreadline. The non-free program is not linked to the library. So why is this illegal? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
Hamish Moffatt [EMAIL PROTECTED] writes: On Thu, Jan 03, 2002 at 10:43:48PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. I should add here that it is relevant that the callouts to the kernel are callouts to an interface which is defined as not making things a combined derived work, which is not normally the case for a library. It is relevant and important here that the authors of the kernel intend that understanding of those callouts. What is the definition of a callout? By callout I mean a mechanism for one program to call another. Why is it so different to a published library function? Apart from convenience of argument, that is. Libraries are much more tightly integrated with their callers, for example. You dismissed my Tcl example without comment but I don't see how it is different to the kernel case. A non-free program running in the Tcl interpreter can have the Tcl interpreter load a GPLed library such as libreadline. The non-free program is not linked to the library. So why is this illegal? Maybe it is disallowed. I haven't thought about it.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Why is it so different to a published library function? Apart from convenience of argument, that is. Libraries are much more tightly integrated with their callers, for example. Oh, and you ignored my stressing the importance of considering intent and common practice. It is the intent of kernel designers that the kernel is not one program together with the programs that it loads. It generally *is* the intent of library authors that the library is part of the programs with which they are linked. The nature and structure of the situation is important, as are the intentions of the parties. But the real point, which people frequently seem to miss, is that only this way can the integrity of the copyleft be maintained. If the use of dynamic loading were sufficient to get around the GPL, then its copylefting provisions would be entirely a dead letter, and it would be no better that the BSD license. For that very reason, the FSF and GPL-users in general staunchly stick to the importance of this rule, because it is the only thing that preserves the integrity of the copyleft itself. Now, if you want to argue the point further, *please* take it up with RMS or with Eben Moglen. There's really no advantage to wasting debian-legal with it. That's what I was trying to get across to [EMAIL PROTECTED], and now he's suckered us into a stupid argument. Thomas
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Fri, Jan 04, 2002 at 06:03:30PM +1100, Hamish Moffatt wrote: On Thu, Jan 03, 2002 at 10:43:48PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. I should add here that it is relevant that the callouts to the kernel are callouts to an interface which is defined as not making things a combined derived work, which is not normally the case for a library. It is relevant and important here that the authors of the kernel intend that understanding of those callouts. What is the definition of a callout? Why is it so different to a published library function? Apart from convenience of argument, that is. I think you're overlooking the fact that in the case of a GPL library, the publishing of the interface is ALSO done under the GPL. Are you using GPL header files when compiling? Then the binary output is a derived work of the GPLed library. This is not to imply that someone who reverse-engineers a GPL header file can necessarily link against a GPL library without also being bound by its license terms; it only shows that in the usual case, there's clear support for the claim that library linking creates a derived work. Steve Langasek postmodern programmer pgpqoOCGrwWXP.pgp Description: PGP signature
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] writes: This is something I am very interested in, but as of now, I am not well versed in the subject. My searching has found that this topic is well discussed, but not necessarily well described. Is there any legal precedence here? It's a standard case of a derived work. Has the object brokerage environments or similar technologies -- RPC even -- ability to get around the GPL been addressed in a meaningful proposal? In general, something which is a subterfuge to get around a licensing requirement, is disallowed by the courts. But someone might be sufficiently tricky, and then they would hurt us. As a result, it is distinctly *not* in the interests of the free software community to try and dream up ways of getting around the GPL. If you think you have something specific in mind that might be a problem, send it to RMS.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
- Original Message - From: Thomas Bushnell, BSG [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: debian-legal@lists.debian.org Sent: Thursday, January 03, 2002 7:07 PM Subject: Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license [EMAIL PROTECTED] writes: This is something I am very interested in, but as of now, I am not well versed in the subject. My searching has found that this topic is well discussed, but not necessarily well described. Is there any legal precedence here? It's a standard case of a derived work. How so? Example: I write a book and suggest that you get another book, because I am going to identify some page numbers in that book where the content supports my content. If you don't get that book, I am going to suggest that my book means nothing. Has the object brokerage environments or similar technologies -- RPC even -- ability to get around the GPL been addressed in a meaningful proposal? In general, something which is a subterfuge to get around a licensing requirement, is disallowed by the courts. But someone might be sufficiently tricky, and then they would hurt us. As a result, it is distinctly *not* in the interests of the free software community to try and dream up ways of getting around the GPL. Wow, I am worried for our free software community then. You sound like the software companies that do not want people to be able to publicly publish security bug reports. How did the GPL get to its current state then? O darn, we lost in court again, better go back to the drawing board. My readings suggest that this may be known issue that is not well addressed. I am hoping that it is well addressed or really is a non-issue as you suggest. Best regards, Lloyd __ Get your FREE personalized e-mail at http://www.canada.com
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] writes: How so? Example: I write a book and suggest that you get another book, because I am going to identify some page numbers in that book where the content supports my content. If you don't get that book, I am going to suggest that my book means nothing. The combined linked binary program is the derived work. It is that combined linked program which can only be distributed if the distribution meets the terms of both licenses. And, any way of distributing that combined linked binary program, even by trying to split it up into little pieces as a subterfuge, is still the same thing. Wow, I am worried for our free software community then. You sound like the software companies that do not want people to be able to publicly publish security bug reports. How did the GPL get to its current state then? O darn, we lost in court again, better go back to the drawing board. If you think there is a bug report, then feel free to post it. But don't expect me to try and think up ways for other people to defeat the GPL! My readings suggest that this may be known issue that is not well addressed. I am hoping that it is well addressed or really is a non-issue as you suggest. I'm telling you: it is. I gave you the reasoning; some people have raised lots of FUD, but it's all really just FUD.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] writes: My readings suggest that this may be known issue that is not well addressed. I am hoping that it is well addressed or really is a non-issue as you suggest. It's really very tedious, you know, to think that you help things by dredging up well-settled discussions, and then saying that anyone who doesn't decide that your issues are real ones. You don't understand the situation; the purpose of debian-legal is not to entertain long drawn out discussion to satisfy all comers about what the actual state of the law is. I'm happy to explain the situation to you, but so far, you've just said I read a lot of stuff and I'm totally confused and maybe the people who know better than I are totally ignorant about it. You worry that it may not be well addressed. I can assure you, it is. But more than that, debian-legal is not the place for addressing it.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
- Original Message - From: Thomas Bushnell, BSG [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: debian-legal@lists.debian.org Sent: Thursday, January 03, 2002 7:44 PM Subject: Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license [EMAIL PROTECTED] writes: My readings suggest that this may be known issue that is not well addressed. I am hoping that it is well addressed or really is a non-issue as you suggest. It's really very tedious, you know, to think that you help things by dredging up well-settled discussions, and then saying that anyone who doesn't decide that your issues are real ones. I do not understand your statements. You don't understand the situation; the purpose of debian-legal is not to entertain long drawn out discussion to satisfy all comers about what the actual state of the law is. I'm happy to explain the situation to you, but so far, you've just said I read a lot of stuff and I'm totally confused and maybe the people who know better than I are totally ignorant about it. I am sorry that I upset you. I am not saying that I am totally confused, nor that I read the right stuff. It is interesting that you claim that I think that you know better than me, and even more interesting that you claim that I think that you are ignorant. If there is a more appropriate forum to learn the legal significance of debian development and whether it is something that I can believe in and share with others, I am very interested in finding out. You are a sham when you say that you would be happy to explain it, when you have not, nor have you directed me to where I can. All the information that you have provided just adds to my noise. You worry that it may not be well addressed. I can assure you, it is. But more than that, debian-legal is not the place for addressing it. Now, I am really confused as I believe that it is related to the reason why the ?majority? believe that vim cannot be packaged in debian. Law has to be knowable, Lloyd __ Get your FREE personalized e-mail at http://www.canada.com
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] writes: I am sorry that I upset you. I am not saying that I am totally confused, nor that I read the right stuff. It is interesting that you claim that I think that you know better than me, and even more interesting that you claim that I think that you are ignorant. If there is a more appropriate forum to learn the legal significance of debian development and whether it is something that I can believe in and share with others, I am very interested in finding out. If you want to decide whether you can believe in it, I would recommend you take a look at www.gnu.org/philosophy. That's much better than posting questions which amount to gee, I wonder whether there's a way to get around the GPL. The short answer is: as far as we know, no. The medium-long answer is: as far as we know, no; if there is something that does get around it, we want to know, in such a way that we can fix it without it being exploitet, so post your question somewhere less public. The long answer is: Here are a jillion things that people have dreamed up, and I can address them one at a time. I'm not willing to do the long one. I'm willing to do the short one: there, done. If you are not just trolling, then post a real-world case, involving software, and someone (maybe even me) can explain the application of the GPL to your case. Now, I am really confused as I believe that it is related to the reason why the ?majority? believe that vim cannot be packaged in debian. The case of vim is still being discussed. Leave that aside for the moment.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
- Original Message - From: Thomas Bushnell, BSG [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: debian-legal@lists.debian.org Sent: Thursday, January 03, 2002 7:39 PM Subject: Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license [EMAIL PROTECTED] writes: How so? Example: I write a book and suggest that you get another book, because I am going to identify some page numbers in that book where the content supports my content. If you don't get that book, I am going to suggest that my book means nothing. The combined linked binary program is the derived work. It is that combined linked program which can only be distributed if the distribution meets the terms of both licenses. And, any way of distributing that combined linked binary program, even by trying to split it up into little pieces as a subterfuge, is still the same thing. If a library's interface is implemented to a standard or similar, than someone linking to a GPL library version should be alright, no? My concern is that in an attempt to protect users, we are no better than patent happy USA. If you think there is a bug report, then feel free to post it. But don't expect me to try and think up ways for other people to defeat the GPL! That is exactly what I would hope you do. The way you have presented your feels... I do not think that you would be receptive to a bug report regardless. Luckily, I do not think that others are in a similar mind-space. Regards, Lloyd __ Get your FREE personalized e-mail at http://www.canada.com
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] writes: If a library's interface is implemented to a standard or similar, than someone linking to a GPL library version should be alright, no? No. Actually linking to the GPL'd library is not allowed if you are doing so from non-GPL-compatible code.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
- Original Message - From: Thomas Bushnell, BSG [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: debian-legal@lists.debian.org Sent: Thursday, January 03, 2002 9:10 PM Subject: Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license [EMAIL PROTECTED] writes: I am sorry that I upset you. I am not saying that I am totally confused, nor that I read the right stuff. It is interesting that you claim that I think that you know better than me, and even more interesting that you claim that I think that you are ignorant. If there is a more appropriate forum to learn the legal significance of debian development and whether it is something that I can believe in and share with others, I am very interested in finding out. If you want to decide whether you can believe in it, I would recommend you take a look at www.gnu.org/philosophy. That's much better than posting questions which amount to gee, I wonder whether there's a way to get around the GPL. The short answer is: as far as we know, no. The medium-long answer is: as far as we know, no; if there is something that does get around it, we want to know, in such a way that we can fix it without it being exploitet, so post your question somewhere less public. The long answer is: Here are a jillion things that people have dreamed up, and I can address them one at a time. I'm not willing to do the long one. I'm willing to do the short one: there, done. If you are not just trolling, then post a real-world case, involving software, and someone (maybe even me) can explain the application of the GPL to your case. This seems like a more reasonable response. Thank you for your time. Your last suggestion seems contrary to your suggestion to post your question somewhere less public. I guess that is the nature of the beast. Best regards, Lloyd __ Get your FREE personalized e-mail at http://www.canada.com
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] writes: I do not really understand why, I guess accepting it in the definition of derivative work is the basis, but I cannot help, but wonder as I have not seen legal challanges that support this. It's a perfectly normal case of a derivative work. When you link program A with program B, you are creating a derivative work, A+B. You can only distribute that work if the licenses of A and B permit it. I also do not understand why GNU has to have contributers sign legal pagers if GPL works. The FSF asks people to assign their work to the FSF because only the copyright owner is legally allowed to sue for copyright infringement. If the FSF has the copyright, then it can do so without a great deal of hassle. The FSF also requires that contributors to GNU software affirm that they have the right to license those changes under the GPL. How do either of these suggest that someone thinks the GPL doesn't work? I guess I am just concerned for free software. Rght. What does that mean? What is your concern, actually?
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] writes: Your last suggestion seems contrary to your suggestion to post your question somewhere less public. I guess that is the nature of the beast. It's the difference between real-world cases that people should understand, and hypothetical rambling about possible things that haven't happened and are unlikely to.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
Scripsit [EMAIL PROTECTED] If a library's interface is implemented to a standard or similar, than someone linking to a GPL library version should be alright, no? This and related questions have been the subject of long and tedious flamewars on debian-legal, complete with a) Discussions about where the line ought to be drawn between incorporating a GPL'ed program and simply using it, from actually pasting source code between .c files, over several technical variations of linking, to system(3) calls and even weirder tricks. b) Discussions about which, if any, difference it ought to make that the GPL'ed program implements an interface for which alternative implementations exist (respectively, can be imagined). c) Discussions about which ways the answers to (a) and (b) ought to be rationalized with legal theory. d) All and any of the above, with ought to replaced with is actually at present, in the opinion of the courts of this and that specific jurisdiction. e) Silly clueless people who cannot distinguish properly between the is and the ought subthreads. f) Universal agreement that such silly clueless people take part in the discussions; equally universal disagreement about who they are. g) Car analogies. (Yeah, and literature analogies, too.) h) As a matter of course, utter lack of eventual consensus. You'll find it all in the list archives. Luckily nobody seems to be much inclined to restart the flamewars just now, but if you insist on trying nevertheless, please at least do us the favor of going to the archives and read the past incarnations to make reasonably sure that whatever you feel like contributing is actually *new* and not just a reiteration of arguments that are known empirically to move nobody's opinion. -- Henning Makholm The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning.
