Re: Another job for the Gnome Foundation ?

[kelly poverty bloomington in us]

On 21 Aug 2000 22:24:39 -0400, Havoc Pennington <hp@redhat.com> said:

>Interesting mail, this is the first very good explanation of why
>copyright assignment is needed I've ever read. RMS's communication
>skills do not encourage people to do the FSF assignment.

To be honest, I have never paid much attention to RMS himself on this
issue.  

>If you can separate a part of the code clearly copyrighted by only
>one party, could you sue for violations of the copyright on that
>portion?  This would apply to many projects or at least chunks of
>them.

To the extent that an individual owner's contribution can be
separated, in accordance with the standards of the copyright law for
such separation, that individual owner-author could sue to vindicate
only her own copyright interest in that portion of the collective
work.  

If I write a short story and grant a license to a publisher to
include it in an anthology, I can subsequently sue someone who
republishes it.  The publisher can also sue if the publisher can show
that the republication was derived from the anthology publication, but
I do not have to make such a showing.

If I write a program and distribute it under the GPL, some person
subsequently includes my program in their own product without
modifying it (or modifying it in such a manner that the modifications
are 'minimally transformative'), and a third person then infringes on
the copyright, it is my belief that I can sue the third person.  If,
however, the intermediate person's modifications are 'substantially
transformative', then (if I recall the copyright law correctly), the
ownership of what that person distributes rests with her and not with
me, so long as the derivation is conducted consistent with the terms
of the license I have granted allowing her to derive new works from my
work.  In this case, I may not be able to sue the third party without
also suing the second party, alleging that she infringed my copyright
by licensing her derived work in a manner inconsistent with the
license I granted her to create derived works from my work.  If I
allege that the second party infringed my copyrights, and prevail on
that allegation, then I become an owner in the derived work and can on
that basis sue the third party for infringing on my interest (newly
"discovered") in the derived work.

So, basically, when you let someone modify your work, the ownership of
the resulting modified work (absent an agreement to the contrary)
rests not with you, but with whoever did the modification, as long as
that modification was done with your permission (and assuming the
modification is not 'minimally transformative').  However, this rule
is subject to two modifications. 

First, when two or more authors work cooperatively, repeatedly
modifying each other's work in a manner where it becomes difficult to
tell which author is responsible for what portion of the whole work,
the law will deem all those authors as common owners of the entire
undivided work with the rights and responsibilities that the law
assigns to the owners of property held in common.  This is "joint
ownership".  A paradigmatic example of a joint work is probably an
academic treatise authored by two or more researchers; generally, such
works are written in a way that the individual contributions of the
joint authors cannot be meaningfully divided.

Second, when a single person (or, occasionally, multiple persons
acting in a manner such that their individual actions cannot be
clearly distingushed from each other) collects together (with
permission) a number of independent works into a single whole without
substantially transforming any of them, that person (commonly called
an "editor") acquires a collective copyright on the resulting whole
work.  This collective copyright does not impair the copyright
interests of the owners of the component works, except as far as such
owners must necessarily grant licenses to the collective author to be
allowed to prepare the work at all.  The owner of any work component
to the collection has no rights with respect to the collection itself
but may sue an infringer on the collective copyright if the infringer
simultaneously infringes on her copyright in one of the included
works.  (Mandatory joinder rules to avoid multiple liability apply in
such cases.)  Paradigmatic examples of such works would include short
story anthologies, collections of poetry, and academic journals.

A final twist: any work produced (including a derivation) by an
employee in the course of her employment is considered by law to have
been authored by the employer (absent an agreement to the contrary).
This vitiates the complexity of the computer code problem in most
cases outside of free software: most of the people writing code for a
proprietary application are either employees of the same company, or
independent contractors bound by agreement to convey their copyright
interests, so in either case the producing company ends up with all of
the copyright interests.  The absence of an unitary employer in free
software development denies us this "out".  (BTW, one has to wonder:
who owns the copyrights to the code being produced by Helix, Eazel,
and Red Hat employees?  Check your employment agreements closely.)

So, suppose I write some application, all by myself, without relying
on anyone else's code or any input from outsiders.  I release version
1.0 under the GPL.  I am the sole owner.  This is easy.

