Tarball licenses (was: Free documentation licenses)

[John Cowan]

On Fri, 1 Dec 2000, Rick Moen wrote:

> [O]ther parties on this list have asserted -- plausibly and without
> contradiction -- that only the copyright holder may relicense a work.

True, in the sense that I can't just hike off Alice's copyright and
supply my own.  False, in the sense that I can create a derivative
work, copyright it in my own name, and issue it under a license of my choice --
provided Alice's license doesn't forbid it.

The central point is that the maker of a derivative work, provided he
acts under license from the copyright owner of the original work, is
a *copyright owner* of his work, and can do the things a copyright
owner may do (specifically, conditional or unconditional restriction
of the actions of others WRT copying, distributing, etc.).

> At first glance, that allegation would seem to contradict your statement
> regarding hypothesised work A1, which you assert to be GPL-licensed, and
> which you derived from Alice's BSD-licensed work A.  (And, frankly, I'm
> not sure that you have _not_ substantively relicensed Alice's work, or
> that you would have the right to do so.  But let's continue.)

This is why I said the term "relicense" should be avoided, as it creates
more confusion than it dispels.

> However, if I understand you correctly, you are asserting that you are
> _not_ relicensing Alice's work, but rather creating a derivative work
> fully in compliance with Alice's terms for the portion she created -- in
> the sense that re-using BSD code in creating a GPLed derivative
> continues to satisfy the BSD author's conditions.

Just so.

> Anyhow, as I was saying earlier, part of the trick of dealing with these 
> matters is to use a fruitful mental model.  Let's try to picture one,
> here:  Alice creates A (thereby gaining copyright).  She releases it,
> after soaking it in BSD sauce.  You like it, but mix it with a bunch of 
> your own ingredients, mixing in GPL extract, calling the result your and
> Alice's GPL-flavoured pudding A1 (a derivative work).  Which Alice's
> choice of sauce indicated would be OK by her.

Good enough, but see the bit about translation below.

