On 05/01/12 21:42, Norbert Thiebaud wrote:
On Tue, May 1, 2012 at 2:10 PM, Pedro Giffuni wrote:
On 05/01/12 12:20, Norbert Thiebaud wrote:
...
For larger contributions, an ICLA (or an SGA) is in order. Ditto for
smaller ones, if there are questions/concerns. Remember, any
committer can veto a patch. So incoming patches without an ICLA need
to meet a high bar to get into the code. My default posture would be
to veto any patch more than 10 lines long that does not come with an
iCLA.
really? so why didn't you veto r1182539, for example ?
I committed it so I will answer what is my personal position on this.
The patches were submitted to Oracle which provided the bugzilla
dump to us. At the time the patches were committed, the codebase
was under LGPLv3. The license for the code headers were later
changed by Oracle in hands of Andrew Rist.
Nice ex-post facto rationalization... so lets take r1226336 where you
pushed code that was not yours _after_ the AL2 re-license of the base
by Andrew...
I am really flattered that you have followed my commits so
carefully, no matter the reasons ;).
In the case of r1226336 I replicated for FreeBSD a change for
linux that was already committed before the move to ASF.
The author of the code was, a SUN/Oracle employee so I
don't see how he would've complained, but much more
relevant for licensing purposes, the code was already
under AL2. The issue number was noted only for
reference / background information.
In any case, the point is that Rob's claim that "My default posture
would be to veto any patch more than 10 lines long that does not come
with an iCLA." does not seems to be enforced in practice.
I don't speak for Rob.
I personally would argue against his specific 10 line limit and focus
more about the quality of the contribution if the argument comes
to be. I do think iCLAs are really about community building than
enforcing laws although I do recognize one needs rules at some
point.
PS: the specific svn revisions here are not the central point, the
point is the lack of any discussion/scrutiny on any of these followed
by the self-fulfilling prophecy: "To be released the code must be
clean. Releasing imply a detailed IP review (RAT was run), so surely
if the release was approved by a vote then the release _is_ IP clean,
and therefore if it is released then it is clean".
I think you are just trying to find some silly excuse to complain
about code that *you* clearly didn't write or own. All the code
either from version control or bugzilla was provided by Oracle
and all the code, and I mean *all* of it, has been carefully
audited in ways that no OpenOffice derivative has done before.
Pedro.
