This document describes the purpose of each paragraph in the SPL:

Title: "Simple Public License"

  -- The main reason for writing a new license is that the existing ones
     are very difficult to read. Most licenses are actually evaluated 
     by ordinary programmers, so it is important that they be short, 
     and written in something close to plain English.


Opening statements: 

  -- Define (vaguely!) what is being licensed and to whom. The software
     itself should declare that it is licensed under this agreement, so
     that there is no ambiguity. For example, a statement should be 
     attached to the program source files: "This software is copyright
     (c) 2000 by ... and is licensed under the Simple Public License".

  -- Make it clear that this license is conditional on compliance, and
     draw attention to our disclaimers to help them be conspicuous.

  -- We need some indication of acceptance, but this is hard in a license
     where the software is distributed freely off of websites and on 
     CDROMs. However, the software is not "shinkwrap", it is packaged in
     an open manner: the user can inspect everything, including all of 
     the source code. Hopefully, then, it is sufficient to hinge 
     acceptance on use: after reading the license and all the source
     code, if desired, the user can use the software by accepting. Still,
     we don't have anything signed, so this might be a sticky issue.


Section (1): USE OUR SOFTWARE FOR FREE

  -- Says that anybody can use the software, and that they can use it
     for free. You may turn around and distribute the software to 
     other people and charge them a fee for that service. You may 
     also run the software on your computer and charge people a 
     fee for the privilege of using it. However, once someone has 
     a copy of the software it's free, and they can give it to 
     others for free if they like.

  -- I think we need to explicitly allow aggregate collections. They
     are technically a type of derivative work, but we don't want to 
     impose on them the kinds of restrictions we place on derivatives.


Section (2): SELLING NON-FREE APPLICATIONS

  -- The goal here is to support consultants who want to build things 
     on top of our software and sell them, without providing source, to 
     their clients. We do not want to allow commercial software vendors 
     to ship commercial versions of our software; nor do we want this 
     license to support commercial vendors who want to mass market a 
     product built out of our software. We want such people to approach
     us and negotiate a different license.

  -- We cut out middlemen, resellers, channels, and stores by insisting
     that the copy be sold directly to the end user. This hinders the 
     ability to mass-market a derived work, without hurting consultants.

  -- We prevent commercial versions of our software itself by insisting
     that the derivative be made from a complete, unmodified version
     of our work plus extra source code. Presumably a modification of
     our software would require changes and additions to our source.
     A consultant could still modify our software in order to support a
     client, but the modifications to our software itself would have to
     be shared with the community under section 3.

  -- We make these non-free versions dead-end copies by preventing 
     recipients from further modifying them, distributing, leasing, etc. 

  -- We specifically allow creating backups, since we have denied all
     rights to copy to the end user, and that would be unfair.


Section (3): Share improvements

  -- The whole point of opensource software is that recipients must
     have access to the source code, and be able to use it. This 
     section grants people the ability to use the source code.

  -- It is a "viral" license, in that it insists that all such
     modifications be shared with the community: if you improve the 
     software, you have to share those improvements with everyone else.

  -- Note the phrase "immediately  make them available to us and to the 
     public ... through a medium commonly used for software exchange ",
     this is intended to allow you to post the changes on a website once,
     and let us know where that website is. It would be an undue burden on
     someone if they had to contact us each and every time they modify our
     software. Instead, they should be able to publish their work on an
     accessible website once they've told us to look for it there.

  -- The license tries to be careful about who is licensing what to who. 
     Rights don't attach to software, so I think we need the "joint 
     offer" language to ensure that recipients of modified versions 
     actually get their rights from all the copyright owners.

  -- We want release under this license to be irrevocable, unless the
     recipient violates its terms. In other words, no releasing some 
     crucial improvements, letting everyone come to rely on them, and
     then pulling permission to use them and demanding money from 
     everyone. If you improve the software and release that to the 
     public, you do so for all time.

  -- We receive rights to alterations to our work itself, so that we 
     can merge them back into our source tree. Without this release of
     rights, we would be unable to release under multiple licenses. We
     do not want to receive the rights to independent works build 
     using our software, though, so we specify only those improvements
     which to the literal source code, "structure, sequence, or
     organization" (SSO) of our software. The SSO phrase is there so 
     that if you make our software depend on an additional file which
     you include, that additional file would be licensed to us as well.

  -- We also don't want people subverting the freedom of the derived
     work by making it subject to a patent claim, or by making the 
     result depend on some proprietary software (which presumably 
     the modifier would own). If you improve the software, you have
     to make sure that the result is really free for people to use.
     Thus we demand that it be unencumbered, and seek a patent license
     in the event that one applies.


