[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

On 4/13/05, Raul Miller <moth@debian.org> wrote:
> On Wed, Apr 13, 2005 at 11:26:47PM +0200, Francesco Poli wrote:
> >  US copyright      italian author's right ("diritto d'autore italiano")
> >  ----------------------------------------------------------------------
> >  compilation work  <--->           collective work ("opera collettiva")
> >  derivative work   <---> creative elaboration ("elaborazione creativa")
> >
> > In the USA, a compilation work is a collective work has its own
> > copyright and thus is also a derivative work.
> >
> > I hope to get it right... or am I confused?
> Sounds right.

Nope.  Compilations (US) / collections (Berne) and derivative works
are disjoint sets under the Berne Convention (Article 2.5 and 2.3
respectively) and its national implementations (separate definitions
in 17 USC 101).  (One could of course have a compilation containing a
derivative work, or a derivative work of a compilation.)  Both are
entitled to independent copyright protection that extends only to the
creative expression not present in the original work(s).  Trivially
obvious collections (hey, let's copyright the bundle of glibc and the
Linux kernel!) are not copyrightable.

Incidentally, the GPL doesn't use "compilation" or "collection" in the
legal sense at all.  GPL Section 2 says "derivative or collective
works", which is the only usage of "collect".  Under 17 USC 101,
collective works are a subset of compilations, specifically those
containing multiple, identifiable, separate works of authorship (as
distinct from compilations of individually uncopyrightable data, which
may still be copyrightable as a whole due to the exercise of
creativity in their selection and arrangement).  Other passages in the
GPL refer to "derived" or "derivative" works.

The "derivative works" category was created so that an author can
authorize publication while reserving rights to the rest of a work's
commercial potential (e. g., a film that uses text from a book, or
even a sequel that uses characters and mise en scene).  The
"collective works" category prevents the editor of a non-trivial
collection (a periodical, a themed anthology) from being ripped off by
another publisher who has similar access to publication rights to the
individual pieces.  Other "compilations" of otherwise uncopyrightable
data are granted copyright protection for similar reasons -- but only
insofar as they are creative works, not mere "sweat of the brow"
(although this dividing line varies by national implementation and by
jurisdiction much more than most other aspects of copyright law).

When the work under discussion is a software package, there's also a
set of engineering relationships to separately authored works that fit
none of these patterns.  Copyright is in my opinion just not the right
tool by which to attempt to control their creation and distribution. 
US courts seem to agree much of the time, disallowing the abuse of the
copyright monopoly to block competition in markets where
interoperation matters.  There's an emerging legal consensus that
copyright on a software work shouldn't grant the power to disallow
competitive use of it any more than copyrighting a drill bit as an
artwork should grant the power to disallow its use in other brands of

On a myopically textual basis, I have previously argued that the text
of GPL Section 2 should be construed to apply only to derivative
works, ignoring the "mere aggregation" clause (and certainly ignoring
the FSF's FAQ).  But as I've also said before, this doesn't really
matter.  The real distinction is that the Berne categories serve
different historical and statutory purposes, grounded in the actual
problems that authors, editors, and publishers face in getting a fair
price for their work.  The GPL software author's position resembles
that of the author of a literary work, not that of a publisher of a
compilation, and the scope of remedies permitted is likely to be
assessed accordingly.

I think it's quite clear (IANAL; cases cited earlier ad nauseam) that
interoperating across a published interface is a protected use
irrespective of licensing terms, and I see no reason why this
shouldn't apply equally to free software.  Hence the price asked by
the GPL -- return of the recipient's incremental work to the software
commons -- is likely to be levied on true derivative works but not on
other works that use them through their documented interfaces,
irrespective of engineering detail.

- Michael

Reply to: