Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