openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Refactoring the brand: Apache ooo + (was branding)
Date Tue, 02 Aug 2011 23:12:02 GMT
On Tue, Aug 2, 2011 at 6:46 PM, Eike Rathke <> wrote:
> Hi Rob,
> On Tuesday, 2011-08-02 13:18:37 -0400, Rob Weir wrote:
>> > And we should look around at some of the TLP project wikis that allow public
>> Pass along some links if you find some good examples.
> I think these explain well what needs to be considered for project
> documentation wikis and that it is allowed to use conventional wikis:
> | the touch point is whether you want to reserve the right to bundle the
> | documentation with a release and/or check a copy into an ASF repository

The essential question to ask is, what rights do users of the doc
have?  If we want downstream consumers to be able to copy, modify and
redistribute the documentation then we need it under Apache 2.0, which
is what would happen if the author signed the iCLA.

Project releases, naturally, are all under Apache 2.0 and must
guarantee these rights.  This is true for any doc that is bundled with

As you know, we don't currently bundle the wiki doc with the releases.
 But should we reserve the right to do this?  Let me give you a very
plausible use case for that:

Imagine a school or government department, or a company, that wants to
deploy OpenOffice in their organization, but also wants to host their
own copy of the wiki documentation, inside their firewall, perhaps
with some customized material.  This could range from adding
additional links to internal template servers, to removing irrelevant
information, to adding documentation regarding internal-only plugins.
It could be complete, or only for some small number of pages.

Is something like that a reasonable use?  Something that we should
"reserve the right" to support?  I think so.  If we ever wanted to
support something like this, then we would need the wiki (or at least
the core doc parts of the wiki) be under a common permissive license.


>  Eike
> --
>  PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
>  Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

View raw message