Re: Corel's apt frontend
On Tue, Nov 02, 1999 at 10:15:29AM -0500, Jeff Teunissen wrote: I haven't seen RMS claim that Emacs, using gcc as a backend to compile code, is a derivative work of gcc. Nor has he taken issue with NeXT Project Builder calling gcc to compile code, or any of the other development environments' (many of which could not exist without gcc) usage of gcc to do what gcc was designed for in their normal operation. Yup, he's restricted himself to those cases where a language is implemented which doesn't generate a language gcc can already handle (C, ..) as the intermediate step to calling gcc. -- Raul
Re: Corel's apt frontend
On Fri, Nov 05, 1999 at 02:33:53PM +0100, Marcus Brinkmann wrote: http://www.compuserve.de/recht/gesetze/urhg/ This is one I'm too ignorant to understand. [I don't understand German.] -- Raul
Re: Corel's apt frontend
I've put up a page detailing the copyright law references that have been posted so far. I should add a berne convention link. Also, note that I can't tell whether the non-english law references are specific to copyright law or whether they're references to all law for that country. Finally, I couldn't even access the danish laws. http://master.debian.org/~moth/copyright-law.html I'll be maintaining this page if anyone wants to send me additional info. Thanks, -- Raul
Re: Corel's apt frontend
On Fri, Nov 05, 1999 at 07:06:40PM +0200, Antti-Juhani Kaijanaho wrote: You should put a link to the unofficial English translation of Finnish Copyright Act. I posted the URL earlier. I never got your original, I extracted the finnish link from a followup. If it's convenient, could you forward me another copy? If not, I'll grab it from the archives tomorrow. Thanks, -- Raul
Re: Corel's apt frontend
Raul Miller [EMAIL PROTECTED] writes: Finally, I couldn't even access the danish laws. Yeah. Nobody can, unless they use a browser that speaks JavaScript. And even then it is is impossible to get a persistent URL for a given document - for unknown reasons they enforce a session login-style interaction. Sucks bigtime, really. -- Henning Makholm Man vælger jo selv sine forbilleder.
Re: Corel's apt frontend
On Wed, Nov 03, 1999 at 07:00:10PM +0100, Henning Makholm wrote: [EMAIL PROTECTED] (Zygo Blaxell) writes: Does this mean that as long as a developer writes their own headers, they can link anything they want to against a GPLed .so file without infringing on the GPL? I don't see any way the copyright on .so could affect programs that link against it, if compiled with clean-room headers (which may need to include a dummy .so that the linker can inspect while creating the executable). I don't see how you could write your own headers without copying the existing ones, personally. (It counts as copying if you get one person to read it, and someone else writes it down, you don't have to be using cp or anything. And personally, I can't see any way you could `reinvent' a header file that wouldn't amount to doing exactly that :-/) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpZqFQzQsuQy.pgp Description: PGP signature
Re: Corel's apt frontend
[EMAIL PROTECTED] (Bruce Perens) writes: The creation of non-GPL headers for the purpose of linking in a GPL library is a device created explicitly for the circumvention of the library's copyright, and would not protect you from being liable for infringement. It could be done without even looking at the source of the GPLed library and this way not doing anything looking like copying. It would take some reverse engineering, wich I don't think the GPL allows, but acording to danish laws[0] I don't care. Production of header files is essential for cooperating with the library which allows me to reverse engineer them. Still talking danish laws: But I'm not sure I could distribute the produced headers. 0) I know other countries has a like laws. Australia come to mind (old /. story) -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, The Dead Past
Re: Corel's apt frontend
On Wed, 3 Nov 1999 12:29:38 -0800 (PST), Bruce Perens [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (Zygo Blaxell) Does this mean that as long as a developer writes their own headers, they can link anything they want to against a GPLed .so file without infringing on the GPL? The creation of non-GPL headers for the purpose of linking in a GPL library is a device created explicitly for the circumvention of the library's copyright, and would not protect you from being liable for infringement. If this is true, then the Wine project would seem to be in serious trouble, wouldn't it? After all, the _entire_ Wine project is a device created explicitly for circumvention of the library's copyright, where the library is the Windows runtime DLL set. When Wine is finished, it won't be necessary to copy Windows at all, which circumvents Windows' copyright in IMHO the cleanest way possible. ;-) Or does what you said apply only when the developer ships the GPL library along with a non-GPL application built with non-GPL headers? When is that different from aggregation on the same media? .
Re: Corel's apt frontend
On Wed, Nov 03, 1999 at 01:05:53PM +0100, Henning Makholm wrote: What Raul seems to be getting at is that dpkg is presently the only existing implementation og the command-line interface in question. His arguments apparently lead to a general principle: if, for some protocol (a command line interface is a particular example of a protocol, but one of the basic premises of the argument is that such technical differences are irrelevant) there is only one existing implementation of one side of the protocol, then every implementation of the *other* side of the protocol automatically becomes deriviate of the implementation of the first side. I don't think copyright law acknowledges such a principle. Copyright law (by which I mean U.S. Copyright law) does indeed have such a principle, but it's formulated very differently: According to U.S. Copyright law, A ''computer program'' is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. Notice that this doesn't care about protocols or interfaces. If the instructions are used to produce the result they're part of the program -- this is a very inclusive statement. To balance this out, there's also a concept of fair use. Most uses of the command line interface count as fair use. I'm not going to go into this any deeper. I've posted that definition of a computer program something like a dozen times and most of the responses I've gotten don't even acknowledge the key issues. I worry that a second sentence would be too complicated for people. -- Raul
Re: Corel's apt frontend
On Thu, Nov 04, 1999 at 08:29:00AM +0100, Peter Makholm wrote: It would take some reverse engineering, wich I don't think the GPL allows,... The GPL places no restrictions on reverse engineering. -- Raul
Re: Corel's apt frontend
Peter Makholm [EMAIL PROTECTED] writes: It would take some reverse engineering, wich I don't think the GPL allows, I.e. looking at the source code? That seems to be quite much allowed by the GPL. -- Henning Makholm Monsieur, vous êtes fou.
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] I'm not going to go into this any deeper. I've posted that definition of a computer program something like a dozen times and most of the responses I've gotten don't even acknowledge the key issues. I worry that a second sentence would be too complicated for people. Raul! Please get off that high horse. I discussed this issue with two attorneys, one of whom appears to be the acknowledged authority on free software law. They are not nearly as sanguine as you. There is thus some possibility that _you_might_be_wrong_. Yes, we understand the definition of a computer program. We simply do not feel that it's the deciding factor in this decision, or even particularly relevant to the argument. You do not have to abuse us with comments about two sentences being too complicated for our understanding. Thanks Bruce
Re: Corel's apt frontend
Anthony Towns aj@azure.humbug.org.au writes: (It counts as copying if you get one person to read it, and someone else writes it down, you don't have to be using cp or anything. And personally, I can't see any way you could `reinvent' a header file that wouldn't amount to doing exactly that :-/) Then it's probably just you who are being unimaginative. Remember, simple facts are not copyrightable. Only particular expressions of facts are. By extension, if there is only way to express some fact, that expression cannot be subjected to copyright. That is, if I do a survey to count the number of ants in Africa I have a copyright on the article where I describe my work. But I cannot prevent others from communicating my result, claiming that I have copyright on the particular sequence of decimal digits that make up my sum. Moving back to the topic of headers, what one needs to do is create an expression of the fact that the .so defines function called such-and-such, which expect their input to be structured like that-and-that and produces output structured like that-and-that. There are several ways of expressing those facts in a way understood by a C compiler, and it is entirely possible to come up with a way whose *only* connection with the other header file is that they define functions with the same names. We're not even talking about header file reimplementations that necessarily have to be compatible with the originals in what the C source sees. The names of data types and struct declarations could be different. And inline functions and macro definitions in the original header file need not even be recreated by the new header file before an executable linking with the library can be produced. -- Henning Makholm*Her* sidder jaj har *ild* bå cigarren *imens* Pelle Jönsson i Nordnorge har mavepine.
Re: Corel's apt frontend
Gavriel State [EMAIL PROTECTED] writes: Regardless of whether or not the dynamic linkage is a violation, the header file used has (almost) nothing to do with it. Nevertheless the inclusion of header files *is* the key point of an often-heard argument that the dynamic linkage is a violation. A legal argument can be made that the relevant portions of header content are not protectable by copyright since they are essentially a 'compilation of facts' I agree with that, but obviously not everybody else do. -- Henning Makholm You propose to avoid dying? I will be interested to hear the method you plan for this endeavour.
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] I'm not going to go into this any deeper. I've posted that definition of a computer program something like a dozen times and most of the responses I've gotten don't even acknowledge the key issues. I worry that a second sentence would be too complicated for people. On Thu, Nov 04, 1999 at 09:59:42AM -0800, Bruce Perens wrote: Raul! Please get off that high horse. I discussed this issue with two attorneys, one of whom appears to be the acknowledged authority on free software law. They are not nearly as sanguine as you. There is thus some possibility that _you_might_be_wrong_. These are Corel's attorneys, right? You expect them to state outright that they think their client is violating copyright law? In a sense it's true that any statement about law is undecided until the courts have ruled. None of us are judges and none of what we say counts as legal precedent. So, it's perfectly reasonable for them to say that I might be wrong -- they're representing their client's interests and it would not be in their client's interests for them to say that their client is wrong. On the other hand, I think it would be wrong of me pretend that this is anything more than a statement that this hasn't been taken to court yet. [On the other hand, note that I'm not putting much energy into this issue -- in my opinion, it's Ian's issue and it's up to him to pursue it. However, I have spent more than a few hours on this already, and if someone raises a simple point which I can address easily, I'm up to that.] Yes, we understand the definition of a computer program. We simply do not feel that it's the deciding factor in this decision, or even particularly relevant to the argument. You do not have to abuse us with comments about two sentences being too complicated for our understanding. It's great that you feel this way, of course. But unless you provide some references that have legal weight, please don't expect me to feel the same way. And, if you choose not to address the the law about the issue, why should I take this as anything more than personal feelings? -- Raul
Re: Corel's apt frontend
A legal argument can be made that the relevant portions of header content are not protectable by copyright since they are essentially a 'compilation of facts' They document the API of the library, so you get into the API copyright issue, too. The argument given here by RMS' law instructor at Columbia is that run-time linking is a device to circumvent the copyright of the library, which otherwise would be static-linked and explicitly copied. Given the universality of run-time linking, I think there's a good counter-argument that it's a device for copyright evasion rather than more pragmatic goals. Thanks Bruce
Re: Corel's apt frontend
Gavriel State [EMAIL PROTECTED] writes: Regardless of whether or not the dynamic linkage is a violation, the header file used has (almost) nothing to do with it. On Thu, Nov 04, 1999 at 07:01:00PM +0100, Henning Makholm wrote: Nevertheless the inclusion of header files *is* the key point of an often-heard argument that the dynamic linkage is a violation. Which probably reflects a lack of understanding of copyright law as much as anything else. For the case of U.S. copyright law dynamic linking not explicitly provided for in the license is a fair use issue, not a this isn't covered by copyright law issue. At least... that's the way I currently understand it. [And, if anyone can provide some legal reference which proves that I'm wrong, I'd be happy to see it.] -- Raul
Re: Corel's apt frontend
The argument given here by RMS' law instructor at Columbia is that run-time linking is a device to circumvent the copyright of the library, which otherwise would be static-linked and explicitly copied. Given the universality of run-time linking, I think there's a good counter-argument that it's a device I think I'm typing too fast. I'll re-state: RMS' law instructor argues that run-time linking is a device to circumvent the copyright of the library, which would otherwise be static-linked and explicitly copied. Thus, the court should treat it as they do static linking. But there is a counter-argument that run-time linking exists for more pragmatic purposes and thus it should not be considered a subterfuge for copyright avoidance. Thanks Bruce
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] These are Corel's attorneys, right? No. Pamela Samuelson, Cyberlaw instructor at Berkeley and notable speaker on free software law. Mitchell Baker, head of Mozilla and also an attorney. They are on our side, and they are not as sanguine on this issue as you are. If it were Corel's attorneys, I'd simply consult a non-Corel attorney before I believed them. That was not the case here. Thanks Bruce
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] These are Corel's attorneys, right? On Thu, Nov 04, 1999 at 10:56:20AM -0800, Bruce Perens wrote: No. Pamela Samuelson, Cyberlaw instructor at Berkeley and notable speaker on free software law. Mitchell Baker, head of Mozilla and also an attorney. They are on our side, and they are not as sanguine on this issue as you are. If it were Corel's attorneys, I'd simply consult a non-Corel attorney Ibefore believed them. That was not the case here. Ok. I'll still take the stance that because this hasn't gone to court that we don't know what the courts will decide. And, since fair use can be a bit of a slippery concept this makes sense to me. But I stand by what I've been saying so far: that the issue of what files the instructions are stored in is a red herring: the questions are fair use issues, not storage format issues. -- Raul
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] I'll still take the stance that because this hasn't gone to court that we don't know what the courts will decide. I will amplify this for you. We are writing the rules as we go along. There is a body of case law that must be accumulated before those rules can be counted on. We haven't seen the first case yet. Thanks Bruce
Re: Corel's apt frontend
Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Ben Pfaff wrote: No, file formats are not copyrightable, only actual files. Otherwise clones of proprietary packages with proprietary file formats would be in violation of copyright. We're starting to digress here though.. lets stop this thread, I think all arguments have been made and in the end we'll just have to wait what comes out of Ian's discussion with Corel. Maybe Ian/Debian/GNU should clarify how Debian/GNU code is licensed and intended to be used. It'd be a lot easier for some of us if there was a statement saying what can and can't be done with Debian/GNU. I'd never have imagined that distributing a non-GPL'ed shell script or other such frontend for dpkg was unacceptable and I've been reading about the GPL for a long time. I wouldn't want to fall into that kind of trap by mistake. Do please consider using a more explicit license if GPL keeps causing all these misunderstandings. Or go the way of Linus Torvalds and expand on what you think the GPL grants or not (/usr/src/linux/COPYING). I don't see why you shouldn't, unless you do want to fool or confuse people. Navin, who has been using and installing Debian/GNU too damned recklessly.
Re: Corel's apt frontend
On Thu, Nov 04, 1999 at 01:41:19PM -0500, Raul Miller wrote: For the case of U.S. copyright law dynamic linking not explicitly provided for in the license is a fair use issue, not a this isn't covered by copyright law issue. I know nothing of US copyright law except that it and Finnish copyright law are based on the same international treaty (the Berne convention). As I understand it, fair use cannot *ever* be a candidate in this situation: fair use it about allowing scholarly citation, commentary and learning. Dynamic linking is none of these things. Fair use is covered in the Copyright Myths FAQ. Here's an excerpt: The fair use exemption to copyright law was created to allow things such as commentary, parody, news reporting, research and education about copyrighted works without the permission of the author. Intent, and damage to the commercial value of the work are important considerations. Are you reproducing an article from the New York Times because you needed to in order to criticise the quality of the New York Times, or because you couldn't find time to write your own story, or didn't want your readers to have to pay to log onto the online services with the story or buy a copy of the paper? The former is probably fair use, the latter probably aren't. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Corel's apt frontend
Raul Miller wrote: I discussed this issue with two attorneys, one of whom appears to be the acknowledged authority on free software law. They are not nearly as sanguine as you. There is thus some possibility that _you_might_be_wrong_. These are Corel's attorneys, right? Do you really think that Corel has managed to hire ***the*** acknowledged authority on free software law? (emphasis mine) I suggest you reread what Bruce wrote, and give him just a little bit more credit. I think he talked to a well-respected third party. (Bruce, can you mention their name?) -- see shy jo
Re: Corel's apt frontend
On Thu, Nov 04, 1999 at 01:41:19PM -0500, Raul Miller wrote: On Thu, Nov 04, 1999 at 07:01:00PM +0100, Henning Makholm wrote: Nevertheless the inclusion of header files *is* the key point of an often-heard argument that the dynamic linkage is a violation. Which probably reflects a lack of understanding of copyright law as much as anything else. Quite plausibly. I can't find any real references for the legal reasoning either way though. My lawyer-student friend couldn't offer any real enlightenment beyond `this is what the LGPL says', either. For the case of U.S. copyright law dynamic linking not explicitly provided for in the license is a fair use issue, not a this isn't covered by copyright law issue. Australia doesn't have fair use provisions, as I understand it, btw. I hope that doesn't mean we're not allowed to use dynamically linked libraries. (`implied permission' would come to mind as an excuse) :-/ At least... that's the way I currently understand it. [And, if anyone can provide some legal reference which proves that I'm wrong, I'd be happy to see it.] Please. (The LGPL simply asserts that binaries linked statically or against a shared library are derived works, it doesn't give any reasoning for it) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpu4ANYjyl1x.pgp Description: PGP signature
Re: Corel's apt frontend
On Mon, Nov 01, 1999 at 02:34:03AM -0500, Raul Miller wrote: The QPL does not require patches. It prefers them, but doesn't require them. You could just as easily provide the original for reference and let someone else diff it (which is at least a major improvement over requiring that only patches be made..) Ok, thanks, I wasn't up on that. But basically what this means, you're obligated to distribute all prior versions -- perhaps as a CVS archive, perhaps as something less efficient. [If you're the author you can collapse versions, but not if you're building on someone else's work.] Not that I particularly care.. Just their latest release. It's at least an improvmenet over patches, but I could have done better if their lawyer hadn't decided that was necessary or anything like that. And as everyone has pointed out several times it'd be a lot simpler for everyone if they used the GPL or something simple like that. I'm not convinced the GPL is ideal, it just seems more ideal than other things and it's the fastest way to fix a few of the IMO bugs in the QPL. I take full responsibility for at least one of those bugs, but I've gone into detail what the problem was and what the Trolls oughtta do to fix it in other messages. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- * Simunye is on a oc3-oc12 daem0n simmy: bite me. :) Simunye daemon: okay :) pgpfD0aUXXPqu.pgp Description: PGP signature
Re: Corel's apt frontend
Raul Miller wrote: On Tue, Nov 02, 1999 at 10:15:29AM -0500, Jeff Teunissen wrote: I haven't seen RMS claim that Emacs, using gcc as a backend to compile code, is a derivative work of gcc. Nor has he taken issue with NeXT Project Builder calling gcc to compile code, or any of the other development environments' (many of which could not exist without gcc) usage of gcc to do what gcc was designed for in their normal operation. And all these use a fairly standard cc interface. But if someone used private interfaces to implement some proprietary compiler, that would be more what I was talking about. No, my examples seem to be precisely what you are talking about. Corel's tool, using libapt, is using dpkg's command-line interface, in the same way an IDE calls a C compiler's command-line interface. The only real difference is in the results; gcc compiles code, dpkg unpacks and installs packages, as well as provides helpful information for programs and people to use. Using a program to do what it's supposed to do, as underlying functionality, is simply use. It does not create some obscure new Program. I understand your point, and there's some truth to this, but it's more accurate to say, is almost always fair use instead of .. is simply use. [Fair use has a specific technical meaning in copyright law, by the way.] Indeed...a very limited form of partial copying, generally for purposes of discussion or review. There is no copying of the program involved, so fair use does not need to be brought into the equation. -- | Jeff Teunissen -- President, Dusk To Dawn Computing -- [EMAIL PROTECTED] | Disclaimer: I am my employer, so anything I say goes for me too. :) | dusknet.dhis.net is a black hole for email.Use my Reply-To address. | Specializing in Debian GNU/Linux http://dusknet.dhis.net/~deek/
Re: Corel's apt frontend
Jeff Teunissen [EMAIL PROTECTED] writes: No, my examples seem to be precisely what you are talking about. Corel's tool, using libapt, is using dpkg's command-line interface, in the same way an IDE calls a C compiler's command-line interface. The only real difference is in the results; gcc compiles code, dpkg unpacks and installs packages, as well as provides helpful information for programs and people to use. What Raul seems to be getting at is that dpkg is presently the only existing implementation og the command-line interface in question. His arguments apparently lead to a general principle: if, for some protocol (a command line interface is a particular example of a protocol, but one of the basic premises of the argument is that such technical differences are irrelevant) there is only one existing implementation of one side of the protocol, then every implementation of the *other* side of the protocol automatically becomes deriviate of the implementation of the first side. I don't think copyright law acknowledges such a principle. -- Henning MakholmDet må være spændende at bo på en kugle. Har I nogen side besøgt de egne, hvor folk går rundt med hovedet nedad?
Re: Corel's apt frontend
On Sun, 31 Oct 1999 00:51:06 -0700 (PDT), Bruce Perens [EMAIL PROTECTED] wrote: From: Raul Miller [EMAIL PROTECTED] But the GPL is very careful about how it defines program. The GPL does not define program. However, FSF has a guidline for when linking should be considered derivation. That is when the works inhabit the same address space. So I can't port a GPLed program to OS-9, where all programs share the same address space? .
Re: Corel's apt frontend
On Sun, 31 Oct 1999 16:19:06 -0800 (PST), Bruce Perens [EMAIL PROTECTED] wrote: From: Raul Miller [EMAIL PROTECTED] That doesn't matter. Static linking copies. Dynamic linking copies at run time, which is a rather shaky argument. Executables that run dynamic libraries are derivative of the headers of those libraries, and they copy them. Exec() doesn't copy. Hmmm...consider the Wine project: a re-implementation of Microsoft DLL's (among other things) using no Microsoft code. No code means no headers as well--anything less would be copyright infringement. Does this mean that as long as a developer writes their own headers, they can link anything they want to against a GPLed .so file without infringing on the GPL? .
Re: Corel's apt frontend
[EMAIL PROTECTED] (Zygo Blaxell) writes: Does this mean that as long as a developer writes their own headers, they can link anything they want to against a GPLed .so file without infringing on the GPL? I don't see any way the copyright on .so could affect programs that link against it, if compiled with clean-room headers (which may need to include a dummy .so that the linker can inspect while creating the executable). Even in the case where the original headers are used, opinions on this list have been found to differ. -- Henning Makholm The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning.
Re: Corel's apt frontend
From: [EMAIL PROTECTED] (Zygo Blaxell) Does this mean that as long as a developer writes their own headers, they can link anything they want to against a GPLed .so file without infringing on the GPL? The creation of non-GPL headers for the purpose of linking in a GPL library is a device created explicitly for the circumvention of the library's copyright, and would not protect you from being liable for infringement. Thanks Bruce
Re: Corel's apt frontend
Zygo Blaxell wrote: Hmmm...consider the Wine project: a re-implementation of Microsoft DLL's (among other things) using no Microsoft code. No code means no headers as well--anything less would be copyright infringement. Does this mean that as long as a developer writes their own headers, they can link anything they want to against a GPLed .so file without infringing on the GPL? Regardless of whether or not the dynamic linkage is a violation, the header file used has (almost) nothing to do with it. A legal argument can be made that the relevant portions of header content are not protectable by copyright since they are essentially a 'compilation of facts' and must be expressed in the way they are for compatability and interoperability reasons. The only portions of header files that might be copyrightable are complex macros or inlines, and comments. This argument is fairly important to us given our work on WINE. I'm not a lawyer, of course, but if anyone is counting on header copyright as a mechanism for 'viral' license transmission, it would probably be a good idea to talk to a lawyer. -Gav -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED]
Re: Corel's apt frontend
On Mon, Nov 01, 1999 at 03:16:41PM +0100, Henning Makholm wrote: There is no derived work anywhere else than in your mind. This is a personal statement, not a technical one. Please confine your discussion to the technical issues. -- Raul
Re: Corel's apt frontend
Raul: This is a personal statement, not a technical one. I think we all got to the point of exasperation on that argument. And having discussed it with attorneys this evening, they don't have a good answer either. So, I think it's best to table it until something changes, like legislation or a test case. Thanks Bruce
Re: Corel's apt frontend
On Mon, Nov 01, 1999 at 11:43:12AM -0500, Ben Pfaff wrote: Wichert Akkerman [EMAIL PROTECTED] writes: Previously Henning Makholm wrote: That's knowledge. Facts are not copyrightable, only particular expressions of facts are. Such as a particular way to express the format for the intermediate languag= e? No, file formats are not copyrightable, only actual files. Otherwise clones of proprietary packages with proprietary file formats would be in violation of copyright. I think you'll find this varies from country to country. There was a case in Australia a while ago about copyright applying to an invented spreadsheet language, that held up I believe. I /believe/ the laws have been changed since, though. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpldbjOrrbuh.pgp Description: PGP signature
Re: Corel's apt frontend
Raul Miller wrote: On Mon, Nov 01, 1999 at 04:23:36PM +0100, Wichert Akkerman wrote: FWIW, RMS also doesn't see a problem with this. Understood, but RMS didn't write dpkg. I think he'd be a little less sanguine about someone doing this with gcc. I haven't seen RMS claim that Emacs, using gcc as a backend to compile code, is a derivative work of gcc. Nor has he taken issue with NeXT Project Builder calling gcc to compile code, or any of the other development environments' (many of which could not exist without gcc) usage of gcc to do what gcc was designed for in their normal operation. Using a program to do what it's supposed to do, as underlying functionality, is simply use. It does not create some obscure new Program. -- | Jeff Teunissen -- President, Dusk To Dawn Computing -- [EMAIL PROTECTED] | Disclaimer: I am my employer, so anything I say goes for me too. :) | dusknet.dhis.net is a black hole for email.Use my Reply-To address. | Specializing in Debian GNU/Linux http://dusknet.dhis.net/~deek/
Re: Corel's apt frontend
On Tue, Nov 02, 1999 at 10:15:29AM -0500, Jeff Teunissen wrote: I haven't seen RMS claim that Emacs, using gcc as a backend to compile code, is a derivative work of gcc. Nor has he taken issue with NeXT Project Builder calling gcc to compile code, or any of the other development environments' (many of which could not exist without gcc) usage of gcc to do what gcc was designed for in their normal operation. And all these use a fairly standard cc interface. But if someone used private interfaces to implement some proprietary compiler, that would be more what I was talking about. Using a program to do what it's supposed to do, as underlying functionality, is simply use. It does not create some obscure new Program. I understand your point, and there's some truth to this, but it's more accurate to say, is almost always fair use instead of .. is simply use. [Fair use has a specific technical meaning in copyright law, by the way.] -- Raul
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] But you do need a copy of dpkg or it won't work. So I don't see how this can be a problem. Because they have a right to copy dpkg onto their system regardless of whether or not any other application uses it, and such copying is simple aggregation. Why make this postulate? ld wasn't invented to circumvent copyright, why must execve() have been invented for this purpose? If, for example, someone put a command line interface on libapt explicitly for the purpose of using it with a non-GPL application, that would be a device for circumventing the copyright. Once again, there's nothing in the GPL about linkages, and there's nothing in copyright law about linkages. That doesn't matter. Static linking copies. Dynamic linking copies at run time, which is a rather shaky argument. Executables that run dynamic libraries are derivative of the headers of those libraries, and they copy them. Exec() doesn't copy. The problem here is that the front end relies on GPLed code to create its result, but uses a proprietary license. So to distribute the resulting program (which happens to not reside in a single file) Corel would need to fix the licensing conflict between these two pieces of the program. I'm sorry. You have a right to run GPL code in a pipeline with proprietary software or any other software. To violate copyright, you must copy. Thanks Bruce
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 05:45:05PM -0500, Raul Miller wrote: Please keep trying then--but the discussion is headed the wrong way right now. Where would you like the discussion to head? Towards a fix for the problem that doesn't make the GPL non-free. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- BenC cerb: we subscribed you to debian-fight as the moderator BenC cerb: list rules are, 1) no nice emails, 2) no apologies pgpvuRRELusL0.pgp Description: PGP signature
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] But you do need a copy of dpkg or it won't work. So I don't see how this can be a problem. On Sun, Oct 31, 1999 at 04:19:06PM -0800, Bruce Perens wrote: Because they have a right to copy dpkg onto their system regardless of whether or not any other application uses it, and such copying is simple aggregation. Care to say why you think this? I'm asserting that it's not simple aggregation because [excuse me for using emphasis but I've stated this point a number of times and you seem to be choosing to ignore it]: The Corel Front End *ceases* *to* *function* if dpkg is not present. The failure mode is different from leaving out libc, but it's just as significant. I'm saying that since dpkg is necessary to produce the result of Corel's front end, that dpkg is a part of that program for copyright purposes. And, once again, I'm going to quote the US law on what this question of what's contained in Corel's front end: A computer program is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. And, once again, my fundamental assertion: Under copyright law the Corel front end program is a derivative work which modifies dpkg. I understand that this definition of modifies is rather technical, and thus non-intuitive, but I've provided plenty of legal quotes to back up my position. Simply asserting that I'm wrong is silly, you need to show some legal reference which superceeds the material which I've quoted. Just in case, here's what US law defines as 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. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 05:45:05PM -0500, Raul Miller wrote: Where would you like the discussion to head? On Sun, Oct 31, 1999 at 05:30:44PM -0800, Joseph Carter wrote: Towards a fix for the problem that doesn't make the GPL non-free. How does my interpretation of copyright law make the GPL non-free? -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 09:54:46PM -0500, Raul Miller wrote: The Corel Front End *ceases* *to* *function* if dpkg is not present. Probably no more than tar ceases to function if bzip2 or gzip is not present. Loss in functionallity, but parts will still work. It more critically ceases to function if the kernel or X is not present. And, once again, I'm going to quote the US law on what this question of what's contained in Corel's front end: A computer program is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. And, once again, my fundamental assertion: Under copyright law the Corel front end program is a derivative work which modifies dpkg. And once again, we point out that your interpretation of that definition means that Corel front end is a derivative of the half the system. -- David Starner - [EMAIL PROTECTED]
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] But you do need a copy of dpkg or it won't work. So I don't see how this can be a problem. On Sun, Oct 31, 1999 at 09:54:46PM -0500, Raul Miller wrote: I understand that this definition of modifies is rather technical, and thus non-intuitive, but I've provided plenty of legal quotes to back up my position. Simply asserting that I'm wrong is silly, you need to show some legal reference which superceeds the material which I've quoted. On Sun, Oct 31, 1999 at 10:07:13PM -0500, Brian Ristuccia wrote: Nintendo v. Galoob. Game Genie ceases to function when the Nintendo game software is removed, but is not a derivative work nor does it create a derivative work when used, according to the court. I'll dig up the full text of the decision if it'll help convince people in this argument. Hmm... I can't find a copy... it would be great if you could. Anyways, the copyright issue in Nintendo v. Galoob was on-screen presentation, not computer program copyright (the game genie worked by altering electrical signals not by running a program). And, yeah, that was declared an example of fair use. And, fair use for computer programs allows for the copying which happens when the user executes the program. [Which seems to be the gist of the point that most people have been trying to make to me.] I can see that the Nintendo v. Galoob decision might cover the case where the Corel front end is distributed without dpkg. Here, you could argue that the front end is just a logical extension of fair use [copyright law says that the copy of a program which is made when the program is run or backed up is fair use.] It's not guaranteed that a court would go along with this, but it is plausible. [It would be much more plausible if the front end was independently useful -- without requiring dpkg.] However, I don't see that Nintendo v. Galoob covers the case where Corel wants to distribute the front end with dpkg. You're not talking about fair use any more but distributing a derived work. [And, as before, if you can find anything that contradicts me I'd be glad to hear about it.] Finally, the reason I'm making an issue of this: I think it's reasonable for Ian to talk with Corel about the licensing of the Corel front end, while other people have claimed that it's not. I'm still convinced that this is a reasonable action on Ian's part. [Especially since Corel is a Canadian company and Canada's treatment of copyright law includes the moral right of integrity.] -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 09:54:46PM -0500, Raul Miller wrote: The Corel Front End *ceases* *to* *function* if dpkg is not present. On Sun, Oct 31, 1999 at 09:33:36PM -0600, David Starner wrote: Probably no more than tar ceases to function if bzip2 or gzip is not present. Loss in functionallity, but parts will still work. It more critically ceases to function if the kernel or X is not present. tar will unpack archives without gzip as long as they're not compressed. If the Corel front end supports other package formats than .deb then there's no problem. Of course, that means that the front end isn't guaranteeing any kind of administrative database integrity, but that's a fair compromise. And, once again, I'm going to quote the US law on what this question of what's contained in Corel's front end: A computer program is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. And, once again, my fundamental assertion: Under copyright law the Corel front end program is a derivative work which modifies dpkg. And once again, we point out that your interpretation of that definition means that Corel front end is a derivative of the half the system. Surely nothing more than the essential parts of the system. And I believe most of those parts have licenses (or alternative implementations) which prevent exactly this sort of problem. However, I'm open to counterexamples. -- Raul
Re: Corel's apt frontend
Raul Miller wrote: [snip] But it matters for the Corel front end. What you're basically trying to show, I think, is that the Corel front end isn't a derivative work of dpkg. What I'm trying to show is that it is -- and I've offered two pieces of evidence that it is: (1) It won't behave according to the documentation if dpkg isn't present, and (2) It's distributed with dpkg It's also distributed with bash, the Linux kernel, and so on. Is it a derivative of all the software on the CD? [snip] -- | Jeff Teunissen -- President, Dusk To Dawn Computing -- [EMAIL PROTECTED] | Disclaimer: I am my employer, so anything I say goes for me too. :) | dusknet.dhis.net is a black hole for email.Use my Reply-To address. | Specializing in Debian GNU/Linux http://dusknet.dhis.net/~deek/
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] The Corel Front End *ceases* *to* *function* if dpkg is not present. Yes, but copyright law does not deal with whether or not an application stops functioning if you remove another component of the system. Copyright law deals with copying. You are grasping at straws. I see no point in continuing this argument. Thanks Bruce
Re: Corel's apt frontend
On Mon, Nov 01, 1999 at 02:39:57PM +1000, Anthony Towns wrote: (If this is the case, it might be a worthwhile service to separate main into `gpl' and `free', so that the things you can just willfully mix and match (the GPL stuff) is more clearly separated from the stuff you have to have a doctorate in laws to deal with (GPL and anything else, anything else and anything else). This is at least plausible with the advertising clause removed from the BSD stuff...) It's not that simple. Consider the mozilla license, for example, and imagine building a program from mozilla and some other work with a mozilla-like license which belongs to some other company. [Or even consider the restrictions on QPL+Artistic license. The new QPL requires patches, and forbids non-source releases, while Artistic requires renaming or severely restricted distribution -- so eventually you wind up with a build process with files you shouldn't rename and an executable which must be renamed.] It's reasonable to partition the distribution into software which is compatible with some particular license. I don't think it's fair to ask our people to render legal judgement on hypothetical future license combinations: every distinct license imposes its own unique set of restrictions and each combination of licenses must be considered individually. The best advice, if you want your life to be simple, is to pick a license you like and develop your software to only require that pieces which use that license. [And, it's probably safe to add BSD and Public Domain and X licensed software to just about any mix -- they can be used in MS Word as easily as they can be used in emacs.] -- Raul
Re: Corel's apt frontend
On Sun, 31 Oct 1999, Joseph Carter wrote: Kernel is GPL. Everything is a derivative of the kernel under your interpretation. You can argue that Linus has allowed people to abuse the GPL of the kernel so it's okay, however I think this would cause the GPL to contaminate any distribution which contains any GPL software. If that doesn't cross the DFSG line, it comes very damned close to doing it. If RMS intends this sort of contamination (I don't believe he's even considered the issue fully) then we CANNOT ship things like Apache with Debian unless we get permission from Linus and the other kernel Copyright holders to do so, in writing (or at least in email with modified license terms to be applied to the next release of the kernel) Or you can simply decide to disagree with Stallman on his interpretation of the GPL itself. The same address space - talk about ambiguity. I have a feeling should Stallman decide that the GPL was this far-reaching, he'd soon have to defend that interpretation in court, a forum the GPL has never been tested in before (under any interpretation). I predict it would also cause a commercial stampede towards FreeBSD. =) I would expect a similar reaction should Stallman change the GPL in GPLv3 to apply to any interface to a GPL'd program (the loophole Bruce wants to close). Should this interpretation of the GPL become dominant I believe we should deprecate the GPL in favor of a license which does not skirt the letter of the DFSG while violating its spirit in favor of some license which doesn't. (Which would suck because I don't know of any other suitable licenses that do anything like what the GPL does..) Thoughts on the MPL? I find it a more than adequate compromise between the GPL's viral nature and BSD's optimal-reuse strategy. Brian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Collab.Net is hiring! http://www.collab.net/
Re: Corel's apt frontend
On Mon, Nov 01, 1999 at 04:56:30AM +, Jeff Teunissen wrote: It's also distributed with bash, the Linux kernel, and so on. Is it a derivative of all the software on the CD? I think this issue has already been discussed. Several times. But maybe there isn't any sort of concise explanation, yet... (1) As Anthony Towns has just pointed out, It's licensed use of the Linux kernel. See the file COPYING at the top of the linux source tree. (2) To my knowledge it could use ash just as easily as bash, so that's fair use. (3) glibc is lgpled. (4) Most of the software it's distributed with isn't required for it to function: you don't really need xeyes for example. [Not that the xeyes copyright would be an issue even if you did need it.] -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 10:45:27PM -0800, Brian Behlendorf wrote: Should this interpretation of the GPL become dominant I believe we should deprecate the GPL in favor of a license which does not skirt the letter of the DFSG while violating its spirit in favor of some license which doesn't. (Which would suck because I don't know of any other suitable licenses that do anything like what the GPL does..) Thoughts on the MPL? I find it a more than adequate compromise between the GPL's viral nature and BSD's optimal-reuse strategy. The MPL is not exactly light reading, to put it mildly. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- Bruce McKinney, author of of Hardcore Visual Basic, has announced that he's fed up with VB and won't be writing a 3rd edition of his book. The best quote is at the end: 'I don't need a language designed by a focus group'. pgpowANDd810a.pgp Description: PGP signature
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 10:45:27PM -0800, Brian Behlendorf wrote: Thoughts on the MPL? I find it a more than adequate compromise between the GPL's viral nature and BSD's optimal-reuse strategy. Netscape owns it. Try combining MPL with MPL' where some other company owns MPL', then imagine people putting serious work into that combination and distributing the result. Then try to sort out what each company is obligated to do vs. what it's allowed to do. [Remember that you're not allowed to remove an author's copyrights.] -- Raul
Re: Corel's apt frontend
On Mon, Nov 01, 1999 at 01:44:32AM -0500, Raul Miller wrote: [Or even consider the restrictions on QPL+Artistic license. The new QPL requires patches, and forbids non-source releases, while Artistic requires renaming or severely restricted distribution -- so eventually you wind up with a build process with files you shouldn't rename and an executable which must be renamed.] The QPL does not require patches. It prefers them, but doesn't require them. You could just as easily provide the original for reference and let someone else diff it (which is at least a major improvement over requiring that only patches be made..) And the language used in that portion of the license is ambiguous enough (not my bug--that one's courtesy of the Trolls' lawyers) that you could drive a truck through it given that anything not explicitly stated can be taken any way you reasonably could take it under contract law. Releases without source it does forbid. The GPL does this too. There is a bug in the license I'd have fixed if anyone had bothered to point it out before the license was final that the license indicates you must release the source to anything that uses Qt unless you have a commercial license. Of course the license is a Copyright license and that requirement is beyond the scope of Copyright law, so it generally is unenforcable. (Which is why someone should have pointed it out so I could have removed it before I was finished and their lawyer had been brought in to finalize it..) -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- Kensey RMS for President??? RelDrgn ...or ESR, he wants a new job ;) pgpKNTMBpQYhB.pgp Description: PGP signature
Re: Corel's apt frontend
On Mon, Nov 01, 1999 at 01:44:32AM -0500, Raul Miller wrote: [Or even consider the restrictions on QPL+Artistic license. The new QPL requires patches, and forbids non-source releases, while Artistic requires renaming or severely restricted distribution -- so eventually you wind up with a build process with files you shouldn't rename and an executable which must be renamed.] On Sun, Oct 31, 1999 at 11:17:11PM -0800, Joseph Carter wrote: The QPL does not require patches. It prefers them, but doesn't require them. You could just as easily provide the original for reference and let someone else diff it (which is at least a major improvement over requiring that only patches be made..) Ok, thanks, I wasn't up on that. But basically what this means, you're obligated to distribute all prior versions -- perhaps as a CVS archive, perhaps as something less efficient. [If you're the author you can collapse versions, but not if you're building on someone else's work.] Not that I particularly care.. -- Raul
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] The Corel Front End *ceases* *to* *function* if dpkg is not present. On Sun, Oct 31, 1999 at 09:41:42PM -0800, Bruce Perens wrote: Yes, but copyright law does not deal with whether or not an application stops functioning if you remove another component of the system. Copyright law deals with copying. Wrong: Copyright doesn't restrict the functioning of the application while it does restrict the copying. But the functioning of the application -- its result -- is integral to copyright's definition of a computer program. -- Raul
GCC M3 frontend (was Re: Corel's apt frontend)
Richard Stallman writes: What front-end is this? I know nothing about it as yet. If the GPL is being violated for GCC, the FSF needs to take action. But we need to know the facts first. Would someone please send me a description of the situation? As I understand it, DEC SRC (now part of Compaq of course) released a Modula-3 frontend which uses GCC as a backend, with some kind of funny licence. I know about it because apparently the Cambridge computer lab did some further work on it: http://www.cl.cam.ac.uk/m3doc/linux/cambridge.html http://www.research.digital.com/SRC/modula-3/html/home.html The DEC SRC copyright is not GPL-compatible but appears to be intended to be at least somewhat free. Persuading them to GPL it might be possible. I enclose a copy. My apologies for assuming you (RMS) knew about this and not telling you about it. Ian. Digital License Agreement SRC Modula-3 1. Grant Of License. Digital Equipment Corporation, having a principal office at 146 Main Street, Maynard, MA 01754 (DIGITAL) grants to you (LICENSEE) the non-exclusive, non-transferable, royalty free right to use, modify, reproduce and distribute SRC Modula-3 (SOFTWARE) subject to the terms set forth herein. Any distribution of SOFTWARE shall include this Digital License Agreement in human readable form. 2. Title to Intellectual Property and Software. Subject to the limited rights and licenses granted under this License Agreement, all rights, title and interests including patent, copyright, and trademark rights in SOFTWARE are and shall remain vested in DIGITAL to the exclusion of LICENSEE. DIGITAL represents and warrants that DIGITAL has the legal right to grant such licenses as are expressly granted under this Agreement. 3. Copyright. The SOFTWARE is owned by DIGITAL or its suppliers and is protected by United States copyright laws and international treaty provisions. Therefore, you must treat the SOFTWARE like any other copyrighted material (e.g., a book or musical recording) except that you may use the SOFTWARE as provided in this Digital License Agreement. 4. Improvements. LICENSEE hereby grants to DIGITAL a non-exclusive, non-transferable, royalty free right to use, modify, reproduce and distribute with the right to sublicense at any tier, any improvements, enhancements, extensions, or modifications that LICENSEE make to SOFTWARE, provided such are returned to DIGITAL by LICENSEE. 5. DISCLAIMER OF WARRANTY. Because the SOFTWARE is a research work and not a released product, it is provided AS IS WITHOUT WARRANTY OF ANY KIND AND WITHOUT ANY SUPPORT SERVICES. EXCEPT AS SPECIFICALLY PROVIDED ABOVE IN SECTION 2, DIGITAL FURTHER DISCLAIMS ALL OTHER EXPRESS OR IMPLIED WARRANTIES OF MERCHANTABILITY OR OF FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK ARISING OUT OF THE USE OR PERFORMANCE OF THE SOFTWARE REMAINS WITH YOU. 6. Limitation of Liability. IN NO EVENT SHALL DIGITAL OR ITS SUPPLIERS BE LIABLE IN AN AMOUNT THAT EXCEEDS THE LICENSE FEE PAID BY LICENSEE FOR ANY DAMAGES (INCLUDING, WITH LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER PECUNIARY LOSS), REGARDLESS OF THE FORM OF CLAIM OR ACTIONS, ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE OR DOCUMENTATION, EVEN IF DIGITAL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU. 7. Acknowledgement of Allocation of Risk. LICENSEE acknowledges and agrees that the fees charged by DIGITAL in this Agreement reflect the allocation of risks provided by the foregoing limitation of liability. LICENSEE acknowledges and represents that it has read and understands these allocations of risk limiting the liability of DIGITAL and that it understands that a modification of the allocation of risks set forth in this agreement would affect the fees charged by DIGITAL, and that LICENSEE, in consideration of such fees, agrees to such allocations of risk. 8. LICENSEE INDEMNIFICATION. LICENSEE SHALL INDEMNIFY DIGITAL AGAINST ALL COSTS AND DAMAGE JUDGEMENTS, INCLUDING ATTORNEY'S FEES AND COSTS OF DEFENSE, INCURRED BECAUSE OF CLAIMS OF DAMAGE ARISING FROM LICENSEE'S POSSESSION OR USE OR INABILITY TO USE SOFTWARE. 9. GOVERNMENT RESTRICTED RIGHTS. The SOFTWARE and documentation are provided with RESTRICTED RIGHTS. Use duplication, or disclosure by the Government is subject restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in Technical Data and Computer Software clause in DFARS 252.227-7013, or subparagraphs (c)(i) and (2) of the Commercial Computer Software --
Re: Corel's apt frontend
Raul Miller [EMAIL PROTECTED] writes: We're not asserting copyright on that command-line interface. We're asserting copyright on a derived work There is no derived work anywhere else than in your mind. -- Henning MakholmI stedet for at finde på en bedre plan havde de alle sammen den frækhed at spørge mig, hvad *jeg* ville foreslå.
Re: Corel's apt frontend
Which is what happens when you make a CD with a /copy of/ dpkg and a /copy of/ get_it. Yes, but I don't see how that could be anything other than aggregation, and it's very, very clear how we treat aggregation. Copyright law doesn't care what programs do _when_they_run_ because it has no concept of reference. It is blind to the fact that one program won't run without another. Now, if you copy one work into another, that's a derivative work. Debian, however, doesn't assert a compilation copyright, so we have nothing to say about what works you put together on the same CD. We can only complain about infringement of individual works, and I don't see that happening here. Postulate for a moment that a dpkg had a license that required programs that called it, using its regular interface, to use the GPL. That would fail #9 of the DFSG. Thanks Bruce
Re: GCC M3 frontend (was Re: Corel's apt frontend)
I'd guess that Modula-3 compiler is including GPL headers to work with the GPL back-end. Is there confirmation of that? Thanks Bruce
Re: Corel's apt frontend
Previously Bruce Perens wrote: Yup. I want to see if he finds a difference where the Modula-3 compiler is concerned. I think he _will_, because the compiler _must_ be using GPL headers to work with the GCC back-end. I'm not sure.. it would be pretty easy do something where you simply push the intermediate code into the gcc backend. You wouldn't need headers to do that.. Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpfd5e1uuEmc.pgp Description: PGP signature
Re: Corel's apt frontend
From: Wichert Akkerman [EMAIL PROTECTED] I'm not sure.. it would be pretty easy do something where you simply push the intermediate code into the gcc backend. You wouldn't need headers to do that.. Yes, but you'd have to look very carefully at the GPL source code to figure out what the intermediate code _is_, and the result, if copied into a non-GPL program, would probably be an infringement. Thanks Bruce
Re: Corel's apt frontend
On Mon, Nov 01, 1999 at 04:23:36PM +0100, Wichert Akkerman wrote: FWIW, RMS also doesn't see a problem with this. Understood, but RMS didn't write dpkg. I think he'd be a little less sanguine about someone doing this with gcc. -- Raul
Re: Corel's apt frontend
Previously Bruce Perens wrote: Yes, but you'd have to look very carefully at the GPL source code to figure out what the intermediate code _is_, and the result, if copied into a non-GPL program, would probably be an infringement. But then you get back to the point it's easy to circumvent: one could make a GPL'ed patch for gcc to make inserting intermediate code simple, and then write a proprietary tool to generate that code.. Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpLH8kzRFkS6.pgp Description: PGP signature
Re: Corel's apt frontend
On Mon, Nov 01, 1999 at 07:58:20AM -0800, Bruce Perens wrote: Which is what happens when you make a CD with a /copy of/ dpkg and a /copy of/ get_it. Yes, but I don't see how that could be anything other than aggregation, and it's very, very clear how we treat aggregation. Copyright law doesn't care what programs do _when_they_run_ because it has no concept of reference. It is blind to the fact that one program won't run without another. quote A ''computer program'' is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. /quote While it's true that copyright law doesn't concern itself with reference it's better to say that it doesn't care about the nature of the reference than to say that reference hides part of the program from copyright law. The machine instructions are the machine instructions. Copyright law doesn't care whether you use clay tablets sequenced by a circus carousel, it doesn't care if files even exist as an abstraction on the computer. Why should it care that the instructions are distributed over multiple files? -- Raul
Re: Corel's apt frontend
[EMAIL PROTECTED] (Bruce Perens) writes: Yes, but you'd have to look very carefully at the GPL source code to figure out what the intermediate code _is_, That's knowledge. Facts are not copyrightable, only particular expressions of facts are. -- Henning MakholmKurt er den eneste jeg kender der er *dum* nok til at gå i *ring* på et jernbanespor.
Re: Corel's apt frontend
Previously Henning Makholm wrote: That's knowledge. Facts are not copyrightable, only particular expressions of facts are. Such as a particular way to express the format for the intermediate language? Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpj4ItQu2oBR.pgp Description: PGP signature
Re: Corel's apt frontend
Wichert Akkerman [EMAIL PROTECTED] writes: Previously Henning Makholm wrote: That's knowledge. Facts are not copyrightable, only particular expressions of facts are. Such as a particular way to express the format for the intermediate languag= e? No, file formats are not copyrightable, only actual files. Otherwise clones of proprietary packages with proprietary file formats would be in violation of copyright. -- Unix... is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. --Neal Stephenson
Re: Corel's apt frontend
Previously Ben Pfaff wrote: No, file formats are not copyrightable, only actual files. Otherwise clones of proprietary packages with proprietary file formats would be in violation of copyright. We're starting to digress here though.. lets stop this thread, I think all arguments have been made and in the end we'll just have to wait what comes out of Ian's discussion with Corel. Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpXgwXd0Nv87.pgp Description: PGP signature
Re: Corel's apt frontend
From: Wichert Akkerman [EMAIL PROTECTED] But then you get back to the point it's easy to circumvent: one could make a GPL'ed patch for gcc to make inserting intermediate code simple, and then write a proprietary tool to generate that code.. No, it'a already easy to insert intermediate code, I think the back-end is a separate process that reads it from a file. But I don't know if the back-end format is documented (as the dpkg interface is). To document it, you'd have to get rather deep into the source code, and you would probably end up copying snippets of the source code into the generator. Thanks Bruce
Re: GCC M3 frontend (was Re: Corel's apt frontend)
From: Henning Makholm [EMAIL PROTECTED] The backend (which I found at ftp://gatekeeper.dec.com/pub/DEC/Modula-3/release-3.6/m3cc.tar.gz ) is not pure GCC; they add (=link) in an m3.c which begins with /* Copyright (C) 1993, Digital Equipment Corporation */ /* All rights reserved.*/ /* See the file COPYRIGHT for a full description. */ The whole thing looks like a face-on violation of GPL 2(a,b). There is no question. Bruce
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 09:41:42PM -0800, Bruce Perens wrote: From: Raul Miller [EMAIL PROTECTED] The Corel Front End *ceases* *to* *function* if dpkg is not present. Yes, but copyright law does not deal with whether or not an application stops functioning if you remove another component of the system. Copyright law deals with copying. Which is what happens when you make a CD with a /copy of/ dpkg and a /copy of/ get_it. The question is whether you're allowed to make this copy. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpl8nCVOgfFh.pgp Description: PGP signature
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. On Sat, Oct 30, 1999 at 12:16:40PM -0700, Bruce Perens wrote: Well, I'd like the law to agree with you, actually. The problem is that copyright law does not consider _reference_ a form of derivation. This would give us problem with dynamic libraries, too, except that the headers get copied into the application. The difference between mere reference and derivation, in this case, is the difference between treating the computer program as a static work (like a book) and a dynamic work (like a screen play or music score). Considering the difficulty Bernstein is having -- establishing his first amendment rights in Bernstein v. US Dept. of Justice -- I doubt there's much basis in considering a computer program as a purely static work. -- Raul
Re: Corel's apt frontend
On Sat, Oct 30, 1999 at 10:16:38PM -0400, Raul Miller wrote: On Sat, Oct 30, 1999 at 12:16:40PM -0700, Bruce Perens wrote: Well, I'd like the law to agree with you, actually. The problem is that copyright law does not consider _reference_ a form of derivation. This would give us problem with dynamic libraries, too, except that the headers get copied into the application. The difference between mere reference and derivation, in this case, is the difference between treating the computer program as a static work (like a book) and a dynamic work (like a screen play or music score). This analogy doesn't really hold up, though: I don't know of any scores that as well as requiring royalties for perfomance or duplication forbid you to perform them with other songs. In particular, if you have a script that has some dialogue followed by ``now do the scene from foo, where Bar bazzes'' sure, you have to get permission to perform `foo', but that's it. This is as opposed to if the script writer had merely cut and pasted the words directly from foo, which would be a copyright violation. And we already have permission to use both dpkg and the Corel frontend. Just because you only use dpkg when Corel tells you too, well, so what? (As I understand it, the `you can't dynamic link against GPLed libraries from non-GPL programs' is more a case of `you can't #include GPLed header files in non-GPLed programs', which is a very different scenario (involving copying copyrighted works, rather than merely linking them)) Hmmm. I also suspect that the performance of a play would constitute a derived work, whereas I can't quite imagine how the execution of a program could. Odd. IANAL. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgp9BcfS0dCVP.pgp Description: PGP signature
Re: Corel's apt frontend
On Oct 30, Bruce Perens wrote: From: Raul Miller [EMAIL PROTECTED] Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. Well, I'd like the law to agree with you, actually. The problem is that copyright law does not consider _reference_ a form of derivation. This would give us problem with dynamic libraries, too, except that the headers get copied into the application. I suspect a blanket prohibition on reference by non-GPL'ed software would be incredibly dumb, even if it were permitted by copyright law. It would forbid anything non-free from operating as a shell (and would even prohibit KDE programs from launching GNU software). Not to mention that it'd be impossible to launch GNU software on a non-GNU system, or even boot a GNU system in the first place (as the boot sector is referenced by a non-free BIOS or other boot rom). I really can't even see the point of forbidding non-free programs from calling dpkg... either (a) they'll reimplement dpkg as non-free software (reimplementing dpkg might be a good idea in and of itself, but a non-free dpkg is pretty worthless to everyone, and probably a source of confusion to boot) or (b) adopt another package manager. (In any event, you're talking about double-indirection here; I assume apt's authors don't give a rat's ass who calls their program, and apt is the program that runs dpkg.) Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Open Directory Editor |Join the party that opposed the CDA| | http://dmoz.org/| http://www.lp.org/| =
Re: Corel's apt frontend
Hmmm. I also suspect that the performance of a play would constitute a derived work You can also perform a computer program, it's generally called _use_. The program's output may be derivative. Given that the GPL has language that is extremely un-restrictive regarding use, I doubt it could be applied to restricting front-ends that run across the exec() interface. Copyright law allows you to control public performance of your work, I think this is a separate concept from use. You could use this control, for example, to control use of your program on a web server, where the output of the program is presented to clients. Thanks Bruce
Re: Corel's apt frontend
On Sat, Oct 30, 1999 at 10:16:38PM -0400, Raul Miller wrote: The difference between mere reference and derivation, in this case, is the difference between treating the computer program as a static work (like a book) and a dynamic work (like a screen play or music score). On Sun, Oct 31, 1999 at 02:17:04PM +1000, Anthony Towns wrote: This analogy doesn't really hold up, though: I don't know of any scores that as well as requiring royalties for perfomance or duplication forbid you to perform them with other songs. Are you suggesting that what you don't know is legally relevant? And we already have permission to use both dpkg and the Corel frontend. Just because you only use dpkg when Corel tells you too, well, so what? Are you suggesting that that front end merely provides documentation on how to use dpkg? If I sold a cdrom which played music, and the music it played was a few bars of my own and some hit single I picked up from a music store, I'd have to have a legal right to sell that hit single. If I don't have that right it doesn't matter whether my cdrom is a regular music cdrom or some computer program that plays back encrypted mp3s. And it most certainly doesn't matter whether that computer program is statically linked or whether it uses a command interface to call the part that plays the hit single (unless the license on the hit single was sensitive to this point). Now, if you can show my anything in copyright law, or in the GPL, which makes any kind of distinction about the mechanics of how control is passed from the part of the work as a whole which is represented in one file to a part of that work which is represented in another file then I'll be happy to talk about that issue. But, last time I read through title 17, the *only* special provisions in copyright law for computer programs had to do with backups. And, the GPL is very careful to define what it means by program -- and that definition most definitely isn't restricted to a single binary object which runs in a single memory space or any other such thing. Anyways, unless you want to provide a reference to back up your point, why are we even discussing this? -- Raul
Re: Corel's apt frontend
On Sat, Oct 30, 1999 at 11:40:16PM -0500, Chris Lawrence wrote: I really can't even see the point of forbidding non-free programs from calling dpkg... either (a) they'll reimplement dpkg as non-free software (reimplementing dpkg might be a good idea in and of itself, but a non-free dpkg is pretty worthless to everyone, and probably a source of confusion to boot) or (b) adopt another package manager. Or (c) change the license on that program. And, if someone wants to re-implement dpkg, more power to them. Meanwhile, I think Ian has the right to talk to Corel about this issue. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:28:39AM -0500, Raul Miller wrote: If I sold a cdrom which played music, and the music it played was a few bars of my own and some hit single I picked up from a music store, I'd have to have a legal right to sell that hit single. A better analogy might be if that cdrom automatically went over to the next CD and played a track from it mid-song. Could the copyright holders of the next CD have any control over you selling a CD that does that? As someone pointed out, this would prohibit you from running perl from bash, or running bash from a non-GPL x-terminal or any GPL program on a proprietary X server. Those would be the same sort of aggretion as get_it calling dpkg. -- David Starner - [EMAIL PROTECTED]
Re: Corel's apt frontend
Hmmm. I also suspect that the performance of a play would constitute a derived work On Sat, Oct 30, 1999 at 11:27:50PM -0700, Bruce Perens wrote: You can also perform a computer program, it's generally called _use_. The program's output may be derivative. It's not the output that's the issue here, but the interaction between the two pieces of the program. I think the real problem in this discussion is that the word program means different things to different people. But the GPL is very careful about how it defines program. In understanding this distinction, it's probably worth noting that, as linux programmers, we're working in an environment where program has a specific, technical meaning -- at the moment, we tend to think of a program as a specific executable file. However, the GPL was written by (or for) a lisp programmer and from that point of view the mechanical issues of storage and parameter passing were never all that important. In the lisp environment there's all sorts of things which could reasonably be called programs... Given that the GPL has language that is extremely un-restrictive regarding use, I doubt it could be applied to restricting front-ends that run across the exec() interface. Once again, this isn't an issue of use, it's an issue of definition. The combination of dpkg plus the front end is an example of what the GPL defines as a program. Copyright law allows you to control public performance of your work, I think this is a separate concept from use. You could use this control, for example, to control use of your program on a web server, where the output of the program is presented to clients. In all the examples I can think up with that's a different issue. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:46:56AM -0500, Raul Miller wrote: Given that the GPL has language that is extremely un-restrictive regarding use, I doubt it could be applied to restricting front-ends that run across the exec() interface. Once again, this isn't an issue of use, it's an issue of definition. The combination of dpkg plus the front end is an example of what the GPL defines as a program. Let's assume for a moment and for the purposes of argument that running get_it does in fact create a single combined work consisting of get_it and dpkg. The user who's lawfully aquired both dpkg and get_it may modify either one by incorporating the other therein as he sees fit without violating copyright law, so long as the result is not distributed. This is the law in both the US and in Europe. Since in a legal context, actions performed by a machine are considered to be performed by the operator of that machine and not the machine itself, it is the operator of the computer running get_it that requests the combination of the two copyrighted works. I see no reason why get_it's use (or incorporation) of dpkg at the operator's request would be in any way affected by copyright law. This has been tested in court by a software package called Game Genie, which patches video game software to enable cheating and then executes the result. Game Genie can also begin execution of a game from a point other than the intended start. A federal judge ruled that the Game Genie software was not a derived work of the copyrighted software that it patched and executed, nor was its publisher responsible for contributory infringement. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] If I sold a cdrom which played music, and the music it played was a few bars of my own and some hit single I picked up from a music store, I'd have to have a legal right to sell that hit single. Well, this is different in that you are copying the hit single. Also, hit singles have different rights from GPL programs. Now, if you can show my anything in copyright law, or in the GPL, which makes any kind of distinction about the mechanics of how control is passed from the part of the work as a whole which is represented in one file to a part of that work which is represented in another file then I'll be happy to talk about that issue. That is just the problem. Copyright law does not say _anything_ about passing of control. It deals with copying. So, if you are not copying a work into another work in order to produce a derivative work, copyright law is silent upon the issue. Thanks Bruce
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:59:24AM -0500, Raul Miller wrote: But the xterminal example is a bit more constrained. Here, you could still run into trouble -- but only if you were distributing both the proprietary x software and the GPLed software as composite parts of some larger work. [And, the mere aggregation clause of the GPL restricts the sorts of larger works which can get into trouble this way.] I must say this thread is VERY disturbing. Have you people considered what you're talking about? How is a non-GPL shell or environment spawning a GPL app different than a GPL shell spawning a non-GPL app? Either way it's the same sort of run-time connection, using the same interface. If one is not allowed, the other is not allowed either. If that is the case the GPL contaminates other software (like the Debian distribution as a whole) by requiring that EVERY SINGLE THING we distribute be GPL. A specific example of something that the GPL would be trying to contaminate would be Apache. Fortunately, the GPL does not do this. I think it's approaching dellusional to believe otherwise, nothing in the GPL itself indicates that simply running a program or having another program run it should be considered a combined work. ANd in fact the GPL is careful to say that mere aggregation of GPL packages is perfectly acceptable if we follow the other restrictions in the GPL. The reason Richard has not tried to close this apparently obvious loophole in the GPL is probably quite simply that he couldn't do it--the law just doesn't work that way. A Copyright license should not cover usage because it can't legally enforce usage restrictions. And IM(NS)HO, if he tried Richard would find he'd lost just about all respect anyone has for him. If Richard came up to me and told me that Debian couldn't distribute Apache anymore (advertising clause isn't GPL compatible) because it's init.d script uses /bin/sh--bash on a Debian system and therefore violates the GPL on bash, I'd tell him what he could do with the GPL... I have no choice to believe he's got more sense than that. I think we could do a lot better to focus on educating people as to why free software is important---and not just why it makes for better software either. Sure that's nice and all, but in the end it's that the freedom and openness that make the software as good as it is so quickly. Case in point, Netscape may have released their source but it wasn't until they actually tried to open the development process that things started moving at any measurable progress level. Having published source is nice, but it's not enough on its own. FWIW, I think this is a problem with Qt still today. They pretty much want you to make whatever changes you want, diff them, and submit the patch for their approval and possible future inclusion or not. Not exactly a major encoaragement for people to want to work on it is it? -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- Knghtbrd mariab - don't think Debian hasn't had some very stupid and obvious bugs before Knghtbrd of course, we usually fix ours BEFORE we release =D pgpFF8BZbLclv.pgp Description: PGP signature
Re: Corel's apt frontend
One problem this thread illustrates is that the GPL is too darned easy to circumvent today. When it was written, there was less use of dynamic linking, less client-server computing, and no object brokers. Bruce
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:59:37AM -0500, David Starner wrote: A better analogy might be if that cdrom automatically went over to the next CD and played a track from it mid-song. Could the copyright holders of the next CD have any control over you selling a CD that does that? On Sun, Oct 31, 1999 at 01:59:24AM -0500, Raul Miller wrote: As I understand it, Corel would be distributing their front end with dpkg -- this conflicts with the distinction you're trying to raise. On Sun, Oct 31, 1999 at 01:32:45AM -0600, David Starner wrote: Okay, you sell the other CD with it. Still doesn't matter. Sure, because you're intending that they both be copied onto the same system. That's not the same as independent cds. As someone pointed out, this would prohibit you from running perl from bash, or running bash from a non-GPL x-terminal or any GPL program on a proprietary X server. Those would be the same sort of aggretion as get_it calling dpkg. But the xterminal example is a bit more constrained. Here, you could still run into trouble -- but only if you were distributing both the proprietary x software and the GPLed software as composite parts of some larger work. [And, the mere aggregation clause of the GPL restricts the sorts of larger works which can get into trouble this way.] I don't understand you're emphasize on distributing them together. So far, we don't know that the CD won't contain dpkg and the first step of installation is to download it from the net. Why would that be - why should it be - any different? Distributing them together is just part of the picture. To understand why it's a part of the picture you'd have to have read the GPL. Rather than try to explain the GPL, yet again, I'll just suggest you read it and pay attention what it's allowing you to do. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:46:56AM -0500, Raul Miller wrote: Once again, this isn't an issue of use, it's an issue of definition. The combination of dpkg plus the front end is an example of what the GPL defines as a program. On Sun, Oct 31, 1999 at 02:17:01AM -0500, Brian Ristuccia wrote: Let's assume for a moment and for the purposes of argument that running get_it does in fact create a single combined work consisting of get_it and dpkg. Feel free, but that's not what I've claimed. I've claimed that get_it (is that really the name of the front end?) has been designed to enhance dpkg, and that get_it is being distributed to enhance dpkg. Running it just illustrates the intentions of the authors, nothing more. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 04:58:29AM -0500, Raul Miller wrote: If that is the case the GPL contaminates other software (like the Debian distribution as a whole) by requiring that EVERY SINGLE THING we distribute be GPL. A specific example of something that the GPL would be trying to contaminate would be Apache. If people are distributing derivative works that include GPLed code and apache, sure. But if apache is just calling /bin/sh, there's nothing special about that -- any /bin/sh can be used. And if the apache module in question calls /bin/bash specifically? Or if /bin/bash calls apache? Fortunately, the GPL does not do this. I think it's approaching dellusional to believe otherwise, nothing in the GPL itself indicates that simply running a program or having another program run it should be considered a combined work. ANd in fact the GPL is careful to say that mere aggregation of GPL packages is perfectly acceptable if we follow the other restrictions in the GPL. Sure, and that has nothing to do with the Corel front end. The Corel front end for dpkg is obviously intended to enhance dpkg. The line HAS to be drawn somewhere. ANY program can be said to enahnce ANY OTHER program. How clearly a program enhances another is completely an arbitrary opinion. Licenses should not be applied arbitrarily. (FWIW in this case I agree---their front end IS an attempt to enhance apt which is an attempt to enhance dpkg. They're seperate works though..) -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- tigah_- i have 4gb for /tmp Knghtbrd What do you do with 4G /tmp? Compile X? tigah_- yes pgpInu7hulCh3.pgp Description: PGP signature
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 02:41:52AM -0800, Joseph Carter wrote: And if the apache module in question calls /bin/bash specifically? Or if /bin/bash calls apache? I'm having trouble imagining a work which involves apache and bash where bash is an inseperable aspect of the whole. Bashisms are so.. trivial.. and so unrelated to web serving. I guess it might be possible for you to create one, though -- and if you did you'd have to address the copyright issues before you could distribute it. [Do you know anyone distributing apache and bash together along with such software? If so, you might want to suggest that they not use bashisms...] -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 04:44:47AM -0500, Raul Miller wrote: It's true that the GPL was written for programs, not music. However, many countries have a legal concept of a moral right of integrity for a copyrighted work, to prevent its mutilation. The U.S. doesn't recognize this as an automatic right, From looking at http://www.smithlyons.ca/it/laws/copyright_act.htm, Canada does though. I just love the whole `linking with non-free software as vandalism' aspect of this. :) I didn't think this was so much about the right of integrity, so much though as just regular copyright. I'm not entirely sure the GPL's definition of derivative work would matter so much in this case, though. The Canadian law apparently is something like: 28.2 (1) The author's right to the integrity of a work is infringed only if the work is, to the prejudice of the honour or reputation of the author, (a) distorted, mutilated or otherwise modified; or (b) used in association with a product, service, cause or institution. `used in association with' is much broader than `derived from', or `based on'. I'd happily concede that that's the case here, and I wouldn't be entirely surprised if you can make a case of `to the prejudice of the honour or reputation of the author'. I'll reserve the right to find it really funny though :) And it most certainly doesn't matter whether that computer program is statically linked or whether it uses a command interface to call the part that plays the hit single (unless the license on the hit single was sensitive to this point). Please back this up. I'm saying that there's no text in title 17 of the U.S.Code which raises this issue. And, I'm saying that there's no text in the GPL which raises this issue. If I'm wrong, it's trivial to prove me wrong: quote the text which raises this issue. Okay, forget this. I was assuming you were saying that having system(dpkg --help); in your program meant that you had to put that program under the GPL. I think this is wrong, because you're not actually copying any of dpkg, and thus copyright law doesn't come into effect. Whereas what you're really saying, is that when you create a CD, or ftp site, or distribution, or whatever, containing both dpkg and your dpkg_help program, you've created a derived work. Which I agree with. You're also saying that this isn't `mere aggregation', so you're not allowed to use the easy-out the GPL gives you. So it'd be perfectly okay for Corel to do something like setup their own ftp site, that doesn't contain dpkg, but does contain their frontend, and tell people to include both the Corel and Debian sites in their apt sources.conf. We'll blithely assume they can get to the point where Apt's functional without infringing, although I'm not sure how they'd manage this. In this case, since they're never distributing dpkg, or any part of it, they don't possibly infringe. In spite of the system() call in the frontend. Agreed? But let's work with a single CD that contains both get_it and dpkg. From the appropriate section of the GPL: ] These requirements apply to the modified work as a whole. If Hmmm. Note, `modified work'. First thought, is that this may not even apply at all. Under section (1) they can simply copy dpkg verbatim as they receive it (from the Debian mirror network), and ignore section (2) entirely. This could work quite legitimately. It'd even force them to cooperate with Debian, since they'd have to distribute exactly what we give them which means if they want a bugfix made, they have to give it to us first. Well. Theoretically. This'd be pretty easy to work around. OTOH, you could claim that making a CD is actually getting dpkg, and making some modifications (namely, adding a whole bunch of other stuff). This seems more like a legal technicality than anything I'd really want to be a part of, though. ] identifiable sections of that work are not derived from the Program, ] and can be reasonably considered independent and separate works in ] themselves, This exception kind-of applies: identifiable sections are not derived from dpkg, and can reasonably be considered separate. It's questionable whether you'd consider them independent... ] then this License, and its terms, do not apply to those ] sections when you distribute them as separate works. ...but, since this section seems to be for `if you add a function in a separate source file, you're allowed to license that source file however you like, as long as its GPL compatible', I think we can consider it independent. ] 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. ...but that doesn't matter for the CD anyway. The paragraph after the next one is
Re: Corel's apt frontend
On Sat, Oct 30, 1999 at 11:40:16PM -0500, Chris Lawrence wrote: I suspect a blanket prohibition on reference by non-GPL'ed software would be incredibly dumb, even if it were permitted by copyright law. It would forbid anything non-free from operating as a shell (and would even prohibit KDE programs from launching GNU software). Not to mention that it'd be impossible to launch GNU software on a non-GNU system, or even boot a GNU system in the first place (as the boot sector is referenced by a non-free BIOS or other boot rom). It's amazing how often this is misunderstood. Use of a GPL program is not restricted, or even covered by the GPL. Only copies, modifications and distributions are. So, a blanko prohibition on reference would only affect the distribution (etc) of a derived work, not the use. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 04:44:47AM -0500, Raul Miller wrote: It's true that the GPL was written for programs, not music. However, many countries have a legal concept of a moral right of integrity for a copyrighted work, to prevent its mutilation. The U.S. doesn't recognize this as an automatic right, On Sun, Oct 31, 1999 at 10:43:29PM +1000, Anthony Towns wrote: From looking at http://www.smithlyons.ca/it/laws/copyright_act.htm, Canada does though. I just love the whole `linking with non-free software as vandalism' aspect of this. :) I didn't think this was so much about the right of integrity, so much though as just regular copyright. I agree with you completely. I brought up this issue to show that the underlying concept isn't unique to the GPL. What I really should have done was come up with an example of a Broadway play where the license limited the forms the performance could take -- but I didn't want to take that much time for legal research. So I just settled for showing that the there's similar legal concepts. ... Okay, forget this. I was assuming you were saying that having system(dpkg --help); in your program meant that you had to put that program under the GPL. I think this is wrong, because you're not actually copying any of dpkg, and thus copyright law doesn't come into effect. Whereas what you're really saying, is that when you create a CD, or ftp site, or distribution, or whatever, containing both dpkg and your dpkg_help program, you've created a derived work. Which I agree with. You're also saying that this isn't `mere aggregation', so you're not allowed to use the easy-out the GPL gives you. So it'd be perfectly okay for Corel to do something like setup their own ftp site, that doesn't contain dpkg, but does contain their frontend, and tell people to include both the Corel and Debian sites in their apt sources.conf. We'll blithely assume they can get to the point where Apt's functional without infringing, although I'm not sure how they'd manage this. In this case, since they're never distributing dpkg, or any part of it, they don't possibly infringe. In spite of the system() call in the frontend. Agreed? That's almost exactly what I'm saying. I say almost exactly because of the relatively new concept of contributory infringement. Rather than spend a lot of time defining this concept, I'll just refer you to http://www.dcl.edu/lawrev/97-4/muroff.htm#24 If it weren't for this, then yes: I would agree. But let's work with a single CD that contains both get_it and dpkg. From the appropriate section of the GPL: ] These requirements apply to the modified work as a whole. If Hmmm. Note, `modified work'. First thought, is that this may not even apply at all. Under section (1) they can simply copy dpkg verbatim as they receive it (from the Debian mirror network), and ignore section (2) entirely. This could work quite legitimately. It'd even force them to cooperate with Debian, since they'd have to distribute exactly what we give them which means if they want a bugfix made, they have to give it to us first. Well. Theoretically. This'd be pretty easy to work around. OTOH, you could claim that making a CD is actually getting dpkg, and making some modifications (namely, adding a whole bunch of other stuff). This seems more like a legal technicality than anything I'd really want to be a part of, though. Well, for example, editorial notes are considered modification, for the purposes of copyright -- even though anyone who edits material would consider the underlying document to be unmodified. But the real kicker is contributory infringement. Because the front end is designed to incorporate dpkg, it doesn't really matter that Corel is allowed to distribute verbatim copies of dpkg -- using that permission to create massive quantities of installed systems which are running what is clearly a composite program is still an issue. ] identifiable sections of that work are not derived from the Program, ] and can be reasonably considered independent and separate works in ] themselves, This exception kind-of applies: identifiable sections are not derived from dpkg, and can reasonably be considered separate. It's questionable whether you'd consider them independent... ] then this License, and its terms, do not apply to those ] sections when you distribute them as separate works. ...but, since this section seems to be for `if you add a function in a separate source file, you're allowed to license that source file however you like, as long as its GPL compatible', I think we can consider it independent. Sure, and even if the corel front end were in the same executable file as dpkg it would be reasonable for the corel front end to have its own copyright for the parts supplied by Corel. But you still wouldn't be allowed to distribute the result if the corel license conflicted with the GPL. ] But when you ]
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] quote 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The Program, below, refers to any such program or work, and 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. (Hereinafter, translation is included without limitation in the term modification.) Each licensee is addressed as you. Surely you can see that is circular. To paraphrase, The program is the program or a derivative work of the program. There is no definition there, unless you consider A rose is a rose to be a definition. The act of running the Program is not restricted This is going to make it extremely difficult to convince anyone that the act of running th program through its intended interface, or packaging the program with a work that runs it through its intended interface, can possibly create a derived work. So, you can circumvent the GPL through various kinds of interfaces that allow one program to refer to another without explicit copying. It's a problem in the GPL that should be fixed. I don't believe we can talk our way around it without fixing the GPL first, and then it only applies to future work. Thanks Bruce
Re: Corel's apt frontend
From: Joseph Carter [EMAIL PROTECTED] Given the choice between making the GPL a non-free license and having a way to potentially do something bad with a GPLed program, I would say it's better to leave things as they are. It's a false dichotomy. I think we could keep it a free license and close this loophole too. Thanks Bruce
Re: Corel's apt frontend
Raul Miller [EMAIL PROTECTED] writes: Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. A front end is a front end is a front end. It's capable of controlling any program that has a user interface that coincides with a certain subset of dpkg's user interface. Claiming that this makes the front end a legal deriviate of any random program it can control is suspiciously close to claiming an interface copyright. In a wierd, backwards way, but an interface copyright nevertheless. -- Henning MakholmMake it loud, make it complicated, make it long, and make it up if you have to, but it'll work all right.
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 10:19:30AM -0800, Bruce Perens wrote: The copying that's relevant here is the copying which goes into the production of the cdroms. That's the same whether dpkg is in the same file as corel's front end or a different file. But that can not possibly be relevant, because it's explicitly excluded in the GPL. Could you be more specific? My argument is that since the corel front end enhances dpkg it counts as a derivative work based on dpkg for the purpose of copyright law, just as editorial notations on a screen play create a derivative work even though the text of the screen play is in some sense unchanged. My argument is that courts don't care whether a file has a .o extension, a .so, or no extension at all -- that they aren't really concerned how many files make up the program, and that they don't care all that much about the technical details of which system calls where made or what address spaces are in use. So if you're talking about the verbatim copy permission in the GPL I'm saying that it's irrelevant for this argument because we're not talking about a verbatim copy but a derivative work. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 10:53:31AM -0800, Bruce Perens wrote: Given the choice between making the GPL a non-free license and having a way to potentially do something bad with a GPLed program, I would say it's better to leave things as they are. It's a false dichotomy. I think we could keep it a free license and close this loophole too. Please keep trying then--but the discussion is headed the wrong way right now. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- * o-o always like debmake because he knew exactly what it would do... ibid o-o: you would ;-) pgpFb3bw5rUf3.pgp Description: PGP signature
Re: Corel's apt frontend
[EMAIL PROTECTED] (Bruce Perens) writes: The act of running the Program is not restricted This is going to make it extremely difficult to convince anyone that the act of running th program through its intended interface, or packaging the program with a work that runs it through its intended interface, can possibly create a derived work. Which is fine. It *can't* possibly. It's a problem in the GPL that should be fixed. I don't see any problem. -- Henning Makholm*Se*!! Nu hælder den vand ud af ørerne *igen*!! *Et mirakel*!!!
Re: Corel's apt frontend
Raul Miller [EMAIL PROTECTED] writes: Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. On Sun, Oct 31, 1999 at 08:36:39PM +0100, Henning Makholm wrote: A front end is a front end is a front end. A variable is a variable is a variable. That doesn't mean that all variables are equivalent. It's capable of controlling any program that has a user interface that coincides with a certain subset of dpkg's user interface. Clearly you're not talking about all front ends here -- you can't be talking about ddd, for example. So you're talking about the Corel front end for dpkg. And that's very clearly not designed to be a program which interfaces to arbitrary package managers, but a program which interfaces specifically to dpkg. Corel would be distributing it in conjunction with dpkg and not, for example, in conjunction with sun's package manager. And I think it would utterly fail if you renamed pkgadd as dpkg. Claiming that this makes the front end a legal deriviate of any random program it can control is suspiciously close to claiming an interface copyright. In a wierd, backwards way, but an interface copyright nevertheless. More like a copyright for where there is no interface. For example, if Corel supplies its own implementation of dpkg to run under the front end then there would obviously be no problem. Here, the commonality between two distinct implementations create an interface and there's no interface copyright on that interface. To give an example of the other extreme, consider a program which used the command line interface plus the ptrace interface to interact with a verbatim copy of gcc. With a little thought you can do anything in this fashion that you can do with relinking (and more). Would you argue that that's legal? If not, and if the part of the program which implemented ptrace was itself released under the GPL, would that make the derived compiler legal under the GPL? Allow me to repeat the definition of a computer program under us copyright law: A ''computer program'' is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. Do you see anything in there which says that if execve() is used then the instructions it executes aren't part of the computer program? So yeah, for the purposes of copyright law, it's reasonable to consider that all programs called by a shell script are a part of that computer program. And, yeah, this can have interesting implications if you're trying to distribute this computer program. Then again, if you don't have the right to distribute all the pieces of a program why would you be distributing it? Mostly this is a non-issue... -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 05:53:31AM -0500, Raul Miller wrote: And if the apache module in question calls /bin/bash specifically? Or if /bin/bash calls apache? I'm having trouble imagining a work which involves apache and bash where bash is an inseperable aspect of the whole. Bashisms are so.. trivial.. and so unrelated to web serving. I guess it might be possible for you to create one, though -- and if you did you'd have to address the copyright issues before you could distribute it. [Do you know anyone distributing apache and bash together along with such software? If so, you might want to suggest that they not use bashisms...] The GPL doesn't say there are legal issues involved with doing so. Also if Corel's front-end calls apt, the fact that apt uses dpkg as a backend is arguably apt's problem since it is intended for apt to also support rpm at some point. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- California, n.: From Latin calor, meaning heat (as in English calorie or Spanish caliente); and fornia' for sexual intercourse or fornication. Hence: Tierra de California, the land of hot sex. -- Ed Moran pgpwlguzsUCiq.pgp Description: PGP signature
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] My argument is that since the corel front end enhances dpkg it counts as a derivative work based on dpkg for the purpose of copyright law, just as editorial notations on a screen play create a derivative work even though the text of the screen play is in some sense unchanged. I agree that it enhances dpkg. The problem is that it does it without copying. You could postulate that the use of a command-line interface is a device contrived for the explicit purpose of circumventing the copyright, but only if the command-line interface was created for that purpose. The command-line interface, however, pre-existed Corel's work and was made explicitly for other programs, such as shell scripts, to call it. If we want to assert a copyright on that command-line interface, what we need is a copyright on the list of commands that can be fed to that interface, so that all programs that call those commands are infringing on that copyright. Then, we have to write in exceptions for shell scripts and normal use, everything except enhanced front-end programs. I doubt the result would be a DFSG-compliant license. And it's clearly an API copyright. If we want to modify the GPL to prevent this from happening in the future, I think we can do that and keep it free software. I don't see how we can do this retroactively without shooting ourselves in the foot. Thanks Bruce
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] My argument is that since the corel front end enhances dpkg it counts as a derivative work based on dpkg for the purpose of copyright law, just as editorial notations on a screen play create a derivative work even though the text of the screen play is in some sense unchanged. On Sun, Oct 31, 1999 at 01:47:31PM -0800, Bruce Perens wrote: I agree that it enhances dpkg. The problem is that it does it without copying. But you do need a copy of dpkg or it won't work. So I don't see how this can be a problem. You could postulate that the use of a command-line interface is a device contrived for the explicit purpose of circumventing the copyright, but only if the command-line interface was created for that purpose. The command-line interface, however, pre-existed Corel's work and was made explicitly for other programs, such as shell scripts, to call it. Why make this postulate? ld wasn't invented to circumvent copyright, why must execve() have been invented for this purpose? If we want to assert a copyright on that command-line interface, what we need is a copyright on the list of commands that can be fed to that interface, so that all programs that call those commands are infringing on that copyright. Then, we have to write in exceptions for shell scripts and normal use, everything except enhanced front-end programs. I doubt the result would be a DFSG-compliant license. And it's clearly an API copyright. We're not asserting copyright on that command-line interface. We're asserting copyright on a derived work which happens to use that command line interface. Once again, there's nothing in the GPL about linkages, and there's nothing in copyright law about linkages. A function call that happens to use fork(), execve(), waitpid() isn't singled out from any other machine instructions in copyright law. The problem here is that the front end relies on GPLed code to create its result, but uses a proprietary license. So to distribute the resulting program (which happens to not reside in a single file) Corel would need to fix the licensing conflict between these two pieces of the program. If we want to modify the GPL to prevent this from happening in the future, I think we can do that and keep it free software. I don't see how we can do this retroactively without shooting ourselves in the foot. And I don't think it's necessary to modify the GPL at all. -- Raul
