Peanuts NeXT Software Archives/Peanuts-2.iso/Developer/resources/classes/misckit/MiscKit.mbox/text0001.txt

Text File | 1993-10-26 | 5.6 KB | 126 lines

[e-mail] (Don Yacktman) writes:
> (2)  Licensing issues need to be dealt with.  [...] we need to
> put a real license on the kit, at the very least to make sure
> that no one is held liable for vicious bugs.  I do NOT want the
> GNU license [...]

Both copyright and licensing issues need to be dealt with.  More
on this below.  And I agree, no GNU license.  Unless we decide that
our goals are the goals of the FSF, then we might as well use it.

>     a) If used in an app, credit should be given, somewhere,
>     to the authors of the kit and a pointer to the location
>     of the most recent source code should be given. [...]

I agree with the "credit" part, but not the "pointer" part. It
may be somewhat cumbersome, and a developer that obtains the
software from location X cannot guarentee that the software
will continue to to be available at X.  And must accommodations
for those w/o ftp access be made by a developer?  A "pointer"
"policy" should attempt to include _everyone_, if it is to be
included at all, imho.

>     Those are the main issues, but I'm sure we'll come up
>     with more.  The important thing here is to delineate a
>     policy we're all comfortable with--and I lean towards
>     keeping things as open as possible.

There is one other issue--that of a copyright holder or holders.
There is no point really in a license without a copyright holder,
since then there would be no one for a developer to infringe the
rights of. It's not useful to try and exclude rights from the
developer, when there is no one to hold those excluded rights.
It is not clear what Don had in mind relating to this.

Below is a license (an amalgam of licenses I have seen and written
in the past, really) that we would use as the basis for a license,
and that includes Don's points.  It illustrates some potential
problems, too.  I include this because I think it will be useful
to talk about these issues in the context of (and/or relative to)
an example.  I am not necessarily in favor of all the parts of
the license below.
-------- -------- -------- -------- -------- -------- --------
Copyright (c) 1993 (*somebody/ies*).  All rights reserved.

Permission to copy this software, to redistribute it, and to
use it for any purpose is granted, subject to the following
restrictions and understandings:

  1. Any copy made of this software must include this copyright
     and licence notice in full.

  2. Modified versions of this software must be plainly marked
     as such, and must not be misrepresented as being the original
     software.


  3. All materials developed as a consequence of the use of this
     software shall duly acknowledge such use, in accordance with
     the usual standards of acknowledging credit in software
     development.

  4. Users of this software agree to make their best efforts to
     return to (*somebody*) any improvements or extensions that
     they make to the original software, so that these may be
     included in future releases.

(*list of the parties involved*) make no express or implied
warranty or representation of any kind with respect to this
software, including any warranty that this software is error-
free. ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE IS HEREBY DISCLAIMED. IN NO EVENT WILL
THE AFOREMENTIONED PARTIES BE LIABLE FOR DAMAGES, INCLUDING
ANY GENERAL, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT. The
parties are under no obligation to provide any services, by
way of maintenance, update, or otherwise.
-------- -------- -------- -------- -------- -------- --------
Point #3 is kind of weak--it needs to be clarified.  The rest is
fairly legally sound.  By "legally", I mean the United States.
I know nothing about warranty and copyright laws of other specific
countries.

One solution that would probably work in the international community:
  1. Individual authors retain their copyright rights. This is
     the "default" as per (I believe) the Berne convention, unless
     it is a "work for hire" or the author signs away his/her
     rights.
  2. A license exists which the authors adopt if they want to
     contribute to the Kit. The license must be adopted as is;
     an author cannot adopt only parts of it, or add anything
     to it.
  3. Modifications (should this policy be adopted) should be
     directed principally towards the copyright holder, whose
     responsibility it is to incorporate them or not, perhaps
     with the advice or assistance of the mailing list.
  4. A copyright holder may assign his/her rights to another. The
     new copyright holder assumes all the responsibilities of the
     original copyright holder, with respect to the copyrighted
     material. The original copyright holder should notify the
     list (at least) of such an assignment. Both parties should
     retain copies of the assignment of copyright. An assignment
     done via e-mail may not be binding; a physical, paper copy
     should be signed by both parties.

Given the above solution, the following might be found at the top of
a source code file in the Kit:
/*  Copyright (c) 1993 John P. Doe.  All rights reserved.
 *
 *  This software is subject to the terms of the MiscKit
 *  general license. Refer to the license document included
 *  with the MiscKit distribution for these terms.
 */

(That is, if the license isn't included verbatim, rather than the
two-sentence notice above.)

>     One suggestion I have received on this is to take Larry
>     Wall's freeware license and modify that; we'd need to
>     get his permission first, though.

I've never seen it.  Is it like the license above?

Christopher Kane
[e-mail]