openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Non-Apache maintenance release for OOo 3.3?
Date Fri, 18 Nov 2011 21:42:14 GMT

On Nov 18, 2011, at 1:12 PM, Ross Gardler wrote:

> Sent from my mobile device, please forgive errors and brevity.
> On Nov 18, 2011 7:11 PM, "Dennis E. Hamilton" <>
> wrote:
> ...
>> An 3.3.1 maintenance release is *not* going to be an Apache
>> release, and not using any Apache code or licenses, I surmise.  It will
> be on
>> the 3.3 code base that is available under LGPL.  So it is a
>> derivative work, but not of Apache-licensed code.
> The press has covered the fact that is now at Apache. A
> release of OOo that is not from the ASF and not under the Apache license
> would be extremely confusing. It could potentially damage both the Apache
> and OOo brands.
> Could this be managed by our press people?
> Possibly, but it would require planning. Without a concrete proposal,
> approved by the PPMC and trademarks that planning cannot begin to start. By
> the time all this is done we'll be pretty close to an Apache release (if
> some of the predictions I've read here are to be believed).
> This conversation should have started months ago. I'll note that it did
> happen on this list and the PPMC decided to focus on the work need for an
> Apache release. This is the first that Team OOo have spoken of these plans.
> Working out a way to do this outside of the normal trademark guidelines is
> not going to be easy, especially without a proposal to consider.

I wouldn't even start considering a proposal from TOOo without changes to their website where
the ASF, Apache ownership of the trademark and Apache OO doesn't exist. Where
the whole OOo is in trouble if people don't give TOOo donations.

This must change immediately.


> Ross
>> In some sense, that is even more reason, under normal conditions, to deny
>> identification of that maintenance result with the name.
>> The tension is that it is closer to an 3.3 maintenance
> release
>> than anything that will ever appear as Apache OpenOffice version-whatever.
>> And more timely.  The question is under what conditions can this be
> allowed to
>> be identified as part of an 3.3.x progression?
>> - Dennis
>> It seems to me that it is more straightforward to consider that the
>> line has ended.  The only thing possible, now, are
> derivatives
>> of the LGPL code base (such as LibreOffice is already),
> other
>> existing peers of, and the reset that Apache OpenOffice
>> represents (and its eventual derivatives too).
>> In that regard, it would be more appropriate for the proposed 3.3.1
>> maintenance release to be identified as a derivative (e.g., Team
> OpenOffice
>> 3.3.1).  It can make nominative use of in regard to it
> being a
>> maintenance derivative of 3.3 and that aspect is settled.
>> Other trademark issues can be resolved with Team OpenOffice and,
> meanwhile,
>> the derivative can be a clean release with splash screens, About dialogs,
> and
>> other insignia that do not employ Apache trademarks and symbols in any way
>> beyond non-confusing nominative usage.  There is now no confusion about
> the
>> roots of the release and its independence from Apache.
>> On the site, it should be possible to identify the
> existence of
>> this derivative and link to a Team OpenOffice page that indicates its
>> availability, solicits funds, or whatever, as a recognized peer.  It is
>> possible to link to LibreOffice in the same manner, and also other
> members of
>> lineage and, other support for the ODF document format as
> well.
>> The emergence of Apache OpenOffice and the steps toward incubator
> releases can
>> also be featured, obviously.
>> That, apart from complications concerning localizations and other
> downstream
>> support of the 3.3.1 including user support and bug reporting against the
>> release, would seem to be that.  There is also the LGPL requirement that
> the
>> source code of the release be available.
>> I suspect that there is a desire for closer coupling than that.  The
> problem,
>> of course, is that the Podling can do nothing with the 3.3
>> code base.  And my understanding is that binaries of such code shall not
> be
>> distributed via Apache sites either. The Apache OpenOffice code base is
> not
>> usable instead; it is not even being positioned for maintenance release
> of an
>> 3.3.1 equivalent. Probably the only case would be the
> unlikely
>> possibility of Oracle undertaking such a release (meaning that updates
> would
>> all be under Oracle SCA though).
>> -----Original Message-----
>> From: Shane Curcuru []
>> Sent: Friday, November 18, 2011 09:06
>> To:
>> Subject: Re: Non-Apache maintenance release for OOo 3.3?
>> On 2011-11-18 11:16 AM, Stefan Taxhet wrote:
>>> Hi Don, all,
>>> Am 17.11.2011 15:34, schrieb Donald Harbison:
>>>> On Thu, Nov 17, 2011 at 9:14 AM, Stefan Taxhet<> wrote:
>>>>> Am 17.11.2011 02:23, schrieb Rob Weir:
>> ...snip...
>>>>> What is your proposal for the name of your release? Please make a
>>>>> proposal
>>>> for what you wish to name your release.
>>> Rob described the two options very concise. The preference would be to
>>> release " 3.3.1" with consent of the home of development
>>> work for future releases.
>> ...
>> The Apache Open Office PPMC is the only organization that should be
>> releasing a software product using just the name "".
>> Apache trademark policy is clear that third parties are *not* allowed to
>> use Apache brands in confusing or infringing manners on software products.
>> We offer broad guidelines for using a "Powered By" style of naming for
>> third party software products that are either built on top of, extend,
>> or otherwise use Apache code but add your own code to your product:
>> Note that we'd certainly consider permitting other phrases besides the
>> "Powered By" phrase, like "Built Using", etc. (but not "Distribution" or
>> "Release" or other similarly non-specific phrases).  This allows third
>> parties to create their own, independently branded products while still
>> allowing third parties to show the obvious relationship to the
>> underlying Apache product.
>> -Shane

View raw message