On Sun, Jan 18, 2009 at 06:03:07PM +0100, David Paleino wrote:
> However, I was planning the release of 126.96.36.199 in Debian and... luckily I
> my debian/copyright with big TODO marks, we avoided a sure REJECT ;)
Well, I think you could include 188.8.131.52 in Debian without the patches
initially. You don't have to apply them.
> > 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.
> > - 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
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
> > - 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;
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 ,
> 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.
> Thank you for your mail. I'll point to it in further mails to add-on authors
Pkg-john-devel mailing list