Free documentation licenses

[kmself at ix.netcom.com]

on Tue, Nov 28, 2000 at 05:26:20PM -0500, John Cowan (jcowan at reutershealth.com) wrote:
> kmself at ix.netcom.com wrote:

> > Software and its accompanying documentation are generally considered two
> > seperate works.  There is no licensing compatibility requirement between
> > the docs and the code.  Even where short samples of code could be used
> > in the document, they could be incorporated under fair use 107
> > exemptions or (possibly) by turning the document as a whole into a
> > collective work.
> 
> I agree; my argument speaks to expediency, not necessity.

Indicating general agreement.

> >  I don't believe there's anything in the GNU GPL, e.g.,
> > which prohibits publishing of the source code within a book, so long as
> > the source itself is clearly identified as GPLd.
> 
> I can't see this.  A book which incorporates all of another textual work
> strikes me as a paradigm case of a derivative work.  IANAL, but such a book
> looks clearly derivative of the source code and as such would have to be
> published under the GPL.

The way I read 3(c), the GNU GPL refers to the program, but doesn't preclude
its inclusion into a larger, ***nonprogram*** work:

    The source code for a work means the preferred form of the work for
    making modifications to it.  For an executable work, complete source
    code means all the source code for all modules it contains, plus any
    associated interface definition files, plus the scripts used to
    control compilation and installation of the executable.  However, as
    a special exception, the source code distributed need not include
    anything that is normally distributed (in either source or binary
    form) with the major components (compiler, kernel, and so on) of the
    operating system on which the executable runs, unless that component
    itself accompanies the executable.

My including, say, a T.S. Eliot poem in a manuscript of my own
authorship doesn't give me rights to dictate terms for republication of
the poem, but neither do its rights infect the manuscript.  

Which doesn't translate strictly to the GPL, but I'd say that the
informal definition of source code above in the GPL might allow one to
make the argument that a GPLd work within a larger work represents a
"mere aggregation" in storage medium of two seperate works -- the text
and the GPLd source.

> > Your example is backwards:  newBSD/MIT software can be relicensed
> > under GPL.  GPLd software cannot be relicensed, by third parties,
> > under any other license (barring GPL versioning allowances), without
> > specific authorization from the copyright holder(s).
> 
> The term "relicense" should be avoided, as it leads to wifty thinking.
> No one but the copyright holder can "relicense" anything, in the
> sense of changing the license.
> 
> You can create a *derivative* work containing BSD parts and GPL parts,
> and license the whole work under the GPL.  You cannot license the
> whole work under the BSD license.  You also cannot change the licenses
> of the parts.  In particular, I can extract a BSD-licensed component
> from a GPL-licensed work and use it in derivative works under the BSD
> license.

"Additionally licensed" might be a better phrase, though I tend to like
your phrasing better than my original.  As I understand it would be
possible to simply publish without modification a newBSD/MIT work under
the terms of the GPL.  The work is effectively dual-licensed.
Downstream modifications from this tree would be governed, as a whole,
by the GPL.  The original code would still be available under the terms
of newBSD/MIT, as appropriate.

From a strategic perspective, I'm coming to feel that it's the
*possibility* of such a license-driven code fork of newBSD/MIT code
which may be serving to help secure the availability of projects under
these licenses in free versions.  A credible proprietized fork would
likely be countered by a GPL or otherwise copylefted fork.  This is
portrayed in its effect of tendency for code to avoid forking in Bob
Young's licensing diagram, found in the back of _Under the Radar_.  A
similar diagram is used by Don Rosenberg in his _Unauthorized White
Papers_, though his placement of the BSD/MIT license is significantly
different from Young's.

-- 
Karsten M. Self <kmself at ix.netcom.com>     http://www.netcom.com/~kmself
 Evangelist, Zelerate, Inc.                      http://www.zelerate.org
  What part of "Gestalt" don't you understand?      There is no K5 cabal
   http://gestalt-system.sourceforge.net/        http://www.kuro5hin.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20001128/e7ce8f39/attachment.sig>