Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Thu, May 29, 2003 at 12:20:39PM -0400, Nathanael Nerode wrote: Steve Langasek wrote: It is not mere aggregation, for the same reason that a bug in a library that makes it unusable by applications is a grave, not a critical, bug: one piece of software is not unrelated to another if the former depends on the latter. Ah, I get what I was missing earlier... so you're claiming that there's a legal status for a combination C of A and B, which does *not* make C a derived work derived from work B, but where C is also not a mere aggregation of work A with work B. I don't think there is. I could be wrong, of course. IANAL. I'm sorry -- IANAL either, and I was not aware that mere aggregation was a legal term at all. I'm discussing the concepts, as present in the DFSG and the GPL, and explaining why I believe that, if the GPL places requirements on applications that use GPL libs, this doesn't violate DFSG#9. -- Steve Langasek postmodern programmer pgp3D16YphSsq.pgp Description: PGP signature
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tuesday, May 27, 2003, at 23:21 US/Eastern, Steve Langasek wrote: Not all: the terms of section 3 talk about covered source code in very broad terms of all modules [the work] contains. Can you expand on your understanding of this phrase? Section 3 reads, in part: You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms ofSections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, Later, complete source code is defined, in part, as all the source code for all modules the work contains. In order to be a part of the complete source code, the source has to be for a module that the Program or a work based on the Program [i.e., a derivative work] contains. This leads fairly clearly to your asymmetry below: One possibility that I had not thoroughly considered is that in the case of an application, all modules includes any libraries referenced by the application; but that in the case of a library, all modules does not include any applications which use that library, because the *library* which is GPLed does not encode any information pointing to the applications. I think it might even be possible that symmetry is preserved; that is, dynamic linking a GPL'd work to a non-GPL'd library might be allowed, too, iff that does not form a derivative work. Why? Because if those are two separate works under copyright law, then the non-GPL'd library is not a module of the work. I'm not sure I like this asymmetry (I'm pretty sure it isn't the FSF's intention), I think the FSF argues that a program using the library is a derivative work of the library, in which case the program using the library is a work based on [the Program] for GPL 3. However, depending on how Lotus v. Borland is interpreted, this reasoning may be specious. Noted. I've come to believe that the basis for claiming the application is a derived work in these cases is very weak, but it still seems prudent to treat dynamically-linked works as covered by the GPL's source code requirements for the time being. As Debian doesn't have a legal war chest (and doesn't want a bunch of bad press, either), it's quite prudent. Then again, it'd end all our OpenSSL problems real quick ;-D However, I think for some cases --- such as the mess that started this whole thread, and for other things that have been discussed, like command-line utilities in shell scripts, we should go ahead and link 'em.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tue, May 27, 2003 at 03:19:45PM -0400, Brian T. Sniffen wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, May 23, 2003, at 03:30 PM, Brian T. Sniffen wrote: ... In Lotus Development Corp. v. Borland International, Inc.,[0] the court held that a menu structure is method of operation. Methods of operation are, by statute, not copyrightable. To quote the decision: We think that method of operation, as that term is used in 102(b), refers to the means by which a person operates something, whether it be a car, a food processor, or a computer. We hold that the Lotus menu command hierarchy is an uncopyrightable method of operation. The Lotus menu command hierarchy provides the means by which users control and operate Lotus 1-2-3. Users must use the command terms to tell the computer what to do. Without the menu command hierarchy, users would not be able to access and control, or indeed make use of, Lotus 1-2-3's functional capabilities. The Lotus menu command hierarchy does not merely explain and present Lotus 1-2-3's functional capabilities to the user; it also serves as the method by which the program is operated and controlled. gibber OK. Well, that settles that argument: if this hasn't been reversed, you're unambiguously correct. Thanks for pointing this out! I wonder how this relates to library interfaces... certainly, those are methods of operation as well. IANAL, TINLA As far as I recall that famous case, the case was about the right to re-implement a programmable interface and whether preserving the interface names was a Copyright infringement on the original implementation. This, I believe, is the landmark ruling that it is not illegal for GNU bash to accept the same language and keywords as ATT sh, for lesstif to be a drop in replacement for Motif etc. The case was not directly about whether someone *using* a proprietary or GPL interface is implicitly deriving from that interface but the ruling may confirm the common theory that gcc for Solaris is not a derivative of the SunOs interface just because it is written to use it. Anyway, I thought the common GPL linking claim was that the runtime in-memory process image includes a copy of the GPL code and is thus a derivative of that copy. Thus at least in the GPL case, the problem is where the borderline is between the last and third-last paragraph of GPL-2 clause 2, with the two extremes being: A: The two pieces of code do not in any way talk to each other but are on the same disk, falling under the explicit mere aggregation provision of clause 2. B: The lines are manually mixed together in the source code of a single medium sized function in a single source file, making the entire function a GPL derivative which must be under the GPL unless otherwise permitted by the author of the old GPL part. If the GPL lines were deleted again, the old GPL parts no longer force GPL-ing of the other lines, but recipients of the combination could continue to act and distribute under the GPL they received it under. So the question is When does a combination of a GPL piece of code and some independent pieces of code reside so close together at runtime, that the combination forms a single derived work of the GPL piece of code and becomes subject to the GPL as a whole, including each and every part regardless who wrote it? Borland vs. Lotus as quoted doesn't say much here, since the whole case was about a situation where the Borland and Lotus code where not even on the same (non-networked) computer. Hope this helps even though it doesn't clear up much, sorry. Jakob -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Steve Langasek wrote: It is not mere aggregation, for the same reason that a bug in a library that makes it unusable by applications is a grave, not a critical, bug: one piece of software is not unrelated to another if the former depends on the latter. Ah, I get what I was missing earlier... so you're claiming that there's a legal status for a combination C of A and B, which does *not* make C a derived work derived from work B, but where C is also not a mere aggregation of work A with work B. I don't think there is. I could be wrong, of course. IANAL. If removal of foo makes bar unusable, the combination of the two cannot be considered mere aggregation. Is that a quote from a legal opinion? If so, I defer to your expertise. I didn't think that was the legal ruling on the nature of derived works. But if it *is*, if it's a combination involving copyrightable elements and it's not 'mere aggregation', then it's a derived work. I think there's no 'third state'. Again, I could be wrong here! Not all: the terms of section 3 talk about covered source code in very broad terms of all modules [the work] contains. Can you expand on your understanding of this phrase? The work is the *derived work* derived from the original GPLed work. It has to be *one work*. For the GPL to apply to it as a consequence of section 2b, it has to be a *derived work* of the original. The modules are independent pieces which can be extracted from the derived work, but may individually not constitute derived works. Suppose we have: GPLed source file A My source file B Object file C, compiled into a program from A, B, and C. Object file B, compiled from B alone Executable file C is one work, which is a derivative of work A. The source file B is the source code for a module which is not a derivative of work A. The source file A is the source code for a module (which is work A.) That was my interpretation of modules; I assumed that it was mainly an effort to elaborate on requiring *complete* source code for an object code file, given the context it's in. The special exception for operating systems still remains meaningful, because it covers OS header files, which may not be freely distributable, and are, in fact, source code for the compiled object file. I was more interested in the phrases about identifiable sections in section 2, but they clearly start from the assumption that there is a modified work, such as executable file C. Noted. I've come to believe that the basis for claiming the application is a derived work in these cases is very weak, but it still seems prudent to treat dynamically-linked works as covered by the GPL's source code requirements for the time being. This, we agree on 100%. :-) --Nathanael
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Thu, May 29, 2003 at 11:57:18AM -0400, Nathanael Nerode wrote: Jakob Bohm said: Anyway, I thought the common GPL linking claim was that the runtime in-memory process image includes a copy of the GPL code and is thus a derivative of that copy. But this derivative (if you assume that it is a derived work) is created by the user on their home computer, and is not redistributed. Since it's not distributed or published, it's not subject to the GPL's 'viral' requirements under section 2b: b) You must cause any work that you distribute or publish, that in ^ whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. (Emphasis mine) This is why the runtime in-memory state of the dynamically linked code is not directly relevant to the GPL's 'virality'. IANAL, TINLA As I said, I believe there is a continuum of cases ranging from mere aggregation to manually mixing of code lines in the hand-edited source. One point in this continuum is when a library and an application are both in a Debian CD image, where the application is clearly marked to automatically link to the library whenever run. Is this mere aggregation or do the two form a single work derived (by simple inclusion) from the library. However the main point of my post was not that. My main point was that in Borland vs. Lotus, the issue placed before the court was the right to *re-implement* a compatible interface, not the right to implement things that *use* the interface. More specifically, this is how I recall the case (I was not around, I just read about it once, so my memory may fail me): Lotus had a monopoly status in the spreadsheet market with its Lotus 1-2-3 program. Part of its monopoly lock-in was the fact that users had invested much time and effort creating and sharing macros written in the Lotus macro languages. Macros which often encoded complex things like price schedules or U.S. Tax Legislation, and were sold as commercial products or used as necessary parts of business relationships (similar to the current status of MS Word .doc files). The Lotus 1-2-3 macro language happened to consist of simply spelling out the actual menu shortcut keys for the Lotus commands. Borland, in its Quattro Spreadsheet program chose as a major feature to implement full support for running and manipulating existing Lotus macros, just as the Free Software community do today for many proprietary interfaces. Lotus sued, claiming that Borland broke the Lotus copyright on the menu tree design detail and the artistic and random choices amongst alternate naming and placement of the items. Borland said that such a claim would amount to forcing gratuitous incompatibilities to the detriment of the general publics ability to use different products at their choice. A comparison was made (in court) to Ford (hypothetically) demanding that all non-Ford cars placed the pedals or steering wheel differently. Borland won, re-implementing an old interface as part of a new superior product while preserving the verbs of the command language seem to be legal and not a violation of the copyright of prior implementations. The ruling also said that such protection could be obtained with a patent, but Lotus did not have one. All of this in the U.S. of cause. Jakob -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Thu, 2003-05-29 at 20:00, Jakob Bohm wrote: However the main point of my post was not that. My main point was that in Borland vs. Lotus, the issue placed before the court was the right to *re-implement* a compatible interface, not the right to implement things that *use* the interface. Lotus v. Borland decided something broader than that: That the menu hierarchy (which Borland copied from Lotus 1-2-3 not just for macros, but to use in its own GUI) is a method of operation, and this not subject to copyright. The court makes it fairly clear that it considers human interfaces to computer programs as methods of operation. signature.asc Description: This is a digitally signed message part
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tuesday, May 27, 2003, at 15:20 US/Eastern, Brian T. Sniffen wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: OK, then I take it you're in favor filing seriouss bug against ftp.debian.org asking for the removal of apache-ssl and *many* more packages like it. Not quite -- I'd prefer to find a more reasonable solution first, and begin implementing it second. Can we call Lotus v. Borland a reasonable solution? ;-)
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tuesday, May 27, 2003, at 15:19 US/Eastern, Brian T. Sniffen wrote: All of those -- TCP, HTTP, and DEB -- are generic formats. .deb isn't. There is, AFAIK, only one implementation. At the very least, alien and dpkg deal with it; I believe there are others. If I remember correctly, alien uses dpkg-deb to do its work. Even if not, isn't alien GPL? [...] but really, you'd rather be writing a derivative of a GPL work than a GFDL work. At least we can agree on that ;-) I wonder how this relates to library interfaces... Me too.
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tuesday, May 27, 2003, at 14:25 US/Eastern, Steve Langasek wrote: This assumes that the FSF's interpretation depends on the claim that dynamic linking creates a derived work. Well, from carefully reading the GPL, this appears to be what it says. A quote: a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. So, if a new_program is neither a derivative work of Program or Program itself, then it is not a work based on the Program as used in the GPL. And then: In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. So, the GPL is very clear that new_program is not covered by the GPL.
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tuesday, May 27, 2003, at 12:22 US/Eastern, Nathanael Nerode wrote: First, any interface which could be used by humans is a method of operation. This is essentially all interfaces. That's a good question. I think the decision only covers interfaces that humans need to use to use the program (and all its features). However, for a library, it is quite arguable that the API is covered. Since dynamic linking involves the copying of small, (usually) uncopyrightable, code segments, together with the use of an interface, dynamic linking incurs no obligations, and the FSF's interpretation is quite wrong. This is quite possible, especially since if the normally copyrightable commands used in a menu are not copyrightable because they are a method of operation, its possible the method names, etc., needed to dynamic link are, too. Second, any interface which is designed for use by humans is a method of operation. This is more restrictive, but does not touch the question of secret interfaces. Suppose that passing -EF)#I^FMCVS)[EMAIL PROTECTED])[EMAIL PROTECTED] on the grep command line gives access to the secret operations -- is this the means by which a person operates something? I think its probable. Even if it isn't, I doubt you could claim copyright over the above string. Same problem with the longer (random) string. If my second extrapolation is the correct one, then the documentation status *may* be relevant as evidence for whether the interface was designed for humans or not, though what matters is whether the GPL program creator documented it. I think that a program which uses command line arguments, one of the standard ways of user interaction on Unix, is very strong evidence that it is a method of operation. It'd be hard, I think, to argue that the command line interface is not intended for humans. (In fact, its other interface designed for 'people to operate it' is the interface for being statically linked with programs, so use of static linking probably isn't covered either! Although in that case the combination is probaly a 'derived work' and may not be redistributable; but individuals can do the linking themselves quite freely.) The GPL never covered use, and copyright law (at least in the US) specifically exempts copying needed to use a computer program, so I don't think the GPL ever prohibited private, non-distributed linking. If my third extrapolation is the correct one, then the FSF's library linking interpretation is valid, but we've wandered into a remarkably fuzzy realm. Certain command-line options are rarely, if ever, used by humans; for instance, options designed to produce better program-readable output. Those options are _very_ often used by humans. Part of the UNIX user interface is the pipe operator in every shell. However, if the 'linkage' causes program B to rely on copyrighted elements of program A, but the 'linkage' is not actually performed except by the end-user, then there is no infringment on the part of the distributor. And the GPL puts no restrictions on 'use', or indeed creation of derived works as long as they're not distributed, so there's no cause for contributory infringment, as far as I can tell. I don't think there is any way to be a contributory infringer when there is no infringement. I'm not sure if eventually dynamic linking will become a way around copyleft licenses, but I wouldn't be surprised if --- should it ever be tested in court --- it turns out to often be. Disclaimer: This is not legal advice! Very strong ditto there.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Tuesday, May 27, 2003, at 15:20 US/Eastern, Brian T. Sniffen wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: OK, then I take it you're in favor filing seriouss bug against ftp.debian.org asking for the removal of apache-ssl and *many* more packages like it. Not quite -- I'd prefer to find a more reasonable solution first, and begin implementing it second. Can we call Lotus v. Borland a reasonable solution? ;-) Heh. Given the chain of logic: A means of operation is not copyrightable; All user interfaces are means of operation; exec() is a programmatic user interface... I'm even willing to concede that exec() is always a boundary between works. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis said: I'm not sure if you're thinking of this when mentioning public domain, but many header files (for example, ones giving simple structs and numeric defines) probably have no copyrightable work in them, and thus would be essentially in the public domain. So, using those is fine, no matter what the copyright notice says. I was, indeed, thinking of this. :-) I point out Lotus v. Borland[0] and note that the commands used by the shell script are the same as used by a human, and thus are a method of operation, not protected by copyright. This is an interesting case, the details of which I was not aware. This case leads to the following test: if you are accessing a program through an interface which is a method of operation, referring to the means by which a person operates something, you incur no obligations, because that is not copyrightable. There are various possible extrapolations from this. First, any interface which could be used by humans is a method of operation. This is essentially all interfaces. Since dynamic linking involves the copying of small, (usually) uncopyrightable, code segments, together with the use of an interface, dynamic linking incurs no obligations, and the FSF's interpretation is quite wrong. Second, any interface which is designed for use by humans is a method of operation. This is more restrictive, but does not touch the question of secret interfaces. Suppose that passing -EF)#I^FMCVS)[EMAIL PROTECTED])[EMAIL PROTECTED] on the grep command line gives access to the secret operations -- is this the means by which a person operates something? Suppose the corresponding scheme is the passing of a specific 255-byte string, designed with the intention that it will only be used by computers? Third, any interface which is usually used by humans is a method of operation. This is also unclear on important points, like the last interpretation. So in regards to declawing, this makes a *non-arbitrary* distinction, Not really. You essentially said that if I, as the author of a non-GPL program that wants to use a GPL'd work says I need a program doing foo, bar, and baz to work, such as GNU frob instead of saying I need GNU frob to work I'm fine. That's a rather pointless distinction, methinks. It consists of creating interface documentation in a publically accessible way; one which allows, and even encourages, creation of replacement programs. This is intended as a defense against the claim that the program *relies* on copyrighted elements of the GPLed program. (No, it doesn't rely on anything in GNU grep. Any user of my program can write an appropriate 'grep' program; I told them what they need to do!) If my first extrapolation from the mentioned case is the correct one, then the documentation status of the interface is truly irrelevant, and incidentally the GPL doesn't cover dynamic linking. If my second extrapolation is the correct one, then the documentation status *may* be relevant as evidence for whether the interface was designed for humans or not, though what matters is whether the GPL program creator documented it. Writing out what features are used is still a way to insulate yourself against claims that you're relying on copyrighted elements of the GPLed program, however, since this extrapolation doesn't clearly resolve the 'secret interfaces' issue. Here, however, we see something interesting. When a library is distributed independently, its *only* interface designed for 'a person to operate' it, is its library linking interface. Accordingly, the FSF's claims about the GPL covering dynamic linking of such libraries are no good, and we can stop worrying generally about dynamic linking of GPL libraries. (In fact, its other interface designed for 'people to operate it' is the interface for being statically linked with programs, so use of static linking probably isn't covered either! Although in that case the combination is probaly a 'derived work' and may not be redistributable; but individuals can do the linking themselves quite freely.) If my third extrapolation is the correct one, then the FSF's library linking interpretation is valid, but we've wandered into a remarkably fuzzy realm. Certain command-line options are rarely, if ever, used by humans; for instance, options designed to produce better program-readable output. --- It's a matter of whether the linkage is integral to the program, or not. Admittedly the distinction must be applied carefully on a case-by-case basis, but that's often what makes good law. I'd say its a matter of if the linkage causes program B to rely on copyrighted elements of program A, then there could be infringement. You're better at stating things clearly. :-) However, if the 'linkage' causes program B to rely on copyrighted elements of program A, but the 'linkage' is not actually performed except by the end-user, then there is no infringment on
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tue, May 27, 2003 at 12:22:35PM -0400, Nathanael Nerode wrote: Anthony DeRobertis said: I'm not sure if you're thinking of this when mentioning public domain, but many header files (for example, ones giving simple structs and numeric defines) probably have no copyrightable work in them, and thus would be essentially in the public domain. So, using those is fine, no matter what the copyright notice says. I was, indeed, thinking of this. :-) I point out Lotus v. Borland[0] and note that the commands used by the shell script are the same as used by a human, and thus are a method of operation, not protected by copyright. This is an interesting case, the details of which I was not aware. This case leads to the following test: if you are accessing a program through an interface which is a method of operation, referring to the means by which a person operates something, you incur no obligations, because that is not copyrightable. There are various possible extrapolations from this. First, any interface which could be used by humans is a method of operation. This is essentially all interfaces. Since dynamic linking involves the copying of small, (usually) uncopyrightable, code segments, together with the use of an interface, dynamic linking incurs no obligations, and the FSF's interpretation is quite wrong. This assumes that the FSF's interpretation depends on the claim that dynamic linking creates a derived work. While varies parties have claimed this at one point or another, I have argued that the dynamically linked work is under the purview of the GPL by virtue of the license terms alone, *if* you are distributing the GPL library in question, which is always the case for Debian. There have been many well-constructed arguments here that writing to an interface does not create a derived work, and is not subject to the copyright of the library because the only parts being copied are not copyrightable. However, the advertising materials for a product are not derived works of a software library either, yet there are software licenses that place restrictions on the contents of advertising materials for products containing the software -- *and* we accept such licenses as free. You have no say in it, it's not a derived work is a null argument, because as distributors we must accept the terms of a license that *gives* them a say in it. The greater question for Debian, I think, is whether such an interpretation can be regarded as DFSG-compliant. I believe the answer is yes: first, because it is not *merely* the act of co-distribution that triggers this license contamination, so DFSG 9 does not seem to apply; second, because this interpretation of the GPL's requirements has existed for a long time, and I'm not aware of any formal objections to its DFSG-freeness even though it depended on a definition of derived work that varies from country to country, so I don't think it suddenly becomes non-free just because we've shown it isn't copyright law directly that's used to enforce the requirement. There is a certain set of freedoms that we demand from Free Software, some of which are granted to the user by default in copyright law and some of which are not; so long as these core freedoms are preserved, I don't think changes in copyright law or its interpretation should render a license non-free. Granted, this rule of thumb has its limitations -- a change in copyright law that eliminates all use rights by default would certainly affect the landscape -- but I think it applies here. -- Steve Langasek postmodern programmer pgpX8ulbvFJkL.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, May 23, 2003, at 03:30 PM, Brian T. Sniffen wrote: Wait. Isn't dpkg under the GPL? Now everything on the entire system has to be under the GPL, because you can't even get it installed without the use of dpkg. I don't see how a program which merely happened to be installed using dpkg can be said to be a derivative work of dpkg, Well, he is going a little far. But certainly the postinst, preinst, postrm, etc. files would have to be, as Debian distributes them in such a way to force dpkg to link them (by executing them). That would mean that everything used in those scripts has to be GPL-compatible. I didn't say *all* execution was derivation. Execution is a form of use, not covered by copyright. Creation with a certain target in mind is derivation, though. All of those -- TCP, HTTP, and DEB -- are generic formats. .deb isn't. There is, AFAIK, only one implementation. At the very least, alien and dpkg deal with it; I believe there are others. BTW: If the documentation in the policy manual makes it a standard, why doesn't the documentation in the GNU grep manpage, info page, etc. make it a standard, too? They do -- but really, you'd rather be writing a derivative of a GPL work than a GFDL work. If he, in his creation, is intentionally deriving creative ideas from the author of a previous work, his work is derivative. The only thing I'm deriving from in, e.g., grep is, if anything: 1) its command line interface 2) its functionality In Lotus Development Corp. v. Borland International, Inc.,[0] the court held that a menu structure is method of operation. Methods of operation are, by statute, not copyrightable. To quote the decision: We think that method of operation, as that term is used in 102(b), refers to the means by which a person operates something, whether it be a car, a food processor, or a computer. We hold that the Lotus menu command hierarchy is an uncopyrightable method of operation. The Lotus menu command hierarchy provides the means by which users control and operate Lotus 1-2-3. Users must use the command terms to tell the computer what to do. Without the menu command hierarchy, users would not be able to access and control, or indeed make use of, Lotus 1-2-3's functional capabilities. The Lotus menu command hierarchy does not merely explain and present Lotus 1-2-3's functional capabilities to the user; it also serves as the method by which the program is operated and controlled. gibber OK. Well, that settles that argument: if this hasn't been reversed, you're unambiguously correct. Thanks for pointing this out! I wonder how this relates to library interfaces... certainly, those are methods of operation as well. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, May 23, 2003, at 09:52 AM, Brian T. Sniffen wrote: Let's take a concrete example: apache-ssl. In particular, it's postint. It uses adduser, which is under the GPL. It also uses update-rc.d, also under the GPL. So, as above, we have to say the postinst is available under the GPL. However, it also uses /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the GPL and the OpenSSL license are not compatible. Is the above legal? If so, why? I'm not a lawyer -- but I think distribution of apache-ssl.postinst must be distributed under the terms of the GPL. As such, it can't be distributed by others without an OpenSSL exception or a license which grants a superset of the freedoms of the GPL. OK, then I take it you're in favor filing seriouss bug against ftp.debian.org asking for the removal of apache-ssl and *many* more packages like it. Not quite -- I'd prefer to find a more reasonable solution first, and begin implementing it second. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Steve Langasek wrote: This assumes that the FSF's interpretation depends on the claim that dynamic linking creates a derived work. While varies parties have claimed this at one point or another, I have argued that the dynamically linked work is under the purview of the GPL by virtue of the license terms alone, *if* you are distributing the GPL library in question, which is always the case for Debian. Well, this statement is simply wrong, and I'll devote the rest of this email to explaining why. If the dynamic linking does *not* create a derived work, you are distributing two works: A. The new program which links to the GPL'ed library B. The GPL'ed library which is linked to Not one work. A mere aggregaton of two works. Under the GPL, the library B is distributable under section 3, using either the written offer (b) or the distribution of source code (a), and the source code for the library can be distributed under section 1. There is no restriction on the distribution of B with other works. In fact, there's an explicit statement that there's no such restriction (Section 2, final paragraph). So the GPL imposes no restriction on the distribution of A and B together. Note carefully that *all* the restrictions in the GPL (except for the very mild section 1 restrictions) are stated in terms of incorporating parts of the Program, as part of a whole which is a work based on the Program, etc., all of which are terms refering to the creation of a derived work. Steve said: You have no say in it, it's not a derived work is a null argument, because as distributors we must accept the terms of a license that *gives* them a say in it. Wrong. The license, in the case of the GPL, *doesn't* give them a say in it. Some other, theoretical, license, *could* impose such a restriction (a la the BSD advertising clause), but the GPL simply *doesn't* impose such restrictions. The dynamic linking imposes GPL is, fundamentally, based on the idea that dynamic linking creates a derived work. I'm quite sure the FSF lawyers will agree with me on that. Furthermore, it is not within the rights of the copyright holder to decide unilaterally what constitutes a derived work. I believe that is considered to be a matter of facts, to be established by court cases and precedents. Respecting the FSF's *opinion* that dynamic linking creates a derived work is perfectly sensible and wise. (Hey, they could be legally correct!) Claiming that the GPL somehow imposes itself on works linked with even if linking *doesn't* legally create a derived work is just plain wrong. --Nathanael
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tue, May 27, 2003 at 05:11:21PM -0400, Nathanael Nerode wrote: Steve Langasek wrote: This assumes that the FSF's interpretation depends on the claim that dynamic linking creates a derived work. While varies parties have claimed this at one point or another, I have argued that the dynamically linked work is under the purview of the GPL by virtue of the license terms alone, *if* you are distributing the GPL library in question, which is always the case for Debian. Well, this statement is simply wrong, and I'll devote the rest of this email to explaining why. If the dynamic linking does *not* create a derived work, you are distributing two works: A. The new program which links to the GPL'ed library B. The GPL'ed library which is linked to Not one work. A mere aggregaton of two works. It is not mere aggregation, for the same reason that a bug in a library that makes it unusable by applications is a grave, not a critical, bug: one piece of software is not unrelated to another if the former depends on the latter. This may or may not make the one work a derived work of the other, but it does mean we're dealing with something more than mere aggregation, because the application references the library at several levels: in the ELF header, in the form of undefined symbol references, and in the Depends: line of the package itself. If removal of foo makes bar unusable, the combination of the two cannot be considered mere aggregation. Under the GPL, the library B is distributable under section 3, using either the written offer (b) or the distribution of source code (a), and the source code for the library can be distributed under section 1. There is no restriction on the distribution of B with other works. In fact, there's an explicit statement that there's no such restriction (Section 2, final paragraph). So the GPL imposes no restriction on the distribution of A and B together. Note carefully that *all* the restrictions in the GPL (except for the very mild section 1 restrictions) are stated in terms of incorporating parts of the Program, as part of a whole which is a work based on the Program, etc., all of which are terms refering to the creation of a derived work. Not all: the terms of section 3 talk about covered source code in very broad terms of all modules [the work] contains. Can you expand on your understanding of this phrase? One possibility that I had not thoroughly considered is that in the case of an application, all modules includes any libraries referenced by the application; but that in the case of a library, all modules does not include any applications which use that library, because the *library* which is GPLed does not encode any information pointing to the applications. I'm not sure I like this asymmetry (I'm pretty sure it isn't the FSF's intention), but I'm also not sure I can make a convincing argument against this interpretation. The best I can muster is that it conflicts with the FSF's public interpretation of the GPL, which *could* be seen as significant in a court case. Furthermore, it is not within the rights of the copyright holder to decide unilaterally what constitutes a derived work. I believe that is considered to be a matter of facts, to be established by court cases and precedents. Certainly. Respecting the FSF's *opinion* that dynamic linking creates a derived work is perfectly sensible and wise. (Hey, they could be legally correct!) Claiming that the GPL somehow imposes itself on works linked with even if linking *doesn't* legally create a derived work is just plain wrong. Noted. I've come to believe that the basis for claiming the application is a derived work in these cases is very weak, but it still seems prudent to treat dynamically-linked works as covered by the GPL's source code requirements for the time being. -- Steve Langasek postmodern programmer pgpKGdKx1ubFd.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Friday, May 23, 2003, at 03:30 PM, Brian T. Sniffen wrote: but given their authors licensed them in ways that forbid linking with non-GPL-compatible software, such as OpenSSL, that sounds reasonable Well, at least you're consistent ;-) Wait. Isn't dpkg under the GPL? Now everything on the entire system has to be under the GPL, because you can't even get it installed without the use of dpkg. I don't see how a program which merely happened to be installed using dpkg can be said to be a derivative work of dpkg, Well, he is going a little far. But certainly the postinst, preinst, postrm, etc. files would have to be, as Debian distributes them in such a way to force dpkg to link them (by executing them). That would mean that everything used in those scripts has to be GPL-compatible. All of those -- TCP, HTTP, and DEB -- are generic formats. .deb isn't. There is, AFAIK, only one implementation. BTW: If the documentation in the policy manual makes it a standard, why doesn't the documentation in the GNU grep manpage, info page, etc. make it a standard, too? If he, in his creation, is intentionally deriving creative ideas from the author of a previous work, his work is derivative. The only thing I'm deriving from in, e.g., grep is, if anything: 1) its command line interface 2) its functionality In Lotus Development Corp. v. Borland International, Inc.,[0] the court held that a menu structure is method of operation. Methods of operation are, by statute, not copyrightable. To quote the decision: We think that method of operation, as that term is used in 102(b), refers to the means by which a person operates something, whether it be a car, a food processor, or a computer. We hold that the Lotus menu command hierarchy is an uncopyrightable method of operation. The Lotus menu command hierarchy provides the means by which users control and operate Lotus 1-2-3. Users must use the command terms to tell the computer what to do. Without the menu command hierarchy, users would not be able to access and control, or indeed make use of, Lotus 1-2-3's functional capabilities. The Lotus menu command hierarchy does not merely explain and present Lotus 1-2-3's functional capabilities to the user; it also serves as the method by which the program is operated and controlled. I think its clear that the logic applies at least as much to a command line interface. Indeed, the court even says If specific words are essential to operating something, then they are part of a 'method of operation' and, as such, are unprotectable. This is so whether they must be highlighted, typed in, or even spoken, as computer programs no doubt will soon be controlled by spoken words.[1] Note that the court did not say that it was copyright infringement but fair use. Instead, it said that menu command hierarchies are not copyrightable. So no use --- programatic or otherwise --- can infringe the copyright, as there is no copyright. Thus, it can't be (1) above. As for (2), Title 17 USC Sec. 102(b) seems to fairly clearly say that can't be protected by copyright, either: In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work In other words, what grep does can't be protected by copyright. Only the expression can be. So I can't be creating a derivative work of what grep does. [0] http://www.kuesterlaw.com/borlan2.html [1] IMO, this is a potential reason for that anti-spam haiku to fail if seriously challenged in court if mass adoption occurs.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Saturday, May 24, 2003, at 10:02 PM, Brian T. Sniffen wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, May 23, 2003, at 01:45 PM, Stephen Ryan wrote: On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote: The other option, of course, is that the kernel exec() function *is* a barrier, Debian *can* be used for real work and not just an exercise in ivory-tower masturbation. Whoa! Those are not my words. I'm not quite sure whose they are. My apologies. It appears I have destroyed the quoting somehow. Those are the words of Stephen Ryan [EMAIL PROTECTED] in Message-Id: [EMAIL PROTECTED]. Well, I don't believe exec is a magic copyright barrier; instead, I think we need to generalize _why_ we generally consider it be one. But this leads me to believe that we may well be on common ground; what generalization do you see there? I see the generalization hinted to in the message I just posted: That no copyrightable elements of programs like grep were derived from.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, May 23, 2003, at 01:45 PM, Stephen Ryan wrote: On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote: The other option, of course, is that the kernel exec() function *is* a barrier, Debian *can* be used for real work and not just an exercise in ivory-tower masturbation. Whoa! Those are not my words. I'm not quite sure whose they are. Well, I don't believe exec is a magic copyright barrier; instead, I think we need to generalize _why_ we generally consider it be one. But this leads me to believe that we may well be on common ground; what generalization do you see there? -Brian
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Wed, 2003-05-21 at 11:59, Brian T. Sniffen wrote: I don't. If it makes use of features specific to the GNU version, it should either use the normally part of your OS exception, or if distributed with GNU grep be itself available under the GNU GPL. So every script that Debian distributes that makes use of features only found in GPL tools must be under the GPL (since Debian can't use the normal part of OS exception). Let's take a concrete example: apache-ssl. In particular, it's postint. It uses adduser, which is under the GPL. It also uses update-rc.d, also under the GPL. So, as above, we have to say the postinst is available under the GPL. However, it also uses /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the GPL and the OpenSSL license are not compatible. Is the above legal? If so, why? I'm not a lawyer -- but I think distribution of apache-ssl.postinst must be distributed under the terms of the GPL. As such, it can't be distributed by others without an OpenSSL exception or a license which grants a superset of the freedoms of the GPL. The distinction really does come down to whether something is a derivative work: A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''. (Title 17 USC, Sec. 101) It's hard to see how a shell script could be a derivative work of grep under that definition. I don't think the shell script is an transformation, recasting, or adaption of grep. Or a modification. It certainly can be. For example, consider the shell script greppager, which simply runs grep and pipes the output through $PAGER. That's a program constructed as a transformation and recasting of grep. That it includes grep by reference rather than by copying shouldn't matter -- this is the heart of the FSF's linking is modification argument. Greppager is a work based on a pre-existing work, consisting of elaborations and other modifications which, as a whole, represents an original work of authorship. I don't need to edit the source of a computer program to modify the program: I can create a derivative function by wrapping another function. The output of (lambda (f) (lambda (l) (map f (filter even? l may be a derivative work of f, for example. That a shell script is easily broken apart and read by a human shouldn't matter. For example, if I distribute a macro package which, given some text, loads MS Excel and uses that to perform some calculations, then closes Excel and uses the output of the calculations for some other purpose, that's clearly a derivative work of Excel. If my work couldn't have existed in the same form without another work, my work is derivative of that work. a shell script which coincidentally uses generic grep functions isn't a derivative work of grep. A shell script which wraps GNU grep to provide some of its peculiar functions to another program is a derivative work of GNU grep. Where do you see that in the definition above? To further clarify, given a copyrightable program P which implements an algorithm A(x), a program Q which implements B(A(x)) by nontrivial use of P is a derivative work of P. Put simply, if it's clear that you wrote Q intending it to wrap P, Q is a derivative work of P. If you wrote Q to work with a separate standard, or with a wide variety of programs P1, P2, etc. all presenting a similar interface to P, then Q isn't a derivative work of any of them (and it's most likely not derivative of the standard, because the procedures expressed in the standard are not copyrighted, only their expression there). -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: On Wed, 2003-05-21 at 11:59, Brian T. Sniffen wrote: I don't. If it makes use of features specific to the GNU version, it should either use the normally part of your OS exception, or if distributed with GNU grep be itself available under the GNU GPL. So every script that Debian distributes that makes use of features only found in GPL tools must be under the GPL (since Debian can't use the normal part of OS exception). Let's take a concrete example: apache-ssl. In particular, it's postint. It uses adduser, which is under the GPL. It also uses update-rc.d, also under the GPL. So, as above, we have to say the postinst is available under the GPL. However, it also uses /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the GPL and the OpenSSL license are not compatible. Is the above legal? If so, why? I'm not a lawyer -- but I think distribution of apache-ssl.postinst must be distributed under the terms of the GPL. As such, it can't be distributed by others without an OpenSSL exception or a license which grants a superset of the freedoms of the GPL. I'm surprised no one else has jumped on this yet. No. The script in question is a derivative of both OpenSSL and of adduser, and the author of the script has no legal standing to relicense either of those. Thus, no script which uses both OpenSSL and adduser may be distributed by anyone under any terms, because it would link OpenSSL with adduser, and they are under incompatible terms. Even though the script itself may offer an exception for OpenSSL, adduser doesn't have that exception, and thus, the work as a whole is undistributable. Wait. Isn't dpkg under the GPL? Now everything on the entire system has to be under the GPL, because you can't even get it installed without the use of dpkg. The other option, of course, is that the kernel exec() function *is* a barrier, Debian *can* be used for real work and not just an exercise in ivory-tower masturbation. -- Stephen RyanDebian Linux 3.0 Technology Coordinator Center for Educational Outcomes at Dartmouth College
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Stephen Ryan [EMAIL PROTECTED] writes: On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: On Wed, 2003-05-21 at 11:59, Brian T. Sniffen wrote: I don't. If it makes use of features specific to the GNU version, it should either use the normally part of your OS exception, or if distributed with GNU grep be itself available under the GNU GPL. So every script that Debian distributes that makes use of features only found in GPL tools must be under the GPL (since Debian can't use the normal part of OS exception). Let's take a concrete example: apache-ssl. In particular, it's postint. It uses adduser, which is under the GPL. It also uses update-rc.d, also under the GPL. So, as above, we have to say the postinst is available under the GPL. However, it also uses /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the GPL and the OpenSSL license are not compatible. Is the above legal? If so, why? I'm not a lawyer -- but I think distribution of apache-ssl.postinst must be distributed under the terms of the GPL. As such, it can't be distributed by others without an OpenSSL exception or a license which grants a superset of the freedoms of the GPL. I'm surprised no one else has jumped on this yet. No. The script in question is a derivative of both OpenSSL and of adduser, and the author of the script has no legal standing to relicense either of those. Thus, no script which uses both OpenSSL and adduser may be distributed by anyone under any terms, because it would link OpenSSL with adduser, and they are under incompatible terms. Even though the script itself may offer an exception for OpenSSL, adduser doesn't have that exception, and thus, the work as a whole is undistributable. Sounds reasonable. I'm not entirely clear on why adduser and update-rc.d are under the GPL and not the BSD license... but given their authors licensed them in ways that forbid linking with non-GPL-compatible software, such as OpenSSL, that sounds reasonable Wait. Isn't dpkg under the GPL? Now everything on the entire system has to be under the GPL, because you can't even get it installed without the use of dpkg. I don't see how a program which merely happened to be installed using dpkg can be said to be a derivative work of dpkg, any more than it being a derivative work of whatever tool was used to download the .deb file, or whatever router software runs in the middle. All of those -- TCP, HTTP, and DEB -- are generic formats. Implementing to a standard does not make your work a derivative work of a popular implementation of that standard. The other option, of course, is that the kernel exec() function *is* a barrier, I don't understand why you believe a technical definition is relevant. Why exec and not ld? Why not JMP? Why not #include? The barrier as you put it has nothing to do with bits. It is defined by thought: by the intent of an author of a potentially derivative work. If he, in his creation, is intentionally deriving creative ideas from the author of a previous work, his work is derivative. If he's creating independently of previous programs, or implementing to a specification, his program is not derivative of any other program. So if I write a shell script which makes calls to /usr/bin/openssl, my program is derivative of Eric Young's program, so we both have a copyright on the result. If my script also calls GNU grep, and I looked at the info page while writing it, consciously implementing it to use features particular to GNU grep, then it's also derivative of that program, and the FSF also owns a copyright on it. Doesn't this framework seem easier to work with than trying to find a technical definition of a barrier? Debian *can* be used for real work and not just an exercise in ivory-tower masturbation. Center for Educational Outcomes at Dartmouth College Ahem. I'm all for getting real work done: I just don't see a need to bend the law or the intent of an author to do it. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Friday, May 23, 2003, at 01:45 PM, Stephen Ryan wrote: On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote: The other option, of course, is that the kernel exec() function *is* a barrier, Debian *can* be used for real work and not just an exercise in ivory-tower masturbation. Well, I don't believe exec is a magic copyright barrier; instead, I think we need to generalize _why_ we generally consider it be one.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Friday, May 23, 2003, at 09:52 AM, Brian T. Sniffen wrote: Let's take a concrete example: apache-ssl. In particular, it's postint. It uses adduser, which is under the GPL. It also uses update-rc.d, also under the GPL. So, as above, we have to say the postinst is available under the GPL. However, it also uses /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the GPL and the OpenSSL license are not compatible. Is the above legal? If so, why? I'm not a lawyer -- but I think distribution of apache-ssl.postinst must be distributed under the terms of the GPL. As such, it can't be distributed by others without an OpenSSL exception or a license which grants a superset of the freedoms of the GPL. OK, then I take it you're in favor filing seriouss bug against ftp.debian.org asking for the removal of apache-ssl and *many* more packages like it. A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''. (Title 17 USC, Sec. 101) It's hard to see how a shell script could be a derivative work of grep under that definition. I don't think the shell script is an transformation, recasting, or adaption of grep. Or a modification. It certainly can be. For example, consider the shell script greppager, which simply runs grep and pipes the output through $PAGER. That's a program constructed as a transformation and recasting of grep. No it isn't; such a simple program has no copyrightable part. That it includes grep by reference rather than by copying shouldn't matter Yes it should. That's why its COPYright law. -- this is the heart of the FSF's linking is modification argument. Yes, and I think they go to far in that argument. A line has to be drawn somewhere; otherwise, think of visiting a non-free webapp with a GPL browser. Or a GPL browser with the default home page set to a non-free webapp --- Google, for example. Greppager is a work based on a pre-existing work, consisting of elaborations and other modifications which, as a whole, represents an original work of authorship. No, it does not represent an original work of authorship. It looks something like this: #!/bin/sh grep $@ | $PAGER There is absolutely nothing to copyright in there; it is not an original work of authorship. I don't need to edit the source of a computer program to modify the program: I disagree (excepting binary patching, and other tricks like that, of course). If my work couldn't have existed in the same form without another work, my work is derivative of that work. That is a very, very, very broad definition of derivative work. Under that definition, Apple would of EASILY won its UI lawsuit against Microsoft; the court, however, found the opposite. Care to explain? To further clarify, given a copyrightable program P which implements an algorithm A(x), a program Q which implements B(A(x)) by nontrivial use of P is a derivative work of P. Why? All Q uses from P is the algorithm A, which is not copyrightable. Put simply, if it's clear that you wrote Q intending it to wrap P, Q is a derivative work of P. No. There is no case law on the subject; and what little there is certainly doesn't say its clear. If I can write Q without reference to any copyrightable parts of P, then it is difficult to argue that Q is a derivative work of P; instead, it is very similar to a proper clean-room reverse engineering job --- which is legal. (and it's most likely not derivative of the standard, because the procedures expressed in the standard are not copyrighted, only their expression there). Nothing besides expressions can be copyrighted ever, even for programs. If its a derivative of a program to make use of its documented interfaces, then it is a derivative of the standard to do the same.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, 2003-05-21 at 11:59, Brian T. Sniffen wrote: I don't. If it makes use of features specific to the GNU version, it should either use the normally part of your OS exception, or if distributed with GNU grep be itself available under the GNU GPL. So every script that Debian distributes that makes use of features only found in GPL tools must be under the GPL (since Debian can't use the normal part of OS exception). Let's take a concrete example: apache-ssl. In particular, it's postint. It uses adduser, which is under the GPL. It also uses update-rc.d, also under the GPL. So, as above, we have to say the postinst is available under the GPL. However, it also uses /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the GPL and the OpenSSL license are not compatible. Is the above legal? If so, why? The distinction really does come down to whether something is a derivative work: A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''. (Title 17 USC, Sec. 101) It's hard to see how a shell script could be a derivative work of grep under that definition. I don't think the shell script is an transformation, recasting, or adaption of grep. Or a modification. a shell script which coincidentally uses generic grep functions isn't a derivative work of grep. A shell script which wraps GNU grep to provide some of its peculiar functions to another program is a derivative work of GNU grep. Where do you see that in the definition above?
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, May 21, 2003 at 01:01:06AM -0500, Branden Robinson wrote: It seems wrong to me that we can take a free, but GPL-incompatible application out of Debian main and hand it to two software distributors. Each distributor grabs a different ABI-compatible implementation of a shared library (upon which this app depends) out of Debian main. One of those happens to be GPLed and the other does not (it's, say, under the MIT/X11 license), but the distributors just flip a coin to decide which one they ship. Under your analysis, one of these guys is in deep shit with the copyright holder of the GPLed implementation of the shared library, and the other guy is not. It's just a bellyfeel, but it's a strong one. What the Debian Project distributes should not be subjecting people to this sort of risk. I think one should be able to distribute arbitrary subsets of the Debian OS in pretty much total ignorance of the licensing on the software within. If they modify stuff, that's a different story. I think that's a reasonable requirement, and I don't think my analysis supports the conclusion that someone distributing a subset of Debian packages would be in violation of the GPL, *if* Debian itself is in compliance with the license. If someone distributes a subset of Debian's packages that includes a GPL library and a GPL-incompatible app, there are two principal possibilities: * Installing the application package automatically pulls in the library package, which means that whoever created the original packages (Debian) is also responsible for any GPL violations that result from such a combination. * Installing the application package does *not* automatically pull in the library package, or does so in a way that the application will not automatically load the library when you try to run the application. Manual intervention is required to combine the GPL and GPL-incompatible code, and the distributor (and Debian) cannot possibly be in violation of the license. The one corner case I can see would be an application kfrob-not-so-gpl which depends on libfrob-lgpl | libfrob-gpl. If someone installs kfrob-not-so-gpl from the Debian archive, it will pull in libfrob-lgpl unless the user declares otherwise. If a distributor ships only kfrob-not-so-gpl and libfrob-gpl, the result is different. I agree that this is bad, but I don't know of any packages this is a problem for in practice. Perhaps the best way to address this corner case would be to prohibit maintainers from doing this. I hate to say this because I love my bright-line tests, but I think intent matters here. Shipping such code together with readline itself, and nothing else, should be distinguishable from what Debian does, which is ship such code, readline itself, a clone or two of readline, and a whole boatload of other stuff that has nothing to do with any of the above. I think references to the file name of the GPL'ed library in an application's ELF header constitute pretty damning evidence of the real intent. Your honor, the plaintiff's license is non-binding because I could have used editline instead doesn't sound like much of a defense to me. If that's the case with readline vs. editline -- I can't be assed to check, then you're right. But does your analysis change at all if libeditline ships, say, its own /lib/libreadline.so.4? I mean, this is exactly the point of ABI compatibility. Just look at the LessTif project. I think it does change in such a case. Today, the libeditline0 and libreadline4 packages can be installed side-by-side, however, and applications built against each look for a different library name. -- Steve Langasek postmodern programmer pgpLEW8uRxPpV.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tue, May 20, 2003 at 01:49:03PM -0500, Steve Langasek wrote: I think it's an interesting case to consider because of the question of whether an interface is copyrightable, but I think that discussion is best left for another thread. In any case, I believe the generic interface defense is only applicable when the distributor is not distributing a combination that requires selecting one specific implementation as the default. I am not sure the U.S. courts agree.[1][2] I don't see how the cases you cite conflict with what I said. In both of the cases, IIRC, the courts found in favor of someone who duplicated a competitor's interface. This seems to support (API vs. user interface question aside) the notion that the generic interface defense *is* applicable when you aren't distributing someone else's copyrighted implementation of the generic interface. However, it does not establish a precedent for the case where you *are* distributing the plaintiff's copyrighted work which provides a given interface. Apple v. Microsoft doesn't mean Microsoft could claim MacOS no longer enjoys copyright protection just because someone cloned the UI. Uh, I see I rebutted the very point you wanted to leave to another thread. Sorry. :) I am not sure I agree that a generic interface defense suddenly becomes unavailable simply due to what a distributor fails to distribute. In my view, either an interface is generic or it is not. It seems wrong to me that we can take a free, but GPL-incompatible application out of Debian main and hand it to two software distributors. Each distributor grabs a different ABI-compatible implementation of a shared library (upon which this app depends) out of Debian main. One of those happens to be GPLed and the other does not (it's, say, under the MIT/X11 license), but the distributors just flip a coin to decide which one they ship. Under your analysis, one of these guys is in deep shit with the copyright holder of the GPLed implementation of the shared library, and the other guy is not. It's just a bellyfeel, but it's a strong one. What the Debian Project distributes should not be subjecting people to this sort of risk. I think one should be able to distribute arbitrary subsets of the Debian OS in pretty much total ignorance of the licensing on the software within. If they modify stuff, that's a different story. Because the two libraries are interface-compatible, the FSF is not in a position to forbid people from distributing code that links against libreadline if that code is not licensed GPL-compatibly, because the code could be linked against libeditline instead.[1] Yes, but they are in a position to forbid distributing such code together with readline itself. I hate to say this because I love my bright-line tests, but I think intent matters here. Shipping such code together with readline itself, and nothing else, should be distinguishable from what Debian does, which is ship such code, readline itself, a clone or two of readline, and a whole boatload of other stuff that has nothing to do with any of the above. I think references to the file name of the GPL'ed library in an application's ELF header constitute pretty damning evidence of the real intent. Your honor, the plaintiff's license is non-binding because I could have used editline instead doesn't sound like much of a defense to me. If that's the case with readline vs. editline -- I can't be assed to check, then you're right. But does your analysis change at all if libeditline ships, say, its own /lib/libreadline.so.4? I mean, this is exactly the point of ABI compatibility. Just look at the LessTif project. -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | pgp9x05iQHnEj.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tue, 2003-05-20 at 05:15, Branden Robinson wrote: I am uncomfortable with some of the ramifications but I am also uncomfortable with totally declawing the GNU GPL by adopting and interpretation of it that would let people wrapper and language-bind their way out of the copyleft commons. At some point, we've got to draw a line where it's de-clawed. After all, I think we all agree that if a shell script calls GNU grep[0], it isn't required to be under the GPL. So, is encapsulating code in the kernel's execve interface always OK? [0] Which, btw, has many extensions over POSIX or BSD grep, so there is not, AFAIK, an alternative implementation. Alternatively, put gcc or your favorite GPL program in its place.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Tue, 2003-05-20 at 05:15, Branden Robinson wrote: I am uncomfortable with some of the ramifications but I am also uncomfortable with totally declawing the GNU GPL by adopting and interpretation of it that would let people wrapper and language-bind their way out of the copyleft commons. At some point, we've got to draw a line where it's de-clawed. After all, I think we all agree that if a shell script calls GNU grep[0], it isn't required to be under the GPL. I don't. If it makes use of features specific to the GNU version, it should either use the normally part of your OS exception, or if distributed with GNU grep be itself available under the GNU GPL. So, is encapsulating code in the kernel's execve interface always OK? The distinction really does come down to whether something is a derivative work: a shell script which coincidentally uses generic grep functions isn't a derivative work of grep. A shell script which wraps GNU grep to provide some of its peculiar functions to another program is a derivative work of GNU grep. There is a wide swath of gray down the middle; this is where we hope people are reasonable, and if not obey the wishes of the original authors. -Brian [0] Which, btw, has many extensions over POSIX or BSD grep, so there is not, AFAIK, an alternative implementation. Alternatively, put gcc or your favorite GPL program in its place. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Thu, May 08, 2003 at 01:04:08PM -0500, Steve Langasek wrote: I am specifically addressing the case where: [...] I'm afraid I cannot come up with very much to add to your analysis. I am uncomfortable with some of the ramifications but I am also uncomfortable with totally declawing the GNU GPL by adopting and interpretation of it that would let people wrapper and language-bind their way out of the copyleft commons. Is it any help to cite the libreadline/libeditline case? Readline is a GPLed library authored by the FSF. Editline is a BSD-licensed clone (with a limited feature set) developed by people who weren't happy with Readline's licensing. I think it's an interesting case to consider because of the question of whether an interface is copyrightable, but I think that discussion is best left for another thread. In any case, I believe the generic interface defense is only applicable when the distributor is not distributing a combination that requires selecting one specific implementation as the default. I am not sure the U.S. courts agree.[1][2] Also worthy of note are the opinions of RMS himself[3]. However, it's possible that RMS feels that only visual interfaces should not be protectable by copyright, and programming interfaces should be. To restate: If distributing a statically-linked binary that combines a GPL library with GPL-incompatible code is a violation of the GPL, then shipping *any other combination of files* which constitute a program that, when run, result in a corresponding intermingling of GPL and GPL-incompatible code in memory is also a violation of the GPL. You cannot circumvent the GPL's requirements on source code by shipping your combined work in the form of a GPLed library and a GPL-incompatible program; nor can you circumvent them by writing (or reusing) a GPL interpreter and shipping it together with the GPLed library and your GPL-incompatible script (bytecode). (I'm going to ignore the much hairier RPC question for the moment. :) Because the two libraries are interface-compatible, the FSF is not in a position to forbid people from distributing code that links against libreadline if that code is not licensed GPL-compatibly, because the code could be linked against libeditline instead.[1] Yes, but they are in a position to forbid distributing such code together with readline itself. I hate to say this because I love my bright-line tests, but I think intent matters here. Shipping such code together with readline itself, and nothing else, should be distinguishable from what Debian does, which is ship such code, readline itself, a clone or two of readline, and a whole boatload of other stuff that has nothing to do with any of the above. [1] Apple Computer v. Microsoft Corp., 35 F.3d 1435, 1446-47 (9th Cir. 1994) [2] Lotus Dev. Corp. v. Borland Int'l, 49 F.3d 807, 815 (1st Cir. 1995). [3] http://lpf.ai.mit.edu/Links/prep.ai.mit.edu/demo.final.release -- G. Branden Robinson| The only way to get rid of a Debian GNU/Linux | temptation is to yield to it. [EMAIL PROTECTED] | -- Oscar Wilde http://people.debian.org/~branden/ | pgpAsPb3vSbU7.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tue, May 20, 2003 at 04:15:54AM -0500, Branden Robinson wrote: Is it any help to cite the libreadline/libeditline case? Readline is a GPLed library authored by the FSF. Editline is a BSD-licensed clone (with a limited feature set) developed by people who weren't happy with Readline's licensing. I think it's an interesting case to consider because of the question of whether an interface is copyrightable, but I think that discussion is best left for another thread. In any case, I believe the generic interface defense is only applicable when the distributor is not distributing a combination that requires selecting one specific implementation as the default. I am not sure the U.S. courts agree.[1][2] I don't see how the cases you cite conflict with what I said. In both of the cases, IIRC, the courts found in favor of someone who duplicated a competitor's interface. This seems to support (API vs. user interface question aside) the notion that the generic interface defense *is* applicable when you aren't distributing someone else's copyrighted implementation of the generic interface. However, it does not establish a precedent for the case where you *are* distributing the plaintiff's copyrighted work which provides a given interface. Apple v. Microsoft doesn't mean Microsoft could claim MacOS no longer enjoys copyright protection just because someone cloned the UI. To restate: If distributing a statically-linked binary that combines a GPL library with GPL-incompatible code is a violation of the GPL, then shipping *any other combination of files* which constitute a program that, when run, result in a corresponding intermingling of GPL and GPL-incompatible code in memory is also a violation of the GPL. You cannot circumvent the GPL's requirements on source code by shipping your combined work in the form of a GPLed library and a GPL-incompatible program; nor can you circumvent them by writing (or reusing) a GPL interpreter and shipping it together with the GPLed library and your GPL-incompatible script (bytecode). (I'm going to ignore the much hairier RPC question for the moment. :) Because the two libraries are interface-compatible, the FSF is not in a position to forbid people from distributing code that links against libreadline if that code is not licensed GPL-compatibly, because the code could be linked against libeditline instead.[1] Yes, but they are in a position to forbid distributing such code together with readline itself. I hate to say this because I love my bright-line tests, but I think intent matters here. Shipping such code together with readline itself, and nothing else, should be distinguishable from what Debian does, which is ship such code, readline itself, a clone or two of readline, and a whole boatload of other stuff that has nothing to do with any of the above. I think references to the file name of the GPL'ed library in an application's ELF header constitute pretty damning evidence of the real intent. Your honor, the plaintiff's license is non-binding because I could have used editline instead doesn't sound like much of a defense to me. -- Steve Langasek postmodern programmer pgpJJBQe2gcmd.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, 2003-05-07 at 19:11, Edmund GRIMLEY EVANS wrote: P is not a derived work of GPLLib, but P+GPLLib is likely to be a derived work of GPLLib, in which case it is not allowed to distribute them together. In [EMAIL PROTECTED], I posted the legal definition of a derivative work in the United States at least, taken from Title 17 USC, Section 101. To repeat: A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''. (Title 17 USC, Sec. 101) From the definition, I don't see how it could be argued that P is not a derivative work of GPLLib, unless P happens to be on the same CD-ROM (ftp site, etc.) as GPLLib. I can see (though not agree with) that the binary image created in memory may be a derivative work. But the GPL allows arbitrary use, so there is no license violation. If it dumps core, though, you may not be able to redistribute the core. :-) BTW: Beware DFSG 1 when arguing that P alone is distributable, GPLLib alone is distributable, but together, they are not. This isn't always true, such as with the system components exception to the GPL, but its something to certainly be wary of. I think an interpretation of either that DFSG and GPL that renders the GPL non-free is strange. However, you could certainly distribute P on its own if you could reasonably claim that P is useful without GPLLib. I'll further argue that P is not based upon GPLLib in any meaningful manner; it includes absolutely no part of GPLLib. There are other implementations of grep, ls, etc, so it would certainly be all right to distribute the GPL-incompatible shell script on its own. Sure. Assuming, of course, that the shell script doesn't use any GNU extensions, which is quite a big assumption. Many scripts use GNU extensions. Especially on Debian, which is a GNU system after all. How many other tars accept a j option, for example? It ain't in SUSv2. Neither is z, for that matter. which is probably doable if the script makes relatively minor use of grep, etc I think you'd have a very hard time finding scripts which make minor use of GPL utilities. Even our cat program (like everything else in coreutils) is GPL. So is our echo program. signature.asc Description: This is a digitally signed message part
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED]: However, you could certainly distribute P on its own if you could reasonably claim that P is useful without GPLLib. I'll further argue that P is not based upon GPLLib in any meaningful manner; it includes absolutely no part of GPLLib. If P is useless without GPLLib, then it might be argued that by distributing P you are encouraging people to link it with GPLLib and are thus indirectly distributing a combined work P+GPLLib which infringes GPLLib's licence. That's why the existence of alternative implementations of GPLLib is important. (Even the existence of alternative GPL implementations might help.) However, if Debian were to distribute P and GPLLib in such a way that P uses GPLLib by default, then I would guess there is potentially a problem even if there are alternative non-GPL implementations of the library. which is probably doable if the script makes relatively minor use of grep, etc I think you'd have a very hard time finding scripts which make minor use of GPL utilities. Even our cat program (like everything else in coreutils) is GPL. So is our echo program. I suppose I should explain what I mean by minor, though I'm not quite sure myself. Perhaps one could compare with the situation where someone distributes a summary of someone else's novel, compared with where someone distributes a criticism of the novel that also summarises it in the course of criticising it. I don't have any legal evidence for this idea, but I suspect that in addition to how much is taken from or used from another work, what else a work contains may be relevant in deciding whether it is a derived or an independent work. Edmund
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, May 07, 2003 at 09:39:25PM -0500, Branden Robinson wrote: On Wed, May 07, 2003 at 01:12:09PM -0400, Anthony DeRobertis wrote: On Wednesday, May 7, 2003, at 01:50 AM, Branden Robinson wrote: Or are you wanting to restrict the problem domain to cases where an interface innovated in a GPLed library hasn't been cloned yet? Given: 1) Library GPLLib is under the GPL 2) Perl module Iface provides an interface to various implementations of similar features, and the user selects which implementation to use 3) Perl modules PM uses GPLLib to implement Iface 4) Perl program P is under a GPL-incompatible license Question: Is is permissible for P to use PM through Iface? I would say yes, and I think that 2) is the critical issue. Edmund GRIMLEY EVANS raised a good point. GPL clause 0 says The act of running the Program is not restricted. Your question should be rephrased as: Question: Does the GPL permit people to distribute P with GPLLib? The answer probably depends on the circumstances, but distributing alternative implementations of Iface with P, not just the GPLLib implementation of Iface, makes the answer an almost certain yes. -- G. Branden Robinson| If you're handsome, it's flirting. Debian GNU/Linux | If you're a troll, it's sexual [EMAIL PROTECTED] | harassment. http://people.debian.org/~branden/ | -- George Carlin pgpz2Ctve4vR4.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, May 07, 2003 at 12:50:30AM -0500, Branden Robinson wrote: On Mon, Apr 28, 2003 at 05:58:15PM -0500, Steve Langasek wrote: Any chance you'd care to comment on the underlying question of whether Debian should or should not accede to the FSF's claim that GPL modules for interpreted languages demand GPL scripts? I believe Anthony and I are at an impasse; we simply disagree on the relative weight that should be given to various factors involved here, so no consensus is likely to be forthcoming between the two of us. I've been away from the list for a few days, but using Mutt to limit the message view to subjects including the string interp reveals no messages I haven't already read. I recall a message from you referring to the GPL FAQ which confusingly talks about whether people can run GPL-incompatible scripts with a GPLed interpreter, which only serves to cloud the issue since The act of running the Program is not restricted. Apparently, I haven't expressed myself very clearly. Yes, I'm not saying a user running such a script would be violating the GPL; the GPL doesn't speak to running the program, and the GPL is non-binding on users. I'm also not talking about any cases where a script is distributed separately from the interpreter, or where the bindings for the interpreted language are distributed separately from the GPL library that they make available to the script; these are gray areas, and not germane to the activities of Debian or its redistributors. I am specifically addressing the case where: - a library, libfoo, available under the GPL - an interpreter, pargle, available under a GPL-compatible license - a module that provides bindings for scripts written in pargle to use libfoo, also available under a GPL-compatible license from a different upstream - a script, fooadmin.prg, under a GPL-incompatible license are all distributed together in such a manner that running the script causes pargle to load libfoo for use by fooadmin.prg. The *act* of running fooadmin.prg is not a violation; but the facts of how this code is combined into a single runtime executable at the instant of running, without any conscious intent on the part of the user, show, I believe, that the distribution of such a combined work constitutes a violation on the part of the distributor. The GPL FAQ supports this interpretation, saying, If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone. However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a facility; libraries that are accessed in this way are linked dynamically with the Java programs that call them. Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together. A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on. The FSF's statement is really much farther-reaching than I believe it has any grounds to be (see the gray areas above), but if it has any merit at all, the case is strongest when distributing all the components together in a single product (operating system or otherwise). So my questions for debian-legal are, Do you believe the GPL FAQ presents a legally valid interpretation of the GPL, as it pertains to the case of combined distribution described above? Do you believe this interpretation is *applicable* to GPL code that is copyright FSF, to code that is copyright MySQL AB, and to GPL code in general? Why or why not? If this interpretation is applicable in some or all cases, could Debian be in violation for using GPL commandline utilities from GPL-incompatible scripts? If not, how are commandline utilities different from language bindings for an interpreted language?
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Mon, Apr 28, 2003 at 05:58:15PM -0500, Steve Langasek wrote: Any chance you'd care to comment on the underlying question of whether Debian should or should not accede to the FSF's claim that GPL modules for interpreted languages demand GPL scripts? I believe Anthony and I are at an impasse; we simply disagree on the relative weight that should be given to various factors involved here, so no consensus is likely to be forthcoming between the two of us. I've been away from the list for a few days, but using Mutt to limit the message view to subjects including the string interp reveals no messages I haven't already read. I recall a message from you referring to the GPL FAQ which confusingly talks about whether people can run GPL-incompatible scripts with a GPLed interpreter, which only serves to cloud the issue since The act of running the Program is not restricted. Is it any help to cite the libreadline/libeditline case? Readline is a GPLed library authored by the FSF. Editline is a BSD-licensed clone (with a limited feature set) developed by people who weren't happy with Readline's licensing. Because the two libraries are interface-compatible, the FSF is not in a position to forbid people from distributing code that links against libreadline if that code is not licensed GPL-compatibly, because the code could be linked against libeditline instead.[1] (Incidentally, there appear to be at least *two* clones of Readline in Debian: libedit-dev - BSD editline and history libraries (development files) libedit2 - BSD editline and history libraries libeditline-dev - Line editing library similar to readline - developer files libeditline0 - Line editing library similar to readline - runtime ) So, following this reasoning, if there is a GNU BASIC interpreter licensed under the GPL, this does not mean that Debian cannot distribute GPL-incompatible BASIC programs in packages, because there are other BASIC interpreters in Debian that are more liberally licensed. Or are you wanting to restrict the problem domain to cases where an interface innovated in a GPLed library hasn't been cloned yet? -- G. Branden Robinson|The first thing the communists do Debian GNU/Linux |when they take over a country is to [EMAIL PROTECTED] |outlaw cockfighting. http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks pgpyZ4U9olEPw.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wednesday, May 7, 2003, at 01:50 AM, Branden Robinson wrote: Or are you wanting to restrict the problem domain to cases where an interface innovated in a GPLed library hasn't been cloned yet? Given: 1) Library GPLLib is under the GPL 2) Perl module Iface provides an interface to various implementations of similar features, and the user selects which implementation to use 3) Perl modules PM uses GPLLib to implement Iface 4) Perl program P is under a GPL-incompatible license Question: Is is permissible for P to use PM through Iface? I argue yes because I don't see how P could _possibly_ be held to be a derived worked of GPLLib, and thus is not subject to the GPLs restrictions. I further argue that if the answer is no, there is no good reason to say changing the language from perl to shell script should matter, and thus no GPL-incompatibly licensed program can use GNU grep, ls, etc.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED]: Given: 1) Library GPLLib is under the GPL 2) Perl module Iface provides an interface to various implementations of similar features, and the user selects which implementation to use 3) Perl modules PM uses GPLLib to implement Iface 4) Perl program P is under a GPL-incompatible license Question: Is is permissible for P to use PM through Iface? Yes, of course, because the GPL doesn't restrict use! I argue yes because I don't see how P could _possibly_ be held to be a derived worked of GPLLib, and thus is not subject to the GPLs restrictions. P is not a derived work of GPLLib, but P+GPLLib is likely to be a derived work of GPLLib, in which case it is not allowed to distribute them together. However, you could certainly distribute P on its own if you could reasonably claim that P is useful without GPLLib. I further argue that if the answer is no, there is no good reason to say changing the language from perl to shell script should matter, and thus no GPL-incompatibly licensed program can use GNU grep, ls, etc. There are other implementations of grep, ls, etc, so it would certainly be all right to distribute the GPL-incompatible shell script on its own. Debian would distribute the shell script with GNU grep, ls, etc, so you'd have to find another argument why the script is a separate work from grep, ls, etc, which is probably doable if the script makes relatively minor use of grep, etc to do something independently interesting, but would be a bit harder if the script implements a graphical interface to grep. That's how I see it, anyway. Edmund
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, May 07, 2003 at 01:12:09PM -0400, Anthony DeRobertis wrote: On Wednesday, May 7, 2003, at 01:50 AM, Branden Robinson wrote: Or are you wanting to restrict the problem domain to cases where an interface innovated in a GPLed library hasn't been cloned yet? Given: 1) Library GPLLib is under the GPL 2) Perl module Iface provides an interface to various implementations of similar features, and the user selects which implementation to use 3) Perl modules PM uses GPLLib to implement Iface 4) Perl program P is under a GPL-incompatible license Question: Is is permissible for P to use PM through Iface? I would say yes, and I think that 2) is the critical issue. Without 2), this procedure looks like an effort to create a Perl module Iface which is a shim to let other programs P make themselves infrining derivatives of GPLLib. But with 2), this procedure looks like an effort to create an abstraction layer Iface, which is a shim to let other programs P interoperate with a de-facto standard. Programs P cannot *necessarily* be derivative works of GPLLlib in this scenario, and therefore such programs are not *necessarily* infringing of the GNU GPL at the time they are distributed. This is my opinion, and I cannot claim to speak for the FSF, but the above sounds exactly like the libreadline/libeditline situation to me, and to my knowledge the FSF has never gone after people who *weren't* using libreadline-as-libreadline with a GPL-incompatible application. NcFTP is an example of a program that did just that, according to the FSF. -- G. Branden Robinson| The software said it required Debian GNU/Linux | Windows 3.1 or better, so I [EMAIL PROTECTED] | installed Linux. http://people.debian.org/~branden/ | pgp3ovUNOX0N9.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Mon, 2003-04-28 at 18:58, Steve Langasek wrote: Any chance you'd care to comment on the underlying question of whether Debian should or should not accede to the FSF's claim that GPL modules for interpreted languages demand GPL scripts? I think he's too busy taking over the world to do that. I believe Anthony and I are at an impasse; Seems that way. so no consensus is likely to be forthcoming between the two of us. At least not without some further arguments coming to light. signature.asc Description: This is a digitally signed message part
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Sat, Apr 26, 2003 at 02:35:30AM -0400, Anthony DeRobertis wrote: A copyright holder has legal standing to sue anyone he damn well pleases. Not true; questions like this are frequently decided in the early phases of civil trials, and not always in favor of the plaintiff. Standing is a legal concept and a matter of law that is litigated by attorneys and decided by judges, often with reference to statutes which *define* standing in various types of cases. Please consult a legal dictionary. -- G. Branden Robinson| There's no trick to being a Debian GNU/Linux | humorist when you have the whole [EMAIL PROTECTED] | government working for you. http://people.debian.org/~branden/ | -- Will Rogers pgp7Imaw0lTVU.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Mon, Apr 28, 2003 at 05:07:03PM -0500, Branden Robinson wrote: On Sat, Apr 26, 2003 at 02:35:30AM -0400, Anthony DeRobertis wrote: A copyright holder has legal standing to sue anyone he damn well pleases. Not true; questions like this are frequently decided in the early phases of civil trials, and not always in favor of the plaintiff. Standing is a legal concept and a matter of law that is litigated by attorneys and decided by judges, often with reference to statutes which *define* standing in various types of cases. Any chance you'd care to comment on the underlying question of whether Debian should or should not accede to the FSF's claim that GPL modules for interpreted languages demand GPL scripts? I believe Anthony and I are at an impasse; we simply disagree on the relative weight that should be given to various factors involved here, so no consensus is likely to be forthcoming between the two of us. -- Steve Langasek postmodern programmer pgppkKtOJt0Qz.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Sun, Apr 20, 2003 at 08:02:45PM -0400, Anthony DeRobertis wrote: My question is, how is a package that depends on DBD::mysql materially different from a compiled program that links dynamically against libmysqlclient? A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''. (Title 17 USC, Sec. 101) I can see how it can be argued that dynamic linking is creating a derivative work, because it actually involves copying _very small_ amounts of the library into the executable. I'm not sure if I agree with that; but let's assume it true for a moment. I am not arguing that dynamic linking creates a derivative work, and I'm not sure the FSF is, either. I *am* arguing that it is within the purview of the GPL to impose restrictions on redistribution of dependent works whether or not these are derivative works; and the FSF's GPL FAQ asserts that they are doing so. If you think that is a creation of a derivative work (and thus violates the GPL), then I have a much bigger GPL violation for you to worry about. It's with an interpreter known as bash. Many bash scripts rely on functionality provided by bash modules such as grep, gawk, and even tar. Why is this OK, if the DBI/DBD stuff isn't? The mechanisms are different; the effect is the same. Are you certain that a copyright holder who subscribed to this interpretation would *not* have legal standing to sue someone for bundling their GPLed 'mygrep' with a proprietary script that invokes it? There are two differences, however. First, we know of no copyright holders who assert such a requirement in the case of shell scripting interfaces; whereas in the case of GPL modules that are loaded into memory by interpreters, there is at least one prominent copyright holder who asserts this requirement. Second, in the case of shell utilities, it is the original authors who have exposed a certain interface (the exec() interface) for use by the system; whereas in the case of a Perl module, the wrapper that provides the interface used by Perl scripts may be written by a third party (as is the case with DBD::mysql), and its existence cannot be construed as an implicit endorsement on the part of the authors of the original library. The truth is that much of this is very fuzzy; but there are some reasons to believe we are acting in good faith when we use GPL shell utilities from GPL-incompatible scripts, and there are also some reasons (such as the statements in the GPL FAQ) to believe this argument would not hold up as well when the GPL lib is incorporated into an extension to an interpreted language. Regards, -- Steve Langasek postmodern programmer pgpcAGcoCVALx.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Sat, 2003-04-26 at 01:17, Steve Langasek wrote: I am not arguing that dynamic linking creates a derivative work, and I'm not sure the FSF is, either. I *am* arguing that it is within the purview of the GPL to impose restrictions on redistribution of dependent works whether or not these are derivative works; and the FSF's GPL FAQ asserts that they are doing so. Considering DFSG 1, I _sincerely_ hope they are not doing that! In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. a 'work based on the Program' means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. So, unless the program is a derivative work, it doesn't fall under the GPL's requirements. Any license that claimed otherwise would, I think, fail DFSG 1. Are you certain that a copyright holder who subscribed to this interpretation would *not* have legal standing to sue someone for bundling their GPLed 'mygrep' with a proprietary script that invokes it? A copyright holder has legal standing to sue anyone he damn well pleases. IANAL, but I think said suit would be lost. The point is, of course, that we have _hundreds_ of scripts like this, and we seem to (by inaction, at least) judge that OK. There are two differences, however. First, we know of no copyright holders who assert such a requirement in the case of shell scripting interfaces; whereas in the case of GPL modules that are loaded into memory by interpreters, there is at least one prominent copyright holder who asserts this requirement. Sure. This does lessen lawsuit risk, but the point is anyone could get ticked off and decide to suddenly try and enforce that. If it's illegal, we shouldn't be doing it --- whether someone currently complains or not. Second, in the case of shell utilities, it is the original authors who have exposed a certain interface (the exec() interface) for use by the system; whereas in the case of a Perl module, Hold on a sec. It's pretty clear that the authors of libmysqlclient have exposed a certain interface (the C API) for use by other programs on the system. The perl module is just using that documented, public interface. The truth is that much of this is very fuzzy; but there are some reasons to believe we are acting in good faith when we use GPL shell utilities from GPL-incompatible scripts, and there are also some reasons (such as the statements in the GPL FAQ) to believe this argument would not hold up as well when the GPL lib is incorporated into an extension to an interpreted language. What, actually, is the difference? That the kernel happens to load libraries into the same address space as programs, but separate programs have separate address space? Does that mean that using those shell scripts on Mac OS before 10 would be illegal because all processes share one address space? Or that shared memory is a problem? Would that be any different than shared disk space, in light of mmap? Why does bash's or dpkg's use of execve(2) for a shell script form a magic copyright barrier, while Perl's use of AutoLoader does not? signature.asc Description: This is a digitally signed message part
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED]: If you think that is a creation of a derivative work (and thus violates the GPL), then I have a much bigger GPL violation for you to worry about. It's with an interpreter known as bash. Another example is the Linux kernel and GPL-incompatible programs that use kernel services. This is mentioned in /usr/src/linux/COPYING: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. (What does it mean by normal system calls? I assume it means system calls of an ordinary, released kernel, as opposed to ones that have been added specially to support some GPL-incompatible program. However, it could mean standard Unix system calls, as opposed to functions that are specific to Linux.) [ Sorry for being so sarcastic in the last paragraph. But we really need to decide when program A benefiting from features of program B creates a derivative work, if ever. ] It's a difficult problem. Edmund
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, 2003-04-16 at 19:19, Steve Langasek wrote: My question is, how is a package that depends on DBD::mysql materially different from a compiled program that links dynamically against libmysqlclient? A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''. (Title 17 USC, Sec. 101) I can see how it can be argued that dynamic linking is creating a derivative work, because it actually involves copying _very small_ amounts of the library into the executable. I'm not sure if I agree with that; but let's assume it true for a moment. Now, we're talking about a perl script that contains _no_ part of the other work. It's hard to see how it could --- by including no part of the work whatsoever --- be a derivative work. Sure, it gets some functionality from it, through a standardized API, which works with several databases. If you think that is a creation of a derivative work (and thus violates the GPL), then I have a much bigger GPL violation for you to worry about. It's with an interpreter known as bash. Many bash scripts rely on functionality provided by bash modules such as grep, gawk, and even tar. Why is this OK, if the DBI/DBD stuff isn't? The mechanisms are different; the effect is the same. I've even heard rumors of a program which links against GPL libraries and yet depends on functionality provided by modules with names like openssl.preinst which are apparently under the OpenSSL license, which is not GPL compatible. Oh, yeah, and there is even that apache-ssl module for that relies on OpenSSL's x509 stuff. Once again, the mechanisms are different; the effect is the same. [ Sorry for being so sarcastic in the last paragraph. But we really need to decide when program A benefiting from features of program B creates a derivative work, if ever. ] http://www.pbwt.com/Attorney/files/ravicher_1.pdf http://www.linuxjournal.com/article.php?sid=6366 signature.asc Description: This is a digitally signed message part
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Hi Raphael, On Tue, Apr 15, 2003 at 10:08:59PM +0200, Raphael Hertzog wrote: Le Tue, Apr 15, 2003 at 02:29:52PM -0500, Steve Langasek écrivait: The latest version of libdbd-mysql-perl build-depends on libmysqclient-dev. I'm afraid that, although this fixed the FTBFS bug, it potentially renders some software in our archive non-distributable. Because the new libmysqlclient12 package is licensed under the GPL, any GPL-incompatible apps which depend on libdbd-mysql-perl would be in violation of the libmysqlclient12 license. I disagree completely with this bug. The perl module links to libmysqlclient12, but the perl module is available under the GPL so it's ok. I agree that the perl module itself is not violating the license of libmysqlclient12. Any other program/script uses DBD::mysql but doesn't link to libmysqlclient12 ... so there's no problem on that side either. Here, I have to disagree. You draw a distinction based on linking, but this word only appears only once in /usr/share/common-licenses/GPL: as a footnote referring to the fact that the LGPL *does* allow linking to proprietary apps. Please note that if you are right, this would be a gaping loophole in the GPL: it would allow people to circumvent the GPL, just by wrapping any code they want as a module for an interpreted language. Fortunately for the goals of the FSF, this is not the case. If you (in this case: Debian) are distributing GPL software, under copyright law the GPL can (and does) place restrictions on your distribution of other software together with the GPL software; and under the DFSG, this is acceptable because the GPL only restricts redistribution of other software that's *related* to the GPL code programmatically (it doesn't taint independent software distributed alongside it). This establishes that a license can place restrictions on scripts built around the software and still be considered free, but of course we must also show that the GPL actually has such a restriction. I believe the key is in GPL section 2: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: [...] b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. We are linking scripts that depend on libdbd-mysql-perl in a manner that's conceptually equivalent to a dynamically-linked binary: we have a programmatic link, in the form of a Depends: line in our package system, that guarantees that when the user runs the script as we distribute it, GPL code is loaded into memory. This means that any scripts *we* distribute that Depend: on libdbd-mysql-perl must comply with the terms of the GPL. This is also not inconsistent with other views of the GPL; anyone else, who is not distributing the MySQL libraries, can distribute such scripts freely under terms of their choice: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. I have not had a chance to look through the list of packages that depend on libdbd-mysql-perl to see if any of these are actually GPL-incompatible; however, libmysqlclient10 has been reintroduced to the archive for just this sort of situation. Please consider changing your build-dep back to libmysqclient10-dev and dropping the libssl-dev build-dep. Not until you can convince me that my interpretation of the license is clearly wrong. Please let me know if you find problems with any of my reasoning above. Since the GPL makes no reference to technical details of linking mechanisms, however, I'm confident that any interpretation that permits distributing GPL-incompatible perl scripts together with a GPL perl module would also permit distributing GPL-incompatible compiled binaries together with GPL libraries. -- Steve Langasek postmodern programmer pgpZ9SwOtPSNJ.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Thu, Apr 17, 2003 at 12:02:31AM +0200, Raphael Hertzog wrote: Le Wed, Apr 16, 2003 at 03:15:19PM -0500, Steve Langasek écrivait: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: [...] b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. I'm sorry but a perl script using DBI/DBD::mysql doesn't contain DBD::mysql and is not derived from DBD::mysql ... and it doesn't contain libmysqlclient12 and it isn't derived from libmysqlclient12. This is even more clear when you consider the fact that a perl script can use DBI as a general DB layer without knowing which driver is used behind the doors. My question is, how is a package that depends on DBD::mysql materially different from a compiled program that links dynamically against libmysqlclient? The mechanisms are different; the effect is the same. I believe that any sane interpretation of the GPL must treat these cases as equivalent. You seem to agree, though you disagree with me on how these two cases should be treated. Please let me know if you find problems with any of my reasoning above. The fact is that I think that you extend too easily the meaning of contains and is derived. While a program directly linked can be considered like a derived work of the library, I don't think that you can say that program A is a derived work of libX if A is linked to libY which itself uses libX. Yes this means that you can go around the limitation of the GPL... but I'm confident that a fake library used only in that intent would be considered as violating the spirit of the GPL. However when that intermediate library serves a generic purpose like DBI, I doubt that we violate the spirit of the GPL. So you don't believe that the letter of the GPL prohibits binary-only distribution of an application, together with a GPL library that it's dynamically linked against? I believe there is room for argument here; however, I also believe that Debian has a responsibility to err on the side of caution when there is room for argument in interpreting a license. As to the spirit of the GPL, please read http://www.fsf.org/licenses/gpl-faq.html#IfInterpreterIsGPL. This is the opinion of the FSF; I'm inclined to believe, based both on past litigation and on the fact of their strange decision to relicense under the GPL that they will take a stance that's as hard-line as or more so than that of the FSF. The packages I listed in the bug report are not just consumers of the intermediary DBI library; through decisions made by the package maintainers, there are explicit dependencies on the DBD::mysql module. Since the GPL makes no reference to technical details of linking mechanisms, however, I'm confident that any interpretation that permits distributing GPL-incompatible perl scripts together with a GPL perl module would also permit distributing GPL-incompatible compiled binaries together with GPL libraries. Note that the perl module is not GPL only, but GPL/Artistic (like most perl modules). I don't know how much trouble that brings ... :-) In this case, I think it saves trouble: if DBD::mysql were GPL-only, then the same argument applies even if you link against the LGPL version of libmysqlclient. Does your reasoning also mean that each time a proprietary perl script is using a standard perl module, it uses the module under the terms of the Artistic license and not under the GPL because it can't comply with the GPL ? Only if the proprietary perl script is bundled with the perl module. If the proprietary perl script isn't bundled, both licenses allow this use (the FSF seems to disagree here, but I don't think they have legal standing to enforce their position against someone who isn't a distributor of the GPL code). -- Steve Langasek postmodern programmer pgphug8uTvxWG.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Le Tue, Apr 15, 2003 at 02:29:52PM -0500, Steve Langasek écrivait: The latest version of libdbd-mysql-perl build-depends on libmysqclient-dev. I'm afraid that, although this fixed the FTBFS bug, it potentially renders some software in our archive non-distributable. Because the new libmysqlclient12 package is licensed under the GPL, any GPL-incompatible apps which depend on libdbd-mysql-perl would be in violation of the libmysqlclient12 license. I disagree completely with this bug. The perl module links to libmysqlclient12, but the perl module is available under the GPL so it's ok. Any other program/script uses DBD::mysql but doesn't link to libmysqlclient12 ... so there's no problem on that side either. I have not had a chance to look through the list of packages that depend on libdbd-mysql-perl to see if any of these are actually GPL-incompatible; however, libmysqlclient10 has been reintroduced to the archive for just this sort of situation. Please consider changing your build-dep back to libmysqclient10-dev and dropping the libssl-dev build-dep. Not until you can convince me that my interpretation of the license is clearly wrong. I'm ccing debian-legal to have further input. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com
