JtR add-on licenses

[Solar Designer]

David,

On Sun, Jan 18, 2009 at 06:03:07PM +0100, David Paleino wrote:
> However, I was planning the release of 1.7.3.1 in Debian and... luckily I marked
> my debian/copyright with big TODO marks, we avoided a sure REJECT ;)

Well, I think you could include 1.7.3.1 in Debian without the patches
initially.  You don't have to apply them.

I wrote:

> > The possibilities for contributed code, to be considered for inclusion,
> > appear to be:
> > 
> > - public domain statement (in this case, the author should be mentioned,
> > but no copyright statement may be included; in fact, a copyright
> > disclaimer may be included along with the "placed in the public domain"
> > statement);
> 
> Well, copyright statement is just saying "Hey, I did it, I have my rights
> on it and can exercise those" --

A copyright statement says "I have my rights on it and can exercise
those".  It does not say "I did it" (copyright could also have been
transferred to the person/entity).

> but right after you release it in the "public domain".

I have no idea what you mean by this.

My point was that "public domain" and "copyrighted work" are mutually
exclusive.  So one can't meaningfully include both a copyright and a
public domain statement on a file.

> I don't consider files with missing statements as PD -- they're "All rights
> reserved" in most countries.

Correct.

> > - a relaxed license compatible with GNU GPL v2+, but also allowing for
> > proprietary derivative works - e.g., the license I use for popa3d or
> > Matthew Kwan's micro-license found in nonstd.c in JtR;
> 
> Yes -- I considered those free already (snippet from current debian/copyright):
...

Great.

I mentioned nonstd.c to illustate a suitable relaxed micro-license for
contributed code in general.  I'd be happy if all contributions, short
of those placed in the public domain (which I like best), were licensed
like that.

> > - dual-license: "GNU GPL v2 or later"
> 
> This is because JtR is itself under GPL-2+, I suppose.

Right now, JtR is GPL v2 only - but I want to retain the right to
"upgrade" to "GPL v2 or later" or to GPL v3 or to a later version (if
available at the time) if I choose to do so in the future.

> > or a specific permissive license allowing for proprietary derivative works at
> > the user's discretion;
> 
> Clear.

I quoted the above paragraph to not leave the "dual-license" quote out
of context (otherwise, someone could think of "dual-license" as
referring merely to different versions of the GPL, whereas it is
referring to "GPLv2+ or a permissive ...").

> As you might have seen, the mails I sent generally lacked any statement. So,
> let the authors decide the license they want -- if they choose BSD, I'll push
> them towards BSD-2, if they choose a JtR-incompatible (yet free) license, I'll
> warn them about the patches not being included upstream, and so forth.

OK.  I think most authors did not care about placing their code under a
specific license, so it makes sense to suggest to them what licenses
work best not only for Debian but also for inclusion upstream.  That way,
we'll avoid having them pick a "random" license at first, then have to
re-license should I want to consider the code for inclusion later.

You have essentially started to do it by including a reference to my
first posting on this in your e-mails.  Thank you!

> > I previously touched on this issue in the following posting:
> > 
> > 	http://www.openwall.com/lists/john-users/2007/03/19/4
> 
> Regarding the OpenSSL issue, ...

I think you misunderstood me on this.  My reference to OpenSSL in that
posting was not in connection with licensing.

> As far as I understand your requirements though, and the OpenSSL license [0],
> probably point 3 is failing your "must not have specific requirements for
> attribution" wish. Correct me if I'm wrong (I'm not a lawyer, after all).

Currently, I include this in the JtR Pro license:

"Some builds of John the Ripper Pro are statically linked against the
SHA-1 code from OpenSSL libcrypto, by Eric Young and others."

I hope this is sufficient.  As to the very specific attribution text
required by the OpenSSL license, I think it is actually inconsistent
with different specific text found in the SSLeay license.  Although the
OpenSSL license also includes the "Original SSLeay License", I find it
weird that it does not require those using OpenSSL in a product to use
the attribution required by SSLeay.  This is understandable, as the old
attribution would no longer be 100% correct, but I think it highlights a
problem with those specific attribution requirements.

Disclaimer: IANAL.

> Thank you for your mail. I'll point to it in further mails to add-on authors :-)

Thank you!

Alexander