You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Simon Phipps <si...@webmink.com> on 2011/06/03 02:12:40 UTC
Proposal for OpenOffice Incubator strategy
TL;DR version: I think I see people talking past each other for a bunch of reasons, and I have a compromise proposal that might make things easier. It's at the bottom, and explained in some detail in the middle.
Introduction
------------
Before I start I will introduce myself. I was at Sun for a decade, more than half of it working on the open source portfolio including OpenOffice.org. Because of that I've a deep awareness of the history of OpenOffice.org and a good idea where most of the bodies are buried. I count many members of Apache and of the OpenOffice community as friends, both on the OpenOffice.org Project (where I'd apply for membership if such a thing existed) and the LibreOffice Project (where I applied and was accepted as a member). Today I am not part of any leadership for any project that's relevant here and I speak only for myself (and especially not for OSI where I am also a director). My dear wish for the last decade has been to see OpenOffice become an open and meritocratic open source project, and that goal has slipped tantalisingly from reach more than once.
I've tried to keep up with all the developments in this saga, as well as talk with all the folk I know how to reach informally to understand its dynamics. My apologies in advance if I've missed important details.
There's a gap
-------------
It seems to me that there's a big gap in the conversation. There's lots of talk of the vision for the future, of how things can be once a critical mass of developers reach Apache, of all the effort IBM wishes to invest in a resurrection. But it overlooks the fact that OpenOffice/LibreOffice isn't dead yet. There are tens of millions of people all over the planet who are using either OpenOffice.org (especially on Windows) or LibreOffice (mainly on Linux) and who rely on the combined work of the (now divided) existing community to deliver a steady stream of new releases incorporating bug fixes and improvements. There are also many people depending on downstream versions of these two projects. OpenOffice/LibreOffice is an existing, running machine with an enormous, incredibly important ecosystem. The big gap represents our collective responsibility to these people in the interim. This isn't just a neutral tarball we have to consider.
Just as the Mozilla project was reborn by the creation of Firefox, so I have long been a proponent of an OpenOffice project that similarly does a new, vibrant thing. I truly hope that Apache can be the home to a project that does this great work that groups of us have tried and failed before to get started - groups that include most of the new names Apache is seeing show up here.
All the same, the world wants OpenOffice to carry on while all this revolution is happening. There needs to be a build system, a distribution system, a contributor methodology and more. All this is needed not for some future, re-invented project but right now. Millions of people globally know what OpenOffice.org is, and they want it to keep going.
It seems to me that all the talk here mixes two different sets of requirements, both of which I support. There's no doubt that OpenOffice.org needs a Firefox-style rebirth. There's also no doubt that the distribution generally known as OpenOffice.org and also widely known as LibreOffice is still crucially important.
Proposal
--------
I suggest we discuss how to do both. We need to both keep the wheels turning so that Windows, Mac, Linux and other platforms get regular releases of updated code. We also need to devise a way for the New Thing to happen. So I suggest we explore something like this:
1. Apache should accept the contribution of both a copyright license to the code from Apache (and I suggest checking it's the full, multi-branched source including all the in-progress contributions that are in a CWS and not just the release) and the trademarks so that those resources are secured for the community.
2. This incubator project, which sets out to be the "Firefox of OpenOffice", should proceed pretty much as described, but under a name other than OpenOffice (just as Firefox got a different name). Something like "Apache ODF Suite" that describes the intent to be the core code of a fresh start. Picking an alternative name will help avoid those millions of current users getting confused, and I suspect will cool down some of the emotions in this discussion. I'm sure Rob and the others behind the proposal will be able to populate a podling to get this started.
3. Given that a substantial part of the effort that the LibreOffice project has committed has been the creation of an open repository and build system coupled with an effective international distribution system, I suggest that we collectively ask LibreOffice to take on the task of "business-as-usual" for OpenOffice, so that the Incubator project can focus on rebirth and not get swamped in the minutiae of "business as usual".
This new OpenOffice/LibreOffice project will also need to be the upstream for many of the non-public projects listed in the proposal (as well as being a downstream for the code from the incubator project when it graduates eventually). That will be fine for some of them, and others will probably need to consider engaging at the new "business-as-usual" project to make things OK. I suggest Apache ask this project to describe itself as "OpenOffice" so that everyone knows both what it is and where to go for the familiar code they are expecting.
I realise there are some big social challenges in this proposal and it will take acts of grace from across the divided community, but given the alternative of either trying to invent a completely new set of infrastructure in the Incubator to sustain business-as-usual or using what already works it seems worth asking for conciliatory grace from the members of the two sides of the existing public community.
This is purely my own thoughts, and there's no doubt room for improvement although I have run it past a few wise friends before posting it. But I suggest that without this clear demarcation of "new-project" and "business-as-usual-project" it will be very hard to disentangle the two sets of needs and fulfil the worthy objective at the start of the proposal, "Both Oracle and ASF agree that the OpenOffice.org development community, previously fragmented, would re-unite under ASF to ensure a stable and long term future for OpenOffice.org".
S.
--
Simon Phipps, http://webmink.com/
---------------------------------------------------------------------
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
Re: Remediation ...
Posted by Michael Meeks <mi...@novell.com>.
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
OpenOffice Proposal: Podling Releases
Posted by ro...@us.ibm.com.
Michael Meeks <mi...@novell.com> wrote on 06/03/2011 10:05:31 AM:
> > As for continuity of OpenOffice releases, there was a full stable
> > release of OpenOffice in January and a preview 3.4.0 release in April.
> > It is very reasonable for the new ApacheOffice project to start up,
> > and even while in incubation produce a release.
>
> It is unclear to me whether you can release binaries with all the
> copy-left dependencies bundled as Apache. If that is so - easy enough.
> If not, life will be harder, more development will be required, and the
> result will be much less feature-full.
>
A Podling can do a Podling release, if approved by the IPMC. My
understanding is the Podling Release must still adhere to AFS legal
requirements, so that would need to be resolved first.
See: http://incubator.apache.org/guides/releasemanagement.html
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). I think we'll all be in a stronger position, IP-wise, once (and
if) we can all get working from the same repository.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 3, 2011, at 11:09 AM, Ross Gardler wrote:
> On 03/06/2011 16:00, Christian Grobmeier wrote:
>>> Stupid question time: If TDF already has the *build* infrastructure,
>>> then isn't *that* a clear choice of where at least some level of
>>> cooperation can occur.
>>>
>>> After all, the ASF provides source... the TDF could provide
>>> the builds?? (but that's not all, of course)...
>>
>> what a fantastic idea!
>> Nothing to add at the moment, but when I read it, I knew this might be
>> a very good direction.
>
> Please see Simon Phipps' email earlier today that contained a very similar suggestion with some more detail, it would be nice to bring these two threads together.
>
Simon's suggestion folded in the concept of TDF's "open repository"
as a factor, which confuses things most awkwardly.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Simon Phipps <si...@webmink.com>.
On Fri, Jun 3, 2011 at 7:13 PM, Ross Gardler <rg...@apache.org> wrote:
>
> Ahhh... Yes I see something missing from Simons mail here. I assumed that
> the LibreOffice distribution would gradually migrate to using the core
> components proposed here (Apache ODFSuite as Simin called it) and thus
> collaboration on those components would also migrate here.
>
Yes, that's exactly what I assumed would happen in time. But my e-mail was
already TL;DR :-)
> If I understand correctly the donations from Oracle are not going to enable
> us to build an appropriately licenced end user product without significant
> work. Furthermore, the proposal and various press releases seem to indicate
> that A key focus of this project will be componentisation of the code base
> making it easier to reuse.
>
That is also my understanding. That's also why it's so important to have a
plan for how to sustain the end-user binary at least at a no-worse-than-now
level while the Apache project works out what has to go, what can stay, what
needs rewriting and so on.
I may be being naive, I prefer to think I'm an optimist.
>
Me too!
S.
Re: Proposal for OpenOffice Incubator strategy
Posted by Ross Gardler <rg...@apache.org>.
Sent from my mobile device (so please excuse typos)
On 3 Jun 2011, at 17:15, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> On Jun 3, 2011, at 12:06 PM, Ross Gardler wrote:
>
>> On 03/06/2011 16:43, Jim Jagielski wrote:
>>>
>>> On Jun 3, 2011, at 11:09 AM, Ross Gardler wrote:
>>>>
>>>> Please see Simon Phipps' email earlier today that contained a very similar suggestion with some more detail, it would be nice to bring these two threads together.
>>>>
>>>
>>> Simon's email, from what I can tell, boils down to:
>>>
>>> 1. The podling goes along as suggested.
>>> 2. The TDF continues business as usual.
>>
>>
>> I read it differently and more like what was proposed in this thread.
>>
>> The podling goes along as suggested and TDF continues to provide essential support to existing users of the the end user product that is currently called OpenOffice.org to some and LibreOffice to others).
>>
>
> But what of the *development* of the code?
Ahhh... Yes I see something missing from Simons mail here. I assumed that the LibreOffice distribution would gradually migrate to using the core components proposed here (Apache ODFSuite as Simin called it) and thus collaboration on those components would also migrate here.
> If business-as-usual
> is both sides independently developing the codebase, then
> how does that address what is, I guess, a main issue?
It doesn't help if there are two code bases, but if one project focusses on building permissively licensed core components that are needed in productivity apps in general then collaboration can happen on those components.
LibreOffice can continue to build an LGPL office suite (using those core components and their build infrastructure) and others can continue to build their own end user products under whatever license they choose (which might include a permissively licences end user product here).
If I understand correctly the donations from Oracle are not going to enable us to build an appropriately licenced end user product without significant work. Furthermore, the proposal and various press releases seem to indicate that A key focus of this project will be componentisation of the code base making it easier to reuse.
> Is the
> idea that the ASF contribute code which is then consumed
> by TDF and that any patches to TDF remain unaccessible to
> the ASF? Does this result in the communities driving closer
> together or farther apart?
My hope is that the benefits of collaboration over maintaining a fork will bring us closer together. I realise this means copyleft only folk have to come towards us for this to work. Certainly some people who don't like permissive licenses will never do this. I hope there are enough who see collaboration as being the right option.
I may be being naive, I prefer to think I'm an optimist.
However, maybe your right. Maybe I'm trying to link two ideas that should be kept separate so they can be evaluated separately.
Ross
> ---------------------------------------------------------------------
> 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: Proposal for OpenOffice Incubator strategy
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 3, 2011, at 12:06 PM, Ross Gardler wrote:
> On 03/06/2011 16:43, Jim Jagielski wrote:
>>
>> On Jun 3, 2011, at 11:09 AM, Ross Gardler wrote:
>>>
>>> Please see Simon Phipps' email earlier today that contained a very similar suggestion with some more detail, it would be nice to bring these two threads together.
>>>
>>
>> Simon's email, from what I can tell, boils down to:
>>
>> 1. The podling goes along as suggested.
>> 2. The TDF continues business as usual.
>
>
> I read it differently and more like what was proposed in this thread.
>
> The podling goes along as suggested and TDF continues to provide essential support to existing users of the the end user product that is currently called OpenOffice.org to some and LibreOffice to others).
>
But what of the *development* of the code? If business-as-usual
is both sides independently developing the codebase, then
how does that address what is, I guess, a main issue? Is the
idea that the ASF contribute code which is then consumed
by TDF and that any patches to TDF remain unaccessible to
the ASF? Does this result in the communities driving closer
together or farther apart?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Ross Gardler <rg...@apache.org>.
On 03/06/2011 16:43, Jim Jagielski wrote:
>
> On Jun 3, 2011, at 11:09 AM, Ross Gardler wrote:
>>
>> Please see Simon Phipps' email earlier today that contained a very similar suggestion with some more detail, it would be nice to bring these two threads together.
>>
>
> Simon's email, from what I can tell, boils down to:
>
> 1. The podling goes along as suggested.
> 2. The TDF continues business as usual.
I read it differently and more like what was proposed in this thread.
The podling goes along as suggested and TDF continues to provide
essential support to existing users of the the end user product that is
currently called OpenOffice.org to some and LibreOffice to others).
In this thread there was talk of sharing the build infrastracture TDF
has created for the product called LibreOffice.
There are some other issues in Simons proposal that might be less
palatable, but there are some that seem to be alinged with the ideas in
this thread. I probably should have pulled out the parts in Simons mail
that I felt were relevant here. Unfortunately I'm now out of time as I'm
off on a camping trip.
I'm sure it'll be thrashed out.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Jun 3, 2011 at 2:47 PM, Simon Phipps <si...@webmink.com> wrote:
> On Fri, Jun 3, 2011 at 7:42 PM, Greg Stein <gs...@gmail.com> wrote:
>
>> When I read Jim's email, I took it to mean your tweets[1]. Not your
>> emails to this list.
>
> Greg: I am being told by Sam Ruby to not talk about these topics so I will
> not respond apart from to acknowledge I am not ignoring you.
To be clear, the topics being your tweets and use of terms like
bitch-slapped and ideological on this list.
> S.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Simon Phipps <si...@webmink.com>.
On Fri, Jun 3, 2011 at 7:42 PM, Greg Stein <gs...@gmail.com> wrote:
>
> When I read Jim's email, I took it to mean your tweets[1]. Not your
> emails to this list.
Greg: I am being told by Sam Ruby to not talk about these topics so I will
not respond apart from to acknowledge I am not ignoring you.
S.
Re: Proposal for OpenOffice Incubator strategy
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jun 3, 2011 at 14:14, Simon Phipps <si...@webmink.com> wrote:
> On Fri, Jun 3, 2011 at 4:43 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>...
>> color me confused: first Simon slams the ASF for not actively
>> engaging TDF and others (although we, of course, did) but now
>> his suggestion is to basically ignore each other...
>
> Actually I thought my whole e-mail was pretty reasonable and in fact a call
> for ASF and TDF /not/ to ignore each other. But apparently my lame attempts
> to talk of collaboration and conciliation are "slamming" and the people who
> are flinging mud at TDF are just fine and get no rebuke from the ASF
> President. I must have done a terrible writing job...
When I read Jim's email, I took it to mean your tweets[1]. Not your
emails to this list.
Cheers,
-g
[1] http://twitter.com/webmink
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Simon Phipps <si...@webmink.com>.
On Fri, Jun 3, 2011 at 7:26 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Jun 3, 2011, at 2:14 PM, Simon Phipps wrote:
>
> >
> > If I were voting on this incubator proposal (and of course I know I am
> not),
> > I would want to know that the people proposing it had a grasp of the
> > enormity of the task and a plan for dealing with it /from day one/ and
> not
> > from an undefined point in the future after which Apache has a serious
> > reputational problem with that end-user community and a serious
> enforcement
> > problem with that trademark.
>
> As we all want to know... we are not idiots.
>
I must have missed the e-mails asking about it. Can you give me pointers
please?
S.
Re: Proposal for OpenOffice Incubator strategy
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 3, 2011, at 2:14 PM, Simon Phipps wrote:
>
> If I were voting on this incubator proposal (and of course I know I am not),
> I would want to know that the people proposing it had a grasp of the
> enormity of the task and a plan for dealing with it /from day one/ and not
> from an undefined point in the future after which Apache has a serious
> reputational problem with that end-user community and a serious enforcement
> problem with that trademark.
As we all want to know... we are not idiots.
>
> Since I did not see any hint of this in the proposal, my suggestion for how
> to deal with it from day one is to explore co-operation with LibreOffice,
> who have the build infrastructure, distribution infrastructure, translation
> and localisation infrastructure and indeed marketing infrastructure already
> in place, following eight months of hard work on their part. Ask them if
> they would be willing to create OpenOffice.org-the-binary-download for you.
> Ask them to host that binary download. Then as the Apache project falls into
> place, continue to collaborate for the good of the open source community.
>
and tell me *exactly* HOW we have not been doing that?
>
>
>> color me confused: first Simon slams the ASF for not actively
>> engaging TDF and others (although we, of course, did) but now
>> his suggestion is to basically ignore each other...
>>
>
> Actually I thought my whole e-mail was pretty reasonable and in fact a call
> for ASF and TDF /not/ to ignore each other. But apparently my lame attempts
> to talk of collaboration and conciliation are "slamming" and the people who
> are flinging mud at TDF are just fine and get no rebuke from the ASF
> President. I must have done a terrible writing job...
No, but *ignoring* the obvious efforts by numerous people who have
been talking of collaboration and conciliation does them a real
disservice.
I fail to see why you suggesting that the ASF and the TDF not ignore
each other, and that we practice collaboration and conciliation, is
something you see as "new" in this whole discussion. I've been pushing
it from the start.
And FWIW, I have quite often "slammed" others...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Simon Phipps <si...@webmink.com>.
On Fri, Jun 3, 2011 at 4:43 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Jun 3, 2011, at 11:09 AM, Ross Gardler wrote:
> >
> > Please see Simon Phipps' email earlier today that contained a very
> similar suggestion with some more detail, it would be nice to bring these
> two threads together.
> >
>
> Simon's email, from what I can tell, boils down to:
>
> 1. The podling goes along as suggested.
> 2. The TDF continues business as usual.
>
That's so far from being a valid interpretation of my proposal I almost
don't know where to begin.
What I am saying is that ASF is being entrusted with something it has never
had before; a consumer brand of inestimable value, combined with an
enormous, non-technical end-user community. OpenOffice.org is probably the
most recognised open source consumer brand after Linux. Servicing that
responsibility is a massive task. I've seen a few e-mails with people with
hand-waving it away ("how hard can it be?" etc) but those of us with
experience of OpenOffice know that it's daunting.
If I were voting on this incubator proposal (and of course I know I am not),
I would want to know that the people proposing it had a grasp of the
enormity of the task and a plan for dealing with it /from day one/ and not
from an undefined point in the future after which Apache has a serious
reputational problem with that end-user community and a serious enforcement
problem with that trademark.
Since I did not see any hint of this in the proposal, my suggestion for how
to deal with it from day one is to explore co-operation with LibreOffice,
who have the build infrastructure, distribution infrastructure, translation
and localisation infrastructure and indeed marketing infrastructure already
in place, following eight months of hard work on their part. Ask them if
they would be willing to create OpenOffice.org-the-binary-download for you.
Ask them to host that binary download. Then as the Apache project falls into
place, continue to collaborate for the good of the open source community.
> color me confused: first Simon slams the ASF for not actively
> engaging TDF and others (although we, of course, did) but now
> his suggestion is to basically ignore each other...
>
Actually I thought my whole e-mail was pretty reasonable and in fact a call
for ASF and TDF /not/ to ignore each other. But apparently my lame attempts
to talk of collaboration and conciliation are "slamming" and the people who
are flinging mud at TDF are just fine and get no rebuke from the ASF
President. I must have done a terrible writing job...
S.
Re: Proposal for OpenOffice Incubator strategy
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 3, 2011, at 11:09 AM, Ross Gardler wrote:
>
> Please see Simon Phipps' email earlier today that contained a very similar suggestion with some more detail, it would be nice to bring these two threads together.
>
Simon's email, from what I can tell, boils down to:
1. The podling goes along as suggested.
2. The TDF continues business as usual.
If the whole point of this discussion is to figure out
*how* the communities will work together, I fail to see
how that helps... After all, if that was the case, then
why even discuss things w/ TDF ("you guys just keep on doing
what you're doing... don't worry about what's going on
here." :) ). We could have done all that already.
color me confused: first Simon slams the ASF for not actively
engaging TDF and others (although we, of course, did) but now
his suggestion is to basically ignore each other...
At no point did I see anyone suggest that TDF totally shut
down and stop doing anything...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Ross Gardler <rg...@apache.org>.
On 03/06/2011 16:00, Christian Grobmeier wrote:
>> Stupid question time: If TDF already has the *build* infrastructure,
>> then isn't *that* a clear choice of where at least some level of
>> cooperation can occur.
>>
>> After all, the ASF provides source... the TDF could provide
>> the builds?? (but that's not all, of course)...
>
> what a fantastic idea!
> Nothing to add at the moment, but when I read it, I knew this might be
> a very good direction.
Please see Simon Phipps' email earlier today that contained a very
similar suggestion with some more detail, it would be nice to bring
these two threads together.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Benson Margulies <bi...@gmail.com>.
I'll go away on this. My concern has been to avoid setting an
impossible bar of organized cooperation as a prerequisite to voting
for the podling. It would be a wonderful thing if cooperation breaks
out, but I think that it is unrealistic to achieve very much of it
before the podling launches.
On Fri, Jun 3, 2011 at 11:10 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> Of course it does... but we are discussing ways where
> we can use all aspects of the existing communities to
> give the IPMC a warm-and-fuzzy regarding voting +1
>
> On Jun 3, 2011, at 11:04 AM, Benson Margulies wrote:
>
>> Um, it seems to me that this discussion of builds and distribution
>> belongs on the dev list of the podling when/if there is a podling.
>
>
> ---------------------------------------------------------------------
> 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: Proposal for OpenOffice Incubator strategy
Posted by Jim Jagielski <ji...@jaguNET.com>.
Of course it does... but we are discussing ways where
we can use all aspects of the existing communities to
give the IPMC a warm-and-fuzzy regarding voting +1
On Jun 3, 2011, at 11:04 AM, Benson Margulies wrote:
> Um, it seems to me that this discussion of builds and distribution
> belongs on the dev list of the podling when/if there is a podling.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Ross Gardler <rg...@apache.org>.
On 03/06/2011 16:04, Benson Margulies wrote:
> Um, it seems to me that this discussion of builds and distribution
> belongs on the dev list of the podling when/if there is a podling.
> Unless someone feels that there's a problem so gigantic that it should
> motivate -1 votes for the podling itself.
I agree that a decision on this is not required before the vote. However
I'd like to encourage discussion on this topic since it is an area for
solid collaboration between the TDF and the proposed Apache project.
That being said, it is important that we recognise this is a decision
for the project to make not the incubator PMC or even the ASF.
Ross
>
> On Fri, Jun 3, 2011 at 11:00 AM, Christian Grobmeier
> <gr...@gmail.com> wrote:
>>> Stupid question time: If TDF already has the *build* infrastructure,
>>> then isn't *that* a clear choice of where at least some level of
>>> cooperation can occur.
>>>
>>> After all, the ASF provides source... the TDF could provide
>>> the builds?? (but that's not all, of course)...
>>
>> what a fantastic idea!
>> Nothing to add at the moment, but when I read it, I knew this might be
>> a very good direction.
>>
>> So... is your suggestion that all development works might happen at
>> apache, but the real downloads and packages are done within TDF?
>>
>> ---------------------------------------------------------------------
>> 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: Proposal for OpenOffice Incubator strategy
Posted by Benson Margulies <bi...@gmail.com>.
Um, it seems to me that this discussion of builds and distribution
belongs on the dev list of the podling when/if there is a podling.
Unless someone feels that there's a problem so gigantic that it should
motivate -1 votes for the podling itself.
On Fri, Jun 3, 2011 at 11:00 AM, Christian Grobmeier
<gr...@gmail.com> wrote:
>> Stupid question time: If TDF already has the *build* infrastructure,
>> then isn't *that* a clear choice of where at least some level of
>> cooperation can occur.
>>
>> After all, the ASF provides source... the TDF could provide
>> the builds?? (but that's not all, of course)...
>
> what a fantastic idea!
> Nothing to add at the moment, but when I read it, I knew this might be
> a very good direction.
>
> So... is your suggestion that all development works might happen at
> apache, but the real downloads and packages are done within TDF?
>
> ---------------------------------------------------------------------
> 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: Proposal for OpenOffice Incubator strategy
Posted by Christian Grobmeier <gr...@gmail.com>.
> Stupid question time: If TDF already has the *build* infrastructure,
> then isn't *that* a clear choice of where at least some level of
> cooperation can occur.
>
> After all, the ASF provides source... the TDF could provide
> the builds?? (but that's not all, of course)...
what a fantastic idea!
Nothing to add at the moment, but when I read it, I knew this might be
a very good direction.
So... is your suggestion that all development works might happen at
apache, but the real downloads and packages are done within TDF?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by ro...@us.ibm.com.
Simon Phipps <si...@webmink.com> wrote on 06/03/2011 10:54:42 AM:
>
> That is what I was suggesting and which Rob claims he won't need because
its
> so easy.
>
Simon,
I don't think we should ever turn down an offer of help. I was just
suggesting that although the project is large and complex to build, we
have several "existence proofs" of projects that have done this with
requiring a high performance super computer. But with Apache Hadoop,
maybe, just maybe....hmmm...
In any case, my understanding is that the discussion around the proposal
is about what is possible and impossible, especially trying to identify
and resolve anything that appears impossible or implausible. I'm not
trying to dismiss issues as not being worth of offers of assistance, but
just trying to get us not to dwell on things that we know are not blocking
issues. It is triage.
In the podling itself, once the proposal is approved, we'll hash out in
the project how to do it well. And this will likely require some
experimentation and iteration based on the new infrastructure, as well as
any offer that emerges from 3rd parties, etc., to help with things like
builds. I'd welcome any help LO can offer in this area.
Regards,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Simon Phipps <si...@webmink.com>.
That is what I was suggesting and which Rob claims he won't need because its
so easy.
{Terse? Mobile!}
On Jun 3, 2011 3:23 PM, "Jim Jagielski" <ji...@jagunet.com> wrote:
>
> On Jun 3, 2011, at 10:05 AM, Michael Meeks wrote:
>
>> Hi Rob,
>>
>> On Thu, 2011-06-02 at 21:26 -0400, robert_weir@us.ibm.com wrote:
>>> Finally, I think we're exaggerating the difficulty of getting out a
>>> release of OpenOfice. LibreOffice did it very quickly. And so did IBM
>>> with Symphony. This is not rocket science.
>>
>> I am impressed by your optimism. Let us see how quickly you personally
>> manage a windows build yourself of what ends up inside the initial
>> Apache code-base (incidentally, I'm eagerly awaiting that myself, when
>> do we see it ? only after acceptance of the podling?). We could even
>> have a small race :-)
>>
>
> Stupid question time: If TDF already has the *build* infrastructure,
> then isn't *that* a clear choice of where at least some level of
> cooperation can occur.
>
> After all, the ASF provides source... the TDF could provide
> the builds?? (but that's not all, of course)...
>
> Just an idea...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: Proposal for OpenOffice Incubator strategy
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 3, 2011, at 10:05 AM, Michael Meeks wrote:
> Hi Rob,
>
> On Thu, 2011-06-02 at 21:26 -0400, robert_weir@us.ibm.com wrote:
>> Finally, I think we're exaggerating the difficulty of getting out a
>> release of OpenOfice. LibreOffice did it very quickly. And so did IBM
>> with Symphony. This is not rocket science.
>
> I am impressed by your optimism. Let us see how quickly you personally
> manage a windows build yourself of what ends up inside the initial
> Apache code-base (incidentally, I'm eagerly awaiting that myself, when
> do we see it ? only after acceptance of the podling?). We could even
> have a small race :-)
>
Stupid question time: If TDF already has the *build* infrastructure,
then isn't *that* a clear choice of where at least some level of
cooperation can occur.
After all, the ASF provides source... the TDF could provide
the builds?? (but that's not all, of course)...
Just an idea...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Michael Meeks <mi...@novell.com>.
Hi Rob,
On Thu, 2011-06-02 at 21:26 -0400, robert_weir@us.ibm.com wrote:
> Finally, I think we're exaggerating the difficulty of getting out a
> release of OpenOfice. LibreOffice did it very quickly. And so did IBM
> with Symphony. This is not rocket science.
I am impressed by your optimism. Let us see how quickly you personally
manage a windows build yourself of what ends up inside the initial
Apache code-base (incidentally, I'm eagerly awaiting that myself, when
do we see it ? only after acceptance of the podling?). We could even
have a small race :-)
> As for infrastructure, we are blessed with an amazing Apache
> Infrastructure Team. I have full confidence in their capabilities.
Last I looked OO.o 3.3.1 is 70+Gb of binary data to compile and
distribute to a mirror infrastructure. Shipping source is quite easy,
binaries are more troublesome to both create, and distribute. No doubt
it can be done - but it is less than trivial. I suspect that Symphony
does not cater for the diversity of locales that the community will
expect (as one data point).
> As for continuity of OpenOffice releases, there was a full stable
> release of OpenOffice in January and a preview 3.4.0 release in April.
> It is very reasonable for the new ApacheOffice project to start up,
> and even while in incubation produce a release.
It is unclear to me whether you can release binaries with all the
copy-left dependencies bundled as Apache. If that is so - easy enough.
If not, life will be harder, more development will be required, and the
result will be much less feature-full.
Which makes me wonder - who would provide the binaries for the
project ? is that typically done by a single individual ? or a company ?
(I assume not) or is it a requirement that anyone can do that ?
I ask because - it is a non-trivial amount of work to setup a Windows
(particularly) build environment capable of compiling OO.o, and clearly
diversity is useful there. Then again, if you have Eric and IBM that can
compile there perhaps that is robust enough.
As for the general quality of the 3.4.0 preview release, it seems to me
that there is some considerable work left to make that release-able.
> Will there be a longer-than-user delay between releases as we
> produce our first release? Of course. But I'm not particularly
> troubled by this.
My take is (and some of this depends on Apache policy, and what code
arrives out of the process) that it could take a handful of months to
get back to the OO.o position. But of course, I look forward to being
proved wrong.
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: Proposal for OpenOffice Incubator strategy
Posted by "Roman H. Gelbort" <ro...@piensalibre.com.ar>.
El 03/06/11 05:15, Ian Lynch escribió:
> We are getting demand for
> OpenOffice certification not any other name.
+1
This is a global and urgent demand by the companies that migrate to
OpenOffice.org... and we can't satisfier.
--
---------------------------------------------------------------------------------------
Prof. Román H. Gelbort
No busquemos aplicaciones que reemplacen aplicaciones,
sino aplicaciones que resuelvan problemas específicos...
http://www.piensalibre.com.ar
---------------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Ian Lynch <ia...@gmail.com>.
>
> But initially the proposal, as it has been
> made, is for the continuation of the existing OpenOffice code base under
> the existing OpenOffice trademark.
And for certification, the OOo brand name is important. (Can't speak for
other areas but probably in other sectors too) We are getting demand for
OpenOffice certification not any other name. That could change over time but
it seems a high risk to get rid of something that has clear value now.
--
Ian
Ofqual Accredited IT Qualifications
The Schools ITQ
www.theINGOTs.org +44 (0)1827 305940
You have received this email from the following company: The Learning
Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79
8AQ. Reg No: 05560797, Registered in England and Wales.
Re: Proposal for OpenOffice Incubator strategy
Posted by ro...@us.ibm.com.
Simon Phipps <si...@webmink.com> wrote on 06/02/2011 08:12:40 PM:
> 2. This incubator project, which sets out to be the "Firefox of
> OpenOffice", should proceed pretty much as described, but under a
> name other than OpenOffice (just as Firefox got a different name).
> Something like "Apache ODF Suite" that describes the intent to be
> the core code of a fresh start. Picking an alternative name will
> help avoid those millions of current users getting confused, and I
> suspect will cool down some of the emotions in this discussion. I'm
> sure Rob and the others behind the proposal will be able to populate
> a podling to get this started.
>
I could certainly see at some future time, if we did a generational
rewrite or refactoring of the code, that we could call it "OpenOffice2".
There is precedent for doing that at Apache, e.g., Xalan2, Xerces2, etc.
But that is branding discussion best left to the project in conjunction
with ASF branding experts. But initially the proposal, as it has been
made, is for the continuation of the existing OpenOffice code base under
the existing OpenOffice trademark.
> 3. Given that a substantial part of the effort that the LibreOffice
> project has committed has been the creation of an open repository
> and build system coupled with an effective international
> distribution system, I suggest that we collectively ask LibreOffice
> to take on the task of "business-as-usual" for OpenOffice, so that
> the Incubator project can focus on rebirth and not get swamped in
> the minutiae of "business as usual".
>
If existing LibreOffice developers should wish to join in support of the
Apache OpenOffice project proposal [1], and work, within Apache, under the
Apache 2.0 license, and then wish to specialize on tasks that support the
needs of existing OpenOffice users, then I would warmly extend my hand to
them. But I don't think anyone can can carve out an exclusive domain for
them in Apache and say only they can work on that release. Every member
will identify what tasks they wish to work on.
But in my experience, you want the version N and version N+1 to occur in
the same project, with the same PMC, but in different components. Often
there will be an wide overlap of developers, but also of users, test
cases, and certainly bug reports.
This supports backwards compatibility as well, which you know if critical
in this product category.
So I would not support splitting this across Apache projects.
[1] http://wiki.apache.org/incubator/OpenOfficeProposal
Finally, I think we're exaggerating the difficulty of getting out a
release of OpenOfice. LibreOffice did it very quickly. And so did IBM
with Symphony. This is not rocket science.
As for infrastructure, we are blessed with an amazing Apache
Infrastructure Team. I have full confidence in their capabilities.
As for continuity of OpenOffice releases, there was a full stable release
of OpenOffice in January and a preview 3.4.0 release in April. It is very
reasonable for the new ApacheOffice project to start up, and even while in
incubation produce a release. Will there be a longer-than-user delay
between releases as we produce our first release? Of course. But I'm not
particularly troubled by this.
Regards,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 2, 2011, at 8:12 PM, Simon Phipps wrote:
> TL;DR version: I think I see people talking past each other for a bunch of reasons, and I have a compromise proposal that might make things easier. It's at the bottom, and explained in some detail in the middle.
>
Welcome to the discussion. Thx for seeing the potential opportunities
that are now available.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/2/2011 7:12 PM, Simon Phipps wrote:
>
> This is purely my own thoughts, and there's no doubt room for improvement although I have run it past a few wise friends before posting it. But I suggest that without this clear demarcation of "new-project" and "business-as-usual-project" it will be very hard to disentangle the two sets of needs and fulfil the worthy objective at the start of the proposal, "Both Oracle and ASF agree that the OpenOffice.org development community, previously fragmented, would re-unite under ASF to ensure a stable and long term future for OpenOffice.org".
Simon, thank you for sharing these thoughts. Obviously the project
contributors themselves will have to determine their direction, and
the TDF folk will determine theirs, but this a unique perspective
that community members (broader defn.) would do well to bookmark :)
I've also appreciated Sam's comments on these threads, reiterated
by yourself and others, that the status quo was a liberally licensed
codebase to the select few, along with the free software license to
the masses. In that sense, adoption of the AL for some reflection or
new superset of OpenOffice doesn't seem at odds with the licensing
'politics' of contributors, as they were already offering their code
to both closed and open ecosystems by virtue of the Sun(Oracle) CCA
which they had signed. That said, it will be individual choices
which lead to contributions to the ASF, TDF and/or elsewhere.
I can see a role for some LGPL elements of an office suite built for
a copyleft platform, and a purpose for AL elements for cooperative
elements or even other platforms, as a free and non-discriminatory
form of the licenses which Sun(Oracle) previously sold. Especially
as it relates to document processing, the AL clearly offers the
advantage of broader adoption, and I can't imagine anyone within
the TDF or other OOo communities arguing against free standardization
of free document formats.
I can't yet envision how TDF and ASF based projects will partition
this larger work and community, but I'm reassured by several recent
posts, including yours, that this is likely happen to a net positive
outcome. Still hoping for some assurance that individuals who happen
to be Oracle employees will not be discouraged from participating on
their own time, should it interest them, and some assurance that the
scope of the non-granted files is not insurmountable on some realistic
timetable for a useful release.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for OpenOffice Incubator strategy
Posted by Simon Phipps <si...@webmink.com>.
On 3 Jun 2011, at 02:32, Allen Pulsifer wrote:
> Hello Simon,
>
> This is a noble proposal, but there are is an important prerequisite. The
> LibreOffice is currently only accepting contributions licensed under the
> LGPL. The LibreOffice project cannot take those contributions and insert
> them into an Apache Licensed project without the approval of those
> contributors.
I believe LibreOffice accepts contributions under any license that is compatible with LGPLv3, including the Apache license.
But anyway, contributions can be made to the "New Thing" project and then used by the "Business-As-Usual" project if that's what the contributor wants.
> Second, I am strongly against adopting any name other than OpenOffice. The
> world is looking for an "official" distribution. If the Apache project does
> not adopt the OpenOffice name, then someone else will, and this will confuse
> users even more.
I am proposing that Apache designate the business-as-usual project as the current "official distribution" on its behalf. There would be far greater confusion if there was /no/ official OpenOffice distribution for many months, which seems a risk at the moment.
> For example, even as we speak, a small company in San
> Francisco has filed an application with the United States Patent and
> Trademark Office to trademark the name "OpenOffice". A copy of this
> application is attached in PDF format. This company is the current operator
> of http://openoffice.us.com and apparently, they envision that they will
> become the exclusive distributor of "OpenOffice". Obviously, that must be
> stopped, which I was planning to post on in more detail. The bottom line
> however is that the only way to stop that is for a recognized organization
> to step up and distribute the "official" OpenOffice distribution.
In which case Apache should get the trademark from Oracle as soon as possible, put it to use on a valid distribution as soon as possible, and challenge the application.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Proposal for OpenOffice Incubator strategy
Posted by Allen Pulsifer <pu...@openoffice.org>.
Hello Simon,
This is a noble proposal, but there are is an important prerequisite. The
LibreOffice is currently only accepting contributions licensed under the
LGPL. The LibreOffice project cannot take those contributions and insert
them into an Apache Licensed project without the approval of those
contributors. So this goes back to the point I raised in my last post: has
anyone contacted the major LibreOffice contributors to determine if they are
willing to contribute code to an Apache licensed project?
Second, I am strongly against adopting any name other than OpenOffice. The
world is looking for an "official" distribution. If the Apache project does
not adopt the OpenOffice name, then someone else will, and this will confuse
users even more. For example, even as we speak, a small company in San
Francisco has filed an application with the United States Patent and
Trademark Office to trademark the name "OpenOffice". A copy of this
application is attached in PDF format. This company is the current operator
of http://openoffice.us.com and apparently, they envision that they will
become the exclusive distributor of "OpenOffice". Obviously, that must be
stopped, which I was planning to post on in more detail. The bottom line
however is that the only way to stop that is for a recognized organization
to step up and distribute the "official" OpenOffice distribution.
Allen