> This reading appears to be shared by, among other people Australian
> programmer Eric A. Young, one of the creators of OpenSSL (formerly
> SSLeay, after Young's initial):  All other coders' modules in OpenSSL
> are straight BSD-licensed, but Young's is BSD w/advertising clause plus
> the following addition:
> 
>  * The licence and distribution terms for any publically available
>  * version or derivative of this code cannot be changed.  i.e. this code
>  * cannot simply be copied and put under another distribution licence
>  * [including the GNU Public Licence.]

Right.  Here Young grants you the right to make a derivative work (and
to copyright it under your own name), but *not* to issue it with a
license of your own choosing.  You must use Young's license on it,
or refrain from distributing it at all (due to the phrase "publicly
available").

This is "viral", like the analogous requirement of the GPL that derivative
works must be distributed under the GPL (or close to it).

> It would certainly be a clean and tidy way to deal with things, to
> regard code modules as the atomic unit for licensing issues, such that,
> if you work on Alice's A that bears a specific licence, what would
> result is a larger or revised A under the same licence, possibly bearing 
> your name on the copyright statement alongside Alice's.  For, of course,
> the second party's creative content is essentially impossible to
> distinguish (disentangle) from Alice's, and who owns what becomes very 
> murky on the intra-module level.  But the law is the law, and 
> you (citing 17 USC 103) say it happens to be untidy, here.  {sigh}

Inevitably so.  Whether work B is a derivative of work A has to be
judged by the facts of history, not by some objective metric of similarity.
If Alice's module is written in Perl, and Bob's module is written in
Java, there may be not a line that is identical between the two --
yet if Bob wrote his module as a translation of Alice's, then it is a
derivative work.

Alternatively, two people may take a photograph of the Washington Monument
from the same place and under the same lighting
conditions, and it may happen that the photos are pixel-for-pixel
identical, and yet the two works are absolutely distinct from a copyright
standpoint.  (In fact, the one case that turned on this ruled the other
way -- but there was an additional element: the second photographer
*intended* to duplicate the first photographer's work, which he had
seen.)

> > Now that's a horse of a different color.  Licenses, other than
> > outright transfers of copyright, need not be in writing or have other
> > formalities.  If there is a plausible claim that Krzysztow had an
> > (unwritten) license from Beirne to create a derivative work, then K.
> > can license the derivative work under the LGPL or otherwise.
> 
> That would then be a truth known to Krzysztow and Beirne, and no one
> else, since Krzysztow did not see fit to document this permission in 
> his tarball.  

Almost.  It might also be inferred from Beirne's actions, or rather
inaction.  If you are aware that infringing derivative works have
been created, and you do nothing, an infringer may be able to claim
that your toleration amounts to a license.

> Such a (hypothesised) truth would protect Krzysztow in court.  But it
> would not even be readily available to, say, those of us who offer
> publicly-distributable software in our public file collections, and who
> wish to ensure that we do so legally.

Ensure, no.  But Beirne's inaction is a fact that isn't just in Krzysztow's
head.

BTW, it would clearly serve the public interest for you, as an archivist,
to seek a letter from Beirne saying that Krzysztow's work was made
under license from him.  You could then tar this up with K's work,
and all would be well.  In this particular case, Beirne doesn't need
to issue a *public* license.

(I am assuming that there is no question that Beirne *is* the copyright
owner; if the work was made in the scope of his employment, however,
it may belong to his employer, a so-called "work made for hire".)

> I'd guess that they would 
> not restore it based only on Krzysztow reassuring them that Beirne had
> granted licence, but would want to see a revision with a Beirne licence
> statement added -- because insisting on clear licence documentation
> establishes Debian's good-faith effort to only distribute software that
> may be legally handed out.

I'd guess you are right.

> [...] -- not to mention the
> copyright holder changing his mind.

Now you bring up a sticky matter which nobody has ever resolved, because
there is no case law about public licenses.  What happens if the copyright
holder does change his mind, and revokes the license?  People who
relied on it in the past clearly have no problem -- if a derivative work
has been created, there is no issue.  But whether that derivative work
can continue to be copied or modified is a question.

> So, as an archivist of publicly available software, I have no problem
> with telling people that software that omits any licence statement is
> _unlicensed_ -- even though effective grants of permission may exist in
> the bottom of a locked filing cabinet stuck in a disused lavatory with a
> sign on the door saying 'Beware of the Leopard.'

Fair enough.  What is not documented to exist, may be treated as if
it were documented not to exist -- not as a matter of law, but as
a matter of prudence.

> > Namely, all rights reserved.
> 
> I am a bit wary of this phrase.
> 
> Some terms people use in these debates have meanings in law, such as
> "transfer of copyright", "derived work" and "compilation" (but not
> "composite work").  I have no idea whether "all rights reserved" is such
> a term, but, whether so or not, it would appear to be a bit misleading.

It means "all rights held by the copyright owner as such with respect
to this very work are reserved".  However, it is a default claim, and
does not override any explicit license.

> That is, as Bernstein points out in http://cr.yp.to/softwarelaw.html ,
> 17 USC 117 provides that a legal recipient of software automatically
> gains some rights, including backing it up, compiling it, running it,
> and even modifying it as necessary, without permission from the
> copyright holder.

Of course the copyright holder cannot reserve rights that he does not have.
The bundle of rights labeled "copyright" is granted to the owner by the
law, and includes only the rights to prevent others from 1) copying,
2) making derivative works, 3) distributing, 4) publicly performing, etc.
And these rights are subject to the limitations imposed by the law.

>> It also includes distributing patches -- but not
> distributing patched versions, or distributing the original.

Right, because patches are not derivative works -- their use of the
original is fair use only.  They are essentially commentary.

> Besides, "all rights reserved" is no shorter than "no explicit licence",
> and the latter phrase strikes me as much clearer.

Fair enough.

-- 
John Cowan                                   cowan at ccil.org
One art/there is/no less/no more/All things/to do/with sparks/galore
	--Douglas Hofstadter