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
> ] 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.
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
> 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.
That's a different copy of "based on". If I write a screen play and my
stage directions for part II say "Wolfe's Colored Museum, first act",
that would be more like the concept of "based on" we're talking about
here.
It's important to note that computer programs aren't screenplays, but
there is a performance aspect to them and the courts do consider this
relevant. Here's what U.S. copyright law has to say about this issue
of "what is a computer program?":
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.
Based on this definition, it's fairly clear that Corel's front end is
a program which incorporates dpkg. You don't get the documented result
if it's run and dpkg is not included.
> 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.
Yeah, copyright law can be rather nutty when you sit back and think
about it.
But it's what we have to work with.
--
Raul
Reply to: