Re: module license taints kernel.

On Nov 20, 11:11 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:

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.

There are very few legal consequences of the operational
characteristics of a work in copyright. Copyright applies pretty much
the same to functional works (like computer programs) as it does to
purely aesthetic works (like abstract art).

The only difference that matters here is that functionality is
explicitly *removed* from copyright protection. Any functional issues
can only reduce the scope of the GPL because it cannot cover pure
functionality, only expression.

You are correct, of course, that a linker can't link anything unless a
human tells it to do so. I could imagine cases where, theoretically,
someone might creatively command a linker to do something. However, in
the vast majority of cases, and all the ones that matter here, the
linking step is purely functional with its characteristics completely
dominated by functional considerations.

It is more like putting bolt on a nut than writing a book. The
functional parts are combined so that they function.

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?

I think you misunderstand what a derivative work is. A derivative work
is a creative extension of a work such that the "new" work contains
expressive elements taken from the original work beyond that required
by mere functional considerations.


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).

What possible relevance do you think this has to copyright law?
Copyright law would cover in precisely the same way software that had
no function whatsoever. In fact, when you consider copyright issues,
you must *erase* all functional aspects from the equation because
functionality is explicitly *exempt* from copyright.

In other words, if you are considering whether work X is a derivative
work of work Y, the first thing you must do is *eliminate* any aspects
of X that are constrained by functionality requirements. You then look
at the *expressive* elements of Y and say, "Which of them are in X?
How have they been changed?"

You seem to think the functional elements get more weight when in
truth they get less.

If would be much worse to take a comment's choice of wording than to
take a brilliant optimization. For example, in one case where one
company was accused of stealing elements of another map, the main
focus wound up on the way street names were placed in areas where they
all wouldn't fit in the most obvious places and lines or arrows were
needed. Why? Because *no* functional considerations controlled this
placement, it was purely a creative exercise.

The parts about the real working parts being taken were dismissed.
Why? Because they were dominated by functional requirements and thus
*not* protectable by copyright.

Note that with patents, it is the opposite.

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.

But linking never combines anything with new parts. It only combines
existing parts.

Presumably, a codec-plugin developed for a particular audio-player
would only take the functional bits of the audio-player that it needs
to plug in. This is not protectable by copyright because it's purely
functional.

Now, suppose the API exchanged compressed audio and the codec took
into its own code the compressor from the audio player. Then there
would be a question of whether the compressor code was dominated by
functional considerations or whether the same functionality could have
been obtained other ways, say by rewriting that code.

But it's quite obvious that it's practically impossible to replicate
the linux kernel interface with independent code. The interface is way
more functional than practical.

Copyright only covers one choice out of millions of equally practical
choices. It does not apply when one way to get the job is way more
practical than others. Again, see Lexmark v. Static Controls. Taking
Lexmark's TLP code was the only practical way for Static Controls to
make a toner cartridge that worked with Lexmark's printers, thus
Static Controls could take it without impacting copyright.

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? :->>).

Exactly. Things can never produce derivative works, only creative
combination by a human can. The module code either is or is not a
derivative work of the kernel, regardless of whether or not anyone
links it or can link it.

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?

Software can be a derivative work of other software if it contains
protectable expressive elements of that other work that have been
creatively extended beyond any practical need imposed by functional
considerations.

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.

The creative expression was not combined with the original work. The
quintissential example would be turning a book into a move. There, the
creative decisions of the book (character names, relationships,
precise events) are creatively transformed so that the same creative
elements are re-expressed.

DS
.

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)
  • Disable Shortcuts
    ... Is there anyway to disable the creation or functionality ... of new shortcuts on the desktop? ... create them from the right click context menu? ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Copyleft and embedded Forth
    ... but my DLL honors a ... functionality to either. ... derivative work of product G, so restrictions imposed by the GPL ... its not near the fuzzy borderline. ...
    (comp.lang.forth)