Message-ID: <47ACA204.7030702@davidnewall.com>
Date:	Sat, 09 Feb 2008 05:10:04 +1030
From:	David Newall <davidn@...idnewall.com>
To:	Marcel Holtmann <marcel@...tmann.org>
CC:	Greg KH <greg@...ah.com>, Christer Weinigel <christer@...nigel.se>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] USB: mark USB drivers as being GPL only

Marcel Holtmann wrote:
> Anyway you are still under the impression that a Linux kernel module can
> be original work in the end. We keep telling you that could be a wrong
> assumption which is based on the view of many of the kernel developers
> and of most of the lawyers that looked at this specific topic.
>   
Yes, I am of that view. I accept that I could be wrong, but that also
means that I could be right. We agree, so far. The important point is
that I could be right. What will be done when somebody brings forth such
an work? Will the restriction in EXPORT_SYMBOL_GPL be removed, or will
the driver be unfairly restricted from using those other modules? You
did agree I could be right, so positing such a driver, what happens? (I
predict nothing; the driver is unfairly restricted.)


Now, Alexander Terekhov has forwarded some links to me, relating to the
question of whether or not a Linux kernel module can be original. Bear
in mind that these links relate to U.S. Copyright Law.

In http://digital-law-online.info/lpdi1.0/treatise27.html, Professor Lee
A Hollaar discusses derivative work and linking with libraries. He says:

    Some have claimed that an application program that needs a library
    for its operation is a derivative work of that library. They take
    that position because the application program is "based on" the
    library because it was written to use the subroutines and other
    aspects of the library.

    Such a position is misplaced. Even though the definition of a
    derivative work contained in Section 101 seems to support such a
    reading when it talks about a derivative work’s being "based upon
    one or more preexisting works," the examples all illustrate
    derivative works where the original work is somehow incorporated or
    recast in the derivative work:

    A "derivative work" is a work based upon one or more preexisting
    works, such as a translation, musical arrangement, dramatization,
    fictionalization, motion picture version, sound recording, art
    reproduction, abridgment, condensation, or any other form in which a
    work may be recast, transformed, or adapted. A work consisting of
    editorial revisions, annotations, elaborations, or other
    modifications which, as a whole, represent an original work of
    authorship, is a "derivative work". {FN109: 17 U.S.C. §101
    <http://www4.law.cornell.edu/uscode/17/101.html>}

    This need to use a portion of the original work in the derivative
    work is stated in the legislative history of the Copyright Act of
    1976, where the drafters discussed when the derivative work
    exclusive right is infringed:

    To be an infringement the "derivative work" must be "based upon the
    copyrighted work," and the definition in section 101 refers to "a
    translation, musical arrangement, dramatization, fictionalization,
    motion picture version, sound recording, art reproduction,
    abridgment, condensation, or any other form in which a work may be
    recast, transformed, or adapted." Thus, to constitute a violation of
    section 106(2), the infringing work must incorporate a portion of
    the copyrighted work in some form;


Let me say it: A work that incorporates no portion of a copyrighted work
is not derivative. He goes on to say:

    It could be argued that the component program really does include
    portions of the library that it uses – data structures that are
    passed as parameters, or even the parameter lists themselves. But
    elements dictated by external considerations are filtered out when
    trying to determine whether there is copyright infringement.


Elsewhere he says, by implication, that "elements like the overall
program structure or architecture and data structures that are ...
dictated by external or efficiency considerations" are not "protected by
the original program’s copyright".

He finishes this part of his treatise by saying:

    No other conclusion makes sense. If it were not the case, then any
    program using the applications program interfaces (APIs) of an
    operating system could be considered a derivative work of that
    operating system.


Another germane reference provided by Alexander

A lengthy article by Prof. Dr. Lothar Determann can be found at
http://www.usfca.edu/law/determann/softwarecombinations060403.pdf
(DANGEROUS LIAISONS – SOFTWARE COMBINATIONS AS DERIVATIVE WORKS?). In
the abstract, Prof. Dr. Determann writes:

    The article concludes that most forms of software combinations are
    less dangerous than commonly assumed, because they do not constitute
    derivative works (but instead either compilations or sui generis
    aggregations outside the scope of the copyright owner’s exclusive
    rights), and a number of statutes and legal doctrines significantly
    limit a copyright owner’s ability to contractually prohibit software
    combinations that do not also constitute derivative works under
    copyright law.


In the Introduction he says:

    [C]ourts and commentators have not yet developed general rules for
    the qualification of software combinations as derivative works, and
    the place and role of derivative works within the statutory context
    of compilations, collective works and other types of aggregations
    does not seem to have been examined in depth yet with respect to
    software combinations.


>From this we must conclude that any claim that kernel modules can only
be derivative is wrong. The courts haven't given us direction yet, so
nobody knows for sure. He goes on to explain a bit about what it is to
be a new and non-derivative work:

    If the creator of a new work takes very little of an existing work
    or takes only non-protectable content (e.g., ideas, facts) or
    changes so much that the new work does not bear a close resemblance
    to the existing work, the new creation is simply a new work of
    authorship––and not a derivative of the existing work. After all,
    most new works are influenced to some extent by existing works.


He repeats this:

    [A] new (non-derivative) work[:] (if only very little of or
    non-protectable elements of the existing materials are present in
    the new work or if the new work does not bear a substantial
    resemblance to the existing work)


He goes on to discuss the Copyright Act, and quotes from it:

    In no case does copyright protection for an original work of
    authorship extend to any idea, procedure, process, system, method of
    operation, concept, principle, or discovery, regardless of the form
    in which it is described, explained, illustrated, or embodied in
    such work.


This defeats a claim that all kernel modules are derivative by virtue of
XXX.

Prof. Dr. Determann directly address the GPL. Others have suggested, in
the course of this discussion, that a Linux kernel module is intended to
be used with Linux and that that brings them into the scope of the GPL.
Prof. Dr. Determann says this:

    It is worth noting, however, that the GPL generally permits end
    users to execute GPLed code in any combination they want. According
    to Section 0 of the GPL, "[t]he act of running the Program is not
    restricted." As a result, software companies do not have to be
    concerned about invoking the "viral" effect of the GPL based on a
    contributory liability theory if they distribute their add-on
    programs separately, i.e., not in context with any GPLed code, even
    if the add-on programs are intended for combination with a
    particular version of GPLed code. End users who run add-on programs
    with the GPLed code would not infringe, because the GPL allows
    execution without any restrictions.


He also addresses the question of dynamic linking:

    Consequently, dynamic linking to GPLed programs would not normally
    trigger the application of the GPL to the linking program, even if
    both programs are distributed together.


He concludes:

    Software combinations are less dangerous liaisons as some have
    recently argued, particularly in the context of the GPL.

    Under the U.S. Copyright Act, a combination of a computer program
    with other software results in the preparation of a derivative work
    only if the combination (a) is sufficiently permanent, (b) contains
    significant and creative portions of the other software, (c) is
    creative in its own right, and (d) involves significant and creative
    internal changes to the other software. Most software combinations
    fail to meet one or more of these requirements and constitute either
    compilations, collective works, or non-copyrightable aggregations,
    and neither affect copyright owners’ adaptation rights under Section
    106 of the U.S. Copyright Act.


Now, Alan has made a big issue over numerous legal opinions he has
received, but he's been completely coy in the details. He has been
spreading hearsay. I have presented quite definite opinions from learned
and respected practitioners. He has presented nothing. It does rather
seem that he is quite wrong, and his recent huffiness, including the
emotive "liar" confrontation, nicely shows the balance between the two
arguments.

The reasonable conclusion is that an original, non-derivative USB driver
can be written, and let's face it, a number of them have been referred
to in the course of this discussion.

USB drivers must NOT be restricted to GPL-licence only; that would
damage Linux.

My thanks go to Alexander Terekhov for providing some very informative
links.

> And while you are talking to a lawyer. Ask him/her if it is okay to
> create a binary only application that uses a GPL library. Tell him/her
> that it is original work.

Where does this come from? It's right out of left field. Since I've
never suggested such a thing, could you please do me the courtesy of
retracting the suggestion that I have?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists