Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Mon, 20 May 2002 14:05:27 -0400
Subject: SUMMARY [ was Re: [LAW] Quick Lesson in Copyright Law (was RE:
 copyright for docs [was: Re: [Bugs] URLSource])
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v472)
From: Diana Shannon <terracare@mac.com>
To: cocoon-dev@xml.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <00c901c20014$cc180f70$ac00a8c0@Gabriel>
Message-Id: <2A49BF00-6C1C-11D6-BA1A-0030653FE818@mac.com>

Here's my current understanding.

1.  contrib.xml makes the distinction between "core" and "optional" 
contributions of source code via patches supplied by non-committers. 
Core source code contributions must have copyright assigned to Apache. 
Optional contributions do not. Contributions of documentation are not 
discussed.

2. The Contributor License Agreement page 
(http://jakarta.apache.org/site/agreement.html) states that 
contributions from committers, not non-committers, are governed by 
licenses, not copyright assignments.

How should we extend this language to cover non-committer contributions 
of documentation?

a. If you extend the "spirit" of contrib.xml to documentation, then the 
decision (license or assignment) is based on how "core" or "optional" 
you consider the documentation.

b. If you extend the "spirit" of the Contributor License Agreement, then 
non-committer contributions should be governed by licensing also, not 
assignment. Why should it be more restrictive?

IMO, both approaches suggest licensing, not assignment. In other words, 
contributors of documentation in the form of patches must agree to 
provide Apache a "non-exclusive, irrevocable, worldwide, no-charge, 
transferable copyright license to use, execute, prepare derivative works 
of, and distribute ... " for their contributions. I don't see why 
assignment is necessary. In fact, licensing may create more incentives 
for would-be authors, because it allows more opportunities for their 
work to be published. This doesn't hurt, in fact, it helps advance 
Cocoon.

If you agree, I'll update contrib.xml (and other author docs) to reflect 
that understanding. If this is incorrect, then please advise.

Thanks for your patience.

Diana


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org