Re: Corel's apt frontend
> > 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.
On Sun, Oct 31, 1999 at 01:28:39AM -0500, Raul Miller wrote:
> > Are you suggesting that what you don't know is legally relevant?
On Sun, Oct 31, 1999 at 05:48:22PM +1000, Anthony Towns wrote:
> Are you suggesting that your analogies have legal force?
Not exactly, but close enough for discussion purposes.
> Change "I don't know of any" to "there aren't any". Whatever. The
> analogy doesn't hold becuase the interesting aspect of the GPL thing
> just doesn't apply to music and such in general: music is generally
> licensed either `no you can't use any of it', or `yes you can perform
> it', or `yes, you can sample it', it doesn't have weird quandries like
> `yes, you can sample it, but only if you distribute the score along
> with any recordings'.
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, but in some cases courts have upheld analogous
concepts -- for example, in Gilliam v. American Broadcasting Cos., Inc.,
538 F.2d 14, 24 (2d Cir. 1976).
And for the case of the GPL we're not talking about an unwritten right --
the GPL does explicitly make statements about the work as a whole.
[By the way, for the case of music, there's a fairly typical sort of
license for music where you have to pay for each performance. That's not
precisely the same thing as the scenario you're trying to talk about, but
even here there's a weak analogy: you'd have to pay twice to perform the
two songs together if they each had such licenses.]
> > > 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?
> No, it provides instructions on when to use dpkg.
If by "instructions" you mean "machine instructions" then that's no different
from any other kind of program.
> > 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.
> Sure. But in this case you already have permission to put the hit
> single on your CD. It's GPLed, remember.
Um.. I don't know what you're thinking here. You've already established
that the GPL is written for programs, not music. And, I was talking about
the nature of licenses in general, so to make it obvious how that character
of licenses is relevant in the context of the GPL.
If we pretend that it's relevant to talk about the GPL applying to music
then there would have to be some concept of non-free music, and this
music GPL would have to prevent the creation of musical works which
combined GPLed music and non-free music. To decide whether it applied
to the creation of music cds we'd have to examine this music license to
see what it said about such a case....
> > 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.
However, since I'm saying that there is no such text the only proof
I can provide is to quote all of 17 USC and all of the GPL. Is that
what you're asking me to do?
> The difference is that static linking produces a derived work (the
> executable) that consists of both your work (foo.c) and a GPLed work
> (bar.a). Dynamic linking produces a derived work that consists of both
> your work (foo.c) and a GPLed work (bar.h). Calling a function via
> system() or fork/exec doesn't combine your work with a GPLed work, and
> thus doesn't produce a work derived from a GPLed work, and thus the
> GPL, and copyright in general, simply doesn't apply.
The GPL doesn't talk about fork() and exec(), nor does copyright law.
> Copyright is about /copying/ stuff, afterall. How have you copied anything
> by simply referring to dpkg?
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.
> > 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.
>
> From section 0 of the GPL:
>
> ``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".)''
>
> Note in particular the phrase `a work containing the Program or a portion
> if it'. Note that Corel's alleged frontend doesn't contain dpkg or a
> portion of it.
Hmm... I think I see your point. But the work containing the program
would be the cdrom set that Corel distributes. Yes, that work does happen
to contain a number of things which are unrelated to dpkg and Corel's
front end, but that doesn't meant that Corel's front end is intended to
be anything other than a part of a joint work which includes dpkg.
> From http://www.law.cornell.edu/copyright/copyright.act.html#17usc411,
> which purports to be the 1976 Copyright act, says:
>
> 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".
>
> which doesn't appear to include ``A work which passes control to the original
> work is a derivative work''.
Um.. the Corel front end requires dpkg. You could say that:
The Corel front end is based upon dpkg.
The Corel front end adapts dpkg so that it's more accessible to users.
The Corel front end elaborates upon the functionality provided by dpkg.
It's true that none of the above says anything about control flow. Then
again, control flow was never the issue.
> > Anyways, unless you want to provide a reference to back up your point,
> > why are we even discussing this?
>
> Because you're completely wrong, clearly.
Heh.
> (or, alternatively, is there any real need to get quite so snobby?)
I couldn't think of a clearer way of expressing myself. Sorry about that.
--
Raul
Reply to: