You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Michael Meeks <mi...@novell.com> on 2011/06/09 18:27:56 UTC
Re: Remediation ...
Hi Rob,
In the deluge of drivel I lost this gem in your response to
my scepticism about how quickly you could provide a binary release:
On Fri, 2011-06-03 at 10:31 -0400, robert_weir@us.ibm.com wrote:
> But one thing not to lose track of is that Symphony has done IP
> remediation at many levels. Where we've worked around things, we'll be
> able to contribute our fixes back. Could we have missed something? This
> is always possible. But I know with certainty that we've fixed things
> that LO has missed. (I'm talking patents, not the MPL/LGPL dependency
> issues).
You seem to assert that you have patent remediation patches for
problems that others are unaware of, that you can provide, but you are
choosing not to (yet) ? There is a nasty nucleus of potential future FUD
here, so it would be interesting to firm this perennial rumour up.
Is that what you are saying ? if so, my /show me the code/
request gets quite a lot louder. Assuming that is what you're saying,
I suppose this holding of key changes back is another un-expected
side-effect of the pure-joy of non-copy-left licensing.
Naturally, if there are changes to improve the product in this area,
I'm eager to be merging them for LibreOffice, and I am certain our team
is too. I would -hope- that open discussion of these things, would follow
IBM's best-practise template of Tridge's excellent work in the (copy-left)
linux kernel eg.
http://lkml.org/lkml/2009/6/26/313
and http://lkml.org/lkml/2009/6/26/314 pwrt. Q5 and onwards
IMHO this is vastly preferable to some smoke and lawyer (IANAL)
filled room that issues edicts to remove features and veto patches
without a clear public rational on a public list (cf. the above).
Can you comment on your plans, and/or can others comment on ASF
policies in this regard ? how are such issues worked through ?
> I think we'll all be in a stronger position, IP-wise, once (and
> if) we can all get working from the same repository.
My hope would be of good public disclosure following Tridge's
pattern that also allows substantial clarity around the issues, and
thus does not require blindly working from the same repository: and
indeed is a benefit to all free software office suite hackers.
Furthermore - another key issue of the LKML approach is that the
functionality is still present, but compile-time disabled. That seems to
me to have a number of positive virtues:
* As a European, I rather resent the ethnocentric imperialism
implied by trying to export the (terminally broken) US patent
system, and I resent the idea of permanently depriving the
whole world of good software primarily to make Americans
happy (until expiration)
+ separation can help avoid this general problem,
* removal of features without a clear explanation is a recipe
for people to jump in and fix eg. the FAT file-system issue
they have, while being unaware of the mine-field they
tap-dance into thus wasting time & destroying motivation
+ much better to have the feature present but separated
in some clean way.
So - in summary, what is really being suggested here ? and how
does it fit into the ASF way ?
Thanks,
Michael.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by ro...@us.ibm.com.
Michael Meeks <mi...@novell.com> wrote on 06/09/2011 12:27:56 PM:
> In the deluge of drivel I lost this gem in your response to
> my scepticism about how quickly you could provide a binary release:
>
> On Fri, 2011-06-03 at 10:31 -0400, robert_weir@us.ibm.com wrote:
> > But one thing not to lose track of is that Symphony has done IP
> > remediation at many levels. Where we've worked around things, we'll
be
> > able to contribute our fixes back. Could we have missed something?
This
> > is always possible. But I know with certainty that we've fixed things
> > that LO has missed. (I'm talking patents, not the MPL/LGPL dependency
> > issues).
>
> You seem to assert that you have patent remediation patches for
> problems that others are unaware of, that you can provide, but you are
> choosing not to (yet) ? There is a nasty nucleus of potential future FUD
> here, so it would be interesting to firm this perennial rumour up.
>
Michael, You might want to check the "External Dependencies" section of
the proposal. That is what the IPMC is voting on. If the IPMC wishes to
vote on every remark you or I have made on this list, on blogs or in the
press, then I'm sure either one of us could be "voted off the island". So
let's focus on the proposal:
http://wiki.apache.org/incubator/OpenOfficeProposal
Regards,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Jun 9, 2011 at 12:46 PM, Simon Phipps <si...@webmink.com> wrote:
> On Thu, Jun 9, 2011 at 5:34 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
>> On Thu, Jun 9, 2011 at 12:27 PM, Michael Meeks <mi...@novell.com>
>> wrote:
>> >
>> > IMHO this is vastly preferable to some smoke and lawyer (IANAL)
>> > filled room that issues edicts to remove features and veto patches
>> > without a clear public rational on a public list (cf. the above).
>>
>> All work at the ASF that involve changes to the code base will be done
>> in smoke-free and publicly archived mailing lists.
>>
>> If you have questions relating to prior work done by groups other than
>> the ASF, I encourage you to contact those groups directly.
>
> Despite the tone, I do think Michael makes a serious point. Rob did indicate
> that IBM has IP concerns and it would be good to have more details before
> Apache takes on any responsibilities for the code.
Yes, the tone is an issue. I will state that I do not appreciate it.
Any and all IP concerns will be taken seriously, and needs to be
resolved prior to exiting incubation. And it is the responsibility of
all who directly participate to ensure that the code is clean. We
clearly have a number of IBM members on the proposed committer list.
And furthermore, clearly everything that is produced here can be
picked up and used elsewhere. However, there is absolutely no
requirement that anybody do so. I won't quote the exact words that
Michael used, but it seems quite likely to me that a company like IBM
may be a bit more risk adverse than the TDF is.
> S.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Greg Stein <gs...@gmail.com>.
On Jun 9, 2011 11:16 AM, "Michael Meeks" <mi...@novell.com> wrote:
>...
> It still leaves something you can't answer though: whether it is
Rob's
> understanding of IBM's intention to camouflage such changes or to flag
> them all openly and clearly. Ultimately with a suite of 8+ million
> lines, packed with obscure features, and thousands of lines of change a
> day it is fairly easy to slip things in, to the potential detriment of
> other users of the code.
There is nothing complicated here. Just reply (on-list) with something like,
"that change seems more complicated than the log message tells me. can you
explain further?"
It isn't hard, and the lig message can be edited to clarify.
Cheers,
-g
Re: Remediation ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Jun 9, 2011 at 2:31 PM, Dave Fisher <da...@comcast.net> wrote:
>
> Since IBM has already implemented their workarounds and it is existing code shouldn't it all be contributed via a Software Grant from IBM and go through the same IP remediation as the Oracle grant only at a much smaller level of effort?
Software Grants from IBM and Oracle will only protect licensees of the
codebase against lawsuits from IBM and Oracle. There may or may not
be other patents held by other entities. These patents may or may not
be valid or enforceable. Different people may come to different
conclusions as to the relative risk.
How we sort this out will depend entirely on the specifics of each instance.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Dave Fisher <da...@comcast.net>.
On Jun 9, 2011, at 11:14 AM, Michael Meeks wrote:
> Hi Sam,
>
> On Thu, 2011-06-09 at 13:54 -0400, Sam Ruby wrote:
>> The net of all of this is that there will need to be a substantial
>> public aspect to this entire discussion. Yes, I will probably have
>> some private discussions with ASF lawyers over time over this matter,
>> but I can't see any way that we can -- or should -- avoid the need for
>> public discussion over this matter.
>
> Great; thank you for that re-assurance, it encourages me yet further
> wrt. Apache's governance, and answers yet more of my remaining
> questions, perhaps all.
>
> It still leaves something you can't answer though: whether it is Rob's
> understanding of IBM's intention to camouflage such changes or to flag
> them all openly and clearly. Ultimately with a suite of 8+ million
> lines, packed with obscure features, and thousands of lines of change a
> day it is fairly easy to slip things in, to the potential detriment of
> other users of the code.
Given the quieting on the list and the desire to move forward with a vote, I hesitate to write the following:
Since IBM has already implemented their workarounds and it is existing code shouldn't it all be contributed via a Software Grant from IBM and go through the same IP remediation as the Oracle grant only at a much smaller level of effort?
If done that way then the initial IBM contribution is clear and can be evaluated by whoever desires without requiring heroic effort in order to sort them out from other changes to the codebase.
I think that the proposal should be updated to include a bullet point about seeking a grant from IBM in the "Initial Source" section.
Best Regards,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Jun 9, 2011 at 2:14 PM, Michael Meeks <mi...@novell.com> wrote:
> Hi Sam,
>
> On Thu, 2011-06-09 at 13:54 -0400, Sam Ruby wrote:
>> The net of all of this is that there will need to be a substantial
>> public aspect to this entire discussion. Yes, I will probably have
>> some private discussions with ASF lawyers over time over this matter,
>> but I can't see any way that we can -- or should -- avoid the need for
>> public discussion over this matter.
>
> It still leaves something you can't answer though: whether it is Rob's
> understanding of IBM's intention to camouflage such changes or to flag
> them all openly and clearly. Ultimately with a suite of 8+ million
> lines, packed with obscure features, and thousands of lines of change a
> day it is fairly easy to slip things in, to the potential detriment of
> other users of the code.
Independent of anybody's understanding of IBM's intent, I can tell you
that the way we will proceed will be based on the input of ASF's
lawyers, not IBM's.
Meanwhile, I won't answer any hypothetical questions on this matter.
When IBM is prepared to contribute fixes, I will participate.
Anything I discover that is relevant to the ASF will be shared with
ASF lawyers, and how we proceed will be take their input and guidance
into consideration.
I will restate that it is not just the initial contribution that we
need to be concerned about. We will need to ensure that subsequent
contributions by any of the contributors does not undo these changes.
> Thanks,
>
> Michael.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Jun 9, 2011 at 2:53 PM, Michael Meeks <mi...@novell.com> wrote:
>
> On Thu, 2011-06-09 at 14:27 -0400, Noel J. Bergman wrote:
>> > Ultimately with a suite of 8+ million lines, packed with obscure features,
>> > and thousands of lines of change a day it is fairly easy to slip things in,
>> > to the potential detriment of other users of the code.
>>
>> Wait. How is an IP remediation of "potential detriment of other users of
>> the code"? I can appreciate your concern over potential submarine patents
>> -- we do have a clause to address that -- but how is REMOVAL of a problem
>> a potential detriment?
>
> The removal is great, we want to do that too (though as a separation).
> The problem is if it is done silently and in a way that is obscured. It
> would be easy to hide the "what to remove" making it available only to
> those using a verbatim Apache Office.
>
> This is what I want to avoid; I would like to winkle this information
> out, publicly, to ensure that LibreOffice (and others: gnumeric, KOffice
> etc.) can take advantage of it. Is that clearer ?
Do you wish to participate? If so, I encourage you to feel free to
sign up on the wiki at this time.
Scanning the current list it appears likely that we have plenty of
volunteers who likely will want to scratch that same itch so signing
up may not be necessary.
Meanwhile, I encourage you to look at the overall history of the ASF
and how we have dealt with patents in the past and not presume that we
will suddenly abandon how we approach such matters.
> HTH,
>
> Michael.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Ross Gardler <rg...@apache.org>.
On 09/06/2011 19:53, Michael Meeks wrote:
>
> On Thu, 2011-06-09 at 14:27 -0400, Noel J. Bergman wrote:
...
> This is what I want to avoid; I would like to winkle this information
> out, publicly, to ensure that LibreOffice (and others: gnumeric, KOffice
> etc.) can take advantage of it. Is that clearer ?
You are welcome to participate in the project in a constructive way,
including helping make sure the project culture embraces this kind of
transparency.
Alternatively, you can consume the code without expecting to influence
it's management.
Or you can simply ignore the whole thing as a corporate trap not worthy
of your time or patronage.
Our processes for handling these situations are good enough for me, I
opt for the first action. I hope you too can opt for one of the first
two options, I truly believe it will strengthen us both. However, you
are free to adopt the third and call me a fool when we have that beer.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 10, 2011, at 11:47 AM, Volker Merschmann wrote:
>>
> Some fundamental comments about the license have been written down by
> the FSF: http://www.fsf.org/news/openoffice-apache-libreoffice
>
As posted on the discuss@ list... So what?
It would be trivially easy for someone here to post a
counterpoint blog coming to the opposite conclusion and
"proving" that AL is the right choice (and unlike the FSF
post, wouldn't be back-pedalling)...
If people are so easily swayed and make their decision of
license based on what FSF (or anyone else) says, then I
pity them.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Volker Merschmann <me...@gmail.com>.
Hi,
2011/6/10 Sam Ruby <ru...@intertwingly.net>:
> On Fri, Jun 10, 2011 at 4:47 AM, Nick Kew <ni...@apache.org> wrote:
>> On 9 Jun 2011, at 20:10, Noel J. Bergman wrote:
>>> I agree that the ethical thing to do is to inform partners of such matters, although I still don't know how to guarantee it. And generally speaking, you might want to treat the specifics of such matters in similarly sensitive manner as to how you would carefully handle any potential security related matters that might exist.
>>
>> Surely now this has been flagged, we can and should proactively address it
>> in incubation.
>>
>> I'd propose to create a "Patent Issues" bug report. We can then call on all
>> participants with knowledge of patent issues to enter them as dependencies
>> of the meta-bug, so that Michael and other interested parties have a focus
>> for related activity at apache.org.
>>
>> I would also suggest that it should be a blocker for graduation that every
>> known patent issue be resolved. That is to say, either a full fix, or failing
>> that a discussion and executive summary sufficient to alert users.
>
> Before proceeding, I would like to seek advice from our counsel. I
> also want to proceed based on specific patent infringement concerns
> and not on abstract hypotheticals. However, I don't want to spend
> valuable time on this until we decide whether or not to accept this
> project for incubation.
>
Some fundamental comments about the license have been written down by
the FSF: http://www.fsf.org/news/openoffice-apache-libreoffice
Volker
--
Volker Merschmann
Member of The Document Foundation
http://www.documentfoundation.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Jun 10, 2011 at 4:47 AM, Nick Kew <ni...@apache.org> wrote:
>
> On 9 Jun 2011, at 20:10, Noel J. Bergman wrote:
>
>> Michael,
>>
>> I agree that the ethical thing to do is to inform partners of such matters, although I still don't know how to guarantee it. And generally speaking, you might want to treat the specifics of such matters in similarly sensitive manner as to how you would carefully handle any potential security related matters that might exist.
>
> Surely now this has been flagged, we can and should proactively address it
> in incubation.
>
> I'd propose to create a "Patent Issues" bug report. We can then call on all
> participants with knowledge of patent issues to enter them as dependencies
> of the meta-bug, so that Michael and other interested parties have a focus
> for related activity at apache.org.
>
> I would also suggest that it should be a blocker for graduation that every
> known patent issue be resolved. That is to say, either a full fix, or failing
> that a discussion and executive summary sufficient to alert users.
Before proceeding, I would like to seek advice from our counsel. I
also want to proceed based on specific patent infringement concerns
and not on abstract hypotheticals. However, I don't want to spend
valuable time on this until we decide whether or not to accept this
project for incubation.
However we proceed, I will keep the incubator PMC informed.
> --
> Nick Kew
>
> Available for work, contract or permanent
> http://www.webthing.com/~nick/cv.html
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Nick Kew <ni...@apache.org>.
On 9 Jun 2011, at 20:10, Noel J. Bergman wrote:
> Michael,
>
> I agree that the ethical thing to do is to inform partners of such matters, although I still don't know how to guarantee it. And generally speaking, you might want to treat the specifics of such matters in similarly sensitive manner as to how you would carefully handle any potential security related matters that might exist.
Surely now this has been flagged, we can and should proactively address it
in incubation.
I'd propose to create a "Patent Issues" bug report. We can then call on all
participants with knowledge of patent issues to enter them as dependencies
of the meta-bug, so that Michael and other interested parties have a focus
for related activity at apache.org.
I would also suggest that it should be a blocker for graduation that every
known patent issue be resolved. That is to say, either a full fix, or failing
that a discussion and executive summary sufficient to alert users.
--
Nick Kew
Available for work, contract or permanent
http://www.webthing.com/~nick/cv.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Remediation ...
Posted by "Noel J. Bergman" <no...@devtech.com>.
Michael,
I agree that the ethical thing to do is to inform partners of such matters, although I still don't know how to guarantee it. And generally speaking, you might want to treat the specifics of such matters in similarly sensitive manner as to how you would carefully handle any potential security related matters that might exist.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Remediation ...
Posted by Michael Meeks <mi...@novell.com>.
On Thu, 2011-06-09 at 14:27 -0400, Noel J. Bergman wrote:
> > Ultimately with a suite of 8+ million lines, packed with obscure features,
> > and thousands of lines of change a day it is fairly easy to slip things in,
> > to the potential detriment of other users of the code.
>
> Wait. How is an IP remediation of "potential detriment of other users of
> the code"? I can appreciate your concern over potential submarine patents
> -- we do have a clause to address that -- but how is REMOVAL of a problem
> a potential detriment?
The removal is great, we want to do that too (though as a separation).
The problem is if it is done silently and in a way that is obscured. It
would be easy to hide the "what to remove" making it available only to
those using a verbatim Apache Office.
This is what I want to avoid; I would like to winkle this information
out, publicly, to ensure that LibreOffice (and others: gnumeric, KOffice
etc.) can take advantage of it. Is that clearer ?
HTH,
Michael.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Remediation ...
Posted by "Noel J. Bergman" <no...@devtech.com>.
Michael Meeks wrote:
> It still leaves something you can't answer though: whether it is Rob's
> understanding of IBM's intention to camouflage such changes or to flag
> them all openly and clearly.
Separating the above from what seems to be the underlying concern.
> Ultimately with a suite of 8+ million lines, packed with obscure features,
> and thousands of lines of change a day it is fairly easy to slip things in,
> to the potential detriment of other users of the code.
Wait. How is an IP remediation of "potential detriment of other users of the code"? I can appreciate your concern over potential submarine patents -- we do have a clause to address that -- but how is REMOVAL of a problem a potential detriment?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Michael Meeks <mi...@novell.com>.
Hi Sam,
On Thu, 2011-06-09 at 13:54 -0400, Sam Ruby wrote:
> The net of all of this is that there will need to be a substantial
> public aspect to this entire discussion. Yes, I will probably have
> some private discussions with ASF lawyers over time over this matter,
> but I can't see any way that we can -- or should -- avoid the need for
> public discussion over this matter.
Great; thank you for that re-assurance, it encourages me yet further
wrt. Apache's governance, and answers yet more of my remaining
questions, perhaps all.
It still leaves something you can't answer though: whether it is Rob's
understanding of IBM's intention to camouflage such changes or to flag
them all openly and clearly. Ultimately with a suite of 8+ million
lines, packed with obscure features, and thousands of lines of change a
day it is fairly easy to slip things in, to the potential detriment of
other users of the code.
Thanks,
Michael.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Jun 9, 2011 at 1:34 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Joe Schaefer wrote:
>
>> I don't see how this has any bearing on the vote. The ASF doesn't require
>> entities to disclose whether or not any particular contribution includes a
>> patent license.
>
> We do, however, have the patent clause to ensure that contributed code comes
> with license for any necessary and owned IP. What would not be covered
> would be any hypothetical 3rd party patent(s) that might potentially be
> infringed by a contribution.
>
>> If at some point there needs to be a discussion about outstanding patent
>> claims regarding the code grant to the ASF, that is best done in the
>> confines of a podling, on the podling's public dev list.
>
> Well, started perhaps with ASF Legal, and then discussed as determined
> appropriate by our lawyers. Which suggests to me that Sam ought to quietly
> take the lead on this issue, and we should put it aside for the moment.
We definitely should decide whether or not we wish to accept this
proposal before we invest efforts in mitigation. Any mitigation will
involve code, and all participants will be able to vote on whether or
not to accept that code. Additionally, it will be incumbent on all
participants to review subsequent changes and potentially veto such
changes. As stated earlier in such threads such vetoes will need to
be accompanied by explanations.
The net of all of this is that there will need to be a substantial
public aspect to this entire discussion. Yes, I will probably have
some private discussions with ASF lawyers over time over this matter,
but I can't see any way that we can -- or should -- avoid the need for
public discussion over this matter.
> --- Noel
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Joe Schaefer <jo...@yahoo.com>.
What we can say for certain is that Oracle won't be turning
around and suing ASF or any downstream user of the Apache-licensed
codebase for infringement. Same goes for IBM once they start
contributing to it. The patent provisions in the license only
kick in on entities who contribute to us, so it's advantageous
to seek out contributions from as many orgs as possible.
----- Original Message ----
> From: Donald Whytock <dw...@gmail.com>
> To: general@incubator.apache.org
> Sent: Thu, June 9, 2011 12:58:26 PM
> Subject: Re: Remediation ...
>
> Considering the code was owned by Oracle, would Oracle and IBM have
> slugged out any IP issues between them before now?
>
> On Thu, Jun 9, 2011 at 12:56 PM, Joe Schaefer <jo...@yahoo.com>
wrote:
> >
> >
> > ----- Original Message ----
> >> From: Simon Phipps <si...@webmink.com>
> >> To: general@incubator.apache.org
> >> Sent: Thu, June 9, 2011 12:46:41 PM
> >> Subject: Re: Remediation ...
> >>
> >> On Thu, Jun 9, 2011 at 5:34 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> >>
> >> > On Thu, Jun 9, 2011 at 12:27 PM, Michael Meeks
<mi...@novell.com>
> >> > wrote:
> >> > >
> >> > > IMHO this is vastly preferable to some smoke and lawyer
(IANAL)
> >> > > filled room that issues edicts to remove features and veto patches
> >> > > without a clear public rational on a public list (cf. the above).
> >> >
> >> > All work at the ASF that involve changes to the code base will be done
> >> > in smoke-free and publicly archived mailing lists.
> >> >
> >> > If you have questions relating to prior work done by groups other than
> >> > the ASF, I encourage you to contact those groups directly.
> >> >
> >>
> >> Despite the tone, I do think Michael makes a serious point. Rob did
>indicate
> >> that IBM has IP concerns and it would be good to have more details before
> >> Apache takes on any responsibilities for the code.
> >
> > I don't see how this has any bearing on the vote. The ASF doesn't require
> > entities to disclose whether or not any particular contribution includes a
> > patent license. If anything is certain about this podling, given the
>mentors
> > there will be no tolerance for any unusual off-list collusion or non-public
> > decision-making regarding contributions of any kind.
> >
> > If Rob or any other IBM person has issues with what LO distributes, they
can
> > take it up with the TDF. If at some point there needs to be a discussion
>about
> > outstanding patent claims regarding the code grant to the ASF, that is best
>done
> > in the confines of a podling, on the podling's public dev list.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Donald Whytock <dw...@gmail.com>.
Considering the code was owned by Oracle, would Oracle and IBM have
slugged out any IP issues between them before now?
On Thu, Jun 9, 2011 at 12:56 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>
>
> ----- Original Message ----
>> From: Simon Phipps <si...@webmink.com>
>> To: general@incubator.apache.org
>> Sent: Thu, June 9, 2011 12:46:41 PM
>> Subject: Re: Remediation ...
>>
>> On Thu, Jun 9, 2011 at 5:34 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>
>> > On Thu, Jun 9, 2011 at 12:27 PM, Michael Meeks <mi...@novell.com>
>> > wrote:
>> > >
>> > > IMHO this is vastly preferable to some smoke and lawyer (IANAL)
>> > > filled room that issues edicts to remove features and veto patches
>> > > without a clear public rational on a public list (cf. the above).
>> >
>> > All work at the ASF that involve changes to the code base will be done
>> > in smoke-free and publicly archived mailing lists.
>> >
>> > If you have questions relating to prior work done by groups other than
>> > the ASF, I encourage you to contact those groups directly.
>> >
>>
>> Despite the tone, I do think Michael makes a serious point. Rob did indicate
>> that IBM has IP concerns and it would be good to have more details before
>> Apache takes on any responsibilities for the code.
>
> I don't see how this has any bearing on the vote. The ASF doesn't require
> entities to disclose whether or not any particular contribution includes a
> patent license. If anything is certain about this podling, given the mentors
> there will be no tolerance for any unusual off-list collusion or non-public
> decision-making regarding contributions of any kind.
>
> If Rob or any other IBM person has issues with what LO distributes, they can
> take it up with the TDF. If at some point there needs to be a discussion about
> outstanding patent claims regarding the code grant to the ASF, that is best done
> in the confines of a podling, on the podling's public dev list.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Remediation ...
Posted by "Noel J. Bergman" <no...@devtech.com>.
Joe Schaefer wrote:
> I don't see how this has any bearing on the vote. The ASF doesn't require
> entities to disclose whether or not any particular contribution includes a
> patent license.
We do, however, have the patent clause to ensure that contributed code comes
with license for any necessary and owned IP. What would not be covered
would be any hypothetical 3rd party patent(s) that might potentially be
infringed by a contribution.
> If at some point there needs to be a discussion about outstanding patent
> claims regarding the code grant to the ASF, that is best done in the
> confines of a podling, on the podling's public dev list.
Well, started perhaps with ASF Legal, and then discussed as determined
appropriate by our lawyers. Which suggests to me that Sam ought to quietly
take the lead on this issue, and we should put it aside for the moment.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Simon Phipps <si...@webmink.com>
> To: general@incubator.apache.org
> Sent: Thu, June 9, 2011 12:46:41 PM
> Subject: Re: Remediation ...
>
> On Thu, Jun 9, 2011 at 5:34 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> > On Thu, Jun 9, 2011 at 12:27 PM, Michael Meeks <mi...@novell.com>
> > wrote:
> > >
> > > IMHO this is vastly preferable to some smoke and lawyer (IANAL)
> > > filled room that issues edicts to remove features and veto patches
> > > without a clear public rational on a public list (cf. the above).
> >
> > All work at the ASF that involve changes to the code base will be done
> > in smoke-free and publicly archived mailing lists.
> >
> > If you have questions relating to prior work done by groups other than
> > the ASF, I encourage you to contact those groups directly.
> >
>
> Despite the tone, I do think Michael makes a serious point. Rob did indicate
> that IBM has IP concerns and it would be good to have more details before
> Apache takes on any responsibilities for the code.
I don't see how this has any bearing on the vote. The ASF doesn't require
entities to disclose whether or not any particular contribution includes a
patent license. If anything is certain about this podling, given the mentors
there will be no tolerance for any unusual off-list collusion or non-public
decision-making regarding contributions of any kind.
If Rob or any other IBM person has issues with what LO distributes, they can
take it up with the TDF. If at some point there needs to be a discussion about
outstanding patent claims regarding the code grant to the ASF, that is best done
in the confines of a podling, on the podling's public dev list.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Simon Phipps <si...@webmink.com>.
On Thu, Jun 9, 2011 at 5:34 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Thu, Jun 9, 2011 at 12:27 PM, Michael Meeks <mi...@novell.com>
> wrote:
> >
> > IMHO this is vastly preferable to some smoke and lawyer (IANAL)
> > filled room that issues edicts to remove features and veto patches
> > without a clear public rational on a public list (cf. the above).
>
> All work at the ASF that involve changes to the code base will be done
> in smoke-free and publicly archived mailing lists.
>
> If you have questions relating to prior work done by groups other than
> the ASF, I encourage you to contact those groups directly.
>
Despite the tone, I do think Michael makes a serious point. Rob did indicate
that IBM has IP concerns and it would be good to have more details before
Apache takes on any responsibilities for the code.
S.
Re: Remediation ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Jun 9, 2011 at 12:27 PM, Michael Meeks <mi...@novell.com> wrote:
>
> IMHO this is vastly preferable to some smoke and lawyer (IANAL)
> filled room that issues edicts to remove features and veto patches
> without a clear public rational on a public list (cf. the above).
All work at the ASF that involve changes to the code base will be done
in smoke-free and publicly archived mailing lists.
If you have questions relating to prior work done by groups other than
the ASF, I encourage you to contact those groups directly.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Ross Gardler <rg...@apache.org>.
Sent from my mobile device (so please excuse typos)
On 9 Jun 2011, at 17:27, Michael Meeks <mi...@novell.com> wrote:
> Can you comment on your plans, and/or can others comment on ASF
> policies in this regard ? how are such issues worked through ?
I can't comment on the details if Robs remediation comments, but I can confirm the ASF does not allow the kind of code blocking you seem to be predicting. Given that Rob is already an Apache committer you can be certain he already knows this.
"To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc. ). A veto without a justification is invalid and has no weight."
http://www.apache.org/foundation/voting.html
Ross
>
>> I think we'll all be in a stronger position, IP-wise, once (and
>> if) we can all get working from the same repository.
>
> My hope would be of good public disclosure following Tridge's
> pattern that also allows substantial clarity around the issues, and
> thus does not require blindly working from the same repository: and
> indeed is a benefit to all free software office suite hackers.
>
> Furthermore - another key issue of the LKML approach is that the
> functionality is still present, but compile-time disabled. That seems to
> me to have a number of positive virtues:
>
> * As a European, I rather resent the ethnocentric imperialism
> implied by trying to export the (terminally broken) US patent
> system, and I resent the idea of permanently depriving the
> whole world of good software primarily to make Americans
> happy (until expiration)
> + separation can help avoid this general problem,
>
> * removal of features without a clear explanation is a recipe
> for people to jump in and fix eg. the FAT file-system issue
> they have, while being unaware of the mine-field they
> tap-dance into thus wasting time & destroying motivation
> + much better to have the feature present but separated
> in some clean way.
>
> So - in summary, what is really being suggested here ? and how
> does it fit into the ASF way ?
>
> Thanks,
>
> Michael.
>
> --
> michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: Remediation ...
Posted by Andreas Kuckartz <A....@ping.de>.
Am 09.06.2011 19:13, schrieb Noel J. Bergman:
> Please stop using the meme that software patents make Americans happy.
+ 1 from Germany
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Remediation ...
Posted by Ross Gardler <rg...@apache.org>.
On 09/06/2011 18:59, Michael Meeks wrote:
>>> and/or can others comment on ASF policies in this regard ? how are
>>> such issues worked through ?
>
> This question was intended to mean:
>
> "What is ASF's normal modus operandi here ?, how does this type
> of issue get addressed ? are there guidelines on this kind of
> work getting done in public ? are there pre-existing cases of
> this getting done ? how are such issues worked through ?"
>
> So far I have an assurance from Sam that everything will be done on the
> public mailing list in an open way. That is great, but not 100%
> satisfying: does that include a public rational for apparently trivial
> code changes that have an impact in this area ? [ we would want to be
> aware of these of course ].
>
> I have an assurance from Ross that, when voted on, technical
> justifications will have to be given for the inclusion or otherwise of
> code changes; that is good too - but surely not every change is voted
> on.
I also provided a link to the page which provides all the answers you
need. In summary:
No - there is no need to justify all code changes (lazy consensus)
Yes - anyone can ask for a justification (usually commit-then-review for
committers and review-then-commit for non-committers)
No - we don't vote on everything (lazy consensus)
Yes - people can object to changes on technical grounds (veto)
No - Veto's can't be used to block things
We have a very long history of managing these things. We don't claim it
is perfect, but to date it has worked for many many many users and
contributors, on many projects.
While *you* may not think our way of doing thing is good enough, many
others do. Please don't try and force those who feel the ASF management
processes are sufficient to change them without strong and verifiable
evidence that the process is broken.
Shouting "FUD" while spreading your own FUD is not helping anyone.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Remediation ...
Posted by "Noel J. Bergman" <no...@devtech.com>.
Michael Meeks wrote:
> I rest my case about FUD. It seems hard for me to reconcile your
> statement with the emphasis around things happening transparently
Then let me be equally clear. I've learned not to discuss *potential* legal issues on public lists before first consulting counsel. Akin to the idea that you don't post security vulnerabilities on a public forum before you have a chance to address them. Which is why the rest of my response may have come across as vague. Personally, I'd prefer that we weren't discussing it until it can be investigated.
What I can say is that if "we" (which hopefully will include you), have done everything right in our code base, then everything you take downstream will be clean, as I previously mentioned and you liked. I'd like to say that any remediation would be flagged as such, but I don't know how to make it an iron-clad guarantee.
> > As an American, I wish that you lot would simply up and pass
> > legislation to reject all US Patents on software so that we
> > can get rid of our broken US patent system.
> As I understand it US patents are not enforceable in Europe and many
> other jurisdictions anyway
That's unclear to me. My hope is that if everyone outside of the US were to outright ban software patents and completely ignore American IP claims on such, that it would remove their value and lead to our abandonment of this dysfunctional system.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Remediation ...
Posted by Michael Meeks <mi...@novell.com>.
Hi Noel,
On Thu, 2011-06-09 at 13:13 -0400, Noel J. Bergman wrote:
> I heard about this, myself, in some specific detail very recently.
> I will leave disclosure to the relevant parties, but while it may
> or may not be an issue for you ...
I rest my case about FUD. It seems hard for me to reconcile your
statement with the emphasis around things happening transparently on
mailing lists. Of course it is an issue for me and disclosure is the
solution for it: surely.
> > Can you comment on your plans, and/or can others comment on ASF
> > policies in this regard ? how are such issues worked through ?
>
> Rob has already stated, as quoted by you, that "Symphony has done
> IP remediation at many levels. Where we've worked around things,
> WE WILL BE ABLE TO CONTRIBUTE OUR FIXES BACK." [Emphasis mine]
Thank you for your emphasis. Let me insert mine: CLEARLY I AM AN IDIOT
(cf. my sig :-). Now let me expand on my question, I had hoped the
question(s), from the context of the preceding paragraph were clear -
apparently they were not:
> > Can you comment on your plans
This meant: does IBM (or whomever the 'we' Rob uses is) intend to
contribute these supposed remediation changes back in a way that
involves full disclosure following the best-practise template that
Tridge provided ?
*Or* - does it intend to simply submit patches that tweak, and/or
remove, and/or change features in subtle ways without advertising their
effect / rational in a way that is not transparent ?
eg. I don't expect to know all the details of why a one-line "fix Foo
Feature implementation" commit is like it is; -but- if there is some
heavy-duty legal thinking behind it - then I do. I would like to know if
IBM intend to make that detail public as they commit such work. Is that
truly an unfair unreasonable question ?
> > and/or can others comment on ASF policies in this regard ? how are
> > such issues worked through ?
This question was intended to mean:
"What is ASF's normal modus operandi here ?, how does this type
of issue get addressed ? are there guidelines on this kind of
work getting done in public ? are there pre-existing cases of
this getting done ? how are such issues worked through ?"
So far I have an assurance from Sam that everything will be done on the
public mailing list in an open way. That is great, but not 100%
satisfying: does that include a public rational for apparently trivial
code changes that have an impact in this area ? [ we would want to be
aware of these of course ].
I have an assurance from Ross that, when voted on, technical
justifications will have to be given for the inclusion or otherwise of
code changes; that is good too - but surely not every change is voted
on.
So these get closer to answering my questions above - yet I am still
concerned about such work being done in a way that is public yet
obscure, hidden in plain sight - hence my question. Unless we are aware
of the issue, we cannot be sure that we include such changes (as
separations) into LibreOffice - which is a substantial issue (at least
for us).
> ASF policy is that our code must be unconstrained, in order to be
> available for all purposes to all parties. So, yes, we should expect
> (and require) that IP remediation will happnen in our codebase.
Thank you, that is helpful.
> > * As a European, I rather resent the ethnocentric imperialism
> > implied by trying to export the (terminally broken) US patent
> > system
>
> As an American, I wish that you lot would simply up and pass
> legislation to reject all US Patents on software so that we
> can get rid of our broken US patent system.
I don't quite understand your suggestion; European jurisdiction quite
sensibly doesn't extend to the US, and my ability to influence US policy
is negligible. As I understand it US patents are not enforceable in
Europe and many other jurisdictions anyway - what more can we do ? but
IANAL so YMMV.
All the best,
Michael.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Remediation ...
Posted by "Noel J. Bergman" <no...@devtech.com>.
Michael Meeks wrote:
> Robert Weir wrote:
> > But I know with certainty that we've fixed things that LO has missed.
> > (I'm talking patents, not the MPL/LGPL dependency issues).
> You seem to assert that you have patent remediation patches for
> problems that others are unaware of, that you can provide, but you are
> choosing not to (yet) ? There is a nasty nucleus of potential future FUD
> here, so it would be interesting to firm this perennial rumour up.
I heard about this, myself, in some specific detail very recently. I will leave disclosure to the relevant parties, but while it may or may not be an issue for you, IBM did not consider it FUD on their end, and invested in addressing it to their satisfaction. So let's at least, taking a line from one of Simon's recent messages, "assume they are a wise and honest conclusion to an earlier conversation until we discover otherwise."
> Can you comment on your plans, and/or can others comment on ASF
> policies in this regard ? how are such issues worked through ?
Rob has already stated, as quoted by you, that "Symphony has done IP remediation at many levels. Where we've worked around things, WE WILL BE ABLE TO CONTRIBUTE OUR FIXES BACK." [Emphasis mine]
ASF policy is that our code must be unconstrained, in order to be available for all purposes to all parties. So, yes, we should expect (and require) that IP remediation will happnen in our codebase.
> * As a European, I rather resent the ethnocentric imperialism
> implied by trying to export the (terminally broken) US patent
> system
As an American, I wish that you lot would simply up and pass legislation to reject all US Patents on software so that we can get rid of our broken US patent system. Please stop using the meme that software patents make Americans happy.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org