Re: Legal question about (re)licensing

[Norbert Thiebaud <nt...@gmail.com>]

On Tue, May 1, 2012 at 2:10 PM, Pedro Giffuni <pf...@apache.org> 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...

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.
As for review... I have yet to see any questions from reviewers,
mentors or ppmc members, to clarify the provenances of these sort of
patches nor the licensing ground behind them.

>
> In all this process, people that have submitted patches were notified
> through bugzilla that we were integrating the code and one person
> even went ahead and requested his patch were reverted (and I did
> it despite considering the patch was not copyrightable).

yeah that was r1195527 - which met Rob's 10 lines threshold - and yet
he did not veto it. in fact it only got reverted (r1198909) because
the author noticed and complained.
So the process is to add code, and wait for the original author to
complain... if he doesn't complain before the release, then it is
deemed to have met the rigorous IP scrutiny that Rob tout ?

Norbert

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".
Rob's 'holier than thou' public attitude on the topic remind me of the
old saying:  "People who live in glass houses shouldn't throw stones.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Legal question about (re)licensing

[Norbert Thiebaud <nt...@gmail.com>]

On Wed, May 2, 2012 at 6:52 AM, Rob Weir <ro...@apache.org> wrote:
> On Tue, May 1, 2012 at 10:42 PM, Norbert Thiebaud <nt...@gmail.com> wrote:
>
> <snip>
>
>> 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".
>> Rob's 'holier than thou' public attitude on the topic remind me of the
>> old saying:  "People who live in glass houses shouldn't throw stones.
>>
>
> Your argument is a form of the logical fallacy known as the "fallacy
> of the false dilemma", also called "false either/or" or
> "black-and-white thinking".  You argue that either the code review
> must reach some absolute level of complete perfection or that it is no
> better than doing no review at all.
>
> Let's recast that argument.

No need to make your straw-man version even more potent.
that is _not_ my argument, that is yours...

My argument is : You tout the quality of your IP review process,
smearing and denigrating the IP process of others, while giving only
lip service to the said process.
This is not your first rodeo
http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3COF1A1F1F97.0BA57C1E-ON852578A4.004EC606-852578A4.004FC4FE@lotus.com%3E
iow, you knowingly approved a release that you claim you "know for a
fact" has 'patent' infringement.


>
> Similarly, the Apache emphasis on IP review is not less important
> because of possible human error.

And error is presumably accidental, you patent threat above was
everything but. The willful ignorance of such allegations of a PPMC
member, by the PPMC is not a 'human error'.

>  In fact the multiple stages of
> review and approval are designed to give maximal opportunity to
> identify and fix such issues.  This has worked very well for this
> project, and the reviews we've done have found and addressed many
> issues.   It is far better than doing nothing.   In the end, I'll take
> diligence over negligence any day.

And yet

- You don't follow you're own guideline to 'veto' commit...
- Multiple error in attribution went in without anyone raising a question
- Multiple patches went in, unchallenged, with no clear connection to
an iCLA/SGA
- You claimed details and specific knowledge of patent infringement in
the code based, yet approved the release of such.

And despite all that you still tout your 'superior' IP cleanliness...
Just writing it in big letter on the Box does not make it true...

Norbert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Legal question about (re)licensing

[Rob Weir <ro...@apache.org>]

On Tue, May 1, 2012 at 10:42 PM, Norbert Thiebaud <nt...@gmail.com> wrote:

<snip>

> 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".
> Rob's 'holier than thou' public attitude on the topic remind me of the
> old saying:  "People who live in glass houses shouldn't throw stones.
>

Your argument is a form of the logical fallacy known as the "fallacy
of the false dilemma", also called "false either/or" or
"black-and-white thinking".  You argue that either the code review
must reach some absolute level of complete perfection or that it is no
better than doing no review at all.

Let's recast that argument.   We are not able to test 100% of
OpenOffice, from a path perspective with our current test cases.
Although we do have a practice of recording bugs and fixing them, we
have no practical way of achieving 100% perfection on defect detection
and removal. Therefore (your argument would go) it is not worth
testing at all, and we should not be allowed to tout the user benefits
of what testing that we do perform.

Now, you wouldn't make such an argument about testing, would you?

Similarly, the Apache emphasis on IP review is not less important
because of possible human error.  In fact the multiple stages of
review and approval are designed to give maximal opportunity to
identify and fix such issues.  This has worked very well for this
project, and the reviews we've done have found and addressed many
issues.   It is far better than doing nothing.   In the end, I'll take
diligence over negligence any day.

-Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Legal question about (re)licensing

[Pedro Giffuni <pf...@apache.org>]

On 05/01/12 23:58, Norbert Thiebaud wrote:
> On Tue, May 1, 2012 at 11:23 PM, Pedro Giffuni<pf...@apache.org>  wrote:
>> 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
> That is not what was said in the ooo-dev list
>
> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3CCAKQbXgCF0b8qtXkF1C_Yryx=EXfww4gX=-+VfkV15K_NNMEMBw@mail.gmail.com%3E
>
> clearly your assumption that the SGA extend to everything that one can
> put his hands on does not seems supported by the document itself. At
> the very least there are serious doubt as to the extent the SGA cover
> CWSs and/or random patch from bugzilla that had not been integrated
> into the project prior to the grant.
>

Ugh, well .. I did forget to mention the one key disclaimer in all
this: I am NOT a lawyer. Feel free to discard all my comments.

Pedro.

Re: Legal question about (re)licensing

[Norbert Thiebaud <nt...@gmail.com>]

On Tue, May 1, 2012 at 11:23 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
> 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

That is not what was said in the ooo-dev list

http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3CCAKQbXgCF0b8qtXkF1C_Yryx=EXfww4gX=-+VfkV15K_NNMEMBw@mail.gmail.com%3E

clearly your assumption that the SGA extend to everything that one can
put his hands on does not seems supported by the document itself. At
the very least there are serious doubt as to the extent the SGA cover
CWSs and/or random patch from bugzilla that had not been integrated
into the project prior to the grant.

But to my point: there are questions about the extent of the scope of
the SGA, question that have been brushed-off with a 'let's
cross-that-bridge-when-we-get-there' to avoid addressing the complex
'general statement'. Fine, but thn one would expect the actual applied
instance of this general problem to be at least discussed and resolved
with the copyright owner(s).... no such things occurred, at least not
on publicly accessible mailing-list.

Norbert

Re: Legal question about (re)licensing

[Norbert Thiebaud <nt...@gmail.com>]

On Tue, May 1, 2012 at 11:23 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
> 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

That is not what was said in the ooo-dev list

http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3CCAKQbXgCF0b8qtXkF1C_Yryx=EXfww4gX=-+VfkV15K_NNMEMBw@mail.gmail.com%3E

clearly your assumption that the SGA extend to everything that one can
put his hands on does not seems supported by the document itself. At
the very least there are serious doubt as to the extent the SGA cover
CWSs and/or random patch from bugzilla that had not been integrated
into the project prior to the grant.

But to my point: there are questions about the extent of the scope of
the SGA, question that have been brushed-off with a 'let's
cross-that-bridge-when-we-get-there' to avoid addressing the complex
'general statement'. Fine, but thn one would expect the actual applied
instance of this general problem to be at least discussed and resolved
with the copyright owner(s).... no such things occurred, at least not
on publicly accessible mailing-list.

Norbert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Legal question about (re)licensing

[Pedro Giffuni <pf...@apache.org>]

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.