For version 1.1, I include two new modules offered to me by X.  I
include these in the program without making any substantial
modification to them.  Result: X owns the new modules, I continue to
own the old modules, and I own the collective copyright on the release 
itself.

In version 1.2, I accept substantial patches to the core from Y, but
make significant changes to the code after including them.  The
patches are so pervasive that it cannot be readily identified what
parts of the code were written by Y and what parts were written by
me.  None of this affects the stuff X gave me back in 1.1. Result: X
continues to be the owner of what she gave me, I and Y jointly own the 
rest of the code, and I hold the collective copyright on the release.

At this point I get bored with the project and give it to Z to
maintain.  Z makes a few insignificant changes and releases 1.3
Result: X continues to own her modules, Y and myself continue to own
the rest of the code, but now Z holds the collective copyright.

Between 1.3 and 2.0 a team of four people (not including Z) working
closely together descend on the project and rewrite virtually then
entire project, significantly transforming the entirety of the code.
Z supervises this but contributes nothing of substance to the project,
but assembles the release.  Result: all of the modules in 2.0 are
owned jointly by these four people, and the collective copyright on
the release is owned by Z.  NOTE CAREFULLY: I AM NO LONGER AN OWNER.
My ownership interest at this point is merely contingent: it will only
arise if the new owners violate the terms of the license I have
granted them to make derivations.

So, if my analysis is not altogether off, the ownership of any
component of a project being developed under the 'bazaar' model lies
solely with the last person to make substantial changes to that
component.  This is modified (as discussed above) to joint ownership
when repeated modifications are made by members of a group of people
in a manner which tends to blur their independent contributions.  The
ownership of the project as a whole lies with whoever does the
assemblage and final distribution.  This means that the ownership of a 
project may be constantly jumping from one person to the next, and
ownership of components not recently modified may belong to people who 
are no longer active in development.  Furthermore, each and every
component has as a contingent owner every person who has ever made a
substantial contribution even if that contribution has since been
excised from the project.  

Another problem with software is identifying "independent works"
within the body of a software system.  While some people have claimed
that each source file can be viewed as an independent work, I'm not
convinced this is accurate.  There is often a great deal of
interdependence between source files in a typical project.  I tend to
suspect that courts would use a higher level of abstraction, probably
something akin to "modules" or "components", to the extent that such
can be identified.  If a program's code is so grossly intertwined such
that no individual components can be identified, then there would be
only one work.  

Of course, this analysis could be completely wrong.  I am NOT an IP
lawyer (merely a law student with a significant interest in this
area).  I'm going on what I've learned so far and my reading of the
cases I've seen, the comments (by lawyers) I've read, and the
statutes.  There are questions here to which I do not have answers, in
part because I lack experience and understanding in this area, and in
part because the answers simply do not yet exist because no court of
competent jurisdiction has ever ruled on them.  I don't know what a
court would consider a "substantial contribution" such that would
grant the contributor ownership.  (A one-line typo correction probably
is not enough.  Contributing ten thousand lines of completely original
code probably is.  Somewhere between these two is a line in the sand,
and I have no idea where it falls.)  When contribution is by
submission of patches, a court might elect to leave ownership with the
person who decides whether or not to include the patch no matter how
substantial it is.  A court might consider contingent owners to be
owners-in-fact, or it might not.  Identifying the proper owner(s) so
as to bring suit in the name of the real party in interest (a
requirement of the procedural law of the United States) may be
difficult, especially when the infringed version is not the current
version of the software.  (For example, I pretty clearly have an
ownership interest in GIMP 1.0, it is unclear whether I have one in
the current development release, and I clearly do not have any
interest at all in GIMP 0.54.)

As I pointed out, when all the code is owned by a single entity, it is
irrelevant who the author is because it all funnels down to the same
entity.  One way to do this is to employ all the programmers; then the
work-for-hire doctrine makes the employer the author.  Another is to
get ongoing assignment agreements from all of the programmers; then,
again, the assignee is the author.  But this strategy only works if
EVERYONE (or at least nearly everyone) who works on the code is either
an employee or an assignor of the host entity.  Hence the FSF push for 
assignment.

Kelly