Re: Corel's apt frontend
> From: Raul Miller <moth@debian.org>
> > 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
Reply to: