incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: selling open office
Date Fri, 02 Mar 2012 02:03:50 GMT
On Thu, Mar 1, 2012 at 6:12 PM, Dave Fisher <> wrote:
> Hi Rob,
> Good questions. I'll play. You are seeking the boundary of what is permissible to be
called AOO, powered by AOO and not permitted. Possible answers below:
> On Feb 29, 2012, at 8:48 AM, Rob Weir wrote:
>> On Wed, Feb 29, 2012 at 11:04 AM, Pedro Giffuni <> wrote:
>>> FWIW;
>>> On 02/29/12 07:54, Rob Weir wrote:
>>>> I don't see how this would have helped with Team OOo.  Surely, the
>>>> logo issue was only a small part of the problem, a very small part.
>>>> Even if we had a "powered by logo", there would have been the other
>>>> issues that were entirely irreconcilable with any reasonable Apache or
>>>> project trademark policy, such as the name of their organization and
>>>> the tenor of their fundraising efforts.  So not a very good example,
>>>> IMHO.
>>>> Maybe a better example would be the FreeBSD port?  That does not have
>>>> the extraneous issues that we had with TOO.
>>> For FreeBSD we will not be rebranding so the idea will be more
>>> in the lines of "Apache OpenOffice powered by FreeBSD" and
>>> not the other way around.
>> But the question is where do we draw the line?
>> At one pole, I think we all agree that released versions of AOO,
>> approved by the PMC and made available on the Apache mirrors,are
>> properly called "Apache OpenOffice".
>> I think also, that most of us agree that exactly copies (MD5 hashes
>> match, etc.) of these releases may also be referred to as Apache
>> OpenOffice, whether distributed via other websites, on CD's, even if
>> offered for sale.  This doesn't mean all cases are acceptable.  If I
>> form a company called "OpenOffice Direct" and sell CD's of AOO from my
>> website and use the AOO logo, then this is a problem.
>> But beyond literal copies, with MD5 hashes, matches, what else can be
>> called "Apache OpenOffice"?
>> For example:
>> 1) I recompile AOO using a better optimizing compiler and release that
>> on my website.  Can I call it "Apache OpenOffice"?
> Since source releases are required for all projects then I think that this would need
to be Apache OpenOffice. Should we distinguish binaries not made by the PPMC as Apache OpenOffice
for Foo or is it Foo Office powered by Apache OpenOffice?  It is probably better for the
brand if it is AOO for Foo or AOO, Foo edition.

Unstated assumption is that rebuilding a complex product like AOO,
with a different tool set, like a different compiler, can introduce
bugs.  It might do better code optimization, but it can also cause
subtle bugs, or even make a latent coding error show itself as a

If we think the "Apache OpenOffice" brand stands for things like
quality, etc., then we should ensure that it is used in conjunction
with products that satisfy those same standards.  Going through the
PMC release process is the primary way in which we ensure these
criteria are met.  But might there be other ways?  For example, if we
had a comprehensive test suite (something we don't have today) would
we be comfortable  allowing the trademark to be used with non-PMC
releases that passed those same tests?   This is similar to how some
other trademarks are used.  For example. Microsoft's various logo
certification programs are really to support a quality mark.  Ditto
for Underwriters Laboratories, etc.

So in this case I'd tend to not give permission, unless the PMC has
some way of assuring that quality standards are met.

>> 2) I take the AOO source, but not from a release, but just a snapshot
>> from the project's SVN.  I think it is good enough for a release, even
>> though the PMC has not yet officially declared a release.  Can I build
>> it and call it Apache OpenOffice?
> No way, it is not an approved source code release. You may be able to say "Powered by"
or "Built with" if desired, but it is not required.


>> 3) I take the AOO source, from a release, but then make additional
>> patches in it, to fix some bugs. Maybe these patches are also
>> contributed back to the AOO project.  Maybe the patches actually come
>> from the AOO project.  This is a common pattern for how a package
>> maintainer for a Linux distro might work.  Can they call such work
>> "Apache OpenOffice"?
> No, it is not an official release. You can call it Symphony or LibreOffice, whatever,
but it is not AOO until the patches are taken in and released.

This example is similar to the issues that were involved in the
Firefox/IceWeasel controversy.

Could be a good use of "Powered by".

>> 4) I take the AOO source, from SVN, not from a release, and port it to
>> a different operating system.  My binaries were never signed off on my
>> the PMC.  The quality and the binaries might be different than the
>> quality of the PMC-approved releases. May I call my port "Apache
>> OpenOffice"?
> No. It is not a release.

This is a variation on #2 above.

On the one hand, I suspect that a port based purely on a PMC-approved
Apache release would be OK.  On the other hand, that is pretty much
back to the "different compiler" case, where a different compiler can
introduce different bugs.

>> 5) I take the AOO binary package, as released, and don't change any of
>> the compiled code.  But I do modify the install program to install
>> additional dictionaries, language packs, extensions, etc.  The core
>> code is identical.  I've only changed the install.  May I call this
>> "Apache OpenOffice"?
> Yes, perhaps AOO, Mongolian Edition.

What if I said I was modifying the install program to insert various
"sponsored offers", various adware applications, including some that
modify your browser's home page and search settings and do other
annoying things.  That is something that has actually happened on
several occasions.  I don't think we want to permit this.

>> 6) I take the AOO binary package and do not change it at all.  But I
>> write my own installer that invokes the AOO installer to install AOO,
>> and then installs additional dictionaries, language packs, extensions,
>> etc.  So the AOO binary package is unchanged, MD5 hashes match, etc.
>> Is this called "Apache OpenOffice + Foo"?  or what do we call it?
> Yes, perhaps AOO, Mongolian Edition.

The previous adware case could be done this way as well.

It is not clear to me that we can craft a policy that would disallow
this while also allowing obviously beneficial bundles.  For example,
bundling Apache OpenOffice with plugins that benefit the blind, such
as the existing Braille generator and DAISY talking book extensions.
Although we could say that this requires a name change, it is rather
difficult for someone to change the name.  To do so they would need to
get dirty at the source code level, and rebuild AOO with different
splash screen and about graphics, replace strings in several
translations, etc.  I think this would go against one of the easiest
ways in which downstream consumers can benefit from AOO, which is by
creating custom bundles.

Note:  not every bundler publicly distributes their packages.  It
might just be something deployed within a corporation.

Anyways, this is the one that troubles me.  I don't see how to craft a
policy that allows the good while preventing the actual abuses that
have occurred.

One option would be to simply say such uses are permitted only with
explicit PMC approval.

>> 7) I am a PC distributor and I pre-install AOO on my PC's.  I use the
>> officially released binary packages from Apache, install them, and
>> then modify some of the default user preferences.  I also include some
>> additional plugins that connect the user to my subscription support
>> site.  May I say in my advertising that my PC's "Include Apache
>> OpenOffice(TM)"?  May I use the logo?
> Yes and yes as long as trademark rules are followed including full and clear disclosure
that the support services and cost are not in any way related by Apache OpenOffice.

I'd state this more as: they cannot say anything that would imply that
the support services were associated with Apache.  I don't think we
need to require a proactive statement.


>> It is cases like this that we need to think about and develop some
>> rational way of deciding:
>> A) What cases are always allowed?
> (5), (6) and (7).
>> B) What cases are always forbidden?
> (2), (3) and (4).
>> C) What cases are reviewed on a case-by-case basis?
> (1) maybe, but maybe it is (A). In this case I think that the developer would want to
engage the project.
> Regards,
> Dave
>>> Pedro.

View raw message