Subject: Re: copyright questions
To: Jim Wise <jimw@numenor.turner.com>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: current-users
Date: 06/13/1997 17:20:53
On Fri, 13 Jun 1997 19:14:25 -0400 (EDT) 
 Jim Wise <jimw@numenor.turner.com> wrote:

 > This is simply not a valid excuse.  The whole point of the NetBSD
 > Project is code which can be freely redistributed under a set of simple,
 > specific requirements, not code which can be freely redistributed with
 > the permission of Chris Demetriou (and whatever hundred other people see
 > fit to emulate his license terms.)

Chris's license _DOES_ allow the code to be free redistributed.  No where
in the license does it say that you have to ask Chris for permission to
redistribute the code.  If it _did_ say that, it would have never made
it into the tree.  (As Chris noted before, it was scoured by people who
are know to pick nits.)

Look at the license... permission to redistribute is _explicitly_ granted
right there in the text (just like it is explicitly granted in stock
Berkeley-style licenses).

What the license _does_ do is document how to contact the author to
arrange for redistribution under different terms.  If you don't want
to arrange different terms, you don't have to contact the author for
any reason.

 > Sure.  But there are thousands of features in any real system.  While
 > requiring credit to be given to those you mention in an add _may_ be
 > feasible, requiring credit be given for the thousands you don't is
 > simply not workable.  Or is the intent of our license that "you may sell
 > NetBSD, but you may not advertise it."?

No, that is _not_ the intent.  The intent of his license is to give
credit where credit is due.  Even with the stock Berkeley-style license,
if you mention, in advertising, a feature who's implementation is covered
by that license, you have to include the attribution notice.

The NetBSD Project intends, before the next release, to have a COPYRIGHT
docuemnt that has the necessary information in it.  Up until now, vendors
have _always_ had to scour the entire source tree to make sure they're
adhering to all of the licenses.  Such a document will make it easier
for them.

 > No one is forcing you to contribute code.  We all appreciate the great
 > amount of excellent work you have done for the Project, but if the only
 > way we can continue to benefit from your work is to sacrifice the
 > Project's ideals, I, for one, say no thank you.  I am also curious to
 > hear from more of core on this -- it surprises me greatly that this
 > license was accepted into the source tree without being submitted to
 > general discussion.  (How does this affect DEC's plans to use NetBSD,
 > for example?)

Well, I am a member of Core, and I have been at least a little active
on this thread... I also try very hard to be fair and reasonable (if
someone thinks I am _not_ being fair and reasonable, by all means, tell
me).

Chris's new license is _not_ contrary to the goals of the project:

	(a) It allows free redistribution in source and binary forms.

	(b) It places no restrictions on who may use the software.

	(c) It places no restrictions on what the software may be
	    used for.

There _was_ a considerable amount of dicussion on this topic within
Core... As Chris could probabably tell you, it took _several_ weeks
to reach a decision.

As for why it wasn't discussed outside of Core... Historically, that's
just not the way things have been done.  When we commit a piece of Mach
code to the tree, do we discuss the license on current-users?  No.
When we commit a driver with a Berkeley-style license (but with a
different attribution clause) to the tree, do we discuss it on
current-users?  No.

The only reason this situation is different is because, in this case,
a contributor approached Core, stating the desire to change his licensing
terms in a way that would meet his needs.  By approaching us, it was
clear that he wanted to find the right terms that would suit his needs
and not conflict with the goals of the project.  We worked together on
it, and an acceptable agreement was reached.  In the event we were not
able to reach an agreement, we were prepared to tell the contributor that
the code could not be included in the NetBSD operating system.

 > If the existing license met the same conditions as yours, why the new
 > license?  You yourself have portrayed the new license as a change in the
 > credit rules.  I feel, as, apparently, do several others on this list,
 > that it is a change which benefits you at the expense of the Project.

On the contrary.  If he wanted to do something at the expense of the
Project, he would have never compromised on his terms when Core objected
to the first several revisions of the license.  It would have effectively
meant that he would no longer have been contributing code to NetBSD.
If he has good code to contribute, and an acceptable license can be
arranged, it benefits the Project to have that code.

 > No.  I would argue, in fact, that your current tack is actively hurting
 > that goal.

Well, I would disagree with you, here.  As I said, we (Core) thought
long and hard on this issue.  When it was all said and done, we determined
that the new license was _not_ contrary to the goals of the project.

As I stated earlier, I try very hard to be fair and reasonable, and I
hope that my track record backs up that claim.  Rest assured that I
thought about this issue very hard, and that I think a reasonable
solution was reached.

If you're still not convinced that we really did consider all of the
issues, and work out all of the loopholes, and would like to discuss
this with me further, my phone numbers are listed below.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939