[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120204213405.I4W4B.197513.imail@fed1rmwml206>
Date: Sat, 4 Feb 2012 21:34:05 -0500
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: copyright and license statements
After getting a reply back from solar offlist, that he was waiting for my acceptance of this plan, I will take the time to do so now. I thought the works that i had done up until now, had satisfied these licensing arrangements.
I will interject comments where i feel they need to be.
---- Solar Designer <solar@...nwall.com> wrote:
> magnum, Jim, all -
>
> On Thu, Jan 05, 2012 at 04:20:50PM +0100, magnum wrote:
> > I use the recommended wording in files like mskrb5_fmt. In files that
> > someone else wrote and I just added stuff (these are the vast majority
> > of my patches), I can't claim "the" copyright, can I? Or maybe I can
> > claim a copyright for the few lines of mine, but then I'm not sure how
> > to word it. Maybe I should just say "This and that added by magnum 2012"
> > and nothing more?
>
> When you make non-trivial changes to source files that I or someone else
> wrote, you become a copyright holder to those derived works. So, yes,
> you can claim copyright, and I (and/or other authors) remain copyright
> holders as well. You don't have to document what exactly your copyright
> applies to (which portions of the source file), but doing so is helpful.
>
> I was not able to find a definitive answer on what constitutes a trivial
> change (too trivial to be subject to copyright). I think this is what
> would be called "a de minimis or insignificant contribution", but there's
> no precise definition of that (and even if there were one, it may differ
> by jurisdiction). I think we need to apply the same approach that most
> others in the "industry" appear to use. It appears that the following
> are examples of changes that don't make you a copyright holder: typo and
> error corrections (unless correcting an error involves adding a
> non-trivial amount of code - again, what is "non-trivial" is not
> precisely defined), moving pieces of code around, adding information
> that "is common property and containing no original authorship" (e.g.,
> character encoding translation tables). On the other hand, changes that
> add functionality and contain your "original work" are likely subject to
> your copyright.
>
> There's some information on this here:
> http://www.softwarefreedom.org/resources/2007/originality-requirements.html
> Section "6 Size and substantiality: affirmative defenses to infringement".
>
> There's also some more definitive information here:
> http://www.copyright.gov/circs/circ1.pdf
> (but this does not appear to touch the issue of triviality).
>
> For non-trivial changes to JtR source files where the contributor
> becomes a copyright holder, my preference so far has been to re-license
> the entire file under the permissive cut-down BSD license. This is what
> we did for jumbo's revision of unique.c when Jim made non-trivial
> contributions to that source file. We may (and probably should) do the
> same for config.c in jumbo, which includes the non-trivial addition of
> the .include directive support.
>
> However, for some other source files I think that would be problematic.
> For example, I am uncomfortable about lifting the GPL restrictions from
> rules.c for everyone at once because that file may be of (more) interest
> to (potential) proprietary password cracker programs. I'd like to
> retain the right to issue such non-GPL licenses to them explicitly. If
> you simply add your copyright statement to that file, which you should
> given your contributions to it in jumbo so far, then I am stuck with
> GPLv2, not being able to re-license the file in the future (neither for
> everyone at once nor for specific companies, etc.) without coordinating
> with you (which may even involve paperwork each time we're talking
> re-licensing for a specific company). I see the following ways to
> resolve this for such source files:
>
> 1. Move your non-trivial contributions to separate (new) source files
> such that you can unambiguously apply your copyright statement and our
> standard permissive cut-down BSD license just to those. Modify the
> original file (such as rules.c) in trivial ways only - e.g., adding
> calls into functions found in your new file.
The can be difficult. Take for instance mscash2. My CPU contributions to that were certainly non-trivial. That change ended up being about 50% total rewrite, and much of the orinal code and optimization attempts were scrapped (which made up about 75% of the original files.
For some modules, adding external source can be achieved, but this may put us into a state where we start adding more and more globals, which for a open project like john, can be a very ugly way to go.
> 2. Don't retain your copyright to your changes to shared files, but
> instead transfer copyright either to me or to a legal entity that will
> be the copyright holder for JtR - perhaps to Openwall, Inc. IIRC, this
> is the approach that e.g. the Nmap project is using (with copyright for
> contributions transferred to Insecure.Com LLC). You will continue to be
> credited as an author of those files anyway, but not be a copyright
> holder. (Authorship and copyright are distinct things.)
This one, I am much more open to, and feel it should be easier to do. Could something like this be done with a blanket transfer statement, and then within source files, simply refer to that statement of transfer. I personally am not overly concerned about the copyright. Credit for being author is all I have ever really wanted anyway. The code I have produced for this project has been done so under my knowledge and consent that the ownership rights of the source was to be owned by the JtR project as a whole, in whatever way was necessary.
> Are these acceptable for you and which one would you prefer?
>
> If we go with #2, then it would make sense to apply the same approach to
> entirely new files as well - e.g., to new formats. (Jumbo now has so
> many extras compared to the main JtR that those extras alone (such as
> many of the formats) may be of value to a company developing a
> proprietary password cracker.) This raises the issue of your own
> ability to reuse your code without GPL restrictions, though. Maybe
> Openwall should issue a license to each contributor with right to
> sublicense that contributor's source files to third-parties if/when the
> contributor chooses so. But this gets complicated.
>
> > There's also files like para-best.sh which is a new file but is a 95%
> > copy of best.sh which is your file. Not sure how to word a statement
> > there.
>
> If your changes made in para-best.sh relative to my best.sh are
> non-trivial, then you're a copyright holder to this derived work.
> I just took a look and I think the changes are non-trivial. In fact, I
> think only trivial aspects of my original best.sh are left - the overall
> structure of the script, but not any detail. My understanding is that
> program structure is not subject to copyright. So I think that you're
> the sole copyright holder to your para-best.sh.
>
> Not speaking of para-best.sh specifically, it would be nice to be able
> to just place one's changes in the public domain, but it is unclear
> whether this is possible. Some would argue that the law defines no
> mechanism to do that. The same can be said of placing entire new works
> in the public domain, but there's precedent to that, which may help.
> I don't know if there's precedent to placing one's changes to an
> existing work in the public domain - are you aware of such examples?
> Yet I prefer a copyright statement with a permissive license in all
> cases lately.
>
> I'd appreciate any comments.
>
> Thanks,
>
> Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
