OSD compliant shareware

[Karsten M. Self]

on Wed, Nov 14, 2001 at 03:10:43PM -0500, Russell Nelson (nelson at crynwr.com) wrote:
> Forrest J. Cavalier III writes:
>  >   2. You may compile this into an executable form, or modify your
>  >      copy or copies of the Program or any portion of it, thus forming
>  >      a work based on the Program, and copy and distribute such
>  >      modifications or work under the terms of Section 1 above.
> 
> Running a program is creating a copy.

I'm inclined to agree with what I think is Russ's drift:  the existing
OSD (suitably interpreted) closes the 117 / MAI v. Peak loophole, and
doesn't allow for "use fee" shareware licenses as proposed.

The question is, which specific OSD clauses do so:

 #1 requires free redistribution.  Is a copy in RAM, for the purposes
    of running the program, a redistribution?  This appears to be a
    stretched analogy, but could be argued.

 #3 requires modifications and derived works to be possible.  Does an
    identical copy of a work in RAM count as a derived work?  The
    definition in 17 USC 101 is:

	A ''derivative work'' is a work based upon one or more
	preexisting works, such as a translation, musical arrangement,
	dramatization, fictionalization, motion picture version, sound
	recording, art reproduction, abridgment, condensation, or any
	other form in which a work may be recast, transformed, or
	adapted. A work consisting of editorial revisions, annotations,
	elaborations, or other modifications which, as a whole,
	represent an original work of authorship, is a ''derivative
	work''.

    How comfortable are we with the idea that a transfer from disk to
    RAM produces a "transformed" work?  This would be required under OSD
    clause 3.

    OSD #4, which allows source-only distribution restrictions of
    _modified source_ if patch files are allowed, does not seem to
    affect this interpretation.

    I feel that the proposed license is not compliant with OSD #3.



I'm something of a conservative when it comes to rules.  If there is a
suitably plausible interpretation of the OSD which is consistent with
the spirit of the document, I'd prefer this to a rewrite of the OSD.  If
a rewrite is necessary, I'd prefer to start from first principles and
identify what we hope to accomplish, and write language to accomplish
this.  My feeling is that the current OSD is consistent with the view
that the view that the proposed fee-for-use shareware license is not
intended to be compliant, and is not in fact compliant, with the OSD.

Peace.

-- 
Karsten M. Self <kmself at ix.netcom.com>       http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?             Home of the brave
  http://gestalt-system.sourceforge.net/                   Land of the free
   Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire                     http://kmself.home.netcom.com/resume.html
-------------- 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/20011114/e137d09e/attachment.sig>