Wednesday, June 21, 2017, 2:52:08 PM, John D. Ament wrote:

> All,
>
> I'm concerned with some of these threads I'm seeing w/r/t Freemarker.
> While I'm not a mentor on the project, I've been a user for a while and
> have been curious about Freemarker at Apache.
>
> I would not cite a CouchDB process from their old wiki.  First, its not
> clear if this is the most recent version (it mentions a migration to the
> new wiki and an external website which are red flags to me).

(It's not in their new Wiki... But then let's ignore it. There's still
LEGA-156.)

> Second, CouchDB has a much different model and contributor set than
> other projects do.
>
> I would cite a legal JIRA, and as far as I know everyone was already
> following this guide.
>
> I would also cite our legal guidelines
> https://www.apache.org/licenses/#clas in
> particular where it makes sense to expect an ICLA on file.  In general, ASF
> expects ICLAs for large enough contributions.  The size is at the
> discretion of the PMC receiving the contribution.  We do require ICLAs for
> committers to join a project (to receive an account, to receive write
> access) and many projects simply follow that model - you need an ICLA at
> that point in time.

I think what I'm proposing is pretty much the same, only it tells more
concrete details (which I believe is good for Committers who has to
merge stuff; or at least I find the ASF documentations pretty
scattered and at some places superficial). What am I missing?

As of https://www.apache.org/licenses/#clas, it says that:

  The ASF desires that all contributors of ideas, code, or
  documentation to any Apache projects complete, sign, and submit via
  email an Individual Contributor License Agreement (ICLA).

I doesn't talk about exceptions where an ICLA is not needed. But,
today I saw a thread on members@ where someone said ICLA is not needed
for mere contributors, only for Committers, and that led me to
https://issues.apache.org/jira/browse/LEGAL-156, where Legal says no
ICLA is needed for GitHub pull requests, etc.

> I would encourage Freemarker to keep things simple, especially since the
> total number of contributors is at 13.

But that's exactly why I wanted this. It is simpler for contributors
if they can just do a PR, without any paper work.

What do you mean by FM becoming process heavy? Which other threads do
you find concerning?

> John
>
> On Wed, Jun 21, 2017 at 6:48 AM Daniel Dekany <[email protected]> wrote:
>
>> Currently we strictly require a CLA (by which I mean an ICLA or CCLA)
>> for any contributions to be accepted, as
>> http://freemarker.org/contribute.html says.
>>
>> This practice was inherited from the pre-ASF times, when without
>> lawyers available, we tried to be on the safe side. But based on
>> https://issues.apache.org/jira/browse/LEGAL-156 and
>> https://wiki.apache.org/couchdb/CommitPolicy and some other mails we
>> can make things simpler for contributors (not to be confused with
>> committers).
>>
>> So I propose that we say that:
>>
>> - People sending contributions with GitHub pull requests need no CLA.
>>   But, before merging, we must check that:
>>   - The mail about the pull request was received to
>>     [email protected], so that there's
>>     a record of this even in the ASF infrastructure.
>>   - The files in the pull request has the standard ASF copyright
>>     headers, or no copyright headers in files where that's normally
>>     not present. There's no other conflicting copyright information
>>     included either (like a such LICENSE file).
>> - People sending in patches as attachment to FreeMarker Jira issues
>>   need no CLA. But, before merging, we must check that:
>>   - It's clear from the wording of the issue that the user wishes to
>>     contribute (as opposed to, for example, just showing an example).
>>   - Copyright headers are in order, just as with GitHub pull request.
>>
>> If someone contributes a bigger feature, yet they isn't a committer,
>> we might still ask a CLA though. But that can be dealt with when such
>> thing happens.
>>
>> --
>> Thanks,
>>  Daniel Dekany
>>
>>

-- 
Thanks,
 Daniel Dekany

Reply via email to