openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Suárez-Potts <>
Subject Re: Non-Apache maintenance release for OOo 3.3?
Date Sat, 19 Nov 2011 05:11:40 GMT

(Nonsense words? iPad's spellchecker.)

-- Louis Suárez-Potts 


On 2011-11-18, at 16:12, 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 think it's quite manageable. One need only do what we used to do with some releases, viz.,
more or less downplay it and emphasise that this is a maintenance one. Indeed, we can also
use the occasion to point to the *new* and exciting Apache release, and to the nature of the
new home.

> 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