Re: module license taints kernel.

David Schwartz <davids@xxxxxxxxxxxxx> writes:
On Nov 19, 11:50 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:
So you rescind your claim that linkers create derivative works?

If have never claimed that linkers create derivative works.

Okay, then maybe I don't know what we're arguing about.

Wether the fact that a tool is not capable of operating on its own has
any relevancy wrt properties of what the person using the tool was
using the tool for, presumably.

You have a new claim -- that a work fed into a linker might be a
derivative work of some other work. Well, duh, of course it might.

No. I still have the original claim, namely, that what is fed into the
linker constitutes 'a work'.

What is fed into the linker is more than one work.

This depends on what is fed into the linker.

That's why it is different from what I had been writing about, namely,
files intended to be linked together using an interface specific to
one of them, eg Linux kernel modules.

Why do you think this matters?

Hmm ... why do you think it doesn't, taking into account that
'derivative works' exist?

Yes, if you did so by a creative process.

In other words: If I combined [...] to create something which has a
function of its own.

No. Function is completely irrelevant. Really.

It is not 'completely irrelevant' because we are arguing about
computer software here and 'having a function' is a necessary property
of computer software and 'having a different function than ...' means
that what has a different function than ... is a different software
than ... (sufficient, but not necessary condition).

[...]

This means that I would have added something which depends
properties specific to both of the other parts and adds
something to them which did not exist before I created it. And
then, I would have made a derivative work of the other two parts.

Yes, provided this process is creatively selective.

The process may additionally have been creatively selective, but the
important property of it was the creation of a derivative work by
combining existing parts with new parts so that something 'new'
results from this (see paragraph above), with the new parts having
been created in a way that renders them useless, except when combined
with the specific existing parts which were used. A practical example
of this would be a codec-plugin developed for a particular
audio-player.

The problem is that linkers are not creatively selective.

Things are never creative, otherwise, they would be people (side
remark: Does this hold when reversed? :->>).

If I know 'cleverly' distribute only the part I created and add some
instructions like 'download this file from there and this other file
from here and combine them in such-and-such a way', this would still
be a derivative work, because my creation has been designed as such.

No, sorry. It would not.

So, obviously, since all software can be split into parts, no software
can ever be a derivative work of any other software?

[...]

Until you combine your own creative expression with the creative
expression of the original work, it's still just the original work.

Well. The example assumed that I did combine it.
.

Relevant Pages

  • Re: module license taints kernel.
    ... would have made a derivative work of the other two parts. ... because my creation has been designed as such. ... Copyrights do not vest based on hard work, functionality, or anything ... Until you combine your own creative expression with the creative ...
    (comp.os.linux.development.system)
  • Re: module license taints kernel.
    ... If have never claimed that linkers create derivative works. ... nor my drop-in malloc replacement dependent on the other. ... derivative work and would not be allowed to distribute it except if I ... because my creation has been designed as such. ...
    (comp.os.linux.development.system)