Re: On interpreting licences (was: KDE not in Debian?)
This is an expanded version of my original response to this message. Andreas indicated that he didn't understand why what I was saying was significant. On Mon, Feb 07, 2000 at 07:10:32PM -0500, Andreas Pour wrote: What does it mean for a program to accompany itself? Why do you raise this point? It's not that the program accompanies itself. The paragraph of Section 3 in question deals in terms of components and modules, not entire executables. The GPL uses the term module exactly once, and component and components once each. Here's the paragraph where this happens: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Note that this paragraph follows a couple clauses which require the complete corresponding source code for an executable before you can distribute the executable: Sections 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, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, ... If you bother to read that, you'll see that (*) The source code must be complete. (*) The source code must correspond to the machine code. (*) Source code must be provided for every piece of the program. (*) There's a special exception for a proprietary libc if that libc accompanies a major component of the operating system which is not distributed with the GPLed program. The requirement that the source code must be complete conflicts with the idea that you can distribute a working copy of kghostscript yet fail to distribute all the source code for a working copy of kghostscript. I suppose that Andreas imagines that kghostscript being split up into multiple files somehow makes a difference. So, when Andreas says: So in the hypothetical case we discuss, libc is a component (although statically linked, the library is a separate binary inside the executable, if I understand the linking process correctly) which accompanies the GPL'd component inside the executable. I must assume that he's misread the GPL, because libc is not a component in the sense that the GPL uses the term. And (looking at the phrase GPL'd component) the way the GPL uses the term, a component wouldn't be licensed under the GPL. In the terms of the GPL, a proprietary libc would be an anything that is normally distributed with a major component of the operating system. There's really no point discussing the logic of this sentence that Andreas wrote -- it just plain doesn't relate to the GPL in any meaningful fashion. If I rewrote it so that we called libc a module which accompanies the GPLed module inside the executable, then the sentence would make sense. But in that case it doesn't make any interesting points... Andreas goes on to say: In any event, as I look up the definition of accompany in Webster's New Universal Unabridged Dictionary (2d ed. 1983), I get: (1) to go with or attend as a companion or associate on a journey, a walk, etc.; as, a man *accompanies* his friend to church, or on a tour. (2) to be with, as connected; to attend; as, pain *accompanies* disease. Syn: attend I have no disagreements with this, and am only quoting it so that Andreas can't claim that I've ignored it. And attend means (taking the only relevant definition): (3) to accompany as a circumstance or result; to be consequent to, from connection of cause, as fever *attends* a cold; a measure *attended* with ill effects. Likewise I have no problem with this as a definition. Looking to the first definition of accompany, I think it fair to say that the libc goes with or attends as a companion the GPL executable as it is distributed. No problem there. But why would this be relevant, and to what? The answer to that question seems to reside in Andreas's confusion about what a major component of the OS is that the GPLed program must
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: [ ... ] On Mon, Feb 07, 2000 at 07:10:32PM -0500, Andreas Pour wrote: What does it mean for a program to accompany itself? Why do you raise this point? It's not that the program accompanies itself. The paragraph of Section 3 in question deals in terms of components and modules, not entire executables. The GPL uses the term module exactly once, and component and components once each. Here's the paragraph where this happens: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Note that this paragraph follows a couple clauses which require the complete corresponding source code for an executable before you can distribute the executable: Sections 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, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, ... If you bother to read that, you'll see that (*) The source code must be complete. Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. (2) to have the capacity for holding. (3) to be equal or equivalent to; as, a gallon *contains* four quarts; Now, please explain how the executable work which I am distributing (kghostview which is dynamically linked to Qt) has in it, holds, encloses or includes, has the capacity for holding, or is equal or equivalent to, the Qt library. Sure, the Qt library can later be added to it -- like sugar to the gallon of water -- but is not contained in it. That's why when you distribute a dynamically-linked kghostview you don't have to distribute Qt source code. Now of course this executable work no more contains Qt if it is distributed on the same CD. (However, in case it is on the same CD, the special exception would not apply.) If you don't like that result, I suggest you talk to FSF about changing the language of the GPL. (*) The source code must correspond to the machine code. (*) Source code must be provided for every piece of the program. Of course this depends on how you define program. As Section 3 defines it, Program is the GPL'ed work, and work based on the Program would be kghostview (but not Qt, since that is not a work based on ghostview). If this is confusing, bear in mind that the Program refers only to source code -- the ghostview code in the example is source code, and it has been modified by adding some more code, but Qt has not been added to it. For copyright purposes, kghostview source code is not a derived work of Qt, any more than the Yahoo directory is a derived work of the Internet. (*) There's a special exception for a proprietary libc if that libc accompanies a major component of the operating system which is not distributed with the GPLed program. Lbc *is* a major component of the OS. The requirement that the source code must be complete conflicts with the idea that you can distribute a working copy of kghostscript yet fail to distribute all the source code for a working copy of kghostscript. Two flaws in this analysis. First, you don't have to distribute a working copy of kghostscript; in fact
Re: Compuclick Ltda - Debian Vendor Page
[cc'ed to legal too] Jordi said: On Tue, Feb 08, 2000 at 05:49:07PM +1100, Craig Small wrote: COMPUCLICK IS AUTHORIZED MANUFACTURER OF THE OFFICIAL CD OF DEBIAN AND BY EACH CD THAT YOU BUY TO US YOU CONTRIBUTE TO AUTOMATICAMENTE A DOLAR TO ALL PROJECTS DEBIAN/GNU BY INTERVAL OF FOUNDATION SPI Two things: I'm not too sure about the authorized part, but that may be the translation (Any other webmasters able to help here?) If your doubt regards author (of a book, whatever) or permission, it's permission. If I'm saying nonsense, I'll bury myself in the backyard ;) Oh, maybe you are trying to say that they don't need permission from Debian to sell official CD's? We don't authorize anyone to do anything. I was just concerned that having authorized there may make people think we have some sort of special relationship with the vendor (over and above merely pumping out an ISO image) and we endorse them. - Craig -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 Eye-Net Consulting http://www.eye-net.com.au/ [EMAIL PROTECTED] MIEEE [EMAIL PROTECTED] Debian developer [EMAIL PROTECTED]
Re: New OPL Draft
On Mon, Feb 07, 2000 at 04:57:14PM -0700, Richard Stallman wrote: As I understand your proposed license, it has no problems falling within the existing DFSG. This is not true for some of the others; whether Debian wants to extend its penumbra in the manner I described is something that will have to be extensively discussed. I'd certainly like your input on this issue; I would be happy to give my opinion, once I see the specific issue. Do you believe it is inconsistent with the philosophy of the Free Software movement to accept any more restrictions on classes of computer-handled data that are not executable code than we do on executable code? -- G. Branden Robinson| You should try building some of the Debian GNU/Linux | stuff in main that is modern...turning [EMAIL PROTECTED] | on -Wall is like turning on the pain. roger.ecn.purdue.edu/~branden/ | -- James Troup pgp8ua89vTlO9.pgp Description: PGP signature
Re: x3270 licenses
On Mon, Feb 07, 2000 at 04:14:52PM +0100, Henning Makholm wrote: Well, I can't argue with that. But I'm happy for not being the judge who - in these days of digital typesetting - must decide when something is an alternative representation of a font and when it is just a document which happens to contain every letter in the alphabet and enough text to exhibit a selection of common kerning pairs... There is jurisprudential precedent on this issue, at least in the United States.[*] It has been ruled that typefaces are not copyrightable, but fonts are. Note the difference. The typeface is what your eyes see. A font is a set of instructions, similar to a computer program, for generating a typeface given a set of input parameters. Things like hinted fonts are very complex indeed, as most of us know; the same font can produce quite distinct typefaces at 6 points and 36, for instance. Simple bitmapped fonts are not effectively copyrightable, IIRC. (All someone has to do is arrange for every glyph to be displayed, and then reverse-engineer it.) Video card manufacturers, for instance, cannot meaningfully assert copyright on VGA BIOS fonts because these are just bitmapped typefaces, not proper fonts. There is a world of difference between bitmapped fonts and hinted fonts like Type 1. Adobe has built an empire on this distinction. [*] This is to the best of my knowledge, which is a few years old, but which I regarded as being from a reputable source. Sorry, I don't have a cite. -- G. Branden Robinson| Debian GNU/Linux |Never attribute to malice that which can [EMAIL PROTECTED] |be adequately explained by stupidity. roger.ecn.purdue.edu/~branden/ | pgpvecAldILnr.pgp Description: PGP signature
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: If I may pick a nit: For an executable work, complete source code means all the source code for all modules it contains, *plus any associated interface definition files*, plus the scripts used to control compilation and installation of the executable. So a dummy library would indeed fill this requirement. However such a dummy library would be an open admission there's a problem. As such, I suspect we'll never see one. This overglorified legal language pissing contest has gone on long enough. Everybody arguing at this point is pretty much repeating themselves. Right or wrong, the others arguing back are no longer listening if ever they were. And at any rate, it seems this list's audience is much smaller than it was. Due to misconfiguration or whatever else I cannot say--I've had people tell me they're on this list (kde-licensing) and have still not seen this thread appear there. Specifically representatives from Troll Tech are not present to my knowledge. In other words, you're all arguing syntactics and semantics for your own benefits, rather than the benefit of KDE, Debian, Troll Tech, or the Free Software community. Give it a rest people. This issue is not going to be resolved here in this forum. You're all wasting your breath on all sides and only adding fuel to the fires. Keep it up and someone is going to burn down the forest. -- Joseph Carter [EMAIL PROTECTED] Debian Linux developer http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43 http://www.debian.org20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 * Knghtbrd crosses his toes Knghtbrd (if I crossed my fingers it would be hard to type) pgp7jvacOB35k.pgp Description: PGP signature
Re: On interpreting licences (was: KDE not in Debian?)
I share similar views to Mr. Hutton. Allegations have been made that KDE is responsible of GPL abuse and copyright violation. The fact that the GPL is generally misunderstood has served to amplify these allegations. It took me a considerable amount of time to find Andreas Pour's arguments in the sea of confusion that surrounds this issue. Now having found them and being convinced by them that no GPL abuse or copyright violation exists I feel that instead of being silenced he very much deserves to be heard. BFN, Don. On Wed, 09 Feb 2000, Steve Hutton wrote: On Tue, 08 Feb 2000, Joseph Carter wrote: This overglorified legal language pissing contest has gone on long enough. Everybody arguing at this point is pretty much repeating themselves. Right or wrong, the others arguing back are no longer listening if ever they were. And at any rate, it seems this list's audience is much smaller than it was. Due to misconfiguration or whatever else I cannot say--I've had people tell me they're on this list (kde-licensing) and have still not seen this thread appear there. Nobody else is listening, therefore the posters should quit arguing with each other? Interesting hypothesis and conclusion :-) I for one have rather enjoyed Mr. Pour's eloquent and reasoned analysis. The GPL is one of the most vague pieces of text of I've ever read, and the fact that these arguments about what it means go on for so long just underscore the point. I find it particularly amusing when people continually declare the GPL says this or that, and Mr. Pour points out that the license in fact contains no such language. More humorous are the frequent implications that the GPL is some kind of mutable license, subject to grow and change depending upon what its author says he meant when he wrote it. I take that back. It's more sad than funny. Steve
Re: Compuclick Ltda - Debian Vendor Page
On Wed, Feb 09, 2000 at 01:30:12PM +1100, Craig Small wrote: COMPUCLICK IS AUTHORIZED MANUFACTURER OF THE OFFICIAL CD OF DEBIAN AND BY EACH CD THAT YOU BUY TO US YOU CONTRIBUTE TO AUTOMATICAMENTE A DOLAR TO ALL PROJECTS DEBIAN/GNU BY INTERVAL OF FOUNDATION SPI What kind of crap is this? Who taught this person English? Binding legal terms should be written in clear, unambiguous, grammatic, and spell-checked language. * An indefinite article is required before AUTHORIZED. To use the definite article would be false. * BY EACH CD THAT YOU BUY TO US is some of the worst preposition abuse I've ever seen. The phrase is nonsensical. * YOU CONTRIBUTE TO should not be followed by an adverb, if that's what that piece of subsequent garbage is. * AUTOMATICAMENTE isn't even a word. * DOLAR isn't a word, either. * ALL PROJECTS DEBIAN/GNU is not a grammatical construct. * There is no such thing as DEBIAN/GNU. Debian is one entity, GNU is another; neither project exists in enough of a legal sense to be able to receive funding in the formal manner described. * BY INTERVAL OF is also not a grammatical construct. * SPI is not a foundation. * If one wants to donate money to Debian, one donates to Software in the Public Interest, Inc. If one wants to donate money to GNU, one donates to the Free Software Foundation. * There is no period at the end of this sentence, if it is reasonable to call this horrible piece of filth a sentence. I suggest COMPUCLICK confine themselves to conducting business only in languages with which they have some facility (if any exist). I don't think we would be deriving much of a revenue stream from them anyway, if their arithmetic skills are as poor as their linguistic ones. Permission is hereby granted to redistribute this mail, particularly if it makes its way back to the chowderheads who wrote that piece of excrement. -- G. Branden Robinson|You live and learn. Debian GNU/Linux |Or you don't live long. [EMAIL PROTECTED] |-- Robert Heinlein roger.ecn.purdue.edu/~branden/ | pgp2SPXhvYIuh.pgp Description: PGP signature
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides Could you please limit your line lengths to around 75 characters? Anything else makes it painful to read and awkward to quote. For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. Emphasis yours. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. (2) to have the capacity for holding. What does (2) mean? ``This bucket contains four gallons of water. No, it doesn't have any water in it, but it has the capacity for holding four gallons, so therefore it contains four gallons.'' That doesn't make sense at all in this context as far as I can see. Leaving that aside, though... The intention of the authors (GNU and rms) is fairly clear, and they make their interpretation fairly clear in the LGPL's (written by the same authors) preamble: When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. [...] As such, I'm not really sure how you can say ``But that's not what RMS meant, coz that's not what he wrote, see, this is what the dictionary says and everything!'' and expect to be taken seriously. Hmmm. Actually, that's not entirely the whole story. The LGPL (Library GPL) version 2, dated June 1991 (which is the same as the GPL), had the following text in the preamble: The reason we have a separate public license for some libraries is that they blur the distinction we usually make between modifying or adding to a program and simply using it. Linking a program with a library, without changing the library, is in some sense simply using the library, and is analogous to running a utility program or application program. However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such. That is, it didn't differentiate between statically linked executables (which clearly makes a combined work under copyright law), and dynamically linked binaries (which is less clear). Now with dynamically liked GPL software we have three cases: (a) A GPLed binary linked against a GPLed library (b) A GPL-incompatible binary linked against a GPLed library. (c) A GPLed binary linked against a GPL-incompatible library (dynamic linking in all cases) We'll note that in no case is the library a derived work (in any sense) based on the binary (it doesn't include any code from the binary, it's perfectly usable without the binary having ever been written, and so on). It's probably arguable whether the binary is a derived work based on the library or not. At best, it may contain portions of the library's interface definitions (header files and what-not), however these are probably not copyrightable [0]. Now, for (a) presumably we don't have any issues at all, and everyone's happy. Of course, it would only apply to KDE if there was a (L)GPLed Qt clone about. Now (b) is clearly not the case for KDE. However it's probably the most questionable one. Clearly, there aren't any issues with distributing the library on its own. As far as distributing the binary is concerned, it seems to me that you'd have to make one of the following arguments to get the GPL to apply: (1) the dynamically linked binary is a derived work (under copyright law) of the library, as well as the binary's source code, because it includes portions of the headers in the resultant binary. (section 0 of the GPL) (2) the dynamically linked binary is a derived work (under copyright law) of the library, because it doesn't work without the library. (3) static linking is obviously bad, and since dynamic linking is just the same as static linking except for a command line option, and some random techincal things, both must be bad. (4) while it's okay to distribute the binary and the library, once you've got them you're not allowed to
Re: x3270 licenses
Scripsit Branden Robinson [EMAIL PROTECTED] There is jurisprudential precedent on this issue, at least in the United States.[*] It has been ruled that typefaces are not copyrightable, but fonts are. Interesting. I'd have though that the typeface was what carried the copyright since that is the *artistic* expression. -- Henning MakholmNej, hvor er vi altså heldige! Længe leve vor Buxgører Sansibar Bastelvel!
Re: Compuclick Ltda - Debian Vendor Page
Scripsit [EMAIL PROTECTED] (Craig Small) COMPUCLICK IS AUTHORIZED MANUFACTURER OF THE OFFICIAL CD OF DEBIAN We don't authorize anyone to do anything. As far as there is such thing as a compilation copyright (which I don't think the Berne convention recognizes, but many jurisdictions do, including all of the EU countries) a CD vendor legally needs the projects' authorization to manufacture Debian CD's. As I read the Social Contract it clearly implies that Debian is providing this authorization unconditionally to the public at large (and it is doubtful whether the licenses of the software in Debian would allow otherwise), so Compuclick is factually correct in claiming that they are authorized to produce Debian CD's - as are everyone else, but since when have people expected advertisers to tell the full story? I was just concerned that having authorized there may make people think we have some sort of special relationship with the vendor Yeah. That is where the Debian trademark comes in, I gather. I couldn't find any trademark policy on www.debian.org, however... -- Henning Makholm Nobody is going to start shouting about moral philosophy on my bridge.
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: (*) The source code must be complete. Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. ^^^ What about the Qt header files, which are included at compile time? (2) to have the capacity for holding. (I am not sure if I get all details of the english language correct, but the kde exectuable has the capacity to hold the qt libs). Marcus
Re: On interpreting licences (was: KDE not in Debian?)
Marcus Brinkmann wrote: On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: (*) The source code must be complete. Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. ^^^ What about the Qt header files, which are included at compile time? Right. And those are distributed in source form. I think you are taking this debate a bit out of context. Raul is trying to convince me why a statically linked kghostview is not OK but a statically linked ghostview on Solaris is. What you seem to be addressing here is the question of whether a KDE/Qt binary can satisfy the GPL at all, which was a whole other debate. To bring the point home, it is also true that proprietary libc header files are enclosed in a Solaris ghostview (or pick another GPL'd/proprietary libc program). (2) to have the capacity for holding. (I am not sure if I get all details of the english language correct, but the kde exectuable has the capacity to hold the qt libs). I don't think you got this right -- this doesn't mean the theoretical capacity but the actual. Otherwise you could say the sun contains Andreas since theoretically it can, but that would not generally be considered a correct statement. Ciao, Andreas
Re: On interpreting licences (was: KDE not in Debian?)
Marcus Brinkmann wrote: What about the Qt header files, which are included at compile time? On Wed, Feb 09, 2000 at 09:08:16AM -0500, Andreas Pour wrote: Right. And those are distributed in source form. Not under terms which satisfy the GPL. The GPL requires that there be no proprietary restrictions on the modification and redistribution of the source for any part of the program. The QPL requires that Troll can put whatever proprietary restrictions they like on the distribution of future modified versions of the program. I think you are taking this debate a bit out of context. Then again, the above issue has been pointed out to you many times, yet you choose to ignore that particular issue whenever you feel like it. Raul is trying to convince me why a statically linked kghostview is not OK but a statically linked ghostview on Solaris is. Well, yes, that's one point I'm currently trying to make. But, I'm begining to think that I couldn't convince you that paper can burn, even if I had unlimited time, unlimited dry paper, unlimited dry air and unlimited dry matches. What you seem to be addressing here is the question of whether a KDE/Qt binary can satisfy the GPL at all, which was a whole other debate. And if you light a match and hold it up to a piece of paper, which is sufficiently dry, and hold it there long enough for the paper to catch -- which isn't usually more than a few seconds, though I'm sure you could come up with some papers that wouldn't burn -- it's possible for the paper to catch on fire. To bring the point home, it is also true that proprietary libc header files are enclosed in a Solaris ghostview (or pick another GPL'd/proprietary libc program). (2) to have the capacity for holding. (I am not sure if I get all details of the english language correct, but the kde exectuable has the capacity to hold the qt libs). I don't think you got this right -- this doesn't mean the theoretical capacity but the actual. Otherwise you could say the sun contains Andreas since theoretically it can, but that would not generally be considered a correct statement. See program. See program run. Run program, run. I think that if you examine an operating program -- not any specially modified program, but the sort of program which any random user of kghostscript might have -- and you took a look at what copyrightable works comprised that program -- you'd have a pretty good idea of what went into that program. Of course, some people have raised the objection that the GPL doesn't care how you use the program. Which means that it would be legal to run the program if it was being distributed legally. But the only way to believe that the program was distributed legally is by pretending that a working copy of kghostscript is just some coincidence -- not something that's being distributed. Of course, once you've made that leap of fantasy (that working copies of kghostscript are not being distributed), I suppose that it's pretty easy to deny the meaning of any contradictory legal language. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. That's part of the definition -- it's not reasonable to claim that this somehow excludes any other definitional material from the GPL (or, for that matter, any other definitional material from common english usage). The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. This is a distinction you've introduced, not something that's ever stated in the GPL. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. 2) to have the (capacity for holding. 3) to be equal or equivalent to; as, a (gallon *contains* four quarts; Now, please explain how the executable work which I am distributing (kghostview which is dynamically linked to Qt) has in it, holds, encloses or includes, has the capacity for holding, or is equal or equivalent to, the Qt library. I don't know which copy of kghostscript you're distributing, but let me ask you this: do you expect that copy to work? Sure, the Qt library can later be added to it -- like sugar to the gallon of water -- but is not contained in it. We're not dealing with laws about the distribution of sugar water. We're dealing with copyright laws in the context of a work which was designed to include material licensed under the GPL as well as under the QPL. And yet you continue to hold that it's just a coincidence that a running copy of kghostscript is going to just happen to include the QPL licensed material. That's why when you distribute a dynamically-linked kghostview you don't have to distribute Qt source code. Now of course this executable work no more contains Qt if it is distributed on the same CD. (However, in case it is on the same CD, the special exception would not apply.) I presume that by contain you're not refering to any sort of physical topology. After all, it's just bits represented on a piece of plastic. There's no inside or outside in the physical sense. You've got a few bits over here which happen to represent (to an informed person) this concept of a filename. Near those bits are a few more bits that happen to indicate some other region of bits which happen to represent the contents of a file. And, on that CD, there are literally thousands of these collections of bits which we think of as files. But, the GPL doesn't make any sort of claim that only a single file is considered to be the program. Whenever it refers to files, it's very clearly refering to multiple files. But somehow you've gotten this idea in your head that the program kghostscript is exactly the same thing as the file which happens to have the name kghostscript. But you've never offered any evidence for that belief. Please present some evidence that that one file represents the whole program. -- Raul
Re: The Penguin Machine Re: Debian for kids
On Wed, 9 Feb 2000, David Starner wrote: of the page at tpm.seul.org. Even though TPM was developed in Australia, would distribution of this program in the US (or export of the program from within the US) put Debian at risk of legal action by the patent holders? Yes. Cf. the RSA code, the mp3 code, and the LZW code. Ah, I was afraid of that. Well, it least it could go into non-US/main. From what I can see it's still not ready for prime time, though. We'll see what comes of it. A shame, though. Ben -- nSLUG http://www.nslug.ns.ca [EMAIL PROTECTED] Debian http://www.debian.org [EMAIL PROTECTED] [ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ] [ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: Marcus Brinkmann wrote: What about the Qt header files, which are included at compile time? On Wed, Feb 09, 2000 at 09:08:16AM -0500, Andreas Pour wrote: Right. And those are distributed in source form. Not under terms which satisfy the GPL. Says you :-). The GPL requires that there be no proprietary restrictions on the modification and redistribution of the source for any part of the program. The QPL requires that Troll can put whatever proprietary restrictions they like on the distribution of future modified versions of the program. I think you are taking this debate a bit out of context. Then again, the above issue has been pointed out to you many times, yet you choose to ignore that particular issue whenever you feel like it. I don't ignore it, I disagree with it. I have spent lots of e-mails explaining why. Raul is trying to convince me why a statically linked kghostview is not OK but a statically linked ghostview on Solaris is. Well, yes, that's one point I'm currently trying to make. But, I'm begining to think that I couldn't convince you that paper can burn, even if I had unlimited time, unlimited dry paper, unlimited dry air and unlimited dry matches. The feeling is mutual. So let's agree to disagree, OK? And I won't respond to what you wrote below -- you get the last word :-). Ciao, Andreas
Re: On interpreting licences (was: KDE not in Debian?)
On Wed, Feb 09, 2000 at 04:02:29PM -0500, Andreas Pour wrote: Then again, the above issue has been pointed out to you many times, yet you choose to ignore that particular issue whenever you feel like it. I don't ignore it, I disagree with it. I have spent lots of e-mails explaining why. Yet every one of these emails has contained significant errors. You've claimed that these errors are inconsequential, but I've yet to see you post an explanation that didn't contain errors of fact. What I want to know is: if all those errors are so inconsequential, why did you bother writing them in the first place? -- Raul
Re: Compuclick Ltda - Debian Vendor Page
Henning Makholm said: As I read the Social Contract it clearly implies that Debian is providing this authorization unconditionally to the public at large (and it is doubtful whether the licenses of the software in Debian would allow otherwise), so Compuclick is factually correct in claiming that they are authorized to produce Debian CD's - as are everyone else, but since when have people expected advertisers to tell the full story? OK, thanks for clearing that up. I won't do anything futher. I thought that might be the case but doesn't hurt to check. - Craig -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 Eye-Net Consulting http://www.eye-net.com.au/ [EMAIL PROTECTED] MIEEE [EMAIL PROTECTED] Debian developer [EMAIL PROTECTED]
Re: New OPL Draft
Do you believe it is inconsistent with the philosophy of the Free Software movement to accept any more restrictions on classes of computer-handled data that are not executable code than we do on executable code? I think the moral requirements for freedom depend on the kind of data or work, and how it is used. For example, where it concerns documentation, and more generally for textbooks, I would insist on the same criteria of freedom that I would apply for software. Likewise for dictionaries. For scientific papers, I think it is reasonable to say that everyone can redistribute them but nobody can modify them. For novels, I would be willing to accept a more restrictive license. The minimum freedom, which should always apply to anything published, is the freedom occasionally to make a copy for an acquaintance.