Section (4): CREDIT

  -- Our main compensation for making our software available for 
     free is status and recognition. Free software amounts to a form
     of advertising of the skills of its authors. We want to ensure
     that we are properly and fully credited for our work.

  -- This clause is carefully worded. We want it to operate pretty much
     within the bounds of copyright law, but we also want it to be strong
     enough that it amounts to "consideration" under contract law: our
     consideration is the free advertising that goes along with the 
     software when someone copies it, or puts it to a new use.


Section (5): GENERAL

  -- Entire agreement: other documentation, things we say on the mailing list, 
     etc., are not to be considered part of the license contract.

  -- Termination. There are issues with termination that I am not clear
     on: what happens to patent rights, etc., that are granted when the
     license is terminated? Do they survive? Otherwise someone could 
     release improvements to the software, wait until everyone depends
     on them, and then terminate the agreement--pulling out the right
     to use those improvements. They could then demand money in exchange
     for licensing the rights to those improvements.. that would be bad.

  -- If the license is terminated the user basically loses all their 
     rights to the software. Except one: we let people continue to 
     distribute the software if it is already part of an existing 
     aggregate collection. If they had printed a million CD's, and
     had to recall them all because of an honest mistake, that would
     be unfair. Under this language they can still ship their CD's, 
     but some of the software on the CD cannot be lawfully used.
 
  -- We confer some special rights on distributors to arm them with 
     the legal right to go after infringers. Free software projects 
     are often abandoned by their original authors--the community then
     takes over development of the work. But then who would be able to
     press an infringement claim? The beneficial owner clause is here
     to allow the community to enforce the license even if the original
     author is hard to find, or hasn't got the legal resources, or 
     the time, or the interest, in pressing the claim.
     
  -- "Nothing will be interpreted strictly against us" probably doesn't
     work in most jurisdictions. The rules often work against the 
     author of a "take it or leave it" style license, on the theory 
     that they're in a position to badger everyone. However, in this 
     case, the software author is likely the little guy, and the 
     software user is some big company with legal muscles who may 
     sue the little guy for damages after a bug bites them. We want
     to give the little guy a break, so we put in this phrase--maybe
     it will help, maybe it will be struck down. 

  -- Since there are many things in our license that are probably not
     valid in all jurisdictions (hard to do in an international license)
     it's important that these invalid clauses don't bring down 
     the entire license--thus the language about reforming invalid
     clauses, and the rest of the license surviving.

  -- We have the right to release updated versions of the license. If 
     it turns out that there is a problem with this license, rather
     than invalidating all of the software under the license, we 
     want the chance to be able to post a corrected version of the 
     license, and have everyone begin using it immediately, without
     having to get all the software from the source all over again.

  -- We define a couple of general terms, like source code, and what 
     we mean by "software depends on other software". Maybe there are
     more important terms we should define here?


Section (6): DISCLAIMERS

  -- We start out justifying why we are imposing such broad disclaimers:
     Our users have the source code so they ARE in a position to find and
     fix problems. Since they get it for free, I feel this puts us
     in a good position to disclaim all warranties and liabilities,
     including the implicit ones. The user has the ability to perform
     their own acceptance testing before deciding to use our software.

  -- We put some teeth into the above by warning the user that our 
     software might be defective, might not conform to its documentation,
     advising them to test its suitability, and notifying them that they
     should fix any problems they encounter. There appears to be an 
     implied warranty for "conformance to documentation" for software 
     in Canada, so this may be needed to get around that. Also, we 
     forbid use of our software in situations where death or injury might
     result so as to avoid having the disclaimer struck down, since such
     risks cannot be disclaimed in many jurisdictions.

  -- We don't want to be liable for things that other people do--so
     we make developers accept liability and warranty offers for any
     derivative work they distribute. Also, just to be sure, we impose
     the same condition on simple distributors. The goal here is to
     avoid liability from third parties who claim that we are negligent,
     but who are not party to any agreement with us.

  -- Finally the big disclaimer statement, where we attempt to avoid 
     liability for anything and everything. In Canada implied warranties
     are called "conditions" whereas in the US they are "warranties", 
     so we disclaim them both, as well as "representations".