Re: GPL-licensed packages with depend-chain to OpenSSL
On Tue, Sep 21, 2004 at 05:13:47PM -0400, Nathanael Nerode wrote: > Consider bash + script X + glibc -- this is mere aggregation. This doesn't seem to be an interesting example. Most scripts are so trivial, that [at least in the u.s.] they fall under fair use. I've never seen a bash-specific script distributed under a license which had terms which conflict with the GPL -- let alone one where the bash-specific script had more than fair-use code which depended on bash. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
Raul Miller wrote: > On Tue, Sep 21, 2004 at 04:32:17PM -0400, Nathanael Nerode wrote: >> Well, then the question is, is that combined program a derived work of >> the GPLed program? >> >> If it consists of two pieces: the GPLed program and the OpenSSL library >> -- and each exists and is fully functional without the other -- and >> neither is a derived work of the other -- >> >> Then in that case we don't have a derived work, we have an aggregated >> work or a collected work or some such. > > I'm not sure where you're going with this. > > Would you claim that copyright holders do not have the right to determine > whether or not a collected work includes their copyrighted material? No. > If not, would you claim that in the absence of an explicit license to > incorporate that copyrighted material in that collected work, that the > collected work may legally include the material? No. > If you're not claiming either of these, are you claiming that the GPL's > "mere aggregation" clause is intended to cover cases where the collective > pieces are designed to work together as a Program? Yes. Or at any rate where they can work together as a program, through freely implementable interfaces. (If they are 'designed to work together' in such a way that they aren't cleanly separable, then the conditions I suggested do not apply, of course.) Consider bash + script X + glibc -- this is mere aggregation. -- This space intentionally left blank.
Re: GPL-licensed packages with depend-chain to OpenSSL
On Tue, Sep 21, 2004 at 04:32:17PM -0400, Nathanael Nerode wrote: > Well, then the question is, is that combined program a derived work of the > GPLed program? > > If it consists of two pieces: the GPLed program and the OpenSSL library -- > and each exists and is fully functional without the other -- and neither is > a derived work of the other -- > > Then in that case we don't have a derived work, we have an aggregated work > or a collected work or some such. I'm not sure where you're going with this. Would you claim that copyright holders do not have the right to determine whether or not a collected work includes their copyrighted material? If not, would you claim that in the absence of an explicit license to incorporate that copyrighted material in that collected work, that the collected work may legally include the material? If you're not claiming either of these, are you claiming that the GPL's "mere aggregation" clause is intended to cover cases where the collective pieces are designed to work together as a Program? Thanks, -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
Raul Miller wrote: >> On Sep 9, 2004, at 23:36, Glenn Maynard wrote: >> > The GPL requires that all derived works be entirely available under the >> > terms of the GPL. > > On Fri, Sep 10, 2004 at 08:35:59AM -0400, Anthony DeRobertis wrote: >> Yes, but OpenSSL wouldn't be a derived work of the GPL program (it >> can't be, because it was created before the GPL program). > > Irrelevant: > > The derived works in question isn't OpenSSL, the question is about the > program which includes both the GPLed program and the OpenSSL library. Ah. Well, then the question is, is that combined program a derived work of the GPLed program? If it consists of two pieces: the GPLed program and the OpenSSL library -- and each exists and is fully functional without the other -- and neither is a derived work of the other -- Then in that case we don't have a derived work, we have an aggregated work or a collected work or some such. -- This space intentionally left blank.
Re: GPL-licensed packages with depend-chain to OpenSSL
Raul Miller <[EMAIL PROTECTED]> schrieb/wrote: >> Raul Miller <[EMAIL PROTECTED]> schrieb/wrote: >>> Ok, you're right -- while copyright law makes no specific provisions >>> about how the copy arrives,... > On Sun, Sep 12, 2004 at 02:27:00PM +0200, Claus Färber wrote: >> That's plain wrong. Copyright law restricts actions related to a >> copyrighted work, not results. > Cite? Berne Convention, Art. 8 to 14. Directive 2001/29/EG, Art. 3 and 4 17 USC §106 Copyright Law of Japan, Art. 22 to 28 All of these give the author the exclusive right, for example, to *make* copies. > On the flip side, consider the legal principle of contributory > infringement. Contributory infringment still relates to infringing actions to which one contributes. Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
> Raul Miller <[EMAIL PROTECTED]> schrieb/wrote: > > Ok, you're right -- while copyright law makes no specific provisions > > about how the copy arrives,... On Sun, Sep 12, 2004 at 02:27:00PM +0200, Claus Färber wrote: > That's plain wrong. Copyright law restricts actions related to a > copyrighted work, not results. Cite? On the flip side, consider the legal principle of contributory infringement. [Do a google search if you don't know what I'm talking about.] > > the copyright license can [and often does] make such provisions. > > Which copyright license? Whichever one is imposing conditions on who is licensed or not. > In many countries you don't get a license if you buy standard software > and you don't need one to use the product. Ok, so let's talk about the U.S. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sun, Sep 12, 2004 at 04:54:00PM +0200, Claus Färber wrote: > They don't share a common ABI for other programs. This isn't interesting. Either a work is normally distributed as part of the system, or it's not; multiple implementations of an ABI don't affect that. You repeatedly ignore the important question, though. > That doesn't matter, though. Debian is never eligible to use the "operating > system" exception, due to "unless that component itself accompanies the > executable". > How is the relevant? The GPL OS exception, again, is not available > to Debian. Since you won't say how it's relevant, I'm assuming it's irrelevant and won't waste further time with this subthread. -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
Glenn Maynard <[EMAIL PROTECTED]> schrieb/wrote: > On Sun, Sep 05, 2004 at 08:56:00PM +0200, Claus Färber wrote: >> Well, if you have different choices even on a single operating >> system, this is an *indication* that it's not a part of the software >> distributed but a component of the execution environment. > There's no connection at all. Debian has multiple choices for bible > study software and Doom. They don't share a common ABI for other programs. The interface used between two software programs is the crucial factor for the decision whether they form a single product with multiple modules or different products that can just "talk" to each other. Multiple different implementations of the same interface are an indication that the interface is more generic and this, in turn, means that they are more likely to have to be considered separate products. (If they are separate, it does not actually matter if the other product is part of the operating system or just any other product; however it often will be the OS.) Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
Raul Miller <[EMAIL PROTECTED]> schrieb/wrote: > Ok, you're right -- while copyright law makes no specific provisions > about how the copy arrives,... That's plain wrong. Copyright law restricts actions related to a copyrighted work, not results. > the copyright license can [and often does] make such provisions. Which copyright license? In many countries you don't get a license if you buy standard software and you don't need one to use the product. Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sun, Sep 12, 2004 at 03:06:55AM -0400, Anthony DeRobertis wrote: > Not really. A having Depends: B doesn't always imply that B is a module > contained in A. Only an examination of the actual relationship between > the GPL-licensed programs in A and the contents of B prove that > relation. I agree with this. Thanks, -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 10, 2004, at 22:31, Raul Miller wrote: Assuming there was infringement, etc. Which would be the case for the context explicitly stated in the subject line of this message. Not really. A having Depends: B doesn't always imply that B is a module contained in A. Only an examination of the actual relationship between the GPL-licensed programs in A and the contents of B prove that relation.
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 11, 2004, at 00:29, Raul Miller wrote: In that context, there are cases where Debian is distributing a program where some of the source is GPL licensed, and some of the source has more restrictive terms. Let me repeat my more Debian-relevant point, that was somehow glossed over. This is copied verbatim from the message: I wrote: (a) Being in the same shared memory space is not a sane criterion for being a module contained in a program. For example, _everything_ runs in a shared address space on, e.g., Mac OS 9.x and earlier. The same applies to various embedded platforms (does it apply to uClinux, I wonder?) I propose that a requisite of BAR being a module contained in FOO is that FOO in some way use BAR. If we use this test, it has been stated that in this particular case the program does not ever make use of OpenSSL. Thus FOO in no way uses BAR. And, to reiterate, GPL (3) defines complete source code for executables as "... all the source code for all modules it contains" So if FOO doesn't contain BAR, then we aren't required by FOO's license to distribute BAR's source code.
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 10, 2004, at 22:25, Raul Miller wrote: On Fri, Sep 10, 2004 at 08:36:23PM -0400, Anthony DeRobertis wrote: Please read the start of this subthread; the point was about distributing as _source_ and compiling on the user's machine. The program in source form does not include OpenSSL. In which case there would be no mention of OpenSSL in this thread. Not really; this sub-thread was started by me in <[EMAIL PROTECTED]>.
Re: GPL-licensed packages with depend-chain to OpenSSL
> > If more than one person is involved in making those copies the individuals > > who contributed towards making those copies can still be nailed for > > contributory infringement. On Fri, Sep 10, 2004 at 08:37:11PM -0700, Ken Arromdee wrote: > In order to have contributory infringement, there must be direct infringement. > In this scenario, nobody is committing direct infringement. Since you've not defined a scenario, I'll assume you're talking about the one mentioned in the subject line. In that context there is direct infringement, at least some of the time: In that context, there are cases where Debian is distributing a program where some of the source is GPL licensed, and some of the source has more restrictive terms. Because of the way apt works, at least some of the time these accompany each other. [Though, granted, not always.] -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, 10 Sep 2004, Raul Miller wrote: > Under copyright law, the precise details of how the copy arrives doesn't > matter. What matters is that the copy arrives. Under many circumstances it doesn't matter. However, if the license prohibits one method of arrival but not another method of arrival, then it does matter, and it is then possible for identical outcomes to be illegal or legal depending on the series of steps used to reach them. It's like a license which says "you can copy this except on Sunday". Assume today is Sunday. You can make a copy, wait a day, and give me the copy. You can also wait a day first, then make a copy, then give it to me. The exact same outcome, but one is legal and one is not--and the only difference is that two steps were done in a different order. Saying that you can't distribute a derived work is like saying you can't distribute on Sunday--it matters greatly whether you do "derive the work, then distribute" or "distribute the work, then derive". > If more than one person is involved in making those copies the individuals > who contributed towards making those copies can still be nailed for > contributory infringement. In order to have contributory infringement, there must be direct infringement. In this scenario, nobody is committing direct infringement.
Re: GPL-licensed packages with depend-chain to OpenSSL
> On Sep 10, 2004, at 18:13, Raul Miller wrote: > > Under copyright law, the precise details of how the copy arrives > > doesn't matter. On Fri, Sep 10, 2004 at 08:48:54PM -0400, Anthony DeRobertis wrote: > Yes it does. Consider the difference between a copy of Windows arriving > by being downloaded from Kazaa and by being purchased from Microsoft. Ok, you're right -- while copyright law makes no specific provisions about how the copy arrives, the copyright license can [and often does] make such provisions. > > What matters is that the copy arrives. If many people are > > getting copies of some work then that's a copyright issue. > > Millions of people have a copy of the linux kernel, yet there is no > copyright issue. They have legal copies of the linux kernel. The issue of legality is indeed a copyright issue. > > If more than one person is involved in making those copies the > > individuals who contributed towards making those copies can still > > be nailed for contributory infringement. > > Assuming there was infringement, etc. Which would be the case for the context explicitly stated in the subject line of this message. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 08:36:23PM -0400, Anthony DeRobertis wrote: > Please read the start of this subthread; the point was about > distributing as _source_ and compiling on the user's machine. The > program in source form does not include OpenSSL. In which case there would be no mention of OpenSSL in this thread. > Under GPL Section 2, derivative work is quite important. I think you've confused a specific case with the general case. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 10, 2004, at 18:13, Raul Miller wrote: On Fri, Sep 10, 2004 at 02:46:52PM -0700, Steve Langasek wrote: Why? The plain-English meaning of the phrase "accompanies the executable" would imply no such thing, and would in fact appear to be contrary to the intent of this part of the license. Under copyright law, the precise details of how the copy arrives doesn't matter. Yes it does. Consider the difference between a copy of Windows arriving by being downloaded from Kazaa and by being purchased from Microsoft. What matters is that the copy arrives. If many people are getting copies of some work then that's a copyright issue. Millions of people have a copy of the linux kernel, yet there is no copyright issue. Copyright holders _OFTEN_ allow certain methods of making & distributing copies and disallow others. It can be "only if you give me $$$", "only if you distribute source code as well", etc. We must therefor analyze the actions involved in the copying, as some may be allowed by fair use, some by licenses, etc. If more than one person is involved in making those copies the individuals who contributed towards making those copies can still be nailed for contributory infringement. Assuming there was infringement, etc. Now, ok, if even though you're distributing Emacs linked against OpenSSL, no one is winding up with copies of Emacs + OpenSSL, that wouldn't be infringing. And if they are, it isn't infringing either --- the GPL explicitly allows this. As long as you didn't distribute them both alongside each other.
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 10, 2004, at 17:15, Raul Miller wrote: On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote: So, you don't need an extreme example. It's perfectly valid for one to take Emacs, link it against OpenSSL, and distribute binaries, as long as OpenSSL doesn't accompany it. In the U.S., at least, "linking it against OpenSSL" probably counts as "accompanying it", even if the binaries for the OpenSSL library do not appear on the same distribution media as the binaries for Emacs. Why? This only becomes a problem when Debian, or some other OS distributor, wants to distribute those binaries. Can you name any legal principles (or cite any court precedents) to back up your point of view? Ummm, this is a specific clause of the GPL. Please go read GPL (3) again. Notice the exception for things that normally come with an OS; and the caveat on that exception that it isn't valid they accompany the (GPL'd) executable.
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 10, 2004, at 09:08, Raul Miller wrote: On Sep 9, 2004, at 23:36, Glenn Maynard wrote: The GPL requires that all derived works be entirely available under the terms of the GPL. On Fri, Sep 10, 2004 at 08:35:59AM -0400, Anthony DeRobertis wrote: Yes, but OpenSSL wouldn't be a derived work of the GPL program (it can't be, because it was created before the GPL program). Irrelevant: The derived works in question isn't OpenSSL, the question is about the program which includes both the GPLed program and the OpenSSL library. Please read the start of this subthread; the point was about distributing as _source_ and compiling on the user's machine. The program in source form does not include OpenSSL. Under GPL Section 2, derivative work is quite important.
Re: GPL-licensed packages with depend-chain to OpenSSL
> > This case is largely irrelevant unless we'll distribute a version of > > emacs with MSVCRT in its depend tree. On Fri, Sep 10, 2004 at 08:11:29PM -0400, Glenn Maynard wrote: > If you build in Windows, you link against MSVCRT; it's libc. This is > very relevant to what users do with the software. Which is not the same thing as being relevant to Debian, nor the same as being relevant to this current thread. That said, if you want to talk about linking in the concept of WINE, that would be different. Anyways, I'm ignoring the rest of your message because of a mistake I made and most of your response being tangential to any remaining valid bits I had to say. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 07:31:13PM -0400, Raul Miller wrote: > On Fri, Sep 10, 2004 at 06:53:49PM -0400, Glenn Maynard wrote: > > Microsoft creates a system library, MSVCRT (Microsoft Visual C runtime), > > which is used by almost all binaries which run on Windows. It's GPL- > > incompatible.[1] > > This case is largely irrelevant unless we'll distribute a version of > emacs with MSVCRT in its depend tree. If you build in Windows, you link against MSVCRT; it's libc. This is very relevant to what users do with the software. > > (On careful re-reading of the exception, I'm not completely sure whether > > the exception allows this or not: it exempts me from needing to provide > > source > > for those libraries, but I'm not sure if it exempts it from compatibility. > > I'll probably ask the FSF, since this is a critical question.) > > It's the source code which needs to be licensed under the terms of the > GPL -- since that exception sometimes excludes some system stuff from > the source code, the excluded stuff doesn't need to be licensed under > the terms of the GPL. The binary must also, according to "... in object code or executable form under the terms of Sections 1 and 2 above", though. 2b requires that it be licensed under the terms of the GPL. > > Regardless of that, if linking counts as "accompanies", this exception > > would be a complete no-op, and you'd have to distribute the glibc source > > along with every GPL application that links against glibc. > > A word used with conditions attached has a more specific meaning than > the same word used without those conditions attached. You said: > In the U.S., at least, "linking it against OpenSSL" probably counts as > "accompanying it", even if the binaries for the OpenSSL library do not > appear on the same distribution media as the binaries for Emacs. My reply is unchanged: If linking counts as "accompanies", this exception would be a complete no-op, and you'd have to distribute the glibc source along with every GPL application that links against glibc. Here's a tip: stop with the attempts at clever-sounding retorts, and instead make an effort to reply clearly. If you had said what condition you were referring to, and how that condition is related to my reply, then this discussion would be further along than it is now. -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 07:31:13PM -0400, I wrote: > In the context of that exception, a distinction has already been drawn > to distinguish between stuff that comes with the system and the rest of > the program. > > It's a mistake to claim that the exception applies to the rest of the > license just because it uses some of the same words, not arranged the > same way. Since I messed up on part of my argument, I figured I should revisit this statement too. The GPL uses forms of the word "accompany" four times. In the first three, it's requiring that something accompany the binary. In the last case it's prohibiting certain things from accompanying the binary. The sorts of conditions you need to guarantee accompaniment happens (what you need in the first three cases) are different from the sort of condition you need to guarantee that something doesn't accompany. In particular, the absence of a guarantee is not a guarantee of absence. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
I need to revist this response. > On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote: > > So, you don't need an extreme example. It's perfectly valid for one to > > take Emacs, link it against OpenSSL, and distribute binaries, as long as > > OpenSSL doesn't accompany it. On Fri, Sep 10, 2004 at 05:15:04PM -0400, Raul Miller wrote: > In the U.S., at least, "linking it against OpenSSL" probably counts as > "accompanying it", even if the binaries for the OpenSSL library do not > appear on the same distribution media as the binaries for Emacs. Ok, re-reading the GPL, I was wrong about this. That said, you left some important conditions out of your "perfectly valid" statement. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 05:40:00PM -0400, Glenn Maynard wrote: > > > Huh? Are you claiming that the OS exception doesn't allow linking against > > > GPL-incompatible system libraries? On Fri, Sep 10, 2004 at 06:16:51PM -0400, Raul Miller wrote: > > It's meaningless to ask that question without specifying who is doing > > the linking and who provided those libraries. The answer is different > > depending on who... On Fri, Sep 10, 2004 at 06:53:49PM -0400, Glenn Maynard wrote: > Microsoft creates a system library, MSVCRT (Microsoft Visual C runtime), > which is used by almost all binaries which run on Windows. It's GPL- > incompatible.[1] This case is largely irrelevant unless we'll distribute a version of emacs with MSVCRT in its depend tree. > John creates Emacs. > > I compile Emacs in VC, to run in Windows. The result is a binary which > uses an GPL-incompatible system C library. > > I believe the OS exception in the GPL allows me to distribute that binary, > but disallows Microsoft from distributing it along with Windows. > > You claim that linking against that library counts as "accompanies", which > would prohibit the above. In the context of that exception, a distinction has already been drawn to distinguish between stuff that comes with the system and the rest of the program. It's a mistake to claim that the exception applies to the rest of the license just because it uses some of the same words, not arranged the same way. > (On careful re-reading of the exception, I'm not completely sure whether > the exception allows this or not: it exempts me from needing to provide source > for those libraries, but I'm not sure if it exempts it from compatibility. > I'll probably ask the FSF, since this is a critical question.) It's the source code which needs to be licensed under the terms of the GPL -- since that exception sometimes excludes some system stuff from the source code, the excluded stuff doesn't need to be licensed under the terms of the GPL. > Regardless of that, if linking counts as "accompanies", this exception > would be a complete no-op, and you'd have to distribute the glibc source > along with every GPL application that links against glibc. A word used with conditions attached has a more specific meaning than the same word used without those conditions attached. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 06:16:51PM -0400, Raul Miller wrote: > On Fri, Sep 10, 2004 at 05:40:00PM -0400, Glenn Maynard wrote: > > Huh? Are you claiming that the OS exception doesn't allow linking against > > GPL-incompatible system libraries? > > It's meaningless to ask that question without specifying who is doing > the linking and who provided those libraries. The answer is different > depending on who... Microsoft creates a system library, MSVCRT (Microsoft Visual C runtime), which is used by almost all binaries which run on Windows. It's GPL- incompatible.[1] John creates Emacs. I compile Emacs in VC, to run in Windows. The result is a binary which uses an GPL-incompatible system C library. I believe the OS exception in the GPL allows me to distribute that binary, but disallows Microsoft from distributing it along with Windows. You claim that linking against that library counts as "accompanies", which would prohibit the above. (On careful re-reading of the exception, I'm not completely sure whether the exception allows this or not: it exempts me from needing to provide source for those libraries, but I'm not sure if it exempts it from compatibility. I'll probably ask the FSF, since this is a critical question.) Regardless of that, if linking counts as "accompanies", this exception would be a complete no-op, and you'd have to distribute the glibc source along with every GPL application that links against glibc. [1] actually, I'm not absolutely sure of this because I can't find the redistributables license, but there are plenty of other libraries in this class on Windows, so I'm assuming it for the sake of discussion -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
> > I certainly don't see the GPL talking about the issue of shipping some > > bits of a program on one day through distributor A and other bits of the > > program on another day through distributor B. On Fri, Sep 10, 2004 at 03:58:16PM -0700, Steve Langasek wrote: > If distributor A is distributing an operating system, it certainly does. And if you add enough other conditions it's talking about other things, too. However, in the context of the subject line, we're talking about Debian dependencies. So both distributors are distributing the same operating system, and the case you're talking about doesn't apply. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 06:50:28PM -0400, Raul Miller wrote: > On Fri, Sep 10, 2004 at 03:38:19PM -0700, Steve Langasek wrote: > > Huh? There is no copyright infringement here because *the GPL > > explicitly allows this form of distribution*. > I was talking about the relationship of copyright law to some distribution > mechanics. > The GPL allows distribution under certain circumstances, but those > allowances are mostly tangential to the mechanisms I was talking about. > I certainly don't see the GPL talking about the issue of shipping some > bits of a program on one day through distributor A and other bits of the > program on another day through distributor B. If distributor A is distributing an operating system, it certainly does. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 03:38:19PM -0700, Steve Langasek wrote: > Huh? There is no copyright infringement here because *the GPL > explicitly allows this form of distribution*. I was talking about the relationship of copyright law to some distribution mechanics. The GPL allows distribution under certain circumstances, but those allowances are mostly tangential to the mechanisms I was talking about. I certainly don't see the GPL talking about the issue of shipping some bits of a program on one day through distributor A and other bits of the program on another day through distributor B. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 06:13:53PM -0400, Raul Miller wrote: > On Fri, Sep 10, 2004 at 02:46:52PM -0700, Steve Langasek wrote: > > Why? The plain-English meaning of the phrase "accompanies the > > executable" would imply no such thing, and would in fact appear to be > > contrary to the intent of this part of the license. > Under copyright law, the precise details of how the copy arrives doesn't > matter. What matters is that the copy arrives. If many people are > getting copies of some work then that's a copyright issue. > If more than one person is involved in making those copies the individuals > who contributed towards making those copies can still be nailed for > contributory infringement. > If the law excused cases where some of the bits arrived on a different > cdrom or a on different day, or encoding using a different algorithm or > any such thing if for some systematic reason that's all sorted out for the > user, then all you'd have to do is break any work down into individual > bits (or small groups of them, as fair use allows), transmit those bits > separately (using whatever this delivery mechanism is, that gets around > copyright) and presto -- that work is no longer protected by copyright. Huh? There is no copyright infringement here because *the GPL explicitly allows this form of distribution*. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 05:40:00PM -0400, Glenn Maynard wrote: > Huh? Are you claiming that the OS exception doesn't allow linking against > GPL-incompatible system libraries? It's meaningless to ask that question without specifying who is doing the linking and who provided those libraries. The answer is different depending on who... -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 02:46:52PM -0700, Steve Langasek wrote: > Why? The plain-English meaning of the phrase "accompanies the > executable" would imply no such thing, and would in fact appear to be > contrary to the intent of this part of the license. Under copyright law, the precise details of how the copy arrives doesn't matter. What matters is that the copy arrives. If many people are getting copies of some work then that's a copyright issue. If more than one person is involved in making those copies the individuals who contributed towards making those copies can still be nailed for contributory infringement. If the law excused cases where some of the bits arrived on a different cdrom or a on different day, or encoding using a different algorithm or any such thing if for some systematic reason that's all sorted out for the user, then all you'd have to do is break any work down into individual bits (or small groups of them, as fair use allows), transmit those bits separately (using whatever this delivery mechanism is, that gets around copyright) and presto -- that work is no longer protected by copyright. In other words, when talking about "distribution" in the context of copy you have to be talking about the copy that gets distributed, not just the technical details of how the distribution works. At least... that's the way it works in the U.S. I don't know about other countries. Now, ok, if even though you're distributing Emacs linked against OpenSSL, no one is winding up with copies of Emacs + OpenSSL, that wouldn't be infringing. But that's kind of like driving off a cliff without hitting the ground (possible, but not the typical case). -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 05:15:04PM -0400, Raul Miller wrote: > On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote: > > So, you don't need an extreme example. It's perfectly valid for one to > > take Emacs, link it against OpenSSL, and distribute binaries, as long as > > OpenSSL doesn't accompany it. > > In the U.S., at least, "linking it against OpenSSL" probably counts as > "accompanying it", even if the binaries for the OpenSSL library do not > appear on the same distribution media as the binaries for Emacs. Huh? Are you claiming that the OS exception doesn't allow linking against GPL-incompatible system libraries? I've always found that to be a major part of its purpose; otherwise, it would be impossible to eg. distribute GPL Windows applications at all--libc, GUI libraries, etc. are all GPL-incompatible. If you disagree, we might have to punt to the FSF yet again. This is a critical question to me, since I'm involved in a project that makes use of a GPL library which runs in Windows. (Of course, another, simpler reason for the exception is so you don't have to include the glibc source with every GPL program.) -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 05:15:04PM -0400, Raul Miller wrote: > On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote: > > So, you don't need an extreme example. It's perfectly valid for one to > > take Emacs, link it against OpenSSL, and distribute binaries, as long as > > OpenSSL doesn't accompany it. > In the U.S., at least, "linking it against OpenSSL" probably counts as > "accompanying it", even if the binaries for the OpenSSL library do not > appear on the same distribution media as the binaries for Emacs. Why? The plain-English meaning of the phrase "accompanies the executable" would imply no such thing, and would in fact appear to be contrary to the intent of this part of the license. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote: > So, you don't need an extreme example. It's perfectly valid for one to > take Emacs, link it against OpenSSL, and distribute binaries, as long as > OpenSSL doesn't accompany it. In the U.S., at least, "linking it against OpenSSL" probably counts as "accompanying it", even if the binaries for the OpenSSL library do not appear on the same distribution media as the binaries for Emacs. > This only becomes a problem when Debian, or some other OS distributor, > wants to distribute those binaries. Can you name any legal principles (or cite any court precedents) to back up your point of view? > > Of course, another issue is: does anyone really care about this kind > > of thing? > > > > If people do, perhaps the right place to start would be to create a > > dummy package which conflicts with all packages which provide software > > only available under a gpl-compatible license. > > Do you mean GPL-incompatible? Yeah, oops. Thanks. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Sep 10, 2004 at 09:08:47AM -0400, Raul Miller wrote: > > > One piece of the resulting binary--OpenSSL--is not. > > > This seems to clearly violate the spirit of the GPL. > > > > It might, but the GPL does have the normal components of an OS > > exception, for example. And only GPL (3), not (1) or (2) mentions all > > components of the resulting binary. > > This is valid for the case where we're not shipping that derived work > with the GPL'd parts of the program. So, for an extreme example, users > writing shell scripts that include curl+ssl and some gnu utils don't > have any such issue to worry about (well, unless they're distributing > that script and running a debian mirror, or some such). I don't quite understand your example--I'm not sure if you're talking about the with-the-OS exception, "only (3) talks about binaries", or both. Also, shell scripts make for murky examples, since there's an entire separate argument about whether you're linking binaries by using a shell script and a pipe ... I think it's reasonable to consider OpenSSL part of the Debian OS (and presumably others; I assume most distributions are shipping it these days, but I wouldn't know). So, you don't need an extreme example. It's perfectly valid for one to take Emacs, link it against OpenSSL, and distribute binaries, as long as OpenSSL doesn't accompany it. This only becomes a problem when Debian, or some other OS distributor, wants to distribute those binaries. I'm not sure if the running-a-mirror case is a problem or not; the GPL doesn't define "accompanies". A similar case would be distributing the binaries on SourceForge: even if you don't include OpenSSL binaries, it's probable that some other project on SF is, which means that there are OpenSSL binaries in some other place on the same mirror. Do they accompany one another? (No, I don't think they do according to what I believe is the intent of the exception; but as for the letter of the license, I don't know.) > Of course, another issue is: does anyone really care about this kind > of thing? > > If people do, perhaps the right place to start would be to create a > dummy package which conflicts with all packages which provide software > only available under a gpl-compatible license. Do you mean GPL-incompatible? -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
> On Sep 9, 2004, at 23:36, Glenn Maynard wrote: > > The GPL requires that all derived works be entirely available under the > > terms of the GPL. On Fri, Sep 10, 2004 at 08:35:59AM -0400, Anthony DeRobertis wrote: > Yes, but OpenSSL wouldn't be a derived work of the GPL program (it > can't be, because it was created before the GPL program). Irrelevant: The derived works in question isn't OpenSSL, the question is about the program which includes both the GPLed program and the OpenSSL library. > > One piece of the resulting binary--OpenSSL--is not. > > This seems to clearly violate the spirit of the GPL. > > It might, but the GPL does have the normal components of an OS > exception, for example. And only GPL (3), not (1) or (2) mentions all > components of the resulting binary. This is valid for the case where we're not shipping that derived work with the GPL'd parts of the program. So, for an extreme example, users writing shell scripts that include curl+ssl and some gnu utils don't have any such issue to worry about (well, unless they're distributing that script and running a debian mirror, or some such). Of course, another issue is: does anyone really care about this kind of thing? If people do, perhaps the right place to start would be to create a dummy package which conflicts with all packages which provide software only available under a gpl-compatible license. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 9, 2004, at 23:36, Glenn Maynard wrote: First off, I made up this example quickly to try and illustrate that looking at the end result is not enough; that we need to examine the steps that got us there. Hopefully, -legal will consider and respond to the other point made in my previous post as well. As an example, I think distributing a package which downloaded FOO source code and compiles it --- on the user's machine --- with OpenSSL might be fine, as we'd be distributing under GPL 2 (or even GPL 1), and GPL 2 doesn't require source to all modules contained in the program (only to the program and works based on it, which OpenSSL clearly isn't). The GPL requires that all derived works be entirely available under the terms of the GPL. Yes, but OpenSSL wouldn't be a derived work of the GPL program (it can't be, because it was created before the GPL program). One piece of the resulting binary--OpenSSL--is not. This seems to clearly violate the spirit of the GPL. It might, but the GPL does have the normal components of an OS exception, for example. And only GPL (3), not (1) or (2) mentions all components of the resulting binary. I have no idea how this would fare in court, It seems quite allowed by the plain language of the GPL. Also, if we were to put a binary in a special section on separate servers, that'd be allowed under the normal components exception to (3). but I hope we agree that this would not be an acceptable thing for Debian to do. (I don't know if by "fine" you mean "legally fine" or "actually fine".) I agree it is not something Debian should be doing. For one thing, we should (when at all reasonable) respect upstream's wishes; for another, not being able to distribute binaries violates the DFSG. It's also probably more risky because even if the GPL allows it, a lot of people probably don't realize it.
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Sep 09, 2004 at 10:55:38PM -0400, Anthony DeRobertis wrote: > (b) The method is what must be analyzed, not the end result. As a > trivial example, take the end result of having Microsoft Windows > installed on a PC. A legal contraption to do that would be to go to > your local computer store and buy a copy. An illegal contraption to > do that would be Kazaa. > > As an example, I think distributing a package which downloaded FOO > source code and compiles it --- on the user's machine --- with OpenSSL > might be fine, as we'd be distributing under GPL 2 (or even GPL 1), and > GPL 2 doesn't require source to all modules contained in the program > (only to the program and works based on it, which OpenSSL clearly > isn't). The GPL requires that all derived works be entirely available under the terms of the GPL. One piece of the resulting binary--OpenSSL--is not. This seems to clearly violate the spirit of the GPL. I don't know if the actual mechanism here is infringing. This is really just a case of the "distribute only source code, avoiding disributing binaries, to circumvent some of the GPL's requirements" "loophole", which we've discussed here several times, I think. I have no idea how this would fare in court, but I hope we agree that this would not be an acceptable thing for Debian to do. (I don't know if by "fine" you mean "legally fine" or "actually fine".) -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
On Mon, Sep 06, 2004 at 02:38:30PM -0400, Brian Thomas Sniffen wrote: > But it'll link against lubcurl-ssl, which we also put on the user's > machine. It doesn't matter how complicated the contraption for > getting some program with libcurl-ssl and openssl into a shared memory > space on an end user's machine is -- it's still a contraption for > distributing that final work. (a) Being in the same shared memory space is not a sane criterion for being a module contained in a program. For example, _everything_ runs in a shared address space on, e.g., Mac OS 9.x and earlier. The same applies to various embedded platforms (does it apply to uClinux, I wonder?) I propose that a requisite of BAR being a module contained in FOO is that FOO in some way use BAR. If we use this test, it has been stated that in this particular case the program does not ever make use of OpenSSL. Thus FOO in no way uses BAR. (b) The method is what must be analyzed, not the end result. As a trivial example, take the end result of having Microsoft Windows installed on a PC. A legal contraption to do that would be to go to your local computer store and buy a copy. An illegal contraption to do that would be Kazaa. As an example, I think distributing a package which downloaded FOO source code and compiles it --- on the user's machine --- with OpenSSL might be fine, as we'd be distributing under GPL 2 (or even GPL 1), and GPL 2 doesn't require source to all modules contained in the program (only to the program and works based on it, which OpenSSL clearly isn't).
Re: GPL-licensed packages with depend-chain to OpenSSL
On Tue, Sep 07, 2004 at 07:57:06PM +0100, Andrew Suffield wrote: > On Tue, Sep 07, 2004 at 05:34:29PM +, Joel Baker wrote: > > On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote: > > > On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote: > > > > > > > and of course that any document > > > > written in Microsoft Word is derived from Word. > > > > > > I can use a word document without a copy of word, these days. There > > > are at least half a dozen other things that can work with them. > > > > Perhaps I am misunderstanding, but by this argument, wouldn't the fact that > > "can link against libcurl with GNU TLS, libcurl with OpenSSL, or libcurl > > with no SSL at all" qualify it as mere aggregation - if the dividing point > > is that multiple implementations, at least some of which are Free, can be > > used with it? > > Maybe. You have implicitly introduced the notion that these three > variations on libcurl are distinct, and I'm just not sure about > that. This transitive option stuff is murky. Perhaps; IMO, a transitive API (that is, an API which provides a thin veneer over other APIs, such as Curl's SSL API) falls under one of two cases: 1) It is, itself, an API barrier beyond which the program cannot "see", and which means the license of the transitive API governs whether it can be used with GPL code. or 2) It "passes through" to the API which *it* calls, and the licensing of any / all implementations of that API distributed come into play. There are some "smell of the wind" tests one could propose to decide between case 1 and case 2, the foremost I can think of having to do with how similar the APIs are (that is, how "thick" the veneer is - panelling, or a two foot wall?), but for the specific instance at hand, it isn't actually necessary to decide, AFAICT. Specifically: In case 1, Curl's license governs, and as far as I understand, this isn't a problem at all (or the issue wouldn't be so murky). In case 2, we degenerate into a situation identical to the readline library situation - multiple implementations of the API exist which can fufill the API requirements for dynamic linking. A quick review of the topic from past d-l posts, courtesy of Google, makes my head hurt a lot more than it did before I began, but the best summary I can find is that "derived work" status may be invalidated if programming to a (non-copyrightable) API, rather than to a specific implementation (modulo Debian packaging choices such as whether it Depends, Recommends, or Suggests packages with various licenses). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Tue, Sep 07, 2004 at 05:34:29PM +, Joel Baker wrote: > On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote: > > On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote: > > > > > and of course that any document > > > written in Microsoft Word is derived from Word. > > > > I can use a word document without a copy of word, these days. There > > are at least half a dozen other things that can work with them. > > Perhaps I am misunderstanding, but by this argument, wouldn't the fact that > "can link against libcurl with GNU TLS, libcurl with OpenSSL, or libcurl > with no SSL at all" qualify it as mere aggregation - if the dividing point > is that multiple implementations, at least some of which are Free, can be > used with it? Maybe. You have implicitly introduced the notion that these three variations on libcurl are distinct, and I'm just not sure about that. This transitive option stuff is murky. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote: > On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote: > > > and of course that any document > > written in Microsoft Word is derived from Word. > > I can use a word document without a copy of word, these days. There > are at least half a dozen other things that can work with them. Perhaps I am misunderstanding, but by this argument, wouldn't the fact that "can link against libcurl with GNU TLS, libcurl with OpenSSL, or libcurl with no SSL at all" qualify it as mere aggregation - if the dividing point is that multiple implementations, at least some of which are Free, can be used with it? Shades of libreadline -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > On Sep 4, 2004, at 07:55, Florian Weimer wrote: > >>> That sounds quite like "plac[ing] restrictions on other software that >>> is distributed along with the licensed software." >> >> If curl-ssl is linked to GPLed programs by default, it's not mere >> aggregation. > > But it's not linked to the programs. The programs would, of course, > Build-Depend on libcurl and Build-Conflicts with libcurl-ssl. So the > programs were dynamically linked to libcurl-nossl (or libcurl-gnutls, > or whatever). > > We then distribute source under the terms of the GPL: > > The source code for a work means the preferred form of the > work for making modifications to it. For an executable work, > complete source code means all the source code for all modules > it contains, plus any associated interface definition files, > plus the scripts used to control compilation and installation > of the executable. > > The binary of FOO we redistribute contains the module FOO, of course, > and maybe the module libcurl-nossl. We distribute the source to those > under GPL 3(a). > > If libcurl-ssl happens to be installed by default, how does that > matter then? OpenSSL is not a module of FOO because /FOO was compiled > without it/. But it'll link against lubcurl-ssl, which we also put on the user's machine. It doesn't matter how complicated the contraption for getting some program with libcurl-ssl and openssl into a shared memory space on an end user's machine is -- it's still a contraption for distributing that final work. Debian will still have built a contraption that distributes some program containing OpenSSL to an end user. -- Brian Sniffen [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Mon, Sep 06, 2004 at 01:27:56PM -0400, Anthony DeRobertis wrote: > > On Sep 4, 2004, at 18:24, Andrew Suffield wrote: > > >Can I take these two packages on the same CD and split them apart > >again, such that they are no longer aggregated, and still use them? > > > >For example, you can't (or at least couldn't, disregarding modern > >binary emulation tricks) realistically use a program linked against > >solaris libc without solaris libc. > > This smoke test suffers the problem that its determination of > 'derivative work' changes over time. That's why it's a test for aggregation, not derivation. Aggregation happens at a different time. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 4, 2004, at 07:55, Florian Weimer wrote: That sounds quite like "plac[ing] restrictions on other software that is distributed along with the licensed software." If curl-ssl is linked to GPLed programs by default, it's not mere aggregation. But it's not linked to the programs. The programs would, of course, Build-Depend on libcurl and Build-Conflicts with libcurl-ssl. So the programs were dynamically linked to libcurl-nossl (or libcurl-gnutls, or whatever). We then distribute source under the terms of the GPL: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The binary of FOO we redistribute contains the module FOO, of course, and maybe the module libcurl-nossl. We distribute the source to those under GPL 3(a). If libcurl-ssl happens to be installed by default, how does that matter then? OpenSSL is not a module of FOO because /FOO was compiled without it/. PS: the DFSG says nothing of mere aggregation, only of 'other software'.
Re: GPL-licensed packages with depend-chain to OpenSSL
It's not about derivative works at all. It's about source. You need libc and a bunch of header files to build a C program; thus, to distribute, you have to pack all those along too. Unless they're part of the OS... unless you distribute them too. It's not about copyright law's definition of derivative works, but about the GPL's statements involving "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 4, 2004, at 18:24, Andrew Suffield wrote: Can I take these two packages on the same CD and split them apart again, such that they are no longer aggregated, and still use them? For example, you can't (or at least couldn't, disregarding modern binary emulation tricks) realistically use a program linked against solaris libc without solaris libc. This smoke test suffers the problem that its determination of 'derivative work' changes over time. I'm pretty sure that a work is either created derivative or not; it can't suddenly become or cease to become derivative (other than a court clarifying the definition of 'derivative work', of course).
Re: GPL-licensed packages with depend-chain to OpenSSL
On Mon, 06 Sep 2004 09:53:35 +0100, MJ Ray <[EMAIL PROTECTED]> wrote: > On 2004-09-06 02:24:58 +0100 Joseph Lorenzo Hall <[EMAIL PROTECTED]> > wrote: > > > There are definitely implicit copyright licenses in (US) copyright > > case law. > > In general, that only concerns us if US law is the one being applied. > I don't think either GPL (for libcurl) or OpenSSL specify US law. If > it's not US law, do we still have the idea of implicit copyright > licences? That's really the beauty of the GPL... it works in over 70 different copyright regimes around the world. You'd have to ask a legal scholar in each regime about any caselaw involving implicit copyright licenses. In the US, there have been rulings like Effects Associates, Inc. v. Larry Cohen, 908 F.2d 555 (9th Cir. 1990)[1] that have established implicit nonexclusive licensing. [1] This is an especially interesting read... it starts off with, "What we have here is a failure to compensate." and concerns a dispute between a B-movie director and a special effects crew. http://www.kentlaw.edu/e-Ukraine/copyright/cases/effects_v_cohen.html Joe -- Joseph Lorenzo Hall UC Berkeley, SIMS PhD Student http://pobox.com/~joehall/
Re: GPL-licensed packages with depend-chain to OpenSSL
* Raul Miller: > On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus Färber wrote: >> They did. Solaris 9 reportedly comes with GNU tools (I can't check it >> myself because I don't have a machine running Solaris). > > You can get gnu tools for solaris from http://www.sunfreeware.com > > To my knowledge, gnu tools are not supplied on the solaris install cds. IIRC, you receive a separate CD containing pre-compiled GNU tools when you buy Solaris 9.
Re: GPL-licensed packages with depend-chain to OpenSSL
On 2004-09-06 02:24:58 +0100 Joseph Lorenzo Hall <[EMAIL PROTECTED]> wrote: There are definitely implicit copyright licenses in (US) copyright case law. In general, that only concerns us if US law is the one being applied. I don't think either GPL (for libcurl) or OpenSSL specify US law. If it's not US law, do we still have the idea of implicit copyright licences? -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
Re: GPL-licensed packages with depend-chain to OpenSSL
On Mon, Sep 06, 2004 at 02:16:00AM +0200, Claus F?rber wrote: > It ultimatly does not make sense if you can choose one of several > libraries (with different licenses) that can be dynamically linked > against a program without recompiling it. > > For example, you distribute a program linked against "libcurl". It works > with "libcurl-nossl", "libcurl-gnutls" -- but also "libcurl-ssl". Is it > linked against a GPL-incompatible library? Careful, this is not an example of a case where the GPL does not apply such restrictions. This is an example of a case where it's so damned snarly that we haven't been able to come up with a good answer yet. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
> Glenn Maynard <[EMAIL PROTECTED]> schrieb/wrote: > > This is all irrelevant. The issue is that you can't distribute GPL > > binaries *linked against* GPL-incompatible libraries. On Mon, Sep 06, 2004 at 02:16:00AM +0200, Claus Färber wrote: > It's more complicated than that when dynamic linking is involved. Maybe. > It ultimatly does not make sense if you can choose one of several > libraries (with different licenses) that can be dynamically linked > against a program without recompiling it. Maybe. > For example, you distribute a program linked against "libcurl". It works > with "libcurl-nossl", "libcurl-gnutls" -- but also "libcurl-ssl". Is it > linked against a GPL-incompatible library? Maybe. The answer to this question depends on information you've not provided. > > The operating system clause makes an exception for this, but it's not > > available when the program is packaged along with the libraries. > > The GPL does not say "packaged along with", it says "accompanied with". > The later suggests a closer relationship than mere aggregation on the > same distriution medium. True. Utterly irrelevant to the current context, but true. "Dynamically linked against a library" is certainly not the same thing as "mere aggregation" with that library. And, yes, this can be an annoying issue to deal with. > You could only claim that something is "normally" part of the os when it > is not. "What's a part of the os" is also utterly irrelevant in the current context. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
On Mon, Sep 06, 2004 at 02:16:00AM +0200, Claus Färber wrote: > Again, it is more complicated. What if you have both a free and binary- > compatible proprietory version of the os? E.g., is a Windows program > linked against the Windows DLLs if users can run it with wine? What > about Linux binaries that can run on Solaris' emulation layer? When Microsoft(tm) is distributing a GPL program along with Windows(tm), Wine doesn't enter into the equation. Microsoft is not allowed to package GNU Emacs in such a way that it's intended to link against their proprietary libraries. The existance of less clear cases (such as an OS that includes both GPL- compatible and GPL-incompatible binary-compatible library sets) doesn't change the above. > There is one big difference here: Word can not be considered a "major > component ... of the operating system". OpenSSL can. > There is no loophole to link against *any* proprietary code. As far as the GPL is concerned, OpenSSL is proprietary. You're searching for a loophole to allow Debian to distribute GPL binaries linked against the proprietary OpenSSL. > I think you'd better explain the intent of the GPL to them and ask why > they don't sue Sun or Apple. Their intent is clear. You're the one claiming that they should be suing Sun and Apple as a result, and you're the one claiming strange things about the GPL that nobody else agrees with, so the burden of asking them for clarification rests on you. I don't have time or interest to respond to everything. I'm not going to waste time arguing about the FSF's intent if you won't even ask them. -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
On 06 Sep 2004 02:54:00 +0200, Claus Färber <[EMAIL PROTECTED]> wrote: > Andrew Suffield <[EMAIL PROTECTED]> schrieb/wrote: > > On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus F?rber wrote: > >> Of course, in such simple cases, they can be thought of having given > >> implicit permission to link against OpenSSL. > > > There is no such thing as implicit permission in copyright law (or > > even contract law). That only works for verbal agreements. > > That's certainly not universally true for any legistlation. I even fail > to see how an "verbal agreement" is not covered by "contract law" even > in the UK. > > For German law, for example, my statement above is valid. There are definitely implicit copyright licenses in (US) copyright case law. Let me know if you want me to cite some cases... It usually involves someone voluntarily contributing to a larger work. For example, if I'm shooting a movie and ask you to help out and you do (fully aware of the nature of the project), you've effectively granted me an implicit license to use your contributions (to the extent that they're copyrightable) in my work. Of course, specific details can always change things in court. -- Joseph Lorenzo Hall
Re: GPL-licensed packages with depend-chain to OpenSSL
Andrew Suffield <[EMAIL PROTECTED]> schrieb/wrote: > On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus F?rber wrote: >> Of course, in such simple cases, they can be thought of having given >> implicit permission to link against OpenSSL. > There is no such thing as implicit permission in copyright law (or > even contract law). That only works for verbal agreements. That's certainly not universally true for any legistlation. I even fail to see how an "verbal agreement" is not covered by "contract law" even in the UK. For German law, for example, my statement above is valid. Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
Glenn Maynard <[EMAIL PROTECTED]> schrieb/wrote: > On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus Färber wrote: >> Brian Thomas Sniffen <[EMAIL PROTECTED]> schrieb/wrote: If we follow this interpretation, this means that you can't distribute an closed source OS with GPL tools. IMO, this was not the intention of the GPL authors. If you have to distribute the component with the GPL software, this is a sign that it's not universally available on the operating system. However, if you are distributing an OS... >> >>> That was *exactly* the intent of the GPL authors: to prevent Sun from >>> distributing the GNU tools with Solaris. They do distribute them >>> separately. >> >> They did. Solaris 9 reportedly comes with GNU tools (I can't check it >> myself because I don't have a machine running Solaris). >> >> I can't find anything on the FSF's homepage that says you can't distri- >> bute GNU tools with non-GPL operating systems. Further, I can't find an > This is all irrelevant. The issue is that you can't distribute GPL > binaries *linked against* GPL-incompatible libraries. It's more complicated than that when dynamic linking is involved. It ultimatly does not make sense if you can choose one of several libraries (with different licenses) that can be dynamically linked against a program without recompiling it. For example, you distribute a program linked against "libcurl". It works with "libcurl-nossl", "libcurl-gnutls" -- but also "libcurl-ssl". Is it linked against a GPL-incompatible library? > A vendor can't distribute a GPL binary for its operating system if its > libc, or any other library used by the GPL binary, is GPL- > incompatible. Again, it is more complicated. What if you have both a free and binary- compatible proprietory version of the os? E.g., is a Windows program linked against the Windows DLLs if users can run it with wine? What about Linux binaries that can run on Solaris' emulation layer? I think you can make a good case that in all of these examples, the library and and actual programs should be considered separate works, even though they use dynamic linking. > The operating system clause makes an exception for this, but it's not > available when the program is packaged along with the libraries. The GPL does not say "packaged along with", it says "accompanied with". The later suggests a closer relationship than mere aggregation on the same distriution medium. > It is *not* intended to allow OS vendors (Microsoft, Debian) to link > GPL applications against whatever proprietary code (such as Word or > OpenSSL, which are both "proprietary" as far as the GPL is concerned) > they wish. There is one big difference here: Word can not be considered a "major component ... of the operating system". OpenSSL can. There is no loophole to link against *any* proprietary code. > The "accompanies the executable" restriction exists to close this > loophole. You could only claim that something is "normally" part of the os when it is not. IOW: Having to distribute a component with your software is a sign that that component is not part of the os. Well, as you say, the clause is supposed to close such loopholes. There is no indication that it is also supposed to prevent os vendors from distributing GPL'd tools along with their operating system. Actually, the results of such an interpretation are quite ridiculous: . You could not distribute updates for an os and GPL'd software for that OS on a magazine CD. You could put them on the CDs of two subsequent issues - or is it enough if you have two CDs in one issue? . You could not distribute Debian (including OpenSSL) along with OpenSSL-dependent programs but you could set up a different, apt- get'able repository with these tools. It was even suggested that putting them in "whatever-but-not-main" is enough. . You could not sell an proprietary os including GPL tools on the distribution media, but you could sell the GPL tools as a separate product or have the user download GPL tools from your website to make your os useable. > This is all very well known to be fundamental to the intent of the GPL. > If you want to convince us that the intent is actually different, you > should start by asking [EMAIL PROTECTED] I think you'd better explain the intent of the GPL to them and ask why they don't sue Sun or Apple. Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus Färber wrote: > Brian Thomas Sniffen <[EMAIL PROTECTED]> schrieb/wrote: > >> If we follow this interpretation, this means that you can't distribute > >> an closed source OS with GPL tools. IMO, this was not the intention of > >> the GPL authors. If you have to distribute the component with the GPL > >> software, this is a sign that it's not universally available on the > >> operating system. However, if you are distributing an OS... > > > That was *exactly* the intent of the GPL authors: to prevent Sun from > > distributing the GNU tools with Solaris. They do distribute them > > separately. > > They did. Solaris 9 reportedly comes with GNU tools (I can't check it > myself because I don't have a machine running Solaris). > > I can't find anything on the FSF's homepage that says you can't distri- > bute GNU tools with non-GPL operating systems. Further, I can't find an This is all irrelevant. The issue is that you can't distribute GPL binaries *linked against* GPL-incompatible libraries. A vendor can't distribute a GPL binary for its operating system if its libc, or any other library used by the GPL binary, is GPL-incompatible. (It doesn't care at all about software it's packaged with but does not link against.) The operating system clause makes an exception for this, but it's not available when the program is packaged along with the libraries. It's intended to make software under the GPL usable on proprietary systems; otherwise, for example, GPL applications could never be used on Windows. (That wouldn't be in the interests of free software; it'd be much more damaging to the GPL application than to Microsoft.) Debian distributes everything together, so it can never use this exception. It is *not* intended to allow OS vendors (Microsoft, Debian) to link GPL applications against whatever proprietary code (such as Word or OpenSSL, which are both "proprietary" as far as the GPL is concerned) they wish. The "accompanies the executable" restriction exists to close this loophole. This is all very well known to be fundamental to the intent of the GPL. If you want to convince us that the intent is actually different, you should start by asking [EMAIL PROTECTED] If you can't convince anyone that the intent is different, then arguing that the license is different is merely searching for loopholes, which Debian won't exploit. -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus F?rber wrote: > Of course, in such simple cases, they can be thought of having given > implicit permission to link against OpenSSL. There is no such thing as implicit permission in copyright law (or even contract law). That only works for verbal agreements. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sun, Sep 05, 2004 at 08:56:00PM +0200, Claus Färber wrote: > Glenn Maynard <[EMAIL PROTECTED]> schrieb/wrote: > > Huh? Whether such a library is "normally distributed with the major > > components of the operating system" isn't related to the existance of > > emulation libraries. > > Well, if you have different choices even on a single operating system, > this is an *indication* that it's not a part of the software distributed > but a component of the execution environment. There's no connection at all. Debian has multiple choices for bible study software and Doom. Multiple choices being available in Debian is not an indiciation at all that it's part of the operating system--in fact, it seems that for any given task, Debian has multiple choices. How is the relevant? The GPL OS exception, again, is not available to Debian. -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus Färber wrote: > They did. Solaris 9 reportedly comes with GNU tools (I can't check it > myself because I don't have a machine running Solaris). You can get gnu tools for solaris from http://www.sunfreeware.com To my knowledge, gnu tools are not supplied on the solaris install cds. -- Raul
Re: GPL-licensed packages with depend-chain to OpenSSL
Claus Färber wrote: the author put it under the GPL because he *didn't* want it shipped with software with restrictions like OpenSSL's. I see: Someone releasing a program written in curl under the GPL does not want it to be distributed along with an operating system that includes the curl runtime. Curl is a downloading API, not a programming language. You mean 'written using curl', surely? No, most authors would probably be very surprised that there is such a problem at all. Of course, in such simple cases, they can be thought of having given implicit permission to link against OpenSSL. The hard cases are those where you have different choices for a library and only one choice links against a non-GPL-compatible library. Oh, you mean like the curl library linked with and without libSSL? Many programs written using curl don't access the SSL functions of it at all. It is hard to be sure whether any given program that doesn't use ssl was written against curl+ssl (and therefore explicitly permitting such linkage), or against a curl without ssl (at best not implicitly permitting such linkage, and at worst expressly forbidding it). -- Lewis Jardine IANAL IANADD
Re: GPL-licensed packages with depend-chain to OpenSSL
David Schleef <[EMAIL PROTECTED]> schrieb/wrote: > For one thing, it's absolutely not possible to run the binary in > such a way that openssl is not part of the process image. You can use an alternative implementation (of libcurl *or* OpenSSL) that offers the same ABI without pulling in OpenSSL. Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
Brian Thomas Sniffen <[EMAIL PROTECTED]> schrieb/wrote: >> If we follow this interpretation, this means that you can't distribute >> an closed source OS with GPL tools. IMO, this was not the intention of >> the GPL authors. If you have to distribute the component with the GPL >> software, this is a sign that it's not universally available on the >> operating system. However, if you are distributing an OS... > That was *exactly* the intent of the GPL authors: to prevent Sun from > distributing the GNU tools with Solaris. They do distribute them > separately. They did. Solaris 9 reportedly comes with GNU tools (I can't check it myself because I don't have a machine running Solaris). I can't find anything on the FSF's homepage that says you can't distri- bute GNU tools with non-GPL operating systems. Further, I can't find an official statement saying: Sun and Apple (Max OS X also comes with GNU tools, according to Apple's homepage) violate the GPL. Further, you can't just interpret a contract (license?) according to the intent of RMS or the FSF. Legal construction is more complex than that (and unfortunatly, the rules vary from legislation to legislation). >> Well, we should not think: "openssl accompanies $tool-ssl" but: >> "$tool-ssl accompanies Debian which also includes openssl (or a >> compatible SSL library)". > Silly syntax games don't help anything: If you dismiss any attempt to interpret the phrase "accompanies the executable" as "syntax games", we can just stop the discussion. > the author put it under the GPL because he *didn't* want it shipped > with software with restrictions like OpenSSL's. I see: Someone releasing a program written in curl under the GPL does not want it to be distributed along with an operating system that includes the curl runtime. No, most authors would probably be very surprised that there is such a problem at all. Of course, in such simple cases, they can be thought of having given implicit permission to link against OpenSSL. The hard cases are those where you have different choices for a library and only one choice links against a non-GPL-compatible library. Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
Glenn Maynard <[EMAIL PROTECTED]> schrieb/wrote: > Huh? Whether such a library is "normally distributed with the major > components of the operating system" isn't related to the existance of > emulation libraries. Well, if you have different choices even on a single operating system, this is an *indication* that it's not a part of the software distributed but a component of the execution environment. Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
Ken Arromdee <[EMAIL PROTECTED]> writes: > On Sat, 4 Sep 2004, Andrew Suffield wrote: >> I find a decent smoke test for aggregation to be: >> >> Can I take these two packages on the same CD and split them apart >> again, such that they are no longer aggregated, and still use them? > > This definition suggests that all Emacs macros are derived from Emacs, that > all Perl scripts are derived from Perl, and of course that any document > written in Microsoft Word is derived from Word. No, it suggests that Emacs macros shipped with Emacs are a combined work -- especially if the macros are shipped in Emacs' load-path. Perl scripts shipped with perl are a combined work, just like C programs shipped with libc are a combined work. This all is exactly what the OS-exception is for -- so that runtime code libraries and interpreters didn't get dragged around by the GPL too, unless you're the OS vendor. Debian is an OS vendor. Eit. -Brian Oh, and Word? I don't think I'd call a Word Doc and MS Word a combined work, or MS Word part of the Source, unless OO.o or AbiWord really couldn't open it. There's a fuzzy line between interpreters and rich document formats, but I think Word is mostly still on the "document format" side of that line. -- Brian Sniffen [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote: > On Sat, 4 Sep 2004, Andrew Suffield wrote: > > I find a decent smoke test for aggregation to be: > > > > Can I take these two packages on the same CD and split them apart > > again, such that they are no longer aggregated, and still use them? It's a smoke test, not a bright-line test. But still... > This definition suggests that all Emacs macros are derived from Emacs, Fairly likely. > that > all Perl scripts are derived from Perl, Difficult to say. Perhaps. Certainly some are (for example, anything involving XSUB) - but perl has two licenses, so that's not hugely interesting. > and of course that any document > written in Microsoft Word is derived from Word. I can use a word document without a copy of word, these days. There are at least half a dozen other things that can work with them. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sat, 4 Sep 2004, Andrew Suffield wrote: > I find a decent smoke test for aggregation to be: > > Can I take these two packages on the same CD and split them apart > again, such that they are no longer aggregated, and still use them? This definition suggests that all Emacs macros are derived from Emacs, that all Perl scripts are derived from Perl, and of course that any document written in Microsoft Word is derived from Word.
Re: GPL-licensed packages with depend-chain to OpenSSL
On 2004-09-04 15:42:00 +0100 Claus Färber <[EMAIL PROTECTED]> wrote: > IMO, this is a clear sign that an OpenSSL-compatible library should be > considered part of the operating system. Any new reasoning for that, or just restating in the hope it will become true? -- MJR/slefMy Opinion Only and not of any group I know
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sat, Sep 04, 2004 at 01:55:33PM -0700, Joseph Lorenzo Hall wrote: > Greetings Debian-legal, (I've just started subscribing to this list.) > > On Sat, 4 Sep 2004 13:42:21 -0700, Steve Langasek <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 04, 2004 at 04:56:00PM +0200, Claus Färber wrote: > > > If we follow this interpretation, this means that you can't distribute > > > an closed source OS with GPL tools. IMO, this was not the intention of > > > the GPL authors. > > > > Of course it was. The GPL is about advancing the cause of a wholly free > > operating system; giving free operating systems a competitive advantage > > over non-free operating systems that happen to provide free tools is > > precisely in line with the goals of the framers. > > > > And while you're free to doubt that this was the intent, this is > > nevertheless what the letter of the license encodes. > > Caveat, mere aggregation: > > http://www.gnu.org/licenses/gpl-faq.html#MereAggregation > > What is the difference between "mere aggregation" and "combining two > modules into one program"? Sneakily not well-defined, thereby defeating all attempts at word games. > Mere aggregation of two programs means putting them side by side on > the same CD-ROM or hard disk. We use this term in the case where they > are separate programs, not parts of a single program. In this case, if > one of the programs is covered by the GPL, it has no effect on the > other program. When one of them depends on the other, it is difficult to call it "mere aggregation". I find a decent smoke test for aggregation to be: Can I take these two packages on the same CD and split them apart again, such that they are no longer aggregated, and still use them? For example, you can't (or at least couldn't, disregarding modern binary emulation tricks) realistically use a program linked against solaris libc without solaris libc. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
Greetings Debian-legal, (I've just started subscribing to this list.) On Sat, 4 Sep 2004 13:42:21 -0700, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Sat, Sep 04, 2004 at 04:56:00PM +0200, Claus Färber wrote: > > If we follow this interpretation, this means that you can't distribute > > an closed source OS with GPL tools. IMO, this was not the intention of > > the GPL authors. > > Of course it was. The GPL is about advancing the cause of a wholly free > operating system; giving free operating systems a competitive advantage > over non-free operating systems that happen to provide free tools is > precisely in line with the goals of the framers. > > And while you're free to doubt that this was the intent, this is > nevertheless what the letter of the license encodes. Caveat, mere aggregation: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation What is the difference between "mere aggregation" and "combining two modules into one program"? Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program. [...] -- Joseph Lorenzo Hall UC Berkeley, SIMS PhD Student http://pobox.com/~joehall/ blog: http://pobox.com/~joehall/nqb2/
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sat, Sep 04, 2004 at 04:56:00PM +0200, Claus Färber wrote: > Brian Thomas Sniffen <[EMAIL PROTECTED]> schrieb/wrote: > > What's in a normal Debian install doesn't matter, because it all gets > > distributed together on mirrors and in cd-packs. There's a very > > specific phrase used to keep MS and Sun from shipping Emacs with their > > proprietary libc: "unless that component itself accompanies the > > executable." > If we follow this interpretation, this means that you can't distribute > an closed source OS with GPL tools. IMO, this was not the intention of > the GPL authors. Of course it was. The GPL is about advancing the cause of a wholly free operating system; giving free operating systems a competitive advantage over non-free operating systems that happen to provide free tools is precisely in line with the goals of the framers. And while you're free to doubt that this was the intent, this is nevertheless what the letter of the license encodes. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sat, Sep 04, 2004 at 04:42:00PM +0200, Claus Färber wrote: > curl-ssl might even be GPL-free if distributed with GnuTLS' OpenSSL- > emulation. > IMO, this is a clear sign that an OpenSSL-compatible library should be > considered part of the operating system. Huh? Whether such a library is "normally distributed with the major components of the operating system" isn't related to the existance of emulation libraries. That doesn't matter, though. Debian is never eligible to use the "operating system" exception, due to "unless that component itself accompanies the executable". -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
[EMAIL PROTECTED] (Claus Färber) writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> schrieb/wrote: >> What's in a normal Debian install doesn't matter, because it all gets >> distributed together on mirrors and in cd-packs. There's a very >> specific phrase used to keep MS and Sun from shipping Emacs with their >> proprietary libc: "unless that component itself accompanies the >> executable." > > If we follow this interpretation, this means that you can't distribute > an closed source OS with GPL tools. IMO, this was not the intention of > the GPL authors. If you have to distribute the component with the GPL > software, this is a sign that it's not universally available on the > operating system. However, if you are distributing an OS... That was *exactly* the intent of the GPL authors: to prevent Sun from distributing the GNU tools with Solaris. They do distribute them separately. > Well, we should not think: "openssl accompanies $tool-ssl" but: > "$tool-ssl accompanies Debian which also includes openssl (or a > compatible SSL library)". Silly syntax games don't help anything: the author put it under the GPL because he *didn't* want it shipped with software with restrictions like OpenSSL's. So we should follow his wishes and not distribute it that way. If he wants it distributable with OpenSSL, he'll grant a license exception. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
Brian Thomas Sniffen <[EMAIL PROTECTED]> schrieb/wrote: > What's in a normal Debian install doesn't matter, because it all gets > distributed together on mirrors and in cd-packs. There's a very > specific phrase used to keep MS and Sun from shipping Emacs with their > proprietary libc: "unless that component itself accompanies the > executable." If we follow this interpretation, this means that you can't distribute an closed source OS with GPL tools. IMO, this was not the intention of the GPL authors. If you have to distribute the component with the GPL software, this is a sign that it's not universally available on the operating system. However, if you are distributing an OS... Well, we should not think: "openssl accompanies $tool-ssl" but: "$tool-ssl accompanies Debian which also includes openssl (or a compatible SSL library)". Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
Anthony DeRobertis <[EMAIL PROTECTED]> schrieb/wrote: > So, if we were to compile it against a curl-nossl, that'd be fine. But > if we then distribute with curl-ssl, that suddenly changes things? curl-ssl might even be GPL-free if distributed with GnuTLS' OpenSSL- emulation. IMO, this is a clear sign that an OpenSSL-compatible library should be considered part of the operating system. Claus -- http://www.faerber.muc.de
Re: GPL-licensed packages with depend-chain to OpenSSL
* Andrew Suffield: >> Probably distribution. If you distribute just the OpenSSL of curl >> version, it's rather clear that you intent that all applications >> linking against curl also link against OpenSSL. > > And if you distribute both? If the OpenSSL version is not marked as the default one (directly or indirectly), I don't think there's a problem.
Re: GPL-licensed packages with depend-chain to OpenSSL
* Anthony DeRobertis: >> Probably distribution. If you distribute just the OpenSSL of curl >> version, it's rather clear that you intent that all applications >> linking against curl also link against OpenSSL. > > So, if we were to compile it against a curl-nossl, that'd be fine. But > if we then distribute with curl-ssl, that suddenly changes things? If curl-ssl is a replacement for curl-nossl that is not installed by default, I don't see a problem. > That sounds quite like "plac[ing] restrictions on other software that > is distributed along with the licensed software." If curl-ssl is linked to GPLed programs by default, it's not mere aggregation.
Re: GPL-licensed packages with depend-chain to OpenSSL
On Aug 19, 2004, at 20:27, Florian Weimer wrote: * Andrew Suffield: Here's the snarly bit: Take a copy of curl, not built with ssl support. Build your GPLed application, linking it to this curl. There should unarguably be no problems here - everything involved is GPL-compatible. Now, go and build a copy of curl that is linked to openssl. Install that one instead, not touching the GPLed application. What just happened? What is going on here and where is the boundary? Probably distribution. If you distribute just the OpenSSL of curl version, it's rather clear that you intent that all applications linking against curl also link against OpenSSL. So, if we were to compile it against a curl-nossl, that'd be fine. But if we then distribute with curl-ssl, that suddenly changes things? That sounds quite like "plac[ing] restrictions on other software that is distributed along with the licensed software."
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Aug 20, 2004 at 02:27:55AM +0200, Florian Weimer wrote: > * Andrew Suffield: > > > Here's the snarly bit: > > > > Take a copy of curl, not built with ssl support. Build your GPLed > > application, linking it to this curl. There should unarguably be no > > problems here - everything involved is GPL-compatible. > > > > Now, go and build a copy of curl that is linked to openssl. Install > > that one instead, not touching the GPLed application. > > > > What just happened? What is going on here and where is the boundary? > > Probably distribution. If you distribute just the OpenSSL of curl > version, it's rather clear that you intent that all applications > linking against curl also link against OpenSSL. And if you distribute both? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, 19 Aug 2004, David Schleef wrote: > > > For one thing, it's absolutely not possible to run the binary in > > > such a way that openssl is not part of the process image. > > Since when is Debian distributing linked process images? > I have a lot of difficulty dicerning a legal difference between > "distrubuting a file containing a program" and "distributing > a bunch of files that become a program when assembled automatically > by the system". I think a judge or jury would have difficulty > with this difference as well. In response, I'll ask: why would a judge or jury consider those two to be the same? They're obviously not the same series of steps. The way in which those two scenarios are the same is that they both have the same result: the user ends up with a copy of the linked program. But two scenarios aren't equivalent just because they have the same result, unless the result itself is what's prohibited. And in this case, the result isn't prohibited, just a particular method of achieving it.
Re: GPL-licensed packages with depend-chain to OpenSSL
* Andrew Suffield: > Here's the snarly bit: > > Take a copy of curl, not built with ssl support. Build your GPLed > application, linking it to this curl. There should unarguably be no > problems here - everything involved is GPL-compatible. > > Now, go and build a copy of curl that is linked to openssl. Install > that one instead, not touching the GPLed application. > > What just happened? What is going on here and where is the boundary? Probably distribution. If you distribute just the OpenSSL of curl version, it's rather clear that you intent that all applications linking against curl also link against OpenSSL.
Re: GPL-licensed packages with depend-chain to OpenSSL
Måns Rullgård wrote: David Schleef <[EMAIL PROTECTED]> writes: Symbol references are not necessarily resolved at that time, unless you define LD_BIND_NOW or are using prelinking. There's really no method of doing "lazy linking" as you suggest with C, since it would either fail (such as with global variables in libraries) or be required to violate the ISO standard, such as taking the address of a function. There is no requirement that the linker be written in C, or that it follow any standard whatsoever as long as the interface and operation visible to applications is as expected. Surely this is to be read "There's really no method of doing 'lazy linking' as you suggest [of programs written in] C", rather than "There's really no method of doing 'lazy linking' as you suggest [using a linker written in] C"? As we all know, any TC language can be converted into any other TC language. It doesn't matter to the operation of the linker which language it's written in. -- Lewis Jardine IANAL IANADD
Re: GPL-licensed packages with depend-chain to OpenSSL
David Schleef <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: >> When using dynamic linking that is not necessarily the case. Most >> dynamic linkers use lazy loading of libraries, such that the openssl >> libraries would not actually be mapped in to the process address space >> until one of its functions is called. > > This is not how an ELF runtime linker works. Run ldd on a binary -- > this lists all the shared object files that are mapped into the > address space of the process before main() is called. Sorry, I was a little too quick there. The file is mapped, but is not read from disk until the code is required. The mapping is also shared with other applications using the library. Are all these applications derived from each other? > Symbol references are not necessarily resolved at that time, unless > you define LD_BIND_NOW or are using prelinking. There's really no > method of doing "lazy linking" as you suggest with C, since it would > either fail (such as with global variables in libraries) or be > required to violate the ISO standard, such as taking the address of > a function. There is no requirement that the linker be written in C, or that it follow any standard whatsoever as long as the interface and operation visible to applications is as expected. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Aug 20, 2004 at 12:26:43AM +0200, Måns Rullgård wrote: > David Schleef <[EMAIL PROTECTED]> writes: > > For one thing, it's absolutely not possible to run the binary in > > such a way that openssl is not part of the process image. > > Since when is Debian distributing linked process images? I have a lot of difficulty dicerning a legal difference between "distrubuting a file containing a program" and "distributing a bunch of files that become a program when assembled automatically by the system". I think a judge or jury would have difficulty with this difference as well. (I'd be happy to be swayed by arguments that demonstrate such a difference, though.) dave...
Re: GPL-licensed packages with depend-chain to OpenSSL
David Schleef <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 08:59:44PM +0200, Måns Rullgård wrote: >> > I didn't say anything about derived works. Neither does the GPL when >> > talking about source code. >> > >> > The GPL also doesn't define source code to include "all modules it >> > uses", it defines it to include "all modules it contains". >> >> Could you please explain to me how something linked against libcurl >> contains openssl? > > For one thing, it's absolutely not possible to run the binary in > such a way that openssl is not part of the process image. Since when is Debian distributing linked process images? -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 19, 2004 at 08:59:44PM +0200, Måns Rullgård wrote: > > I didn't say anything about derived works. Neither does the GPL when > > talking about source code. > > > > The GPL also doesn't define source code to include "all modules it > > uses", it defines it to include "all modules it contains". > > Could you please explain to me how something linked against libcurl > contains openssl? For one thing, it's absolutely not possible to run the binary in such a way that openssl is not part of the process image. dave...
Re: GPL-licensed packages with depend-chain to OpenSSL
Here's the snarly bit: Take a copy of curl, not built with ssl support. Build your GPLed application, linking it to this curl. There should unarguably be no problems here - everything involved is GPL-compatible. Now, go and build a copy of curl that is linked to openssl. Install that one instead, not touching the GPLed application. What just happened? What is going on here and where is the boundary? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: > When using dynamic linking that is not necessarily the case. Most > dynamic linkers use lazy loading of libraries, such that the openssl > libraries would not actually be mapped in to the process address space > until one of its functions is called. This is not how an ELF runtime linker works. Run ldd on a binary -- this lists all the shared object files that are mapped into the address space of the process before main() is called. Symbol references are not necessarily resolved at that time, unless you define LD_BIND_NOW or are using prelinking. There's really no method of doing "lazy linking" as you suggest with C, since it would either fail (such as with global variables in libraries) or be required to violate the ISO standard, such as taking the address of a function. dave...
Re: GPL-licensed packages with depend-chain to OpenSSL
Steve Langasek <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: >> Steve Langasek <[EMAIL PROTECTED]> writes: > >> > If your understanding of the license exception requirements were >> > correct, it would be a very easy loophole for people to exploit, using >> > GPL-compatible library layers to "sanitize" the licenses of library >> > dependencies. > >> > But in fact, the GPL's definition of source code is: > >> > The source code for a work means the preferred form of the work for >> > making modifications to it. For an executable work, complete source >> > code means all the source code for all modules it contains, plus any >> > associated interface definition files, plus the scripts used to >> > control compilation and installation of the executable. However, as a >> > special exception, the source code distributed need not include >> > anything that is normally distributed (in either source or binary >> > form) with the major components (compiler, kernel, and so on) of the >> > operating system on which the executable runs, unless that component >> > itself accompanies the executable. > >> > For GPL applications linked against curl, "all modules it contains" >> > includes both libcurl and libssl. > >> When using dynamic linking that is not necessarily the case. Most >> dynamic linkers use lazy loading of libraries, such that the openssl >> libraries would not actually be mapped in to the process address space >> until one of its functions is called. If, as per assumption, the >> application does not use any ssl related features of curl, the openssl >> libraries would never be touched, except for a possible scan of its >> symbol table. The openssl libraries could be replaced by another >> library containing dummy entries for all the required symbols and the >> curl using application would still function correctly. How the >> presence or absence of a particular library at runtime could possibly >> change the derivedness of a some program from said library is beyond >> my comprehension. > > I didn't say anything about derived works. Neither does the GPL when > talking about source code. > > The GPL also doesn't define source code to include "all modules it > uses", it defines it to include "all modules it contains". Could you please explain to me how something linked against libcurl contains openssl? -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > If your understanding of the license exception requirements were > > correct, it would be a very easy loophole for people to exploit, using > > GPL-compatible library layers to "sanitize" the licenses of library > > dependencies. > > But in fact, the GPL's definition of source code is: > > The source code for a work means the preferred form of the work for > > making modifications to it. For an executable work, complete source > > code means all the source code for all modules it contains, plus any > > associated interface definition files, plus the scripts used to > > control compilation and installation of the executable. However, as a > > special exception, the source code distributed need not include > > anything that is normally distributed (in either source or binary > > form) with the major components (compiler, kernel, and so on) of the > > operating system on which the executable runs, unless that component > > itself accompanies the executable. > > For GPL applications linked against curl, "all modules it contains" > > includes both libcurl and libssl. > When using dynamic linking that is not necessarily the case. Most > dynamic linkers use lazy loading of libraries, such that the openssl > libraries would not actually be mapped in to the process address space > until one of its functions is called. If, as per assumption, the > application does not use any ssl related features of curl, the openssl > libraries would never be touched, except for a possible scan of its > symbol table. The openssl libraries could be replaced by another > library containing dummy entries for all the required symbols and the > curl using application would still function correctly. How the > presence or absence of a particular library at runtime could possibly > change the derivedness of a some program from said library is beyond > my comprehension. I didn't say anything about derived works. Neither does the GPL when talking about source code. The GPL also doesn't define source code to include "all modules it uses", it defines it to include "all modules it contains". -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
Steve Langasek <[EMAIL PROTECTED]> writes: > If your understanding of the license exception requirements were > correct, it would be a very easy loophole for people to exploit, using > GPL-compatible library layers to "sanitize" the licenses of library > dependencies. > > But in fact, the GPL's definition of source code is: > > The source code for a work means the preferred form of the work for > making modifications to it. For an executable work, complete source > code means all the source code for all modules it contains, plus any > associated interface definition files, plus the scripts used to > control compilation and installation of the executable. However, as a > special exception, the source code distributed need not include > anything that is normally distributed (in either source or binary > form) with the major components (compiler, kernel, and so on) of the > operating system on which the executable runs, unless that component > itself accompanies the executable. > > For GPL applications linked against curl, "all modules it contains" > includes both libcurl and libssl. When using dynamic linking that is not necessarily the case. Most dynamic linkers use lazy loading of libraries, such that the openssl libraries would not actually be mapped in to the process address space until one of its functions is called. If, as per assumption, the application does not use any ssl related features of curl, the openssl libraries would never be touched, except for a possible scan of its symbol table. The openssl libraries could be replaced by another library containing dummy entries for all the required symbols and the curl using application would still function correctly. How the presence or absence of a particular library at runtime could possibly change the derivedness of a some program from said library is beyond my comprehension. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 19, 2004 at 10:02:06AM +0200, Francesco P. Lovergine wrote: > On Thu, Aug 12, 2004 at 04:17:22PM -0700, Steve Langasek wrote: > > > I'm not a Debian guru, but I scanned through the list of apps depending > > > on > > > curl to see what licenses they use, and I stopped when I had collected > > > five > > > examples: > > > > > grip, logjam, ardour, fbi, xine-ui > > > > > They are all GPLv2 licensees. > > > > This is, in fact, a violation of the GPL as we understand it. > Uhm, please clarify. E.g. I - an upstream - link a library which in turn > links openssl, but I do not use ssl related functions at all in my > sources. Could you explain why I should add a clause for openssl? > Linking with it is of course a choice of curl upstream (and maintainer) > and of course not mandatory. I (again the typical upstream) link using > curl API, which should hide those kind of details, tamquam non esset. > The only upstream which should add the clause is curl one AFAIK, if needed > (I don't know what sort of license it uses). If you admit indirect > linking vincula, we could probably remove a good portion of main > in debian, due to bsd-gpl problem. You are welcome to demonstrate that there is actually a bsd-gpl problem that would require removal of large portions of main. However, this has been the orthodox understanding of the GPL for longer than I've been involved in Debian, and is taken very seriously. If your understanding of the license exception requirements were correct, it would be a very easy loophole for people to exploit, using GPL-compatible library layers to "sanitize" the licenses of library dependencies. But in fact, the GPL's definition of source code is: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. For GPL applications linked against curl, "all modules it contains" includes both libcurl and libssl. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 12, 2004 at 04:17:22PM -0700, Steve Langasek wrote: > On Thu, Aug 12, 2004 at 03:22:34PM +0200, Daniel Stenberg wrote: > > Please forgive a new subscriber if this subject already has been debated to > > death. In that case, just let me know and I'll quietly crawl away again. > > > Ok, here's my explanation of the "problem": > > > There this package in recent Debian named 'curl' (using a MIT-like > > license). It is built with OpenSSL (you all know the OpenSSL license). > > > With curl there comes two (that we care about here) debian packages > > nowadays named libcurl2 and libcurl3 (libcurl3 being the new ABI and > > libcurl2 the older one). Both are linked against the OpenSSL libraries. > > > Many applications use libcurl. Including several applications/packages in > > Debian unstable that are GPL-licensed. > > > See where I'm drifting? Several packages in Debian unstable are licensed > > GPL (without explicit allowance for linking with OpenSSL) but links with > > libraries/components that link with OpenSSL... This creates binaries that > > are not allowed to distribute due to GPL license violations. AFAICT. > > > I'm not a Debian guru, but I scanned through the list of apps depending on > > curl to see what licenses they use, and I stopped when I had collected five > > examples: > > > grip, logjam, ardour, fbi, xine-ui > > > They are all GPLv2 licensees. > > This is, in fact, a violation of the GPL as we understand it. > Uhm, please clarify. E.g. I - an upstream - link a library which in turn links openssl, but I do not use ssl related functions at all in my sources. Could you explain why I should add a clause for openssl? Linking with it is of course a choice of curl upstream (and maintainer) and of course not mandatory. I (again the typical upstream) link using curl API, which should hide those kind of details, tamquam non esset. The only upstream which should add the clause is curl one AFAIK, if needed (I don't know what sort of license it uses). If you admit indirect linking vincula, we could probably remove a good portion of main in debian, due to bsd-gpl problem. -- Francesco P. Lovergine
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Aug 13, 2004 at 12:59:00AM +0200, Freek Dijkstra wrote: > Given the fact that this topic seems to come up relatively often, would it > be a good idea to put a few things into a FAQ for people to refer to? > In my opinion, it should be added to, or referred from either or both: > http://people.debian.org/~bap/dfsg-faq.html > http://www.debian.org/doc/debian-policy/ I don't think questions about the GPL belong in the DFSG FAQ. They belong in the FSF's: http://www.gnu.org/licenses/gpl-faq.html It doesn't clearly answer every common question; I'd recommend bringing your suggestions of missing questions to the FSF for possible inclusion in their FAQ. (I did try to refer to it during our discussion, but couldn't find in it a clear answer to your questions, so it's either too short--doesn't have the information--or too long, and I simply couldn't dig it out.) They don't belong in Debian policy. > Here is a quick draft: > Q: How to find if a licence is 'free'? > A: See http://www.nl.debian.org/legal/licenses/byclass > Or http://www.gnu.org/licenses/license-list.html Debian and the FSF have similar but different definitions of Free; Debian should be pointing to the DFSG, not gnu.org. :) > Q: Will the FSF sue me if I do this? > A: No. First of all, since this is copyright law, only the copyright owner > can sue you. That is sometimes the FSF, but often a group of open source > developers. Even so, they probably don't have the resource to sue you. > However, breaking the law is not the solution, even if it is injust in your > opinion. I'd recommend against making claims to what the FSF will or won't do. (Remember, the FSF holds copyright to a large quantity of GPL-licensed code.) -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 12, 2004 at 03:22:34PM +0200, Daniel Stenberg wrote: > Please forgive a new subscriber if this subject already has been debated to > death. In that case, just let me know and I'll quietly crawl away again. > Ok, here's my explanation of the "problem": > There this package in recent Debian named 'curl' (using a MIT-like > license). It is built with OpenSSL (you all know the OpenSSL license). > With curl there comes two (that we care about here) debian packages > nowadays named libcurl2 and libcurl3 (libcurl3 being the new ABI and > libcurl2 the older one). Both are linked against the OpenSSL libraries. > Many applications use libcurl. Including several applications/packages in > Debian unstable that are GPL-licensed. > See where I'm drifting? Several packages in Debian unstable are licensed > GPL (without explicit allowance for linking with OpenSSL) but links with > libraries/components that link with OpenSSL... This creates binaries that > are not allowed to distribute due to GPL license violations. AFAICT. > I'm not a Debian guru, but I scanned through the list of apps depending on > curl to see what licenses they use, and I stopped when I had collected five > examples: > grip, logjam, ardour, fbi, xine-ui > They are all GPLv2 licensees. This is, in fact, a violation of the GPL as we understand it. It would be helpful if you could file bug reports (severity: serious) against these packages you've looked at, documenting the license problem. The maintainer may have further licensing information that's not documented in the package copyright file; or, OTOH, we may need to remove these packages from sarge if the question can't be resolved quickly. > (I'm sure someone with more Debian skill can do this checking better and > more accurate - these numbers were obtained by some rather crude and > error-prone scripts.) It's possible to quickly find a list of packages using libcurl2/3, but checking the licenses of these packages still requires human review of the copyright files. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On 2004-08-12 23:59:00 +0100 Freek Dijkstra <[EMAIL PROTECTED]> wrote: Given the fact that this topic seems to come up relatively often, would it be a good idea to put a few things into a FAQ for people to refer to? Yes, and that's why people started work on one already. Please add to http://people.debian.org/~bap/dfsg-faq.html ...noticing question 26. http://www.debian.org/doc/debian-policy/ I think other people maintain that. Here is a quick draft: Q: How to find if a licence is 'free'? I would rather not have such loose language in the FAQ. I don't care whether a licence is "free" (whatever that means) but I care whether the debian contains only free software. Q: Why is licence x free, but not GPL-compatible? Really should be in the GPL FAQ, but a simpler answer (after s/licence/software/): It follows the Debian Free Software Guidelines (DFSG), but the terms of its licence and the GPL in combination do not allow us to distribute software which satisfies both licences and follows our guidelines. Most of the rest should really really be in the GPL FAQ as a first attempt, if they aren't already. If you want to maintain a "shadow GPL FAQ" then go on. Q: This is outrageous! [...] -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
Re: GPL-licensed packages with depend-chain to OpenSSL
Given the fact that this topic seems to come up relatively often, would it be a good idea to put a few things into a FAQ for people to refer to? I am willing to put down a draft of questions. I have proposed this as a side note in a private mail, and was pointed that this not a Debian-specific question. I agree. However, given the interest and the number of times it pops up, I belief a FAQ is a good idea. In my opinion, it should be added to, or referred from either or both: http://people.debian.org/~bap/dfsg-faq.html http://www.debian.org/doc/debian-policy/ Here is a quick draft: Q: How to find if a licence is 'free'? A: See http://www.nl.debian.org/legal/licenses/byclass Or http://www.gnu.org/licenses/license-list.html Q: How to find if a licence is 'GPL-compatible'? A: See http://www.gnu.org/licenses/license-list.html Q: Why is licence x free, but not GPL-compatible? A: There may be different reasons. See http://www.gnu.org/licenses/license-list.html for specific arguments. For example licence x may give permission to use, modify and redistribute the source code (making it free), but also requires you to give attribution to the original copyright owner. This is called the advertising clause, and is incompatible with the GPL, because it places an additional restriction on the source which the GPL does not has. So that code can never be redistributed under the GPL. In addition, the GPL explicitly forbids anyone to add additional restrictions on GPL-licenced code, so code once code is under the GPL, it can never be redistributed under a licence x which has such an advertising clause. The FSF takes the prohibition of added resistrictions very strict. For example, the following licence is not GPL-compatible: "This code may be freely modified, copied and distributed, so long as no fee is charged for it.", because of the added restriction that no fee may be applied. Q: Can I redistribute a binary of program xxx with non-GPL compatible licence y if it has been linked to library zzz, which has the GPL licence? A: No. The binary you are to distribute is a derivate on library zzz, according to copyright law. Therefor, according to the definition in the GPL, the binary is based on library zzz, and must therefor be released under the GPL. See also http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL Q: Can I redistribute a binary of program xxx with a non-GPL compatible licence y if it is dynamically linked to library zzz, which has the GPL licence, even if I make sure only to distribute program xxx and not library zzz. A: No. It is technically possible to distribute the two parts seperately. But according to section 2b of the GPL, you must distribute the program as a whole under a single licence. As you may read in the GPL, this requirements apply to the modified work as a whole, not if the the program xxx and the library zzz can be considered independant and separate works in themselves. Now, this is a tricky business. Ultimately, a judge will decide if the combination is one whole or two separate parts. According to the FSF, linking is an act specifically to combine programs making it one whole. See http://www.gnu.org/licenses/gpl-faq.html#MereAggregation for details. Nobody has so far been willing to have a lawsuit over this, so it's not possible to confirm or deny this. Believing the FSF is safer than not doing so, so Debian takes the low-risk approach. Q: Can I redistribute a binary of program xxx with non-GPL compatible licence y if it has been linked to library zzz, which has the LGPL licence? A: Yes, only if you use dynamic linking. Unlike the GPL, the LGPL (lesser GPL) does explicitly make a distinction between a "work based on the library" and a "work that uses the library". Such a binary is not covered by the LGPL, as explained in section 5 of the LGPL. Q: Can I redistribute a binary of program xxx with the GPL licence if it has been linked to library zzz which is covered by non-GPL compatible licence y? A: No. First of all, licence y may not allow this. But even if it does, the GPL does not allow this. According to the GPL, if your program is specifically code against an other library, then the two parts form one whole combined program. According to section 2b of the GPL, you must release this whole under a single licence. According to section 6 of the GPL, this must be the GPL. However, since licence y is incompatible with the GPL, this is not possible. See also http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleAlone Q: Can I even not redistribute a binary of program xxx with the GPL licence if it has been dynamically linked to library zzz which is covered by non-GPL compatible licence y? When it is dynamically linked, it does not contain any byte of executable code generate by non-GPL code! A: No. According to section 2 of the GPL, the combination may only distributed together under a single licence. The fact that it is technically possible does not allow it. Some people have claim
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 12, 2004 at 03:22:34PM +0200, Daniel Stenberg wrote: > There this package in recent Debian named 'curl' (using a MIT-like > license). It is built with OpenSSL (you all know the OpenSSL license). > > With curl there comes two (that we care about here) debian packages > nowadays named libcurl2 and libcurl3 (libcurl3 being the new ABI and > libcurl2 the older one). Both are linked against the OpenSSL libraries. > > Many applications use libcurl. Including several applications/packages in > Debian unstable that are GPL-licensed. Yes, we've done this before, but never reached a meaningful conclusion. It's really knotty. I'm aware of a few other package combinations like this. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 12, 2004 at 03:31:19PM +0200, Daniel Stenberg wrote: > On Thu, 12 Aug 2004, Daniel Stenberg wrote: > > >If this a hge can of worms or am I just plain wrong? > > Ok, don't hit me. > > I did another google and I've found enough references on the topic "openssl > is PART of the OS" etc so no need to say anything else. That doesn't apply to Debian, and we haven't been using it as an excuse since non-US was removed. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
