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 then:
] In addition, mere aggregation of another work not based on the Program
] with the Program (or with a work based on the Program) on a volume of
] a storage or distribution medium does not bring the other work under
] the scope of this License.
This is probably iffy at best. It seems perfectly reasonable to me to
consider apt or get_it to be `a work based on dpkg'. But that's more of
a technical interpretation, than a legal one --- an academic work can be
`based on' a bunch of other work, but only ever list them as references,
which doesn't really give copyright a chance to come into play. So it
doesn't seem entirely unreasonable to think that it's /not/ based on
dpkg, under the interpretation that a work is based on another if you
copied from it.
So I'm not entirely sure. I'd be inclined to interpret it as aggregation,
and I don't *think* that's entirely unreasonable.
I don't think it's a particularly consistent restriction since it can
be so easily avoided in other ways (either by separate distribution,
or by verbatim distribution). This is as opposed to, say, static linking
in which case the works can't be separated because they're, well, linked,
or dynamic linking in which case they headers have been compiled into the
program and aren't really separable. In these cases you can't distribute
the derived work (the binary) separately from the GPLed material. In the
current case, you can. As such, if you put the two bits that you could
just as easily have distributed separately next to each other on a CD,
you're merely aggregating them.
IANAL, YMMV. Hell, the way this is going, MMMV.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <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
Attachment:
pgpzcUcb7reIy.pgp
Description: PGP signature