You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Michael Meeks <mi...@suse.com> on 2012/05/01 18:38:10 UTC
Re: Legal question about (re)licensing
Hi Rob,
On Sun, 2012-04-29 at 12:08 -0400, Rob Weir wrote:
> On Sun, Apr 29, 2012 at 11:48 AM, Dennis E. Hamilton
> <de...@acm.org> wrote:
> > To be precise, the practice is for new contributions to be dual
> > licensed as LGPL and MPL by the contributor. It remains the case
> > that the main code body is under LGPL3 with the usual variations
> > for third-party material incorporated in the release.
>
> But the "practice" is not backed by a CLA or a code audit.
Interesting to see you laying down the facts about what happens in
LibreOffice land :-)
> So what exactly LO has is "license soup" as far as I am concerned.
The situation is reasonably simple currently; yet it is of course made
un-necessarily difficult by IBM & Oracle's insistence on choosing yet
another project and license for some ill-defined subset of the available
code; yet it will get unwound.
On Sun, 2012-04-29 at 10:41 -0700, Dennis E. Hamilton wrote:
> I have no idea how the TDF deals with provenance. None of us do
> anything to confirm that a contribution is original (in the copyright
> sense) and the contributor has the right. Acceptance is in good faith.
Dennis speaks much sense. IIRC you guys accept patches 'submitted' to
Apache without a CLA; using the AL2 'Contribution' language - which
makes sense to me. That however is conceptually rather similar to our
approach, opening the door in just the same way for being an unwitting
victim of incompetence or bad-faith from a submitter.
All the best,
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Re: Legal question about (re)licensing
Posted by Pedro Giffuni <pf...@apache.org>.
Michael, Michael ...
On 05/01/12 11:38, Michael Meeks wrote:
> Hi Rob,
>
>
>
>> So what exactly LO has is "license soup" as far as I am concerned.
> The situation is reasonably simple currently; yet it is of course made
> un-necessarily difficult by IBM& Oracle's insistence on choosing yet
> another project and license for some ill-defined subset of the available
> code; yet it will get unwound.
Come on ... you can't blame us for your inability to work with mainstream
OpenOffice since the early days of Go-OO :).
Concerning the code and licensing issues you seem to have, I will explain
it again in public:
1) Our development is pretty open and we have all the code available
on-line but we are not (yet) an official Apache Project, and the PPMC
doesn't have any authority to do a release.
2) The fact that the ASF has a SGA doesn't mean any code has been
or will be relicensed. All the code has to be reviewed first and will be
available as it is released by the ASF Project Incubator.
3) Just like everyone else you are invited to wait for the new release
which we hope you will find useful for your own purposes.
Pedro.
Re: Legal question about (re)licensing
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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.
Re: Legal question about (re)licensing
Posted by 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.
Re: Legal question about (re)licensing
Posted by 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
Posted by Pedro Giffuni <pf...@apache.org>.
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.
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).
I should also mention that I did a sweep through bugzilla and warned
all the coders I found that were explicitly licensing their contribution
under an unacceptable license: some of them relicensed and the rest
were closed.
best regards,
Pedro.
> Norbert
Re: Legal question about (re)licensing
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 1, 2012 at 1:20 PM, Norbert Thiebaud <nt...@gmail.com> wrote:
> On Tue, May 1, 2012 at 11:48 AM, Rob Weir <ro...@apache.org> wrote:
>>
>> We accept relatively small contributions without an ICLA. But all
>> contributions get reviewed, and all releases go through scans (what we
>> call RAT == Release Audit Tool) and are voted on in a transparent,
>> open process.
>
> RAT does not help you track to provenance of patches applied to existing files.
> RAT only check that a correct/compatible license is claimed, not that
> it is true.
>
Correct. That is why we have committers that apply patches, and
committers that review patches and can veto patches. And then we have
a vote by the entire PMC, and in our case also by the IPMC, to approve
a release. So it is multiple stages of review and approval, as befits
the important question. The RAT scan provides an automated inspection
that finds some, but not all issues. We think it is useful.
But in the interest of mutual information exchange and sharing, can
you tell us how TDF/LO determines that the code is sufficiently clean,
from an IP perspective, to release? This would be useful to
understand.
-Rob
>>
>> 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 ?
>
> Norbert
Re: Legal question about (re)licensing
Posted by Norbert Thiebaud <nt...@gmail.com>.
On Tue, May 1, 2012 at 11:48 AM, Rob Weir <ro...@apache.org> wrote:
>
> We accept relatively small contributions without an ICLA. But all
> contributions get reviewed, and all releases go through scans (what we
> call RAT == Release Audit Tool) and are voted on in a transparent,
> open process.
RAT does not help you track to provenance of patches applied to existing files.
RAT only check that a correct/compatible license is claimed, not that
it is true.
>
> 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 ?
Norbert
Re: Legal question about (re)licensing
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 1, 2012 at 12:38 PM, Michael Meeks <mi...@suse.com> wrote:
> Hi Rob,
>
> On Sun, 2012-04-29 at 12:08 -0400, Rob Weir wrote:
>> On Sun, Apr 29, 2012 at 11:48 AM, Dennis E. Hamilton
>> <de...@acm.org> wrote:
>> > To be precise, the practice is for new contributions to be dual
>> > licensed as LGPL and MPL by the contributor. It remains the case
>> > that the main code body is under LGPL3 with the usual variations
>> > for third-party material incorporated in the release.
>>
>> But the "practice" is not backed by a CLA or a code audit.
>
> Interesting to see you laying down the facts about what happens in
> LibreOffice land :-)
>
>> So what exactly LO has is "license soup" as far as I am concerned.
>
> The situation is reasonably simple currently; yet it is of course made
> un-necessarily difficult by IBM & Oracle's insistence on choosing yet
> another project and license for some ill-defined subset of the available
> code; yet it will get unwound.
>
> On Sun, 2012-04-29 at 10:41 -0700, Dennis E. Hamilton wrote:
>> I have no idea how the TDF deals with provenance. None of us do
>> anything to confirm that a contribution is original (in the copyright
>> sense) and the contributor has the right. Acceptance is in good faith.
>
> Dennis speaks much sense. IIRC you guys accept patches 'submitted' to
> Apache without a CLA; using the AL2 'Contribution' language - which
> makes sense to me. That however is conceptually rather similar to our
> approach, opening the door in just the same way for being an unwitting
> victim of incompetence or bad-faith from a submitter.
>
We accept relatively small contributions without an ICLA. But all
contributions get reviewed, and all releases go through scans (what we
call RAT == Release Audit Tool) and are voted on in a transparent,
open process.
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.
-Rob
> All the best,
>
> Michael.
>
> --
> michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
>