Tarball licenses (was: Free documentation licenses)

Fri Dec 1 08:43:56 UTC 2000

John, I appreciate the trouble you've been taking on this, especially
the relevant quotations from 17 USC 103.  I've been meaning to
straighten out my understanding of this matter, and really should have
read the relevant statutes.  Far too much of what's said on this matter
ignores the statutes and legislative history, not to mention caselaw.

(Consider the necessary disclaimer added, about other legal jurisdictions
differing.)

begin John Cowan quotation:

>> Case 3.   Programmer Alice wrote source modules A and B.  Her copyright
>> notice grants BSD usage and distribution rights.  You improve module A,
>> and throw the improved version with module B into tarball X, asserting
>> in an included file copyright over your "derived work" X and that it is
>> GPL-covered.
> 
> Let us suppose that my changes rise to the level of a derivative work
> (reformatting doesn't cut it, e.g.).  So now I have module A1.
> [...]

> If I acquire a license to work A (a public license or otherwise, no
> matter), and create from it a derivative work A1, that work A1 is
> *copyrightable*, and I may enforce license breaches with respect to
> the parts of A1 that are not copied from A.
> [...]

> Alice licensed me (as a member of the public) to create and distribute
> derivative works.  As long as I conform to the BSD stipulations, I am
> fine.

And this is where I need to slow down and straighten things out.  Few
of us have time to pursue the matter properly, and it's easy to get
tripped up by all the varied and conflicting claims, here.  For example,
other parties on this list have asserted -- plausibly and without
contradiction -- that only the copyright holder may relicense a work.

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

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.

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.

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

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}

>> Bram went on to help Pat Beirne create the MakeDoc utility, whose source
>> code I eventually tracked down.  It likewise has no explicit licence.
>> Beirne's last version was a Java one, MakeDocJ, which I can no longer
>> find.  However, Jeffrey A. Krzysztow found Beirne's Java code, improved
>> it, and purports to place the result under the GNU LGPL:
>> http://linuxmafia.com/pub/palmpilot/MakeDocJ-3.6.0.zip .
>> 
>> I would estimate that Krzysztow's LGPL assertion is simply ineffective,
>> as it would violate Beirne's rights....
> 
> Specifically the right to control the making of derivative works.

My point, in part, is that there's probably a great of such derived
works from dubious sources, whose new licence status gets asserted and
semi-established through sheer bluff by a later modifier.  When the 
original codebase is less trivial than MakeDocJ, this practice can be a
hidden pitfall for programmers, users, and others who rely on the
derived work's (alleged) licence status.

And, in the real world, those programmers, users, and others must work
with less than perfect information.  E.g., it will be somewhere between
impractical and reckless to rely on license terms that are _not_
provided with the work, but only available elsewhere.  We'll return to
that point, immediately below.

>> I would estimate that Krzysztow's LGPL assertion is simply
>> ineffective, as it would violate Beirne's rights, which would mean
>> that, technically, the Beirne-derived source modules in
>> MakeDocJ-3.6.0.zip remain under Beirne's non-licence, are technically
>> not legally redistributable, and do not belong in either of my
>> directories.

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

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.

The Debian Project is one such collection, and I've learned a great deal
about real-world licence concerns by studying their policies.  Krzysztow's
MakeDocJ might be initially accepted into the Debian "main" collection,
but probably would be yanked once its status as a derived work based on 
Beirne's no-licence MakeDocJ was discovered.  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.

Some would be content with copyright-holder permissions that are
available elsewhere, even though not in the packages in question.  For 
example, a large part of the licence terms for Daniel J. Bernstein's
Qmail package are on his Web site at http://cr.yp.to/qmail/dist.html, 
rather than in the Qmail tarball.  Legally sufficient?  No doubt.  But
subject to disappearance and unavailability -- not to mention the
copyright holder changing his mind.

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

>> I would estimate that Krzysztow's LGPL assertion is simply
>> ineffective, as it would violate Beirne's rights, which would mean
>> that, technically, the Beirne-derived source modules in
>> MakeDocJ-3.6.0.zip remain under Beirne's non-licence....
> 
> 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.
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.  It also includes distributing patches -- but not
distributing patched versions, or distributing the original.

So, all rights are not reserved.  Some are automatically available to
anyone who acquired the code legally.[1]

Anyhow, I'll conditionally accept your explanation of derived works with
a new licence terms, and (impliedly) why this need not constitute
relicencing -- for which I thank you.

[1] Thus, I may not have legally acquired the Krzysztow MakeDocJ tarball
carried on my site, since he may have illegally redistributed Beirne's
code -- technically speaking.  Thus my caution and inclination to
insist, a la Debian Project, that licence terms be provided with the
affected code.

-- 
Cheers,                                      "Reality is not optional."
Rick Moen                                             -- Thomas Sowell
rick at linuxmafia.com