Simple SSL/TLS - Some Questions

[Zooko O'Whielacronx]

 Jill Ramonsky <Jill.Ramonsky at aculab.com> wrote:
>
> I confess ignorance in matters concerning licensing. The basic rules 
> which I want, and which I believe are appropriate are:
> (i) Anyone can use it, royalty free. Even commercial applications.
> (ii) Anyone can get the source code, and should be able to compile it to 
> executable from this.
> (iii) Copyright notices must be distributed along with the toolkit.
> (iv) Anyone can modify the code (this is important for fixing bugs and 
> adding new features) and redistribute the modified version. (Not sure 
> what happens to the copyright notices if this happens though).

#include "disclaimers/legalty"
#include "disclaimers/truth"
#include "disclaimers/appropriateness"
#include "disclaimers/miscellaneous"

I entered your preferences (I think) into the handy dandy interactive license 
chooser at http://pgl.yoyo.org/lqr/, and it said the following.  I may have
misunderstood your desiderata though, so don't take my word for it.  ;-)

Regards,

Zooko

License
   |           Hackers like accepting code under it
   |             | Combine with proprietary and redistribute
   |             |   | Combine with GPL'ed code and redistribute
   |             |   |   | Can redistribute binaries without source
   |             |   |   |   | Required to include patent license with contrib
   |             |   |   |   |   |
   |             |   |   |   |   |
   v             v   v   v   v   v
  ---           --- --- --- --- ---
 permissive      -   Y   -   Y   -
 GNU LPGPL       -2  Y1  -   N   -
 GNU GPL         -2  N   -   N   -
 Mozilla PL 1.1  -2  Y   -3  N   -

notes:

   1. The LGPL imposes some conditions on redistributing a combination of
LGPL'ed and proprietary code, including some requirement on how the LGPL'ed code
and the proprietary code are linked at run-time on the user's machine. It
appears to me that these clauses are intended to prevent people from violating
the spirit of the LGPL by using an obfuscating linker which prevents the user
from swapping in alternative versions of the LGPL'ed code. Read Section 6 of the
LGPL for details.
   2. Some members of the community refuse to accept GPL'ed source code into
their projects, although other members of the community strongly prefer GPL'ed
source code over other licenses. Contrast with code under permissive licenses
such as BSD, X11, MIT, and expat, which nobody refuses to accept. Almost nobody
refuses to accept LGPL'ed code, except the Apache Foundation so refuses, saying
that they think it would impose LGPL requirement upon the proprietary code (when
they are linked via the Java class-loading mechanism). The FSF disagrees with
this statement, asserting that such linking falls under section 6 of the LGPL.
As far as I know, nobody refuses to accept code which is licensed under the
Mozilla PL 1.1-plus-GPL-compatibility-clause (see note #3).
   3. MPL 1.1 can be specifically amended to allow combining with GPL, according
to the FSF's license list. 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com