incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <...@robweir.com>
Subject Re: [legal] ICLA paragraph 7
Date Wed, 31 Aug 2011 20:06:48 GMT
On Wed, Aug 31, 2011 at 3:54 PM, Eike Rathke <ooo@erack.de> wrote:
> Hi,
>
> I'm going to warm this up, as legal seems to have no definite opinion on
> it and effectively suggests the project has to establish its process and
> decide how it will handle larger contributions. See
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201108.mbox/%3CC23DED33-C4D1-454B-9A52-55281A4144F9@oracle.com%3E
>
> So, only one question:
>
> Will AOOo accept code contributions under AL2, be it on the mailing
> list, as JIRA attachment, or otherwise with consent of the original
> author, without the author having signed an iCLA?
>
> My position on this: yes, it should.
>

Let's reframe the question:  Will the project accept code
contributions under ALv2 via SVN from any committer?

The answer is: We usually operate under CTR.  Any other committer can
give a veto on your code contribution, for good reasons.

I think the same would be true for a patch from a non-committer.
Since only a committer can actually check in the patch, this is really
the same situation.  Any other committer can veto the merge of the
patch.

So I think we take this on a case-by-case basis.  Personally, I don't
have problems with a small patch of a few lines where the author has
clearly expressed they are contributing it under ALv2.  But a patch of
10,000 lines of code with doubted provenance?  I would not hesitate to
veto that.  For the in-between cases, I think we discuss the specific
case.

And from a community development perspective, we should be looking for
opportunities to encourage contributors to sign the iCLA and look for
ways to vote them in as Committers.  If someone is making many
patches, especially significant ones, and we have not voted them in as
a Committer, then the PPMC is doing something wrong.


>  Eike
>
>
> On Friday, 2011-08-12 18:53:41 +0200, Michael Stahl wrote:
>
>> hi Apache mentors,
>>
>> i've got a question as to what extent an ICLA from the copyright
>> holder is required for code contributions.
>>
>> a volunteer who is currently working in GSoC over at LibreOffice
>> (who has not signed an Apache ICLA) has given me permission to
>> contribute a bunch of makefiles that he wrote, with no licensing
>> restriction.
>>
>> now the ICLA contains this paragraph:
>>
>> >7. Should You wish to submit work that is not Your original creation,
>> >   You may submit it to the Foundation separately from any
>> >   Contribution, identifying the complete details of its source and of
>> >   any license or other restriction (including, but not limited to,
>> >   related patents, trademarks, and license agreements) of which you
>> >   are personally aware, and conspicuously marking the work as
>> >   "Submitted on behalf of a third-party: [named here]".
>>
>> so it seems to me that an ICLA from the copyright holder is not an
>> absolute requirement to contribute to Apache.
>>
>> is there any restriction in scope or otherwise for this paragraph?
>>
>> what exactly are the process requirements?
>>
>> my assumption is that the Committer must ask the potential
>> contributor whether they actually hold the copyright.
>>
>> i guess "submit it separately" means that it must be its own SVN
>> commit, not mixed with anything the Committer wrote him/herself.
>>
>> is it sufficient to put something like this into the SVN commit message:
>> "Submitted on behalf of a third party: [author name]; no licensing
>> restrictions"
>>
>> is it necessary to ask on the mailing list in every instance?
>>
>> in this case we are talking about ~30 new files, totalling ~2000 lines
>> (of which ~1000 are the boilerplate licensing headers...).
>>
>> regards,
>>  michael
>>
>
> --
>  PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
>  Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
>

Mime
View raw message